Over the past year, GuidePoint’s Threat and Attack Simulation (TAS) team has assessed client environments of every size and the same lesson keeps repeating: the deeper a company goes into the cloud, the more room it creates for misconfigurations that lead to significant exposure.

What Are the Exploitable Misconfigurations in AWS Lambda and API Gateway?

Organizations are deploying countless Lambda functions behind API Gateway endpoints, providing both flexibility and speed in feature delivery. The problem is, many of the internal components of this architecture default to insecure configurations that propagate across rapidly growing environments. The result is an environment where misconfigurations can quietly exist across dozens of functions and endpoints, often going undetected until they are actively exploited.

To understand the attack surface, it helps to first understand the key components of this architecture and how they interact: 

AWS Lambda

AWS Lambda is a serverless compute service. You upload a function (Python, Node, Java, Go, etc.) and AWS runs it on demand without you managing any underlying servers. Three properties matter offensively:

• Execution Role: An IAM role attached to the function that defines what AWS services it can call. Every Lambda has one. The function runs as this role and its temporary credentials are injected into the execution environment as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN.
• Environment Variables:  Key-value pairs baked into the function at deploy time. Developers routinely store database connection strings, API keys and Secrets Manager ARNs here.
• VPC Configuration: A Lambda can optionally run inside a VPC, giving it network access to private resources like RDS instances, ElastiCache and internal services.

API Gateway

API Gateway is AWS’s managed service for exposing HTTP endpoints. It sits in front of your backend and routes incoming requests to Lambda functions. There are two common types you will see with Lambda functions.

Considerations

While this walkthrough used a ReadOnly IAM role for the enumeration phase, it is important to recognize that the credentials were never a hard requirement for exploitation. The enumeration steps simply allowed us to map the attack surface more efficiently. In practice, if a single API endpoint URL were exposed through a leaked configuration file, a public GitHub repository or a JavaScript file served by a web application, an attacker with no AWS credentials whatsoever could skip directly to Step 6 and begin injecting payloads against the unauthenticated endpoint. 

It is also worth noting that this walkthrough focused specifically on Python’s eval() function as the injection point, but this represents just one example of a much broader class of vulnerabilities. Code injection can manifest in dozens of ways depending on the language and framework in use, but the end goal in a cloud environment is often the same, reading the execution environment’s credential variables. The underlying principle is the same in every case, where user-supplied input is being processed by the application in a way that allows it to be interpreted as code rather than data. This pattern, combined with an unauthenticated API endpoint and an over-permissioned execution role, creates the same chain of compromise demonstrated here.

Expanding the Attack Chain

The attack chain demonstrated here ends with execution role credentials and access to whatever that role can reach, but depending on the permissions attached to that role, the impact can extend well beyond retrieving a database secret. If the execution role carries iam:PassRole alongside lambda:CreateFunction or lambda:UpdateFunctionConfiguration, an attacker can attach a higher-privileged role to a Lambda function and use it to escalate to full account control. If the role has broad IAM permissions or an attached AdministratorAccess policy, the extracted credentials provide unrestricted access to every resource in the account. Even without elevated IAM permissions, lambda:UpdateFunctionCode allows an attacker to replace the code of any Lambda function in the account, providing persistence that survives a patch of the original vulnerability. These are just a few examples of how the chain can grow; however, the true scope of what is possible is entirely dependent on how the environment is configured and no two environments look the same.

Detection, Remediation and OPSEC Considerations

Operating against Lambda-backed API Gateway endpoints generates several distinct log streams and the misconfigurations that enabled this attack chain are all addressable. The following covers both how this activity would appear to a defender and what should be done to prevent it.

Remediation

This attack chain is the product of three distinct misconfigurations stacked on top of each other and resolving any one of them breaks the chain entirely.

• Require authentication on all API Gateway endpoints. Every endpoint that does not explicitly need to be public should require authentication, whether that is AWS IAM authorization, a Lambda authorizer or Amazon Cognito. Unauthenticated endpoints are a significant risk even before any application-level vulnerability is considered and all stages including dev and staging should be held to the same standard as production.
• Never pass user-supplied input to dynamic code execution functions. Functions like eval() and exec() should never receive input that originates from an end user. Input should be validated against a strict allowlist of expected values before it is used anywhere in application logic and code reviews should treat any use of these functions as an automatic finding requiring justification.
• Scope Lambda execution roles to least privilege. Lambda execution roles should be granted only the specific permissions the function genuinely requires to perform its intended task. A function that reads from a single DynamoDB table has no business having access to Secrets Manager, IAM or other Lambda functions. Regularly auditing execution role permissions and removing anything that is not actively needed significantly reduces the blast radius of any future compromise.

CloudWatch Lambda Invocation Logs

Every Lambda invocation generates a log entry by default in /aws/lambda/<function-name>. Any payload that gets passed to the lambda function will be logged here. Anomalous invocation patterns will trigger alerts if the client has GuardDuty or a SIEM ingesting CloudWatch. The presence of a X-Amzn-Trace-Id header in response means that X-Ray tracing is active and detailed execution traces are being captured.

API Gateway Access Logs

API Gateway access logging is not enabled by default; however, when opted in, it captures source IP, user agent, request path, HTTP method, response code and latency. Custom domain names in front of API Gateway may have additional WAF logging.

CloudTrail Credential Use

Every AWS API call made with extracted execution role credentials is logged in CloudTrail with source IP, user agent, timestamp and request parameters. Calling secretsmanager:GetSecretValue or s3:GetObject from a residential IP in a different country is an immediate high confidence alert. Using these extracted credentials from infrastructure that matches the expected call patterns such as another Lambda or an EC2 instance in the same VPC could help to obfuscate your traffic.

Invocation Frequency

Depending on the functionality of the Lambda function and expected usages, CloudWatch alarms may trigger alerts if, for example, a function normally receives 10 requests per day but spikes to 10,000 on the day. These alerts may lead to throttling of invocations by a SOC team.

GuardDuty

GuardDuty has specific findings relevant to this attack chain:

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration: fires when Lambda credentials are used from an IP outside AWS
• CredentialAccess:Lambda/AnomalousBehavior: fires when a Lambda execution role is used in an unusual pattern
• PrivilegeEscalation:IAMUser/AdministrativePermissions: fires on iam:PassRole abuse patterns

Conclusion

Every step in this attack chain used either standard AWS CLI commands or unauthenticated HTTP requests. The entire path, from discovering an API Gateway endpoint to extracting execution role credentials and accessing Secrets Manager, runs on defaults and misconfigurations that exist across production environments right now.

That's the uncomfortable reality of serverless security. The architecture removes the many infrastructure security concerns, but the identity layer, permissions model and application logic all carry their own risk of exposure. When those exposures stack, a single URL becomes the entry point to an organization's most sensitive resources.

GuidePoint's Cloud Penetration Testing services help find the risks in your cloud environment before an attacker can use them as entry points. Schedule an assessment and find out what's reachable from the outside in.

Tools and References

• AWS CLI
• AWS API Gateway Authorization
• AWS Lambda Execution Role
• AWS CloudTrail
• AWS GuardDuty Finding Types