Detect Serverless in Elastic Security
Adversaries may compromise serverless cloud infrastructure, such as Cloudflare Workers, AWS Lambda functions, or Google Apps Scripts, to proxy command-and-control (C2) communications between implants on victim systems and adversary-controlled backend servers. Because traffic destined for compromised serverless functions originates from subdomains of trusted cloud providers (e.g., *.workers.dev, *.execute-api.amazonaws.com, script.google.com), network-layer defenses relying on domain or IP reputation are largely ineffective. Detection pivots to behavioral analysis of victim-side telemetry: identifying processes on endpoints communicating with serverless platforms in patterns consistent with C2 beaconing (periodic connections, low-variance timing, small symmetric payloads), correlating process context with destination domains, and monitoring cloud audit logs for unauthorized modifications to serverless functions within environments the defender controls.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1584 Compromise Infrastructure
- Sub-technique
- T1584.007 Serverless
- Canonical reference
- https://attack.mitre.org/techniques/T1584/007/
Elastic Detection Query
sequence by host.name, process.entity_id with maxspan=24h
[network where event.type == "connection" and event.outcome == "success"
and (
dns.question.name like "*.workers.dev" or
dns.question.name like "*.cloudflareworkers.com" or
dns.question.name like "*.execute-api.*.amazonaws.com" or
dns.question.name like "*.lambda-url.*.amazonaws.com" or
dns.question.name like "script.google.com" or
dns.question.name like "*.cloudfunctions.net" or
dns.question.name like "*.run.app" or
dns.question.name like "*.azurewebsites.net" or
dns.question.name like "*.pages.dev" or
dns.question.name like "*.netlify.app" or
dns.question.name like "*.vercel.app" or
dns.question.name like "*.supabase.co" or
dns.question.name like "*.deno.dev"
)
] with runs=12Detects repeated successful network connections from a single process to known serverless cloud infrastructure domains (Cloudflare Workers, AWS Lambda, GCP Cloud Functions, etc.) over a 24-hour window. Twelve or more connection events per process-host pair triggers the rule, consistent with C2 beaconing via compromised serverless functions. Uses EQL sequence with 'runs' to count repeated matching events.
Data Sources
Required Tables
False Positives & Tuning
- CI/CD pipelines and build agents that frequently poll deployment endpoints on AWS Lambda or Azure Functions for status checks
- Legitimate SaaS products (e.g. Supabase-backed apps, Vercel-hosted SPAs) whose client components make frequent API calls to serverless backends
- Security scanning or monitoring tools that probe serverless endpoints as part of health checks or synthetic transactions
Other platforms for T1584.007
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate C2 Beacon to Cloudflare Workers Domain
Expected signal: DeviceNetworkEvents: 15 ConnectionSuccess events from PowerShell.exe to httpbin.org, spaced ~30 seconds apart. Sysmon Event ID 3: Network connections with consistent DestinationPort=443 and DestinationHostname=httpbin.org. Inter-arrival time analysis will show MeanInterval ~30 seconds with low standard deviation (JitterCoefficient < 0.05).
- Test 2Non-Browser Process Connecting to AWS Lambda URL
Expected signal: Sysmon Event ID 3: Network connections with Image=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe making POST requests to httpbin.org:443. DeviceNetworkEvents: InitiatingProcessFileName=powershell.exe, connection count=5 with small SentBytes values. Sysmon Event ID 22: DNS query for httpbin.org from powershell.exe.
- Test 3Enumerate and Test Unauthorized AWS Lambda Function (Controlled Lab)
Expected signal: AWS CloudTrail: ListFunctions and InvokeFunction API calls logged in CloudTrail with sourceIPAddress of the calling machine, userAgent=aws-cli, and requestParameters including the function name. If forwarded to a SIEM via CloudWatch/Kinesis, these appear in your cloud audit log index. EventName=InvokeFunction with errorCode absent indicates successful invocation.
- Test 4Deploy Test Cloudflare Worker via wrangler CLI (Simulates Infrastructure Compromise Foothold)
Expected signal: Cloudflare Audit Log: Worker script deployment event with actor email, source IP, and timestamp. If Cloudflare Logpush is configured to forward audit logs to your SIEM, the event appears as audit_log.action.type=deploy with resources referencing the worker name. Process telemetry: node.exe or cmd.exe spawning wrangler commands visible in Sysmon Event ID 1.
References (9)
- https://attack.mitre.org/techniques/T1584/007/
- https://www.bleepingcomputer.com/news/security/blackwater-malware-abuses-cloudflare-workers-for-c2-communication/
- https://blog.xpnsec.com/aws-lambda-redirector/
- https://awakesecurity.com/blog/threat-hunting-series-detecting-command-control-in-the-cloud/
- https://www.bleepingcomputer.com/news/security/hackers-abuse-google-apps-script-to-steal-credit-cards-bypass-csp/
- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html
- https://developers.cloudflare.com/workers/observability/logging/
- https://cloud.google.com/logging/docs/audit/understanding-audit-logs
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1584.007/T1584.007.md
Unlock Pro Content
Get the full detection package for T1584.007 including response playbook, investigation guide, and atomic red team tests.