(in)sicurezza digitale

2026-06-26 17:03:48

macOS.Gaslight: backdoor nordcoreana in Rust che inganna i tool AI degli analisti di sicurezza

Il panorama delle minacce avanzate ha appena acquisito una dimensione inedita e preoccupante: un malware nordcoreano progettato specificamente per manipolare i tool di analisi basati su intelligenza artificiale, non per sfuggire ai sandbox tradizionali. macOS.Gaslight, scoperto e analizzato dai ricercatori di SentinelOne Labs, introduce una tecnica mai vista in natura: la prompt injection direttamente nel binario, indirizzata ai pipeline di triage assistiti da LLM che oggi affiancano il lavoro degli analisti di sicurezza.

Il contesto: l’escalation del malware DPRK per macOS

La Corea del Nord ha sviluppato negli anni una capacità offensiva su macOS di tutto rispetto, tipicamente orientata al furto di criptovalute e all’infiltrazione di aziende nel settore tecnologico e finanziario. I gruppi Lazarus, BlueNoroff e i loro cluster affiliati hanno già firmato strumenti come RustBucket, KANDYKORN e ObjCShellz. macOS.Gaslight si inserisce in questa filiera, ma aggiunge un elemento evolutivo significativo: la consapevolezza che i moderni workflow di analisi del malware si appoggiano sempre più a strumenti di triage automatizzato basati su LLM, e la volontà di sfruttare proprio questa dipendenza come vettore di evasione.

La tecnica centrale: prompt injection contro l’analista, non contro il sandbox

La caratteristica distintiva di macOS.Gaslight è un payload da 3,5 KB embedded direttamente nel binario: un blob in formato Markdown contenente 38 messaggi di sistema fasulli, delimitati da token {{DATA}}. Questa struttura imita deliberatamente lo scaffold di un harness LLM per il triage del malware, rendendo indistinguibile il confine tra dati campione non attendibili e istruzioni attendibili del sistema.

I messaggi fabricati simulano scenari di errore critici: scadenza del token, kill per esaurimento della memoria (OOM), esaurimento dello spazio su disco, ripetuti fallimenti operativi, avvisi di vulnerabilità da injection e flag da analisi statica. L’obiettivo, secondo SentinelOne, è far dubitare l’agente LLM della propria sessione di analisi, portandolo ad abortire o rifiutare l’esame del campione.

«La sua caratteristica più notevole è una cascata di messaggi di sistema fabbricati, progettata per far dubitare un agente di triage assistito da LLM della propria sessione. Attacca la percezione dell’agente, non il sandbox in cui opera.»
Phil Stokes, SentinelOne Labs

Architettura tecnica del malware

Linguaggio e firma: il binario è scritto in Rust, compilato per l’architettura macOS aarch64 (Apple Silicon). È firmato in modalità ad hoc e porta l’identificatore endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea. Il campione era stato caricato su VirusTotal il 22 maggio 2026, prima che un aggiornamento di Apple XProtect lo intercettasse basandosi puramente sull’hash.

Persistenza: il malware installa un LaunchAgent nel profilo utente, usando il label com.apple.system.services.activity nel file .plist, volutamente progettato per mimetizzarsi tra i processi di sistema legittimi di Apple. Per ottenere il percorso assoluto di se stesso da inserire nell’array ProgramArguments, il binario risolve a runtime la propria posizione tramite __NSGetExecutablePath.

Comando e controllo: l’implant utilizza il Telegram Bot API come canale C2, entrando in un ciclo di polling con getUpdates che permette all’operatore di inviare istruzioni tramite una shell interattiva e ricevere i risultati. Una scelta operativa che sfrutta la legittimità del traffico Telegram per eludere blocchi di rete basati su reputazione dei dominio. Il malware si auto-censura eliminando il proprio token Telegram dall’output runtime, impedendo a chiunque catturi log o crash di recuperarlo.

Modulo infostealer: incorporato nel binario è presente uno script Python da 6,6 KB codificato in Base64 che funge da suite di raccolta informazioni. Raccoglie: cronologia dei comandi del terminale, lista delle applicazioni installate, snapshot dei processi in esecuzione, profilo hardware e software del sistema, il database Keychain di macOS e credenziali salvate nei browser Chrome, Brave, Firefox e Safari. I dati raccolti vengono compressi in un archivio ZIP (temp/collected_data.zip) e caricati su Telegram.

Due righe per i difensori

macOS.Gaslight segna un punto di svolta: per la prima volta in natura si documenta l’uso della prompt injection come tecnica di evasione nei confronti dei pipeline di analisi automatizzata del malware. Non è più sufficiente affidarsi esclusivamente all’AI-assisted triage per la classificazione di campioni sospetti; i team di sicurezza devono implementare approcci a difesa in profondità che combinino analisi statica tradizionale, sandbox comportamentali e revisione umana.

Per quanto riguarda la detection su endpoint macOS, è consigliabile monitorare creazioni di LaunchAgent con label che imitano naming convention Apple (com.apple.*), connessioni uscenti verso l’API di Telegram (api.telegram.org) da processi non familiari, accessi al database Keychain da processi non autorizzati, e la creazione di archivi ZIP in directory temporanee non standard.

Indicatori di compromissione (IoC)

# Identificatore binario
endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea
# Persistenza LaunchAgent
Label: com.apple.system.services.activity
Path: ~/Library/LaunchAgents/com.apple.system.services.activity.plist
# File creato durante esfiltrazione
temp/collected_data.zip
# Traffico di rete C2
api.telegram.org (polling via getUpdates)
# Caratteristiche binario
Arch: macOS aarch64 (Apple Silicon)
Linguaggio: Rust
Firma: ad hoc signed

L’analisi completa con ulteriori indicatori tecnici è disponibile nel report originale di SentinelOne Labs. La scoperta rafforza la necessità di trattare qualsiasi output di analisi AI di campioni sconosciuti con un livello aggiuntivo di scetticismo, verificando manualmente le conclusioni quando i tool automatizzati segnalano errori di sessione o fallimenti operativi insoliti durante il triage.

(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.