Inteligência de Ameaças em Cloud

Nota 01 do capítulo 26, que abre a parte da biblioteca dedicada a CTI e Threat Hunting em ambientes modernos.
O foco é adaptar o ciclo de inteligência ao cloud: atores, fontes de intel específicas e PIRs do ambiente de nuvem.
Dialoga com o capítulo 01 (ciclo e PIRs), com a nota 11 do capítulo 08 (hunting em cloud e SaaS) e com a nota 01 do capítulo 21 (EASM multi-cloud).

1. Contexto e Posicionamento na Biblioteca

O ambiente de cloud não pede um ciclo de inteligência novo, mas altera substancialmente o conteúdo de cada fase do ciclo do capítulo 01. A coleta muda de fontes, porque a telemetria decisiva é a de plano de controle e não a de endpoint; a análise muda de foco, porque o artefato central é a identidade e a chamada de API e não o binário; e a produção muda de destinatário, porque as decisões de bloqueio e correção ficam com times de plataforma e não apenas de SOC. Esta nota percorre essas adaptações e mostra como integrá-las ao programa de CTI existente por meio de PIRs dedicados a cloud.

A nota estrutura o tema em quatro blocos: o teatro de ameaças e a superfície de cloud, os atores e motivações recorrentes, as fontes de inteligência específicas e a integração no programa por meio de PIRs e EEIs. O hunting sobre a mesma telemetria está na nota 11 do capítulo 08, e a nota 02 deste capítulo aprofunda o vetor dominante, a identidade. O exemplo da seção 7 executa um PIR de cloud ponta a ponta, do requisito ao produto disseminado.

2. O Cloud como Teatro de Ameaças

O plano de controle é a nova rede: criar uma instância, assumir um papel, emitir uma chave de acesso e revisar uma permissão são operações de API com efeito imediato e global, sem bins em disco e sem escaneio de rede tradicional. A responsabilidade compartilhada desloca o risco para o lado do cliente, identidade, configuração e dados, e é justamente esse lado que os atores exploram, porque o provedor endurece a plataforma com o tempo enquanto a configuração do cliente varia a cada projeto. A infraestrutura é efêmera nos dois lados: o atacante sobe e derruba instâncias em minutos, e o defensor precisa de telemetria de API que sobreviva a essa velocidade.

Três consequências práticas orientam a coleta. Primeira, os logs que importam são os de auditoria do provedor, como CloudTrail e os logs de atividade do Entra ID, e o gap deles é invisível para qualquer outra ferramenta. Segunda, a persistência raramente é malware: aplicativo OAuth com escopos altos, chave de acesso esquecida, serviço de automação manipulado e domínio federado alterado são os mecanismos dominantes. Terceira, o exfiltração usa a própria infraestrutura da vítima, com staging em buckets e contas de armazenamento legítimos, o que exige baseline de acesso normal para diferenciar uso legítimo de abuso.

O inventário de serviços de borda abaixo concentra a maior parte das intrusões cloud documentadas, e cada item é candidato natural a PIR e a hipótese de caça.

• Painéis de administração e console de gerenciamento expostos, com autenticação fraca ou federada sem condicional.
• Gateways de VPN e brokers de acesso remoto com CVEs conhecidas sob exploração em massa.
• Armazenamento de objetos com permissões públicas e segredos versionados no repositório de código.
• Clusters de orquestração, como Kubernetes, com API exposta e controles de acesso permissivos.
• Serviços de integração e de automação com credenciais de longa duração e sem rotação.

3. Atores e Motivações Recorrentes

O catálogo de atores em cloud é dominado por motivações financeiras, com a espionagem como minoria sofisticada e persistente. A tabela abaixo organiza os objetivos mais recorrentes, o comportamento típico e as referências de atores publicamente documentadas em relatórios do setor, servindo de insumo para a avaliação de ameaças do programa.

A leitura tática da tabela destaca o padrão central: quase todos os comportamentos começam por identidade. Cryptomining precisa de credencial que crie recursos, extorsão precisa de sessão válida, espionagem precisa de persistência federada. Essa concentração explica a ordem das notas deste capítulo, que caminha da inteligência de cloud para o hunting de identidade e depois para as pontes híbridas, e justifica a priorização de PIRs sobre abuso de IAM antes de PIRs sobre exploração de CVE em workloads.

A concentração em identidade também orienta a leitura de indicadores: um mesmo IP pode criar instâncias em três contas distintas sem que nenhuma delas registre processo suspeito, e o vínculo entre os casos só aparece na correlação de identidade. Por isso o produto de inteligência cloud deve carregar sempre a camada de identidade envolvida, e não apenas os recursos criados. A avaliação de ameaças do programa precisa refletir essa realidade ao definir os cenários prioritários de risco.

4. O que Muda no Ciclo Tradicional

A adaptação do ciclo é melhor entendida por comparação dimensão a dimensão, porque o objetivo não é criar um processo paralelo, mas estender o processo existente. A tabela abaixo consolida as diferenças que exigem decisão de programa, de ferramenta ou de pessoal.

A linha do consumidor merece ênfase: o produto de inteligência cloud que fica no SOC e não chega ao time de plataforma perde a decisão mais valiosa, que é corrigir a configuração e a permissão que tornaram o abuso possível. A revisão de PIRs precisa, por isso, incluir assentos do time de plataforma na definição de requisitos, e a disseminação do capítulo 15 precisa contemplar canal dedicado para esse público.

A adaptação também muda a relação com a linha do tempo do atacante. A intrusão cloud típica tem fases rápidas: obtenção de credencial, reconhecimento de permissões com ferramentas legítimas, criação de persistência e movimentação para o objetivo, tudo em horas ou menos. O hunting orientado por janelas semanais chega tarde nesse ciclo, e por isso a família de PIRs cloud privilegia deteções contínuas sobre comportamentos de plano de controle, com o hunting humano reservado para as hipóteses de maior complexidade analítica.

5. Fontes de Inteligência Cloud

As fontes de intel cloud são distintas das fontes tradicionais de malware, e a tabela abaixo organiza as principais com o conteúdo que oferecem e o uso recomendado no programa. A regra de coleção é a mesma do capítulo 01: cada PIR define a fonte, e não o contrário, evitando a coleta compulsiva de relatórios que ninguém consome.

Duas práticas elevam o aproveitamento dessas fontes. A primeira é o processamento estruturado: os advisories da CISA já vêm com ATT&CK mapeado e mitigações, e a extração desses campos no pipeline da nota 08 do capítulo 09 transforma o texto em objetos consultáveis no TIP. A segunda é a verificação de aplicabilidade: nem toda campanha documentada aplica-se ao stack da organização, e o filtro de aplicabilidade, por provedor, serviço e versão, é o que evita a saturação da fila de análise.

O registro de coleção abaixo ilustra o formato mínimo para uma fonte da seção 5, amarrando o consumo ao PIR e à validade. O mesmo padrão se aplica aos relatórios pagos, que exigem justificativa de assinatura na revisão anual do programa.

Fonte F-CLD-07: advisories da CISA com foco em cloud
Conteúdo: TTPs mapeadas em ATT&CK, indicadores e mitigações
PIR atendidos: PIR-CLD-01, PIR-CLD-03
Processamento: extração de TTPs e IOCs para o TIP, revisão semanal
Responsável: analista de CTI do núcleo cloud
Validade do consumo: contínua, com revisão de relevância a cada trimestre

6. Integração no Programa de CTI: PIRs e EEIs de Cloud

A integração formal acontece no registro de requisitos do capítulo 01, com uma família de PIRs dedicada a cloud ao lado das famílias tradicionais. Cada PIR cloud nasce de uma pergunta de decisão: qual ator ameaça qual serviço, qual técnica de abuso é viável com a configuração atual e qual telemetria falta para detectar. Os EEIs correspondentes seguem a mesma lógica do capítulo 01, nota 09: o que a organização precisa saber sobre a ameaça para gerir o risco do ambiente de nuvem, expresso em pergunta respondível, e não em feed assinável.

O loop de feedback fecha a integração: os achados do hunting de cloud da nota 11 do capítulo 08 alimentam novos PIRs, as deteções implantadas a partir dos produtos são validadas pelo purple teaming do capítulo 19, e o aproveitamento das fontes da seção 5 é medido em produtos efetivamente consumidos. A métrica de saúde do programa cloud é simples: para cada PIR cloud ativo, existe fonte definida, produto com data de validade e consumidor identificado.

As perguntas iniciais abaixo ilustram a família de PIRs cloud de uma organização hipotética, e cada uma delas é respondível com o método do ciclo.

• Quais atores financeiros miram o nosso provedor principal e com quais técnicas de acesso inicial?
• Quais técnicas de cryptomining são viáveis com as quotas e as regiões das nossas contas?
• Quais sinais de abuso de token aparecem na nossa telemetria e quais faltam por lacuna de coleta?
• Quais mudanças de configuração observadas combinam com TTPs documentadas em advisories recentes?

Os EEIs correspondentes seguem o mesmo formato do capítulo 01, e a tabela abaixo mostra o vínculo entre o requisito e a pergunta de informação essencial.

7. Exemplo de PIR Cloud e de Fonte Consumida

O exemplo abaixo percorre o requisito PIR-CLD-03, criado após o inventário de dados revelar clusters Kubernetes gerenciados com custo de computação fora da linha de base. O registro do PIR mostra o formato mínimo esperado no registro do programa.

PIR-CLD-03: Quais técnicas os grupos de cryptomining usam para obter acesso,
escalar privilégios e esconder cargas em clusters Kubernetes gerenciados?

Motivação: desvio de custo de 38% na conta de computação em dois clusters.
Pergunta de decisão: qual detecção e qual restrição de IAM encerram o abuso
sem interromper workloads legítimos?

Fonte primária: advisory da CISA sobre atividade de cryptomining em cloud,
com TTPs mapeadas em ATT&CK e mitigações de IAM e de quota.
Fonte secundária: relatório anual de runtime security com casos reais de
criação de pods privilegiados e uso de instâncias spot em regiões baratas.
Fonte terciária: telemetria interna de API dos dois clusters afetados.

Produto esperado: nota tática CLD-2026-004 com indicadores de uso de API,
regra de detecção para criação de pods privilegiados e revisão de quotas.
Consumidor: time de plataforma e SOC, com prazo de 10 dias úteis.
Validade: 90 dias ou até a conclusão da revisão de quotas.

A execução do ciclo sobre este PIR seguiu o caminho esperado. O advisory primário entregou as técnicas de obtenção de credencial por segredo exposto em repositório e a criação de DaemonSets para persistência; o relatório secundário confirmou o padrão de região e de família de instâncias observado na conta; e a telemetria interna correlacionou as duas fontes com a identidade de serviço que originava a criação de pods. O produto CLD-2026-004 resultou em duas deteções implantadas, na revogação do segredo e na restrição da permissão de criação de cargas, encerrando o desvio de custo e abrindo um novo PIR sobre gestão de segredos em repositórios, demonstrando o ciclo completo de inteligência aplicado a cloud.

O detalhe que fecha o exemplo é a origem do PIR: ele não nasceu de um feed, mas de uma anomalia financeira percebida pelo time de plataforma, que é o consumidor da inteligência. Esse caminho inverso, do dado operacional ao requisito, é frequente em cloud e reforça a necessidade de canal formal entre plataforma e CTI. O PIR que nasce do consumidor tem contexto, prazo e critério de sucesso, e é por isso que os melhores requisitos do programa costumam vir do time que paga a conta.

8. Erros Comuns e Pontos de Atenção

O erro fundacional é tratar cloud como extensão do datacenter e herdar PIRs de malware para um ambiente em que a persistência raramente é binário. O erro simétrico é contratar fontes cloud inteiras sem PIR, produzindo relatórios não consumidos e a falsa impressão de inteligência. Ambos se resolvem ancorando a família de PIRs cloud nas decisões reais que os times de plataforma precisam tomar.

Completam a lista os itens abaixo.

• Coletar logs de plano de controle com lacunas de serviço, deixando cego exatamente o plano onde o abuso ocorre.
• Ignorar a telemetria de identidade e delegar o tema ao capítulo de rede, perdendo o vetor dominante.
• Tratar cryptomining como dano menor, quando ele é frequente sinal de acesso inicial reutilizável por atores de extorsão.
• Disseminar o produto apenas no SOC, sem o time de plataforma que decide correção de configuração e permissão.
• Não mapear as TTPs dos advisories em ATT&CK, desperdiçando a ligação direta com priorização de hipóteses.

• Deixar o PIR cloud sem validade e sem consumidor, transformando requisito em acervo morto no registro.

• Confinar a inteligência cloud ao SOC, ignorando o time de plataforma que decide a correção de configuração e de permissão.

9. Integração com o Restante da Biblioteca

A nota dialoga com a nota 11 do capítulo 08, que executa o hunting sobre a telemetria aqui descrita, e com a nota 02 deste capítulo, que aprofunda o vetor de identidade responsável pela maioria dos incidentes cloud. O EASM e o CTEM do capítulo 21 fornecem a descoberta de exposição externa que prioriza PIRs sobre serviços de borda, e o capítulo 19 valida as deteções implantadas a partir dos produtos cloud. No ciclo formal do framework CTH, os controles do grupo HNT recebem as hipóteses cloud e o grupo ANA recebe os produtos, fechando o mesmo circuito das famílias tradicionais. A próxima nota desce ao vetor dominante: a identidade, novo perímetro onde a maior parte das caçadas modernas começa.