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