HazyBeacon: Lambda Function URLs Abused as C2 Infrastructure

HazyBeacon: Lambda Function URLs Abused as C2 Infrastructure

Active malware campaigns now weaponize AWS Lambda Function URLs as command-and-control endpoints, bypassing traditional perimeter detection. For organizations running serverless workloads, this directly undermines the assumption that ephemeral compute is inherently secure. Security Reviewer customers operating AWS environments face immediate risk — uncontrolled outbound connections from Lambda functions can exfiltrate credentials and escalate privileges without triggering conventional network alerts.

The Attack Surface

HazyBeacon exploits Lambda Function URLs as ingress points for C2 traffic. Attackers invoke the URL with encoded payloads that trigger the function to make outbound HTTP connections to attacker-controlled infrastructure. Because Lambda functions typically run with broad IAM roles, these outbound calls can reach STS, S3, DynamoDB, and external endpoints in a single execution path. The critical failure point is not the invocation itself — it is the untracked data flow from that invocation through IAM role assumption to external network contact.

Taint Analysis and Data Flow Tracking

Static detection of this pattern requires taint analysis that follows data from the Lambda URL handler's entry point through all branching logic to network call sites. The tainted input is the HTTP request body or query parameters mapped to the function URL event. Security Reviewer's taint engine propagates this marker through environment variable reads, IAM credential retrieval via STS AssumeRole or GetSessionToken, and finally to HTTP clients that make outbound connections. When tainted data influences the destination URL, headers, or body of an outbound request, the engine flags a credential exfiltration path.

Identifying Privilege Escalation Chains

The most damaging scenarios involve privilege escalation: a Lambda function invoked via its URL assumes a higher-privilege role and then accesses secrets or mutates infrastructure. Security Reviewer maps IAM policy attachments across the codebase and chains them with function-to-function invocation graphs. When a tainted entry point can reach a target with broader IAM scope — for example, a function reading from a Secrets Manager ARN accessible only to a different role — the engine surfaces this as an escalation chain, not just a single finding.

Unauthorized Outbound Connection Detection

Outbound connections from serverless code are often legitimate — SDK calls to AWS APIs, third-party integrations, logging exfiltration. The distinction matters. Security Reviewer classifies outbound endpoints by domain provenance: AWS service endpoints (tagged as expected), third-party SaaS (flagged for review), and unknown or newly registered domains (critical). Taint-influenced connections to non-AWS, non-whitelisted endpoints are reported with full source-to-sink traces so teams can validate or block immediately.

What Security Reviewer Coverage Looks Like

For AWS-mapped codebases, Security Reviewer continuously scans serverless stacks for three conditions: Lambda functions with public URL enabled and lax resource policies, IAM roles with sts:AssumeRole cross-account permissions reachable from external triggers, and outbound HTTP calls where destination is influenced by untrusted input. Each finding carries the complete taint path from function URL handler to the sensitive operation, giving security teams actionable evidence rather than generic alerts. Compliance teams can map these findings directly to SOC 2 and ISO 27001 controls around data flow integrity and least-privilege enforcement.

If your organization runs serverless workloads on AWS, request a focused assessment from Security Reviewer to identify exposed Lambda URL surfaces, privilege escalation paths through IAM chaining, and unauthorized outbound data flows mapped directly to your codebase.