HazyBeacon: Weaponizing AWS Lambda for Stealthy Command-and-Control Relays

A sophisticated cyber espionage operation, identified as HazyBeacon (tracked by researchers as CL-STA-1020), has emerged, signaling a strategic pivot toward “living off the cloud” tactics. By leveraging Amazon Web Services (AWS) as a tactical layer, the threat actors are constructing highly resilient, stealthy Command-and-Control (C2) channels designed to bypass traditional perimeter defenses. The campaign is currently focused on high-value government targets across Southeast Asia.

Unlike traditional C2 models that rely on external, attacker-owned Virtual Private Servers (VPS) or known malicious domains—which security teams can easily block via IP reputation and threat intelligence—HazyBeacon operates entirely within the “trust boundary” of legitimate cloud environments. This effectively masks malicious traffic as standard, encrypted cloud activity.

The Lifecycle of the Attack: From Credential Theft to Cloud Deployment

The operation begins with the compromise of Identity and Access Management (IAM) credentials. Threat actors acquire these through several common vectors: harvesting exposed keys from public code repositories, targeted phishing, or extracting local credential files from compromised developer workstations.

Once the attackers gain a foothold, they perform low-noise reconnaissance using legitimate AWS API calls to determine the scope of their permissions. Their primary objective is to identify if the compromised account allows for the creation of AWS Lambda functions and the configuration of public endpoints.

According to technical research published by Palo Alto Networks Unit 42, the attackers specifically exploit AWS Lambda Function URLs. By setting the AuthType to NONE, they create unauthenticated, publicly accessible HTTPS endpoints that require no specialized authentication to trigger.

Architecting the “Middleman” Proxy

The execution phase involves the rapid deployment of lightweight, purpose-built Lambda functions. To avoid detection by cloud administrators, these functions are often given benign names (e.g., “SystemUpdateService” or “LogProcessor”) and are deployed in secondary AWS regions that are rarely monitored by the victim organization.

The Lambda function functions as a sophisticated proxy:

• Infection Phase: Malware residing on a compromised endpoint sends encrypted HTTP requests to the Lambda Function URL.
• Relay Phase: The Lambda function intercepts the request and forwards the payload to the attacker’s actual backend server.
• Instruction Phase: The backend sends commands back through the Lambda function, which then relays them to the malware.

This architecture creates a “middleman” effect. From the perspective of a network defender, the outbound traffic appears to be a legitimate connection to a trusted *.on.aws domain. Simultaneously, the attacker’s backend sees incoming traffic originating from the legitimate AWS infrastructure, making attribution and IP-based blocking nearly impossible without disrupting actual business operations.

The malware itself is highly modular, capable of performing host enumeration, remote command execution, and the exfiltration of sensitive documents and keystroke logs.

Defense and Mitigation Strategies

It is critical to note that HazyBeacon does not exploit a vulnerability in the AWS platform itself; rather, it exploits misconfigurations and identity mismanagement. To defend against this cloud-native threat, organizations must move beyond traditional network security and focus on identity governance.

Recommended defensive postures include:

• Strict IAM Governance: Enforce the Principle of Least Privilege (PoLP) and implement mandatory rotation for all access keys.
• Enhanced Visibility: Enable and centralize AWS CloudTrail logging to monitor for unusual API calls and Lambda creation events.
• Configuration Guardrails: Utilize Service Control Policies (SCPs) to restrict the ability to create Lambda Function URLs with AuthType: NONE.
• Network Monitoring: Analyze VPC Flow Logs for anomalous patterns of communication with internal cloud services.

MITRE ATT&CK Mapping