Introduction to AWS Serverless Exploitation: Attacking Lambda, API Gateway & Cognito

This article is based on a talk by Sankalp Paranjpe - an SRE intern at Intangles Labs and an AWS Cloud Club Captain - at BSides Mumbai 2024. You can watch the full session on YouTube.

"Serverless" is one of the most misunderstood words in cloud computing. It does not mean there are no servers - it means someone else runs them for you, and you never see them. That convenience is exactly why serverless security is so easy to get wrong: when AWS manages the infrastructure, it is tempting to assume AWS manages the security too. It does not. Sankalp Paranjpe opened his BSides Mumbai 2024 talk with a simple question - "is it no servers?" - and spent the next twenty minutes showing how a single missing input check in an AWS Lambda function can hand an attacker a shell, your environment variables, and ultimately your AWS access keys.

Key Takeaways

• Serverless does not mean secure by default. Under the AWS shared responsibility model, AWS secures the runtime and infrastructure, but your function code, IAM policies, and data are entirely your responsibility - "security in the cloud" versus "security of the cloud".
• The OWASP Serverless Top 10 still starts with injection. Unvalidated input flowing into a Lambda function is the number-one risk, and it chains straight into credential theft because Lambda hands its IAM role's keys to the running code through environment variables.
• Least privilege is the control that limits the blast radius. Most of the mitigations in the talk - scoped IAM policies, Secrets Manager, dependency scanning, monitoring - come back to giving each function only the permissions it actually needs.

What "Serverless" Actually Means

With serverless, the servers still exist - the cloud provider just manages them for you, so you can stay focused on your application code instead of patching operating systems and provisioning capacity. That is the pitch, and it is a good one: you ship ideas to market faster, you pay less, and the platform scales for you automatically.

Sankalp framed the day around three core AWS services that show up in almost every serverless stack:

• AWS Lambda runs your code without any server provisioning. You write functions in Node.js, Python, Java, Go, or another supported runtime, and each function is deployed as an encrypted container.
• Amazon API Gateway is the fully managed front door for creating, publishing, and securing the APIs that trigger your functions.
• Amazon Cognito handles authentication and authorization - customer identity and access management - so you do not have to build login yourself.

Lambda functions do not run on their own; they are triggered by event sources. Those include cloud storage events (an upload to an S3 bucket), NoSQL database events (DynamoDB), HTTP API calls through API Gateway, message queues, and push/SMS notifications. Every one of those event sources is also an entry point an attacker can probe - which is why threat modelling a serverless app means enumerating every trigger, not just the obvious web endpoint.

The Shared Responsibility Model, Serverless Edition

The single most important slide in the talk was the shared responsibility model. AWS provides the compute, storage, database, and networking, and secures the underlying execution environment and runtime. But the moment you write a Lambda function, the function code and its libraries are your responsibility. AWS will faithfully run whatever you deploy - including your bugs. Encryption, IAM policies, and input validation on the code you ship are all "security in the cloud", and that half of the model belongs to you.

The OWASP Serverless Top 10

Sankalp walked through the serverless risk list one item at a time. The headline categories:

1. Injection - untrusted input reaching your function logic.
2. Broken authentication - rolling your own auth instead of using Cognito or single sign-on.
3. Broken access control - IAM roles that can touch every bucket instead of one.
4. Insecure serverless deployment configuration.
5. Sensitive data disclosure - hardcoded credentials in function code.
6. Security misconfiguration - for example, an S3 bucket an anonymous profile can copy wholesale.
7. Insecure third-party dependencies.
8. Insecure application secret storage.
9. Inadequate function monitoring and logging.
10. Denial of service and resource exhaustion.

A recurring theme: several of these are the same familiar web vulnerabilities, but the consequences are different in a serverless world. A DoS attack, for instance, does not just knock your app offline - because Lambda scales automatically and bills per invocation, a flood of malicious requests through API Gateway becomes resource exhaustion and a very large AWS bill.

The Demo: From Command Injection to Stolen AWS Keys

The most memorable part of the session was a recorded demo of a deliberately vulnerable app deployed with AWS CloudFormation. The app took an uploaded document and converted it to HTML - a classic "resume analytics" style Lambda function with no input validation.

Here is the attack chain Sankalp demonstrated:

1. Fingerprint the backend. Intercepting the upload request in Burp Suite revealed telltale response headers - x-amz-request-id, API Gateway signatures - that identify the app as running on AWS Lambda behind API Gateway, even though in production it would sit behind a DNS name.
2. Find the injection. Because the function shelled out to convert the file without sanitising input, injecting a command into the request got echoed back - confirming command injection.
3. Read the filesystem. cat /etc/passwd returned the contents of the file, proving arbitrary command execution inside the Lambda execution environment.
4. Steal the credentials. This is the serverless-specific twist: Lambda exposes its IAM role's temporary credentials as environment variables. Dumping the environment revealed the AWS_ACCESS_KEY_ID, secret key, and session token.
5. Pivot into the account. With those keys loaded into the AWS CLI, the attacker can authenticate as the function's role and act inside the account - for example spinning up expensive GPU instances that quietly run up a huge bill.

One missing input check became full programmatic access to the AWS account. That is the whole point: in serverless, injection and credential theft are almost the same bug.

How to Defend Your Serverless Stack

Sankalp's mitigations map cleanly onto the risks:

• Never trust input. Validate everything at every entry point, and threat-model every event source that can trigger a function.
• Enforce least privilege. Scope each IAM policy to a specific action on a specific resource (for example s3:PutObject on one named bucket), and use IAM Access Analyzer to verify what your roles can actually do.
• Use a real secrets store. Never hardcode credentials in function code. Put them in AWS Secrets Manager, which integrates with Key Management Service (KMS) to encrypt, decrypt, and rotate secrets automatically.
• Use managed authentication. Don't build your own auth - lean on Cognito or single sign-on, and authenticate service-to-service calls with secure API keys and certificates.
• Scan your dependencies. Maintain an inventory of packages, run software composition analysis (SCA) in every stage of the SDLC, remove unused dependencies, and keep everything patched.
• Adopt a serverless security framework. Sankalp pointed to the OWASP Serverless Top 10, the AWS Startup Security Baseline, the CIS Foundations Benchmark, and the AWS Well-Architected Framework.
• Monitor continuously. Wire up CloudWatch, CloudTrail, and Amazon Detective so that when something does go wrong, you can detect it and trace the root cause.

Frequently Asked Questions

Is serverless more secure than traditional servers?

It removes an entire class of problems - you are no longer responsible for patching the operating system or the runtime, because AWS handles that. But it does not remove application-level risk. Injection, broken access control, and leaked secrets are still entirely yours to prevent, and serverless adds its own twists like credential exposure through environment variables and cost-based denial of service.

Why is command injection so dangerous in AWS Lambda specifically?

Because Lambda passes the function's IAM role credentials to the running code as environment variables. Once an attacker can execute commands, they can read those variables and obtain valid AWS access keys - turning a code-execution bug directly into account access. That is why least-privilege IAM roles matter so much: they cap how much damage a stolen key can do.

What is the single most important control for serverless security?

Least privilege. Almost every mitigation in the talk traces back to it - scoping IAM policies to exactly one action and one resource, so that even if a function is compromised, the attacker inherits the smallest possible set of permissions.

Summary

Serverless shifts the operational burden to AWS, but it does not shift the security burden - the shared responsibility model draws a clear line, and your code, your IAM policies, and your data stay on your side of it. The OWASP Serverless Top 10 is a practical map of what goes wrong, and Sankalp's demo showed how quickly a single unvalidated input becomes command execution, leaked environment variables, and stolen AWS keys. Validate every input, scope every IAM role to least privilege, keep secrets in Secrets Manager, scan your dependencies, and monitor continuously - and the convenience of serverless stops being a liability.

About the Speaker

Sankalp Paranjpe is a Site Reliability Engineering intern at Intangles Labs in Pune and a cloud security and DevSecOps enthusiast. In 2023 he was selected as one of AWS's Cloud Club Captains - among 10 students from India and 50 worldwide - and holds the AWS Certified Solutions Architect - Associate and AWS Certified Cloud Practitioner certifications. He delivered this introduction to AWS serverless exploitation at BSides Mumbai 2024.

Watch the Full Talk

Want the complete walkthrough, including the live command-injection demo? Watch the full BSides Mumbai 2024 session below.