O Rustinel é um agente de deteção de endpoint escrito em Rust que recolhe telemetria por ETW no Windows e por eBPF no Linux e normaliza os eventos num modelo comum. Criado por Théo Foucher e distribuído sob licença Apache 2.0, o projeto colapsa num único codebase o trabalho que antes exigia pipelines separados para cada sistema operativo.
Pontos-chave: corre em modo utilizador sem driver de kernel; traz três motores de deteção (Sigma, YARA e IOC atómico); escreve alertas em ECS NDJSON prontos para Elastic ou Splunk; recarrega regras em quente sem reiniciar o processo; oferece resposta ativa opcional em modo dry-run.
O problema que o Rustinel resolve
A deteção de endpoint open-source esteve durante anos dividida entre ferramentas centradas no Windows, construídas em torno do Sysmon, e ferramentas Linux, assentes em eBPF ou auditd. Quem gere ambientes mistos costura pipelines distintos, conjuntos de regras distintos e ónus de manutenção duplicado. O Rustinel é uma tentativa de colapsar esse trabalho numa única base de código. Recolhe telemetria por ETW no Windows e por eBPF no Linux, normaliza os eventos num modelo partilhado e avalia-os contra regras Sigma, assinaturas YARA e indicadores de compromisso atómicos. Os alertas são escritos em disco como NDJSON compatível com ECS, um formato fácil de enviar, analisar e integrar em pipelines de SIEM como Elastic ou Splunk.
Cobertura por sistema operativo
No Windows a cobertura abrange criação de processos, carregamento de imagens, rede, ficheiros, registo, DNS, PowerShell, WMI, serviços e tarefas agendadas. No Linux inclui processos, rede, ficheiros e DNS. A cobertura do Windows mantém-se mais ampla por agora, com o suporte eBPF em Linux a continuar a crescer. O agente corre em modo utilizador nas duas plataformas. No Windows pode ser instalado como serviço. No Linux exige kernel 5.8 ou superior com suporte BTF e corre sob root ou sob um supervisor à escolha do operador. A resposta ativa é opcional e pode configurar-se em modo dry-run, com allowlists que isentam caminhos confiáveis da ação de bloqueio ou terminação.
A escolha do modo utilizador
A maioria dos EDR comerciais entrega um driver de kernel para obter visibilidade precoce e resistência a adulteração. O Rustinel segue um caminho diferente. Théo Foucher disse à Help Net Security que a escolha foi deliberada. O objetivo é manter-se o mais simples, transparente e estável possível, recolhendo ao mesmo tempo telemetria útil do host. Foucher reconheceu os limites dessa decisão. Um agente em modo utilizador não consegue igualar um driver de kernel em resistência a adulteração ou visibilidade profunda do kernel, e o Rustinel não está desenhado para parar rootkits de kernel ou defender-se de um atacante privilegiado que consiga desativar a telemetria. O benefício é operacional. Um bug num processo em modo utilizador tem muito menos probabilidade de derrubar um host do que um bug em espaço de kernel, e a segurança de memória do Rust elimina por defeito classes inteiras de defeitos. Foucher apontou também os limites da própria proteção baseada em kernel. Técnicas BYOVD e outros ataques de abuso de drivers demonstraram que mesmo EDRs comerciais maduros podem ser atacados pelo caminho do kernel.
Os três motores de deteção
O Rustinel corre três motores em paralelo. Sigma trata do matching comportamental contra o fluxo de eventos normalizado. YARA analisa executáveis na criação de processos, num worker em segundo plano. O motor de IOC faz verificações determinísticas de hashes, intervalos IP, domínios e padrões de caminho conhecidos. Foucher justificou a combinação pela reutilização de conteúdo. Chegou ao Sigma, YARA e IOC porque resolvem partes diferentes do problema de deteção e já são largamente compreendidos por defensores. Foi direto sobre as lacunas de cobertura. Payloads só em memória, atividade living-off-the-land fortemente ofuscada, comportamento novo fora das regras Sigma existentes e técnicas de adulteração de telemetria ficam de fora do que o agente apanha neste momento. Command-and-control encriptado sobre infraestrutura confiável também pode fugir ao matching de IOC, a não ser que o comportamento envolvente acione uma regra. A análise de memória com YARA está em desenvolvimento ativo para melhorar a cobertura contra payloads empacotados e desempacotados em tempo de execução.
As regras são recarregadas em quente sem reiniciar o processo, com swaps atómicos e janela de debounce de dois segundos. Resultados vazios são rejetados por segurança, mantendo ativos os motores compilados anteriores. As condições Sigma são transpilidas e pré-compiladas no arranque e em cada recarga. O contexto de processo é anexado aos alertas, não a cada evento, o que reduz custo no caminho quente. O enrichamento inclui normalização de caminho NT para DOS, extração de metadados de PE, correlação de processo pai, resolução de SID para utilizador e mapeamento reverso de DNS com cache. A saída segue o formato ECS NDJSON, com um objeto JSON por linha, pronto para ingestão direta em qualquer pipeline de logs que aceite NDJSON.
O que considerar antes de adotar
O Rustinel está em fase Alpha. É utilizável para experimentação, implantações em laboratório e endurecimento iterativo, mas o autor avisa que devem esperar-se mudanças disruptivas enquanto o esquema e os motores amadurecem. Não substitui um EDR comercial num ambiente de produção regulado, nem cobre rootkits de kernel ou atacantes privilegiados com acesso direto à telemetria. Para quem mantém ambientes mistos, oferece uma base sólida para unificar deteção, reutilizar regras Sigma e YARA já existentes e reduzir o peso de manter conjuntos de regras separados para Windows e Linux.
Quem procura deteção autónoma com IA encontra em ferramentas complementares alternativas válidas. O DarkMoon executa pentest ponta a ponta com um motor autónomo de IA. Quem precisa de scanner de dependências pode recorrer ao CVE Lite CLI, focado em JavaScript e em dependências npm. O repositório do Rustinel fica no GitHub sob licença Apache 2.0, com binários prontos a usar na página de releases.