Cibersegurança e segurança da informação

Investigação de Credenciais AWS Suspeitas com CloudTrail e GuardDuty

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de Credenciais AWS na área de Cloud Security e IR

Resposta rápida

A investigação de Credenciais AWS exige a conexão entre Identity, Audit Logs, ações da API, recursos, Regions e Sessions. Comece por preservar as evidências e construir uma Timeline, e só depois execute o Containment documentado.

A investigação na nuvem exige a conexão de identidades, Control Plane, recursos, chaves, Sessions e serviços de segurança. Uma vez que a atividade está dispersa entre serviços e regiões, a Timeline e a compreensão das permissões são críticas. Este artigo foca-se na investigação de Credenciais AWS e destina-se a analistas de Cloud e SOC. O objetivo é fornecer um método de trabalho que possa ser aplicado na prática, em entrevistas profissionais e em ambientes de trabalho, sem se limitar a uma definição de dicionário.

O desafio central é que os dados são quase sempre incompletos. CloudTrail, GuardDuty, IAM principal podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos a investigação em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: investigação de chamadas de API simuladas de uma localização incomum. Todos os exemplos são dados de laboratório ou descrição de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com aprovação explícita, Scope definido e capacidade de interromper o teste.

Fontes de Telemetria

Nesta fase, define-se quais as evidências necessárias para responder à questão da investigação. Para a investigação de Credenciais AWS, os pontos base são Principal e session, API action, Resource e region, Source IP e user agent. Para cada fonte, documentam-se o proprietário, o período de retenção, o fuso horário, o atraso de ingestão e os campos que possam estar em falta.

A qualidade da recolha não se mede pelo facto de o log 'chegar'. É preciso verificar a Completeness, Latency, Parsing, Duplicate events e a sincronização temporal. Um teste Canary ou um evento de laboratório conhecido permite verificar se a ação apareceu na fonte, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Principal e Access key

O tópico 'Principal e Access key' é uma parte central do trabalho de investigação de Credenciais AWS. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se pretende tomar e que evidência é suficiente para a justificar. Estas perguntas evitam o uso automático de uma ferramenta sem a compreensão do objetivo.

Na prática, registe o CloudTrail, GuardDuty, IAM principal, access key, AssumeRole, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Timeline do CloudTrail

A Timeline é a espinha dorsal da investigação de Credenciais AWS. Os tempos são normalizados para UTC ou o fuso horário é explicitamente indicado, tanto o Event time quanto o Ingestion time são mantidos, e os eventos são conectados por identificadores estáveis. A linha deve incluir tempo, origem, entidade, ação, resultado e fiabilidade.

Uma lacuna ou contradição não é um erro no documento, mas sim uma descoberta. Clock drift, atraso de ingestão, NAT, reutilização de PID ou uma Session contínua podem alterar a ordem. Por isso, indicam-se intervalos de incerteza e mantém-se um link para a evidência bruta.

GuardDuty e Scoping

O tópico 'GuardDuty e Scoping' é uma parte central do trabalho de investigação de Credenciais AWS. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se pretende tomar e que evidência é suficiente para a justificar. Estas perguntas evitam o uso automático de uma ferramenta sem a compreensão do objetivo.

Containment, Rotation e Lições Aprendidas

A resposta à investigação de Credenciais AWS deve reduzir o risco sem apagar as evidências que ainda são necessárias. Começa-se por uma ação reversível e focada, confirmam-se a propriedade e a autoridade, e documentam-se o tempo, o executante e o resultado.

A correção a longo prazo trata da raiz: permissões, configuração, Validation, Telemetry, processo ou formação. Após a implementação, realiza-se um Retest e monitorizam-se sinais de recorrência, em vez de se contentar com o fecho do Ticket.

Pontos de Verificação Únicos

Neste tópico, é recomendável construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: CloudTrail, GuardDuty, IAM principal, access key, AssumeRole, region, S3/Lambda/EC2. A lista não é um Checklist automático; cada item é escolhido porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

CloudTrail: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
GuardDuty: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
IAM principal: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
access key: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
AssumeRole: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
region: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.

Quando um dos focos não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usam-se Metadata, volume, frequência e TLS/DNS context.

Processo de Trabalho Recomendado

Defina um Scope e uma única questão de trabalho sobre a investigação de Credenciais AWS.
Registe as fontes de dados e as evidências necessárias: CloudTrail, GuardDuty, IAM principal, access key.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Realize o teste mínimo num ambiente de laboratório e guarde o tempo, a entrada e a saída.
Construa uma Timeline ou tabela de comparação e separe o facto da interpretação.
Realize um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
Resuma a decisão, as limitações, a ação recomendada e o critério de Retest.

Cenário Prático

O cenário escolhido é a investigação de chamadas de API simuladas de uma localização incomum. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, janela de tempo e resultado esperado.

No final do exercício, deve ser apresentado um produto que outro analista ou auditor possa revisar: uma captura de tela ou Export da evidência, uma Timeline curta, uma suposição inicial, uma evidência verificadora, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Passo	O que é realizado	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências de CloudTrail, GuardDuty, IAM principal devem aparecer.	Plano de teste curto
Criação de Dados	Realize uma ação segura e simulada relacionada com a investigação de Credenciais AWS, sem informações reais ou impacto num sistema de produção.	Evento/Pedido/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, os identificadores e a integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a explicação legítima possível.	Conclusão intermédia
Finalização	Escolha um encerramento, escalada, Finding ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist Prático

Verifique e documente: Principal e session.
Verifique e documente: API action.
Verifique e documente: Resource e region.
Verifique e documente: Source IP e user agent.
Verifique e documente: Audit event ID.
Verifique e documente: GuardDuty/Defender/SCC finding.
Indique Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes de filtrar ou modificar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a próxima ação com uma data.

Erros Comuns

Focar-se apenas numa área.
Rodar uma chave antes de preservar a Timeline.
Não verificar AssumeRole ou Token.
Ignorar o Control Plane.
Não mapear permissões eficazes.
Concluir que a localização geográfica prova um ataque.

Resumo e CTA

A investigação de Credenciais AWS suspeitas com CloudTrail e GuardDuty é um tópico que conecta o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e verificada novamente.

No percurso de Cybersecurity & AI da HPI, estes princípios são praticados através de sistemas, logs e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

A investigação de Credenciais AWS por si só prova um ataque ou vulnerabilidade?

Não. Fornece um sinal ou descoberta que precisa de contexto, verificação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na sua correspondência com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos com suposições nem apresente 'Unknown' como válido.

Quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente o Retention, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, as Stop conditions e o backup antes de começar o trabalho.