O que é um EDR?
EDR significa Endpoint Detection and Response. É um agente instalado em cada máquina, responsável por monitorar eventos gerados pelo sistema operacional para identificar possíveis ataques. Quando algo suspeito é detectado, o EDR gera um alerta e o envia para ferramentas como SIEM ou SOAR, onde analistas humanos irão avaliar o incidente. A parte de “Response” envolve ações tomadas após a detecção, como isolar o host.
As soluções de segurança modernas combinam diversas técnicas para identificar e classificar softwares como maliciosos. Para desenvolvedores de malware, compreender esses mecanismos é essencial para entender como essas defesas funcionam e como o ambiente de detecção evolui.
De modo geral, antivírus tradicionais são utilizados principalmente por usuários domésticos, enquanto os EDRs são adotados por empresas devido à sua capacidade avançada de detecção, telemetria em tempo real e resposta a incidentes.
The UI of (Microsoft Defender for Endpoint):
O EDR, ao detectar uma atividade suspeita, normalmente reúne e apresenta diversas informações relevantes para auxiliar o analista na investigação: processos envolvidos, argumentos utilizados, hashes, relações de processos pai e filho, entre outros detalhes. Com base nesses dados, o analista precisa decidir se está diante de um falso positivo ou de um ataque real.
O EDR tenta detectar atividades mais avançadas, focando nas TTPs, ferramentas, técnicas e procedimentos usados pelos atacantes.
Entender completamente um único EDR já é bem difícil, e conhecer todos é praticamente impossível. Por isso, o EDR que descrevo aqui é uma versão mais abstrata, uma ideia de como um EDR “ideal” poderia funcionar. Não é exatamente o que existe hoje, e sim o que seria possível fazer com a telemetria e os dados que o Windows oferece.
Detecção por Hash
A detecção por hash é considerada um subconjunto da detecção estática, mais especificamente da detecção por assinatura. Trata-se de uma técnica simples e rápida para identificar malwares já conhecidos.
O funcionamento é o seguinte: os hashes de malwares já conhecidos são armazenados em um banco de dados, podendo ser hashes MD5, SHA-256, entre outros. Quando um arquivo é analisado, seu hash é comparado com esse banco de dados que armazena centenas de milhares de hashes de malwares conhecidos, verificando se há alguma correspondência.
Uma analogia útil: os hashes dos arquivos funcionam como impressões digitais. Assim como uma impressão digital identifica uma pessoa de forma única, o hash identifica um arquivo de forma única.
A principal limitação da detecção por hash é que basta alterar um único byte no arquivo para que o hash seja completamente modificado. Qualquer alteração gera um novo hash, evitando assim a detecção, já que o novo hash não estará presente no banco de dados.
Detecção Heurística
A detecção por assinatura é facilmente contornável por pequenas alterações nos arquivos. A detecção heurística surge como alternativa, sendo capaz de detectar características suspeitas em arquivos mesmo que sejam novos ou desconhecidos, ou seja, mesmo que não estejam presentes em nenhum banco de dados.
Análise Estática (sem execução): O modelo heurístico examina a estrutura do binário procurando características suspeitas, por exemplo:
Entropia: Seções com entropia alta indicam conteúdo criptografado ou comprimido, comum em malware empacotado.
Import Address Table (IAT): Combinações suspeitas de imports como
VirtualAlloc+VirtualProtect+CreateThreadjuntas
O programa é sinalizado se acumular indicadores suficientes de comportamento suspeito.
Análise Dinâmica (com execução): O programa é executado em um ambiente controlado (sandbox ou emulador), onde seu comportamento é monitorado em tempo real:
Sequências de API calls
Tentativas de acessar processos sensíveis
Modificações em registry keys de persistência
Conexões de rede para IPs/domínios suspeitos
Verificação da IAT
A tabela de importações (IAT) lista todas as funções que serão utilizadas pelo executável em tempo de execução, junto com as DLLs que as exportam. Isso permite que soluções de segurança identifiquem quais APIs do Windows o programa pode utilizar.
Exemplo prático: Ransomwares geralmente utilizam funções de criptografia e manipulação de arquivos. Se um arquivo analisado faz uso exclusivo de funções como CryptCreateHash, CryptHashData ou CryptGetHash, sem utilizar outras funções mais comuns, pode ser sinalizado como malicioso.
Falsos Positivos
Arquivos benignos também podem fazer uso dessas funções. Quando soluções de segurança detectam um arquivo normal como malicioso, ocorre o chamado falso positivo. Esse tipo de situação ainda acontece, embora seja menos comum atualmente.
Pilares de Detecção
Um EDR utiliza três técnicas principais para identificar ameaças:
File Scanning
Assinaturas (como regras YARA) são aplicadas em arquivos no disco
Memory Scanning
Assinaturas são aplicadas na memória dos processos em execução
Telemetria/Comportamento
Análise de ações realizadas pelo processo através do sistema operacional
Esses três pilares estão interligados. Se você usa um loader para evitar a detecção no disco (criptografando o payload), o código malicioso ainda precisará estar descriptografado na memória para ser executado, tornando-o detectável por memory scanning. Se você implementa criptografia de memória para evitar isso, acaba gerando mais telemetria que pode ser usada para detectar essa técnica. É um ciclo constante.
Fontes de Telemetria (Sensores)
Para um processo fazer qualquer coisa útil, como abrir arquivos, criar conexões de rede ou exibir uma janela, ele precisa interagir com o kernel do Windows. Não há como evitar isso. A Microsoft habilitou o kernel a gerar dados sobre essas operações, e o EDR consome esses dados como eventos.
O EDR recebe telemetria de duas fontes principais:
Usermode
O edr realiza hooks nas principais APIs utilizadas por programas maliciosos isso resulta no seguinte:
Se olharmos como ficam funções hookadas na memória vamos ver o seguinte:
Com isso, o EDR recebe o nome das funções chamadas e seus parâmetros como telemetria.
É importante notar que esses hooks em usermode podem ser removidos ou contornados, já que estão no espaço de memória do próprio processo. Por isso, EDRs modernos não dependem exclusivamente dessa técnica.
AMSI (Antimalware Scan Interface) O AMSI escaneia scripts executados em interpretadores Windows como PowerShell, VBA do Office e .NET/C#. A aplicação solicita ao sistema operacional que realize um scan via AMSI no conteúdo que pretende executar.
Kernelmode
A telemetria do kernel é mais confiável porque é gerada pelo próprio kernel, não podendo ser suprimida ou contornada sem privilégios de kernel.
ETW (Event Tracing for Windows) Infraestrutura de rastreamento de eventos do Windows que fornece informações detalhadas sobre operações do sistema. Exemplo: Um evento ETW de ImageLoad do provedor Microsoft-Windows-Kernel-Process registra quando um processo carrega uma DLL ou imagem executável.
ETW-TI (Threat Intelligence) Extensão do ETW focada em eventos de segurança sensíveis, como operações de memória entre processos.
Exemplo: O evento RemoteReadProcessMemory (ID 23) do provedor Microsoft-Windows-Threat-Intelligence registra quando um processo tenta ler a memória de outro processo. Na imagem abaixo, o mimikatz.exe acessa o lsass.exe:
Kernel Callbacks São rotinas de notificação que o kernel dispara quando eventos específicos ocorrem:
PsSetCreateProcessNotifyRoutine
Criação/término de processo
PsSetCreateThreadNotifyRoutine
Criação/deleção de thread
PsSetLoadImageNotifyRoutine
Carregamento de imagens/DLLs
ObRegisterCallbacks
Operações em objetos (NtOpenProcess, NtOpenThread, etc.)
Esses callbacks são executados no contexto do processo/thread relevante, fornecendo informações sobre a origem do evento.
NDIS / Minifilter Drivers
Drivers que monitoram operações de filesystem e rede.
Análise de Regiões de Memória
Quando um .exe é iniciado, as seções do arquivo PE são copiadas para a memória. A seção .text contém o código assembly, enquanto .data e similares contêm dados do programa.
As regiões de memória que vêm do arquivo PE são chamadas de backed (ou IMAGE). Elas são confiáveis porque são cópias 1:1 do arquivo PE que já foi escaneado pelo AV no disco.
Quando o processo aloca memória adicional com VirtualAlloc(), essa memória é unbacked (também chamada de PRIVATE ou USER).
IMAGE/Backed
Confiável - mapeada do PE no disco
PRIVATE/Unbacked
Suspeita - shellcode geralmente vive aqui
Indicadores suspeitos:
PRIVATE + RWX = muito suspeito
PRIVATE + RX = suspeito (possível shellcode)
Threads iniciando de unbacked memory = suspeito
Copy-On-Write: O EDR pode verificar se páginas read-only (como .text) foram modificadas. Isso é incomum, já que essas páginas deveriam ser compartilhadas entre processos. Ferramentas como Moneta utilizam essa técnica.
Callstack Analysis
Quando um processo chama uma função, é possível descobrir a cadeia de funções que levou a essa chamada. Isso é o callstack.
O EDR pode inspecionar o callstack quando funções sensíveis são chamadas e analisar a origem:
O que o EDR verifica:
A origem deve ser de memória backed
Deve passar por DLLs legítimas
Origem em unbacked = provável shellcode
Essa análise permite detectar técnicas como direct syscalls, dentre outras.
Thread State Analysis
Threads podem estar dormindo por diferentes razões. Investigar o estado da thread e o callstack que a levou até ali revela indicadores de beacons dormindo ou criptografia de memória.
Suspeito:
Chamadas para memória virtual no callstack durante sleep
Origem em non-backed memory regions
Padrões de sleep consistentes com beacons de C2
Exemplo: O EDR detecta uma thread em estado de sleep chamando NtDelayExecution(). Ao analisar o callstack, vê que a cadeia de chamadas inclui uma região unbacked (0x7ff00000). Isso indica um possível beacon de C2 aguardando comandos.
Exemplo de Regra
Para entender melhor vou estar mostrando um exemplo de rule que o Elastic tem, essa rule basicamente: detecta quando um processo carrega DLLs de rede a partir de memória não mapeada (unbacked), indicando possível injeção, e ao confirmar o padrão suspeito no call stack, ela finaliza automaticamente o processo:
Por que ele monitora essas DLLs?
C2 frameworks como Cobalt Strike, Sliver e Havoc precisam se comunicar com o servidor do atacante. Para isso, geralmente usam:
wininet.dll/winhttp.dll→ comunicação HTTP/HTTPSws2_32.dll→ conexões via socket
São DLLs legítimas do Windows, mas quando um shellcode as carrega, o padrão de execução é diferente de um programa normal.
Como o EDR sabe quando verificar?
O EDR não fica analisando a call stack 24/7, isso seria inviável. Em vez disso, ele usa hooks e callbacks para ser notificado quando eventos específicos acontecem.
No caso do carregamento de DLLs, existem algumas formas:
PsSetLoadImageNotifyRoutine
Kernel
O Windows "avisa" o driver do EDR toda vez que uma imagem (DLL/EXE) é carregada
Hook em LdrLoadDll
User-mode (ntdll)
O EDR intercepta a função que carrega DLLs
Hook em LoadLibraryA/W
User-mode (kernel32)
Intercepta a API de alto nível
Quando a wininet.dll é carregada, o EDR recebe essa "notificação", pausa a execução, captura a call stack da thread e analisa.
O que ele procura na call stack?
Uma call stack normal de um programa legítimo seria assim:
Todos os frames apontam para módulos conhecidos (executáveis ou DLLs mapeadas).
Agora olha a call stack de um shellcode:
O endereço 0x0000024efef91095 não pertence a nenhum módulo carregado. Isso significa que o código está rodando em uma região de memória alocada dinamicamente, típico de shellcode:
XDR (Extended Detection and Response)
Os XDRs estendem o monitoramento para outros componentes de infraestrutura, coletando logs de:
Máquinas e endpoints
Dispositivos de rede (firewalls, roteadores, switches)
Outros componentes de infraestrutura
Todos esses dados são armazenados em um único banco de dados, permitindo correlação entre eventos. Isso teoricamente resulta em melhor detecção, já que o foco não está apenas em uma máquina, mas na rede como um todo.
Mas a alta quantidade de dados fluindo para a nuvem é significativa, especialmente em empresas com centenas ou milhares de funcionários. Mesmo com inteligência artificial, tornar todo esse sistema eficaz permanece um desafio complexo.
Conclusão
Não entrei muito a fundo nos tópicos; meu objetivo era apenas passar uma visão geral do que considero realmente importante. Vale lembrar que um EDR também pode realizar enriquecimento de eventos, emulação AV (pré-execução), correlação de dados, entre outras capacidades, mas acredito que o que abordei aqui já é suficiente para o contexto.
Last updated