GhostLocker: Neutralizzazione EDR basata su AppLocker

Introduzione

Dopo il mio articolo su Fairy-Law, in cui ho utilizzato mitigazioni del kernel per disabilitare le soluzioni Endpoint Detection & Response (EDR), diversenok ha osservato che le esclusioni IFEO (Image File Execution Options) erano troppo invasive per le applicazioni di terze parti. Questo ha portato a un approccio migliore: sfruttare il potere intrinseco che gli amministratori già possiedono tramite AppLocker.

Il concetto è stato ispirato da diversenok, che ha sottolineato come gli amministratori possano legittimamente controllare qualsiasi software sui propri sistemi. Da questa intuizione, ho sviluppato una tecnica che utilizza AppLocker come meccanismo di controllo nativo di Windows. Questa ricerca esplora l'implementazione tecnica di AppLocker per il controllo degli EDR, confrontandola con WDAC e presentando un proof-of-concept pratico.

---

AppLocker: Architettura di whitelisting delle applicazioni

AppLocker è stato introdotto con Windows 7 e migliorato in Windows 8.1, 10 (Enterprise) e Windows Server 2012/R2/2016+. È un framework di whitelisting delle applicazioni che consente agli amministratori di definire con precisione quali eseguibili, script o installer possono essere eseguiti da specifici utenti o gruppi.

Architettura interna (prospettiva Windows Internals)

Componenti user-mode e kernel:

AppIDSvc (Application Identity Service)

• Viene eseguito con l'account LocalService
• Monitora le modifiche al registro relative ai percorsi delle policy AppLocker
• Traduce le definizioni di regole basate su XML in SDDL binario (Security Descriptor Definition Language)
• Comunica gli aggiornamenti delle policy al driver del kernel tramite DeviceIoControl

AppID.sys (Driver del kernel)

• Intercetta gli eventi di creazione dei processi tramite meccanismi di callback
• Esegue la valutazione delle regole utilizzando SeSrpAccessCheck
• Opzionalmente monitora i caricamenti di DLL (disattivato di default per motivi di prestazioni)

Chiarimento:
Mentre AppID.sys esegue la valutazione delle regole in modalità kernel, l'applicazione delle regole sulle DLL non è autonoma.
Il driver del kernel non monitora attivamente i caricamenti di DLL da solo. Invece, i componenti user-mode devono interrogare esplicitamente il driver tramite IOCTL per determinare se un caricamento di DLL è consentito.
Di conseguenza, le regole DLL di AppLocker agiscono di fatto come un meccanismo di protezione lato client.

Tipi di regole e applicazione

AppLocker supporta due categorie principali di regole:

Regole Allow: consentono esplicitamente l'esecuzione delle applicazioni definite

Regole Deny: bloccano esplicitamente l'esecuzione delle applicazioni definite

• Le regole Deny hanno sempre precedenza sulle regole Allow
• Possono includere eccezioni per condizioni specifiche
• Supportano l'assegnazione a livello di utente e di gruppo

Criteri delle regole (attributi AppID):

• Regole basate sul percorso: C:\Program Files\Security\*.exe
• Regole basate su hash: validazione hash SHA256 Authenticode
• Regole basate sull'editore: verifica di firma digitale, versione, nome del prodotto
• Regole basate sugli attributi dei file: nome dell'azienda, versione del prodotto, ecc.

Posizioni di archiviazione nel registro:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (archiviazione policy XML, persistente)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (formato binario SDDL, applicazione attiva)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (cache dei certificati)

Applicazione per i servizi e i processi SYSTEM (spesso trascurata)

Per impostazione predefinita, AppLocker non applica le regole ai servizi o ai processi SYSTEM.
Non esiste un'opzione dell'interfaccia grafica per abilitare questo comportamento.

L'applicazione per i servizi può essere abilitata solo tramite la policy XML utilizzando RuleCollectionExtensions.

La seguente sezione di policy è necessaria per applicare le regole AppLocker ai servizi:

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

Come indicato dai nomi delle estensioni, queste opzioni sono supportate solo su Windows 10+ e non sono disponibili nelle versioni precedenti. Vedi Microsoft - AppLocker rule collection extensions

Flusso di applicazione:

1. Windows notifica al driver AppID la creazione del processo
2. AppID.sys valuta gli attributi dell'applicazione
3. In base alle regole AppLocker, consente o blocca il processo
4. Se bloccato, la creazione del processo viene interrotta con STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Limitazione critica:

⚠️ AppLocker NON termina i processi in esecuzione.

L'applicazione di AppLocker si riferisce solo a nuovi eventi di creazione di processi. I processi EDR già in esecuzione continuano a funzionare fino al riavvio del sistema. Questo è un vincolo architetturale fondamentale.

Nota sulla telemetria del driver del kernel:

Anche dopo aver bloccato gli eseguibili userland dell'EDR, i driver del kernel (*.sys) rimangono attivi e operativi. Questi driver continuano a:

• Registrare callback del kernel (processi, thread, caricamento immagini, registro)
• Raccogliere dati di telemetria
• Monitorare gli eventi di sistema

Tuttavia, test approfonditi rivelano che questa telemetria diventa funzionalmente inefficace. Senza motori di analisi userland, sistemi di correlazione e meccanismi di reporting, i dati di telemetria grezzi non possono essere trasformati in rilevamenti utilizzabili. Le soluzioni EDR dipendono fortemente dai componenti userland per:

• Correlazione degli eventi e analisi comportamentale
• Inferenza tramite machine learning
• Generazione di alert e orchestrazione della risposta
• Comunicazione con le console di gestione

---

GhostLocker: Implementazione proof-of-concept

Panoramica dello strumento

GhostLocker è un'implementazione in C++ che automatizza la distribuzione di policy AppLocker per bloccare gli eseguibili EDR.

Analisi dell'implementazione tecnica

Varianti di implementazione

GhostLocker fornisce due varianti di implementazione:

main.cpp – Versione con enumerazione dinamica

Questa versione enumera i processi in esecuzione e risolve i relativi percorsi completi dell'immagine utilizzando API native (NtQuerySystemInformation).
I percorsi assoluti risolti vengono quindi utilizzati per generare regole Deny AppLocker precise.

Lo strumento utilizza CreateToolhelp32Snapshot con TH32CS_SNAPPROCESS per enumerare tutti i processi in esecuzione. Confronta i nomi dei processi con un elenco predefinito di target utilizzando un confronto senza distinzione tra maiuscole e minuscole (_wcsicmp).

Perché questo approccio?

• Enumerazione leggera e veloce
• Nessun privilegio elevato richiesto per leggere l'elenco dei processi
• Il confronto senza distinzione tra maiuscole e minuscole gestisce le variazioni di denominazione

1. Enumerazione dei processi (FindTargetsAndQueryPaths)

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. Risoluzione del percorso tramite NtQuerySystemInformation

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;