mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-12 15:50:19 -08:00
98 lines
4.2 KiB
Markdown
98 lines
4.2 KiB
Markdown
# AWS - Lambda Post Exploitation
|
||
|
||
{{#include ../../../../banners/hacktricks-training.md}}
|
||
|
||
## Lambda
|
||
|
||
For more information check:
|
||
|
||
{{#ref}}
|
||
../../aws-services/aws-lambda-enum.md
|
||
{{#endref}}
|
||
|
||
### Exfilrtate Lambda Credentials
|
||
|
||
Lambda uses environment variables to inject credentials at runtime. If you can get access to them (by reading `/proc/self/environ` or using the vulnerable function itself), you can use them yourself. They live in the default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||
|
||
By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
|
||
|
||
### `lambda:Delete*`
|
||
An attacker granted lambda:Delete* can delete Lambda functions, versions/aliases, layers, event source mappings and other associated configurations.
|
||
|
||
```bash
|
||
aws lambda delete-function \
|
||
--function-name <LAMBDA_NAME>
|
||
```
|
||
|
||
### Steal Others Lambda URL Requests
|
||
|
||
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
|
||
|
||
{{#ref}}
|
||
aws-warm-lambda-persistence.md
|
||
{{#endref}}
|
||
|
||
### Steal Others Lambda URL Requests & Extensions Requests
|
||
|
||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||
|
||
{{#ref}}
|
||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||
{{#endref}}
|
||
|
||
### AWS Lambda – VPC Egress Bypass
|
||
|
||
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
|
||
|
||
{{#ref}}
|
||
aws-lambda-vpc-egress-bypass.md
|
||
{{#endref}}
|
||
|
||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||
|
||
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
|
||
|
||
{{#ref}}
|
||
aws-lambda-runtime-pinning-abuse.md
|
||
{{#endref}}
|
||
|
||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||
|
||
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
|
||
|
||
{{#ref}}
|
||
aws-lambda-loggingconfig-redirection.md
|
||
{{#endref}}
|
||
|
||
### AWS - Lambda Function URL Public Exposure
|
||
|
||
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
|
||
|
||
{{#ref}}
|
||
aws-lambda-function-url-public-exposure.md
|
||
{{#endref}}
|
||
|
||
### AWS Lambda – Event Source Mapping Target Hijack
|
||
|
||
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
|
||
|
||
{{#ref}}
|
||
aws-lambda-event-source-mapping-hijack.md
|
||
{{#endref}}
|
||
|
||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||
|
||
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
|
||
|
||
{{#ref}}
|
||
aws-lambda-efs-mount-injection.md
|
||
{{#endref}}
|
||
|
||
|
||
|
||
{{#include ../../../../banners/hacktricks-training.md}}
|
||
|
||
|
||
|
||
|