> For the complete documentation index, see [llms.txt](https://vith0r.gitbook.io/public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vith0r.gitbook.io/public/defense-ops/endpoint-protection/o-que-e-um-edr.md).
# 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` + `CreateThread` juntas
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:
| Pilar | O que faz |
| ---------------------------- | ------------------------------------------------------------------------ |
| **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:
```asm
Função Original (no disco): Função Hookada (na memória):
────────────────────────── ────────────────────────────
mov r10, rcx mov r10, rcx
mov eax, 50h jmp 0x7ffaeadea621 ← desvio para EDR
test byte ptr [...] test byte ptr [...]
syscall syscall
ret ret
```
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:
| Callback | Evento Monitorado |
| --------------------------------- | -------------------------------------------------------- |
| `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).
| Tipo | Confiabilidade |
| ---------------- | ----------------------------------------- |
| 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:
```
Callstack legítimo:
aplicacao.exe → kernel32.dll → ntdll.dll → syscall
Callstack suspeito:
[região unbacked 0x1a0000] → ntdll.dll → syscall
```
**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:
```applescript
┌─────────────────────────────────────────────────────────────────────────────┐
│ ELASTIC ENDPOINT RULE │
│ Network Module Loaded from Suspicious Unbacked Memory │
└─────────────────────────────────────────────────────────────────────────────┘
name = "Network Module Loaded from Suspicious Unbacked Memory"
query = '''
sequence by process.entity_id
# EVENTO 1: Processo inicia
[process where event.action == "start" and
# Exceção: ignora processos assinados em Program Files
not (process.executable : "?:\\Program Files\\*" and
process.code_signature.trusted == true)
]
# EVENTO 2: DLL de rede carregada (TRIGGER)
[library where
# DLLs monitoradas
dll.name : ("ws2_32.dll", "wininet.dll", "winhttp.dll") and
# Call stack contém região UNBACKED
process.thread.Ext.call_stack_contains_unbacked == true and
# Padrões suspeitos de call stack
process.thread.Ext.call_stack_summary : (
"ntdll.dll|kernelbase.dll|Unbacked",
"ntdll.dll|kernelbase.dll|Unbacked|kernel32.dll|ntdll.dll"
)
]
until [process where event.action:"end"]
'''
# Ação quando detecta
[[actions]]
action = "kill_process"
```
#### 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/HTTPS
* `ws2_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:
| Método | Onde opera | Como funciona |
| ----------------------------- | -------------------- | ------------------------------------------------------------------------------- |
| `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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://vith0r.gitbook.io/public/defense-ops/endpoint-protection/o-que-e-um-edr.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.