Descoberta e escopo da ameaça
Ambientes em nuvem tornaram-se silenciosamente uma das áreas mais visadas na cibersegurança moderna. À medida que as organizações migram para a nuvem, os serviços que rastreiam a atividade dentro desses ambientes tornaram-se uma prioridade máxima para atacantes. Serviços de log, que registram cada ação tomada dentro de uma conta em nuvem, estão agora sendo armados contra as próprias equipes que dependem deles.
Quando esses registros são adulterados ou redirecionados, as equipes de segurança perdem sua janela mais clara para o que está acontecendo dentro de sua própria infraestrutura. Pesquisadores da Unit 42 identificaram e documentaram esses métodos de ataque em um relatório compartilhado com a Cyber Security News, detalhando como os atacantes visam o log em nuvem de duas maneiras distintas: evasão de defesa e visibilidade contínua.
Vetor e exploração técnica
A evasão de defesa através do log em nuvem assume várias formas. O método mais direto é parar o processo de log completamente. Na AWS, um atacante com as permissões certas pode chamar a API stop-logging em uma trilha específica, interrompendo imediatamente todas as gravações de log no bucket S3 conectado. No Google Cloud, o equivalente é desabilitar um sink, o que impede que as entradas de log alcancem seu destino.
Além de parar os logs, os atacantes podem excluir o bucket de armazenamento inteiramente. Na AWS, isso requer permissões s3:DeleteBucket e s3:DeleteObject. No Google Cloud, um bucket de log excluído entra no estado DELETE_REQUESTED por sete dias antes da remoção permanente. Uma abordagem mais sutil envolve trocar a chave de criptografia que protege os logs com uma chave KMS controlada pelo atacante, revogando o acesso a ela, tornando os logs impossíveis de escrever ou ler.
O quinto método é o envenenamento de log, onde um atacante edita um arquivo de log para remover evidências de sua atividade e o faz upload novamente, invalidando a trilha de auditoria. Uma vez dentro de um ambiente de vítima, atacantes sofisticados não apenas destroem logs. Eles os redirecionam criando um novo recurso de roteamento ou modificando um existente, enviando todos os logs de atividade para o armazenamento que controlam.
Impacto e alcance operacional
A escala do dano é significativa. Ferramentas como plataformas SIEM, sistemas SOAR e produtos de gerenciamento de postura de segurança em nuvem dependem de dados de log limpos e ininterruptos para funcionar. Se esses logs estiverem faltando, alterados ou redirecionados, essas ferramentas ficam cegas. Um atacante operando nesse silêncio pode levar seu tempo, escalar privilégios e acessar dados sensíveis enquanto enfrenta quase nenhuma resistência das equipes de segurança.
Na AWS, isso é feito usando as APIs create-trail ou update-trail com um nome de bucket personalizado. No Google Cloud, as APIs logging.sinks.create ou logging.sinks.update alcançam o mesmo resultado. A partir desse ponto, o atacante recebe um feed em tempo real de tudo o que está acontecendo na conta da vítima, desde alterações de IAM até acesso a dados sensíveis, tudo sem que a vítima saiba.
Medidas de mitigação recomendadas
Para reduzir a exposição, os usuários da AWS devem restringir a API update-trail para usuários altamente privilegiados e bloquear as políticas do bucket S3 para que apenas o CloudTrail possa escrever nelas. A AWS também mantém um histórico de eventos imutável de 90 dias que não pode ser alterado. No Google Cloud, as equipes devem restringir as permissões logging.sinks.update rigidamente.
O bucket de log _Required incorporado fornece um registro imutável que não pode ser modificado ou excluído. Habilitar a validação de integridade de arquivo de log do CloudTrail também é crítico, pois usa verificações criptográficas para detectar se os arquivos de log foram alterados após a entrega. As organizações devem revisar as permissões de IAM relacionadas a logs e garantir que a integridade dos logs seja verificada regularmente.
O que os CISOs devem fazer imediatamente
1. Revisar as permissões de IAM para APIs de log (update-trail, logging.sinks.update) e restringir a usuários de confiança. 2. Habilitar a validação de integridade de arquivo de log no CloudTrail e verificar a configuração de sinks no Google Cloud. 3. Implementar alertas para atividades de exclusão de buckets S3 ou modificação de sinks de log. 4. Garantir que haja um bucket de log imutável ou separado para armazenamento de auditoria crítica. 5. Monitorar tentativas de desabilitação de serviços de log ou redirecionamento de tráfego de log para buckets não autorizados.