Hunting em Cloud e SaaS

Nota 11 do capítulo 08 (Técnicas de Hunting por TTPs), fechando o bloco de caça por tática no plano de infraestrutura em nuvem e aplicativos SaaS.
Levanta a telemetria dos provedores (CloudTrail, Azure Activity, GCP Audit), mapeia TTPs de cloud e OAuth em SaaS e entrega consultas por provedor.
Dialoga com a nota 10 em identidade, com as notas 06 e 07 em rede e com os controles PRT.4 e TH.12 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Cloud inverteu a geometria da intrusão: a superfície exposta virou API, o perímetro virou controle de identidade e o objetivo do adversário passou a ser a conta com privilégio, porque com ela o console e o CLI substituem o exploit e a persistência. Incidentes públicos de campanhas contra ambientes mal configurados mostram o padrão repetido: credencial vazada ou token roubado, reconhecimento programático, escalonamento de IAM e, quando há dado em jogo, snapshot ou transferência para conta do operador. Esta nota organiza essa sequência em telemetria, técnicas e consultas, e cobre a camada SaaS, onde o mesmo adversário aparece como aplicativo OAuth e download em massa.

O posicionamento na biblioteca fecha o arco do capítulo 08: as notas 06 e 07 cobriram rede, as notas 08 e 09 cobriram host e diretório, e a nota 10 entregou a identidade comprometida que aqui se transforma em ação na plataforma. Os controles PRT.4 e TH.12 do capítulo 15 recebem daqui o material de cobertura de cloud e de rede de nuvem, e o inventário de dados do TH.1 é o pré-requisito que decide se as consultas abaixo funcionam, porque CloudTrail sem data events e Activity Log sem diagnóstico viram caça cega.

2. Telemetria de Cloud por Provedor

Cada provedor tem seu plano de auditoria, e a gramática é a mesma: eventos de gestão descrevem mudanças de configuração e de permissão, eventos de dados descrevem acesso a conteúdo, e o campo de identidade diz quem chamou, de que IP e com qual agente. A tabela consolida as fontes equivalentes nos três grandes provedores e o que cada uma entrega para hunting, com atenção ao detalhe que mais custa: eventos de dados são separados e precisam ser habilitados explicitamente no trail ou no diagnóstico.

Três prerequisitos definem se a caça em cloud é real. O trail precisa cobrir todas as regiões e os eventos de gestão com logging de leitura e de escrita, porque reconhecimento é leitura; os eventos de dados precisam estar ligados nos buckets e cofres que guardam dado sensível, senão a exfiltração de conteúdo não aparece; e a retenção centralizada precisa levar os logs ao SIEM, porque o portal do provedor não suporta janela de campanha nem correlação com identidade. O controle DAT.4 do capítulo 15 descreve a centralização; aqui, a regra prática é que toda consulta desta nota exige gestão ligada e, para conteúdo, exige evento de dado ligado.

3. TTPs de Cloud e suas Assinaturas

As técnicas dominantes em cloud formam uma cadeia reconhecível, e cada elo tem assinatura clara no plano de auditoria. O console sem MFA denuncia conta acessada por canal fraco; o reconhecimento com ferramentas conhecidas aparece como rajada de List e Get com user agent característico; o escalonamento de IAM aparece como sequência de criação de credencial e anexação de política; o snapshot de volume é a cópia de dado para leitura em conta controlada pelo operador; e o recurso novo é a infraestrutura plantada para persistência ou para mineração. A tabela liga cada técnica ao evento e ao filtro essencial, no vocabulário da AWS com equivalentes diretos nos outros provedores.

A leitura operacional da tabela é que a cadeia completa é o sinal mais forte, e as consultas devem encadear, e não isolar: reconhecimento seguido de escalonamento seguido de acesso a segredo é incidente por construção, mesmo quando cada evento isolado teria explicação administrativa. Essa lógica de sequência é a mesma das notas anteriores, com a vantagem de que cloud registra tudo em um só plano e facilita a linha do tempo por identidade.

4. Consultas KQL por Provedor

A consulta de console sem MFA é a mais simples e a mais valiosa, porque console é canal humano e sua entrada sem segundo fator é anomalia de política com valor de incidente. O agregado por identidade e por dia separa teste legítimo de rotina de acesso, e a origem residencial ou de datacenter fora do baseline reforça a prioridade.

// Console AWS sem segundo fator, agregado por identidade e dia
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "ConsoleLogin"
| extend MFAUsada = tostring(parse_json(tostring(additionalEventData)).MFAUsed)
| where MFAUsada =~ "No"
| summarize Logins = count(), IPs = dcount(SourceIPAddress) by Identidade = UserIdentityUserName, Dia = bin(TimeGenerated, 1d)
| order by Dia desc, Logins desc

A consulta de escalonamento de IAM encadeia os eventos de criação de credencial e anexação de política por identidade, em janela de uma hora, e é a implementação direta da cadeia da seção 3. O make_list preserva a ordem dos eventos, e a leitura da lista mostra a narrativa do ataque sem abrir cada linha.

// Sequência de escalonamento IAM por identidade em janela de 1h
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("CreateAccessKey", "CreateLoginProfile", "AddUserToGroup",
                      "AttachUserPolicy", "PutUserPolicy", "AttachRolePolicy",
                      "CreatePolicyVersion", "SetDefaultPolicyVersion")
| summarize Acoes = make_list(EventName), Primeira = min(TimeGenerated),
            Ultima = max(TimeGenerated), IPs = dcount(SourceIPAddress)
            by Identidade = UserIdentityUserName, Janela = bin(TimeGenerated, 1h)
| where array_length(Acoes) >= 3
| extend Narrativa = strcat_array(Acoes, "; ")
| order by Janela desc

No Azure, a mesma cadeia aparece como operações sobre recursos, e a consulta abaixo caça cópia de disco, leitura de chave de conta de armazenamento e criação de snapshot bem-sucedidas, que são os elos de exfiltração de conteúdo na plataforma. No GCP, o equivalente usa Data Access em métodos de leitura de storage e secret manager, e a disciplina de agregação por principal é a mesma. O nome exato das colunas varia conforme o conector de ingestão, e a prática de mercado é validar o esquema do SIEM antes de fixar a consulta, mantendo o critério de caça, que é leitura de conteúdo fora do padrão de principal, independente do campo.

// GCP: leitura de conteúdo e de segredos agregada por método e recurso
GCPAuditLogs
| where TimeGenerated > ago(7d)
| where MethodName in~ ("storage.objects.get", "storage.objects.list",
                        "secretmanager.versions.access")
| summarize Acessos = count(), Primeiro = min(TimeGenerated), Ultimo = max(TimeGenerated)
            by MethodName, Recurso = GCPResourceName
| where Acessos > 100
| order by Acessos desc

// Azure: exfiltração candidata por cópia de disco e leitura de chaves
AzureActivity
| where TimeGenerated > ago(7d)
| where ActivityStatusValue =~ "Succeeded"
| where OperationNameValue endswith "snapshots/write"
    or OperationNameValue endswith "disks/begingetaccess/action"
    or OperationNameValue endswith "storageaccounts/listkeys/action"
| summarize Acoes = count(), Recursos = dcount(_ResourceId), IPs = dcount(CallerIPAddress)
            by Caller, bin(TimeGenerated, 1d)
| where Recursos > 3 or Acoes > 10
| order by Acoes desc

A agregação por user agent complementa as duas anteriores e é o filtro mais barato contra ferramentas automatizadas: agentes de SDK e de CLI de teste, como pacu, scout suite e boto3 em rajada, assinam o plano de auditoria de forma estável, e o cruzamento com identidade que nunca apareceu com aquele agente é candidato imediato a revisão. A regra prática é manter a lista de agentes por função da organização, com exceções documentadas, e caçar o agente novo em identidade com privilégio alto.

5. Caça em SaaS: OAuth e Download em Massa

A camada SaaS repete o padrão de cloud com vocabulário próprio, e os dois sinais dominantes são o consenso de aplicativo OAuth e o download em massa de conteúdo. O consenso perigoso já foi tratado na nota 10 do lado do IdP; aqui o complemento é o comportamento do aplicativo depois do consenso, porque aplicativo malicioso usa o token em rajada de leitura, e essa rajada aparece nos logs de atividade da plataforma como volume de arquivo e de caixa postal por aplicativo. O download em massa é o sinal clássico de insider e de conta comprometida, e a agregação por usuário e por hora, com corte por número de arquivos e por bytes, é a consulta de referência.

// Download em massa em SharePoint e OneDrive por usuário e hora
OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation in~ ("FileDownloaded", "FileSyncDownloadedFull", "FileSyncDownloadedPartial")
| where UserId !has_any ("svc-", "backup-")
| summarize Arquivos = dcount(SourceFileName), Bytes = sum(SourceFileSize),
            Sites = dcount(Site_Url)
            by Usuario = UserId, Janela = bin(TimeGenerated, 1h)
| extend GB = round(Bytes / 1073741824.0, 2)
| where Arquivos > 300 or GB > 5
| project Usuario, Janela, Arquivos, GB, Sites
| order by GB desc

A interpretação em SaaS exige baseline por função, como na nota 07, porque funções de conteúdo movem gigabytes legítimos e o corte absoluto só serve para começar. O refinamento que agrega valor é o destino do download: cliente desconhecido no user agent, dispositivo não registrado e horário atípico somados ao volume produzem o caso; volume alto em dispositivo conhecido e horário habitual produz apenas atualização de baseline. A rotação de caças deve incluir ainda os eventos de administrador do SaaS, como exportação de caixas e mudança de papel, porque o administrador comprometido é o caminho mais curto para todo o conteúdo da organização.

6. Exemplo de Caça no CloudTrail

O caso simula a investigação de credencial de usuário administrativo aparecendo em origem nova. A hipótese estruturada é: se um adversário obteve credencial com poder de IAM, então a sequência de reconhecimento, criação de chave e anexação de política aparece encadeada por aquela identidade em janela curta, seguida de uso da chave nova para acesso a dado. O roteiro segue quatro passos com critérios de fechamento.

1. Confirmar a anomalia de entrada com a consulta de console sem MFA e com o histórico de origem da identidade no IdP, estabelecendo a janela do comprometimento e separando o uso humano de console do uso programático com chave.
2. Rodar a consulta de escalonamento por identidade na janela estabelecida e ler a narrativa de ações; a presença de CreateAccessKey seguida de anexação de política administrativa fecha a hipótese de escalonamento e move o caso para resposta imediata.
3. Rastrear o uso da chave nova com eventos de leitura de dado, agregando GetObject e GetSecretValue por bucket e por cofre, para medir o escopo de conteúdo acessado; esse inventário é a insumo direto do time jurídico e de privacidade quando dado pessoal está em jogo.
4. Fechar com varredura reversa de 30 dias pela mesma identidade e pelo mesmo IP, procurando a primeira aparição do padrão, e produzir a lista de recursos criados pelo adversário, que é o material de erradicação e a base da regra de detecção permanente.

// Uso da chave nova para leitura de dado, por bucket e cofre
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("GetObject", "GetSecretValue", "ListSecrets")
| where UserIdentityUserName =~ "usuario-alvo"
| summarize Acessos = count(), Recursos = dcount(Resources), IPs = dcount(SourceIPAddress),
            Primeiro = min(TimeGenerated), Ultimo = max(TimeGenerated)
            by Identidade = UserIdentityUserName, Tipo = EventType
| order by Acessos desc

O veredicto do caso segue a disciplina do capítulo: sequência encadeada de eventos com narrativa coerente vale mais que qualquer evento isolado, e a presença dos três elos, entrada anômala, escalonamento e acesso a dado, fecha o caso como incidente de nuvem com escopo medido. Com dois elos, o caso abre monitoramento nomeado e revisão de permissões; com um elo, vira ajuste de política documentado. A contenção típica inclui desativar chaves, revogar sessões, resetar credencial e auditar recursos criados, e o caso só se encerra com a regra permanente registrada, porque ambientes de cloud com privilégio administrativo tornam a recorrência questão de tempo.

7. Erros Comuns e Pontos de Atenção

• Caçar sem eventos de dados: o trail padrão só registra gestão, e a leitura de objeto, que é o coração da exfiltração em nuvem, não aparece; habilitar evento de dado nos cofres e buckets sensíveis é pré-requisito documentado, e sua ausência invalida qualquer conclusão de escopo.
• Agregar por conta raiz ou por papel e perder a identidade: papéis assumidos por STS escondem o usuário real se a consulta olha só o nome do papel, e a caça precisa atravessar o campo de identidade assumida até o principal de origem.
• Tratar região nova como conteúdo: expansão legítima existe, e o sinal de recursos novos só fecha com combinação de série de instância, user agent e identidade nova; região sem contexto vira fila de falsos positivos em semanas.
• Ignorar o user agent: a ferramenta do adversário assina o log de forma estável, e a lista de agentes por função da organização é um dos filtros mais baratos e estáveis de todo o hunting de cloud.
• Separar cloud do IdP: a mesma identidade apareceu no portal e na API, e sem o plano de identidade da nota 10 a caça vê só metade da história; a correlação entre os dois planos é o que converte anomalia de acesso em incidente com escopo.

8. Integração com o Restante da Biblioteca

Esta nota fecha o capítulo 08 aplicando a telemetria de cloud inventariada no capítulo 02, as hipóteses do TH.6 e a cobertura de rede e de cloud dos controles TH.12 e PRT.4, com lacunas registradas no MAP.4 para as técnicas da tabela da seção 3. A nota 10 é a porta de entrada da cadeia, porque a conta comprometida é o evento fundador do caso de cloud, e a nota 07 reaparece aqui no plano SaaS com download em massa como equivalente do upload do proxy. O capítulo 09 detalha as ferramentas e conectores citados, o capítulo 18 recebe as consultas maduras como regras com limiares do MET.2, e o capítulo 26 aprofunda o cenário moderno de identidade e nuvem onde esta nota termina. Quando o caso confirma grupo e infraestrutura, o capítulo 05 orienta atribuição e confiança, e o ciclo CTI.9 do capítulo 15 recebe a atualização dos PIRs, encerrando o arco que o capítulo começou: da hipótese nascida de inteligência à detecção permanente que devolve inteligência.