Kernel ETW é o melhor ETW

Preâmbulo

Um recurso crítico do software seguro por design é a geração de logs de auditoria quando operações privilegiadas são executadas. Esses logs de auditoria nativos podem incluir detalhes do estado interno do software, o que é impraticável para fornecedores de segurança terceirizados adicionarem posteriormente.

A maioria dos componentes do Windows gera logs usando o Rastreamento de Eventos para Windows (ETW). Esses eventos expõem parte do funcionamento interno do Windows, e há cenários em que os produtos de segurança de endpoint se beneficiam da assinatura deles. Por questões de segurança, porém, nem todos os provedores de ETW são criados iguais.

A primeira consideração normalmente é a confiabilidade do próprio provedor de eventos — em particular, onde o registro acontece. Está dentro do processo do cliente e é trivialmente vulnerável à adulteração do ETW? Ou talvez seja um pouco mais seguro em um processo de servidor RPC? O ideal, porém, é que a telemetria venha do kernel. Dado o limite de segurança do usuário para o kernel, isso fornece garantias antiviolação mais fortes em relação à telemetria em processo. Esta é a abordagem recomendada pela Microsoft. Assim como o Elastic Endpoint, o Microsoft Defender for Endpoint também usa o kernel ETW em vez de ganchos frágeis do modo de usuário ntdll .

Por exemplo, um adversário pode ser capaz de evitar facilmente um gancho de modo de usuário em processo em ntdll!NtProtectVirtualMemory, mas ignorar um evento PROTECTVM ETW do kernel é significativamente mais difícil. Ou, pelo menos, deveria ser.

O Log de Eventos de Segurança é efetivamente apenas um armazenamento persistente para os eventos do provedor ETW Microsoft-Windows-Security-Auditing. Surpreendentemente, o Evento de Segurança 4688 para criação de processo não é um evento do kernel. O kernel envia os dados para o serviço Autoridade de Segurança Local (lsass.exe), emitindo um evento ETW para o Log de Eventos consumir. Portanto, os dados podem ser adulterados dentro desse processo do servidor. Compare isso com o evento ProcessStart do provedor Microsoft-Windows-Kernel-Process, que é registrado diretamente pelo kernel e requer privilégios de nível de kernel para interferir.

A segunda consideração é a confiabilidade das informações registradas. Você pode confiar na origem do evento, mas e se ela estiver apenas registrando cegamente dados fornecidos pelo cliente que são extrínsecos ao evento que está sendo registrado?

Neste artigo, vamos nos concentrar nos eventos ETW do kernel. Geralmente, elas são as mais relevantes em termos de segurança porque são difíceis de ignorar e geralmente dizem respeito a ações privilegiadas executadas em nome de um thread de cliente.

Quando a Microsoft introduziu o Kernel Patch Protection, os fornecedores de segurança ficaram significativamente limitados em sua capacidade de monitorar o kernel. Dado o número limitado de pontos de extensão do kernel fornecidos pela Microsoft, eles foram cada vez mais obrigados a confiar em eventos ETW assíncronos para visibilidade posterior das ações do kernel executadas em nome do malware.

Dada essa dependência, a documentação pública das fontes de telemetria do kernel do Windows é infelizmente um tanto esparsa.

Eventos do Kernel ETW

Atualmente, há quatro tipos de provedores de ETW que precisamos considerar.

Em primeiro lugar, existem variantes legadas e modernas de “provedor de eventos”:

• provedores de eventos legados (baseados em mof )
• provedores de eventos modernos (baseados em manifesto )

E então há variantes legadas e modernas de “provedor de rastreamento”:

• provedores de rastreamento do pré-processador de rastreamento de software Windows legado (WPP)
• provedores de rastreamento TraceLogging modernos

A distinção entre “evento” e “traço” é principalmente semântica. Os provedores de eventos geralmente são registrados no sistema operacional com antecedência, e você pode inspecionar os metadados de telemetria disponíveis. Eles geralmente são usados por administradores de sistema para fins de solução de problemas e geralmente são semidocumentados. Mas quando algo dá realmente muito errado, existem provedores de rastreamento (ocultos). Eles geralmente são usados apenas pelos autores originais do software para solução de problemas avançados e não são documentados.

Na prática, cada um usa um arquivo de formato ligeiramente diferente para descrever e registrar seus eventos, o que introduz pequenas diferenças em como os eventos são registrados e, mais importante, como os eventos potenciais podem ser enumerados.

Provedores de eventos do kernel moderno

Os provedores modernos de ETW do kernel não são estritamente documentados. No entanto, os detalhes do evento registrado podem ser consultados no sistema operacional por meio da API Trace Data Helper. A ferramenta PerfView da Microsoft usa essas APIs para reconstruir o manifesto de registro do provedor, e o EtwExplorer de Pavel Yosifovich então encapsula esses manifestos em uma GUI simples. Você pode usar esses arquivos de valores separados por tabulações de manifestos registrados de versões sucessivas do Windows. Uma única linha por evento é muito útil para grepping, embora outros tenham publicado os manifestos XML brutos.

No entanto, esses não são todos os eventos possíveis do Windows ETW. Eles são apenas aqueles registrados no sistema operacional por padrão. Por exemplo, os eventos ETW para muitas funções de servidor não são registrados até que esse recurso seja habilitado.

Provedores de eventos do kernel legado

Os eventos do kernel legado são documentados pela Microsoft. Majoritariamente.

Provedores legados também existem no sistema operacional como classes WMI EventTrace . Os provedores são as classes raiz, os grupos são os filhos e os eventos são os netos.

Para pesquisar eventos legados da mesma forma que eventos modernos, essas classes foram analisadas e o MOF original (em sua maior parte) reconstruído. Esse suporte MOF foi adicionado ao EtwExplorer, e resumos de valores separados por tabulação dos eventos legados onde essas classes foram analisadas e o MOF original (em sua maior parte) reconstruído. Esse suporte MOF foi adicionado ao EtwExplorer e resumos de valores separados por tabulações dos eventos legados foram publicados.

O MOF do Windows Kernel Trace totalmente reconstruído está aqui (ou em formato tabular aqui).

Dos 340 eventos legados registrados, apenas 116 foram documentados. Normalmente, cada evento legado precisa ser habilitado por meio de um sinalizador específico, mas isso também não foi documentado. Havia uma pista na documentação para os eventos de rastreamento do Gerenciador de Objetos do kernel. Ele mencionou PERF_OB_HANDLE, uma constante que não está definida nos cabeçalhos do SDK mais recente. Felizmente, Geoff Chappell e o Windows 10 1511 WDK vieram em nosso socorro. Essas informações foram usadas para adicionar suporte aos sinalizadores de rastreamento do kernel PERFINFO_GROUPMASK à biblioteca KrabsETW da Microsoft. Também descobrimos que a documentação do Object Trace estava errada. Essa constante não pública só pode ser usada com uma extensão de API não documentada. Felizmente, projetos públicos da Microsoft, como PerfView geralmente fornecem exemplos de como usar APIs não documentadas.

Com manifestos e MOFs publicados no GitHub, a maioria dos eventos do kernel agora pode ser encontrada com esta consulta.

Curiosamente, a Microsoft frequentemente ofusca os nomes de eventos relevantes para a segurança, então procurar por eventos com um prefixo de nome genérico como task_ produz alguns resultados interessantes.

Às vezes, a palavra-chave indica o propósito do evento. Por exemplo, task_014 em Microsoft-Windows-Kernel-General é habilitado com a palavra-chave KERNEL_GENERAL_SECURITY_ACCESSCHECK.

E, felizmente, os parâmetros quase sempre têm nomes bem definidos. Podemos supor que task_05 em Microsoft-Windows-Kernel-Audit-API-Calls está relacionado ao OpenProcess , pois ele registra campos chamados TargetProcessId e DesiredAccess.

Outra consulta útil é procurar eventos com um campo ProcessStartKey explícito. Os eventos ETW podem ser configurados para incluir esse campo no processo de registro, e qualquer evento que inclua essas informações para outro processo geralmente é relevante para a segurança.

Se você tivesse uma API específica em mente, você poderia consultar seu nome ou seus parâmetros. Por exemplo, se você quiser eventos de Pipe Nomeado, você pode usar esta consulta.

Neste caso, porém, Microsoft-Windows-SEC pertence aos drivers de segurança integrados da Microsoft que o Microsoft Defender for Endpoint (MDE) utiliza. Este provedor está oficialmente disponível apenas para MDE, embora Sebastian Feldmann e Philipp Schmied tenham demonstrado como iniciar uma sessão usando um AutoLogger e assinar os eventos dessa sessão. Atualmente, isso só é útil para usuários do MDE, pois, caso contrário, o driver não está configurado para emitir eventos.

Mas e os provedores de rastreamento?

Provedores de rastreamento de kernel modernos

Os metadados do TraceLogging são armazenados como um blob opaco dentro do binário de registro. Felizmente, esse formato foi revertido por Matt Graeber. Podemos usar o script de Matt para despejar todos os metadados do TraceLogging para ntoskrnl.exe. Um exemplo de dump de metadados do Windows 11 TraceLogging está aqui.

Infelizmente, a estrutura de metadados por si só não retém a correlação entre provedores e eventos. Há nomes de provedores interessantes, como Microsoft.Windows.Kernel.Security e AttackSurfaceMonitor, mas ainda não está claro em nosso despejo de metadados quais eventos pertencem a esses provedores.

Provedores de rastreamento de kernel legado

Os metadados do WPP são armazenados em arquivos de símbolos (PDBs). A Microsoft inclui essas informações nos símbolos públicos de alguns drivers, mas não de todos. O kernel em si, entretanto, não produz nenhum evento WPP. Em vez disso, o provedor de eventos legado do Windows Kernel Trace pode receber sinalizadores não documentados para habilitar os eventos legados de “rastreamento”, geralmente disponíveis apenas para desenvolvedores do kernel da Microsoft.

Próximas etapas

Agora temos metadados de eventos do kernel para cada um dos quatro tipos de provedores ETW, mas uma lista de eventos ETW é apenas nosso ponto de partida. Saber o provedor e a palavra-chave do evento pode não ser suficiente para gerar os eventos que esperamos. Às vezes, uma chave de registro de configuração adicional ou uma chamada de API é necessária. Na maioria das vezes, porém, precisamos apenas entender as condições exatas sob as quais o evento é registrado.

Saber exatamente onde e o que está sendo registrado é fundamental para realmente entender sua telemetria e suas limitações. E, graças aos descompiladores que estão se tornando cada vez mais disponíveis, temos a opção de fazer uma reversão apenas o suficiente. No IDA chamamos isso de “pressionar F5”. Ghidra é a alternativa de código aberto e suporta scripts… com Java.

Para o kernel ETW, estamos particularmente interessados em chamadas EtwWrite que podem ser acessadas por meio de chamadas de sistema. Queremos o máximo possível de informações sobre os parâmetros do local da chamada, incluindo qualquer informação de símbolo público associada. Isso significava que precisávamos percorrer o gráfico de chamadas, mas também tentar resolver os valores possíveis para parâmetros específicos.

Os parâmetros necessários foram RegHandle e EventDescriptor. O primeiro é um identificador opaco para o provedor, e o último fornece informações específicas do evento, como o ID do evento e suas palavras-chave associadas. Uma palavra-chave ETW é um identificador usado para habilitar um conjunto de eventos.

Melhor ainda, esses descritores de eventos normalmente eram armazenados em uma constante global com um símbolo público.

Tínhamos metadados de eventos suficientes, mas ainda precisávamos resolver o identificador opaco do provedor atribuído em tempo de execução de volta aos metadados sobre o provedor. Para isso, também precisamos das chamadas EtwRegister .

O padrão típico para provedores de eventos modernos do kernel era armazenar o GUID do provedor constante e o identificador de tempo de execução em globais com símbolos públicos.

Outro padrão encontrado foram chamadas para EtwRegister, EtwEwrite e EtwUnregister, todas na mesma função. Neste caso, aproveitamos a localidade para encontrar o GUID do provedor para o evento.

No entanto, os provedores modernos de TraceLogging não tinham símbolos públicos associados por provedor para fornecer uma dica da finalidade de cada provedor. No entanto, Matt Graeber reverteu o formato de metadados do TraceLogging e documentou que o nome do provedor é armazenado em um deslocamento fixo do GUID do provedor. Ter o nome exato do provedor é ainda melhor do que apenas o símbolo público que recuperamos para eventos modernos.

Restaram apenas os provedores legados. Eles não pareciam ter símbolos públicos nem blobs de metadados. Algumas constantes são passadas para uma função não documentada chamada EtwTraceKernelEvent que encapsula a eventual chamada de gravação ETW.

Essas constantes estão presentes nos cabeçalhos do Windows 10 1511 WDK (e nos cabeçalhos do System Informer ), então poderíamos rotular esses eventos com os nomes das constantes.

Este script foi atualizado recentemente para o Ghidra 11, juntamente com suporte aprimorado para eventos TraceLogging e Legacy. Agora você pode encontrá-lo no GitHub aqui - https://github.com/jdu2600/API-To-ETW

Exemplo de saída para o kernel do Windows 11 aqui.

Nossos eventos Microsoft-Windows-Kernel-Audit-API-Calls anteriormente anônimos são rapidamente desmascarados por este script.

Símbolo e função de contenção para eventos Microsoft-Windows-Kernel-Audit-API-Calls

Com o caminho da chamada e as informações dos parâmetros recuperados pelo script, também podemos ver que o evento SECURITY_ACCESSCHECK anterior está associado à API do kernel SeAccessCheck , mas registrado apenas em uma função chamada SeLogAccessFailure. Somente condições de falha de registro são uma ocorrência muito comum com eventos ETW. Para fins de solução de problemas, o caso de uso original do ETW, geralmente, é o mais útil e a implementação na maioria dos componentes reflete isso. Infelizmente, por questões de segurança, o inverso geralmente é verdadeiro. Os registros de operações bem-sucedidas geralmente são mais úteis para encontrar atividades maliciosas. Portanto, o valor de alguns desses eventos legados geralmente é baixo.

A prática moderna de Secure by Design é auditar o registro de sucessos e falhas de atividades relevantes para a segurança, e a Microsoft continua adicionando novos eventos ETW relevantes para a segurança que fazem isso. Por exemplo, a versão de visualização do Windows 11 24H2 inclui alguns novos eventos ETW interessantes no provedor Microsoft-Windows-Threat-Intelligence . Esperamos que isso seja documentado para fornecedores de segurança antes do lançamento.

A execução deste script descompilador em drivers interessantes do Windows e DLLs de serviço é deixada como um exercício para o leitor.