GhostLocker: Neutralização de EDR Baseada em AppLocker

Introdução

Após meu artigo sobre Fairy-Law, onde usei mitigações em modo kernel para desabilitar soluções de Detecção e Resposta de Endpoint (EDR), diversenok apontou que as exclusões de IFEO (Image File Execution Options) eram invasivas demais para aplicações de terceiros. Isso levou a uma abordagem melhor: aproveitar o poder inerente que os administradores já possuem através do AppLocker.

O conceito foi inspirado por diversenok, que destacou que administradores podem controlar legitimamente qualquer software em seus sistemas. A partir dessa percepção, desenvolvi uma técnica usando o AppLocker como um mecanismo de controle nativo do Windows. Esta pesquisa explora a implementação técnica do AppLocker para controle de EDR, comparando-o com WDAC e apresentando uma ferramenta prática de prova de conceito.

AppLocker: Arquitetura de Lista de Permissões de Aplicativos

O AppLocker foi introduzido com o Windows 7 e aprimorado no Windows 8.1, 10 (Enterprise) e Windows Server 2012/R2/2016+. É uma estrutura de lista de permissões de aplicativos que permite aos administradores definir precisamente quais executáveis, scripts ou instaladores podem ser executados para usuários ou grupos específicos.

Arquitetura Interna (Perspectiva de Internals do Windows)

Componentes de Modo de Usuário e Kernel:

AppIDSvc (Serviço de Identidade de Aplicativo)

• Executa sob a conta LocalService
• Monitora alterações no registro nos caminhos da política do AppLocker
• Traduz definições de regras baseadas em XML para SDDL binário (Security Descriptor Definition Language)
• Comunica atualizações de política ao driver do kernel via DeviceIoControl

AppID.sys (Driver do Kernel)

• Intercepta eventos de criação de processo através de mecanismos de callback
• Realiza avaliação de regras usando SeSrpAccessCheck
• Opcionalmente monitora carregamentos de DLL (desabilitado por padrão por motivos de desempenho)

Esclarecimento:
Embora o AppID.sys realize a avaliação de regras em modo kernel, a aplicação de regras de DLL não é autônoma.
O driver do kernel não monitora ativamente os carregamentos de DLL por conta própria. Em vez disso, componentes em modo de usuário devem consultar explicitamente o driver via IOCTL para determinar se um carregamento de DLL é permitido.
Como resultado, as regras de DLL do AppLocker atuam efetivamente como um mecanismo de proteção no lado do cliente.

Tipos de Regras e Aplicação

O AppLocker suporta duas categorias principais de regras:

Regras de Permissão: Permitem explicitamente que aplicativos definidos sejam executados

Regras de Negação: Bloqueiam explicitamente que aplicativos definidos sejam executados

• Regras de negação sempre têm precedência sobre regras de permissão
• Podem incluir exceções para condições específicas
• Suportam direcionamento a nível de usuário e grupo

Critérios de Regra (Atributos AppID):

• Regras baseadas em caminho: C:\Program Files\Security\*.exe
• Regras baseadas em hash: Validação de hash SHA256 Authenticode
• Regras de editor: Assinatura digital, versão, verificação de nome de produto
• Regras de atributos de arquivo: Nome da empresa, versão do produto, etc.

Locais de Armazenamento no Registro:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (Armazenamento de política XML, persistente)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (Formato binário SDDL, aplicação ativa)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (Cache de certificados)

Aplicação em Serviços e Processos SYSTEM (Frequentemente Ignorada)

Por padrão, o AppLocker não aplica regras em serviços ou processos SYSTEM.
Não há opção de interface gráfica para habilitar esse comportamento.

A aplicação para serviços só pode ser habilitada via política XML usando RuleCollectionExtensions.

A seguinte seção de política é necessária para aplicar as regras do AppLocker em serviços:

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

Como indicado pelos nomes das extensões, essas opções são suportadas apenas no Windows 10+ e não estão disponíveis em versões anteriores. Consulte Microsoft - Extensões de coleção de regras do AppLocker

Fluxo de Aplicação:

1. O Windows notifica o driver AppID na criação do processo
2. AppID.sys avalia os atributos da aplicação
3. Com base nas regras do AppLocker, permite ou bloqueia o processo
4. Se bloqueado, a criação do processo é abortada com STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Limitação Crítica:

⚠️ O AppLocker NÃO finaliza processos em execução.

A aplicação do AppLocker se aplica apenas a eventos de criação de novos processos. Processos EDR já em execução continuam operando até a reinicialização do sistema. Esta é uma restrição arquitetural fundamental.

Ressalva sobre Telemetria de Drivers de Kernel:

Mesmo após bloquear os executáveis em modo de usuário do EDR, os drivers de kernel (*.sys) permanecem ativos e operacionais. Esses drivers continuam:

• Registrando callbacks do kernel (processo, thread, carregamento de imagem, registro)
• Coletando dados de telemetria
• Monitorando eventos do sistema

No entanto, testes extensivos revelam que essa telemetria se torna funcionalmente ineficaz. Sem os mecanismos de análise em modo de usuário, sistemas de correlação e relatórios, os dados brutos de telemetria não podem ser processados em detecções acionáveis. As soluções EDR dependem fortemente de componentes em modo de usuário para:

• Correlação de eventos e análise comportamental
• Inferência de aprendizado de máquina
• Geração de alertas e orquestração de resposta
• Comunicação com consoles de gerenciamento

GhostLocker: Implementação de Prova de Conceito

Visão Geral da Ferramenta

GhostLocker é uma implementação em C++ que automatiza a implantação de políticas do AppLocker para bloquear executáveis de EDR.

Análise da Implementação Técnica

Variantes de Implementação

O GhostLocker fornece duas variantes de implementação:

main.cpp – Versão de Enumeração Dinâmica

Esta versão enumera os processos em execução e resolve seus caminhos completos de imagem usando APIs nativas (NtQuerySystemInformation).
Os caminhos absolutos resolvidos são então usados para gerar regras de negação precisas do AppLocker.

A ferramenta usa CreateToolhelp32Snapshot com TH32CS_SNAPPROCESS para enumerar todos os processos em execução. Ela compara os nomes dos processos com uma lista de alvos predefinida usando correspondência sem diferenciação de maiúsculas/minúsculas (_wcsicmp).

Por que essa abordagem?

• Enumeração leve e rápida
• Nenhum privilégio elevado necessário para ler a lista de processos
• A correspondência sem diferenciação de maiúsculas/minúsculas lida com variações de nomenclatura

1. Enumeração de Processos (FindTargetsAndQueryPaths)

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

2. Resolução de Caminho via 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
);

Detalhes Técnicos:

• Usa a classe de informação não documentada SystemProcessIdInformation (0x58)
• Retorna formato de caminho de dispositivo NT: \Device\HarddiskVolume3\Windows\System32\...
• Requer conversão para formato de caminho Win32 para compatibilidade com AppLocker

Lógica de Conversão de Caminho:

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;
}

Limitação: Suposição codificada de HarddiskVolume3. Deve ser melhorado para resolver dinamicamente os números de volume.

3. Geração de Política PowerShell

A ferramenta incorpora um script PowerShell completo que:

a) Valida Caminhos Alvo

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

b) Gera Regras de Negação Dinâmicas

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>'
}

Elementos Chave da Política:

• UserOrGroupSid="S-1-1-0": Aplica-se a Todos (todos os usuários)
• Action="Deny": Regra de bloqueio explícita
• EnforcementMode="Enabled": Aplicação ativa para regras EXE
• Regras de negação inseridas antes das regras de permissão de fallback (precedência)

c) Aplicação da Política

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

4. Codificação Base64 e Execução

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);
}

Fundamentação Técnica:

• Codificação UTF-16LE: O PowerShell -EncodedCommand espera UTF-16LE
• Codificação Base64: Ignora restrições de caracteres na linha de comando
• -ExecutionPolicy Bypass: Ignora a política de execução de scripts
• Verbo runas: Aciona a elevação UAC para direitos administrativos

main_improved.cpp – Versão Estática Baseada em Caracteres Curinga

Após esclarecimento do diversenok, ficou claro que as regras de caminho do AppLocker suportam correspondência com caracteres curinga e não exigem caminhos completos de executáveis.

Esta versão melhorada remove toda a enumeração de processos e lógica de resolução de caminho nativo e, em vez disso, depende de regras curinga estáticas como: *\MsMpEng.exe

Requisitos

⚠️ Pré-requisitos para Implantação Bem-Sucedida:

• Deve ser executado a partir de um contexto elevado (Administrador)
• O serviço AppIDSvc deve estar em execução: sc start AppIDSvc
• Reinicialização do sistema necessária após a implantação para eficácia total
• Os processos EDR alvo devem estar em execução durante a fase de enumeração

Resultados da Pesquisa: Testes com EDR do Mundo Real

Metodologia de Teste

Testes controlados extensivos foram conduzidos contra múltiplas soluções comerciais de EDR para avaliar a eficácia.

Ambiente de Teste:

• Windows 11 (25H2)
• Múltiplos produtos comerciais de EDR (nomes omitidos)
• Detecção de linha de base: técnicas simples de injeção de processo
• Verificação pré-teste: capacidades de detecção de EDR confirmadas

Principais Descobertas

Capacidades de Detecção Pós-Bloqueio

Falha na Análise Comportamental:

• Todas as soluções EDR testadas falharam em gerar alertas após o bloqueio do AppLocker
• Injeções simples previamente detectadas não foram detectadas
• Nenhuma detecção comportamental foi acionada para atividades suspeitas

Perspectiva do Console de Gerenciamento:

• Os agentes continuaram reportando como "online" e "protegidos"
• Os timestamps de última visualização foram atualizados normalmente
• Nenhuma indicação de comprometimento a partir da interface de gerenciamento

Análise de Telemetria do Driver de Kernel

Apesar dos drivers de kernel continuarem executando e coletando fluxos de dados de telemetria, a ausência de componentes de processamento em modo de usuário tornou os dados coletados ineficazes.

O Que Continua Funcionando:

• Os callbacks do kernel disparam normalmente (processo, thread, carregamento de imagem, registro, etc.)
• A coleta de dados brutos de telemetria persiste
• A comunicação driver-para-driver pode funcionar

Insight Crítico:

A arquitetura moderna de EDR depende de um acoplamento estreito entre drivers de kernel e mecanismos de análise em modo de usuário. Quebrar esse acoplamento efetivamente cega o EDR apesar da coleta contínua de telemetria.

Captura de tela (Enumerando e aplicando a Política AppLocker):

Captura de tela (WinDefend Desativado):

Captura de tela da Versão 2

Comparação: WDAC vs. AppLocker

O que é WDAC?

O Windows Defender Application Control (WDAC) foi introduzido no Windows 10 e representa a estrutura moderna de controle de aplicativos da Microsoft. Ele aplica políticas em binários tanto em modo de usuário quanto em modo kernel.

Arquitetura WDAC:

Características Principais:

• Aplicação em todo o sistema (todos os usuários, todas as sessões)
• Aplicação pré-inicialização
• Modelo de negação padrão
• Mecanismo de política de Integridade de Código (CI)
• Exigência de assinatura de driver de kernel

Armazenamento de Política WDAC:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (Política ativa, assinada)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (Múltiplas políticas)
Partição do Sistema EFI (Aplicação UEFI)

WDAC como Vetor de Ataque: Krueger

Krueger demonstrou o abuso do WDAC para bloqueio de drivers de EDR:

Diferença Chave:

• WDAC bloqueia no momento do carregamento do driver (kernel)
• AppLocker bloqueia no momento da criação do processo (modo de usuário)

Matriz de Comparação Detalhada

Considerações Práticas de Ataque

Quando Usar AppLocker (GhostLocker):

• O objetivo é apenas o bloqueio de processos em modo de usuário
• Deseja manter a telemetria do driver de kernel (menos suspeito)
• Precisa de políticas com escopo de usuário para bloqueio direcionado

Quando Usar WDAC (estilo Krueger):

• Precisa de bloqueio completo no nível do driver
• O alvo não possui aplicação WDAC

Orientação de Detecção e Prevenção

1. Avaliação de Política Pré-Execução

O Windows fornece a API Get-AppLockerFileInformation, que permite testar se um executável específico seria bloqueado sob a política atual do AppLocker.

Um EDR pode usar este mecanismo para verificar proativamente se seus próprios binários ou serviços seriam negados após uma alteração de política.
Se um componente principal transitar de permitido para negado, isso deve ser tratado como uma condição de adulteração de alta confiança.

2. Monitoramento de Alterações na Política do AppLocker

As atualizações da política do AppLocker são comunicadas ao AppID.sys via chamadas IOCTL explícitas do modo de usuário.
Isso fornece um caminho de sinal claro indicando que o estado de aplicação mudou.

Drivers de kernel podem observar essas notificações e correlacioná-las com falhas de execução subsequentes de serviços protegidos, permitindo a detecção precisa de neutralização baseada em política.

3. Persistência e Correlação de Reinicialização

As políticas do AppLocker são persistidas entre reinicializações em locais bem definidos do registro.
As soluções EDR podem capturar o estado relevante da política antes da reinicialização e verificar a consistência da aplicação após a inicialização do sistema.

Uma incompatibilidade entre o estado de execução esperado e a aplicação pós-reinicialização indica fortemente uma manipulação intencional da política.

4. Mecanismos de Exclusão Integrados

O Windows inclui mecanismos nativos para excluir processos da aplicação SRP/AppLocker.
Espera-se que os produtos de segurança se integrem a esses mecanismos para garantir a continuidade operacional.

A falha em considerar essas exclusões não é uma limitação do AppLocker, mas sim uma omissão arquitetural no produto protegido.

Resumo

Nenhuma dessas estratégias de detecção requer a contornar o AppLocker ou violar os limites de segurança do Windows.
Elas dependem exclusivamente de comportamento documentado e interfaces já fornecidas pelo sistema operacional.

Conclusão

GhostLocker demonstra que o AppLocker, um recurso legítimo de segurança do Windows, pode ser instrumentalizado para neutralizar soluções EDR através do bloqueio de processos em modo de usuário. Esta pesquisa destaca vulnerabilidades arquiteturais fundamentais nos designs atuais de EDR que acoplam fortemente a coleta de telemetria do kernel com mecanismos de análise em modo de usuário.

Principais Conclusões:

1. Eficácia do AppLocker: Bloqueia com sucesso processos em modo de usuário de EDR de múltiplos fornecedores
2. Vulnerabilidade Arquitetural: Drivers de kernel continuam executando, mas tornam-se funcionalmente cegos sem o processamento em modo de usuário
3. Cegueira de Detecção: EDRs testados mostraram falha completa de detecção pós-bloqueio
4. Engano do Console de Gerenciamento: Agentes aparecem "online" e "protegidos" apesar do comprometimento
5. Técnica Nativa do Sistema: Usa recursos legítimos do Windows

Para uma futura implementação em C#:

• Execução em memória pura .NET (melhor OPSEC)
• Uso direto de APIs sem dependências do PowerShell

Aviso Legal

Esta pesquisa é fornecida apenas para fins educacionais e de segurança defensiva. As técnicas descritas devem ser usadas apenas em ambientes de teste autorizados com permissão explícita.

Referências e Leitura Adicional

• Windows Internals, Part 1 & 2 (7th Edition)
• Referência Técnica do AppLocker
• Guia de Design do WDAC
• Krueger: Ferramenta de Abuso do WDAC

Contribuições da Comunidade Bem-Vindas

Se você estiver interessado em contribuir para o GhostLocker, especialmente para a implementação em C#, você é muito bem-vindo.