(in)sicurezza digitale

2026-06-25 14:00:03

Kit AiTM contro AWS: Datadog svela una campagna di phishing che bypassa l’MFA in tempo reale

Si parla di:
Toggle

Tra il 16 e il 19 giugno 2026, i ricercatori di Datadog Security Research hanno osservato una campagna di phishing altamente sofisticata contro la console AWS. Non si tratta del classico furto di credenziali: il kit implementa tecniche adversary-in-the-middle (AiTM) che permettono di catturare i codici MFA in tempo reale, bypassando email, SMS e app di autenticazione TOTP. Un’analisi tecnica dettagliata pubblicata il 24 giugno svela l’architettura del kit, gli IoC e le tecniche di delivery utilizzate.

La campagna: tre domini in 48 ore

La campagna si è concretizzata con la registrazione di tre domini in una finestra di soli due giorni, tutti attraverso il registrar NICENIC INTERNATIONAL GROUP CO., LIMITED e ospitati su infrastruttura Cloudflare. I domini impersonavano con fedeltà la pagina di login della console AWS:

• us-west-login[.]com (registrato il 18 giugno 2026) — con sottodomini aws.us-west-login[.]com e aws-central.us-west-login[.]com
• us-east-prod[.]com (registrato il 17 giugno 2026) — con sottodominio aws.us-east-prod[.]com
• loginportal-aws[.]com (registrato il 16 giugno 2026)

In parallelo, sono stati identificati altri tre domini che impersonavano SendGrid, registrati nello stesso arco temporale attraverso lo stesso registrar. La doppia infrastruttura — AWS e SendGrid — suggerisce che gli attaccanti abbiano progettato un sistema integrato: SendGrid per la consegna delle email di phishing, i cloni AWS per la raccolta delle credenziali.

Come funziona il kit: AiTM in tempo reale

La caratteristica più pericolosa di questo kit non è la clonazione della pagina login, ma la capacità di intercettare e ritrasmettere il secondo fattore di autenticazione in tempo reale. Il flusso si articola in più fasi:

1. Validazione del target prima del rendering: quando la vittima accede alla pagina di phishing, il kit legge il parametro URL input_24 contenente un blob base64 cifrato. Il server decodifica l’indirizzo email della vittima e lo imposta come cookie. Solo se l’email è valida e registrata come target, la pagina viene effettivamente renderizzata — una misura anti-sandbox che rende inutile l’analisi automatica senza una email vittima valida.

// Logica di validazione dell'indirizzo vittima
let e = new URLSearchParams(window.location.search).get(`input_24`);
(e ? fetch(`/api/check`, {
  method: `POST`,
  body: JSON.stringify({ encrypted: e }),
  credentials: `include`
}) : Promise.resolve({ ok: !1 }))
.then(e => e.ok ? e.json() : null)
.then(() => fetch(`/api/me`, { credentials: `include` }))
.then(e => e.json())
.then(e => t(e.email || null))

2. Furto delle credenziali primarie: la pagina clonata raccoglie username e password tramite i form di login AWS (sia account root che IAM) e li invia a /api/login. Il server, agendo come proxy verso la vera console AWS, ottiene in risposta quale tipo di MFA è configurato sull’account.

3. Intercettazione dell’MFA in real-time: il kit presenta alla vittima la challenge MFA corrispondente al secondo fattore configurato — /email, /sms, o /gauth per le app TOTP. Il codice inserito viene intercettato e ritrasmesso immediatamente al server AWS legittimo, completando l’autenticazione prima che il codice scada.

Delivery: phishing mirato via SendGrid e Nimbu

Il 19 giugno 2026 è apparso su VirusTotal un batch file che funge da artefatto di validazione dell’infrastruttura. Il file contiene la struttura di un’email di phishing che impersona il supporto AWS, citando un ticket di supporto fasullo su presunto throttling della banda. La consegna avviene tramite piattaforme email legittime come SendGrid e Nimbu, scelta tattica che permette di passare i controlli SPF/DKIM/DMARC e bypassare i filtri antispam aziendali.

L’uso del parametro input_24 per la validazione dell’email suggerisce inoltre che si tratti di una campagna di spear phishing mirato piuttosto che mass phishing: ogni link contiene l’email cifrata della specifica vittima, rendendo impossibile l’accesso alla pagina di phishing senza il link personalizzato.

TTPs e mapping MITRE ATT&CK

• T1566.002 — Spearphishing Link: link personalizzati con email cifrata per targeting preciso
• T1111 — MFA Interception: cattura in real-time di email OTP, SMS e codici TOTP
• T1056.001 — Keylogging: raccolta di username, password e codici di verifica prima del forwarding
• T1583.001 — Acquire Infrastructure: Domains: tre domini registrati nello stesso arco di 48 ore
• T1133 — External Remote Services: targeting dell’accesso alla console AWS

Indicatori di compromissione (IoC)

# Domini AWS phishing
us-west-login[.]com
aws.us-west-login[.]com
aws-central.us-west-login[.]com
us-east-prod[.]com
aws.us-east-prod[.]com
loginportal-aws[.]com

# Registrar comune
NICENIC INTERNATIONAL GROUP CO., LIMITED

# Infrastruttura di hosting
Cloudflare (tutti i domini)

# Endpoint API del kit
/api/check   - validazione email vittima
/api/me      - recupero email da cookie
/api/login   - furto credenziali e identificazione MFA
/email       - challenge MFA via email
/sms         - challenge MFA via SMS
/gauth       - challenge MFA via TOTP

# Parametro URL di targeting
input_24 (blob base64 cifrato contenente email vittima)

Come rilevare l’attacco

Datadog consiglia le seguenti azioni di hunting per chi sospetti di essere stato targetizzato:

• DNS hunting: verificare la presenza nei log DNS di query verso i domini elencati negli IoC, inclusi i sottodomini
• CloudTrail monitoring: controllare eventi ConsoleLogin da IP inusuali o da località geografiche anomale, soprattutto a ridosso delle date di campagna (16-19 giugno 2026)
• Email gateway review: cercare email provenienti da SendGrid o Nimbu che contengano link con il parametro input_24 nell’URL
• Credential review: se si sospetta compromissione, revocare immediatamente le sessioni AWS attive, ruotare le credenziali e abilitare notifiche di accesso non familiare

La sofisticazione di questo kit — targeting selettivo, bypass MFA in real-time, uso di infrastrutture email legittime — lo colloca in una categoria diversa rispetto al phishing di massa. Le organizzazioni che utilizzano AWS in ambienti enterprise dovrebbero trattare questa campagna come un rischio attivo, non come una minaccia teorica.

(in)sicurezza digitale

2026-06-24 17:24:58

Skill AI malevola raggiunge 26.000 agenti: la tecnica del mutable link che inganna tutti gli scanner di sicurezza

I ricercatori di AIR hanno costruito una skill AI fasulla, l’hanno caricata su un marketplace e promossa via Instagram, e l’hanno vista raggiungere 26.000 agenti — inclusi account aziendali — senza che un singolo scanner di sicurezza la rilevasse come pericolosa. L’arma? Un link esterno modificabile dopo il superamento dei controlli.

Il problema che nessuno vuole ammettere: i marketplace di skill AI sono fondamentalmente insicuri

Nel giro di pochi mesi, le “skill” per agenti AI sono diventate il nuovo npm: pacchetti di codice che estendono le capacità degli assistenti AI, installabili con un click, fidandosi di valutazioni, stelle GitHub e reputazione open source. E come npm nel 2018, stanno diventando un vettore di attacco privilegiato.

Il team di ricerca AIR ha deciso di quantificare il problema invece di teorizzarlo. Ha costruito una skill malevola, l’ha caricata su un marketplace di agenti, e ha tracciato la sua diffusione. Il risultato è al tempo stesso prevedibile e allarmante: 26.000 agenti installanti, inclusi account riconducibili a organizzazioni aziendali, e zero rilevamenti da parte degli scanner di sicurezza testati.

La tecnica: il mutable link come cieco spot nelle pipeline di vetting

Il cuore tecnico dell’attacco è una tecnica elegante che sfrutta un’assunzione implicita nei sistemi di vetting delle skill: che il codice analizzato al momento della scansione sia lo stesso codice che verrà eseguito dopo l’installazione.

La skill creata da AIR conteneva un riferimento a un link esterno — non il payload direttamente, ma un URL che punta a un file remoto caricato al momento dell’esecuzione. Durante la fase di scansione, quel link puntava a codice benigno. Dopo che la skill aveva superato tutti i controlli e veniva distribuita agli agenti, il contenuto del link remoto poteva essere sostituito con payload arbitrari.

# Schema semplificato della tecnica mutable link
# Fase 1 - durante la scansione di sicurezza:
skill.execute() → fetch(external_link) → returns: benign_code.py → PASS
# Fase 2 - dopo approvazione e distribuzione:
skill.execute() → fetch(external_link) → returns: malicious_payload.py → EXEC
# Il contenuto di external_link è controllato dall'attaccante
# e può essere modificato in qualsiasi momento dopo il vetting

AIR ha mantenuto il payload effettivo completamente innocuo — raccogliendo solo l’indirizzo email dell’utente — per rispettare l’etica della ricerca. Ma la dimostrazione è cristallina: la stessa tecnica avrebbe potuto distribuire qualsiasi payload: infostealer, accesso remoto, exfiltration di credenziali API, manipolazione delle risposte del modello LLM.

Nessuno dei segnali di fiducia ha funzionato

Quello che rende questo esperimento particolarmente significativo non è la tecnica in sé — varianti del “mutable dependency” attack sono note nell’ecosistema npm e PyPI — ma il fatto che nessuno dei meccanismi su cui gli utenti si affidano per valutare la sicurezza di una skill abbia funzionato:

• Scanner automatici di sicurezza: tutti i tool testati da AIR hanno classificato la skill come sicura. L’analisi statica del codice non può rilevare comportamenti che dipendono da contenuto remoto mutabile.
• Stelle GitHub e reputazione open source: indicatori di popolarità, non di sicurezza. La skill aveva un repository pubblico con codice apparentemente innocuo.
• Revisione manuale del codice sorgente: la skill era tecnicamente open source — ma il punto è che il codice rilevante non è nel repository, è sul server remoto.
• Provenienza del publisher: un account creato ad hoc senza storia precedente ha comunque raggiunto 26.000 installazioni.

Il contesto: 2026 è l’anno zero della sicurezza agentica

Questa ricerca arriva in un momento di crescente preoccupazione per la sicurezza dei marketplace di skill per agenti AI. A gennaio 2026, la campagna ClawHavoc aveva sistematicamente compromesso oltre 1.184 skill nel marketplace ClawHub di OpenClaw — circa una su cinque — con infostealer che raccoglievano chiavi API LLM, chiavi SSH private, password salvate nel browser e dati di wallet crittografici.

Il pattern si ripete con caratteristiche comuni: gli attacchi sfruttano la fiducia implicita che gli utenti ripongono nei marketplace ufficiali, l’assenza di standard di sicurezza stringenti per la pubblicazione delle skill, e la difficoltà strutturale di ispezionare comportamenti dinamici con tool di analisi statica.

Il problema è aggravato dalle caratteristiche peculiari degli agenti AI rispetto ai software tradizionali. Una skill malevola installata su un agente non è solo malware che gira su un host: è codice che opera con i permessi dell’agente, ha accesso ai contesti delle conversazioni, può esfiltrare prompt e risposte, manipolare le istruzioni che l’agente riceve e potenzialmente propagarsi attraverso le funzioni di collaborazione tra agenti.

Vettore di distribuzione: Instagram come canale di diffusione

Un dettaglio operativo significativo dell’esperimento AIR è il canale di distribuzione utilizzato: oltre alla pubblicazione sul marketplace, la skill è stata promossa tramite annunci Instagram. Questo rivela come gli attori malintenzionati non si limitino ai canali tecnici per diffondere skill pericolose — le piattaforme social diventano un amplificatore efficace per raggiungere utenti che cercano funzionalità specifiche per i loro agenti.

La combinazione marketplace + social advertising è particolarmente efficace perché mima esattamente come vengono promosse le skill legittime: sviluppatori e piccoli vendor usano i social per aumentare la visibilità dei propri strumenti. Non c’è un segnale d’allarme visibile per l’utente finale.

Due righe per i difensori: cosa fare adesso

La ricerca AIR lascia i team di sicurezza con un problema concreto: come valutare la sicurezza delle skill AI installate in ambiente aziendale quando gli strumenti attuali non sono adeguati?

• Inventario delle skill installate: avere visibilità su quali skill sono attive negli agenti AI aziendali è il prerequisito minimo. Molte organizzazioni non hanno ancora questo controllo di base.
• Policy di approvazione centralizzata: analogamente ai criteri di approvazione per le estensioni browser o i plugin IDE, le skill AI dovrebbero essere soggette a un processo di vetting prima dell’uso in contesti aziendali.
• Sandbox per l’esecuzione delle skill: isolare l’esecuzione delle skill in ambienti sandboxed può limitare il raggio d’azione di una skill compromessa, impedendole di accedere a credenziali, file system o rete aziendale.
• Monitoraggio delle connessioni in uscita: le skill che stabiliscono connessioni HTTP verso URL esterni non strettamente necessari alla loro funzione dichiarata dovrebbero generare alert nel sistema di monitoraggio.
• Diffidare del dynamic loading: skill che caricano codice da URL remoti dovrebbero essere trattate con la stessa cautela con cui si trattano i loader malware nel contesto tradizionale.

Il nodo irrisolto: chi è responsabile della sicurezza dei marketplace?

La ricerca AIR apre una questione di governance che l’industria non ha ancora risolto: chi è responsabile della sicurezza in un marketplace di skill AI? I marketplace stessi hanno incentivi a crescere rapidamente e a ridurre le frizioni per i publisher. I vendor di agenti AI scaricano spesso la responsabilità sugli utenti finali. I publisher di skill, se malintenzionati, ovviamente non si auto-regolano.

Il risultato è un ecosistema in cui 26.000 agenti — inclusi probabilmente molti in contesti aziendali — possono essere raggiunti da codice arbitrario, e nessuno ha strumenti adeguati per rilevarlo prima che accada. Un problema familiare a chiunque abbia vissuto l’evoluzione della sicurezza dell’ecosistema npm o PyPI — con la differenza che gli agenti AI operano con privilegi e accessi molto più estesi di una libreria Node.js.

(in)sicurezza digitale

2026-06-23 13:55:01

VBScript via WhatsApp: documenti aziendali falsi installano ManageEngine RMM in campagna globale con tracce cinesi

Si parla di:
Toggle

Kaspersky ha documentato una campagna malware attiva in 11 Paesi che utilizza WhatsApp come vettore di distribuzione iniziale. Allegati VBScript pesantemente offuscati, camuffati da documenti aziendali, avviano una catena di infezione multi-stadio che termina con l’installazione silenziosa di ManageEngine Endpoint Central — un software RMM legittimo riconfigurato per dare agli attaccanti accesso remoto persistente. L’infrastruttura mostra sovrapposizioni con campagne Gh0st RAT e ValleyRAT, suggerendo con bassa confidenza un operatore di lingua cinese.

WhatsApp come vettore: la scelta tattica

La scelta di WhatsApp come canale di distribuzione è tutt’altro che casuale. A differenza della posta elettronica, WhatsApp non dispone di gateway di sicurezza aziendali, filtri antimalware inline, o sandbox automatici per gli allegati. I file vengono recapitati direttamente al dispositivo della vittima, bypassando la maggior parte delle difese perimetrali tradizionali. Inoltre, i messaggi arrivano da account WhatsApp precedentemente compromessi — non da numeri sconosciuti — il che aumenta notevolmente la probabilità che la vittima apra l’allegato, fidandosi del mittente apparente.

I file vengono distribuiti come archivi ZIP con nomi volutamente credibili in più lingue: “Financial Reports.vbs”, “Account Statement.vbs”, ma anche varianti in portoghese, francese, tedesco e malese, a riflettere la portata geografica dell’operazione.

La catena di infezione: quattro stadi verso il controllo remoto

Una volta che la vittima apre il file VBScript su Windows, si attiva una sequenza di infezione articolata in quattro fasi.

Stage 1 — VBScript offuscato: il file VBS è pesantemente offuscato per eludere il rilevamento statico. All’esecuzione, contatta l’infrastruttura dell’attaccante e scarica due script aggiuntivi.

Stage 2 — UAC bypass: uno degli script scaricati disabilita le protezioni User Account Control (UAC) attraverso modifiche al registro di sistema di Windows, eliminando i prompt di sicurezza per le operazioni successive.

Stage 3 — Download del payload: viene scaricato un archivio ZIP contenente un deployment preconfigurato di ManageEngine Endpoint Central, comprensivo di installer MSI (UEMSAgent.msi), certificati, file di configurazione e script di installazione.

Stage 4 — Installazione silenziosa: il launcher setup1.vbs esegue l’installazione silenziosa dell’agente tramite msiexec.exe. L’agente viene registrato sull’infrastruttura di controllo dell’attaccante, fornendo accesso remoto completo al sistema della vittima: esecuzione di comandi, trasferimento file, accesso alla shell, e molto altro.

--- CATENA DI INFEZIONE ---

[WhatsApp] → ZIP archive
    └── Financial_Reports.vbs (offuscato)
          ├── Stage 2: Download script → UAC bypass via Registry
          │     HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
          │     ConsentPromptBehaviorAdmin = 0 / EnableLUA = 0
          └── Stage 3: Download ZIP (ManageEngine Endpoint Central)
                └── UEMSAgent.msi
                └── setup1.vbs → msiexec.exe /quiet /norestart
                └── Certificati e config preconfigurati
                      └── Registrazione su C2 attaccante

L’abuso degli strumenti RMM legittimi: una tecnica consolidata

L’utilizzo di ManageEngine Endpoint Central come payload finale è una scelta deliberata e strategica. I software RMM legittimi come ManageEngine, AnyDesk, TeamViewer o Atera presentano vantaggi significativi per gli attaccanti: sono firmati digitalmente da vendor riconosciuti, vengono spesso esclusi dalle soluzioni antimalware per evitare falsi positivi operativi, sono difficilmente distinguibili da usi legittimi in ambienti enterprise, e forniscono funzionalità complete di gestione remota. La CISA americana ha già avvertito in passato dell’abuso di strumenti RMM da parte di attori state-sponsored e cybercriminali.

Attribuzione: tracce verso la Cina, confidenza bassa

I ricercatori di Kaspersky hanno identificato sovrapposizioni infrastrutturali con campagne precedenti attribuite a ValleyRAT e Gh0st RAT, due famiglie di malware storicamente associate ad attori di lingua cinese. In particolare, l’indirizzo IP 202.61.160.201 è apparso sia nell’infrastruttura di questa campagna sia in precedenti operazioni Gh0st RAT/ValleyRAT. Nonostante queste sovrapposizioni, Kaspersky mantiene una bassa confidenza nell’attribuzione, in quanto la riutilizzazione di infrastruttura non implica necessariamente la stessa organizzazione — una tecnica che alcune operazioni usano deliberatamente per depistare le attribuzioni.

Distribuzione geografica: Malaysia epicentro, portata globale

Le vittime osservate sono distribuite in 11 Paesi e territori: Malaysia (circa l’80% dei casi), Brasile, India, Messico, Singapore, Regno Unito, Spagna, Taiwan, Australia, Russia e Vietnam. La concentrazione in Malaysia suggerisce che questa possa essere la regione target primaria, con gli altri Paesi colpiti da una distribuzione più opportunistica o da campagne parallele adattate linguisticamente.

Due righe per i difensori

Per mitigare questa minaccia è necessario agire su più livelli. A livello di endpoint, occorre bloccare l’esecuzione di file .VBS, .VBE, .JS e .WSF da parte di utenti non amministratori tramite Group Policy (Software Restriction Policies o AppLocker). È altresì importante monitorare le modifiche alle chiavi di registro relative a UAC (ConsentPromptBehaviorAdmin, EnableLUA) come segnale di compromissione. Sul fronte delle applicazioni, è necessario implementare una whitelist dei software RMM autorizzati e bloccare l’installazione silenziosa di agenti non approvati tramite msiexec. Gli utenti, infine, vanno sensibilizzati a non aprire allegati ricevuti via WhatsApp — specialmente file .ZIP con estensioni .VBS — anche quando provengono da contatti noti, poiché gli account WhatsApp dei mittenti potrebbero essere compromessi.

--- INDICATORI DI COMPROMISSIONE (IoC) ---

IP infrastruttura:
  202.61.160.201  (overlap con Gh0st RAT / ValleyRAT)

File sospetti:
  Financial Reports.vbs
  Account Statement.vbs
  setup1.vbs
  UEMSAgent.msi  (ManageEngine Endpoint Central preconfigurato)

Chiavi di registro modificate (UAC bypass):
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Processo sospetto:
  msiexec.exe /quiet /norestart [lanciato da VBScript]

Paesi colpiti: Malaysia (80%), Brasile, India, Messico, Singapore,
               UK, Spagna, Taiwan, Australia, Russia, Vietnam

Fonte: Kaspersky Securelist, giugno 2026

(in)sicurezza digitale

2026-06-22 16:57:54

AryStinger: la botnet che trasforma router D-Link in armi silenziose per attacchi globali

I ricercatori di XLab (Qianxin) hanno scoperto AryStinger, una botnet precedentemente sconosciuta che ha compromesso oltre 4.000 router obsoleti in tutto il mondo, trasformandoli in proxy silenziosi al servizio di attori malevoli. A differenza delle classiche botnet DDoS, AryStinger è progettata per il ricognizione e il supporto alle intrusioni — un’infrastruttura invisibile concepita per penetrare reti aziendali e governative.

Scoperta e timeline dell’operazione

Il 12 marzo 2026, il sistema di threat awareness di XLab ha rilevato l’indirizzo IP 107.150.106.14 che diffondeva un campione ELF con zero detection su VirusTotal, sfruttando due vulnerabilità datate: CVE-2013-3307 e CVE-2016-5681. Il campione, implementato in C, prendeva di mira router D-Link DIR-850L e DIR-818LW — dispositivi giunti a fine vita, privi di patch e ancora ampiamente diffusi in ambito SOHO.

Il 26 aprile è comparso un secondo campione correlato, questa volta scritto in Go e rivolto a dispositivi NAS, sfruttando CVE-2025-11837. Il percorso nel codice sorgente del campione Go rivela il nome del progetto interno: Ary-Attack — un dettaglio che ha consentito ai ricercatori di attribuire le due famiglie alla stessa operazione.

Architettura e capacità operative

AryStinger converte i dispositivi infetti in “executor” telecomandati, capaci di eseguire un insieme ricco di operazioni su richiesta del C2:

• Scansione di rete: port scanning, identificazione dei servizi, enumerazione di sottodomini — attività tipiche della fase di ricognizione pre-intrusione.
• Proxying e tunneling: il device infetto instrada traffico malevolo verso destinazioni terze, mascherando l’origine reale dell’attaccante.
• Esecuzione di comandi arbitrari sul sistema.
• Modifiche DNS: la botnet può alterare le configurazioni DNS del router per intercettare il traffico web degli utenti connessi.
• Payload multi-linguaggio: supporta l’iniezione di payload scritti in Go, Java e Python, garantendo flessibilità operativa.
• Canali di accesso persistente via dropbear (SSH) o gs-netcat.

Le comunicazioni con il server di comando e controllo avvengono via HTTP/HTTPS, con traffico serializzato tramite Protobuf e cifrato con XOR — una scelta che garantisce compattezza e una certa difficoltà nell’ispezione del traffico.

Distribuzione geografica e target

La telemetria di Qianxin mostra che la distribuzione delle infezioni è geograficamente concentrata: Corea del Sud (48,5%), Cina (31,8%), Svezia (6,4%), Malesia (3,5%) e Singapore (2,5%). La forte prevalenza asiatica suggerisce che il deployment iniziale sia stato mirato su mercati dove i router D-Link di fascia bassa hanno avuto larga diffusione e dove la sostituzione dei dispositivi a fine vita avviene con ritardi.

Il targeting di NAS oltre ai router nella seconda fase dell’operazione indica un’evoluzione verso dispositivi con maggiore capacità di elaborazione e connettività persistente — ideali per operazioni di lunga durata che richiedono stabilità dell’infrastruttura proxy.

Perché AryStinger è diversa dalle botnet tradizionali

La distinzione fondamentale di AryStinger rispetto a botnet come Mirai o AISURU è l’obiettivo operativo: non DDoS né mining di criptovalute, bensì la costruzione di un’infrastruttura di intrusione distribuita. I dispositivi compromessi diventano nodi di una rete di proxy residenziali che conferiscono agli attaccanti un’anonimizzazione difficile da penetrare: il traffico malevolo emerge da indirizzi IP domestici o di piccola impresa, superando spesso i blocchi basati su reputazione IP.

Questo modello operativo è tipico di gruppi APT che necessitano di infrastrutture di staging durante la fase di ricognizione e di pivoting nelle reti bersaglio. La capacità di modificare le configurazioni DNS aggiunge una dimensione ulteriore: chi usa un router infetto espone tutte le proprie comunicazioni a potenziale intercettazione.

Indicatori di compromissione (IoC)

# IP di spreading iniziale
107.150.106.14
# Dominio C2 autenticazione
eixfi.ajb8.com  (/auth endpoint)
# CVE sfruttate
CVE-2013-3307   (D-Link DIR-850L - autenticazione bypassata)
CVE-2016-5681   (D-Link DIR-818LW - esecuzione remota di codice)
CVE-2025-11837  (dispositivi NAS - variante Go)
# Processi sospetti da verificare sul dispositivo
syswapd0h
syswapd0w
# Percorso da verificare
/tmp/bin/  (presenza di campioni malware)
# Nome progetto interno (da path nel codice Go)
Ary-Attack

Due righe per i difensori

Per chi gestisce reti con dispositivi edge, le azioni prioritarie sono: sostituire immediatamente i router D-Link DIR-850L e DIR-818LW con modelli supportati e aggiornati; applicare gli aggiornamenti firmware più recenti su tutti i dispositivi di rete perimetrali; modificare le credenziali amministrative di default; disabilitare le interfacce di gestione remota se non strettamente necessarie. A livello di monitoraggio, è opportuno inserire il dominio eixfi.ajb8.com e l’IP 107.150.106.14 nelle blocklist e verificare nei log di rete la presenza di connessioni Protobuf verso host sconosciuti su porte non standard.

La scoperta di AryStinger conferma una tendenza consolidata: i dispositivi IoT e i router SOHO a fine vita restano un vettore di attacco privilegiato per costruire infrastrutture di intrusione persistenti e difficili da attribuire. La prossima botnet potrebbe già essere nascosta nel router del vostro operatore ISP locale.

(in)sicurezza digitale

2026-06-19 12:06:52

Operation Endgame abbatte SocGholish: 100 server offline e 15.000 siti risanati nell’operazione contro Evil Corp

Il 18 giugno 2026, un’operazione congiunta di forze dell’ordine internazionali ha sferrato un colpo devastante contro TA569, il gruppo cybercriminale noto per la distribuzione del malware SocGholish. L’Operazione Endgame ha abbattuto oltre 100 server e domini, sanificato quasi 15.000 siti web compromessi in tutto il mondo e — soprattutto — ha colpito un’infrastruttura criminale che per anni ha aperto le porte a ransomware come LockBit, WastedLocker e RansomHub.

Chi è TA569 e perché importa

Proofpoint segue TA569 dal 2018, anno in cui il gruppo ha iniziato a dominare la scena dei web inject, ovvero l’iniezione di codice malevolo in siti web legittimi per reindirizzare i visitatori verso payload pericolosi. Il modus operandi è ormai tristemente noto: la vittima visita un sito compromesso e si trova davanti a un pop-up che imita fedelmente una notifica del browser, chiedendole di aggiornare Chrome o Edge. Un clic sul pulsante di aggiornamento avvia il download di GhoLoader, il payload di primo stadio che — in ambienti Active Directory — può rapidamente evolvere in un attacco ransomware devastante.

Il gruppo è stato associato da più ricercatori a Evil Corp, il famigerato sodalizio cybercriminale russo i cui membri sono stati sanzionati più volte da governi occidentali (USA, UK, Australia). Il collegamento non è formale ma è suffragato da sovrapposizioni infrastrutturali, utilizzo degli stessi strumenti e partnership operative. I ransomware distribuiti attraverso la catena SocGholish includono WastedLocker (firmato Evil Corp), LockBit e — più recentemente — RansomHub.

L’architettura di SocGholish: TDS, fake plugin e proxy inverso

La catena di attacco di TA569 si articola in tre componenti distinte. Prima di tutto, il web inject: il gruppo compromette siti WordPress attraverso password spraying, credenziali riutilizzate, vulnerabilità in plugin abbandonati o zero-day in componenti CMS. Una volta dentro, installa plugin falsi che si nascondono dall’interfaccia di amministrazione e iniettano JavaScript offuscato nelle risposte HTTP del sito, che funge da proxy inverso verso l’infrastruttura TA569.

Il secondo componente è il Traffic Distribution System (TDS): TA569 utilizza sia ParrotTDS (di proprietà del gruppo) sia il servizio Keitaro gestito da TA2726, un altro threat actor. Il TDS filtra il traffico in base a paese, browser, sistema operativo e comportamento dell’utente prima di decidere quale payload consegnare. Questa variabilità rende la documentazione degli attacchi particolarmente complessa: lo stesso sito compromesso può consegnare SocGholish a un utente Windows negli USA, FrigidStealer a un Mac in Gran Bretagna, o nulla a un sistema di sicurezza automatizzato.

Il terzo componente è GhoLoader: quando la vittima supera tutti i controlli anti-bot e clicca sul pulsante di aggiornamento, un iframe nascosto caricato da un URI data: recupera lo script malevolo dal C2, costruisce il file client-side tramite URL.createObjectURL() e innesca il download. Il file scaricato (Google Launcher.js) è in realtà GhoLoader Stage 1 — uno script WSH JScript che comunica con il C2 tramite ActiveXObject('MSXML2.XMLHTTP'). Questa tecnica aggira i sandbox che si limitano a simulare un click sul pulsante, senza gestire la comunicazione cross-frame tramite postMessage.

Operation Endgame: la risposta internazionale

Il 18 giugno 2026, autorità di quattro paesi — Paesi Bassi (NHCTU), Canada (RCMP), Stati Uniti (FBI) e Germania (BKA), con il supporto di Europol — hanno eseguito un’azione coordinata contro l’infrastruttura di TA569. I risultati, comunicati ufficialmente dalla polizia olandese, sono notevoli:

• Oltre 100 server e domini abbattuti a livello globale
• 14.971 siti web compromessi identificati e risanati
• Video di denuncia pubblica pubblicato sul sito di Operation Endgame
• Proofpoint ha fornito intelligence tecnica alle autorità per supportare l’operazione

Non si tratta del primo capitolo di Operation Endgame: nel 2024 la stessa operazione aveva colpito loader come IcedID, Smokeloader e SystemHeuristicZ. Il fatto che TA569 sia ora nel mirino delle forze dell’ordine segna un’escalation significativa, dato che SocGholish è stato il vettore di distribuzione per alcune delle campagne ransomware più dannose degli ultimi anni.

Impatto e ripercussioni nell’ecosistema dei web inject

TA569 è stato il capostipite dei web inject malevoli, ma nel tempo ha ispirato un ecosistema di imitatori: ClearFake, ZPHP, ErrTraffic, LandUpdate808 (noto anche come KongTuke) e altri attori monitorati da Proofpoint continuano ad operare in modo indipendente. L’operazione di law enforcement colpirà direttamente TA569 ma non eliminerà il problema alla radice: TA2726, il fornitore TDS che serve anche altri threat actor, non sembra direttamente coinvolto nell’azione.

Proofpoint stima che l’operazione causerà interruzioni operative significative per TA569, incluse perdite finanziarie, danni reputazionali nei circuiti criminali e perdita di clienti ransomware. Tuttavia, come accaduto dopo precedenti disruption (LockBit, ALPHV), è probabile che parte del traffico di web inject migri verso altri attori già attivi.

Indicatori di Compromissione (IoC)

# Domini C2 TA569 osservati (maggio-giugno 2026)
platform[.]exathomeswebuyarizona[.]com   # Delivery SocGholish Stage 1
js-new[.]newtoyoygame[.]com             # C2 GhoLoader Stage 1
# File osservati
Google Launcher.js                       # GhoLoader Stage 1 (WSH JScript)
# Tecnica di delivery
blob:    # URL createObjectURL() per delivery senza traccia di rete
data:    # iframe nascosto per comunicazione cross-frame
# Threat actors correlati
TA569   # Evil Corp-linked, SocGholish operator
TA2726  # Keitaro TDS provider (continua a operare)
ParrotTDS  # TDS di proprietà TA569

Due righe per i difensori

Per i team di sicurezza, la mitigazione richiede un approccio stratificato. Sul fronte della difesa di rete, è consigliabile adottare il ruleset Emerging Threats e implementare protezioni endpoint capaci di rilevare l’esecuzione di script WSH/JScript. Gli utenti vanno formati a riconoscere i falsi aggiornamenti del browser — un pattern che non cambierà anche se TA569 verrà completamente smantellato, perché i copycats lo perpetueranno.

Per gli amministratori WordPress, le autorità hanno pubblicato linee guida specifiche: abilitare MFA sull’account amministratore, restringere l’accesso a /wp-admin tramite IP allowlisting, bloccare l’esecuzione di PHP nella directory uploads, mantenere aggiornati core, plugin e temi e monitorare l’integrità dei file con strumenti dedicati. Particolarmente importante è verificare la presenza di plugin sconosciuti o nascosti a livello di filesystem, che potrebbero sfuggire all’interfaccia di amministrazione.

(in)sicurezza digitale

2026-06-19 12:03:56

LLMjacking si evolve: server Ollama esposti diventano il cervello di uno strumento di hacking autonomo, catturato in sviluppo da Sysdig

Si parla di:
Toggle

Il 12 giugno 2026, il Sysdig Threat Research Team (TRT) ha osservato qualcosa che i ricercatori di sicurezza prevedevano da almeno due anni: un threat actor che utilizzava un server AI accessibile su internet come cervello di uno strumento di hacking completamente automatizzato. Non si trattava di un esperimento accademico né di una proof-of-concept: il framework, denominato VAPT, era in sviluppo attivo, con stadi aggiornati in tempo reale, e operava contro ambienti benchmark privati usando capacità di inferenza sottratte tramite un server Ollama esposto senza autenticazione.

Dal furto di compute all’arma autonoma: l’evoluzione del LLMjacking

Il termine LLMjacking è stato coniato da Sysdig nel maggio 2024 per descrivere il pattern in cui attori malevoli utilizzano credenziali cloud sottratte per accedere a servizi AI a pagamento — OpenAI, Anthropic, Google Gemini — scaricando le spese sulla vittima, con costi potenziali fino a 46.000 dollari al giorno. Entro il 2025, questa pratica si era industrializzata in un mercato nero con infrastruttura di reverse-proxy che intermediava miliardi di token rubati.

Con la proliferazione di server AI auto-ospitati, la superficie di attacco si è spostata. Ollama, il popolare tool per servire modelli LLM in locale, ascolta sulla porta 11434 senza autenticazione per impostazione predefinita. Ricercatori indipendenti hanno catalogato circa 175.000 istanze Ollama pubblicamente esposte in più di 130 paesi, una superficie enorme di compute non protetto e non fatturato. Ciò che Sysdig TRT ha osservato a giugno 2026 è il passo successivo: non il furto di compute per rivenderlo, ma il suo utilizzo come motore ragionante per offensive tooling autonomo.

Il threat actor e le sessioni osservate

La prima sessione osservata dal Sysdig TRT ha avuto origine dall’IP 122.183.48.82, registrato a un provider residenziale/small-business di Hyderabad, India. La sessione è iniziata alle 15:43 UTC del 12 giugno 2026 e si è protratta per circa otto ore e mezza. Due giorni dopo, il 14 giugno, lo stesso tool è tornato operativo da tre IP aggiuntivi: 122.183.48.35, 122.183.48.195 (stessa rete del primo) e 47.15.69.15, tutti riconducibili a connessioni residenziali indiane.

Sysdig attribuisce tutte le sessioni allo stesso operatore per tre ragioni convergenti: identica pipeline VAPT, identici target benchmark privati, e comune origine geografica indiana. La rotazione tra ISP è la normale variazione di una connessione residenziale, non il segnale di operatori multipli indipendenti.

Architettura del framework VAPT: il modello AI come decision engine

Ciò che rende questa campagna eccezionale dal punto di vista dell’analisi è la visibilità completa ottenuta da Sysdig. Poiché il framework invia le proprie istruzioni complete al modello a ogni richiesta, il team ha potuto catturare l’architettura integrale: ogni stadio della pipeline logica, la struttura imposta agli output del modello, e la firma usata per confermare una compromissione.

Il framework VAPT opera come una pipeline sequenziale di stadi specializzati, ciascuno con un ruolo preciso:

• Service fingerprinting: normalizza i banner dei servizi di rete in un’identità software precisa per la ricerca CVE.
• Vulnerability matching e triage: incrocia prodotto e versione con le vulnerabilità note, filtrando quelle applicabili.
• Web reconnaissance: analizza testo della pagina, header, cookie, form field e path scoperti per costruire un profilo di attacco.
• Proof-of-concept synthesis: costruisce PoC per validare singole vulnerabilità, inclusi payload protocol-aware.
• Blind SQL injection crafting: costruisce payload time-based con logica di filter-evasion.
• Credential e secret extraction: analizza file di sistema compromessi alla ricerca di credenziali riusabili.
• Arbitrary file-read planning: data una primitiva di lettura file, pianifica quali file recuperare.
• Privilege escalation: decide il passo successivo per l’escalation dei privilegi.
• Autonomous orchestration: controller che guida l’intera catena fino al raggiungimento di command execution.

L’orchestratore autonomo: il codice catturato

Lo stadio di orchestrazione è il più rivelatore dell’intento del tool. L’istruzione inviata al modello specifica un agente di web-exploitation “autorizzato” che deve raggiungere la command execution sul target. Una volta confermata l’RCE tramite il pattern echo VAPTb3gin; id; echo VAPTfin, il tool congela la richiesta riuscita sostituendo il comando con il placeholder __VAPTCMD__, trasformando il singolo exploit in una ricetta riutilizzabile con qualsiasi comando.

Una variante dell’orchestratore rivela un ulteriore dettaglio architetturale: il modello opera in modalità “PROPOSE-ONLY”, mentre un verificatore deterministico separato (oracles.py) decide se un payload ha effettivamente avuto successo. Questa separazione tra componente AI (proposta) e componente deterministica (verifica) è il design pattern di software mantenuto professionalmente, non di uno script improvvisato.

Il tool era in sviluppo attivo

Uno degli aspetti più significativi della campagna è la prova che il tool era in sviluppo iterativo durante le sessioni osservate. Nella sessione dell’8 ore del 12 giugno, il set di stadi è cresciuto nel corso della giornata: service fingerprinting, vulnerability triage, blind SQL injection, PoC synthesis e orchestratore autonomo sono apparsi dopo circa tre ore. Credential extractor e file-read planner sono stati aggiunti in serata, gli stadi per il database SQL triage nelle ultime novanta minuti. Singoli stadi sono stati riscritti in-place più volte — la fase di web-reconnaissance ha attraversato tre versioni distinte.

Quando il tool è tornato il 14 giugno, il set completo di stadi — inclusi quelli apparsi solo nelle fasi finali della sessione precedente — era presente fin dalle prime richieste. Il threat actor aveva integrato ogni aggiunta nel codice baseline prima del run successivo. Sysdig descrive questo come un vantaggio di osservazione straordinariamente precoce: il tool è stato catturato prima di essere diretto contro vittime reali.

I modelli richiesti: agnosticismo del backend

Un dettaglio tecnico rivelatore è l’elenco dei modelli richiesti dal tool al server Ollama: gpt-4o-mini (OpenAI), claude-3-5-sonnet (Anthropic), gemini-2.0-flash-exp (Google), mistral:7b, deepseek-r1:8b, qwen3.5:4b, e una versione “abliterated” (con guardrail rimossi) di Llama-3.3-70B. I tre modelli commerciali non sono compatibili con Ollama: la loro presenza mostra che il tool è backend-agnostico e l’operatore aveva semplicemente reindirizzato il backend verso il server Ollama gratuito in sostituzione di un API key a pagamento. Il server esposto era un drop-in sostituto per l’inferenza a tariffazione.

Due righe per i difensori

Sysdig identifica un blind spot difensivo fondamentale: il rilevamento che monitora i log del proprio server modello presuppone che l’operatore possieda e monitori quel server. Un server esposto scoperto da un attore esterno è, per definizione, uno che il proprietario non sta osservando. I proprietari vedranno compute elevato e una porta aperta, non una pipeline di attacco multi-stadio.

Indicatori di Compromissione

# IP sorgente osservati
122.183.48.82    # Hyderabad, India - sessione 12 giugno
122.183.48.35    # Hyderabad, India - sessione 14 giugno
122.183.48.195   # Hyderabad, India - sessione 14 giugno
47.15.69.15      # India, secondo ISP - sessione 14 giugno

# Marker di compromissione (RCE oracle)
echo VAPTb3gin; id; echo VAPTfin

# Marker nel payload
VAPTb3gin        # Sentinel di apertura
VAPTfin          # Sentinel di chiusura
__VAPTCMD__      # Placeholder per replay exploit

# Target fittizi del benchmark
MediaVault Asset Portal
Reverb Studio

# Range di rete target
172.30.0.0/24    # Range benchmark privato
10.129.0.0/16    # Range HackTheBox lab VPN

# Porta esposta
11434            # Porta default Ollama (no auth)

# Pattern di detection (Falco)
richieste HTTP su porta 11434 con contenuto
matching /VAPTb3gin|VAPTfin|VAPTCMD/

Raccomandazioni operative

• Isolare i server modello dalla rete pubblica: Ollama e sistemi simili devono essere esposti solo su localhost o su interfacce interne, mai su internet. La porta 11434 non deve essere raggiungibile dall’esterno.
• Aggiungere autenticazione a livello di proxy: Ollama non implementa autenticazione nativa; deve essere aggiunta tramite un reverse proxy autenticante.
• Monitorare il volume di inferenza: picchi anomali di compute sul server AI sono un indicatore primario di abuso esterno.
• Cercare i marker VAPT nei log: scansionare i log delle applicazioni web per le stringhe VAPTb3gin, VAPTfin e __VAPTCMD__ — la loro presenza indica che un sistema è stato attaccato da questo framework o da varianti.
• Scansione proattiva dei propri asset: verificare internamente la presenza di server Ollama o altri inference endpoint esposti su internet con la stessa metodologia usata da un attaccante.

Fonte: Sysdig Threat Research Team, Michael Clark (Director of Threat Research). Research pubblicato il 17 giugno 2026. Full report: sysdig.com/blog/llmjacking-evolved

LLMjacking evolved: Attackers are using stolen AI compute to build offensive agentic tools | Sysdig

Sysdig TRT caught a threat actor using a stolen Ollama server to power an autonomous, multi-stage offensive hacking tool — live, in development, and in full detail.

^{Michael Clark (Sysdig)}

(in)sicurezza digitale

2026-06-18 13:52:11

ClickFix si evolve: BabaDeda, Lorem Ipsum Loader e Potemkin portano ransomware e RAT con architetture modulari anti-detection

Si parla di:
Toggle

Tre ricerche indipendenti pubblicate lo stesso giorno — da Morphisec, BlueVoyant e Huntress — documentano come la tecnica ClickFix stia evolvendo da vettore opportunistico a framework di delivery modulare di prima scelta per attori sia criminali che ransomware. I nuovi loader BabaDeda, Lorem Ipsum e Potemkin mostrano un ecosistema in rapida professionalizzazione, dove la separazione dei componenti (delivery, storage, esecuzione, payload) rende il rilevamento progressivamente più difficile.

Cos’è ClickFix e perché funziona ancora

ClickFix è una tecnica di social engineering che convince la vittima a incollare manualmente comandi PowerShell malevoli nella propria macchina, tipicamente presentando un falso errore di sistema, una verifica CAPTCHA contraffatta o un avviso di aggiornamento browser. L’efficacia deriva dall’eludere i meccanismi di difesa che bloccano l’esecuzione automatica di codice: poiché è l’utente a eseguire il comando, molti endpoint security tools non lo intercettano come attività sospetta iniziale. La tecnica è attiva almeno dal 2024 e continua a essere sfruttata perché il fattore umano rimane il vettore più affidabile.

BabaDeda Loader: dal crypto al settore finanziario e dell’istruzione

Morphisec documenta la nuova iterazione del BabaDeda Loader, crypter service già documentato nel 2021 in campagne contro il settore crypto/Web3. Le campagne di aprile 2026 segnano un’espansione verso organizzazioni finanziarie e dell’istruzione, con un’architettura significativamente più sofisticata rispetto ai precedenti installer trojanizzati.

La catena di attacco parte da un lure ClickFix che induce l’esecuzione di un comando PowerShell. Il loader risultante combina diverse tecniche di evasione:

• DLL side-loading in processi Windows fidati come svchost.exe
• Shellcode in-memory: il payload non tocca disco nella forma finale
• Storage Crypter: le componenti malevole sono nascoste in file container dall’aspetto legittimo (es. List.Control.dat), decodificate solo al momento dell’esecuzione
• Profiling dell’host con skip automatico su sistemi con locale russo o bielorusso — indicatore tipico di attori di lingua russa
• Controlli su prodotti di sicurezza installati prima del recupero del payload finale

I payload distribuiti includono un backdoor .NET con capacità di esfiltrazione dati (cookie, credenziali browser, cronologia, chiavi di cifratura DPAPI, contenuto file), oltre a DanaBot e SectopRAT (aka ArechClient) via DLL side-loading in una seconda catena parallela.

Lorem Ipsum Loader e Vanilla Tempest: ClickFix come accesso iniziale per ransomware

BlueVoyant documenta una campagna attiva che utilizza almeno cinque siti WordPress compromessi — nei settori architettura, servizi legali e tecnologia edilizia — come punto di partenza per distribuire il Lorem Ipsum Loader, attivo in the wild dal febbraio 2026. L’elemento più rilevante è l’attribuzione con alta confidenza a Vanilla Tempest (alias Rapid Brigantine, Vice Society, Vice Spider): un attore finanziariamente motivato con un track record documentato nel deployment di ransomware Rhysida, BlackCat, Zeppelin e Quantum Locker.

Il cambio di delivery mechanism rispetto alle campagne precedenti — da installer Microsoft Teams trojanizzati via SEO poisoning a ClickFix su WordPress compromessi — è direttamente riconducibile all’intervento di Microsoft contro Fox Tempest (Forging Marauder): la disruption del servizio MSaaS (Malware-Signing-as-a-Service) che forniva certificati Microsoft Trusted Signing fraudolenti ha reso non viable il modello precedente. In risposta, gli operatori hanno abbandonato il code signing adottando ClickFix, che elimina la dipendenza dalla firma del codice.

La catena tecnica: un lure ClickFix per un falso aggiornamento Edge esegue un comando che scarica un archivio ZIP contenente una versione obsoleta di Node.js (v7.10.1, del 2017) per eseguire payload JavaScript. Lo script JS fa da dropper per un batch script che imposta persistenza tramite una catena di DLL side-loading (mscoree.dll o msvcp140.dll), che a sua volta carica il Lorem Ipsum Loader. Il Loader recupera il Lorem Ipsum Backdoor da profili attaccante su social network. La catena termina con il handoff agli strumenti post-exploitation di Rapid Brigantine e al deployment di Rhysida ransomware.

Potemkin Loader: DGA, EtherRAT e controllo remoto del dominio

Huntress descrive la terza campagna, rilevata il mese scorso, che installa un pacchetto MSI che tramite un payload HTA (HTML Application) rilascia Potemkin, un loader x64 custom precedentemente non documentato. Le caratteristiche distintive:

• Domain Generation Algorithm basato su un dizionario di 1.000 parole integrato per il discovery C2 — rendere difficile il sinkholing
• Identificazione vittima via UUID univoco scritto in %LOCALAPPDATA%\hyper-v.ver
• Cifratura custom per comunicazioni C2 e protezione del dizionario DGA
• Caricamento in-memory (reflective loading) dei moduli follow-on

Potemkin installa EtherRAT e RMMProject, un DLL scriptabile in Lua con moduli per controllo remoto dello schermo e furto credenziali browser tramite bypass di Chromium App-Bound Encryption (ABE). Dopo aver stabilito l’accesso, l’attore non identificato ha condotto attività hands-on-keyboard: configurazione esclusioni Microsoft Defender, deploy di tunnel SOCKS reverse con Chisel, ricognizione, tunnel Cloudflare per accesso persistente, e movimento laterale via WMIExec e SMBExec verso il domain controller, propagando EtherRAT su oltre 11 host.

Il pattern comune: modularità come strategia difensiva per gli attaccanti

Le tre campagne documentano una tendenza strutturale: i moderni loader framework separano delivery, storage, esecuzione e payload deployment in componenti distinti piuttosto che affidarsi a un’entità monolitica. Questa architettura a strati riduce la visibilità forense, complica l’analisi automatizzata e diminuisce le finestre temporali in cui i tool di sicurezza tradizionali possono intercettare l’attività malevola prima dell’esecuzione. La risposta alla disruption di Fox Tempest da parte di Vanilla Tempest — pivot verso ClickFix in pochi giorni — dimostra anche la resilienza operativa di questi ecosistemi: la perdita di un componente della supply chain non blocca l’operazione, la ridiritta.

Due righe per i difensori

Le tre campagne hanno un punto di contatto comune: la vittima esegue manualmente il codice iniziale. I controlli preventivi più efficaci sono: politiche di esecuzione PowerShell restrictive (Constrained Language Mode, logging completo di script block e moduli), blocco dei siti WordPress compromessi via web filtering, detection di child processes sospetti avviati da browser (Edge, Chrome), monitoraggio di DLL side-loading in path inusuali, e alert su Node.js version obsolete eseguite da utenti non amministratori. Per Potemkin specificamente, il file %LOCALAPPDATA%\hyper-v.ver è un IoC host-based rilevabile.

# IoC host-based Potemkin
%LOCALAPPDATA%\hyper-v.ver   # file UUID vittima

# Tecniche MITRE ATT&CK rilevanti
T1204.002  - User Execution: Malicious File
T1059.001  - Command and Scripting Interpreter: PowerShell
T1574.002  - Hijack Execution Flow: DLL Side-Loading
T1568.002  - Dynamic Resolution: Domain Generation Algorithms
T1021.006  - Remote Services: WMIExec
T1021.002  - Remote Services: SMB/Windows Admin Shares
T1090.003  - Proxy: Multi-hop Proxy (Chisel SOCKS)
T1562.001  - Impair Defenses: Disable or Modify Tools (Defender exclusions)

(in)sicurezza digitale

2026-06-18 13:59:31

FortiBleed: 73.000 firewall Fortinet violati in 194 paesi, un gruppo russo con 1,16 miliardi di tentativi svela i limiti della complessità delle password

Si parla di:
Toggle

Una campagna di cyber-spionaggio di proporzioni storiche ha silenziosamente svuotato le credenziali di decine di migliaia di firewall Fortinet in tutto il mondo. L’operazione, battezzata FortiBleed dai ricercatori di Hudson Rock, ha compromesso 73.932 URL univoci di dispositivi FortiGate e gateway SSL VPN distribuiti in 194 paesi, con conseguenze documentate che vanno dall’esfiltrazione di documenti riservati presso un contractor NATO turco alla presenza di credenziali funzionanti per colossi come Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture e Oracle.

Scoperta e attribuizione

Il dataset è stato inizialmente scoperto dal ricercatore ucraino Volodymyr “Bob” Diachenko, successivamente analizzata in profondità da Hudson Rock tramite il loro portale infostealers.com. La campagna è attribuita a un gruppo cybercriminale di lingua russa, multi-operatore, che ha costruito un’infrastruttura industriale per la compromissione automatizzata di perimetri aziendali. Non si tratta di un attore state-sponsored nel senso classico del termine, ma di un gruppo con capacità operative paragonabili, capace di gestire simultaneamente operazioni su scala globale.

La metodologia: credential stuffing da 1,16 miliardi di tentativi

Il modus operandi del gruppo rivela una sofisticazione che va ben oltre il semplice credential stuffing. Gli attori hanno prima eseguito una scansione sistematica di internet alla ricerca di istanze Fortinet esposte, raccogliendo oltre 320.000 target FortiGate. Contro questi obiettivi hanno eseguito 1,16 miliardi di tentativi di credenziali, attingendo a database storici di leak di credenziali. In parallelo, hanno condotto 2,1 miliardi di tentativi brute-force contro oltre 160.000 server MSSQL.

La chiave tecnica della campagna è l’intercettazione e il cracking degli hash di autenticazione SSL VPN. Quando un client si autentica a un gateway FortiGate via SSL VPN, vengono scambiati hash crittografici. Il gruppo ha costruito un cluster dedicato da 45 GPU gestito tramite Hashtopolis per craccare questi hash offline e recuperare le password in chiaro. Questo approccio trasforma la complessità della password in un fattore irrilevante: una stringa da 20 caratteri con simboli speciali è craccabile esattamente come una password semplice, purché l’hash sia stato intercettato.

La fase post-compromissione: pivot verso Active Directory

Una volta ottenuto l’accesso al gateway VPN, il gruppo ha operato in modo sistematico per approfondire il foothold. Il pattern documentato prevede il pivot diretto verso l’ambiente Active Directory interno, con l’obiettivo di stabilire persistenza a lungo termine nella rete della vittima. Questo approccio è coerente con operazioni di cyber-spionaggio piuttosto che con ransomware o criminalità finanziaria immediata: l’interesse non è monetizzare l’accesso in modo rumoroso, ma mantenerlo il più a lungo possibile.

Il caso più grave documentato da Diachenko riguarda un contractor della difesa turco membro NATO, da cui il gruppo ha esfiltrato con successo documenti classificati di difesa. Sono state inoltre documentate compromissioni complete di network in Giappone, Taiwan, Vietnam e Iraq.

La distribuzione geografica: l’Italia al 15° posto

La campagna ha avuto un impatto globale con una distribuzione geografica che riflette la diffusione di Fortinet come vendor di riferimento per la sicurezza perimetrale. I paesi più colpiti sono India (9.629), USA (6.352), Taiwan (3.637), Messico (3.197) e Turchia (3.032). L’Italia si posiziona al 15° posto con 1.251 dispositivi compromessi, un numero che include inevitabilmente PMI, enti pubblici e infrastrutture critiche, considerata la penetrazione di Fortinet nel mercato italiano.

I settori più colpiti globalmente sono IT Services (1.975 compromissioni), Costruzioni (587), Telecomunicazioni (574), Ingegneria (528) e Industrial Equipment (467). Seguono Financial Services (460) e Government Services (454), confermando che il gruppo non operava una selezione settoriale ma mirava alla massima copertura.

Il problema strutturale: la complessità delle password non basta

FortiBleed mette in crisi uno dei pilastri della security hygiene tradizionale: la complessità delle password. Il dataset mostra un alto volume di password estremamente complesse compromesse con successo. Il motivo è tecnico e fondamentale: quando le credenziali vengono recuperate in chiaro — tramite infostealer che le esfiltrano dal browser della vittima, tramite cracking di hash, o tramite exploit specifici del dispositivo — la complessità della stringa è completamente irrilevante. Un attaccante che dispone del plaintext di una password da 20 caratteri ha lo stesso accesso di chi usa “password123”.

Azioni di mitigazione immediate

• Rotazione forzata delle credenziali: reimpostare immediatamente tutte le password associate alle interfacce VPN e admin Fortinet, indipendentemente dalla loro complessità.
• MFA universale: applicare l’autenticazione multi-fattore a tutti i gateway esterni senza eccezioni. Questo neutralizza il valore delle credenziali sottratte.
• Audit dei log di accesso: analizzare i log di accesso Fortinet alla ricerca di sessioni amministrative inaspettate, login da posizioni anomale o volumi di traffico insoliti.
• Verifica backdoor: verificare la presenza di account nascosti, regole firewall non autorizzate, o configurazioni VPN anomale che potrebbero indicare una persistenza preesistente.
• Monitoraggio credenziali: confrontare le credenziali dei dipendenti e dei vendor di terze parti con database di threat intelligence per identificare quelle già compromesse.
• Verifica esposizione: Ransomfeed ha reso disponibile un portale gratuito su ransomfeed.it/?page=fortibleed dove le organizzazioni possono verificare se il proprio dominio è presente nel dataset compromesso.

Contesto: Fortinet e le vulnerabilità sistematiche

FortiBleed non arriva da zero. Negli ultimi anni i dispositivi Fortinet sono stati al centro di numerose campagne di exploitation che sfruttavano vulnerability critiche: CVE-2022-40684 (authentication bypass), CVE-2023-27997 (heap overflow pre-auth nel SSL VPN), CVE-2024-21762 (out-of-bounds write nel SSL VPN), tutte sfruttate attivamente in the wild. La presente campagna sembra però basarsi prevalentemente su credential stuffing da leak storici e cracking di hash piuttosto che su zero-day, il che suggerisce una superficie di attacco strutturalmente diversa e più difficile da mitigare tramite il solo patching.

Indicatori di Compromissione

# Portale di verifica gratuito Randomfeed
https://ransomfeed.it/?page=fortibleed

# Fonte primaria (infostealers.com/Hudson Rock)
<blockquote><a href="https://www.infostealers.com/article/fortibleed-75000-fortinet-firewalls-compromised-global-enterprises-exposed-claim-your-ethical-disclosure/">FortiBleed: 75,000 Fortinet Firewalls Compromised: Global Enterprises Exposed – Claim Your Ethical Disclosure</a></blockquote>

# Ricercatore originale
Volodymyr "Bob" Diachenko (@MayhemDayOne)

# Infrastruttura attaccante
- Cluster GPU dedicato: 45 GPU gestite via Hashtopolis
- 1,16 miliardi di tentativi su FortiGate
- 2,1 miliardi di tentativi brute-force su MSSQL
- Target: 320.000+ URL FortiGate, 160.000+ server MSSQL
- Paesi colpiti: 194
- URL unici compromessi: 73.932
- Domini unici compromessi: 21.632

Fonte: Hudson Rock / infostealers.com, ricerca di Volodymyr Diachenko. Pubblicato il 17 giugno 2026.

Ransomfeed

^Ransomfeed

(in)sicurezza digitale

2026-06-17 20:24:17

Supply chain attack su Uncanny Automator Pro: build backdoorata v7.3.0.5 distribuita a migliaia di siti WordPress

Il 12 giugno 2026, un attaccante sconosciuto ha compromesso l’infrastruttura di distribuzione di Uncanny Automator Pro, uno dei plugin WordPress più diffusi con oltre 50.000 installazioni attive. Il risultato: una build malevola — la versione 7.3.0.5 — consegnata automaticamente a una percentuale dei siti che usano il plugin, trasformando il canale di aggiornamento in un vettore di attacco. Un caso da manuale di supply chain attack nel mondo WordPress.

Cos’è Uncanny Automator e perché è un target appetibile

Uncanny Automator, sviluppato dalla società canadese Uncanny Owl, è un plugin WordPress per l’automazione di workflow. Permette di connettere plugin, app e servizi creando “ricette” automatizzate — integrazioni tra WooCommerce, BuddyBoss, LearnDash, Slack e molti altri. La versione Pro conta migliaia di siti attivi e viene distribuita tramite il sito automatorplugin.com, server di aggiornamento e licensing separato dal repository ufficiale di WordPress.org.

Questo modello di distribuzione autonomo — comune tra i plugin premium — è esattamente ciò che ha reso possibile l’attacco: compromettere automatorplugin.com significa controllare cosa viene consegnato agli aggiornamenti automatici di migliaia di siti WordPress.

Come si è svolto l’attacco

Secondo la comunicazione ufficiale firmata dal co-fondatore Ken, l’attaccante ha sfruttato una vulnerabilità in un software di terze parti in esecuzione su automatorplugin.com per ottenere accesso ai sistemi dell’azienda. Una volta dentro, ha eseguito due operazioni ad alto impatto in rapida successione:

• Tampering del pacchetto di aggiornamento: la build legittima di Uncanny Automator Pro sul server di distribuzione è stata sostituita con una versione backdoorata, etichettata come versione 7.3.0.5.
• Accesso al database di licensing: l’attaccante ha violato il database dello store e del sistema di licenze, esfiltrando dati cliente.

Il repository del codice sorgente non è stato toccato — un dettaglio importante che limita l’impatto futuro ma non quello immediato, poiché i siti non scaricano il codice dal repository ma dal server di distribuzione.

La finestra di esposizione: 21 ore di distribuzione malevola

La build compromessa è rimasta disponibile per circa 21 ore, dal 12 al 13 giugno 2026, quando Uncanny Owl ha rilevato l’intrusione e rimosso l’accesso dell’attaccante. In questa finestra, la versione 7.3.0.5 è stata distribuita a meno del 6% dei siti attivi che usano il plugin Pro — un numero contenuto, ma potenzialmente ancora nell’ordine delle migliaia di installazioni WordPress compromesse.

La versione gratuita Uncanny Automator Lite, distribuita tramite il repository ufficiale di WordPress.org, non è stata interessata dall’attacco.

Dati esposti e rischi per i clienti

La violazione del database di licensing ha esposto i seguenti dati per i clienti registrati:

• Nomi e indirizzi email
• Chiavi di licenza del plugin
• URL dei siti WordPress associati alle licenze

Dati di pagamento e numeri di carta non sono stati compromessi poiché l’azienda non li memorizza. Le password erano archiviate come hash crittografici — non in chiaro — ma come misura precauzionale Uncanny Owl ha resettato tutte le password degli account.

La combinazione di email + URL del sito + chiave di licenza crea però un vettore di phishing estremamente credibile: un attaccante può inviare email personalizzate fingendo di essere Uncanny Owl, chiedendo di installare “l’ultima versione” del plugin — che potrebbe essere di nuovo una build malevola. È un rischio che persiste anche dopo la remediation dell’infrastruttura.

Risposta dell’azienda e remediation

Uncanny Owl ha risposto rapidamente una volta rilevata l’intrusione:

• 13 giugno: rimosso l’accesso dell’attaccante, rilasciata la versione pulita 7.3.0.6
• 14 giugno: completata l’indagine, nessun segno di reinfezione
• Eliminati account amministratore non autorizzati, entry malevole nel database e task pianificati inseriti dall’attaccante
• Rotazione di tutte le credenziali e chiavi esposte

L’azienda ha pubblicato un Security Incident Notice completo sul proprio sito con tutti i dettagli e gli step di remediation raccomandati.

Il rischio residuo: la 7.3.0.5 è ancora in circolazione

Un aspetto critico sottolineato da Uncanny Owl riguarda la persistenza del rischio: installare una build 7.3.0.5 da qualsiasi fonte infetterà ancora il sito. Non è sufficiente che il server di distribuzione sia ora pulito. Copie della build malevola potrebbero circolare su repository non ufficiali, forum di pirateria software o essere utilizzate in attacchi successivi.

Inoltre, un aggiornamento in-place verso la 7.3.0.6 non è sufficiente per i siti già infetti: il backdoor installato dalla 7.3.0.5 può persistere indipendentemente dall’aggiornamento del plugin. È necessaria una remediation completa.

Cosa devono fare gli amministratori WordPress

• Verificare immediatamente la versione installata del plugin: deve essere 7.3.0.6 o superiore, mai 7.3.0.5
• Se il sito ha eseguito la 7.3.0.5, trattarlo come compromesso e seguire la procedura di remediation completa indicata da Uncanny Owl
• Resettare la password dell’account su automatorplugin.com tramite i canali ufficiali
• Monitorare eventuali email sospette da mittenti che si spacciano per Uncanny Owl o Uncanny Automator
• Non installare la versione 7.3.0.5 da nessuna fonte, anche se presentata come “originale”
• Verificare l’assenza di account amministratore WordPress non autorizzati, task pianificati anomali e modifiche al database

# Indicatori di compromissione da verificare su siti WordPress con plugin v7.3.0.5

# 1. Account amministratore WordPress non autorizzati
SELECT user_login, user_email FROM wp_users 
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
ORDER BY user_registered DESC;

# 2. Task schedulati WordPress anomali (wp-cron)
SELECT * FROM wp_options WHERE option_name = 'cron' -- cercare entry con hook sconosciuti

# 3. Modifiche recenti a file core o plugin (ultimi 21 giorni)
find /path/to/wordpress -newer /path/to/wordpress/wp-config.php -name "*.php" 
  -not -path "*/cache/*" -not -path "*/uploads/*"

# Versione sicura: >= 7.3.0.6
# Versione compromessa: 7.3.0.5 (da qualsiasi fonte)
# Versione Lite (WordPress.org): non interessata dall'attacco

L’incidente di Uncanny Automator si inserisce in un pattern preoccupante di supply chain attack contro plugin WordPress premium, dove la distribuzione autonoma fuori dal repository ufficiale diventa il tallone d’Achille. La dipendenza da infrastrutture di distribuzione di terze parti, spesso meno protette del repository centrale, continuerà a essere un vettore di attacco privilegiato per chi vuole colpire a scala migliaia di siti simultaneamente.

Security Incident Notice: Uncanny Automator - Uncanny Automator

Summary We are writing to inform you of a security incident affecting Uncanny Automator and automatorplugin.com. On June 12, 2026, an attacker exploited a vulnerability in third-party software running on automatorplugin.

^{Ken Young (Uncanny Automator)}