{“lastseen”:”2026-06-02T16:05:08″,”description”:”#### **Key Takeaways**\\n\\n * 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.\\n * Attackers use stolen IAM credentials**** to deploy Lambda functions that proxy malware communications through trusted AWS domains.\\n * 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.\\n\\n\\n\\n* * *\\n\\n## **The Rise of Cloud-Native Command and Control (C2)**\\n\\nCommand 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.\\n\\nCloud 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.\\n\\nThe 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.\\n\\n* * *\\n\\n* * *\\n\\n## **Borrowed Infrastructure Attacks**\\n\\nHazyBeacon 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.\\n\\nIn this model, the victim environment becomes part of the attacker\u2019s operational stack.\\n\\nA typical Borrowed Infrastructure Attack follows four stages:\\n\\n 1. A credential compromise grants access to a cloud account.\\n 2. Infrastructure is deployed using legitimate cloud APIs.\\n 3. Malware communications are routed through trusted cloud endpoints.\\n 4. Attribution becomes difficult because the infrastructure is owned by an unrelated organization.\\n\\n\\n\\nThis 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.\\n\\n### The Malware Payload\\n\\nOnce installed on a victim’s endpoint, HazyBeacon operates as a lightweight downloader and execution framework designed to remain flexible and evasive.\\n\\nIts primary functions include:\\n\\n 1. System Enumeration: Gathering hostname, IP address, user privileges, and operating system (OS) version.\\n 2. Remote Task Execution: Receiving encrypted commands to download further payloads or execute shell commands.\\n 3. Data Exfiltration: Uploading stolen documents and captured keystrokes.\\n\\n\\n\\n### The Infrastructure Pivot\\n\\nRather than hosting dedicated command servers, the attackers behind HazyBeacon compromised unrelated AWS accounts and deployed lightweight Lambda-based relays inside those environments.\\n\\nThese 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.\\n\\nThe communication chain typically follows this pattern:\\n\\n * Malware (Victim A) sends an encrypted HTTP POST to the Lambda function URL (Victim B’s Account).\\n\\n\\n * Lambda strips the headers, logs the basic metadata (for the attacker’s analytics), and forwards the payload to the attacker’s backend server.\\n * The attacker\u2019s backend server responds to the Lambda, which relays the command back to the Malware.\\n\\n\\n\\nThis \u201cmiddleman\u201d 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.\\n\\n### Why Lambda Function URLs Are the Ultimate C2 Proxy\\n\\nTo 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.\\n\\nBefore 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.\\n\\nAWS Lambda Function URLs allow developers to expose a serverless function through a dedicated HTTPS endpoint without configuring API Gateway or a load balancer.\\n\\nA typical endpoint looks like: \\n\\n`https:\/\/\\u003curl-id\\u003e.lambda-url.\\u003cregion\\u003e.on.aws`\\n\\nCrucially, they support two authentication modes:\\n\\n 1. AWS_IAM: Requires the caller to sign requests with valid IAM credentials.\\n 2. NONE: Allows unauthenticated, public access from anywhere on the internet.\\n\\n\\n\\nThreat actors prefer the second option, `AuthType: NONE`, because it allows them to deploy a public HTTPS relay inside AWS infrastructure within seconds.\\n\\n\\n\\n\\n\\n#### The \\”Lookalike\\” Problem\\n\\nBecause 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. \\n\\n### The Cloud Infrastructure Kill Chain\\n\\nThe 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.\\n\\nThe attack typically unfolds in several phases:\\n\\n**Phase 1: Reconnaissance \u2013 Credential Harvesting**\\n\\n 1. Credential harvesting provides initial access.\\n 2. Theft of AWS access keys from public GitHub repositories, developer phishing campaigns, or malware harvesting ~\/.aws\/ credentials.\\n 3. Credentials are typically static IAM keys created long ago and never rotated.\\n 4. No interaction with AWS infrastructure occurs at this stage.\\n\\n\\n\\n**Phase 2: Weaponization \u2013 Access Validation**\\n\\n 1. Access validation follows.\\n 2. Stolen credentials are validated using low-noise API calls.\\n 3. Common commands include aws sts get-caller-identity and aws iam list-attached-user-policies.\\n 4. The attacker enumerates permissions such as l`ambda:CreateFunction` and `lambda:CreateFunctionUrlConfig`.\\n\\n\\n\\n**Phase 3: Delivery and Exploitation \u2013 Infrastructure Deployment**\\n\\n 1. Infrastructure deployment occurs next.\\n 2. Legitimate AWS APIs are used as the delivery mechanism.\\n 3. A zipped Python or Node.js payload is uploaded as a Lambda function.\\n 4. Functions are given benign names (e.g., UpdateWorker) to evade casual inspection.\\n 5. Deployment often occurs in regions with reduced scrutiny, such as sa-east-1 or eu-north-1.\\n\\n\\n\\n**Phase 4: Installation \\u0026 Command and Control**\\n\\n 1. Command channel activation occurs.\\n 2. Persistence is established by creating a Lambda Function URL.\\n 3. The Function URL is configured with `AuthType: NONE`.\\n 4. The URL is integrated into the attacker\u2019s C2 infrastructure.\\n\\n\\n\\n**Phase 5: Actions on Objectives**\\n\\n 1. Once active, the compromise spreads through the Lambda function.\\n 2. The victim\u2019s AWS account becomes an unwitting C2 relay for malware communications.\\n 3. Thousands of command-and-control requests are processed through the function per hour.\\n 4. The activity appears operationally normal within most enterprise environments.\\n\\n\\n\\n## **MITRE ATT \\u0026CK Deep Dive: Mapping the Serverless Attack Surface**\\n\\nThis campaign maps directly to several techniques in the MITRE ATT\\u0026CK framework for cloud environments.\\n\\n**Tactic**| **Technique ID**| **Technique Name**| **Context in HazyBeacon** \\n—|—|—|— \\nInitial Access| T1078.004| Valid Accounts Cloud Accounts| Usage of stolen, static IAM Access Keys to enter the cloud environment. \\nExecution| T1648| Serverless Execution| Creating new Lambda functions that persist independently of the compromised user session. \\nDefense Evasion| T1564| Hide Artifacts| Deploying in unused regions; using benign naming conventions (\\”BackupHandler\\”, \\”ImageResizer\\”). \\nCommand \\u0026 Control| T1102| Web Service| Using AWS Lambda as the communication channel to blend with legitimate web traffic. \\nCommand \\u0026 Control| T1090| Proxy| The Lambda function serves purely as a hop point to obscure the true destination. \\n \\nThis mapping illustrates that the attack does not rely on sophisticated exploits. It relies on predictable weaknesses in identity governance and infrastructure monitoring.\\n\\n## **How to Prevent Cloud Infrastructure from Becoming Command Infrastructure******\\n\\nCampaigns like HazyBeacon reveal how attackers repurpose cloud services for command channels; the defensive response must focus on the layers that govern how infrastructure is created and used. It requires visibility and control across three layers of the cloud operating model: identity, the control plane, and infrastructure behavior.\\n\\n### **Identity Hygiene is the New Security Perimeter**\\n\\nIn cloud environments, identity effectively defines the security boundary. Campaigns like HazyBeacon depend on compromised IAM credentials that allow attackers to deploy Lambda functions and expose public Function URLs. Controls that disable unused access keys, enforce regular key rotation, and require multi-factor authentication significantly reduce this attack surface. Controls that disable unused access keys, enforce regular key rotation, and require multi-factor authentication significantly reduce the likelihood that attackers can deploy malicious infrastructure.\\n\\nStrong credential governance removes one of the primary prerequisites for serverless command infrastructure.\\n\\n### **Control Plane Visibility Reveals Infrastructure Deployment**\\n\\nIf identity controls fail, detection shifts to the control plane.\\n\\nCloud environments produce detailed telemetry for every infrastructure action. Services such as AWS CloudTrail record API calls used to create resources such as Lambda functions and Function URLs. When logging is enabled across all regions, attempts to deploy infrastructure in less monitored locations become visible.\\n\\nMonitoring anomalous API activity can often reveal compromised credentials during reconnaissance or privilege testing, before attackers establish operational command infrastructure.\\n\\n### **Infrastructure Behavior Exposes Command Relays**\\n\\nEven though Lambda is serverless, it still generates observable network patterns.\\n\\nOrganizations that route Lambda workloads through Virtual Private Clouds can collect flow telemetry that exposes proxy-like behavior. A command relay typically produces a near one-to-one relationship between inbound and outbound requests, as the function forwards traffic between malware clients and attacker infrastructure.\\n\\nSuch patterns can reveal when a Lambda function is operating as a relay rather than executing a legitimate workload. Broader configuration weaknesses, including overly permissive security groups, also tend to correlate with higher rates of identity compromise.\\n\\n## **High-Signal Controls for Detecting and Restricting Lambda Abuse**\\n\\nBeyond detection, organizations should actively restrict the conditions that allow attackers to expose serverless infrastructure to the internet.\\n\\nTwo controls are particularly effective:\\n\\n 1. **Enforcing Zero Trust Function Policy** \\nOrganizations can implement Service Control Policies (SCPs) at the AWS Organization level that prevent the creation of Function URLs with `AuthType: NONE` unless the function is exclusively approved through tagging or policy exceptions (e.g., `PublicFacing: True`). \\n \\nThis approach enforces a zero-trust model for public serverless endpoints. Even if an attacker gains access to valid IAM credentials, the API call required to expose a Lambda function publicly will fail. \\n\\n 2. **Monitoring Cost Anomalies in Serverless Workloads** \\nCommand infrastructure generates volume. A command relay supporting large numbers of infected systems can produce thousands or even millions of Lambda invocations. \\n \\nMonitoring service-level cost anomalies can therefore act as an additional detection signal. Granular AWS budget alerts for Lambda compute usage can reveal unexpected spikes in invocation activity, particularly in nonproduction regions. Such patterns often indicate infrastructure abuse, including command relays or unauthorized compute workloads.\\n\\n\\n\\n## **Operationalizing Cloud Infrastructure Defense with Qualys TotalCloud**\\n\\nApplying these controls consistently across large cloud environments requires continuous visibility across accounts, identities, and serverless workloads.\\n\\n**Qualys TotalCloud** helps organizations identify exposed IAM credentials, monitor Lambda Function URL creation, detect risky configuration drift, and surface abnormal serverless activity from a unified cloud posture management layer.\\n\\nBy correlating identity, infrastructure, and workload telemetry, TotalCloud helps security teams identify the conditions that enable cloud-native command infrastructure before those resources become operational attack relays.\\n\\n## **Closing the Door on Cloud-Native Malware**\\n\\nThe HazyBeacon campaign demonstrates how cloud infrastructure can be repurposed into operational command infrastructure when identity and configuration controls fail.\\n\\nFor attackers, cloud environments are the perfect hideout: high trust, low cost, and endless scale. For defenders, however, the cloud offers a unique advantage: Visibility. Unlike on-premises networks, where a rogue server might hide under a desk, in the cloud, every asset, every API call, and every configuration change is logged and leaves a record.\\n\\nWhen organizations enforce strong identity governance, maintain visibility across the cloud control plane, and monitor infrastructure behavior, they remove the conditions that allow attackers to turn legitimate infrastructure into operational malware.\\n\\n* * *\\n\\n**See how Qualys Kubernetes and Container Security helps organizations modernize lifecycle visibility for containerized applications and Kubernetes environments**\\n\\nSpeak to a Cloud Expert\\n\\n* * *\\n\\n## Frequently Asked Questions (FAQs)\\n\\n### **What is HazyBeacon?**\\n\\nHazyBeacon is a Windows backdoor that uses AWS Lambda Function URLs as a command-and-control relay. Malware communicates with a Lambda endpoint, which forwards instructions and stolen data to the attacker\u2019s backend server.\\n\\n### **Why are AWS Lambda Function URLs used for command and control**\\n\\nWhen configured with **AuthType NONE** , Lambda Function URLs create public HTTPS endpoints. Because they run on trusted AWS domains, malicious traffic can blend in with normal cloud traffic.\\n\\n### **Does HazyBeacon exploit a vulnerability in AWS?**\\n\\nNo. The attack relies on stolen IAM credentials and misconfigured permissions, not flaws in AWS services.\\n\\n### **Why is this type of command infrastructure hard to detect?**\\n\\nTraffic to AWS infrastructure appears as legitimate encrypted HTTPS traffic, making it difficult for traditional network defenses to distinguish malicious activity.\\n\\n### **How do attackers deploy Lambda-based command relays?**\\n\\nAttackers use compromised IAM credentials to create Lambda functions and expose them through public Function URLs.\\n\\n### **How can organizations reduce the risk of this attack?**\\n\\nBy enforcing strong identity governance, enabling CloudTrail logging, restricting public Function URLs, and monitoring unusual Lambda activity.”,”published”:”2026-06-02T16:00:00″,”modified”:”2026-06-02T16:00:00″,”type”:”qualysblog”,”title”:”The HazyBeacon Protocol \u2013 How Malware Weaponizes Amazon Web Services (AWS) Lambda Function URLs”,”source”:””,”references”:””,”id”:”QUALYSBLOG:1BBF6B5B1C7D340BAA7806C60697CFB8″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/blog.qualys.com\/category\/qualys-insights”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-06-02T16:05:08″,”description”:”#### **Key Takeaways**\\n\\n * 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.\\n…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,120,7,11,5],"class_list":["post-59297","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-qualysblog","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n