EDR come superficie d'attacco: zero-day Defender e Apex One in 48 ore

Tra il 20 e il 21 maggio 2026 CISA ha aggiunto al Known Exploited Vulnerabilities catalog tre zero-day che colpiscono due dei prodotti di endpoint security più diffusi al mondo: due in Microsoft Defender (CVE-2026-41091 e CVE-2026-45498) e uno in Trend Micro Apex One on-prem (CVE-2026-34926). Tutte e tre sono confermate sfruttate in-the-wild. Le agenzie federali statunitensi hanno tempo fino al 3-4 giugno 2026 per applicare la patch o sospendere l'uso del prodotto. Dodici giorni dalla disclosure all'azione obbligata, sulla stessa classe di software che la maggior parte dei programmi di sicurezza tratta come ground truth.

Il dato che conta è il pattern. L'EDR e l'antivirus endpoint erano il prodotto che intercettava l'attacco. Questa settimana sono diventati il prodotto su cui l'attacco viaggia.

La coppia Defender: SYSTEM, poi silenzio

CVE-2026-41091 è una local privilege escalation nel Microsoft Malware Protection Engine. La causa, secondo l'analisi di Help Net Security, è una "risoluzione impropria dei link prima dell'accesso ai file" — un classico primitivo di link-following in un servizio che gira in contesto SYSTEM. L'exploit riuscito consegna all'attaccante SYSTEM su ogni host Windows con Defender attivo, ovvero praticamente ogni host Windows distribuito in quest'ultimo decennio. La patch è Malware Protection Engine v1.1.26040.8.

CVE-2026-45498 è invece un denial-of-service nel Microsoft Defender Antimalware Platform. Il DoS disattiva le funzionalità del prodotto antimalware. In parole povere: spegne Defender, sul posto, senza notificare l'utente. La patch è Antimalware Platform v4.18.26040.7.

Concatena le due e la kill chain si scrive da sé. La LPE porta l'attaccante a SYSTEM. Il DoS chiude Defender e la piattaforma smette di produrre telemetria. Tutto ciò che un SIEM agganciato all'EDR si aspettava di vedere da quell'host — eventi di process creation, tracce AMSI, verdetti di real-time scan — smette di arrivare. L'endpoint non "fallisce in chiuso" generando un alert. Fallisce in aperto, in silenzio.

Microsoft ha attribuito la scoperta della LPE a "più ricercatori" e non ha nominato nessuno per il DoS. L'avviso CISA del 20 maggio ha aggiunto entrambi al KEV insieme ad altre cinque CVE legacy del 2008-2010, con deadline di remediation federale al 3 giugno 2026.

Apex One on-prem: l'EDR diventa il canale di distribuzione

CVE-2026-34926 è il bug più interessante della settimana, e merita molta più attenzione di quanto suggerisca il suo CVSS di 6.7. È una directory traversal (CWE-23) nel componente server di Apex One on-prem. Il pezzo di BleepingComputer sintetizza il meccanismo: un attaccante con accesso amministrativo al server Apex One può "modificare una tabella chiave sul server per iniettare codice malevolo da deployare sugli agent delle installazioni colpite."

Va riletto. Il bug non permette di bypassare gli agent EDR. Il bug permette di usare il canale legittimo di deployment degli agent per inviare codice controllato dall'attaccante a ogni endpoint protetto da Apex One. Il payload malevolo arriva sullo stesso management plane che usa il canale di update dell'EDR. Dal punto di vista della rete è traffico vendor normale proveniente da un server interno fidato. Dal punto di vista dell'agent endpoint è un aggiornamento firmato e atteso dalla propria console di gestione. Non c'è un integrity gap da rilevare.

Il team IR di Trend Micro ha confermato almeno un tentativo di exploitation in-the-wild prima della disclosure pubblica. CISA l'ha aggiunta al KEV il 21 maggio (insieme a Langflow CVE-2025-34291), con deadline di patch federale al 4 giugno 2026. L'advisory nota che CISA traccia dodici CVE Apex One precedentemente o attivamente sfruttate — non è un caso isolato, è una classe ricorrente.

Lo score CVSS è fuorviante. Una directory traversal che concede diritti di distribuzione malware su una flotta gestita di migliaia di host ha blast radius effettiva di un RCE wormable, non di un 6.7.

È il trend 2026, solo a un'altitudine più alta

L'inquadramento "EDR come superficie d'attacco" non è una novità del 2026. Quello che è cambiato è il livello.

Nel primo trimestre, affiliati ransomware Qilin e Warlock sono stati osservati distribuire una msimg32.dll malevola capace di terminare oltre 300 driver EDR di praticamente ogni vendor sul mercato. Una analisi separata di The Hacker News ha catalogato 54 EDR killer che sfruttano la tecnica Bring-Your-Own-Vulnerable-Driver attraverso 35 driver firmati. Tutte mosse di "neutralizzazione dell'EDR" — l'EDR era un ostacolo, l'attaccante lo disabilitava prima della fase di cifratura.

Il DoS Defender di questa settimana appartiene a questa famiglia. Il bug Apex One no. Il bug Apex One tratta l'EDR come infrastruttura da sovvertire, non come sensore da silenziare. È lo stesso salto concettuale che l'industria ha fatto sulle pipeline CI/CD dopo SolarWinds e sulle software supply chain dopo event-stream su npm: il sistema difensivo smette di essere il muro e inizia a essere il cavallo di Troia.

Classe	Cosa vuole l'attaccante	Esempio 2026
Evasione EDR	Code execution senza alert	Abuso anti-rootkit via BYOVD
Neutralizzazione EDR	Silenziare la telemetria prima della cifratura	Killer 300+ driver Qilin/Warlock, DoS Defender CVE-2026-45498
Sovversione EDR	Usare il management plane come canale di distribuzione malware	Iniezione agent Apex One CVE-2026-34926

La progressione è monodirezionale. Ogni gradino in alto è più difficile da rilevare perché ogni gradino assomiglia di più al comportamento normale del prodotto.

Perché la detection endpoint-only non basta

Il problema strutturale non riguarda solo Defender o Apex One. Vale per ogni stack di sicurezza endpoint-resident:

• Se l'agent è silenziato (DoS), il SIEM smette di ricevere eventi da quell'host. La maggior parte dei pipeline di detection non distingue tra "host silenzioso perché non è successo nulla" e "host silenzioso perché l'agent è stato mutato". Entrambi appaiono verdi.
• Se l'agent è sovvertito (pattern Apex One), il log stream dell'agent è ora prodotto dall'attaccante. La telemetria endpoint diventa input adversariale invece di ground truth.
• Se l'agent gira come SYSTEM e l'attaccante ottiene SYSTEM via LPE, non c'è più un privilege boundary che l'agent possa applicare. Le protezioni anti-tamper scritte in user space vengono bypassate per definizione.

"L'EDR ha intercettato il lateral movement." — quello che ogni cliente vuole sentirsi dire dopo un incidente.

"L'EDR era il lateral movement." — quello che queste tre CVE rendono plausibile.

La risposta difensiva non è "comprate un EDR migliore". È duplice: mantenere un canale di detection che non dipenda dall'endpoint, e validare in continuo la piattaforma di endpoint security stessa come target — non come sensore.

Il primo lato è wire-side. La rete non mente su ciò che l'ha attraversata. Un agent push cifrato che inietta codice in migliaia di endpoint gestiti emette comunque un pattern di traffico: un burst di payload identici in uscita dal server di management, una temporizzazione di fan-out che corrisponde all'inventario degli agent, spesso un picco corrispondente di primitivi di process creation sugli endpoint che trapela brevemente prima che il muting si completi. Una deep-packet machine learning che gira out-of-band — su un'appliance separata, non sull'host sotto attacco — vede quel pattern in tempo reale. Il SIEM no, perché il SIEM è alimentato dall'endpoint compromesso.

Il secondo lato è la validazione offensiva continua dello stack di sicurezza. La maggior parte degli scope di pentest esclude esplicitamente l'EDR ("non testate l'EDR, sballate il tuning del SOC"). Quella esclusione è esattamente il gap in cui vivono queste CVE. Se l'EDR non è mai stato in scope, l'EDR non è mai stato testato.

Cosa dovrebbero chiedersi i CISO questa settimana

Tre domande che vale la pena portare al prossimo risk committee:

• Quando è stata l'ultima volta che la nostra piattaforma endpoint security è stata testata come target, non come sensore? Se la risposta è "mai" o "durante il POC iniziale tre anni fa", quello è il gap. Il threat model del vendor non è il vostro threat model.
• Se i nostri agent endpoint fossero mutati per le prossime 72 ore, cosa vedremmo comunque? Se l'unica risposta è "niente di significativo", il programma di detection ha un single point of failure che le KEV di questa settimana hanno appena trasformato da teorico a forzato-da-deadline-federale.
• Il nostro clock di incident reporting parte quando l'EDR lancia l'alert, o quando il compromesso effettivamente comincia? L'incident reporting NIS2 e la finestra di classificazione di 4 ore di DORA partono entrambi dal momento in cui l'operatore sapeva o avrebbe dovuto sapere. "L'EDR non ce lo ha detto" non è una difesa — i regolatori si aspettano ora flussi di evidenza paralleli.

Per le istituzioni in scope DORA TLPT secondo l'RTS adottato nel 2025, l'obbligo è più esplicito: il threat-led penetration testing deve coprire end-to-end le funzioni critiche e importanti. Una piattaforma di endpoint security che decide quali alert raggiungono il SOC qualifica sia come critica sia come importante.

Come Zero Hunt chiude il gap

La domanda difensiva che le aggiunte KEV di questa settimana costringono a porsi è: "Chi valida che lo strumento di validazione funzioni ancora, contro attacchi che lo strumento di validazione non ha mai visto?" È il design centre del pillar di generative pentest di Zero Hunt.

Lo swarm AI a 10 agent — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, più un AI Controller orchestratore — tratta ogni asset sul perimetro come target, inclusa la piattaforma di endpoint security stessa. Gli exploit sono generati per-target da un LLM locale, non pescati da ExploitDB, quindi la validazione non è limitata a ciò che è già pubblico. Le 142+ skill di sicurezza self-evolving in AI Gym sono backtestate contro Vulhub (316/317 esercizi su 16 classi di vulnerabilità), NYU CTF Bench (200 task CSAW, 129 networked), Cybench e Vulhub-Bench (314 task black-box CVE-based) prima che una skill tocchi un ambiente di produzione — così i primitivi di directory-traversal, link-following e abuso di management plane sono nel corpus prima che la prossima CVE classe Apex One diventi notizia.

Quando l'endpoint non è affidabile, il pillar di AI Traffic Analysis gira out-of-band. Un modello deep-learning proprietario con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione tipo di attacco, application fingerprinting — sostiene 2.7+ Gbit/s sulla GPU dell'appliance. Vede il fan-out dell'agent push, il callback C2, il lateral movement mentre avvengono, non nel digest SIEM della mattina dopo, e non tramite un sensore che l'attaccante può aver già silenziato.

Ogni finding è firmato ECDSA al momento della scrittura e mappato sui 32 framework di compliance (NIS2 Titolo 13, DORA TLPT RTS 2025, ISO 27001, SOC 2, PCI-DSS, HIPAA, NIST CSF e altri 25). La catena di audit non dipende dai log dell'EDR — il che, dopo questa settimana, è esattamente il punto.

L'appliance è 100% on-prem. Nessun callback cloud, nessuna telemetria, nessuna API LLM esterna. Air-gap supportato. Lo strumento di validazione è esso stesso fuori dalla superficie d'attacco che sta validando. Quella proprietà — separazione del tester dal sistema in test — è la risposta strutturale alla domanda che questa settimana sta facendo a voce alta.