EDRChoker: il tool che “spegne” gli EDR manipolando la Quality Of Services di Windows

EDRChoker è un nuovo strumento open source che utilizza le policy QoS di Windows per limitare drasticamente la connettività degli agenti EDR verso il cloud, senza disattivarli direttamente. La tecnica provoca timeout continui e interrompe il flusso di telemetria, rendendo più difficile individuare attività malevole. Il caso evidenzia una debolezza delle architetture EDR cloud-based e la necessità di monitorare anche le modifiche alle policy QoS e alle restrizioni di banda applicate ai processi di sicurezza.

Un nuovo strumento open-source, EDRChoker, dimostra che non è necessario terminare, falsificare o attaccare direttamente il processo di sicurezza. È sufficiente bloccare quasi completamente la sua connessione di rete tramite il meccanismo standard di Windows e l’agente risulterà attivo ma perderà la connessione al cloud.

Lo strumento EDRChoker è stato sviluppato da un ricercatore @TwoSevenOneT. EDRChoker utilizza il servizio Quality Of Services di Windows (QoS), un meccanismo integrato di gestione della qualità del servizio di rete. Mentre QoS viene tipicamente utilizzato per dare priorità al traffico, in questo caso diventa un modo per limitare drasticamente la larghezza di banda per processi specifici. Per l’agente EDR, questa configurazione significa un isolamento pressoché totale dai server di gestione.

Le moderne piattaforme EDR si basano fortemente sulla comunicazione costante tra l’agente endpoint e l’infrastruttura cloud del fornitore. Eventi di sicurezza, dati di telemetria e avvisi di attività sospette vengono trasmessi attraverso questo canale. L’agente riceve inoltre policy, comandi amministrativi e regole di risposta aggiornate tramite questo canale. Quando la connessione viene interrotta, il sistema di sicurezza non necessariamente smette di funzionare, ma perde una delle sue funzioni chiave: la segnalazione rapida degli eventi al centro di controllo dal dispositivo.

In passato, i red team interferivano spesso utilizzando metodi più diretti. Ad esempio, creando regole per il firewall di Windows Defender o utilizzando la piattaforma di filtro di Windows (WFP) per bloccare i pacchetti in uscita dagli agenti EDR. Questo approccio presenta un notevole svantaggio per l’attaccante: il blocco e l’eliminazione dei pacchetti sono chiaramente visibili a molti prodotti di sicurezza. Alcune soluzioni, tra cui Elastic Defend, sono già in grado di rilevare tali tentativi di elusione tramite WFP e di generare un allarme.

EDRChoker adotta un approccio più discreto. Lo strumento non blocca completamente il traffico, ma ne riduce la velocità disponibile quasi a zero. In pratica, l’agente tenta di connettersi al server, ma la connessione va costantemente in timeout. Anche un handshake TLS standard richiede lo scambio di diversi kilobyte di dati, inclusa la catena di certificati, e con il canale artificialmente limitato, il normale scambio di dati semplicemente non ha il tempo di completarsi. Dall’esterno, la situazione sembra più un problema di rete che un blocco classico.

La particolarità tecnica deriva dal punto in cui Windows applica queste restrizioni. Le policy QoS sono gestite dal componente pacer.sys, il driver di filtro leggero NDIS. Questo componente opera più vicino alla scheda di rete, al di sotto del livello della piattaforma di filtro di Windows (WFP) nello stack di rete. Per questo motivo, gli strumenti di monitoraggio che si concentrano principalmente sugli eventi WFP potrebbero non rilevare il consueto schema di blocco. Il traffico viene limitato prima che determinati meccanismi di controllo possano raggiungerlo.

Secondo l’autore, EDRChoker accetta un file contenente un elenco di processi EDR e crea automaticamente policy QoS individuali per ciascuno di essi. Ogni policy utilizza un nome di processo e un GUID casuale per garantire che diverse esecuzioni dello strumento non producano risultati identici. Lo strumento è inoltre in grado di eliminare le policy create e di ripulire le tracce di configurazione.

Il rischio principale di EDRChoker non risiede nell’utilità in sé, ma nell’idea stessa. Molte aziende sono abituate a considerare l’EDR come una fonte di informazioni pressoché inesauribile sullo stato degli endpoint. Tuttavia, l’architettura cloud si basa su una connessione stabile. Se l’agente non riesce a comunicare con il server, il centro di monitoraggio non ottiene un quadro completo della situazione, ma solo una comoda illusione di controllo. Il processo sulla macchina continua a essere in esecuzione, l’icona potrebbe apparire normale, ma i dati di telemetria non raggiungono più il livello necessario per attivare un avviso e una risposta.

Per chi si occupa della sicurezza, questa è una conclusione piuttosto spiacevole, ma utile. Monitorare solo processi, servizi, regole del firewall ed eventi WFP non è sufficiente. È necessario monitorare anche le modifiche alle policy QoS, le restrizioni di banda sospette per i processi di sicurezza e gli strani timeout degli agenti EDR. Più gli aggressori penetrano nello stack di rete di Windows, meno utile diventa monitorare solo i livelli superiori. Altrimenti, l’organizzazione rischia di scoprire un problema in un momento cruciale per il settore della sicurezza: troppo tardi.

Carolina Vivianti

Carolina Vivianti è consulente/Advisor autonomo in sicurezza informatica con esperienza nel settore tech e security. Ha lavorato come Security Advisor per Ford EU/Ford Motor Company e Vodafone e ha studi presso la Sapienza Università di Roma.

Aree di competenza: Cybersecurity, IT Risk Management, Security Advisory, Threat Analysis, Data Protection, Cloud Security, Compliance & Governance