GuardDuty Extended Threat Detection passa a cruzar vulnerabilidade, pacote malicioso e exposição pública em sequências de ataque

Desde 20 de maio de 2026, o GuardDuty Extended Threat Detection anexa cinco indicadores vindos do Inspector, do Reachability Analyzer, do Macie e do Security Hub às sequências de ataque, transformando sinais fracos de runtime em achados críticos acionáveis.

Desde 20 de maio de 2026, o GuardDuty Extended Threat Detection anexa cinco indicadores vindos do Inspector, do Reachability Analyzer, do Macie e do Security Hub às sequências de ataque, transformando sinais fracos de runtime em achados críticos acionáveis.

Quem opera GuardDuty em conta de produção conhece o problema: um pod exec estranho, uma chamada de AssumeRoleWithWebIdentity fora do padrão, um processo que não bate com nenhuma assinatura conhecida de ferramenta ofensiva. Isoladamente, nada disso cruza o limiar de confiança para virar um achado crítico. Desde 20 de maio de 2026, o GuardDuty Extended Threat Detection começou a resolver parte desse problema anexando cinco novos tipos de indicador às suas sequências de ataque, conforme detalha o AWS Security Blog.

Os indicadores são VULNERABILITY, MALICIOUS_PACKAGE, REACHABILITY, MISCONFIGURATION e SENSITIVE_DATA. Eles não vêm do próprio GuardDuty: são sinais de postura e de risco que o Amazon Inspector, o Amazon VPC Reachability Analyzer, o Amazon Macie e o AWS Security Hub já produzem, e que agora alimentam o motor de correlação do Extended Threat Detection. Para quem já roda esses serviços por outros motivos, não muda nada em configuração; o que muda é a qualidade do achado final.

O que cada indicador entrega

A lógica do Extended Threat Detection é simples de enunciar e difícil de operar manualmente: um sinal fraco de runtime (um processo, uma syscall, uma chamada de API) só vira achado crítico de alta confiança quando o contexto do recurso confirma que ele é explorável. Os cinco indicadores novos são exatamente esse contexto de estado do recurso, e aparecem na aba Indicators do achado, tanto no console quanto no JSON retornado por GetFindings.

Vale a pena entender por que o EPSS importa aqui. Segundo o FIRST, que mantém o padrão, o EPSS é a probabilidade de uma CVE publicada ser explorada em até 30 dias, numa escala de 0 a 1. Ele não substitui o CVSS, que descreve a severidade inerente da falha; o EPSS descreve a chance de exploração iminente, o que o torna o número mais útil para quem está priorizando resposta a incidente, não auditoria de postura.

Pré-requisitos: nada novo para habilitar, mas nada aparece sem os serviços ligados

Os indicadores só populam se os serviços de origem já estiverem ativos na conta: Amazon Inspector em EC2 e EKS para VULNERABILITY e MALICIOUS_PACKAGE; Security Hub com os Foundational Security Best Practices para MISCONFIGURATION; VPC Reachability Analyzer rodando contra as VPCs de produção para REACHABILITY; Macie para SENSITIVE_DATA; e GuardDuty Runtime Monitoring em EC2, ECS e EKS, porque é ele que gera os sinais fracos que os indicadores vão reforçar. Quem já mantém essa pilha ligada por outros motivos de compliance não precisa fazer nada: os indicadores passam a aparecer automaticamente nas sequências novas.

Exemplo real: cluster EKS que não teria disparado nada antes

O post da AWS detalha um caso observado num cluster Amazon EKS ao longo de 8 dias, com 55 sinais de EKS_AUDIT_LOGS (pod exec, assunção de papel, AssumeRoleWithWebIdentity) e 18 sinais de nível de achado, todos partindo do mesmo IP externo, 198.51.100.69, que autenticou como quatro identidades IAM distintas no mesmo cluster. A atividade de runtime nos nós era genérica: nenhum processo batia com caminho de ferramenta ofensiva conhecida, então a regra EKS_MALICIOUS_PROCESS nunca disparou, e sem ela não havia sequência correlacionada antes do lançamento.

Com os cinco indicadores, o quadro muda de figura. O cluster carregava o identificador de pacote malicioso MAL-2022-4933 do Inspector; 42 CVEs no total, 33 classificadas CRITICAL por CVSS, sendo 12 delas de alta prioridade por EPSS (entre elas CVE-2022-1471, deserialização em SnakeYAML, com EPSS 0,94, e CVE-2024-4577, injeção de argumento em PHP-CGI, com EPSS 0,97); os cinco nós de trabalho somavam 379 CVEs, 68 marcadas CRITICAL; o endpoint da API do cluster e três dos cinco nós estavam acessíveis pela internet; e todos os cinco nós ainda expunham IMDSv1.

Com os quatro indicadores populados, isso virou um único achado AttackSequence:EKS/CompromisedCluster de severidade CRITICAL, mapeado no MITRE ATT&CK para Initial Access via serviço remoto externo, Discovery e Persistence.

Em resumo: o mesmo conjunto de eventos que antes ficava abaixo do radar por falta de uma assinatura de ferramenta conhecida agora vira achado crítico porque o Extended Threat Detection enxerga o estado do recurso, não só o comportamento isolado.

Segundo exemplo: cryptomining que já tinha achado forte ganha trilha de remediação

Nem todo caso depende dos novos indicadores para existir. Num grupo de instâncias EC2 que já se comunicava com destino conhecido de cryptomining (classificado como mining/misc pela inteligência de ameaças do GuardDuty), o achado AttackSequence:EC2/CompromisedInstanceGroup já seria gerado só com a evidência de rede. O que o indicador VULNERABILITY acrescentou foi a CVE-2007-4559, falha de path traversal no tarfile do Python, com EPSS em torno de 0,9, presente em duas das três instâncias envolvidas. A diferença prática: a equipe de resposta deixa de só bloquear o IP de saída e passa a saber qual patch fecha a porta de entrada provável.

Indicadores de comprometimento observados na primeira semana

A AWS registrou, nas contas que receberam os indicadores na primeira semana após o lançamento, um conjunto recorrente de CVEs de EPSS alto: CVE-2024-4577 (PHP-CGI, EPSS acima de 0,97), CVE-2022-1471 (SnakeYAML, EPSS 0,94, CVSS crítico), CVE-2022-37434 (estouro de buffer no zlib, EPSS 0,92), CVE-2007-4559 (tarfile do Python, ainda acima de 0,9 em 2026), além de CVE-2025-29927 (bypass de autenticação em Next.js), CVE-2024-34351 (SSRF em Next.js) e CVE-2023-44487 (HTTP/2 Rapid Reset). No lado de ferramental, apareceu a família HackTool Linux/frp, usada como túnel de comando e controle, disfarçada de binários kuboard-agent e kuboard-agent-server em nós de EKS, com rastro no caminho /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/.

Como o binário fica embutido na imagem do contêiner e no nó, reconstruir o nó a partir de uma AMI não corrigida não remove a ameaça sozinho. Também apareceram hostnames de callback do Burp Collaborator sob o padrão *.oastify.com, coexistindo com o frp na mesma sequência, possível sinal de uma segunda ferramenta ou de um segundo agente na mesma infraestrutura comprometida.

O que muda no playbook de quem responde a incidente

A AWS é direta em dizer que os indicadores não mudam o runbook para sequências já fechadas; eles mudam a qualidade e a urgência das sequências novas. Para o analista de SOC ou engenheiro de segurança que recebe o alerta, a recomendação prática do próprio post se resume a três movimentos:

• Tratar com urgência todo achado com MALICIOUS_PACKAGE combinado a VULNERABILITY de alta prioridade: o host esteve, e ainda está, em risco. Rotacionar toda credencial IAM, instance profile ou papel vinculado a IRSA que possa ter sido exposto.
• Priorizar patch por EPSS, não só por CVSS bruto: a lista de alta prioridade na VULNERABILITY já vem filtrada pelas CVEs de maior probabilidade de exploração real.
• Isolar recursos marcados por REACHABILITY: host acessível pela internet com vulnerabilidade explorável entra em isolamento antes da remediação, não depois.

Para quem ainda não habilitou Inspector, Reachability Analyzer, Macie ou os controles do Security Hub, o ganho descrito aqui simplesmente não existe: o Extended Threat Detection continua rodando, mas sem o contexto de estado do recurso que torna o achado acionável. O próprio post aponta, como recurso adicional de suporte para quem precisa de mais apoio na triagem, o GuardDuty Investigation, a análise assistida por IA sobre os achados e contas do GuardDuty.

Fonte: AWS Security Blog