Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Ho lavorato per diversi anni come System Engineer e uno dei compiti che ho svolto è stata la gestione di Citrix PVS. Uno dei problemi con PVS era l’analisi dei file di dump. L’unico modo per generare un file di dump completo era utilizzare l’ opzione DedicatedDumpFile, disponibile come chiave di registro in HKLMSYSTEMCurrentControlSetControlCrashControl.
Un ostacolo significativo quando il file DedicatedDumpFile è abilitato e configurato è la sua eliminazione, poiché è sempre in uso da parte di un processo.
Il crash dump viene creato dal kernel di Windows (ntoskrnl.exe) in collaborazione con il driver Crashdmp.sys. Per garantire che il file sia sempre contiguo, non frammentato e disponibile al momento del crash, il kernel lo mantiene aperto e riservato mentre il sistema è in esecuzione.
Ora, cosa succede se il valore della chiave di registro DedicatedDumpFile non è un file .dmp?
Per impostazione predefinita, Windows non verifica se il valore della chiave punta a un file .dmp. Se inseriamo il percorso di un file .exe (ad esempio, EDR.exe) nella chiave DedicatedDumpFile , Windows aprirà il file all’avvio, causando l’utilizzo del file .exe.
Questo può causare il crash di un processo protetto, come un EDR? Certo che sì.
Ho creato un semplice script PowerShell che aggiunge la chiave DedicatedDumpFile con il valore di un percorso .exe (EDRService.exe).
Come puoi vedere nell’immagine sottostante, la chiave è stata aggiunta correttamente.
Naturalmente è necessario un riavvio perché la chiave venga aggiunta in HKLM .
Dopo il riavvio, come accennato in precedenza, il processo EDR non può essere avviato perché il servizio è in uso.
Ora siamo in grado di eseguire le azioni desiderate senza l’interazione dell’EDR.
Questa tecnica è stata testata su otto EDR e solo uno di essi l’ha bloccata, non a causa di DedicatedDumpFile, ma perché controlla se una chiave di registro è scritta con il suo nome.
