Uma nova campanha de malware está transformando a infraestrutura em nuvem confiada contra as organizações que dependem dela. Conhecida como HazyBeacon e rastreada sob o identificador de cluster CL-STA-1020, a campanha visa redes governamentais no Sudeste Asiático. Em vez de usar servidores facilmente bloqueados, os atores de ameaças se escondem dentro de uma das plataformas mais confiadas do mundo, a Amazon Web Services (AWS).
Descoberta e escopo da campanha
O que diferencia esta campanha é como ela se comunica com as máquinas infectadas. Os atacantes comprometem contas da AWS pertencentes a organizações não relacionadas e implantam funções serverless leves dentro delas como pontos de relé ocultos. Para qualquer equipe de segurança monitorando o tráfego, as comunicações parecem conexões HTTPS criptografadas de rotina para a própria infraestrutura da Amazon. Pesquisadores da Qualys disseram em um relatório compartilhado com a Cyber Security News (CSN) que a campanha foi originalmente documentada pela Palo Alto Networks Unit 42 em julho de 2025.
A análise da Qualys detalha as mecânicas técnicas e descreve como os defensores podem detectar e parar essa ameaça nativa da nuvem. Uma vez que o HazyBeacon instala em uma máquina Windows vítima, ele funciona como um backdoor leve. Ele coleta detalhes do sistema como nome do host, endereço IP e privilégios de usuário. Ele recebe comandos criptografados para executar instruções de shell ou baixar payloads adicionais. Ele sobe silenciosamente documentos roubados e teclas capturadas para os atacantes.
Mecânica de ataque e infraestrutura
O núcleo deste ataque é o abuso das URLs de Função Lambda da AWS, introduzidas em abril de 2022. Essas URLs expõem uma função serverless diretamente à internet sem exigir serviços como API Gateway. Essa simplicidade é útil para desenvolvedores, mas fácil de ser armada. As URLs de Função Lambda oferecem dois modos de autenticação. Um exige que os chamadores assinem com credenciais IAM válidas, enquanto o outro, chamado AuthType: NONE, permite que qualquer um envie solicitações sem autenticação.
Os atacantes escolhem essa opção para criar um relé HTTPS público dentro da infraestrutura da AWS em segundos. Como o domínio de ponto final termina em on.aws, o tráfego se mistura com serviços Amazon confiados. O relé funciona como um intermediário silencioso. O malware envia um POST HTTP criptografado para uma URL Lambda dentro de uma conta AWS comprometida diferente. Essa função remove os cabeçalhos e encaminha o payload para o servidor backend real do atacante, que responde através do mesmo caminho.
Nem a vítima do malware nem o proprietário da conta da AWS geralmente sabem que algo está errado até que chegue um aviso de abuso ou uma conta inesperada. O ataque segue uma cadeia de morte previsível enraizada na higiene de identidade ruim. Os atacantes validam chaves roubadas com chamadas de API silenciosas, sobem um payload Python ou Node.js compactado como uma função Lambda com um nome benigno como "UpdateWorker" e implantam em uma região AWS de baixa vigilância para evitar detecção.
Defesas e mitigação
O primeiro passo mais importante é uma higiene IAM forte. As equipes devem desativar chaves de acesso não utilizadas, impor rotação regular e exigir autenticação multifator em contas de nuvem. Esses controles cortam o ponto de entrada primário no qual esta campanha depende. Habilitar o registro do AWS CloudTrail em todas as regiões é igualmente crítico. O CloudTrail registra todas as chamadas de API usadas para criar funções Lambda e URLs de Função, expondo implantações não autorizadas mesmo em regiões raramente vigiadas.
Identificar atividade anômala durante o reconhecimento pode revelar credenciais comprometidas antes que um relé entre no ar. As organizações também podem aplicar Políticas de Controle de Serviço no nível da Organização AWS para bloquear URLs de Função Lambda configuradas com AuthType: NONE, a menos que explicitamente aprovadas por tag. Isso impede que um relé público seja implantado mesmo com credenciais roubadas válidas. Roteamento de cargas de trabalho Lambda através de uma VPC adiciona outra camada de detecção, pois o tráfego de relé produz um padrão de entrada para saída um-para-um visível nos logs de fluxo.
Monitorar anomalias de custo Lambda completa a defesa. Um relé servindo muitas máquinas infectadas gera volumes de invocação maciços que aparecem como picos de faturamento, especialmente em regiões não de produção. Alertas de orçamento AWS granulares podem revelar esse abuso antes que ele escale.
Monitoramento e resposta
Para equipes de SOC, a detecção deve focar em padrões de tráfego incomuns para domínios on.aws que não são esperados. O uso de ferramentas de detecção de ameaças em nuvem (CTI) pode ajudar a identificar funções Lambda com configurações de URL públicas. A revisão regular de permissões IAM e a auditoria de funções Lambda implantadas são essenciais para prevenir a reutilização de contas comprometidas. A implementação de políticas de segurança que restringem a criação de URLs Lambda públicas sem aprovação explícita é uma medida proativa recomendada.
Perguntas frequentes
Qual é o objetivo da campanha? A campanha visa redes governamentais no Sudeste Asiático para coleta de dados e controle remoto.
Como mitigar? Revise permissões IAM, desative chaves antigas e monitore o CloudTrail para implantações de Lambda não autorizadas.
É uma falha na AWS? Não, a campanha explora más práticas de configuração e credenciais roubadas, não falhas na plataforma AWS.