Una proof of concept chiamata EDR-Freeze dimostra che i componenti di Windows Error Reporting (WER) possono essere usati per mettere in stato di sospensione processi di sicurezza endpoint sfruttando MiniDumpWriteDump e sospendendo il dumper stesso. La tecnica non richiede driver né exploit kernel, ma richiede privilegi elevati e lascia artefatti osservabili che i difensori possono rilevare se la telemetria è adeguata.

EDR-Freeze è una PoC che coordina la creazione di dump tramite il sistema di error reporting di Windows per bloccare l’esecuzione di un agente di sicurezza. Invece di ricorrere a driver vulnerabili o esecuzione in kernel, la PoC utilizza un componente firmato di sistema (WerFaultSecure.exe) insieme a MiniDumpWriteDump per sospendere il processo target e poi sospendere il processo che dovrebbe ripristinarlo, mantenendo quindi l’agente in uno stato di “pausa”. La fattibilità pratica dipende da privilegi sulla macchina e dall’ambiente operativo.

Come funziona l’Exploit

  1. Selezione del target e privilegi necessari.
    L’attaccante deve poter eseguire codice con diritti sufficienti per invocare WER contro un altro processo e per sospendere processi. In pratica ciò richiede SeDebugPrivilege o capacità equivalenti per aprire e manipolare handle e thread di altri processi. Senza privilegi elevati l’attacco non riesce.
  2. Invoker: WerFaultSecure + MiniDumpWriteDump.
    WerFaultSecure.exe è parte del Windows Error Reporting e, in alcune configurazioni, è in grado di generare dump per processi ad alta integrità o protetti perché viene eseguito come Protected Process Light (PPL). La routine tipicamente utilizzata è MiniDumpWriteDump (esportata da dbghelp.dll), che sospende tutti i thread del processo target per catturare uno snapshot coerente della memoria e poi riprende l’esecuzione. Normalmente la sospensione è temporanea (frazione di secondo).
  3. Creazione della race / mantenere il target sospeso.
    L’elemento chiave è: durante la creazione del dump i thread del target sono sospesi; la PoC sospende il dumper (WerFaultSecure) dopo che ha sospeso il target ma prima che possa riprenderlo. Con WerFaultSecure sospeso, non può completare l’operazione di ripristino: il processo target rimane bloccato in stato di Suspended indefinitamente fino a ripresa manuale, riavvio o kill. La PoC implementa logiche di monitoraggio e timing per ottenere questo stato in modo affidabile.
  4. Risultati e limitazioni pratiche.
    • Il processo target non viene terminato: è semplicemente fermo.
    • La ripresa riporta il comportamento normale — un riavvio o la riattivazione del processo lo riporta operativo.
    • È una tecnica situazionale: richiede privilegi e orchestrazione precisa, quindi è più un primitivo di elusione che un vettore di attacco efficace su larga scala.

Artefatti osservabili e opportunità di detection

Dal momento che la tecnica sfrutta componenti di sistema firmati, la strategia difensiva si basa su comportamento e correlazione di telemetria più che su firme statiche. Artefatti utili sono:

  • Command line di WerFaultSecure e tempistiche di invocazione. Invocazioni legittime del WER sono tipicamente correlate a crash. Esecuzioni di WerFaultSecure.exe con argomenti espliciti (/pid, /encfile, ecc.) contro PID di agenti, fuori da un contesto di crash, sono sospette.
  • Processi in stato Suspended. API e strumenti riportano lo stato dei thread/processi. Un agente di sicurezza che resta sospeso oltre la finestra temporale attesa per un dump è un indicatore.
  • Eventi di accesso al processo. Chiamate che aprono handle con PROCESS_SUSPEND_RESUME o uso di SeDebugPrivilege da binari non usuali sono segnali rilevanti. Sysmon (Event ID di ProcessAccess) e ProcessCreate aiutano a ricostruire la catena: dumper lanciato → accesso/sospensione del dumper.
  • Lacune di telemetria / perdita del “heartbeat”. Se la telemetria dell’agente cessa contemporaneamente alla comparsa del dumper, la correlazione temporale è un’evidenza ad alta fedeltà.

Questi segnali, opportunamente correlati, consentono di distinguere attività legittime da abusi.

Mitigazioni concrete

Di seguito alcune raccomandazioni specifiche e implementabili nella maggior parte degli ambienti enterprise; sono intenzionalmente focalizzate per ridurre i falsi positivi e per consentire azioni automatiche limitate.

  1. Regola Sysmon: alert su WerFaultSecure con argomenti di dump
    • Monitorare Image = C:\Windows\System32\WerFaultSecure.exe con CommandLine che corrisponde a (?i)/pid\s+\d+|/encfile. Escludere processi parent standard (svchost.exe, services.exe) secondo baseline locale. Al match, generare allarme per indagine.
  2. Rilevamento di processi Suspended a lunga durata e rimedio automatico
    • Implementare uno script/azione dell’agent: ogni minuto enumerare i PID degli agent protetti; se lo stato thread/process riportato indica Suspended per >30 secondi senza crash registrato, lanciare un tentativo di restart controllato del servizio o un job di remediation che logga evento, invia allarme e riavvia l’agente. Questo riduce la finestra sfruttabile.
  3. Limitare e monitorare SeDebugPrivilege
    • Tramite GPO, PAM o controlli LAPS, assicurarsi che SeDebugPrivilege sia concesso solo ad account amministrativi noti e a servizi attesi. Loggare e allertare su acquisizioni di questo privilegio da parte di eseguibili anomali.
  4. Hardening del percorso di invocazione di WER (WDAC/AppLocker)
    • Applicare policy WDAC o una regola AppLocker che limiti quali binari o contesti possono lanciare WerFaultSecure.exe con argomenti non standard. Se WDAC è impraticabile, definire una regola AppLocker che blocchi esecuzioni non autorizzate del dumper.
  5. Regola di correlazione SIEM ad alta fedeltà
    • Sequenza da implementare: WerFaultSecure ProcessCreate → agente diventa Suspended → agente manca il heartbeat entro 5–15 secondi = escalation SOC. Questa correlazione riduce falsi positivi.

Indicatori di compromissione

2054a0866411f22a98c3fedc200d6947facdd6046a5e51ec9109380ef0cf2dd1
d989ebd417e6fae60a544e43bfc0ee63f5d9352ce0059b95ed4e7e18efbc5d0b
8819d5a64d7b95314630ed54156240c855e570b94bc01a88357e626615221858
1fa74c9be827171bfff81757130dbd1f1f79436199b4c4955410cf241e2b7a88
222649815d204ce19f652b3b57c81ddda3182f7a2851b9e4166d9160b2954d13
69e9b4ef471fb1ed719a44fe0a4e5aff5b341ee5a81d22cb3c57020d76a83f04
e2b2dd0984e52112965392471f6a09020eb8380aa53d48d2fb4dd3aaa7edae9b

Note finali

EDR-Freeze è una dimostrazione mirata che riutilizza un comportamento legittimo del sistema operativo in modo non previsto. Non è un rootkit kernel né un payload persistente, ma evidenzia come la fiducia nei componenti di sistema possa essere sfruttata in scenari con privilegi elevati. Con telemetria adeguata e regole comportamentali mirate, tecniche come questa possono essere rilevate e mitigate.

Ti è piaciuto l’articolo? Seguici su Linkedin per sostenerci!

consigliati