
Ferramenta que coleta um conjunto personalizável de telemetria ETW e gera detecções definidas pelo usuário.
EventHorizon é uma ferramenta destinada a capacitar analistas e/ou pesquisadores de segurança com telemetria de Event Tracing for Windows (ETW) que, combinada com regras similares às do sigma, permite capacidades robustas de detecção e resposta em endpoints. Dito isso, o EventHorizon não substitui, de forma alguma, soluções adequadas. Este projeto visa principalmente permitir facilidade de uso na coleta de telemetria ETW, bem como na geração de regras de detecção sem a necessidade de escrever código. Para aumentar essa facilidade de uso, o processo de configuração do EventHorizon foi projetado para ser o mais simples possível, com um instalador .msi fornecido (consulte a guia de lançamentos) e instruções básicas de instalação (consulte o wiki).
[!WARNING]
Use o EventHorizon apenas em um ambiente de teste (NÃO EM PRODUÇÃO). A instalação exige que certos recursos de segurança do Windows sejam desabilitados, e eu não garanto que o EventHorizon seja um software seguro ou profissionalmente escrito.
Para começar, acesse o EventHorizon Wiki
Embora não possa prometer que manterei o EventHorizon, no futuro gostaria de adicionar/alterar algumas coisas:
O EventHorizon consiste em vários componentes distribuídos entre o modo de usuário e o modo kernel. As seções a seguir visam fornecer uma visão geral detalhada dos componentes e uma ideia geral do que eles fazem.
No que diz respeito ao modo de usuário no EventHorizon, há um único serviço chamado EventHorizon que serve para orquestrar os outros vários componentes do modo de usuário do EventHorizon. Os arquivos relacionados à funcionalidade do modo de usuário estão localizados em C:\Program Files\EventHorizon\, embora esse caminho possa ser alterado durante a instalação.
O componente do modo kernel do EventHorizon consiste em um único driver Early Launch Antimalware (ELAM) chamado EventHorizonELAM, localizado em C:\Windows\System32\drivers\.

O EventHorizon também tenta ter o mínimo de sobrecarga possível no sistema. Em idle, ele normalmente usará pouco mais de 2 MB de RAM. Dito isso, quanto mais telemetria for recebida e mais regras forem carregadas, mais poder de processamento/RAM será utilizado. Se você usar um provedor que tenha um alto volume de eventos, o consumo de recursos pode aumentar rapidamente.

Orquestração EventHorizon (EventHorizon.exe): orquestra os componentes do modo de usuário relacionados à funcionalidade do EventHorizon. Quando o serviço é iniciado, ele inicia o executável de telemetria e o motor de detecção com proteções PPL AntiMalware e os monitora caso, por algum motivo, sejam encerrados. Também lida com solicitações de desinstalação.
Telemetria EventHorizon (EventHorizonTelemetry.exe): lê a configuração ETW, assina provedores relevantes, filtra eventos recebidos e os envia através de um pipe nomeado usando uma fila para o motor de detecção.
Motor de Detecção EventHorizon (EventHorizonDetectionEngine.exe): carrega regras, recebe telemetria do executável de telemetria e dispara detecções no Visualizador de Eventos do Windows se as regras forem acionadas.

Dentro do Visualizador de Eventos do Windows, em Applications and Services Logs > EventHorizon, há 3 canais diferentes usados pelo EventHorizon.
Os eventos relacionados aos nomes dos canais são colocados ali. Consulte o wiki para obter mais informações sobre eventos específicos.

Conforme mencionado anteriormente, o componente do modo kernel do EventHorizon consiste em um único driver Early Launch Antimalware (ELAM) chamado EventHorizonELAM, localizado em C:\Windows\System32\drivers\. Esse driver ELAM é o que permite que os componentes do modo de usuário do EventHorizon obtenham proteções PPL AntiMalware. Além disso, o driver responde a solicitações feitas pelos componentes do modo de usuário através de IOCTLs para:
O EventHorizon depende de algumas bibliotecas:
Abaixo está uma lista de recursos que usei durante o desenvolvimento, mas primeiro gostaria de agradecer a algumas pessoas por suas contribuições diretas. Primeiramente, gostaria de agradecer a Jacob Acuna por suas contribuições iniciais para a estrutura geral e funcionalidade do projeto. Além disso, gostaria de agradecer a Eric Esquivel, Julian Peña e Kyle Avery por suas valiosas percepções.