I just completed Tyler Ramsbey's Intro to AWS pentesting course, approaching it from a GRC professional's perspective. The results were sobering: An environment passing 82% of Cloud Security Posture Management checks was completely compromised in under 30 minutes.
Switching to this side of the keyboard in simulated attack scenarios helps GRC practitioners to:
Ask better risk assessment questions
Speak the same language as more technical teams
Prioritize remediation based on actual exploit paths
If you'd like to join me in sharpening your technical acumen to narrow the gap between GRC and offensive security, try the "AWS Beanstalk Secrets" scenario here, check out my walkthrough below, and of course consider Tyler's awesome course. As he would say, "Happy Hacking!"
Table of Contents
Prerequisites
AWS Account
Create a free account
Set up a $0.1 budget alert
Also remember to destroy your CloudGoat scenarios after completing the walkthrough to avoid unexpected AWS charges. Run
cloudgoat destroy beanstalk_secretswhen finished.
VirtualBox with Kali
Install VirtualBox
Install Kali
Install the AWS CLI for Kali
Install Terraform on Kali
Notion
I prefer Obsidian as a daily driver for notes but its SaaS offering has a cost, so a free Notion account comes in handy for pen test challenges like this, synching in real time between your laptop and Kali on your Virtual Machine
Flameshot
apt install flameshotI learned about this app in the course and it works well
Pacu AWS Exploitation Framework
pipx install git+https://github.com/RhinoSecurityLabs/pacu.gitCloudGoat
pipx install cloudgoatCreate the “beanstalk_secrets” Scenario
beanstalk_secrets (Easy)
cloudgoat create beanstalk_secrets
In this scenario, you are provided with low-privileged AWS credentials that grant limited access to Elastic Beanstalk. Your task is to enumerate the Elastic Beanstalk environment and discover misconfigured environment variables containing secondary credentials. Using these secondary credentials, you can enumerate IAM permissions to eventually create an access key for an administrator user. With these admin privileges, you retrieve the final flag stored in AWS Secrets Manager.
Contributed by Tyler Ramsbey
Attack Scenario Overview
⚠️ IMPORTANT SECURITY DISCLAIMER: The techniques demonstrated in this walkthrough are for educational purposes only and should ONLY be performed in authorized environments such as your own AWS account with CloudGoat scenarios. Unauthorized access to computer systems is illegal and unethical. Always ensure you have explicit permission before testing any security measures. Misuse of these techniques could result in criminal charges, termination of employment, and civil liability.
The Vulnerable Environment
What is Elastic Beanstalk?
AWS Elastic Beanstalk is a Platform-as-a-Service (PaaS) that simplifies deploying and scaling web applications. Despite its widespread use, Elastic Beanstalk is frequently overlooked in security assessments. Security teams often focus on EC2 instances and Lambda functions while missing Beanstalk environments entirely. This oversight is critical because developers frequently store API keys, database credentials, and other sensitive data in Beanstalk environment variables, treating them as a secure configuration store when they're actually accessible to anyone with basic read permissions.
Example Use Case
Attack Chain Summary
Enabling AWS Services Before the Attack
To help our understanding of the vulnerabilities in this cloud environment before, during and after the attack, let’s enable some helpful native AWS services.
AWS Security Hub CSPM
Security Hub CSPM (Cloud Security Posture Management) provides centralized security findings and compliance monitoring.
.
It takes about 15 minutes to complete the first scan, which runs daily. Before the attack even begins we see a security score of only 77% and 120 findings raised in this intentionally vulnerable (for practicing pen test techniques) environment.
GuardDuty Threat Detection
GuardDuty uses machine learning to identify malicious activity and unauthorized behavior.
Before the attack we have 1 low finding. We’ll check on this again after the attack.
VPC Flow Logs
These capture all the network traffic from your Kali machine to AWS APIs, and will show the timing and volume of connections during the attack.
VPC Flow Logs Setup:
Go to AWS Console → VPC service
In left sidebar, click "Your VPCs"
Select the VPC used by your Beanstalk environment (check VPC ID)
Click "Actions" dropdown → "Create flow log"
Configure settings:
Filter: All (captures accepted, rejected, and all traffic)
Maximum aggregation interval: 1 minute (for faster detection)
Destination: Send to CloudWatch Logs
Destination log group: Create new → name it "beanstalk-vpc-flow-logs"
IAM role: Create new role (AWS will auto-create)
Add tags (optional): Name = "Beanstalk-Attack-Demo"
Click "Create flow log"
Verification: After 5-10 minutes, go to CloudWatch → Log groups → you should see traffic appearing
CloudTrail Insights
CloudTrail Insights Setup:
Go to AWS Console → CloudTrail service
Click "Trails" in left sidebar
You should see a default trail - click on its name
Click "Edit" (top right)
Scroll to "Insights events" section
Check the boxes for:
✅ API call rate (detects unusual API activity volume)
✅ API error rate (detects rapid permission testing)
Scroll down and click "Save changes"
Verification: CloudTrail → Event history → Change filter to "Insights events" (takes 15-30 minutes to baseline your normal activity)
Privilege Escalation Walkthrough, Mapped to MITRE & NIST
NIST SP 800-53 Security Posture Score: 82%
I mention CSF in the YouTube video but I use the control dictionary NIST SP 800-53 as the closes AWS native equivalent, and one that directly maps to CSF functions, categories and subcategories.
Before we start hacking the cloud, AWS Security Hub CSPM identifies 44 failed NIST SP 800-53 controls, with 2 CRITICAL and 5 HIGH severity findings. The 18% deficient controls span across:
Identity and Access Management
Logging and Monitoring
Network Security
Data Protection
Let’s see which of these enable an attack foothold and action on objectives.
Initial Access
Phase 1: Credential Compromise & Initial Authentication
Commands Executed:
# Configure compromised credentials
aws configure --profile cgidvpxxpwzbff
# AWS Access Key ID: AKIAQQALVHUI7********
# AWS Secret Access Key: ********************************
# Default region: us-east-1
# Verify access
aws sts get-caller-identity --profile cgidvpxxpwzbff
# Output: arn:aws:iam::03**********:user/cgidvpxxpwzbff⚔ MITRE ATT&CK Technique:
T1078.004 - Valid Accounts: Cloud Accounts
🔴 NIST SP 800-53 Control Failures Exploited:
IAM.6 - CRITICAL: Hardware MFA Not Enabled for Root User
Failed Controls: AC-2(1), AC-3(15), IA-2(1), IA-2(2), IA-2(6), IA-2(8)
Impact: Root account vulnerable to credential compromise
Exploitation: Although not directly used, absence indicates poor security hygiene
Practical Risk: Without MFA, a compromised password grants full account access. This control failure means an attacker who obtains root credentials through phishing, credential stuffing, or insider threat can completely compromise the AWS account with no additional authentication barriers.
IAM.19 - MEDIUM: MFA Not Enabled for IAM Users (4 users affected)
Failed Controls: AC-2(1), AC-3(15), IA-2(1), IA-2(2), IA-2(6), IA-2(8)
Impact: All 4 IAM users vulnerable to simple password compromise
Exploitation: cgidvpxxpwzbff user accessed without MFA challenge
Practical Risk: This means that all four IAM users in the account can be accessed with just a username and password. In real organizations, this often leads to account takeover through password reuse, phishing, or brute force attacks.
Discovery
Phase 2: Enumerate Beanstalk Applications & Extract Credentials
Commands Executed:
# Enumerate Beanstalk applications
aws elasticbeanstalk describe-applications --profile attacker
# Found: cgidvpxxpwzbff-app
# Launch Pacu and enumerate Beanstalk for secrets
pacu
> create attacker
> import_keys attacker
The import_keys command loads our compromised AWS credentials into Pacu's session manager, allowing us to use Pacu's automated modules instead of manual AWS CLI commands. This saves significant time during enumeration.
> run elasticbeanstalk__enum --region us-east-1
# Results: Found secondary credentials in environment variables
# SECONDARY_ACCESS_KEY => AKIAQQALVHUI2*******
# SECONDARY_SECRET_KEY => c183flQL8oGN6K2H+NuO7TWvXn***********The elasticbeanstalk__enum module specifically targets Elastic Beanstalk services, automatically calling all the Describe and List APIs we have access to. It extracts application configurations, including the critical environment variables where developers often store secrets.
⚔ MITRE ATT&CK Techniques:
🔴 NIST SP 800-53 Control Failures Exploited:
Config.1 - CRITICAL: AWS Config Not Enabled
Failed Controls: CM-3, CM-6(1), CM-8, CM-8(2)
Impact: No tracking of configuration changes or compliance
Exploitation: Beanstalk environment variable changes not monitored
Practical Risk: Without AWS Config, organizations can't detect when someone adds malicious environment variables, modifies security groups, or changes IAM policies. It's like having no security cameras in a building - you can't see what happened or when.
ElasticBeanstalk.2 - HIGH: Managed Platform Updates Not Enabled
Failed Controls: SI-2, SI-2(2), SI-2(4), SI-2(5)
Impact: Vulnerable platform versions in use
Exploitation: cgidvpxxpwzbff-env running outdated platform with known issues
Practical Risk: Outdated platforms contain unpatched vulnerabilities that attackers can exploit.
S3.17 - MEDIUM: S3 Buckets Not Encrypted with KMS (2 buckets)
Failed Controls: SC-12(2), CM-3(6), SC-13, SC-28, SC-28(1), SC-7(10), CA-9(1), SI-7(6), AU-9
Impact: Beanstalk deployment artifacts stored unencrypted
Exploitation: Application source code in elasticbeanstalk-us-east-1-03********** bucket readable
Practical Risk: Unencrypted S3 buckets mean that anyone who gains access can read the data immediately. In breach scenarios, this often includes source code, customer data, and backup files that should be protected.
Lateral Movement
Phase 3: Configure Secondary Credentials & Verify Access
Commands Executed:
# Configure discovered secondary credentials
aws configure --profile lateral
# AWS Access Key ID: AKIAQQALVHUI2********
# AWS Secret Access Key: ********************************
# Verify new access
aws sts get-caller-identity --profile lateral
# Output: arn:aws:iam::03**********:user/cgidvpxxpwzbff_secondary_user
# Check attached policies
aws iam list-attached-user-policies \
--user-name cgidvpxxpwzbff_secondary_user --profile lateral
# Found: cgidvpxxpwzbff_secondary_policy⚔ MITRE ATT&CK Technique:
T1078.004 - Valid Accounts: Cloud Accounts (using extracted credentials)
🔴 NIST SP 800-53 Control Failures Exploited:
SecretsManager.1 - MEDIUM: Secrets Without Automatic Rotation
Failed Controls: AC-2(1), AC-3(15)
Impact: Static long-lived credentials in environment variables
Exploitation: Extracted credentials (AKIAQQALVHUI2********) remained valid throughout attack allowing persistent lateral movement
Practical Risk: Static credentials that never expire are like having the same lock on your door for 10 years. If someone makes a copy of the key, they have permanent access until you manually change the lock. Automatic rotation would invalidate stolen credentials within hours or days.
CloudTrail.5 - LOW: CloudTrail Not Integrated with CloudWatch
Failed Controls: AC-2(4), AC-4(26), AC-6(9), AU-10, AU-12, AU-2, AU-3, AU-6(1), AU-6(3), AU-6(4), AU-6(5), AU-7(1), CA-7, SC-7(9), SI-20, SI-3(8), SI-4(20), SI-4(5), SI-7(8)
Impact: API enumeration not triggering real-time alerts
Exploitation: elasticbeanstalk:Describe* and iam:List* API calls by attacker profile went unmonitored
Practical Risk: Without CloudWatch integration, security teams can't set up real-time alerts for suspicious activity. It's like having security footage that nobody watches - by the time someone reviews it, the damage is done.
Privilege Escalation
Phase 4: Identify & Exploit CreateAccessKey Permission
Commands Executed:
# In Pacu, scan for privilege escalation vectors
> create lateral2
> import_keys lateral
> run iam__privesc_scan --scan-only
The iam__privesc_scan module analyzes IAM permissions to identify privilege escalation paths. With --scan-only, it identifies potential escalation methods without executing them - risking detection from a noisy attack.
# Results: CONFIRMED escalation method: CreateAccessKey
# Also enumerated 14 unconfirmed permissions with wildcards
# Execute privilege escalation
> run iam__privesc_scan --user-methods CreateAccessKey
Now we run the module again without --scan-only, actively exploiting the CreateAccessKey permission. This module will create new access keys for any user we can modify, potentially including administrators.
# Prompt: Choose target user
# Selection: [1] cgidvpxxpwzbff_admin_user
# Successfully backdoored admin user:
# Access Key ID: AKIAQQALVHUI3********
# Secret Key: ********************************⚔ MITRE ATT&CK Techniques:
🔴 NIST SP 800-53 Control Failures Exploited:
IAM.7 - MEDIUM: Weak Password Policy Configuration
Failed Controls: AC-2(1), AC-2(3), AC-3(15), IA-5(1)
Impact: Weak credential requirements across IAM users
Exploitation: cgidvpxxpwzbff_secondary_user had overly permissive iam:CreateAccessKey permission with wildcard resources
Practical Risk: Weak IAM policies are like giving a janitor the ability to make copies of the CEO's office key. The CreateAccessKey permission with wildcards (*) means the secondary user can create credentials for ANY user, including administrators.
Account.2 - HIGH: Not Part of AWS Organizations
Failed Controls: CA-9(1), CM-2
Impact: No centralized governance or Service Control Policies
Exploitation: No organizational boundaries prevented backdooring cgidvpxxpwzbff_admin_user via CreateAccessKey privilege escalation
Practical Risk: AWS Organizations provides guardrails that prevent even administrators from making certain dangerous changes. Without it, there's no safety net - a compromised admin account has unlimited power to destroy or exfiltrate everything.
Persistence
Phase 5: Configure Admin Access & Verify Privileges
Commands Executed:
# Configure backdoored admin credentials
aws configure --profile admin-exfil2
# AWS Access Key ID: AKIAQQALVHUI3********
# AWS Secret Access Key: ********************************
# Verify admin access
aws sts get-caller-identity --profile admin-exfil2
# Output: arn:aws:iam::03**********:user/cgidvpxxpwzbff_admin_user⚔ MITRE ATT&CK Technique:
T1078.004 - Valid Accounts: Cloud Accounts (admin level)
🔴 NIST SP 800-53 Control Failures Exploited:
CloudTrail.2 - MEDIUM: CloudTrail Not Encrypted at Rest
Failed Controls: AU-9, CA-9(1), CM-3(6), SC-13, SC-28, SC-28(1), SC-7(10), SI-7(6)
Impact: Audit logs of privilege escalation stored unencrypted
Exploitation: iam:CreateAccessKey API call for cgidvpxxpwzbff_admin_user logged but not protected
Practical Risk: Unencrypted logs mean that an attacker who gains access to the S3 bucket storing CloudTrail logs can read all audit history. They could learn about the environment, identify other targets, or even modify logs to hide their tracks.
CloudTrail.4 - LOW: Log File Validation Not Enabled
Failed Controls: AU-9, SI-4, SI-7(1), SI-7(3), SI-7(7)
Impact: Audit logs could be tampered with after compromise
Exploitation: Attacker with admin access could potentially modify logs to remove evidence of backdoor creation
Practical Risk: Without log validation, there's no cryptographic proof that logs haven't been altered. An attacker could delete entries showing their activity, making forensic investigation nearly impossible.
Macie.1 - MEDIUM: Amazon Macie Not Enabled
Failed Controls: CA-7, CA-9(1), RA-5, SA-8(19), SI-4
Impact: No data classification or anomaly detection
Exploitation: Unusual access pattern of new admin keys immediately accessing Secrets Manager went undetected
Practical Risk: Macie uses machine learning to detect unusual data access patterns. Without it, an attacker downloading all your customer data looks the same as normal operations to your monitoring systems.
Collection & Exfiltration
Phase 6: Retrieve Secrets from AWS Secrets Manager
Commands Executed:
# In Pacu, enumerate and download secrets
> import_keys admin-exfil2
> run secrets__enum --region us-east-1
The secrets__enum module automatically discovers and downloads all secrets from AWS Secrets Manager that our admin credentials can access. It saves them locally for offline analysis.
# Found: cgidvpxxpwzbff_final_flag
# Access downloaded secrets
cd ~/.local/share/pacu/admin-exfil2/downloads/secrets/secrets_manager/
cat secrets.txt
# Output: cgidvpxxpwzbff_final_flag:FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}⚔ MITRE ATT&CK Techniques:
🔴 NIST SP 800-53 Control Failures Exploited:
S3.8 - HIGH: S3 Buckets Not Blocking Public Access
Failed Controls: AC-21, AC-3, AC-3(7), AC-4, AC-4(21), AC-6, SC-7, SC-7(11), SC-7(16), SC-7(20), SC-7(21), SC-7(3), SC-7(4), SC-7(9)
Impact: Potential for data exfiltration to public endpoints
Exploitation: cgidvpxxpwzbff_final_flag could be exfiltrated without network restrictions after retrieval from Secrets Manager
Practical Risk: S3 buckets without public access blocks can accidentally become world-readable through a single misconfiguration. This has led to numerous data breaches where sensitive data was exposed to the entire internet.
EC2.9 - HIGH: EC2 Instances with Public IPv4 Addresses
Failed Controls: AC-21, AC-3, AC-3(7), AC-4, AC-4(21), AC-6, SC-7, SC-7(11), SC-7(16), SC-7(20), SC-7(21), SC-7(3), SC-7(4), SC-7(9)
Impact: Direct internet connectivity for Beanstalk instances
Exploitation: Enabled outbound connections for Pacu commands and data exfiltration from compromised environment
Practical Risk: EC2 instances with public IPs can be accessed directly from the internet if security groups are misconfigured. They also allow attackers to exfiltrate data without going through controlled egress points where data loss prevention tools might detect the theft.
EC2.6 - MEDIUM: VPC Flow Logging Not Enabled (2 VPCs)
Failed Controls: AC-4(26), AU-12, AU-2, AU-3, AU-6(3), AU-6(4), CA-7, SI-7(8)
Impact: Network traffic during exfiltration not logged
Exploitation: Data transfer patterns during secrets__enum operation not captured for forensics analysis
Practical Risk: VPC Flow Logs are like network security cameras. Without them, you can't see what data left your network, where it went, or how much was stolen. This makes incident response and forensics extremely difficult.
Post-Incident Analysis: Learning from AWS Native Security Tools
After successfully completing the Beanstalk exploitation scenario, examining the AWS native monitoring tools reveals valuable insights about what these services automatically capture - even with default configurations. This analysis helps businesses understand what forensic capabilities AWS provides out-of-the-box and how simple configuration changes can dramatically improve security posture.
What AWS Automatically Captured
GuardDuty: Threat Intelligence at Work
AWS GuardDuty, when enabled, immediately began identifying suspicious patterns without any custom configuration:
Medium Finding 1: PenTest Tool Detection
GuardDuty recognized Kali Linux usage through its threat intelligence feeds
Flagged
ListAttachedUserPoliciesandDescribeApplicationsAPI calls as reconnaissanceProvided attribution including source IP and IAM principal
Medium Finding 2: Unusual API Activity
Detected root credential usage for
DescribeRegionsClassified appropriately as policy violation
These detections demonstrate GuardDuty's machine learning capabilities - it recognized attack patterns without any rule configuration. For businesses, this means enabling GuardDuty provides immediate value without security expertise.
VPC Flow Logs: Network Visibility
The VPC Flow Logs captured 6,153 connection attempts, providing:
Source and destination IP addresses
Port numbers indicating service targeting
Accept/reject decisions
Timestamp correlation with other events
This data is invaluable for understanding network behavior and is automatically collected when VPC Flow Logs are enabled. Businesses can use this for compliance reporting, troubleshooting, and security analysis.
CloudWatch Logs: Comprehensive API Audit Trail
CloudWatch Logs automatically captured every API call with:
Account ID (03**********)
ENI identifiers tracking resource access
Timestamp precision to the millisecond
Complete request/response metadata
This creates an immutable audit trail that satisfies compliance requirements for many regulatory frameworks (SOC 2, PCI DSS, HIPAA), but it’s only as good as DETECT and RESPOND functions that benefit from it.
The Bottom Line
This AWS Elastic Beanstalk walkthrough demonstrates critical real-world vulnerabilities that security professionals encounter during cloud penetration tests. Here's what makes this scenario invaluable for your learning journey:
Research is Essential - The ability to investigate unfamiliar AWS services independently is a fundamental skill for ethical hackers. This scenario intentionally introduces Elastic Beanstalk without prior explanation, forcing you to develop research capabilities.
Attack Chains are Real - What starts as simple read-only Beanstalk access escalates through:
Environment variable enumeration → Secondary credentials
IAM permission discovery → CreateAccessKey exploitation
Privilege escalation → Full admin compromise
Automation Saves Hours - The Pacu module transforms hours of manual API enumeration into minutes of automated discovery, showing the power of tool development in security testing.
Teaching Reinforces Learning - Creating your own walkthrough solidifies understanding far better than passive consumption. Document your approach, share your discoveries, and contribute to the security community.
I hope you enjoy this lab as much as I did.
Happy hacking!
