Lateral Movement in Serverless: Tracing Cross-Function Exploits in AWS Lambda and GCP Cloud Functions

Serverless platforms like AWS Lambda and GCP Cloud Functions offer unmatched speed and scalability. But with that flexibility comes a new class of risk: lateral movement. 

When functions are misconfigured or over-permissioned, attackers can quietly move between services or escalate privileges often without raising alarms. This guide breaks down how these exploits unfold and what you can do today to stop them.

What Is Lateral Movement in Serverless?

Lateral movement is when an attacker gains access to one component and uses it to reach others. In serverless environments, this often involves:

• Abusing overly broad IAM roles
• Triggering functions through spoofable event sources (e.g., Pub/Sub, S3)
• Accessing shared services like databases or queues

Because functions are short-lived and logs are fragmented across services, tracing the attack path can be difficult until it's too late.

Real-World Example: Over-Permissioned Lambda Role

Let’s say a Lambda function processes image uploads from S3. It only needs s3:GetObject, but its IAM role also includes s3:PutObject, dynamodb:PutItem, and lambda:InvokeFunction.

An attacker exploits the function, perhaps through a vulnerable dependency or misconfigured endpoint, and uses the role to:

1. Upload malicious content to another S3 bucket
2. Invoke a different Lambda function with higher privileges
3. Insert falsified records or exfiltrate data via DynamoDB

This is lateral movement. And without strong isolation and logging, it can go unnoticed.

Step-by-Step: How to Trace Cross-Function Exploits

1. Check IAM Role Usage and Sharing

• List all functions using the same IAM role
  
  • AWS: Use aws lambda list-functions + get-function-configuration
  • GCP: Use gcloud functions describe + service account mapping
• Flag roles or service accounts reused across multiple functions or projects

2. Map Event Triggers and Downstream Access

• Document how each function is triggered (e.g., S3, Pub/Sub, API Gateway)
• Identify any publicly accessible or easily spoofable event sources
• Determine whether a function can invoke other functions directly

3. Review Audit Logs and Trace Activity

• Enable AWS CloudTrail and GCP Cloud Audit Logs
• Filter for events like InvokeFunction, PutItem, or Publish
• Trace actions tied to the same IAM role or service account

Example AWS filter:

(PUT IN CODE BOX)

aws logs filter-log-events \

  --log-group-name /aws/lambda/my-function \

  --filter-pattern '{ $.eventName = "InvokeFunction" }'

Common Mistake: GCP Cloud Functions often share a default service account across projects leading to unintended privilege sprawl.

How to Prevent Lateral Movement in Serverless

1. Use a Unique Role per Function

• Avoid sharing IAM roles or service accounts across functions
• Grant only the minimum permissions needed
• Apply scope controls in AWS with iam:PassRole and in GCP with IAM bindings

2. Limit Function Permissions

• Remove wildcard permissions like lambda:* or s3:*
• Use IAM Access Analyser (AWS) or IAM Recommender (GCP) to review access

3. Restrict Function-to-Function Invocations

• Only allow cross-function calls where absolutely necessary
• Scope invocation permissions to specific functions, not all

4. Harden Event Triggers

• Lock down API Gateways with authentication and rate limits
• Use signed URLs or messages for S3, Pub/Sub, and other triggers
• Validate all input payloads rigorously

‍5. Enable Logging and Alerts on Role Abuse

• Set alerts for unexpected invocations or privilege escalations
• Use AWS GuardDuty or GCP Security Command Centre to surface anomalies
• Monitor sensitive services like Secrets Manager and KMS‍

Final Checklist

Conclusion

Serverless changes how lateral movement happens, it doesn’t eliminate it. To defend against cross-function attacks, isolate IAM roles, restrict permissions, and tighten your event triggers. Then make sure you're logging, monitoring, and ready to respond.

Because in serverless, any function could be your weakest link. Contain the blast radius before it’s too late.

‍