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.