Franc Mac

2026-04-14 15:22:26

Le irricevibili parole di Trump sul Presidente del Consiglio italiano: “Vi piace che la vostra presidente non stia facendo nulla per ottenere il petrolio? Sono scioccato da lei. Pensavo che avesse coraggio, mi sbagliavo”

“È lei che è inaccettabile, perché 
non le importa se l’Iran ha una arma nucleare e farebbe saltare in aria l’Italia in due minuti se ne avesse la possibilità” afferma il presidente statunitense secondo cui la presidente del Consiglio italiana “non è più la stessa persona, e l’Italia non sarà lo stesso paese, l’immigrazione sta uccidendo l’Italia e tutta l’Europa”.

@[url=https://feddit.it/c/politica]Politica interna, europea e internazionale[/url] interna, europea e internazionale

♲ @elezioni@poliverso.org:

Trump contro Meloni: “Scioccato dalla premier, pensavo avesse coraggio”. Poi attacca ancora il Papa: “Dovrebbe tacere sulla guerra in Iran, non capisce”

@[url=https://feddit.it/c/politica]Politica interna, europea e internazionale[/url] interna, europea e internazionale
È un Donald Trump senza freni quello che parla al Corriere della Sera a cui ha concesso una breve intervista in esclusiva. Il presidente Usa scarica Giorgia Meloni che aveva definito “inaccettabili” le dichiarazioni

Spcnet.it

2026-04-14 12:10:20

Azure MCP Server 2.0: 276 strumenti per integrare Azure negli agenti AI

Il Model Context Protocol (MCP) sta rapidamente diventando lo standard de facto per consentire agli agenti AI di interagire con servizi e strumenti esterni. Microsoft ha appena rilasciato la versione 2.0 stabile di Azure MCP Server, un passo significativo che porta a 276 strumenti distribuiti su 57 servizi Azure direttamente accessibili da qualsiasi agente o IDE compatibile con MCP.

Cos’è Azure MCP Server?

Azure MCP Server è un’implementazione del Model Context Protocol che funge da ponte tra gli agenti AI e l’ecosistema Azure. Invece di dover scrivere codice di integrazione personalizzato per ogni servizio, un agente AI può semplicemente “scoprire” e utilizzare i tool messi a disposizione dal server MCP, che includono operazioni di provisioning, deployment, monitoraggio e diagnostica su decine di servizi Azure.

L’idea centrale è quella di rendere le operazioni su Azure talmente naturali per un agente AI quanto lo è per un programmatore umano navigare sul portale Azure o usare la CLI. La versione 2.0 segna la transizione da una release preview a un prodotto stabile e pronto per l’uso in produzione.

Le principali novità della versione 2.0

Deployment remoto self-hosted

La novità più significativa di questa release è il supporto al deployment remoto. Nelle versioni precedenti, il server MCP doveva girare localmente sulla macchina dello sviluppatore. Con la 2.0, è possibile distribuire Azure MCP Server come servizio centralizzato, accessibile da tutto il team o dall’intera organizzazione tramite trasporto HTTP.

Questo cambia radicalmente le possibilità di adozione enterprise: invece di configurare ogni sviluppatore individualmente, il team di platform engineering può mantenere un’istanza centralizzata con configurazione e governance coerenti. Meno deriva di configurazione, più sicurezza, un unico punto di aggiornamento.

Integrazione con Microsoft Foundry e flusso OBO

La versione 2.0 introduce il supporto per il flusso On-Behalf-Of (OBO), noto anche come OpenID Connect delegation. Questo meccanismo consente al server MCP di chiamare le API Azure usando il contesto dell’utente autenticato, mantenendo la separazione delle identità e rispettando i permessi RBAC assegnati al singolo utente.

L’integrazione con Microsoft Foundry consente di usare le managed identity direttamente, semplificando la gestione delle credenziali in ambienti cloud-native senza dover gestire segreti esplicitamente.

Security hardening

Con il passaggio a stable, Microsoft ha rafforzato significativamente la sicurezza del server:

• Validazione endpoint più rigorosa
• Protezioni contro pattern di injection nei tool di query
• Controlli di isolamento più stringenti

Questi miglioramenti sono essenziali per l’adozione in contesti enterprise dove la superficie di attacco deve essere minimizzata.

Supporto sovereign cloud

Azure MCP Server 2.0 è ora configurabile per operare su Azure US Government e Azure operated by 21Vianet (il cloud sovrano cinese), ampliando notevolmente la portata per organizzazioni soggette a requisiti di sovranità dei dati.

Come installare e usare Azure MCP Server

Il server è disponibile attraverso diversi canali di distribuzione, adatti a scenari diversi:

Via IDE extension

La via più semplice per gli sviluppatori è attraverso le estensioni per i principali IDE:

• Visual Studio Code
• Visual Studio
• IntelliJ / Eclipse
• Cursor

Una volta installata l’estensione, il server MCP viene configurato automaticamente e i tool Azure diventano disponibili nell’assistente AI del tuo IDE.

Via GitHub Copilot CLI o Claude Code

Per chi lavora da terminale, Azure MCP Server si integra nativamente con GitHub Copilot CLI e Claude Code, consentendo di gestire risorse Azure direttamente dalla riga di comando con il supporto dell’AI.

Via Docker (deployment self-hosted)

Per il deployment remoto centralizzato, Microsoft fornisce un’immagine Docker ufficiale:

# Scarica l'immagine Docker
docker pull mcr.microsoft.com/azure-mcp-server:latest

# Esegui il server localmente
docker run -p 8080:8080 mcr.microsoft.com/azure-mcp-server:latest


La documentazione completa per il self-hosting è disponibile su aka.ms/azmcp/self-host.

Panoramica degli strumenti disponibili

Con 276 tool distribuiti su 57 servizi Azure, la copertura è notevolmente ampia. Gli strumenti coprono l’intero ciclo di vita delle risorse cloud:

• Provisioning e deployment: creare e configurare risorse Azure (VM, App Service, AKS, ecc.)
• Monitoraggio e diagnostica: interrogare Azure Monitor, Log Analytics, Application Insights
• Gestione identità: interagire con Microsoft Entra ID, gestire service principal e managed identity
• Storage e database: operazioni su Blob Storage, Cosmos DB, Azure SQL
• Networking: configurazione di VNet, DNS, load balancer
• Servizi AI: integrazione con Azure OpenAI, AI Foundry, Cognitive Services

Implicazioni per il workflow degli sviluppatori

L’arrivo di Azure MCP Server 2.0 stabile ha implicazioni concrete per i team di sviluppo che usano Azure:

Meno context switching: gli sviluppatori possono interrogare lo stato dei loro servizi Azure, diagnosticare problemi e persino deployare aggiornamenti senza uscire dall’IDE o passare al portale Azure.

Automazione conversazionale: invece di ricordare i comandi esatti della Azure CLI, è possibile descrivere in linguaggio naturale l’operazione desiderata e lasciare che l’agente AI formuli la chiamata corretta al tool MCP.

Governance centralizzata: con il deployment self-hosted, le organizzazioni possono controllare centralmente quali tool sono disponibili, chi può usarli e in che contesto, mantenendo audit trail completi.

Conclusione

Azure MCP Server 2.0 rappresenta un passo maturo verso l’integrazione dell’AI nei workflow operativi su cloud. Il supporto al deployment remoto e al flusso OBO erano i due tasselli mancanti per l’adozione enterprise, e la loro disponibilità in una release stabile apre scenari concreti di adozione su larga scala.

Per i team che già usano GitHub Copilot o altri agenti AI nel loro IDE, la barriera di ingresso è minima: basta installare l’estensione e il ricco catalogo di tool Azure diventa immediatamente disponibile. Per chi vuole andare oltre, il deployment self-hosted offre la flessibilità necessaria per integrarlo nei flussi platform engineering più sofisticati.

Fonte originale: Announcing Azure MCP Server 2.0 Stable Release — Sandeep Sen, Microsoft Azure SDK Blog

Announcing Azure MCP Server 2.0 Stable Release for Self-Hosted Agentic Cloud Automation

Azure MCP Server 2.0 introduces self‑hosted remote deployment for secure agentic workflows using standardized tools across Azure services.

^{Sandeep Sen (Azure SDK Blog)}

(in)sicurezza digitale

2026-04-14 12:08:51

Phishing SPID contro le Pubbliche Amministrazioni: CERT-AGID smonta la campagna che usa siti WordPress legittimi per rubare credenziali istituzionali

Un’istanza WordPress compromessa, loghi dell’Agenzia delle Entrate e del Sistema Pubblico d’Identità Digitale riprodotti con precisione millimetrica, link personalizzati con l’email della vittima pre-compilata: CERT-AGID ha rilevato una nuova campagna di phishing che prende di mira le Pubbliche Amministrazioni italiane, con l’obiettivo di sottrarre credenziali SPID e accessi istituzionali. L’analisi tecnica rivela un attacco che sfrutta l’infrastruttura legittima per eludere i filtri antispam e conquistare la fiducia delle vittime.

Il Vettore: un’infrastruttura legittima trasformata in arma

Il primo elemento che distingue questa campagna dalle operazioni di phishing più rudimentali è la scelta dell’infrastruttura. Gli attaccanti non hanno registrato domini malevoli evidenti — hanno invece compromesso un server WordPress legittimo (documentato all’indirizzo wp-dev.typhur.com/agenziaentrate/), sfruttandone la reputazione consolidata per eludere i filtri antispam e i sistemi di blacklist automatici.

Un sito web legittimo offre agli attaccanti tre vantaggi competitivi fondamentali: certificati HTTPS validi che mostrano il lucchetto verde nel browser delle vittime, una reputazione di dominio già stabilita che bypassa i filtri di sicurezza email, e la capacità di ospitare contenuto HTML arbitrario che replica fedelmente le interfacce istituzionali italiane. Il vettore di compromissione del WordPress è quasi certamente legato a plugin o temi non aggiornati — il vettore più comune per questo tipo di hijacking.

Anatomia dell’attacco: come funziona la truffa SPID

La catena di attacco documentata da CERT-AGID si articola in più fasi progettate per massimizzare la credibilità e minimizzare i campanelli d’allarme per la vittima:

• Fase 1 — Email di spearphishing personalizzata: la vittima riceve una comunicazione che la invita ad accedere alla propria area riservata dell’Agenzia delle Entrate-Riscossione. Il link contenuto nell’email è personalizzato e include già l’indirizzo email del destinatario come parametro URL.
• Fase 2 — Pagina di login pre-compilata: cliccando il link, la vittima atterra su una pagina che replica fedelmente il portale dell’Agenzia delle Entrate, completa di loghi ufficiali di AdE, SPID e AgID. La casella email è già compilata con il proprio indirizzo — un elemento che abbassa drasticamente il livello di sospetto e aumenta la probabilità di inserimento della password.
• Fase 3 — Harvesting delle credenziali: al momento dell’invio, la password viene trasmessa ai server degli attaccanti. La vittima viene quindi reindirizzata al sito reale dell’Agenzia delle Entrate dove appare un messaggio di errore simulato — un “errore di sistema generico” che rende plausibile la necessità di reinserire le credenziali.
• Fase 4 — Accesso istituzionale: con le credenziali SPID compromesse, gli attaccanti ottengono potenzialmente accesso a tutti i servizi della Pubblica Amministrazione collegati all’identità digitale: portali fiscali, documenti istituzionali, sistemi interni delle PA.

Target primario: Pubbliche Amministrazioni

L’aspetto più allarmante della campagna, come sottolineato da CERT-AGID, è la natura del target primario: non utenti consumer generici, ma dipendenti e funzionari delle Pubbliche Amministrazioni italiane. Questa scelta non è casuale. Le credenziali SPID di un funzionario PA offrono un accesso privilegiato a sistemi interni, documenti riservati e portali interistituzionali che un account privato non avrebbe. La compromissione di un account PA può diventare il punto di partenza per movimenti laterali all’interno dei sistemi governativi, attacchi BEC (Business Email Compromise) verso altre istituzioni, e persino accessi a dati sensibili di cittadini.

MITRE ATT&CK: mappatura delle tecniche

• T1566.002 — Phishing: Spearphishing Link: link personalizzati con l’email della vittima pre-inserita per massimizzare la credibilità
• T1078 — Valid Accounts: compromissione di account SPID legittimi per accesso a sistemi istituzionali
• T1190 — Exploit Public-Facing Application: compromissione del server WordPress tramite vulnerabilità in plugin/temi per uso come infrastruttura di phishing
• T1036 — Masquerading: replica accurata dell’interfaccia di portali governativi legittimi (AdE, SPID, AgID)
• T1589.002 — Gather Victim Identity Information: Email Addresses: utilizzo di indirizzi email pre-identificati nei link personalizzati

Indicatori di Compromissione (IoC)

# Domini malevoli identificati
agenziadelleentrate.live          # Dominio typosquatting principale
wp-dev.typhur.com/agenziaentrate/ # WordPress compromesso usato come host
# Dominio mittente email
@propiski.com                     # Utilizzato come sender domain nelle email di phishing
# Dominio di reindirizzamento
sushicool.net                     # Usato come redirect dopo la sottrazione delle credenziali
# File IoC ufficiale CERT-AGID
phishing_AdE_10_04_26.json        # Disponibile tramite feed ufficiale CERT-AGID

Il contesto: una campagna seriale contro l’Identità Digitale italiana

Questa campagna non nasce dal nulla. L’Agenzia delle Entrate ha emesso un avviso ufficiale già il 30 marzo 2026, segnalando campagne attive che sfruttano impropriamente i loghi di AdE, SPID e AgID. La storia recente mostra un pattern ricorrente: gli attori malevoli hanno identificato nel sistema SPID un bersaglio appetibile perché rappresenta la chiave di accesso unificata ai servizi digitali della PA italiana. Compromettere uno SPID significa potenzialmente accedere a decine di portali governativi con un’unica credenziale.

La tecnica di compromissione di siti WordPress legittimi come piattaforma di phishing è altrettanto consolidata: consente di sfruttare la reputazione del dominio ospitante e i certificati TLS validi per superare i controlli automatici, scaricando il costo di mantenimento dell’infrastruttura sull’ignaro proprietario del sito compromesso.

Raccomandazioni per i difensori e le Pubbliche Amministrazioni

• MFA obbligatoria su tutti gli account istituzionali: l’autenticazione a due fattori vanifica il phishing di credenziali anche quando la vittima inserisce username e password sulla pagina falsa
• Formazione specifica sul phishing SPID: i dipendenti PA devono sapere che l’Agenzia delle Entrate non chiede mai credenziali via email; l’accesso ai portali fiscali va effettuato sempre digitando manualmente l’URL o utilizzando bookmark certificati
• Monitoraggio del feed IoC CERT-AGID: l’integrazione automatica del feed JSON di CERT-AGID nei propri sistemi di sicurezza permette il blocco in tempo reale dei domini malevoli identificati
• Verifica dell’URL nel browser: prima di inserire qualsiasi credenziale SPID, verificare che l’URL nella barra del browser corrisponda esattamente al dominio ufficiale (agenziaentrate.gov.it)
• Audit CMS e aggiornamento plugin: le organizzazioni che gestiscono siti WordPress devono implementare processi di patch management rigorosi per evitare che le proprie infrastrutture vengano weaponizzate come piattaforme di phishing
• Segnalazione a CERT-AGID: eventuali email sospette che impersonano l’Agenzia delle Entrate vanno segnalate immediatamente all’indirizzo dedicato di CERT-AGID per l’aggiornamento del feed IoC

Il CERT-AGID ha già avvisato le organizzazioni coinvolte e richiesto il takedown delle pagine di phishing identificate. Tuttavia, data la natura delle campagne di phishing — che spesso cambiano rapidamente infrastruttura per sopravvivere ai takedown — il monitoraggio continuo rimane essenziale.

macfranc

2026-04-14 09:09:09

In queste ore si sta verificando un attacco per rubare gli account agli utenti Mastodon. Ecco cosa sapere per evitare le truffe su Mastodon e nel Fediverso con la guida di @FediTips

Il post è stato ripubblicato sul gruppo @fediverso

Come in qualsiasi altro social network, anche su Mastodon e nel più ampio Fediverso potresti imbatterti in truffatori. Ecco come individuarli e cosa fare in caso di dubbio.

1. Truffa: "Abbiamo bisogno che tu verifichi il tuo account"
2. Truffa: "Vogliamo pagarti per i post / instaurare una collaborazione / offrirti una ricompensa"
3. Truffa: "Si prega di modificare temporaneamente l'indirizzo email del proprio account"

• Cosa devo fare se vedo un post truffaldino?
• Dovrei vergognarmi se sono caduto vittima di una truffa?

NB: questa guida è una traduzione della pagina realizzata da @FediTips

[SEGUE]

How to avoid scammers on Mastodon and the Fediverse | Fedi.Tips – An Unofficial Guide to Mastodon and the Fediverse

An unofficial guide to using Mastodon and the Fediverse

^{FediTips (Fedi.Tips - An Unofficial Guide to Mastodon and the Fediverse)}

(in)sicurezza digitale

2026-04-14 08:10:24

APT35 e la Cyber Guerra Parallela: come l’Iran aveva già compromesso ogni paese colpito nell’Operazione Epic Fury

Si parla di:
Toggle

• La notte del 28 Febbraio: quando la guerra digitale diventa fisica
• APT35 e la dottrina della Pre-Posizione
• Il modello di conflitto a tre fasi
• L’ecosistema APT iraniano: non solo APT35
• Infrastruttura di attacco: offuscamento multi-livello
• Vulnerabilità sfruttate: un catalogo di CVE note
• Il significato strategico: un nuovo standard di conflitto ibrido
• Indicazioni per i difensori

Prima che i missili iraniani illuminassero il cielo di sette nazioni, un’altra guerra era già in corso nelle reti digitali di quei paesi. L’analisi della campagna condotta da APT35 rivela come il gruppo legato all’IRGC avesse sistematicamente compromesso le infrastrutture critiche di ogni paese successivamente colpito dall’Operazione Epic Fury, trasformando la cyber intelligence in un componente integrale della dottrina militare iraniana.

La notte del 28 Febbraio: quando la guerra digitale diventa fisica

Il 28 febbraio 2026, Stati Uniti e Israele hanno lanciato l’Operazione Epic Fury (denominata “Operazione Roaring Lion” dalla parte israeliana): oltre 1.250 obiettivi colpiti nelle prime 48 ore, infrastrutture nucleari iraniane distrutte, connettività internet dell’Iran ridotta all’1-4% dei livelli normali in quello che è stato definito il più grande cyberattacco della storia. Ma ciò che i rapporti di intelligence successivi hanno rivelato è ancora più preoccupante: l’Iran non si trovava impreparato. Per mesi, forse anni, i suoi gruppi APT affiliati all’IRGC e al MOIS avevano già mappato, compromesso e pre-posizionato capacità offensive nelle reti digitali di ogni paese che avrebbe poi colpito.

APT35 e la dottrina della Pre-Posizione

APT35 — conosciuto anche come Charming Kitten, Phosphorus, Magic Hound e Mint Sandstorm — è il gruppo cyber più rappresentativo dell’IRGC Intelligence Organisation (Unit 1500, Department 40), attivo almeno dal 2014. La sua caratteristica distintiva non è la sofisticazione tecnica delle singole operazioni, ma la pazienza strategica: operazioni di ricognizione prolungate, accesso silenzioso mantenuto per mesi o anni prima di un’attivazione.

Secondo le analisi di CloudSek e dei ricercatori di IT Nerd, APT35 aveva documentabilmente compromesso infrastrutture nei seguenti paesi prima dei bombardamenti:

• Giordania: accesso ai dati dell’aviazione civile e al Ministero della Giustizia
• Emirati Arabi Uniti: sistemi di aviazione e asset governativi a Dubai
• Arabia Saudita: documenti governativi e infrastrutture energetiche; il malware Shamoon ha distrutto circa 15.000 workstation nel settore energetico saudita prima delle operazioni cinetiche
• Kuwait, Bahrain, Qatar: attività di ricognizione e targeting operativo
• Israele: sistemi industriali e infrastrutture civili

Il modello di conflitto a tre fasi

L’analisi degli eventi suggerisce un modello di conflitto ibrido strutturato in tre fasi sequenziali, ormai consolidato nella dottrina iraniana:

• Fase 1 — Ricognizione estesa e silenziosa: compromissione di sistemi internet-facing (Exchange Server, VPN, Fortinet FortiOS), installazione di webshell, tunneling nascosto, raccolta di intelligence su reti, persone e infrastrutture critiche
• Fase 2 — Degradazione pre-cinetica: attivazione di malware wiper (come Shamoon) per distruggere workstation, esfiltrazione di documenti strategici, interruzione di servizi prima degli attacchi fisici
• Fase 3 — Coordinamento post-attacco: entro 24 ore dall’avvio delle operazioni militari, creazione di un “Electronic Operations Room” che ha coordinato oltre 60 gruppi hacktivist per colpire contemporaneamente infrastrutture governative, finanziarie e critiche

L’ecosistema APT iraniano: non solo APT35

APT35 non ha operato in isolamento. Il Tenable Research ha identificato 12 gruppi APT iraniani attivi nelle settimane e mesi precedenti l’Operazione Epic Fury, coordinati attraverso strutture parallele:

Gruppi IRGC-affiliati: Pioneer Kitten (Fox Kitten, UNC757), Imperial Kitten (Tortoiseshell, TA456), CyberAv3ngers — quest’ultimo specializzato nel targeting di sistemi OT e PLC nei sistemi idrici. Gruppi MOIS-affiliati: APT34/OilRig (nuova infrastruttura per attacchi ed esfiltrazione), MuddyWater/Mango Sandstorm (picco di attività nella rete nel settembre 2025, con server distribuiti in Russia, Estonia e UK), Banished Kitten/Void Manticore (usa la persona Handala, wiper-focused). Gruppi IRGC-IO: APT42 (credential harvesting tramite social engineering). Gruppi IRGC-CEC: Cotton Sandstorm (revival della persona Altoufan Team).

Infrastruttura di attacco: offuscamento multi-livello

Particolarmente sofisticata è stata l’architettura di infrastruttura impiegata per mascherare l’attribuzione. Netcrook ha documentato uno schema di offuscamento a tre livelli:

• Livello base: ISP iraniani (Sefroyek Pardaz Engineering) come punto di origine
• Bulletproof hosting: ALEXHOST in Moldova e RouterHosting LLC nel Wyoming (USA) come nodi intermedi
• Shell company layer: società fittizie come Cloudblast (registrata negli USA, operativa a Dubai) e UltaHost (registrazioni UK/USA) per la gestione dell’infrastruttura front-end

Questa architettura ha reso estremamente complessa l’attribuzione rapida e le azioni legali di takedown durante le operazioni.

Vulnerabilità sfruttate: un catalogo di CVE note

Il documento Tenable elenca 67 CVE sfruttate dai gruppi iraniani, incluse vulnerabilità ben note mai patchate da molte organizzazioni. Tra le più critiche:

# CVE sfruttate dai gruppi APT iraniani (selezione)
CVE-2021-26855  # Microsoft Exchange Server - ProxyLogon SSRF
CVE-2021-26858  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-26857  # Microsoft Exchange - insecure deserialization
CVE-2021-27065  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-44228  # Apache Log4j2 - Log4Shell RCE
CVE-2022-40684  # Fortinet FortiOS/FortiProxy - authentication bypass
CVE-2020-3153   # Cisco ASA - path traversal
# Malware famiglie associate
BellaCiao        # RAT/implant IRGC (codice sorgente esposto in leak)
Sagheb RAT       # Remote Access Trojan IRGC
Shamoon          # Wiper distruttivo (energia, Arabia Saudita)
# Malware ICS/OT
Custom PLC malware targeting Rockwell Automation (CyberAv3ngers)

Il significato strategico: un nuovo standard di conflitto ibrido

La vicenda dell’Operazione Epic Fury e della sua dimensione cyber non è semplicemente la cronaca di un conflitto mediorientale. È la dimostrazione concreta di come le operazioni cyber siano diventate componenti integrali — non accessorie — della dottrina militare degli stati autoritari. Il pre-posizionamento di APT35 nelle reti dei paesi bersaglio anni prima delle operazioni fisiche stabilisce un precedente: in futuri conflitti, qualsiasi attore statale disporrà presumibilmente di “porte di accesso” già aperte nelle infrastrutture avversarie.

Per i difensori occidentali, la lezione è chiara: la minaccia non inizia il giorno in cui i missili vengono lanciati. Inizia quando un webshell silenzioso viene installato su un server Exchange non patchato da sei mesi.

Indicazioni per i difensori

• Patch immediata dei sistemi internet-facing: Exchange, FortiOS, Cisco ASA, Log4j sono ancora vettori attivi
• Audit degli accessi amministrativi: verificare account privilegiati, in particolare su sistemi OT/ICS
• Webshell hunting: scansione proattiva per webshell su server web esposti, soprattutto su CMS e sistemi legacy
• Validazione della copertura di detection: testare le soluzioni EDR/XDR contro BellaCiao, Sagheb RAT e le tecniche di tunneling documentate
• Monitoraggio per nuova infrastruttura hacktivist: i gruppi come Handala e CyberAv3ngers si riorganizzano rapidamente dopo le operazioni

APT35 e la Cyber Guerra Parallela: come l'Iran aveva già compromesso ogni paese colpito nell'Operazione Epic Fury - (in)sicurezza digitale

Prima che i missili iraniani illuminassero il cielo di sette nazioni, i gruppi APT dell'IRGC avevano già compromesso silenziosamente le infrastrutture critiche di quei paesi.

^{Dario Fadda ((in)sicurezza digitale)}

macfranc

2026-04-14 09:10:29

1) Esempio di truffa: "Abbiamo bisogno che tu verifichi il tuo account" - Torna al primo messaggio

Qualcuno che si spaccia per un amministratore di un server Mastodon inventa una scusa per richiedere la verifica dell'account, magari sostenendo che l'utente abbia compiuto un'azione sospetta. Successivamente, fornisce un link su cui cliccare per inserire i dati della carta di credito o altre informazioni personali. Non cliccare su questo link e non fornire alcuna informazione: si tratta di una truffa.

Nessun amministratore legittimo ti chiederà mai di verificare il tuo account. Su Mastodon esiste un sistema di verifica, ma è completamente facoltativo e non prevede di cliccare su link sospetti o di fornire dati personali.

@fediverso

[SEGUE]♲ @macfranc@poliversity.it:

In queste ore si sta verificando un attacco per rubare gli account agli utenti Mastodon. Ecco cosa sapere per evitare le truffe su Mastodon e nel Fediverso con la guida di @FediTips

Il post è stato ripubblicato sul gruppo @fediverso

Come in qualsiasi altro social network, anche su Mastodon e nel più ampio Fediverso potresti imbatterti in truffatori. Ecco come individuarli e cosa fare in caso di dubbio.

1. Truffa: "Abbiamo bisogno che tu verifichi il tuo account"
2. Truffa: "Vogliamo pagarti per i post / instaurare una collaborazione / offrirti una ricompensa"
3. Truffa: "Si prega di modificare temporaneamente l'indirizzo email del proprio account"

• Cosa devo fare se vedo un post truffaldino?
• Dovrei vergognarmi se sono caduto vittima di una truffa?

NB: questa guida è una traduzione della pagina realizzata da @FediTips

[SEGUE]

How do I verify my account on Mastodon and the Fediverse? | Fedi.Tips – An Unofficial Guide to Mastodon and the Fediverse

An unofficial guide to using Mastodon and the Fediverse

^fedi.tips