A new malware campaign is turning trusted cloud infrastructure against the organizations that rely on it. Known as HazyBeacon and tracked under cluster identifier CL-STA-1020, the campaign targets government networks across Southeast Asia.
Rather than using easily blocked servers, the threat actors hide inside one of the world’s most trusted platforms, Amazon Web Services (AWS).
What sets this campaign apart is how it communicates with infected machines. Attackers compromise AWS accounts belonging to unrelated organizations and plant lightweight serverless functions inside them as hidden relay points.
To any security team watching traffic, the communications look like routine, encrypted HTTPS connections to Amazon’s own infrastructure.
Researchers at Qualys said in a report shared with Cyber Security News (CSN) that the campaign was originally documented by Palo Alto Networks Unit 42 in July 2025.
The Qualys analysis breaks down the technical mechanics and outlines how defenders can detect and stop this cloud-native threat.
Once HazyBeacon installs on a victim’s Windows machine, it works as a lightweight backdoor. It collects system details like hostname, IP address, and user privileges.
It receives encrypted commands to run shell instructions or pull down further payloads. It silently uploads stolen documents and captured keystrokes to the attackers.
The campaign does not exploit flaws in AWS itself. Attackers steal static IAM access keys from exposed GitHub repositories or phishing campaigns, then use those keys to build a relay inside a compromised cloud account.
HazyBeacon Camapign Weaponizes Amazon Web Services
The core of this attack is the abuse of AWS Lambda Function URLs, introduced in April 2022.
These URLs expose a serverless function directly to the internet without requiring services like API Gateway. That simplicity is useful for developers but easy to weaponize.
Lambda Function URLs offer two authentication modes. One requires callers to sign with valid IAM credentials, while the other, called AuthType: NONE, lets anyone send requests without authentication.
Attackers choose this option to spin up a public HTTPS relay inside AWS infrastructure within seconds. Since the endpoint domain ends in on.aws, the traffic blends in with trusted Amazon services.
The relay works as a silent middleman. Malware sends an encrypted HTTP POST to a Lambda URL inside a different compromised AWS account.
That function strips the headers and forwards the payload to the attacker’s real backend server, which responds through the same path.
Neither the malware victim nor the AWS account owner typically knows something is wrong until an abuse notice or unexpected bill arrives.
The attack follows a predictable kill chain rooted in poor identity hygiene. Attackers validate stolen keys with quiet API calls, upload a zipped Python or Node.js payload as a Lambda function with a benign name like “UpdateWorker,” and deploy it in a low-scrutiny AWS region to avoid detection.
Key Defenses Against Lambda-Based Command Relays
The most important first step is strong IAM hygiene. Teams should disable unused access keys, enforce regular rotation, and require multi-factor authentication across cloud accounts. These controls cut off the primary entry point this campaign relies on.
Enabling AWS CloudTrail logging across all regions is equally critical. CloudTrail records every API call used to create Lambda functions and Function URLs, exposing unauthorized deployments even in rarely watched regions.
Spotting anomalous activity during reconnaissance can reveal compromised credentials before a relay goes live.
Organizations can also apply Service Control Policies at the AWS Organization level to block Lambda Function URLs configured with AuthType: NONE unless explicitly approved through tagging.
This prevents a public relay from being deployed even with valid stolen credentials. Routing Lambda workloads through a Virtual Private Cloud adds another detection layer, since relay traffic produces a one-to-one inbound to outbound pattern visible in flow logs.
Monitoring Lambda cost anomalies rounds out the defense. A relay serving many infected machines generates massive invocation volumes that appear as billing spikes, especially in nonproduction regions. Granular AWS budget alerts can surface this abuse before it scales.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
