diff --git a/_posts/####2023-01-21-IAM-attacking-AWS.md b/_posts/####2023-01-21-IAM-attacking-AWS.md index 4d96ef07ca7d..8ff158895ab3 100644 --- a/_posts/####2023-01-21-IAM-attacking-AWS.md +++ b/_posts/####2023-01-21-IAM-attacking-AWS.md @@ -20,7 +20,7 @@ tags: After identifying a knowledge gap in pentesting AWS (and cloud in general), I decided to spin up and attack [AWSGoat](https://github.com/ine-labs/AWSGoat) which is an intentionally vulnerable AWS lab environment with multiple paths to privilege escalation. -I learnt a ton about IAM and how to attack it and, more importantly, had an absolute blast. so much in fact, that I have decided to make this a 3-part series to include [AzureGoat](https://github.com/ine-labs/AzureGoat) and [GCPGoat](https://github.com/ine-labs/GCPGoat) +I learnt a ton about IAM and how to attack it and, more importantly, had an absolute blast. So much in fact, that I have decided to make this a 3-part series to include [AzureGoat](https://github.com/ine-labs/AzureGoat) and [GCPGoat](https://github.com/ine-labs/GCPGoat) ## Discovering the Application @@ -103,6 +103,8 @@ So reviewing the above output we can see that this policy has access to attach p ## Abusing Lambda to escalate privileges +### Think of Lambda as "Function as a Service", it is based on a "micro-VM" architecture called [Firecracker](https://github.com/firecracker-microvm/firecracker) + I decided to go down the route of abusing these actions via Lambda, as I thought [Cloudtrail](https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/index.html) may be less likely to be configured to feed Lambda logs into [GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html) in a "real" environment (I could be way off here), nevertheless the following is a valuable exercise in understanding IAM and Lambda. Let's take another look at the `blog_app_lambda_data` role now that we have an account with sufficient `iam` actions to effectively enumerate.