Uma integração esquecida pode continuar de portas abertas muito depois de a equipe parar de usá-la. Foi exatamente essa relação de confiança que invasores exploraram em ambientes da Amazon Web Services ligados à plataforma de dados Qubole, segundo uma investigação da Wiz com participação da Sentra e da Mandiant.
Os pesquisadores observaram credenciais associadas a uma conta AWS usada pela Qubole sendo empregadas para assumir funções criadas por clientes em suas próprias contas. Em ambientes afetados, os responsáveis enumeraram recursos, coletaram segredos e acessaram dados no Amazon S3. O caso descrito envolve confiança concedida a um terceiro; a pesquisa não afirma que a infraestrutura central da AWS tenha sido comprometida.
O que é uma função entre contas?
Uma aplicação externa pode precisar operar recursos que pertencem ao cliente. Na AWS, uma forma de permitir isso é criar uma função IAM com uma política de confiança que autoriza uma conta ou identidade externa a assumi-la. Em vez de entregar uma chave permanente da conta do cliente, a integração pode receber credenciais temporárias para executar as ações permitidas.
Esse mecanismo tem usos legítimos. A questão é que a confiança continua valendo enquanto a política permitir, mesmo quando o projeto que justificou a integração já foi encerrado. Se uma identidade do lado autorizado for comprometida, o invasor pode tentar usar essa relação existente para entrar pela porta que a própria organização criou.
Os pesquisadores identificaram exatamente esse padrão. Algumas funções ainda aceitavam acesso mesmo sem atividade legítima recente do serviço. A falta de uso, por si só, não revoga permissões: para a plataforma de identidade, uma autorização antiga ainda é uma autorização até que alguém a altere.
O que os invasores fizeram depois?
Depois de assumir funções em ambientes de clientes, o invasor consultou recursos em busca do que conseguia acessar. A Wiz relata interesse em configurações de funções Lambda, no Secrets Manager e no Systems Manager Parameter Store — locais que podem conter senhas, tokens e configurações sensíveis de aplicações.
Os pesquisadores também observaram credenciais encontradas nos ambientes sendo testadas contra diferentes serviços. Uma chave válida não significa que seu uso seja legítimo: autenticar e autorizar são etapas distintas, e uma credencial roubada pode passar pela primeira se ainda não tiver sido revogada.
No Amazon S3, a atividade observada incluiu descoberta de buckets e leitura de objetos. Em alguns casos, dados foram baixados. A extensão do acesso dependia das permissões de cada função; não é correto presumir que todos os clientes tiveram os mesmos dados expostos ou sofreram o mesmo impacto.
O CloudTrail mostra tudo?
Não necessariamente. A pesquisa chama atenção para uma distinção importante: eventos de gerenciamento do CloudTrail podem registrar a assunção da função e operações de descoberta, mas leituras de objetos S3 dependem da configuração dos eventos de dados apropriados ou de outros registros disponíveis.
Essa diferença pode determinar o que a equipe consegue reconstruir depois do incidente. Se o registro de acesso a objetos não estava habilitado para um bucket, a ausência de um evento naquele conjunto de logs não é prova de que nenhum objeto tenha sido lido. É uma limitação de visibilidade que precisa ser considerada na investigação.
Antes de um problema, vale escolher quais buckets exigem registros detalhados, avaliar custos e retenção e testar como a equipe consultará esses dados. Segurança que só existe no diagrama não ajuda muito quando alguém precisa responder, com urgência, o que uma função realmente acessou.
Rotacionar chaves resolve sozinho?
Rotacionar uma credencial exposta é uma parte importante da resposta, mas o caso também envolve funções assumidas e sessões temporárias. A orientação precisa levar em conta quais sessões estavam ativas, o que cada função podia ler e quais segredos adicionais podem ter sido descobertos.
Isso inclui revisar políticas de confiança e restringir permissões, de preferência com os mecanismos documentados pelo fornecedor e pela AWS. Restrições de origem e identificação de integrações podem ajudar, desde que sejam compatíveis com o serviço e testadas. Uma política excessivamente ampla pode facilitar o movimento do invasor; uma alteração improvisada também pode interromper aplicações legítimas.
A Wiz identificou ainda outra atividade relacionada a integrações Qubole, mas não conseguiu ligá-la definitivamente à campanha principal. Essa ressalva não é detalhe: padrões parecidos e infraestrutura envolvendo o mesmo fornecedor não bastam para provar que todos os eventos pertencem ao mesmo grupo ou operação.
O problema maior é o acesso esquecido
Organizações acumulam fornecedores, provas de conceito, ambientes temporários e contas de teste. Cada integração pode deixar para trás uma função, um segredo ou uma exceção que parecia razoável quando foi criada. Meses depois, a pessoa que conhecia a origem daquele acesso pode ter mudado de equipe e a documentação pode estar desatualizada.
O incidente mostra por que o ciclo de vida de uma integração deve incluir sua retirada. Quando um serviço deixa de ser usado, é preciso identificar e remover a confiança que ele recebeu, além de verificar tokens e permissões relacionadas. Não se trata de desconectar tudo às pressas: o primeiro passo é descobrir o que existe e quem depende disso.
⚡ Veredicto GeekZilla
A integração funcionou como havia sido configurada — inclusive quando ninguém mais lembrava por que ela existia. Esse é o incômodo do caso: acesso legítimo no papel pode virar uma rota para um invasor quando a identidade confiável cai em mãos erradas. Revise suas relações entre contas, registre o que é necessário e trate a retirada de um fornecedor como parte da implantação, não como um detalhe para a próxima auditoria.
