Nel mio ultimo post, "The Cutting Edge: AI’s Inevitable Rise in Offensive Security" (All'avanguardia:l'inevitabile ascesa dell'IAnella sicurezza offensiva), ho esaminato come l'IA stia iniziando ad automatizzare e potenziare le operazioni dei red team. Stiamo passando da strumenti manuali ad agenti autonomi in grado di elaborare strategie e adattarsi. Tuttavia, molti dei metodi generativi attualmente utilizzati dai red team devono affrontare sfide quali allucinazioni, limitazioni contestuali e compromessi tra modelli specializzati e framework modulari più generici.
Oggi vorrei approfondire una soluzione proposta in quel documento che segna un cambiamento di paradigma per il comando e controllo (C2): il Model Context Protocol (MCP). Non si tratta solo di un miglioramento incrementale, ma di un nuovo modo di concepire il comando e controllo.
I framework C2 tradizionali, nonostante la loro utilità, funzionano secondo un ciclo prevedibile e ritmico: l'impianto invia un "segnale" al server C2 per verificare la presenza di nuovi comandi. Questa regolarità rappresenta un rischio significativo per la sicurezza operativa (OPSEC). Le moderne soluzioni NDR sono specificamente progettate per individuare questi modelli. Una volta che un NDR segnala quel battito cardiaco costante, l'impianto e l'operazione vengono bruciati.
L'architettura MCP cambia radicalmente questo modello consentendo operazioni asincrone e parallele senza alcun beaconing periodico. Invece di un check-in costante, gli agenti comunicano in modo nascosto, mescolando il loro traffico con quella che sembra una normale attività di IA aziendale. Questo è il punto di forza principale: si nasconde nel rumore delle comunicazioni legittime della rete, rendendo eccezionalmente difficile l'isolamento da parte dei difensori.
La nostra architettura (figura sopra) ha 3 componenti principali. L'agente MCP ha due canali di comunicazione: uno con il server MCP e un altro con il provider LLM, in questo caso Anthropic.
- Server MCP: dove viene assegnato e restituito il compito di alto livello.
- Agente MCP: si connette al server MCP per acquisire l'attività, si disconnette e invia un rapporto in un secondo momento. L'agente MCP comunica anche con l'API LLM che sta eseguendo l'attacco.
- API antropica: il vero aggressore in questo caso. Grazie alla combinazione di un buon prompt di sistema e un'attività di alto livello, siamo in grado di far sì che il LLM benigno esegua exploit completi e segnali quando l'attività è stata completata.
Oltre il Beaconing
La figura sottostante illustra un Cobalt Strike , mostrando chiaramente i modelli di beaconing. Quando l'autore dell'attacco entra in azione, i picchi significativi rappresentano grandi quantità di dati trasmessi, principalmente output di comandi.
Al contrario, la figura sottostante mostra come avviene la comunicazione con il nostro framework agentico. Questa comunicazione è guidata dagli eventi: un compito viene assegnato a un agente collegato all'MCP. L'agente raccoglie il compito e chiude la connessione con il server MCP. Dopo aver eseguito il compito, l'agente si ricollega al server e riferisce i risultati ottenuti. Nella rappresentazione sottostante sono raffigurati due casi di questo tipo (due attacchi). Il grande picco blu nel secondo picco di ciascun attacco indica il punto in cui l'agente invia tutte le informazioni importanti.
Ora, concentriamoci su uno di questi attacchi. Il grafico in basso nella figura seguente rappresenta la comunicazione degli agenti con il server MCP, ingrandita su uno degli attacchi sopra menzionati. Possiamo vedere chiaramente che l'agente invia rapporti solo all'inizio e alla fine dell'attività, mentre la comunicazione effettiva avviene tra l'agente e l'API Anthropic.
Come possiamo vedere, si sta formando uno schema che ci permette di individuare questo comportamento, ad esempio l'aumento dei picchi blu man mano che il contesto si riempie nel tempo. Ma ora osserviamo la figura sottostante:
Il cambiamento nel modello è evidente: l'agente ha utilizzato una risposta in streaming e ha gestito la finestra contestuale in modo più efficace, alterando così completamente il modello precedentemente identificato. A complicare ulteriormente la sfida, molte aziende tecnologiche utilizzano strumenti come Claude Code o Cursor, che eseguono chiamate API ad Anthropic, rendendo questi modelli ancora più difficili da differenziare a causa del rumore generato dalle chiamate innocue.
Evasione EDR e sciame polimorfico
Questo può essere concettualizzato come un passaggio da una spia solitaria e statica a una squadra dinamica di esploratori mutaforma. "Polimorfico" indica che questi agenti possono modificare le loro caratteristiche per eludere il rilevamento in base all'ambiente. "Distribuito" significa che numerosi agenti operano contemporaneamente. Questo "sciame" è in grado di:
- Operare in parallelo: anziché affidare a un singolo agente l'esecuzione sequenziale di un'unica attività, lo sciame può mappare simultaneamente diversi segmenti di rete, testare varie vulnerabilità e raccogliere informazioni.
- Condivisione delle informazioni in tempo reale: l'MCP funge da sistema nervoso centrale per questo sciame. Quando un agente individua un potenziale percorso, una credenziale debole o un servizio non aggiornato, diffonde immediatamente tali informazioni all'intero sciame, consentendo una ridefinizione collettiva delle priorità e lo sfruttamento di nuove opportunità.
- Aumento della resilienza: anche se un agente viene individuato e neutralizzato, la missione non viene compromessa. Il resto dello sciame si adatta e continua l'operazione, imparando dall'individuazione per migliorare la propria invisibilità.
Un caso di studio reale: compromissione rapida del dominio
Come abbiamo visto nei grafici sull'elusione EDR, non si tratta solo di teoria: abbiamo implementato la nostra soluzione utilizzando proprio questa architettura su reti reali e su macchine di prova. I risultati dell'elusione EDR variano notevolmente a seconda del sistema di cui dispone l'agente e del compito che gli è stato assegnato. Ad esempio, quando gli viene assegnato il compito di:
“Verificare le capacità di elusione EDR utilizzando BYOVDKit e la manipolazione di base dei processi. Identificare innanzitutto la soluzione EDR in esecuzione, quindi tentare di caricare un driver vulnerabile utilizzando BYOVDKit per disabilitare la protezione dei processi. Verificare l'iniezione di base dei processi e documentare ciò che viene rilevato. Se l'operazione ha esito positivo, procedere con tecniche di movimento laterale semplici.”
Descrizione dell'esecuzione: L'agente ha autonomamente tradotto questo obiettivo in un piano multifase e lo ha eseguito.
1) Fase 1: Identificazione EDR (Successo)
L'agente ha iniziato effettuando una ricognizione per identificare la soluzione di sicurezza attiva. Ha identificato con successo MsMpEng.exe e MpDefenderCoreService.exe come processi EDR primari. Ha inoltre interrogato lo stato del difensore e confermato che tutte le funzionalità di protezione chiave erano attive, tra cui RealTimeProtectionEnabled: True e, cosa fondamentale, IsTamperProtected: True|.
2) Fase 2: Ricognizione dei driver vulnerabili (bloccata dal rafforzamento)
Seguendo il suo piano di tentare un attacco "Bring Your Own Vulnerable Driver" (BYOVD), l'agente ha cercato nel sistema driver vulnerabili comuni, ma non ne ha trovati. Ciò ha dimostrato che l'host non era vulnerabile a questo vettore di attacco comune e ha impedito all'agente di procedere con la manipolazione a livello di kernel.
3) Fase 3: Tentativo di iniezione del processo (bloccato da AMSI)
Passando dall'approccio BYOVD fallito, l'agente ha tentato una classica tecnica di iniezione di processo in explorer.exe utilizzando PowerShell . Il tentativo è fallito immediatamente a causa di un errore di analisi di PowerShell, che il riepilogo dell'IA dell'agente ha correttamente attribuitoMalware Interface (AMSI) di Microsoft, che ha impedito l'esecuzione dello script dannoso nella memoria.
Dal punto di vista della valutazione, il test è stato un successo clamoroso. L'agente ha eseguito in modo autonomo un piano complesso, ha identificato correttamente le difese attive ed è stato infine bloccato dai controlli di sicurezza a più livelli. Ma soprattutto, l'intera operazione, compreso il tentativo di iniezione fallito, non ha generato alcun rilevamento da parte dell'EDR che abbiamo utilizzato.
Intelligenza condivisa con demo (video)
Nel nostro test abbiamo utilizzato due agenti per dimostrare il concetto di intelligenza condivisa. Il risultato? L'agente ha compromesso il router sulla rete (video qui sotto).
Gli agenti sono riusciti a compromettere un router di rete, dimostrando l'efficacia pratica del passaggio da agenti monolitici a uno sciame coordinato. Combina le capacità di pianificazione di alto livello dei modelli linguistici di grandi dimensioni (LLM) con un framework C2 che può essere furtivo e veloce.
Il buono e il cattivo:
Questo strumento offre vantaggi significativi per i penetration tester, consentendo una rapida valutazione dello stato della rete e il rilevamento proattivo dei comportamenti basati su LLM. Tuttavia, presenta anche un rischio, in quanto potrebbe potenzialmente consentire a persone con conoscenze limitate in materia di sicurezza informatica di causare danni significativi conil "vibe hacking".