Uma campanha em andamento está usando credenciais IAM comprometidas para acionar mineração de criptomoedas em contas AWS, explorando privilégios administrativos para orquestrar recursos em EC2 e ECS em poucos minutos após o primeiro acesso.
O ataque se destaca pela combinação do uso abusivo de APIs como RunInstances (DryRun), criação massiva de clusters ECS, autoscaling agressivo e um truque de persistência via ModifyInstanceAttributeque impedem o encerramento de instâncias e dificultam a resposta a incidentes.
Como começa o ataque na AWS
O ator parte das credenciais IAM de usuário com privilégios semelhantes ao administrador e, a partir de uma infraestrutura externa, faz um reconhecimento rápido do ambiente.
Ele enumera recursos e permissões e testa limites do EC2 usando a API RunInstances com o parâmetro DryRun ativado, validando o que pode fazer sem de fato subir instâncias, o que evita custos imediatos e reduz os vestígios.
Em seguida, chamamos CreateServiceLinkedRole e CreateRole para criar funções IAM usadas por grupos de auto scaling e funções Lambda, anexando à função Lambda a política AWSLambdaBasicExecutionRole.
Com essa base de permissões, a operadora prepara o terreno para orquestrar recursos de distribuição distribuídos no ambiente da vítima.
Mineração em ECS Fargate e EC2 em escala
Na fase seguinte, os especialistas criam amostras de clusters ECS — em alguns ataques, mais de 50 clusters em um único ambiente — e registram uma definição de tarefa apontando para a imagem maliciosa do DockerHub yenik65958/secret:user.
Usando o mesmo identificador em clusters e serviços, ele cria serviços ECS Fargate que disparam a execução da imagem, cuja configuração inclui um script de inicialização que lança mineração com o algoritmo RandomVIREL.
Paralelamente, o operador configura grupos de auto scaling em EC2 com limites agressivos, por exemplo, escalando de 20 até 999 instâncias, com foco tanto em tipos de GPU/ML quanto em instâncias de computação, memória e uso geral, para maximizar o consumo de recursos e o ganho financeiro.
Em casos observados, mineradores já estavam operando menos de 10 minutos após o primeiro acesso, demonstrando automação pesada da cadeia de ataque.
Persistência via proteção de terminação
O principal diferencial tático da campanha é o uso da ação ModifyInstanceAttribute com o parâmetro disableApiTermination configurado como True em instâncias EC2 usadas para mineração.
Esse ajuste impede que as instâncias sejam encerradas pelo console, CLI ou API até que alguém reabilite manualmente a terminação via API, o que pode confundir vezes de resposta e playbooks automatizados que esperam conseguir destruir recursos comprometidos diretamente.
A Amazon observa que essa técnica evidencia conhecimento dos fluxos típicos de resposta a incidentes em nuvem e intenção clara de manter o minerador ativo pelo maior tempo possível.
O risco de ModifyInstanceAttribute já havia sido demonstrado em 2024 por Harsha Koushik em um PoC que mostrou como a ação pode ser abusada para tomar instâncias, exfiltrar credenciais de funções e até ganhar controle total da conta AWS.
SES, Lambda aberta e possível phishing
Além da mineração, o ator cria uma função Lambda invocável por qualquer principal e um usuário IAM “user‑x1x2x3x4” ao qual atribui a política gerenciada AmazonSESFullAccess.
Isso concede controle completo sobre o Amazon SES, permitindo potencial envio de grandes volumes de e-mails com alta entregabilidade, possivelmente para campanhas de phishing ou spam abusando da recompensa da conta da vítima.
O uso combinado de Lambda e SES também pode servir como canal de comando e controle ou para notificações internacionais do próprio ator (por exemplo, alertas de sucesso de mineração ou de bloqueios).
Em conjunto com o escalonamento agressivo e proteção de terminação, esse arsenal torna a campanha uma evolução relevante nas táticas de criptojacking em nuvem, segundo a Amazon.
Medidas de defesa recomendadas pela Amazon
Para mitigar o risco, a Amazon orienta fortalecer o controle de identidade e acesso: substituir chaves de longo prazo por credenciais temporárias, aplicar MFA a todos os usuários e adotar o princípio do menor privilégio (PoLP) para usuários e funções IAM.
Também é recomendado adicionar controles de segurança de contêiner para escanear imagens suspeitas, monitorar instruções de CPU/memória em definições de tarefa ECS e revisar revisões para ações sensíveis como ModifyInstanceAttribute.
Em nível de observabilidade, a empresa destaca a importância de ter AWS CloudTrail habilitado para todos os serviços, usar GuardDuty para detecção de ameaças inteligentes e integrar esses eventos a fluxos de trabalho de resposta automática.
Os clientes ainda devem monitorar padrões anômalos de criação de clusters ECS, grupos de auto scaling com limites fora do normal, e o surgimento de usuários/funções inesperadas ligadas a SES e Lambda — sinais fortes de uma operação de criptojacking em andamento.
