Técnicas de Ataque a Bancos de Dados em Cloud

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Explora a cobertura
do ATT&CK para bancos de dados gerenciados em cloud, consolidada a partir da v18
com a sub-técnica Databases e amadurecida nas janelas da v19 e da v19.2, com
telemetria, detecção e exemplo de caça. Dialoga com Hunting em Cloud e SaaS e com
os controles DAT e MAP do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

Bancos de dados gerenciados em cloud, como instâncias relacionais e documentais dos grandes provedores, mudaram a mecânica do roubo de dados. O adversário raramente precisa exportar a base com um dump clássico: basta obter credenciais com permissão de leitura, criar um snapshot e compartilhá-lo, ou encaminhar fluxo de dados para um destino externo com funções serverless. O ATT&CK acompanhou essa realidade com técnicas específicas, e a v18 de outubro de 2025 deu um passo importante ao adicionar a sub-técnica Databases (T1213.006) sob Data from Information Repositories, completando o vocabulário que as janelas da v19 e da v19.2 consolidaram em contexto de ameaça.

Para a biblioteca, esta nota cobre o recorte de dados em cloud dentro do capítulo de atualizações, conversando com a nota de Hunting em Cloud e SaaS do capítulo 8, que traz as hipóteses gerais de caça, e com os controles DAT.2 e DAT.4, que tratam de telemetria e centralização. O objetivo é que o leitor saiba quais técnicas representam cada padrão de ataque a bancos de dados gerenciados, qual telemetria as sustenta e como estruturar uma caça concreta para o padrão de exfiltração via snapshot.

2. Cobertura do ATT&CK para Bancos de Dados Gerenciados

O vocabulário do ATT&CK para esse recorte combina técnicas de collection, discovery, credential access e exfiltration. A sub-técnica Databases (T1213.006) descreve a coleta de dados diretamente de bancos de informações armazenados em repositórios, incluindo bancos SQL e NoSQL gerenciados. Data from Cloud Storage (T1530) cobre a leitura de objetos em armazenamento de objetos, frequentemente o destino de dumps, e Cloud Storage Object Discovery (T1619) descreve a enumeração de buckets e objetos antes do acesso. Do lado de preparação de infraestrutura, Cloud Infrastructure Discovery (T1580) cobre o mapeamento de recursos cloud pelo adversário já posicionado.

O quadro abaixo organiza as técnicas centrais do recorte, com o padrão de ataque correspondente e a fase típica. Ele serve de índice para a construção de cobertura e para a leitura das release notes, onde ajustes nessas famílias aparecem com frequência nas categorias de cloud.

3. Três Padrões de Ataque Dominantes

O primeiro padrão é o abuso de credenciais de banco. O adversário obtém credenciais válidas, por vazamento em repositório de código, por coleta em variáveis de ambiente de pipeline, no recorte de T1552, ou por roubo de token de aplicação, no recorte de T1528, e passa a consultar a base como um usuário legítimo. É o padrão mais silencioso, porque não há exploit: há consultas válidas de um agente ilegítimo, e a detecção depende de comparação com baseline de usuário, origem, horário e volume de leitura, no espírito do que as notas de UEBA do capítulo 10 discutem.

O segundo padrão é a exfiltração via snapshot. Em bancos gerenciados, o snapshot é uma operação administrativa comum e barata, e o adversário com permissão adequada cria um snapshot da base e o compartilha com uma conta externa sob seu controle, ou copia dados para um bucket próprio, no recorte de T1537. O componente de dados Snapshot Deletion, presente no modelo de Data Components do ATT&CK, lembra que o ciclo de vida do snapshot também é relevante, pois a exclusão rápida do snapshot após a cópia é comportamento de encobrimento típico. O padrão é especialmente grave porque a base inteira sai em uma operação, sem varredura incremental.

O terceiro padrão é o uso de funções serverless como bomba de transferência. O adversário com acesso ao ambiente cloud cria ou reconfigura uma função serverless, no recorte de T1584.007 e T1648, para se conectar à base e despejar dados em destino externo, aproveitando a identidade legítima da função e o tráfego que sai de dentro do ambiente. Esse padrão combina collection e exfiltration e é difícil de notar em telemetria de rede, porque não há fluxo direto da base para fora: há a função, com papel legítimo, mediando a transferência.

4. Telemetria e Detecção por Padrão

A telemetria decisiva para esse recorte é a auditoria do plano de controle do provedor, e não o tráfego de banco. No AWS, o CloudTrail com data events captura operações sobre instâncias e snapshots; no Azure, os logs de auditoria do SQL e as operações do Resource Manager capturam mudanças de configuração; no GCP, os Cloud Audit Logs cumprem papel equivalente. Somam-se os logs de conexão do próprio banco, com usuário, origem e consulta, e os logs de IAM, que revelam elevações de privilégio que antecedem o acesso. A tabela abaixo liga cada padrão a eventos concretos de telemetria e às técnicas ATT&CK correspondentes.

A detecção de valor mais alto do recorte é a cadeia de snapshot: criação seguida de modificação de atributo de compartilhamento com ID de conta externa em janela curta. Essa cadeia raramente tem motivo legítimo não documentado, e quando existe, é processo de mudança formal, o que permite filtrar por tickets autorizados. Já no padrão de credenciais, a detecção é estatística: usuário que salta de origem, horário anômalo e volume de leitura fora do percentil, avaliados em conjunto para reduzir falso positivo.

Para o padrão de abuso de credenciais, a caça típica compara o comportamento de leitura por principal com a própria média histórica, buscando desvios que caracterizam coleta massiva compatível com T1213.006. O esqueleto abaixo, em KQL sobre logs de conexão e auditoria de banco ingestados no SIEM, ranka principais por volume de leitura no dia e compara com a janela de referência de trinta dias, destacando desvios expressivos.

BancoAuditoriaConsultas
| where TimeGenerated > ago(1d)
| summarize LeituraHoje = sum(RowsRead),
            Origens = dcount(SourceIP),
            Usuarios = dcount(DBUser) by Principal
| join kind=inner (
    BancoAuditoriaConsultas
    | where TimeGenerated between (ago(31d) .. ago(1d))
    | summarize MediaLeitura = avg(RowsRead) by Principal
  ) on Principal
| extend Desvio = round(LeituraHoje / max_of(MediaLeitura, 1.0), 1)
| where Desvio > 5
| project Principal, LeituraHoje, MediaLeitura, Desvio, Origens, Usuarios
| order by Desvio desc

O limiar de desvio deve ser calibrado por criticidade da base e pelo histórico do ambiente, e resultados precisam ser cruzados com janelas de manutenção e rotinas de backup, que naturalmente produzem picos de leitura. O output da caça alimenta a mesma ficha de documentação do padrão de snapshot, com técnica, evidência, veredicto e acompanhamento, mantendo a biblioteca de caças homogênea e auditável.

5. Exemplo de Caça: Exfiltração via Snapshot

A hipótese de caça é formulada no formato da biblioteca: se um ator interno ou externo obtiver credenciais com permissão de snapshot em bancos gerenciados, então é possível exfiltrar a base inteira em uma única operação de compartilhamento externo. A caça busca a sequência criar snapshot, compartilhar snapshot e, opcionalmente, excluir snapshot em janela curta, correlacionando CloudTrail e IAM para entender qual identidade executou e como obteve a permissão.

AWSCloudTrail
| where TimeGenerated > ago(30d)
| where EventName in ("CreateDBSnapshot", "ModifyDBSnapshotAttribute",
        "DeleteDBSnapshot")
| extend Snapshot = tostring(parse_json(RequestParameters).DBSnapshotIdentifier),
         Contas = tostring(parse_json(RequestParameters).AccountIds),
         Executor = tostring(UserIdentityUserName)
| where EventName == "ModifyDBSnapshotAttribute" and isnotempty(Contas)
| project TimeGenerated, Snapshot, Contas, Executor,
          InstanceIdentificada = tostring(parse_json(RequestParameters).DBInstanceIdentifier)
| order by TimeGenerated desc

A consulta acima deve ser lida como esqueleto adaptável ao esquema real de ingestão, porque nomes de campos variam entre conectores e provedores. O roteiro de investigação após o achado segue os passos da tabela abaixo, que também serve de estrutura para o registro da caça no formato de documentação do capítulo 7 da biblioteca.

Os resultados devem registrar a técnica correspondente, T1537 em combinação com T1213.006, e alimentar a métrica de cobertura do MAP.4, porque essa caça só é viável se a organização coleta CloudTrail com data events do serviço de banco gerenciado, requisito que deve estar no inventário de DAT.1. Caças que não produzem achado positivo também produzem valor: provam que a cadeia não ocorreu no período e fundamentam a afirmação de cobertura nos relatórios do grupo MET. Vale registrar a caça em repositório permanente, com a versão do ATT&CK usada no mapeamento, seguindo a disciplina de rastreabilidade recomendada neste capítulo.

6. Priorização e Cobertura do Recorte

Nem todo banco precisa do mesmo nível de cobertura, e a priorização evita espalhar esforço onde o risco é baixo. O critério recomendado combina sensibilidade dos dados, exposição de credenciais em pipelines e desenvolvedores, e maturidade da telemetria disponível. A tabela abaixo sugere uma matriz simples de priorização que pode ser aplicada na revisão anual de cobertura do recorte, em sintonia com MAP.4 e com o inventário de DAT.1.

A métrica de sucesso do recorte é direta: 100 por cento dos bancos de prioridade alta com a cadeia de snapshot detectável e com baseline de leitura ativo. O percentual de bancos classificados e o tempo médio de detecção da cadeia em testes controlados complementam o quadro, e todos entram no dashboard do grupo MET com a mesma rastreabilidade de versão exigida das demais métricas deste capítulo.

Exceções à matriz de priorização devem ser documentadas com justificativa e prazo de revisão, porque bancos mal classificados tendem a ser exatamente os esquecidos nas próximas revisões. A classificação também deve ser reavaliada quando a base muda de dono, de provedor ou de criticidade, e a mudança deve ser registrada com a mesma disciplina de versionamento que o capítulo exige dos mapeamentos.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é monitorar apenas o tráfego de rede do banco e ignorar o plano de controle, exatamente onde a exfiltração via snapshot acontece sem nenhum fluxo direto para fora. O segundo erro é tratar a sub-técnica Databases como se cobrisse só bancos relacionais corporativos; o recorte inclui repositórios diversos, e instâncias gerenciadas de analytics e de busca merecem a mesma análise de permissões. O terceiro erro é confiar que a proteção por rede privada resolve o problema, quando o vetor dominante é credencial válida dentro do próprio ambiente, como mostram campanhas de roubo de token associadas a atores como os registrados na v19.2 no contexto de ambientes cloud e de desenvolvedor.

Cuidado também com a janela de retenção dos logs de controle. Operações de snapshot compartilhado e exclusão posterior podem ocorrer em minutos, e retenções curtas de CloudTrail ou de logs de banco fazem a caça chegar depois da prova ter desaparecido. Por fim, evite mapear cada operação administrativa do provedor como técnica ATT&CK sem contexto; o mapeamento correto parte do comportamento do adversário, não do nome do evento, e registra o par evento e técnica apenas quando existe justificativa de ameaça.

8. Integração com o Restante da Biblioteca

Esta nota aprofunda o recorte de dados em cloud e se apoia em três leituras complementares: Hunting em Cloud e SaaS, do capítulo 8, para as hipóteses gerais e consultas de caça, DAT.1 e DAT.4, para o inventário de fontes e a centralização no SIEM, e MAP.4, para registrar a cobertura obtida com as detecções da seção 4. Os padrões de roubo de token discutidos aqui também conversam com a nota de Hunting de Identidade e Autenticação, pois o ciclo de vida de credenciais cloud é a raiz da maior parte dos incidentes do recorte.

O exercício final recomendado é aplicado: listar os bancos gerenciados da organização por provedor, levantar quem tem permissão de snapshot e de compartilhamento, verificar se a cadeia de eventos da seção 5 é capturada hoje no SIEM e, em caso negativo, abrir o item de coleta correspondente. Esse exercício conecta o capítulo de atualizações do ATT&CK ao dado mais valioso que a organização tem, e transforma o estudo das release notes em redução concreta de risco.

Três entregas concretas fecham o exercício e garantem que o estudo não fica no papel: a matriz de priorização preenchida, o item de coleta aberto ou confirmado e a caça da seção 5 registrada no repositório de caças com versão do ATT&CK anotada.