The HazyBeacon Protocol – How Malware Weaponizes Amazon Web Services (AWS) Lambda Function URLs

Summary

Palo Alto Networks Unit 42 documented the HazyBeacon campaign, which abuses AWS Lambda Function URLs configured with no authentication (AuthType: NONE) to operate as stealth command-and-control relays. Attackers use stolen IAM credentials to deploy Lambda functions that proxy malware communications through trusted AWS domains, making the traffic appear legitimate to network defenses. The attack represents a shift toward 'borrowed infrastructure' attacks where adversaries deploy C2 inside compromised cloud accounts rather than attacker-controlled servers.

Full text

Table of ContentsThe Rise of Cloud-Native Command and Control (C2)Borrowed Infrastructure AttacksMITRE ATT&CK Deep Dive: Mapping the Serverless Attack SurfaceHow to Prevent Cloud Infrastructure from Becoming Command InfrastructureHigh-Signal Controls for Detecting and Restricting Lambda AbuseOperationalizing Cloud Infrastructure Defense with Qualys TotalCloudClosing the Door on Cloud-Native MalwareFrequently Asked Questions (FAQs) Key Takeaways HazyBeacon (CL-STA-1020) targets Southeast Asian government networks by abusing AWS Lambda Function URLs configured with AuthType: NONE as stealth command-and-control relays. Attackers use stolen IAM credentials to deploy Lambda functions that proxy malware communications through trusted AWS domains. Organizations can reduce exposure by enforcing identity-centric access controls, enabling global CloudTrail logging, enabling VPC flow telemetry, and implementing Service Control Policies that restrict Lambda Function URL exposure, all supported by continuous configuration monitoring. The Rise of Cloud-Native Command and Control (C2) Command and control (C2) infrastructure traditionally lived outside the victim environment. Malware beaconed to attacker-operated servers hosted on rented VPS infrastructure or compromised websites, and defenders focused on identifying those endpoints through IP reputation, domain intelligence, and network blocking. Cloud computing has started to blur that boundary. In some campaigns, the infrastructure issuing commands is no longer owned by the attacker at all. It is deployed inside legitimate cloud platforms using stolen IAM credentials and standard service features such as serverless compute and public HTTPS endpoints. The HazyBeacon campaign documented by Palo Alto Networks Unit 42 in July 2025 illustrates this shift. Infected systems communicated with AWS Lambda Function URLs hosted inside Amazon infrastructure. To most network defenses, the traffic appeared as ordinary HTTPS traffic to a trusted cloud service, while the Lambda function itself operated as a relay for an attacker-controlled command-and-control infrastructure. Qualys InsightsAs software delivery accelerates, visibility becomes a defining security capability. Discover the trends, challenges, and priorities influencing cloud security leaders in 2026.Know More Borrowed Infrastructure Attacks HazyBeacon reflects an emerging model of cloud-enabled cyber operations. Instead of hosting command servers on attacker-controlled systems, adversaries deploy infrastructure inside compromised cloud accounts. In this model, the victim environment becomes part of the attacker’s operational stack. A typical Borrowed Infrastructure Attack follows four stages: A credential compromise grants access to a cloud account. Infrastructure is deployed using legitimate cloud APIs. Malware communications are routed through trusted cloud endpoints. Attribution becomes difficult because the infrastructure is owned by an unrelated organization. This approach offers several operational advantages for attackers. Cloud platforms provide globally distributed infrastructure, elastic scaling, and low-friction deployment through legitimate APIs, allowing to blend malware traffic into legitimate cloud activity. The Malware Payload Once installed on a victim’s endpoint, HazyBeacon operates as a lightweight downloader and execution framework designed to remain flexible and evasive. Its primary functions include: System Enumeration: Gathering hostname, IP address, user privileges, and operating system (OS) version. Remote Task Execution: Receiving encrypted commands to download further payloads or execute shell commands. Data Exfiltration: Uploading stolen documents and captured keystrokes. The Infrastructure Pivot Rather than hosting dedicated command servers, the attackers behind HazyBeacon compromised unrelated AWS accounts and deployed lightweight Lambda-based relays inside those environments. These accounts often belonged to development teams or smaller organizations where IAM credentials had been exposed or poorly governed. Once inside the environment, the attackers deployed Lambda functions that proxied malware communications between infected systems and the real backend command infrastructure. The communication chain typically follows this pattern: Malware (Victim A) sends an encrypted HTTP POST to the Lambda function URL (Victim B’s Account). Lambda strips the headers, logs the basic metadata (for the attacker’s analytics), and forwards the payload to the attacker’s backend server. The attacker’s backend server responds to the Lambda, which relays the command back to the Malware. This “middleman” architecture makes attribution incredibly difficult. The malware victim sees traffic going to Amazon infrastructure. The attacker’s real server sees requests originating from Amazon infrastructure. The victim or the AWS account hosting the Lambda often has no awareness that its resources are participating in a global espionage network until they receive an abuse notice or a massive bill. Why Lambda Function URLs Are the Ultimate C2 Proxy To understand why this attack is so effective, it is important to examine the feature being exploited, i.e., AWS Lambda Function URLs, introduced in April 2022. Before Function URLs, exposing a Lambda function to the public internet required setting up an Amazon API Gateway or an Application Load Balancer (ALB). These services are powerful but complex, logging-heavy, and incur additional costs. They leave a larger footprint. AWS Lambda Function URLs allow developers to expose a serverless function through a dedicated HTTPS endpoint without configuring API Gateway or a load balancer. A typical endpoint looks like: https://<url-id>.lambda-url.<region>.on.aws Crucially, they support two authentication modes: AWS_IAM: Requires the caller to sign requests with valid IAM credentials. NONE: Allows unauthenticated, public access from anywhere on the internet. Threat actors prefer the second option, AuthType: NONE, because it allows them to deploy a public HTTPS relay inside AWS infrastructure within seconds. The “Lookalike” Problem Because the domain ends in on.aws, the endpoint inherits the trust associated with Amazon Web Services domains. To a Security Operations Center (SOC) analyst reviewing network telemetry, the traffic appears indistinguishable from routine AWS activity. The Cloud Infrastructure Kill Chain The deployment of a HazyBeacon command node follows a predictable Cyber Kill Chain rooted in basic cloud hygiene failures. It rarely involves zero-day exploits against AWS itself; instead, attackers exploit basic identity and configuration weaknesses within cloud environments. The attack typically unfolds in several phases: Phase 1: Reconnaissance – Credential Harvesting Credential harvesting provides initial access. Theft of AWS access keys from public GitHub repositories, developer phishing campaigns, or malware harvesting ~/.aws/ credentials. Credentials are typically static IAM keys created long ago and never rotated. No interaction with AWS infrastructure occurs at this stage. Phase 2: Weaponization – Access Validation Access validation follows. Stolen credentials are validated using low-noise API calls. Common commands include aws sts get-caller-identity and aws iam list-attached-user-policies. The attacker enumerates permissions such as lambda:CreateFunction and lambda:CreateFunctionUrlConfig. Phase 3: Delivery and Exploitation – Infrastructure Deployment Infrastructure deployment occurs next. Legitimate AWS APIs are used as the delivery mechanism. A zipped Python or Node.js payload is uploaded as a Lambda function. Functions are given benign names (e.g., UpdateWorker) to evade casual inspection. Deployment often occurs in regions with reduced scrutiny, such as sa-east-1 or eu-north-1. Phase 4: Installation & Command and Control Command channel activation occurs. Persistence is established by creating a Lambda Fu

Indicators of Compromise

• malware — HazyBeacon

Entities