HazyBeacon Campaign Abuses AWS Lambda URLs for Stealthy Malware Communications

Security researchers are warning about HazyBeacon, a Windows backdoor campaign that abuses Amazon Web Services infrastructure to hide command-and-control traffic inside trusted cloud communications.

The activity, tracked as CL-STA-1020, targets government organizations in Southeast Asia. Palo Alto Networks Unit 42 first detailed the campaign in July 2025, while a newer Qualys analysis explains how attackers can turn serverless cloud features into stealthy relay infrastructure.

The campaign stands out because the malware does not rely on a suspicious attacker-owned server. Instead, it communicates through AWS Lambda Function URLs, making traffic look like normal encrypted HTTPS activity to Amazon’s cloud infrastructure.

How HazyBeacon hides inside trusted AWS traffic

HazyBeacon works as a lightweight Windows backdoor. Once active, it can collect system details, receive commands, download additional tools, and help attackers steal files from compromised government networks.

Unit 42 said the backdoor used AWS Lambda URLs for command and control. AWS launched Lambda Function URLs in 2022 as a simple way to give a Lambda function a dedicated HTTPS endpoint without requiring Amazon API Gateway or an Application Load Balancer.

That feature has legitimate uses for developers. In this campaign, however, attackers used it as a relay. The infected machine contacted a Lambda URL, the Lambda function forwarded the request to the real attacker-controlled backend, and the command returned through the same cloud path.

The campaign abuses credentials, not an AWS flaw

The important point for cloud teams is that HazyBeacon does not exploit a vulnerability in AWS Lambda. The attack relies on stolen or exposed cloud credentials, weak identity controls, and Lambda Function URLs that attackers can expose to the internet.

AWS documentation explains that Lambda Function URLs can use AWS_IAM authentication or NONE. When NONE combines with a public resource-based policy, anyone with the function URL can invoke it.

Qualys said attackers can use compromised IAM credentials to create Lambda functions, configure public Function URLs, and deploy relay code under harmless-looking function names. The result gives malware a trusted cloud endpoint that many network filters may not block by default.

Campaign detail	What researchers reported
Campaign name	HazyBeacon
Cluster identifier	CL-STA-1020
Primary targets	Government organizations in Southeast Asia
Main technique	Command and control through AWS Lambda Function URLs
Cloud risk	Compromised AWS accounts used as relay infrastructure
AWS vulnerability involved	No, researchers describe abuse of legitimate cloud features

Why Lambda Function URLs make detection harder

Traditional malware detection often looks for unusual domains, suspicious hosting providers, or known attacker infrastructure. HazyBeacon complicates that model because infected machines communicate with AWS-hosted endpoints that can look normal in enterprise traffic logs.

The original Unit 42 report also said the attackers used legitimate services, including Google Drive and Dropbox, during attempted exfiltration. That continued the same pattern: blend malicious activity into services that organizations already trust.

Qualys describes this as a borrowed infrastructure attack. The attacker does not need to own the visible relay. A compromised cloud account can host the Lambda function, while the attacker’s real backend stays hidden behind Amazon-hosted traffic.

How attackers can build a Lambda relay

The attack chain starts with cloud identity compromise. Attackers may obtain static IAM access keys from exposed repositories, phishing campaigns, malware, or poorly protected developer environments.

After that, they can validate the credentials with low-noise API calls, check permissions, and deploy a small Python or Node.js Lambda function. If the account allows public Function URLs, the attackers can expose that function as an internet-facing HTTPS relay.

AWS introduced the feature to simplify single-function web endpoints. The same simplicity gives attackers a fast way to create infrastructure if defenders fail to monitor identity use and serverless deployments.

• Attackers steal or find valid AWS credentials.
• They test the account quietly through normal AWS API calls.
• They create a Lambda function with relay logic.
• They expose it through a public Function URL.
• Malware traffic flows through the AWS-hosted endpoint.

What defenders should monitor

CloudTrail visibility is one of the most important defenses. AWS CloudTrail records Lambda API calls, including activity from the console and Lambda API operations. That makes it useful for spotting unexpected Function URL creation and unusual Lambda changes.

Organizations should monitor for CreateFunction, CreateFunctionUrlConfig, AddPermission, UpdateFunctionCode, and related Lambda events across every region. Attackers may choose quieter regions to avoid routine review.

The latest Qualys report recommends strong IAM hygiene, global logging, VPC flow telemetry where possible, and policy controls that restrict public Function URLs unless teams explicitly approve them.

Defense area	Action to take	Why it helps
IAM credentials	Disable unused access keys and rotate active keys regularly	Reduces the chance that old static keys can deploy attacker infrastructure
Function URLs	Restrict public AuthType NONE usage	Limits unauthenticated Lambda endpoints that can act as relays
CloudTrail	Log Lambda activity across all regions	Exposes unauthorized deployments in overlooked regions
Billing	Alert on sudden Lambda invocation spikes	Relay abuse can create unusual serverless usage volume
Network telemetry	Review relay-like inbound and outbound Lambda patterns	Command relays often show repeated proxy behavior

Public Function URLs need stricter controls

Many organizations use public Lambda Function URLs for valid reasons, such as webhooks, lightweight APIs, or simple public services. The risk appears when cloud accounts allow anyone to create those endpoints without review, tagging, or policy enforcement.

AWS access guidance makes clear that the NONE authentication mode bypasses IAM request signing for invocation. Security teams should treat every public Function URL as an exposed internet endpoint, not merely as an internal serverless setting.

Enterprises can use Service Control Policies to define maximum permissions across AWS accounts in an organization. That gives security teams a way to block risky deployment paths even when a compromised identity has broad permissions inside a member account.

Cloud command-and-control is becoming harder to spot

HazyBeacon shows how modern malware can use normal cloud features to reduce suspicion. Instead of hiding in obscure infrastructure, attackers hide behind services that enterprises already use every day.

That shift makes identity controls more important than domain blocking alone. If attackers can steal valid cloud keys and create resources with normal APIs, defenders must detect the behavior inside the cloud control plane.

Cloud teams should also watch for unexpected Lambda activity in accounts that do not normally run serverless workloads. New functions, public URLs, sudden invocations, unfamiliar regions, and unexplained cost spikes can all point to abuse.

Key steps for AWS security teams

Organizations should start by reviewing every Lambda Function URL across all accounts and regions. Public endpoints should have a clear owner, a business reason, restrictive policy controls, and monitoring.

Security teams should also review Lambda API activity in CloudTrail and set detections for new public Function URLs. This matters most in development, test, and rarely used cloud accounts, where exposed keys and weak governance often persist longer.

Finally, administrators should apply organization-level guardrails before attackers get access. Strong IAM controls, all-region logging, approved public endpoint workflows, and budget alerts can stop a compromised AWS account from becoming malware infrastructure.

FAQ