HazyBeacon Malware Uses AWS Lambda URLs to Hide Command-and-Control Traffic

HazyBeacon is a Windows backdoor used in a cyber-espionage campaign against government entities in Southeast Asia. The malware stands out because it uses AWS Lambda URLs as part of its command-and-control communication, helping attacker traffic blend into normal cloud activity.

The campaign is tracked by Palo Alto Networks Unit 42 as CL-STA-1020. Unit 42 said the activity has been tracked since late 2024 and appears focused on intelligence gathering, including sensitive government data tied to tariffs and trade disputes.

Qualys later highlighted the case as an example of cloud-native command-and-control abuse. In its HazyBeacon analysis, the company said attackers can use Lambda Function URLs configured with public access to relay malware communications through trusted cloud infrastructure.

How HazyBeacon hides behind AWS traffic

Traditional malware often communicates with attacker-owned servers that defenders can block using IP reputation, domain intelligence, or network filtering. HazyBeacon makes that harder by placing a trusted cloud service in the middle of the communication path.

AWS Lambda Function URLs are HTTPS endpoints that allow direct access to Lambda functions. According to AWS Lambda documentation, function URLs can use either AWS_IAM authentication or NONE as the authentication type.

When a function URL uses public access, malware traffic can appear as normal HTTPS communication to an AWS-hosted domain. That makes the traffic harder to separate from legitimate cloud use, especially in organizations that already rely heavily on AWS services.

Item	Details
Campaign tracking name	CL-STA-1020
Malware name	HazyBeacon
Main target region	Southeast Asia
Primary victims	Government entities
Technique	Command-and-control through AWS Lambda Function URLs
Reported goal	Covert intelligence gathering and data collection

The campaign abuses legitimate cloud features

The HazyBeacon activity does not point to a flaw in AWS itself. Qualys said the abuse relies on stolen IAM credentials and misconfigured permissions, not a vulnerability in AWS services.

The key risk comes from public or overly permissive function URLs. AWS says that when a function URL uses AuthType NONE and its resource-based policy grants public access, any unauthenticated user with the URL can invoke the function, according to its Lambda access control guidance.

That public endpoint can act as a relay. The infected machine connects to the Lambda URL, the function forwards traffic to attacker infrastructure, and the response travels back through the same trusted cloud service.

What Unit 42 observed in the attack chain

Unit 42 said attackers deployed HazyBeacon through DLL sideloading. A malicious DLL was placed alongside a legitimate Windows executable, allowing the malware to load in a way that looked less suspicious than a standalone malicious process.

Once running, the backdoor connected to an attacker-controlled Lambda URL hosted in the ap-southeast-1 region. The Unit 42 report said the malware then received commands and downloaded additional payloads.

Those payloads included file collection tools, a legitimate 7-Zip utility used to archive data, and custom upload tools for Google Drive and Dropbox. Unit 42 said the attackers also ran targeted searches for documents related to trade issues before attempting exfiltration.

• HazyBeacon established command-and-control through an AWS Lambda URL.
• Attackers used DLL sideloading to help deploy the backdoor.
• The malware downloaded additional tools into the C:\ProgramData directory.
• The attackers collected and archived files from compromised systems.
• They attempted to use Google Drive and Dropbox as exfiltration channels.

Why Lambda Function URLs can be attractive to attackers

Lambda Function URLs are useful for developers because they provide direct HTTPS access to serverless functions without requiring API Gateway. This makes deployment simple and fast for legitimate teams.

The same simplicity can help attackers when credentials are stolen or cloud controls are weak. AWS explains that setting AuthType to NONE bypasses IAM authentication and allows anyone to make requests to the function URL, if the necessary resource policy also permits access.

The risk increases when organizations do not monitor the creation, update, or invocation of function URLs. In that environment, attackers can create a relay that looks like routine cloud traffic until defenders inspect behavior, identity use, and configuration changes.

How defenders can detect Lambda URL abuse

Security teams should start with identity. AWS recommends phishing-resistant MFA where possible, temporary credentials instead of long-term access keys, least-privilege policies, and IAM Access Analyzer to review public or cross-account access in its IAM best practices.

Organizations should also review Lambda Function URL creation events, public resource policies, unusual invocation spikes, and unexpected Lambda costs. Lambda relays used for C2 may generate patterns that differ from normal application workloads.

Network teams should avoid treating all traffic to trusted cloud domains as safe. HazyBeacon shows that attackers can hide behind reputable infrastructure, so detection must combine endpoint telemetry, DNS visibility, cloud audit logs, and identity behavior.

1. Inventory Lambda Function URLs across all AWS accounts and regions.
2. Flag function URLs using AuthType NONE unless they have a documented business need.
3. Review resource-based policies that allow public invocation.
4. Monitor CloudTrail for CreateFunctionUrlConfig and UpdateFunctionUrlConfig events.
5. Rotate exposed access keys and remove long-term credentials where possible.
6. Use service control policies to restrict risky Lambda Function URL configurations.
7. Review endpoint logs for suspicious connections to lambda-url regional domains.

What AWS administrators should harden now

Administrators should prefer AWS_IAM authentication for private or internal Lambda Function URLs. Public function URLs should remain limited to specific use cases, and teams should document why public access is necessary.

The AWS access control documentation also notes that permissions for function URLs depend on both AuthType and resource-based policies. That means administrators must review both settings, not only the visible URL configuration.

For larger environments, security leaders should use organization-level guardrails. AWS recommends service control policies as permissions guardrails across accounts, and its IAM guidance also encourages reducing unused users, roles, permissions, policies, and credentials.

A warning for cloud-heavy organizations

HazyBeacon shows how attackers can turn trusted cloud services into operational infrastructure. The technique gives them scale, reliability, and a way to hide in environments where cloud communication is already common.

The lesson is not that Lambda Function URLs are unsafe by default. The lesson is that public endpoints, stolen credentials, and weak monitoring can create a stealthy path for attacker operations.

As Qualys explains in its cloud-native C2 write-up, defenders need identity-centric controls, global logging, VPC flow telemetry, and continuous configuration monitoring to reduce this risk. The Lambda Function URL configuration guide also makes clear that authentication settings decide whether a function URL stays restricted or becomes publicly reachable.

FAQ