EDR compromesso — il playbook quando lo stack endpoint è il vettore

Usa questo playbook quando uno qualunque dei seguenti trigger è osservato:

• Una CVE che impatta la tua piattaforma di sicurezza endpoint deployata è aggiunta al catalogo Known Exploited Vulnerabilities CISA — esempi recenti includono CVE-2026-41091 (LPE Microsoft Defender), CVE-2026-45498 (DoS Defender) e CVE-2026-34926 (agent-injection Trend Micro Apex One on-prem).
• Un host noto-attivo è andato in telemetria-silenzio per più della baseline della tua detection platform, senza ticket di cambio host che lo spieghi.
• La console di management endpoint (portale Defender for Endpoint, server Apex One, admin plane CrowdStrike Falcon, console di management SentinelOne, policy server MDE) mostra attività amministrativa inattesa, modifiche configurazione o eventi di agent-deployment fuori change-management.
• Un'organizzazione peer nel tuo settore ha pubblicato un report IR che descrive lo stesso vendor e la stessa versione che hai in produzione.
• È osservato un pattern BYOVD — caricamento di driver kernel-level da un path non-vendor, catene di terminazione del servizio EDR, o side-loading in stile msimg32.dll coerente con le campagne Qilin / Warlock 2026.

NON usare questo playbook per: un EDR che semplicemente non ha allertato su una detection nota (è un problema di tuning, non un compromise della piattaforma), cicli di vendor-patch di routine senza evidenza di sfruttamento, o tempeste di falsi positivi (sono triage operativo, non IR).

Due clock girano in parallelo. Confonderli è l'errore operativo più comune.

Il detection clock è interno. Parte dall'osservazione del trigger (CVE pubblicata, gap di telemetria, traffico anomalo sul management plane) e gira contro la tua SLO interna da triage a containment. Target maturi tipici: sotto 1 ora alla decisione di triage, sotto 4 ore all'isolamento della piattaforma, sotto 24 ore alla conferma del blast radius.

Il regulator clock è esterno. Sotto art. 23 NIS2 parte dal momento di awareness di un incidente significativo — early warning a 24 ore, notifica incidente a 72 ore, report finale a 1 mese. Sotto art. 19 DORA parte dalla classificazione di un incidente ICT grave — notifica iniziale a 4 ore dalla classificazione (tetto esterno di 24 ore dalla detection), intermedia a 72 ore, finale a 1 mese. Sotto art. 33 GDPR — 72 ore dall'awareness di una violazione di dati personali.

La trappola: i team aspettano che l'EDR confermi il compromise prima di partire il regulator clock. La regola lato regolatore è "sapevi o avresti dovuto sapere" — una volta che una CVE KEV-listed nel tuo stack è pubblicata con un report di sfruttamento, avresti dovuto sapere. La difesa "il nostro EDR non ha allertato" danneggia attivamente la tua posizione perché conferma che l'EDR non può essere fidato come fonte di verità che il supervisore si aspettava lo fosse.

La disciplina: parti *entrambi* i clock al trigger. Fila l'early warning regolatorio su evidenze out-of-band — listing KEV, advisory vendor, gap di telemetria osservato. Aggiorna al gate intermedio man mano che l'indagine interna chiude il quadro. Non ritardare il filing regolatorio per certezza interna; il regolamento si aspetta che le submission preliminari evolvano.

Obiettivo: contenere il percorso di sovversione più probabile prima che si diffonda. Non assumere che la flotta di agenti sia ostile finché non provato; assumi che il management plane sia ostile finché non provato sicuro.

Checklist per le prime 4 ore:

• Classifica il trigger rispetto alle tre categorie: evasion (BYOVD, bypass anti-tamper), neutralisation (DoS, muting agent, gap di telemetria) o sovversione (management plane usato come canale di deployment). La categoria sovversione è il caso a severità più alta e richiede assunzione di breach fleet-wide.
• Isola la console di management al livello di rete: rimuovi la raggiungibilità della console di agent-deployment dagli endpoint gestiti (ACL firewall sul set di porte di agent-update), preserva accesso read-only per la forensics.
• Congela lo stato del management plane: snapshot della VM console, snapshot del database sottostante, export di policy e cronologia deployment, export dei log di autenticazione amministrativa per gli ultimi 14 giorni. Firma ogni snapshot al write time.
• Identifica le sessioni privilegiate in volo: ogni sessione amministrativa attiva sulla console tra il trigger time e l'isolamento è sospetta. Force-revoke, cattura i token di sessione, allerta il team identity.
• Attiva il piano di telemetria out-of-band: DPI di rete, log sign-in identity provider (Entra/Okta), log cloud-control-plane (AWS CloudTrail, Azure Activity, GCP Audit) diventano sorgenti primarie. L'EDR endpoint-resident è *secondario* finché non liberato.
• Parti il regulator clock. Fila l'early warning NIS2 / notifica iniziale DORA sull'evidenza disponibile — citazione KEV, advisory vendor, gap osservato. Non aspettare che la forensics interna sia completa.
• Notifica il vendor. Per eventi in classe Trend Micro Apex One, il team IR vendor ha playbook specifici per il pattern di abuso del loro management plane ed è contrattualmente obbligato ad assistere.

Failure mode a questo gate: rimuovere gli agenti EDR dalla flotta. Distrugge lo stato forense e rimuove l'unica strumentazione on-host che hai. Isola il management plane dagli agenti; non disinstallare gli agenti dagli endpoint.

Obiettivo: ricostruire la verità di stato senza affidarsi all'agente endpoint. Fila il report intermedio regolatorio entro ora 72.

Sorgenti dati out-of-band (in ordine di priorità):

1. DPI di rete / NDR: analisi del traffico cifrato da un tap passivo o un appliance in-line che non gira sugli endpoint. Una sovversione del management plane che spinge codice attaccante a migliaia di endpoint emette una firma di traffico riconoscibile — timing di fan-out che combacia con l'inventario degli agenti, clustering di payload-size al deployment time. È il canale parallelo più affidabile perché il filo non mente su cosa lo ha attraversato.
2. Log audit identity provider: ogni autenticazione amministrativa alla console — Entra, Okta, Active Directory — indipendente dall'EDR. Cross-reference contro la lista di sessioni privilegiate da Ora 0-4.
3. Log control-plane cloud: dove la console gira in AWS/Azure/GCP, il log audit della piattaforma cattura chiamate API fuori dalla conoscenza dell'EDR — modifica istanza, cambio IAM, riconfigurazione rete.
4. Log resolver DNS: ogni beaconing da endpoint compromessi, incluso il phone-home post-sovversione dal codice deployato dall'attaccante, transita per DNS. I log resolver centralizzati vedono cosa l'agente on-host non vede.
5. Tooling di configuration management: gli inventari Ansible, SCCM, Intune, Chef ti danno lo "stato noto" di ogni host indipendentemente dalla vista che l'EDR ha di sé.

Checklist di mappatura blast-radius:

• Enumera ogni endpoint a cui la console di management *avrebbe potuto* pushare tra il trigger time e l'isolamento. È la tua flotta sospetta.
• Per ogni host sospetto, recupera la telemetria di rete — nuove destinazioni outbound, primitive rilevanti per la persistence (creazione scheduled task, registrazione servizio, scrittura registro visibili via firme NDR Sysmon-equivalent).
• Identifica il silent set: host andati in telemetria-silenzio dentro la finestra trigger senza motivo di business. Trattali come compromessi finché non liberati.
• Identifica il lateral set: host che hanno ricevuto connessioni inbound dal sospetto o silent set. Trattali come esposti.
• Costruisci la tabella di cross-reference: host sospetto → attività identity provider → attività piattaforma cloud → log risoluzione DNS → verdetto NDR.

Il report intermedio regolatorio (filato entro ora 72) copre:

• Valutazione aggiornata dello scope impattato (dimensione flotta sospetta, silent set, lateral set).
• Indicatori di compromissione tratti dalle sorgenti out-of-band — mai esclusivamente dalla telemetria dell'EDR sospettato di compromissione.
• Azioni di containment prese: isolamento management plane, congelamento pipeline di agent-deployment, revoca sessioni privilegiate.
• Ipotesi iniziale di root-cause legata alla CVE specifica o alla primitiva BYOVD osservata (cita l'ID CVE; è quello che i supervisori si aspettano).
• Se sono stati acceduti dati personali (fa partire il timeline parallelo art. 33 GDPR).
• Stima aggiornata di clienti, transazioni o servizi critici impattati (criteri di classificazione DORA).

Obiettivo: riportare la piattaforma di sicurezza endpoint a uno stato noto-buono, validare quello stato contro un avversario, e filare il report finale regolatorio entro 1 mese.

L'eradication è a due strati:

1. Strato piattaforma: patcha la console alla versione vendor-fixed, ricostruisci la VM del management plane da un'immagine verified-clean, ruota ogni credenziale amministrativa (console-local, IdP-federated, API key), invalida tutti i token di sessione, audita policy e cronologia deployment per modifiche non autorizzate, ripristina la policy da uno snapshot precedente al trigger.
2. Strato agente: per la flotta sospetta-e-silent, non fidarti dell'auto-attestazione di pulizia dell'EDR (ora patchato). Imagina forensemente un campione statistico, valida contro il set IoC costruito a Ora 4-72, e o re-imagina la flotta o esegui un hunt out-of-band con un tool second-source (Velociraptor, GRR, forensics OS nativa) prima di dichiarare pulito.

Validazione recovery:

• Riabilita la comunicazione management-plane-verso-agente solo dopo che entrambi gli strati sono eradicati e l'hunt IoC torna negativo per ≥ 7 giorni.
• Esegui una validazione offensiva mirata contro la piattaforma ricostruita: replay della primitiva di attacco originale (sfruttamento CVE in lab, driver BYOVD contro la nuova policy) e conferma che il nuovo stato rilevi o prevenga. Non dichiarare recovery solo sulla patch vendor.
• Ripristina la fiducia detection on-host gradualmente — promuovi l'EDR da "secondario, audit-only" a "primario" solo dopo che la detection parallela out-of-band ha confermato accordo per un periodo sostenuto.

Contenuto del report finale regolatorio (filato entro mese 1):

• Root cause verificata con riferimento a CVE o nome driver.
• Blast radius confermato (count finali su sospetto, silent, lateral set).
• Lista IoC completa con provenance — quali IoC vengono da sorgenti out-of-band, quali dall'EDR post-recovery.
• Status remediation: patch console in produzione, management plane ricostruito, imaging flotta completato per X host, esposizione residua per Y host (con target date).
• Lessons learned legate specificamente al modello di fiducia — cosa l'organizzazione ha cambiato su come pesa la telemetria endpoint-resident vs out-of-band.
• Costi diretti e indiretti (criterio di impatto economico DORA).
• Cross-reference a submission parallele (NIS2, GDPR, settoriali, law enforcement).

Su tutti e tre i gate, pianifica di avere pronto (ogni artefatto firmato al write time, datato, chain-of-custody preservata):

• Record di trigger: ID CVE, data listing KEV, ID advisory vendor, il tuo alert KEV-monitor (se presente) — la chain di evidenze che prova che eri stato messo in awareness.
• Coppia di snapshot console di management: snapshot pre-isolamento (l'evidenza viva) e snapshot post-isolamento (lo stato congelato) della VM console e del suo database.
• Log sessioni amministrative: ogni autenticazione al management plane per i 30 giorni precedenti il trigger, con IP sorgente, user agent, metodo MFA e risultato.
• Log deployment / cambio policy: ogni push dalla console agli agenti gestiti nei 30 giorni precedenti il trigger.
• Export telemetria di rete: cattura NDR/DPI sulla finestra trigger più 14 giorni precedenti, con timestamp originali e metadati di pacchetto preservati.
• Export log audit identity provider: tutte le autenticazioni di livello amministrativo su Entra/Okta/AD per la stessa finestra.
• Export log control-plane cloud: CloudTrail / Activity / Audit per l'ambiente del management plane.
• Export log resolver DNS: per ogni host nella flotta sospetta-e-silent.
• Artefatti di imaging forense: dove è stato usato sampling statistico per validare pulizia flotta, la metodologia di imaging, il record di chain-of-custody e il risultato di validazione.
• Comunicazioni IR vendor: record datato di advisory vendor ricevuti, ticket di supporto aperti, interazione con team IR vendor.
• Ricevute submission regolatorie: ogni timestamp di submission NIS2 / DORA / GDPR e relativa acknowledgement.
• Timeline attacco ricostruita: chain di timestamp firmati dall'osservazione trigger al report finale, niente edit manuali retroattivi.

Il pattern che le organizzazioni peer riportano dagli incidenti endpoint-piattaforma 2025-2026: il collo di bottiglia non è la risposta tecnica, è produrre evidenze regulator-grade sotto deadline quando la sorgente di verità primaria (l'EDR) è la cosa sotto investigazione. La validazione adversarial continua della piattaforma di sicurezza endpoint — far girare un generative pentest engine che produce primitive di sfruttamento novel contro la configurazione EDR deployata *prima* che la prossima CVE droppi — è la risposta ingegneristica che Zero Hunt costruisce, sul rail di AI Generative Pentest. Lo stesso engine che pressure-testa la piattaforma produce anche la chain di evidenze di tentativi di sfruttamento pre-firmata che chiude la domanda post-incidente "avresti potuto saperlo prima".

1. Trattare "nessun alert EDR" come evidenza di sicurezza. È il failure mode che ogni CVE in questa classe è progettata per sfruttare. CISA documenta dodici vulnerabilità Trend Micro Apex precedentemente o attivamente sfruttate — il pattern ricorre. Costruisci il runbook per scattare al listing KEV del *tuo* stack, indipendentemente dagli alert dell'agente.

2. Rimuovere gli agenti dalla flotta al primo sospetto. Rimuove lo stato forense. Isola il management plane dagli agenti — gli agenti sugli endpoint sono l'unica strumentazione on-host che hai.

3. Partire il regulator clock da "conferma interna di compromise" invece che da "sapevi o avresti dovuto sapere". I supervisori leggono la regola nel secondo modo. Un gap di 12 ore tra il listing KEV nel tuo stack e la tua submission di early warning è un rilievo, indipendentemente dallo status dell'indagine interna.

4. Detection a sorgente singola durante la response. Se l'unica sorgente che contraddice l'EDR è *un altro* tool host-resident, non sei effettivamente uscito dall'assunzione di fiducia. Il canale parallelo deve essere off-host — DPI di rete, identity provider, control plane cloud.

5. Recovery solo via vendor-patch. Rileggendo il report BleepingComputer Apex One: la CVE è stata patchata, ma il management plane era stato un percorso di sovversione viable. La patch chiude *questa* primitiva; la domanda di fiducia sul management plane resta aperta. Re-valida adversarially prima di dichiarare recovery.

6. Tagliare l'EDR fuori dallo scope di pentest. La regola storica "non testare l'EDR, confonde il SOC" è esattamente il gap che queste CVE sfruttano. Porta la piattaforma di sicurezza endpoint nello scope di validazione adversarial continua; non lasciarla come l'unico componente che non vede mai un avversario se non in produzione.

Un singolo incidente endpoint-piattaforma fa tipicamente scattare notifiche regolatorie multiple in parallelo:

• Entità essenziale o importante UE sotto NIS2: early warning a 24 ore, notifica a 72 ore, finale a 1 mese — il trigger è "incidente significativo", e una CVE KEV-listed in una piattaforma di sicurezza fleet-wide attraversa quasi sempre la soglia di significatività.
• Entità finanziaria UE sotto DORA: notifica iniziale a 4 ore, intermedia a 72 ore, finale a 1 mese — la piattaforma di sicurezza endpoint protegge funzioni critiche e importanti per definizione; un incidente che la impatta attraversa l'art. 7 (servizi critici impattati) del Reg (UE) 2024/1772.
• Art. 33 GDPR se sono stati acceduti dati personali via la flotta sospetta (gli host del lateral set sono il test case) — 72 ore dall'awareness.
• Settoriali: in Italia, Consob (servizi di investimento), IVASS (assicurazioni), AgID (PA) — alcuni clock settoriali sono più corti di 24 ore, nel qual caso la notifica settoriale domina.
• Liaison law-enforcement: per attribuzioni confermate statuali o crimine organizzato, notifica parallela al CERT nazionale (ACN, BSI, ANSSI) e law enforcement.

La disciplina operativa: una base evidenze, export multipli. La stessa timeline firmata, lista IoC, worksheet di classificazione e documento di root-cause alimenta ogni submission in forme di summary diverse. Costruire il record una volta è l'unico modo perché il report finale di 1 mese non consumi il team — in particolare quando la response sta anche ricostruendo il management plane in parallelo. L'angolo metodologico è coperto nei playbook esistenti timeline incidenti NIS2 Title 13 e DORA 4h/72h/1-mese; la disciplina cross-pillar è la stessa qui, con la regola aggiunta che la sorgente di evidenza primaria (l'EDR) non può essere il testimone audit per un incidente in cui è implicato.