Mastering AWS Penetration Testing with Kali Linux: Tools, Techniques, and Best Practices

Cloud environments like Amazon Web Services (AWS) have become the backbone of modern IT infrastructure. Yet, with great scalability comes great security responsibility.

This article provides a technical deep dive into how to perform ethical AWS penetration testing using Kali Linux, covering methodology, tools, and compliance requirements to help you strengthen your cloud security posture.

What Is Kali Linux?

This Debian-based Linux distribution was created for digital forensics and penetration testing. This includes a variety of tools for attacking networks, servers, and individual devices. Kali Linux is maintained by Offensive Security Ltd., a provider of first-class information security training and penetration testing services. Kali Linux can be run on a wide variety of devices, including desktops, laptops, and ARM-based systems. Kali also has a large online community that contributes to its growth.

This operating system’s primary purpose is security auditing that can be used by both developers and hackers alike who want access to powerful penetration testing tools. It is essentially the most perfect tool for AWS penetration testing. Its tools can be used to identify vulnerabilities in an AWS environment. In addition, it’s easy to use and provides a wealth of information on how to perform different types of attacks.

Kali comes preinstalled with hundreds of pen/exploitation tools, including Armitage (a graphical cyber attack management tool), Metasploit Framework (a tool used for developing & executing exploit code against a remote target machine), and Nmap (a port scanner). It runs natively when installed on hard disks, and it can also be booted from a live CD or live USB or runs well in virtual machines.

What Is AWS Penetration Testing?

AWS penetration testing is the process of legally simulating attacks on your AWS workloads to uncover vulnerabilities before real attackers do. Unlike traditional on-prem tests, AWS pentests require understanding shared responsibility, ephemeral resources, and API-driven architectures.

The primary goal is to validate the effectiveness of security controls across compute, storage, identity, and network layers, without disrupting production workloads.

Why Perform an AWS Penetration Test?

AWS penetration testing is the process of simulating an attack against your organization’s AWS infrastructure in order to identify security risks and improve its overall security posture.

Here are a number of reasons why you might want to perform an AWS penetration test:

> To identify vulnerabilities in your AWS environment.
> To assess the risk that attackers pose to your organization’s cloud infrastructure.
> To evaluate the security setup of your organization’s cloud applications.
> To simulate a real-world attack on your company’s cloud infrastructure.

AWS Pentesting Scope and Legal Guidelines

Before launching any tests, it’s critical to understand AWS’s penetration testing policy and scope limitations. AWS follows a Shared Responsibility Model – AWS secures the underlying cloud infrastructure, while you are responsible for securing what you deploy (your OS, applications, IAM configurations, etc.). Yes, AWS allows customers to pentest their own AWS environments without prior approval for many services, but you must stay within permitted bounds. Here are key points from the official AWS policy:

* Permitted AWS Services for Pentesting: Amazon EC2 instances, AWS Lambda functions, Amazon RDS databases, Amazon CloudFront distributions, API Gateways, AWS AppSync, Lightsail, Elastic Beanstalk, ECS/Fargate containers, Amazon OpenSearch/Elasticsearch, and others in AWS’s allowed list. In short, you can test your compute instances, databases, and other resources that you’ve deployed. (Notably, testing applications hosted on S3 is allowed only as normal web testing – directly attacking S3 storage itself is out of scope.)

* Services & Activities Off-Limits: AWS forbids tests that target AWS’s underlying infrastructure or services not on the approved list. Disallowed actions include any form of DoS/DDoS or flooding attacks, DNS zone walking or hijacking, and exploit attempts against AWS-managed services (e.g., trying to break the S3 service or AWS’s control plane). For example, mass-scanning S3 endpoints for vulnerabilities or attempting subdomain takeovers on AWS domains is explicitly prohibited. Essentially, focus on finding weaknesses in your own configurations, not in AWS’s core systems.

* Simulated Events & Advanced Testing: If you need to perform more aggressive scenarios – such as a covert red team exercise with Command & Control (C2) infrastructure, or DDoS attack simulations – AWS requires prior authorization via a Simulated Events request. This involves submitting a Simulated Event form in the AWS console with details of your planned test (dates, AWS account IDs, target resources, methods, etc.), at least two weeks in advance. AWS will review and approve the plan (typically within 2 business days of submission), after which you may proceed during the specified window. Always follow this process for any covert ops, malware testing, or stress tests to ensure you remain within AWS’s terms.

* Ethical Boundaries: Only conduct tests on AWS accounts and applications you own or are authorized to assess. Never attempt to access data that isn’t yours. If, during testing, you accidentally discover a vulnerability in AWS’s platform itself (rather than your implementation), notify AWS Security immediately instead of exploiting it. AWS also expects you to respond promptly if any abuse reports arise from your testing activity, have an explanation ready about the test, and a point of contact. In all cases, adhere to the AWS Customer Agreement and security testing terms.

By understanding what’s allowed, you can safely proceed with an AWS pentest that’s both effective and compliant with AWS policy. Now, let’s get our Kali environment ready.

Preparing Kali Linux for AWS Penetration Testing

To follow along, you should have Kali Linux installed (or run it live/VM) and updated to the latest version. Kali provides a robust Linux environment packed with hundreds of pentesting tools, many of which are useful for cloud assessments. For AWS-specific testing, we’ll need to configure a few things:

* AWS CLI & Credentials: Install the AWS Command Line Interface (awscli) on Kali (if not already installed) so that you can interact with AWS services programmatically. On Kali, you can install it via apt (sudo apt install awscli) or pip. Next, obtain AWS API credentials (Access Key ID and Secret Access Key) for the account you’ll be testing. Ideally, create a dedicated IAM user with least-privilege permissions for the pentest (for example, start with read-only SecurityAudit role, then adjust as needed). Configure the AWS CLI by running aws configure and entering the keys, default region, etc. This will save your credentials in ~/.aws/credentials for use by AWS tools.

* Networking Setup: Ensure your Kali box has a stable internet connection for external reconnaissance. If you’re testing internally (for example, attacking from an EC2 inside a private VPC), make sure you have the necessary VPN/VPC access. In some cases, testers launch a Kali Linux EC2 instance in the target AWS account or VPC to simulate an internal attacker – AWS even provides an official Kali AMI on the marketplace. Just be mindful not to break AWS’s rules from within (the rules apply the same inside EC2).

* Install AWS Pentest Tools on Kali: Kali Linux includes some cloud tools in its repositories. We’ll use the following specialized AWS testing tools throughout this tutorial, so install them (via apt or git) if they aren’t already present:

• Pacu – An open-source AWS exploitation framework by Rhino Security Labs. Pacu is like “Metasploit for AWS”, allowing you to enumerate and exploit AWS configurations using modular plugins. Install it on Kali by running sudo apt install pacu. This will set up Pacu and dependencies (Python3+Boto3, etc). Pacu runs as an interactive console where you can set AWS keys and run modules for various attacks.
• ScoutSuite – A multi-cloud security auditing tool by NCC Group. It performs a read-only audit of your AWS account’s settings to find misconfigurations (IAM, S3, EC2, etc.) without making changes. You can install ScoutSuite via pip (pip install scoutsuite) or from source. (Kali might not have it pre-installed by default.) We’ll use ScoutSuite to quickly baseline the target environment’s security posture.
• enumerate-iam – A Python tool by Andrés Riancho that enumerates the permissions of AWS credentials by safely brute-forcing various AWS API calls. This is extremely useful after you’ve obtained a set of AWS keys (for example, through leaked credentials or an exploited instance) to determine what those keys can do. We’ll clone this from GitHub and run it to map out permissions.
• cloud_enum – An OSINT/cloud reconnaissance tool that finds public cloud assets (AWS, Azure, GCP) based on a given keyword. For AWS, cloud_enum can search for S3 buckets and other resources matching your target’s name. Kali includes it (sudo apt install cloud-enum). We’ll use it for external recon to discover things like misnamed S3 buckets.
• S3Scanner – A tool to check the security of Amazon S3 buckets. S3Scanner finds open S3 buckets and can dump their contents if they are publicly accessible. It’s handy for verifying which buckets discovered via cloud_enum (or other means) are actually misconfigured. Install via sudo apt install s3scanner.

* Kali Configuration: Ensure all tools are up-to-date (sudo apt update && sudo apt upgrade). It’s also a good idea to configure environment variables for AWS keys if you’ll be switching between multiple credentials frequently. For example, you can export AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN (if using temporary STS tokens) in your shell, which tools like Pacu or ScoutSuite will then pick up by default. Pro Tip: Create separate AWS profiles or environment files for different test accounts to avoid any confusion or accidental commands in the wrong account.

With Kali ready and credentials in hand, you have a solid platform to begin the assessment. Next, we’ll outline the methodology, covering each phase of an AWS penetration test and how to execute it using Kali Linux and the above tools.

AWS Penetration Testing Methodology (Using Kali Linux)

A thorough AWS pentest involves many of the classic phases of any penetration test – recon, enumeration, exploitation, privilege escalation, persistence, and reporting – but adapted to AWS’s cloud context. Let’s break down each phase with techniques and tools:

1. Reconnaissance (External Information Gathering)

In this initial phase, we gather as much information as possible about the target’s AWS footprint from the outside. This may include mapping out domains, cloud services, and publicly exposed assets. Key goals are to discover entry points like open S3 buckets, vulnerable web endpoints on EC2, or leaked credentials.

* Identify Cloud Resources by Domain: Often, companies use subdomains that point to AWS services (for example, app.example.com might be an AWS Elastic Beanstalk app or CloudFront distribution). Use Kali’s DNS and OSINT tools (like amass, Sublist3r, or assetfinder) to enumerate subdomains and check for CNAMEs pointing to AWS. If you find a subdomain pointing to an S3 bucket or CloudFront, that’s a clue. Also look for common AWS hostnames – e.g. *.s3.amazonaws.com (S3 buckets), *.cloudfront.net (CloudFront), etc.

* Search for Public S3 Buckets: S3 buckets often contain sensitive data if misconfigured. Kali’s cloud_enum tool automates finding S3 buckets (and buckets in other clouds) by trying variations of a keyword. For example, run:

cloud_enum -k <company-name> --quickscan

This will search for bucket names containing “<company-name>” and quickly report any hits. Cloud_enum uses permutations and a built-in wordlist to guess bucket names. It will highlight buckets that are open (publicly readable) versus those that exist but are access-restricted (“protected”). Even protected buckets can be a risk if they allow authenticated AWS user access (the “Any Authenticated AWS User” ACL) – meaning anyone with an AWS account could list them. Keep note of any bucket names found for validation.

* Verify S3 Bucket Access: For each bucket name discovered, use S3Scanner to check its exposure. For example:

s3scanner -bucket <bucket-name> -enumerate

This will attempt to determine if the bucket is publicly listable or writable, and optionally list contents. S3Scanner can try multiple cloud providers, but by default, it checks AWS. A bucket that allows public listing or file retrieval is a serious finding – you might download a few non-sensitive files as proof (always avoid downloading large amounts of data from a client’s bucket without permission). If -enumerate is slow or not needed, you can omit it to just check permissions quickly.

* Port Scanning & Service Fingerprinting: Identify any public-facing EC2 instances or load balancer endpoints from the recon data. If you have IP addresses or hostnames, use nmap (with caution on frequency to avoid looking like a DDoS) to scan for open ports and services. Standard scanning (within the policy limits) is permitted. For example, if demo.example.com resolves to an EC2 IP, you might find ports like 22 (SSH), 80/443 (HTTP/HTTPS), etc. This helps in the next phase when checking for vulnerabilities.

* Public Code Repositories & Leaked Creds: As part of recon, check if the target organization has public GitHub repos or Docker images that might contain hard-coded AWS keys or passwords. Tools like truffleHog or git-secrets on Kali can scan for AWS secret patterns in repo histories. Finding a leaked AWS Access Key ID and Secret is a golden ticket to move into authenticated enumeration quickly – just be sure it’s in scope to use them (usually, yes if they belong to the target).

Remember, reconnaissance for AWS is two-pronged: discovering cloud resources exposed (like S3 buckets, cloud services endpoints) and traditional recon (domains, IPs, leaks) that might yield cloud credentials. By the end of recon, you should have a map of external AWS assets and any initial footholds, such as an open bucket or a vulnerable web app URL.

2. Enumeration (Authenticated Cloud Assessment)

Once you’ve completed external recon, the next step is cloud enumeration – mapping out the internal AWS environment. This typically requires AWS credentials. You might obtain these in a few ways: the client may provide a low-privilege IAM user for assessment, or you might have compromised credentials via phishing, recon, or exploiting an instance (as we’ll see later). Using those credentials, enumerate the AWS account to understand the attack surface.

* Use AWS CLI for Quick Info: With valid AWS keys configured in Kali (aws configure done), you can run basic AWS CLI commands to test access. For example, aws sts get-caller-identity will tell you what account and IAM user/role the keys belong to – confirming they work. You can then do things like aws iam list-users, aws s3 ls, aws ec2 describe-instances etc., to manually peek at resources. However, it’s more efficient to leverage automation tools for comprehensive enumeration.

* Run ScoutSuite for a Cloud Audit: ScoutSuite is excellent for a broad survey of the account’s security posture. It uses your AWS creds in read-only mode to gather configuration data across dozens of services, then produces an HTML report of findings (with risk ratings). To run it on Kali, ensure your AWS creds are active (environment or config) and simply execute: scout aws.

If installed via pip, the command might be scout, or you may need to run python3 scout.py aws from the ScoutSuite folder. It will authenticate to AWS and start pulling config from services (EC2, S3, IAM, RDS, etc). This can take a few minutes. Once done, ScoutSuite saves an HTML report in a folder like scoutsuite-report/. Open the HTML file in a browser to view results. Look for critical issues like S3 buckets without encryption or public access, EC2 security groups with open ports (0.0.0.0/0), IAM users with no MFA, etc. ScoutSuite flags these clearly.

* Enumerate IAM Permissions (Privilege Analysis): If you have credentials for an IAM user or role, you’ll want to know what actions those creds permit. AWS IAM policies can be complex, so we use enumerate-iam to brute-force the effective permissions by calling numerous AWS APIs and seeing which succeed. This tool is non-destructive – it only uses read/list type calls, so it won’t change anything while testing permissions. Run it like:

git clone https://github.com/andresriancho/enumerate-iam
cd enumerate-iam
python3 enumerate-iam.py --access-key <AKIA...> --secret-key <YOURSECRET> --session-token <if any>

The script will try hundreds of AWS actions across services, logging which calls succeeded (meaning the IAM identity had that permission). For example, if it finds ec2:DescribeInstances works but ec2:TerminateInstances fails, you know the user can read EC2 info but not stop instances. Be aware: this process will generate a lot of CloudTrail logs (one entry for each API call), so it’s noisy.

Pro Tip: Use enumerate-iam during a scheduled test window and inform the cloud security team beforehand, since it might trigger anomaly alerts due to the high API call volume. The output of enumerate-iam helps greatly in the next phase (figuring out potential privilege escalation paths).

* Use Pacu for In-Depth Enumeration: Pacu is a powerful all-in-one toolkit for AWS exploitation. After installing, launch Pacu by simply running pacu in Kali. It drops you into an interactive shell. First, you’d set your AWS keys in Pacu. You can do set_keys (and input Access Key, Secret, Session token) or use import_keys if you have an AWS profile configured. Once keys are loaded, Pacu can run various modules to enumerate the environment. For example:

• run ec2__enum – enumerates EC2 instances, security groups, etc.
• run iam__enum_users_roles_policies – gathers IAM users, roles, attached policies.
• run s3__enum_buckets – lists S3 buckets in the account (and checks access).
• data command – view collected data in Pacu’s session.

Pacu automates what you might do manually with AWS CLI, and often formats the results for easier analysis. It’s known for finding things like exposed resources and weak policies. In fact, Pacu’s documentation highlights that it can quickly find open S3 buckets, unused keys, IAM misconfigurations, etc. Think of it as your cloud Metasploit: use recon modules first to map out the terrain.

By the end of the enumeration, you should have:

• A list of AWS resources in scope (servers, databases, storage, etc.).
• Security findings like misconfigured settings or suspicious configurations.
• A clear idea of what level of access your current credentials have (and maybe hints of other accounts/roles in the environment).

This sets the stage for attempting exploitation of any weaknesses uncovered.

3. Exploitation (Identifying and Exploiting Vulnerabilities)

Exploitation in AWS can take many forms. Unlike traditional pentests, where exploitation often means using an exploit payload against a buffer overflow or SQL injection, in cloud pentesting, exploitation is frequently about abusing misconfigurations to gain unauthorized access or data. Let’s cover a few common scenarios:

* Exploiting Public-Facing Applications on EC2: If your recon found a web application or API on an EC2 instance with vulnerabilities (e.g., SQL injection, remote code execution), you would exploit it as normal (using Burp Suite, sqlmap, Metasploit, etc.). The twist is that compromising an EC2 might grant you access to instance metadata and possibly IAM role credentials.

For example, the infamous Capital One breach in 2019 occurred because the attacker exploited a SSRF vulnerability in a web app (hosted behind an AWS WAF) to access the instance’s metadata URL, retrieving temporary IAM credentials. Those creds were tied to a role with excessive S3 permissions, which she then used to download ~100 million customer records from an S3 bucket. As a pentester, if you find SSRF or similar server-side vulnerabilities on an EC2, check if you can reach http://169.254.169.254/latest/meta-data/ – that’s the internal metadata service. If successful, you may harvest credentials under .../iam/security-credentials/RoleName. This is a critical issue to demonstrate (and you should immediately alert, not actually exfiltrate real data beyond what’s needed to prove access).

* Abusing Misconfigured S3 Buckets: Suppose ScoutSuite or your manual checks reveal an S3 bucket configured with public read/write or with an ACL granting access to the “Authenticated Users” group (any AWS user). Exploiting this is straightforward: you can list the bucket’s contents (aws s3 ls s3://bucket-name) and retrieve potentially sensitive files – customer data, backups, etc. In one case, Twilio suffered a breach because a world-writable S3 bucket allowed attackers to replace a JavaScript library hosted there, inserting malicious code.

As a test, if you find writable buckets, you could ethically demonstrate impact by uploading a benign file (e.g., a text banner) or, more safely, just point out that write access exists. For read-exposed buckets, downloading a sample non-sensitive file (or just listing filenames) can often be enough evidence of the flaw.

* Leveraging Leaked Credentials: If your recon turned up AWS keys (for example, in a leaked GitHub repo or an exposed .env file), test those credentials. Often, these might belong to a developer account or an automation user with quite a lot of access. Use Pacu or AWS CLI to see what you can do with them. In some cases, credentials might allow administrative actions right away – which is immediate escalation. In other cases, they are limited, and you proceed to privilege escalation (next section).

* Network Exploitation and Lateral Movement: Within AWS, if you compromise one EC2 instance (say via a vulnerable web app or stolen SSH key), treat it like an entry point to pivot. You can scan the internal AWS network (the VPC) from that instance to find other reachable systems. Perhaps there’s an internal-only API or database. Use Kali’s tools (nmap, or even Metasploit’s auxiliary scanners) from the compromised box. Also, check that instance’s IAM role – it might have its own permissions you can now use via AWS CLI from the instance.

A common vector: an EC2 role with access to secrets in AWS Systems Manager or AWS Secrets Manager – if so, you could retrieve database passwords, etc., via AWS CLI calls that the instance is allowed to make.

Throughout exploitation, maintain good operational security (OPSEC). Avoid disrupting services – for example, don’t actually shut down servers or modify data. Focus on proof-of-concept actions: demonstrate that you could retrieve or alter something, without causing harm. For instance, if you find you have permission to start new instances, you might not actually launch one (unless approved), but you’d note that privilege for escalation.

4. Privilege Escalation in AWS

Privilege escalation in AWS means turning a low-level foothold or set of permissions into higher privileges – potentially up to full admin of the AWS account. AWS IAM has many possible misconfigurations that allow escalation. Here are some avenues and how to spot them (our earlier use of enumerate-iam and ScoutSuite will have helped identify these):

* IAM Policy Misconfigurations: If the compromised IAM user/role has overly broad permissions on IAM itself, you can often escalate directly. For example, if the user can perform iam:AttachUserPolicy on itself or others, it could attach the AdministratorAccess policy to itself. Or if it can iam:CreateUser and iam:PutUserPolicy, it could create a new user and attach an admin inline policy – essentially creating a new admin.

Pacu has modules to automate some of these checks; it even has a privilege escalation module that tries known escalation tricks. Using Pacu or the manual AWS CLI, you can attempt these if authorized. Always document each step (e.g., created a new IAM user “pentest-admin” to demonstrate escalation, then immediately deleted it).

* Role Assumption (Pivoting to other roles): AWS IAM roles can be assumed if you have the right permissions or if they are misconfigured with overly trusting AssumeRole policies. For instance, if you compromise Account A and find it has a role that trusts Account B (your target) and you have the ability to assume that role from A – you’ve escalated into another account. Within a single account, there might be roles meant for specific services, but with weak trust conditions that any user could potentially assume.

The enumerate-iam output and Pacu’s IAM enum will list roles and their trust policies. If you see a role that trusts all principals in the account (Principal: "*") or trusts a broad condition, you might try: aws sts assume-role --role-arn arn:aws:iam::<Account>:role/<RoleName> --role-session-name hack to assume it. If it works, you now have that role’s permissions (which might be admin or higher than your current).

* Abusing PassRole & Service Privileges: A common AWS escalation vector is the iam:PassRole permission in combination with the ability to create or modify certain resources. For example, if your IAM user can passrole an IAM role to an EC2 instance, and also launch an EC2 (ec2:RunInstances), you can effectively launch a new EC2 instance and attach an existing high-privilege role to it, thus gaining those privileges on the new instance. Similarly, if you can pass a role to a Lambda function or ECS task you create, you escalate. Look for any permissions around creating resources that accept an IAM role.

Pacu’s modules and some automated scanners (like Prowler or ScoutSuite) might flag these situations. As a test, you could create a minimal resource with an admin role if allowed – or simply explain the scenario in the report if actual exploitation is too risky in a prod environment.

Pro Tip: Keep a close eye on any IAM permission that allows modifying IAM, as well as any wildcard * permissions in policies attached to your user. These are usually the keys to escalation. Also, coordinate with the cloud admin if you’re going to demonstrate an escalation by creating accounts or roles – you’ll likely have to roll those changes back after confirming the concept.

5. Maintaining Persistence (Post-Exploitation)

After gaining high privileges (or during exploitation), an attacker would normally establish persistence – ways to maintain access to the AWS environment even if the originally compromised credentials are reset. As an ethical hacker, you should also check for possible persistence mechanisms and, if in scope, demonstrate and then remove them. Some persistence techniques in AWS include:

* Creating Backdoor IAM Users/Keys: An obvious method: if you attain Administrator rights, create a new IAM user (e.g., “system-admin2”) and attach Admin policy, then generate access keys for it. This new set of keys is a backdoor into the account. Pentesters often do this as a last step to prove total ownership, but be absolutely sure to delete the user and keys afterward (and mention that you did so to the client!). Pacu actually has a module to backdoor IAM users by adding extra credentials or policies.

* Inserting Persistent Access in Roles: Instead of a new user, an attacker might add a malicious policy to an existing role or user that is less likely to be noticed. For instance, take an innocuous existing IAM user and attach an inline policy that grants admin – so the user becomes a stealth admin. Or add your external account as a trusted principal to a sensitive role’s trust policy (cross-account persistence). Always log exactly what changes you make and revert them later.

* AWS Service Persistence: There are more covert tactics, too. For example, planting a Lambda function that runs with high privileges on a schedule (could be used to re-establish a user account if removed), or creating a backdoor EC2 instance in a seldom-used region with an admin role attached. Attackers have also used things like adding resources to CloudFormation or hiding payloads in User Data scripts on EC2 that re-create access on startup. These are advanced, but you can mention them as possibilities if you don’t actually perform them.

Given the potential impact, persistent access should typically be a discussion in reporting rather than fully executed (unless in a controlled lab). If you do create persistent access to demonstrate it, coordinate with the owners and clean it up.

6. Reporting and Remediation

Finally, no penetration test is complete without a thorough report. For an AWS pentest, the report should clearly explain the findings in terms of cloud risk. Here’s how to structure it:

* Executive Summary: Summarize the overall security posture of the AWS environment. Mention high-level outcomes like “No critical vulnerabilities were found” or “Critical issues were discovered that could lead to full account compromise.” Include context from case studies if relevant (e.g., “This misconfiguration is similar to what led to the Capital One breach, indicating a serious gap.”).

* Findings Detail: For each finding, provide Description, Impact, Evidence, and Recommendation. For example, one finding might be “S3 Bucket prod-backups is publicly accessible without authentication.” Explain why that’s bad (data exposure risk, compliance violation, etc.). Provide evidence – screenshot of S3Scanner output or AWS CLI listing showing accessible files. Then give remediation: “Enable block public access on the bucket and ensure proper IAM policies. Consider using VPC endpoints or pre-signed URLs for controlled access.”

Another example: “IAM user jenkins has the ability to elevate privileges by attaching policies to itself.” Impact: an attacker with those creds can become admin (as demonstrated). Evidence: enumerate-iam output or policy snippet. Remediation: apply least privilege – remove that permission, use a role with limited scope, enable MFA, etc. (The report can reference AWS best practices for IAM and network config).

* Real-World References: Map each issue to known breaches or known CWE/ATT&CK when possible. For instance, if you found an open S3 bucket, you could note, “This is exactly the kind of misconfiguration that led to the Twilio breach in 2020. An attacker could similarly inject malicious content or steal sensitive data from your bucket.” Such comparisons drive home the point to stakeholders.

* General Security Posture: Comment on broader issues: Are there proper monitoring and logs? (Did GuardDuty or CloudTrail catch your activities? If you had stealth, maybe not.) If not in place, recommend enabling AWS GuardDuty for threat detection – it can warn on unusual API calls or port scans. Also, suggest a review of all IAM users for key rotation and MFA, audit of security group rules, etc. Essentially, provide a mini roadmap to improve cloud security hygiene beyond the specific exploits you found.

* Appendices: It can be useful to include raw outputs, tool version info, or any code/scripts used in an appendix. For example, a sanitized excerpt of the ScoutSuite report or Pacu session log can be attached. This helps the client’s cloud engineers later verify and fix issues.

Finally, stress the importance of addressing the findings quickly and monitoring for similar issues across all cloud accounts. Cloud environments are dynamic – new resources could be created insecurely next month. Regular audits (maybe using tools like AWS Config, ScoutSuite, or continuous monitoring like CloudSploit) are advisable.

AWS Pentesting Tools Cheat Sheet

For quick reference, here’s a summary of the key Kali Linux tools and commands used for AWS security testing that we used in this guide:

Pacu – “AWS Metasploit”: AWS exploitation framework with modules for enumeration, privilege escalation, data exfiltration, and more.

• Install: sudo apt install pacu (or clone from Rhino Security Labs).
• Usage: Run pacu, then inside the console use set_keys to add AWS creds. Run modules with run <module_name>. E.g., run iam__privesc_scan to find potential privilege escalation paths. Use --help or --list-modules to explore options. Pacu can automate checking for misconfigs like wide-open S3, vulnerable Lambda functions, etc.

ScoutSuite – Cloud Auditor: Multi-cloud (AWS/Azure/GCP) read-only auditor that finds misconfigurations and security issues.

• Install: pip install scoutsuite (or use the ScoutSuite GitHub).
• Usage: Ensure AWS credentials configured, then run scout aws. The output HTML report (in scoutsuite-report/) will highlight issues (with severity). No changes are made in the cloud environment. Check sections like IAM, S3, and EC2 for critical findings.

enumerate-iam – IAM Permissions Enumerator: Enumerates all actions that the provided AWS keys are allowed to perform by attempting safe API calls.

• Install: git clone https://github.com/andresriancho/enumerate-iam (Kali might include it in some toolset, but git is sure).
• Usage: python enumerate-iam.py --access-key X --secret-key Y [--session-token Z]. Let it run to completion. It will list every AWS API call that succeeded. Use this to identify hidden permissions (e.g., if it lists iam:CreateUser works – that’s a red flag). Remember, it’s noisy (lots of API calls), so use it in a controlled manner.

cloud_enum – Public Resource Finder: OSINT tool to find public cloud assets like S3 buckets, Azure blobs, etc., using a keyword.

• Install: sudo apt install cloud-enum (in Kali repo).
• Usage: cloud_enum -k <keyword> (for single keyword) or -kf keywords.txt for multiple. Add --quickscan to limit brute-force depth. It will output discovered bucket names or resources, indicating if they’re open or require auth. Use this during recon to uncover unintended public cloud exposures.

S3Scanner – S3 Bucket Vulnerability Scanner: Checks a list of S3 bucket names for openness and dumps contents if allowed.

• Install: sudo apt install s3scanner.
• Usage: Provide a bucket or list: s3scanner -bucket-file buckets.txt -threads 10 -enumerate. It will report for each bucket if it’s Public, Authentication required, or Not found. If public, it can list and download files (which it saves locally). Great for validating bucket findings and demonstrating the risk (by retrieving a benign sample file, for instance).

Other Notables: Nmap (port scanning EC2 instances), Burp Suite (web pentesting on cloud-hosted apps), Metasploit (if exploiting OS-level vulns on EC2), and cloud-specific scripts like Prowler (an AWS CIS benchmark tool) are also part of a Kali tester’s toolkit. AWS’s own services, like GuardDuty, can sometimes be used defensively to see if your activities are detected. Consider checking GuardDuty findings after your test as part of assessing detection capabilities.

Conclusion

AWS penetration testing with Kali Linux combines cloud knowledge with classic hacking skills. By following a structured approach – reconnaissance of cloud assets, enumerating configurations, safely exploiting misconfigurations or vulnerabilities, escalating privileges, and assessing persistence – you can thoroughly evaluate the security of an AWS environment. Always do so within the legal scope and AWS’s guidelines: test your own cloud infrastructure, get approvals for anything beyond basic testing, and respect the boundaries between testing your cloud resources versus AWS’s managed services.

We have also provided a Kali Linux cheat sheet for performing different types of attacks on an AWS environment. A proactive pentest can reveal these issues earlier. So begin your AWS penetration testing with Kali Linux today and improve your overall cloud security posture!

__
Thank you for reading our blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-