AWS, Azure e GCP - Telemetria e Ameaças

Nota 05 do capítulo 26 (CTI e Threat Hunting em Ambientes Modernos), cobrindo a telemetria nativa dos três grandes provedores de nuvem e as ameaças típicas de cada ecossistema.
A nota consolida eventos críticos de CloudTrail, Azure Activity Log e GCP Cloud Audit Logs, compara as diferenças de identidade e de plano de dados e apresenta a normalização multi-cloud com OCSF.
Dialoga com a nota 11 do capítulo 08 (Hunting em Cloud e SaaS), com os controles DAT.4 e PRT.4 do capítulo 15 e com as notas de EASM multi-cloud do capítulo 21.

1. Contexto e Posicionamento na Biblioteca

A operação de CTI e Threat Hunting em nuvem raramente é mono-provedor: a maioria das organizações grandes combina AWS, Azure e GCP, e o adversário que obtém uma credencial qualquer não se importa com o logo do provedor onde o dado está. O problema prático para o hunter é que cada provedor tem seu próprio plano de auditoria, seu vocabulário de eventos e seu modelo de identidade, e uma mesma ação, como anexar uma política permissiva a um usuário, aparece com nomes, campos e tabelas completamente distintos nas três plataformas. Esta nota organiza essa diversidade em três camadas: fontes de telemetria, eventos críticos equivalentes e ameaças típicas por provedor.

O posicionamento na biblioteca é de consolidação prática: a nota 11 do capítulo 08 já entregou a lógica de caça em cloud por TTP, e aqui o foco é a gramática dos três provedores usados juntos, com a normalização multi-cloud como ponte para consultas únicas no SIEM ou no lakehouse. As notas 06, 07 e 08 deste capítulo estendem a mesma lógica para Kubernetes, CI-CD e SaaS, formando o bloco de ambientes modernos do capítulo 26.

2. Telemetria Nativa por Provedor

Cada provedor registra duas famílias de eventos que o hunter precisa separar mentalmente: eventos de plano de controle (gestão), que descrevem mudanças de configuração, identidade e permissão, e eventos de plano de dados, que descrevem acesso a conteúdo, como leitura de objeto, segredo ou banco. Os eventos de gestão costumam vir habilitados por padrão; os de dados exigem configuração explícita, e é exatamente neles que a exfiltração aparece. A lista abaixo resume a fonte principal de cada provedor e a pegadinha de habilitação que mais quebra caças no primeiro dia.

• AWS: o CloudTrail registra eventos de gestão em todas as regiões quando o trail é multi-região, e os eventos de dados de S3, Lambda e DynamoDB precisam de event selectors (ou Advanced Event Selectors) explícitos por bucket e por classe de recurso. Os eventos do Secrets Manager, como GetSecretValue, são eventos de gestão no vocabulário do CloudTrail e por isso aparecem sem configuração extra, o que engana muita gente em relação ao S3.
• Azure: o Azure Activity Log cobre o plano de controle do Resource Manager, mas a identidade do usuário está no Microsoft Entra ID, cujo Sign-in Logs e Audit Logs precisam ser exportados para o workspace do Log Analytics via configuração de diagnóstico. O plano de dados de Key Vault, Storage e SQL vem em tabelas de diagnóstico separadas, como AzureDiagnostics com categoria AuditEvent, e o Defender for Cloud Apps agrega a atividade SaaS em CloudAppEvents.
• GCP: o Cloud Audit Logs traz o Admin Activity sempre ativo e gratuito, o Data Access opt-in por serviço e por projeto, o System Event para ações automatizadas e o Policy Denied para acessos bloqueados pelo IAM. O sink para BigQuery ou Cloud Logging com agregação de pastas e organizações é o que garante cobertura multi-projeto, porque o log de um projeto isolado não enxerga a campanha que atravessa a organização.

No plano de dados, os serviços sensíveis mudam de nome em cada provedor, mas o conjunto de acessos que importam para hunting é o mesmo: objeto de storage, segredo, chave criptográfica e banco gerenciado. A tabela abaixo serve de mapa rápido para validar, serviço por serviço, se a telemetria de leitura está realmente sendo coletada no ambiente, porque é nessa camada que a exfiltração se materializa.

O pré-requisito transversal é a centralização: sem ingestão do CloudTrail no SIEM, do Activity Log e do Sign-in Logs no mesmo workspace e do Cloud Audit Logs exportado para um repositório consultável, o hunter fica preso a consoles por projeto e a janelas de retenção curtas. O controle DAT.4 do capítulo 15 formaliza essa centralização e a nota 04 do capítulo 02 trata a telemetria como fonte de inteligência, não como registro burocrático.

3. Diferenças de Eventos-Chave entre Provedores

A tabela abaixo consolida as ações críticas da cadeia de ataque em nuvem e o nome do evento equivalente em cada provedor, com o vocabulário real que aparece no log. O hunter deve memorizar a equivalência funcional, porque consultas multi-cloud dependem de mapear conceito para o nome nativo de cada plataforma antes da normalização.

Três diferenças estruturais merecem atenção permanente. Primeiro, o modelo de identidade: na AWS a identidade que importa no log pode ser usuário IAM, role assumida ou federated user, e o campo UserIdentity carrega ARN, conta e tipo; no Azure separa-se o Caller do Activity Log, que é a identidade do Resource Manager, da UPN do Entra no Sign-in Logs; no GCP o principal é o e-mail da conta de serviço ou do usuário, com a distinção entre principal e principalSubject que muda quando há impersonation. Segundo, a regionalidade: CloudTrail multi-região resolve a dispersão de eventos da AWS, enquanto o Activity Log por assinatura e o Cloud Audit por projeto exigem agregação no destino central. Terceiro, a latência e a retenção variam por provedor e por camada, e janelas de campanha de horas só existem no SIEM com ingestão própria, nunca na retenção padrão do portal.

O plano de autenticação ainda tem particularidades que mudam a hipótese de caça. Na AWS, o ConsoleLogin traz o campo MFAUsed dentro do additionalEventData e os logins programáticos aparecem como AssumeRole ou GetFederationToken sem evento de login tradicional, o que obriga a caça de sessão a olhar a cadeia de role assumida; no Azure, o SigninLogs diferencia interativo de não interativo e carrega o resultado do Conditional Access, permitindo caçar sessões concedidas com risco elevado; no GCP, o evento de login do serviço google.login convive com o padrão de autenticação por token de conta de serviço, em que não existe sessão e a pergunta correta é de onde veio o JWT. Sem reconhecer essas três gramáticas, o hunter busca persistência de sessão onde ela não existe e perde o sinal onde ela existe.

4. Fontes de Ameaça Típicas por Provedor

• Criptomineração (T1496): a ameaça mais banal e mais frequente em contas vazadas, caracterizada por criação de instâncias em famílias de hardware caro, como as séries p e g da AWS, a2 e g2 do GCP e as VMs de GPU do Azure, geralmente em regiões fora do baseline. O sinal é o par criação de recurso com tipo incomum mais execução contínua com custo anômalo, e o hunting ganha força ao cruzar eventos de criação com o billing em janelas de poucas horas.
• Escalonamento de IAM (T1098, T1078.004): a cadeia clássica é reconhecimento com List e Describe, criação de credencial e anexação de política permissiva. Na AWS aparecem CreateAccessKey seguido de AttachUserPolicy e PutRolePolicy, com iam:PassRole como elo de pivot para computação; no Azure, roleAssignments/write e concessões de app role no Entra; no GCP, setIamPolicy em projeto ou bucket seguido de GenerateAccessToken para impersonar conta de serviço, que é a versão cloud-native do roubo de identidade.
• Abuso de snapshot (T1530): o equivalente cloud da cópia de disco para leitura offline. Na AWS a assinatura é CreateSnapshot ou CopySnapshot seguida de ModifySnapshotAttribute compartilhando com conta externa; no Azure, criação de snapshot e exportação para conta de storage com SAS URL gerada na sequência; no GCP, snapshot de disco seguido de exportação da imagem para bucket cujo IAM foi alterado para principal fora da organização.
• Persistência via recursos novos (T1136, T1578): a criação de usuário IAM, conta de serviço ou aplicativo corporativo, assim como a alteração de guardrails, como Service Control Policies, security defaults e exclusões de organização no Cloud Logging, marca o ambiente para o longo prazo. O hunting compara o inventário de identidades e recursos de novo tipo contra o processo de aprovação, e qualquer criação fora da esteira de IaC é candidata, porque a esteira legítima sempre deixa assinatura previsível de pipeline.
• Evasão de logging (T1562.008): a desativação de telemetria é incidente por si só e costuma anteceder ou suceder a ação grave. StopLogging e DeleteTrail na AWS, exclusão de diagnostic settings no Azure e DeleteSink ou exclusão de permissão no Cloud Logging do GCP devem ser tratados como eventos de resposta imediata, independente de qualquer outra evidência, porque nenhuma operação legítima desliga auditoria sem change registrada.

A leitura operacional dessas famílias é que nenhuma delas depende de exploit: todas são abuso de API legítima com credencial válida, o que significa que a detecção vem de sequência e de contexto, não de assinatura de payload. Uma ação isolada de ListBuckets tem explicação administrativa; ListBuckets, CreateAccessKey e GetSecretValue pela mesma identidade em trinta minutos são incidente por construção, e é essa lógica de cadeia que as consultas da seção 6 implementam.

5. Normalização Multi-Cloud com OCSF

Escrever três versões de cada caça, uma por provedor, multiplica o custo de manutenção e esconde lacunas de cobertura, e é por isso que a normalização para um esquema comum virou prática de mercado. O OCSF (Open Cybersecurity Schema Framework) define classes que traduzem o vocabulário de cada provedor para campos estáveis, com destaque para Cloud API Activity (uid 6) para eventos de plano de controle, Authentication (3002) e Account Change (3001) para o plano de identidade, e File Activity (1001) para o plano de dados. Produtos e serviços como Amazon Security Lake, que entrega tabelas OCSF prontas no S3, e a normalização ASIM do Microsoft Sentinel, que antecede o padrão com o mesmo espírito, permitem uma única consulta cobrindo os três provedores.

A implementação disciplinada do mapeamento segue quatro passos que valem como checklist de projeto. Primeiro, ingerir o formato nativo intacto, preservando o evento bruto como fonte da verdade. Segundo, construir o arquivo de mapeamento por provedor, declarando campo por campo a tradução para o OCSF e versionando esse arquivo no mesmo repositório das detecções. Terceiro, validar enums e tipos, porque campos como activity_name e severity mudam de domínio entre provedores e precisam de dicionário próprio. Quarto, manter a revisão trimestral do mapeamento, usando como gatilho tanto as atualizações do esquema OCSF quanto as mudanças de API anunciadas pelos provedores, pois evento novo fora do mapeamento entra no lakehouse invisível para as consultas.

A armadilha da normalização é tratá-la como perda de fidelidade: o correto é manter o evento bruto sempre disponível para drill-down, porque detalhes como o additionalEventData do ConsoleLogin ou a lista de modifiedProperties do Entra só existem no formato nativo. A regra prática é normalizar para detectar e correlacionar em escala, e voltar ao formato nativo para investigar caso a caso.

6. Exemplo Prático: Consulta Multi-Cloud Normalizada

A consulta abaixo roda em BigQuery sobre uma tabela OCSF alimentada pelos três provedores e implementa a heurística de cadeia da seção 4: identificar contas com reconhecimento em volume que também executaram ao menos uma ação de escalonamento no mesmo período. A sintaxe é BigQuery, mas o mesmo padrão funciona no Snowflake, no Panther ou no SIEM com esquema normalizado.

-- Reconhecimento seguido de escalonamento, por identidade, em qualquer provedor
SELECT
  metadata.product.name AS provedor,
  cloud.account.name    AS conta,
  actor.user.name       AS identidade,
  COUNT(*)              AS total_eventos,
  MIN(activity_time)    AS primeiro_evento,
  MAX(activity_time)    AS ultimo_evento,
  COUNTIF(activity_name IN (
    'ListUsers', 'ListBuckets', 'DescribeInstances',
    'List resources', 'GetSecretValue'
  ))                    AS reconhecimento,
  COUNTIF(activity_name IN (
    'CreateAccessKey', 'AttachUserPolicy', 'PutRolePolicy',
    'Microsoft.Authorization/roleAssignments/write',
    'setIamPolicy', 'GenerateAccessToken'
  ))                    AS escalonamento
FROM `proj_seguranca.ocsf.cloud_api`
WHERE activity_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY provedor, conta, identidade
HAVING reconhecimento >= 5 AND escalonamento >= 1
ORDER BY escalonamento DESC, total_eventos DESC

Em ambientes que ainda não adotaram o lakehouse OCSF, o mesmo raciocínio funciona no SIEM com consulta unificada sobre as tabelas nativas, aceitando o custo de manter os nomes dos três provedores na mesma consulta. O exemplo abaixo é ilustrativo no Microsoft Sentinel e assume as colunas mapeadas pelo conector de cada provedor, devendo ser ajustado ao esquema real do workspace, mas demonstra o padrão de unificar por conceito antes de agregar.

// Caça unificada multi-cloud no Sentinel, sem lakehouse OCSF
union isfuzzy=true AWSCloudTrail, AzureActivity, GCPAuditLogs
| where TimeGenerated > ago(7d)
| extend Provedor = case(
    isnotempty(EventName), "AWS",
    isnotempty(MethodName), "GCP",
    "Azure"),
    Evento = coalesce(EventName, MethodName, OperationName),
    Identidade = coalesce(UserIdentityUserName, PrincipalEmail, Caller)
| where Evento in ("ListUsers", "ListBuckets", "DescribeInstances",
    "CreateAccessKey", "AttachUserPolicy", "setIamPolicy", "GenerateAccessToken")
| summarize Eventos = count(), Provedores = dcount(Provedor),
    Escalonamento = countif(Evento in ("CreateAccessKey", "AttachUserPolicy", "setIamPolicy", "GenerateAccessToken"))
    by Identidade
| where Eventos >= 5 and Escalonamento >= 1
| order by Escalonamento desc

A leitura do resultado segue a disciplina de verificação de hipótese: cada linha candidata precisa ser checada no formato nativo, confirmando de quem é a identidade, se o IP de origem pertence ao baseline de administração e se há justificativa de change registrada. Falsos positivos previsíveis incluem automação de IaC que lista e modifica permissões em lote, e por isso o filtro por userAgent ou por identidade de pipeline entra na segunda iteração da caça, sempre documentando o baseline que exclui cada automação legítima.

7. Erros Comuns e Pontos de Atenção

• Operar com eventos de gestão apenas: reconhecimento e mudança de permissão aparecem no plano de controle, mas leitura de objeto e exfiltração vivem no plano de dados, e sem event selectors ou Data Access habilitados a caça termina na metade da cadeia.
• Confundir os planos de identidade do Azure: o Activity Log diz quem chamou a API do Resource Manager, o Sign-in Logs diz como o usuário autenticou, e a correlação entre os dois é o que revela token roubado com login limpo, o padrão típico de sessão sequestrada.
• Tratar o nome do evento como IOC: nomes como GetSecretValue são legítimos por definição, e alertar por nome isolado gera ruído infinito; o valor está na sequência, no volume e no desvio de baseline por identidade.
• Ignorar o custo e o billing como telemetria: a mineração e o abuso de snapshot têm assinatura financeira imediata, e a ausência de ingestão de billing no SIEM joga fora o sinal mais rápido de compromisso.
• Confiar na retenção padrão dos consoles: janelas de dias não sustentam investigação de campanha, e a ausência de sink centralizado é equivalente a não ter log.
• Deixar contas fora da agregação: a conta de billing, os projetos de sandboxes e as assinaturas de teste são exatamente onde adversários testam credenciais, e a agregação que cobre só a organização principal cria um ponto cego institucionalizado.
• Usar userAgent como filtro exclusivo: o campo de agente ajuda a separar automação de humano, mas o adversário controla esse valor com facilidade, e caça que descarta linhas por userAgent descarta o próprio alvo.

O ponto de atenção final é a governança do esquema normalizado: atualizações de provedores introduzem eventos novos que só existem no vocabulário nativo por um tempo, e o mapeamento OCSF precisa de revisão trimestral, do mesmo jeito que as regras de detecção precisam de revisão. Sem esse ritual, o lakehouse normalizado envelhece silenciosamente e a caça multi-cloud começa a devolver lacunas que ninguém percebe.

8. Integração com o Restante da Biblioteca

Esta nota é a fundação cloud do bloco de ambientes modernos: as notas 06, 07 e 08 do capítulo 26 assumem essa telemetria disponível e estendem a análise para Kubernetes, esteiras de CI-CD e SaaS, que em grande parte rodam sobre os mesmos três provedores. A nota 11 do capítulo 08 fornece as técnicas e os ATT&CK IDs da cadeia cloud, e a presente nota fornece o mapa de eventos para executar essas técnicas nos três ecossistemas sem reimprovisar consultas.

No plano dos controles, a nota alimenta o DAT.4 (centralização de logs) com a lista de fontes cloud obrigatórias, o PRT.4 (monitoramento de containers e cloud-native) com os eventos de plano de controle que cercam os clusters e o TH.1 (inventário de dados para hunting) com o critério de habilitação de eventos de dados por bucket e serviço. As notas de EASM multi-cloud do capítulo 21 complementam a visão externa, cobrindo o que o adversário vê de fora enquanto esta nota cobre o que ele deixa registrado por dentro.