Certification Courses
Hands-On Labs
Threat Intelligence
Latest Cyber News
MITRE ATT&CK Breakdown
All Cyber Keywords
Latest News
T1583.007 , Resource Development (TA0042)
Acquire Infrastructure: Serverless
Cloudflare Workers · AWS Lambda · Google Apps Script , invisible infrastructure with no servers to trace...
// Google Apps Script
function doPost(e) {
var cmd = e.parameter.cmd;
var data = decrypt(cmd);
// Execute malicious payload
eval(data.instructions);
return respond(data);
}
// Lambda Runtime
[START] RequestId: a3f8-c2d1
[INIT] Cold start: 142ms
[PARSE] C2 beacon decoded
[EXEC] Routing to backend...
[WARN] Anomalous IAM perms
[RESP] 200 OK , payload sent
[END] Duration: 387ms
// Section 02
Why Serverless Infrastructure Matters
Serverless computing represents the newest and most dangerous frontier in adversarial infrastructure acquisition. Unlike traditional servers or virtual machines that require provisioning, maintenance, and leave behind forensic artifacts, serverless platforms such as AWS Lambda, Cloudflare Workers, and Google Apps Script provide adversaries with ephemeral, auto-scaling execution environments that exist only when triggered and vanish the moment they complete. There are no persistent servers to seize, no disk images to forensically analyze, and no VPC logs that definitively tie activity back to a specific attacker-controlled instance. According to the 2025 State of Cloud Security report by Orca Security, nearly one-third of cloud assets are in a neglected state, signaling ongoing challenges with monitoring and prioritization that adversaries are actively exploiting.
The attribution challenge posed by serverless infrastructure is unprecedented. When adversary traffic originates from workers.dev subdomains, lambda-url.us-east-1.amazonaws.com, or script.google.com endpoints, it appears to the untrained eye as ordinary cloud provider traffic , the same traffic millions of legitimate applications generate every second. The 2020 BlackWater malware campaign demonstrated this effectively when it leveraged Cloudflare Workers as C2 redirectors, routing command-and-control communications through Cloudflare's edge network to mask the true backend server locations. APT41, one of the most prolific Chinese state-sponsored groups, has similarly utilized serverless infrastructure to blend their operations with legitimate cloud traffic patterns, making detection significantly more difficult for security teams relying on traditional IP-based blocklists.
In 2025, attackers are finding increasingly sophisticated ways to exploit misconfigurations, insecure functions, and excessive permissions in serverless environments. AWS Lambda functions with over-privileged IAM roles can be weaponized to access S3 buckets, DynamoDB tables, or other cloud resources. Google Apps Script abuse has been documented in credit card theft operations and Content Security Policy (CSP) bypass attacks. The CISA has issued guidance on securing cloud workloads, while NIST frameworks now include specific controls for Function-as-a-Service (FaaS) security. The MITRE ATT&CK framework formally tracks serverless abuse under T1583.007, acknowledging it as a distinct and growing threat vector within the Resource Development tactic.
~33%
Cloud Assets in Neglected State (2025)
300+
Cloudflare Edge Locations Globally
0
Persistent Servers to Seize
142ms
Avg Lambda Cold Start Time
// Section 03
Key Terms & Concepts
Definition
Serverless Infrastructure Abuse (T1583.007) refers to the adversary practice of purchasing, configuring, or compromising serverless cloud infrastructure , such as AWS Lambda functions, Cloudflare Workers, Google Apps Scripts, or Azure Functions , that can be used during targeting operations. By utilizing serverless infrastructure, adversaries can make it more difficult to attribute infrastructure used during operations back to them. Once acquired, the serverless runtime environment can be leveraged to either respond directly to infected machines or to relay information between C2 servers and compromised hosts. As traffic generated by these functions originates from subdomains of trusted cloud providers, it may be difficult to distinguish from ordinary cloud traffic, significantly enhancing operational stealth.
Everyday Analogy
Like using a disposable phone that automatically destroys itself after each call , there's no device to find, no record to trace, and it works from anywhere in the world. Imagine a burner phone that exists only for the exact seconds you're speaking, appears to dial from your carrier's own headquarters, and evaporates the instant you hang up. Serverless infrastructure operates on this principle: the function exists only when triggered, executes on cloud provider infrastructure, appears as legitimate provider traffic, and leaves behind no persistent footprint once it completes. There's no server to confiscate, no hard drive to image, and no IP address to block , because next time, the function might spin up in a completely different data center on the other side of the planet.
AWS Lambda
Amazon's serverless compute service that runs code in response to events. Auto-scales, pay-per-invocation, supports multiple runtimes (Python, Node.js, Java). Abused as C2 redirectors and data relay endpoints.
Cloudflare Workers
JavaScript/TypeScript execution at the edge of Cloudflare's CDN network (300+ locations). Used by BlackWater malware (2020) as C2 redirectors to mask backend server IPs.
Google Apps Script
JavaScript cloud scripting platform tied to Google Workspace. Abused for credit card theft (2021), CSP bypass, and C2 communication via
script.google.com endpoints.Edge Computing
Processing data at the network edge, closer to end users. Cloudflare Workers execute at edge locations, making C2 traffic appear from hundreds of different geographic regions.
Function-as-a-Service (FaaS)
Cloud computing model where providers dynamically manage function execution. Users write code; providers handle infrastructure, scaling, and availability. Minimizes attacker's operational footprint.
Event-Driven Execution
Serverless functions triggered by events: HTTP requests (API Gateway), S3 uploads, scheduled cron (CloudWatch), or queue messages (SQS). Adversaries exploit HTTP triggers for C2 endpoints.
// Section 04
Real-World Scenario: Maya Thompson
🎯 Operation "Ghost Edge" , Cloudflare Workers C2 Campaign
Maya Thompson, a sophisticated threat actor operating on behalf of a criminal enterprise, has been running a persistent credential harvesting campaign against financial services firms across North America and Europe. Her innovation isn't in the malware itself , it's a relatively standard info-stealer , but in her choice of command-and-control infrastructure.
Phase 1: Worker Deployment
Maya creates a free Cloudflare Workers account using a burner email address registered through Tor. Within minutes, she deploys a lightweight JavaScript Worker that acts as a reverse proxy , receiving HTTPS beacons from infected machines, decoding the embedded data, and forwarding it to her actual C2 backend hosted on a Bulletproof VPS in Eastern Europe. The Worker code is less than 50 lines of JavaScript. The endpoint URL , api.maya-cdn-check.workers.dev , looks like a legitimate CDN health check service.
Phase 2: Active Exploitation
When a defender at one of the target organizations detects the suspicious beacon traffic and attempts to block it, they identify the Cloudflare Workers domain. They add *.workers.dev to their firewall blocklist. But Maya anticipated this , she simply updates her Worker code to respond with a 302 redirect to a Google Apps Script URL. The malware on infected machines automatically follows the redirect, and C2 communication resumes through a completely different cloud provider within minutes.
Phase 3: Backend Rotation
Over the next several weeks, Maya rotates her backend infrastructure across three different Bulletproof hosting providers. Each time, she only needs to update a single variable in her Cloudflare Worker code , the backend URL. The endpoint URL that the malware calls never changes. From the perspective of the infected machines and network defenders, the C2 address has remained constant. In reality, traffic has been silently rerouted to five different backend servers across three countries.
Phase 4: Infrastructure Abandonment
After extracting over 12,000 credentials and 2.3GB of sensitive financial data, Maya deletes her Cloudflare Worker account entirely. Unlike a traditional VPS where disk images might survive, or a domain where WHOIS history persists, the Worker code and all execution logs are gone. She creates a new Workers account with a different email address and deploys fresh infrastructure for her next campaign. The forensic trail is effectively nonexistent , no server to seize, no container to analyze, no IP address to attribute.
⚠️ Key Takeaway
Serverless infrastructure gives adversaries the ability to maintain persistent C2 channels while making backend rotation trivial. The endpoint URL stays the same while the actual destination changes, and when the operation ends, the infrastructure can be destroyed completely with no forensic artifacts remaining. Defenders who rely on IP-based indicators of compromise (IOCs) are fundamentally outmatched by this model.
// Section 05
Step-by-Step: Acquiring Serverless Infrastructure
01
Select Serverless Platform PREVENT
Choose the optimal serverless platform based on operational requirements, geographic coverage, and evasion needs.
- Evaluate web services integration capabilities (AWS Lambda, Azure Functions, Google Cloud Functions)
- Consider edge deployment via Cloudflare Workers for global proximity to targets (300+ PoPs)
- Assess Google Apps Script for scenarios requiring Google Workspace integration or CSP bypass
02
Create Anonymous Accounts DETECT
Establish accounts on the chosen platform(s) using identity-obscuring methods to prevent attribution.
- Register accounts using burner email addresses provisioned through Tor or VPN tunnels
- Use cryptocurrency or prepaid gift cards for any payment requirements
- Avoid linking accounts to real identity, phone numbers, or known email addresses
03
Deploy Malicious Functions DETECT
Write and deploy serverless functions that serve as C2 relay points, payload delivery endpoints, or data exfiltration channels.
- Implement lightweight reverse proxy logic in Workers/Lambda (HTTP request forwarding with header manipulation)
- Encode C2 instructions in base64, XOR, or custom encoding schemes within function parameters
- Deploy Google Apps Script as
doPost/doGetweb app endpoints for C2 communication
04
Configure Trigger Mechanisms PREVENT
Set up event triggers that activate the malicious functions on demand or at scheduled intervals.
- Configure API Gateway or HTTP triggers for on-demand function invocation from malware beacons
- Set up scheduled triggers (CloudWatch Events, cron) for periodic data exfiltration tasks
- Implement S3 bucket triggers or SQS queue listeners for event-driven data collection
05
Test and Validate RESPOND
Verify that the deployed serverless infrastructure functions correctly and evades detection before operational use.
- Test C2 communication reliability through the serverless proxy from multiple geographic regions
- Verify that cloud provider traffic blends with legitimate traffic patterns (TLS certificates, headers)
- Confirm that function execution times stay within free tier limits to avoid billing records and financial trails
06
Maintain and Rotate RESPOND
Continuously manage serverless infrastructure to maintain operational security and avoid detection.
- Rotate backend URLs within Worker/Lambda code without changing the public-facing endpoint address
- Monitor free tier usage limits and create new accounts when approaching thresholds
- Abandon and recreate infrastructure periodically to minimize forensic footprint accumulation
// Section 06
Common Mistakes & Best Practices
✕ Common Mistakes (Adversarial Pitfalls)
- Exceeding free tier usage limits, generating billing records that create a financial trail linking accounts to payment methods and real identities
- Using the same Cloudflare Workers or Lambda function for multiple unrelated operations, enabling investigators to link disparate campaigns through shared infrastructure
- Leaving verbose error handling and debug logging in production serverless code that may expose operational details in cloud provider monitoring dashboards
- Hardcoding backend C2 URLs directly in malware rather than using the serverless endpoint as an abstraction layer, defeating the rotation advantage entirely
- Ignoring IAM role permissions on Lambda functions, granting excessive privileges that could be detected by cloud security posture management (CSPM) tools
✓ Best Practices (Defensive Countermeasures)
- Implement serverless function monitoring using AWS CloudTrail, Azure Monitor, or Google Cloud Audit Logs to track all function creations, modifications, and invocations
- Enforce least-privilege IAM policies on all Lambda functions and Cloudflare Workers, restricting access to only the specific resources each function requires
- Deploy Cloud Security Posture Management (CSPM) tools to continuously scan for misconfigured serverless environments, over-privileged roles, and neglected cloud assets
- Establish baseline behavioral profiles for normal serverless function execution patterns , invocation frequency, data transfer volumes, runtime durations , and alert on deviations
- Integrate serverless security solutions with runtime protection capabilities that can detect and block anomalous function behavior in real time, rather than relying solely on post-execution log analysis
// Section 07
Red Team vs Blue Team View
RED TEAM , Attacker
⚔ Offensive Advantages
- No infrastructure to trace: Serverless functions are ephemeral , they exist only during execution and leave no persistent servers, containers, or disk images for forensic analysis
- Instant global deployment: Cloudflare Workers deploy to 300+ edge locations worldwide within seconds; AWS Lambda can be provisioned in 20+ regions with a single API call
- Auto-scaling resilience: Serverless platforms automatically scale to handle traffic spikes, meaning C2 infrastructure won't go offline even if thousands of bots beacon simultaneously
- Trusted domain camouflage: Traffic originates from *.workers.dev, *.amazonaws.com, or script.google.com , domains that firewall policies inherently trust and cannot block without disrupting legitimate business operations
- Cost-free operations: Free tier allowances on Cloudflare Workers (100,000 requests/day), AWS Lambda (1M requests/month), and Google Apps Script enable campaigns with zero financial exposure
- Backend abstraction: The public endpoint URL remains constant while backend C2 servers can be rotated freely, making infrastructure blocking ineffective
BLUE TEAM , Defender
🛡 Defensive Countermeasures
- Cloud audit logs: AWS CloudTrail logs every Lambda function creation and IAM role change; Google Cloud Audit Logs track Apps Script deployments; Cloudflare provides Workers analytics dashboards
- Function monitoring: Runtime Application Self-Protection (RASP) and serverless security tools like PureSec, Protego, and Check Point CloudGuard can detect malicious function behavior in real time
- Anomaly detection: Machine learning models can establish baseline patterns for function invocations, execution durations, and data transfer volumes, flagging statistical outliers that suggest abuse
- CASB integration: Cloud Access Security Brokers (CASB) provide visibility into serverless function usage across multi-cloud environments, detecting shadow IT deployments and policy violations
- Network traffic analysis: Deep packet inspection (DPI) and TLS fingerprinting can distinguish between legitimate cloud API calls and C2 beacon patterns, even when both originate from the same cloud provider IP ranges
- IAM governance: Automated policy enforcement tools prevent the creation of over-privileged Lambda execution roles and detect anomalous permission escalation attempts
// Section 08
Threat Hunter's Eye
🔍 Hunting Hypotheses for Serverless Infrastructure Abuse
Proactive threat hunters should monitor for the following behavioral patterns that may indicate serverless infrastructure is being abused for malicious purposes. These indicators go beyond simple IOC matching to focus on behavioral anomalies within cloud environments.
- Unusual serverless function creation patterns: Multiple Lambda functions or Cloudflare Workers created in rapid succession from unfamiliar accounts, especially those using free-tier email domains or newly registered identities , may indicate bulk infrastructure provisioning for a campaign
- API Gateway anomalies: REST API endpoints configured with suspicious URL patterns, high request volumes to newly created API Gateway routes, or endpoints that accept unusually large payloads or return encoded data without business justification
- CloudTrail execution anomalies: Lambda functions invoked with unusually high frequency (suggesting beacon traffic), functions with execution times significantly longer than the median (suggesting data processing or relay operations), or invoke patterns that correlate with known malware communication schedules
- IAM permission escalation: Newly created IAM roles with overly permissive policies attached to Lambda functions, especially roles that grant access to S3, DynamoDB, Secrets Manager, or cross-account resources beyond what the function's declared purpose requires
- Cross-region function replication: Identical or near-identical Lambda functions deployed across multiple AWS regions simultaneously, suggesting an adversary is building redundant C2 infrastructure for resilience against regional blocking
- Google Apps Script deployment spikes: Sudden creation of Apps Script web apps with
doPost/doGethandlers published as "Anyone" access, especially scripts that reference external URLs, use base64 encoding/decoding functions, or invokeUrlFetchAppwith suspicious destinations
📊 Suggested SIEM Detection Queries
# AWS CloudTrail , New Lambda functions from new accounts
index=cloudtrail eventName=CreateFunction20150331
| stats count by userIdentity.arn, sourceIPAddress, requestParameters.functionName
| where count > 3 AND relative_time(now(), _time) < 24h
# Cloudflare , Workers API call patterns
index=cloudflare sourcetype=cf:workers analytics
| stats avg(duration), dc(clientIP) as unique_ips by workerName
| where avg(duration) > 500 AND unique_ips < 5
# GCP , Apps Script deployments as web apps
index=gcp resource.type="script.googleapis.com/Project"
protoPayload.methodName="script.projects.updateContent"
| where protoPayload.serviceData LIKE "%doPost%" OR LIKE "%doGet%"
// Section 09
Continue Exploring Related Techniques
🛡 Understand the Full Infrastructure Acquisition Landscape
Serverless abuse (T1583.007) is one of eight distinct sub-techniques under the Acquire Infrastructure parent technique (T1583). Adversaries often combine multiple infrastructure types , domains, VPS servers, DNS infrastructure, web services, and serverless functions , to create resilient, multi-layered operational platforms. Explore the related techniques below to understand the complete spectrum of infrastructure acquisition methods used by modern threat actors.
DONATE · SUPPORT
ROOT::DONATE
- April 7, 2026
- No Comments