This chapter covers cloud pentesting specifically for Amazon Web Services (AWS) and Microsoft Azure, two of the most widely adopted cloud platforms. For the PT0-002 exam, this topic area appears in roughly 10-15% of questions, often in scenario-based formats that require you to identify misconfigurations, enumerate resources, and exploit common weaknesses. Mastering this content is critical because cloud environments introduce unique attack surfaces like IAM roles, storage buckets, and serverless functions that differ fundamentally from on-premises networks. You will learn the specific tools, commands, and techniques used to assess AWS and Azure, including how to leverage APIs, enumerate permissions, and pivot within cloud accounts.
Jump to a section
Cloud pentesting is like hiring a security inspector to evaluate a commercial building. The inspector has a blueprint (the cloud architecture) and a checklist of common vulnerabilities (like unlocked doors, weak locks, or insecure wiring). In AWS and Azure, the 'building' is a shared responsibility: the cloud provider secures the physical walls and foundation (the data center, hypervisor, network), while the tenant secures their own offices (OS, applications, IAM policies). The inspector (pentester) tests only the tenant-controlled areas—they cannot break the building's structural columns (provider infrastructure). They use tools like port scanners (checking doors), vulnerability scanners (testing lock strength), and social engineering (trying to trick reception into giving access). They must stay within agreed boundaries (scope) and report findings without causing damage. Misconfigurations are the most common issues—like leaving a back door unlocked (open S3 bucket) or using default keys (weak passwords). The inspector then provides a report with prioritized fixes, mimicking the pentest deliverable.
What is Cloud Pentesting and Why Does It Exist?
Cloud pentesting is the authorized simulation of attacks against cloud-hosted infrastructure to identify security weaknesses. Unlike traditional pentesting, cloud pentesting must account for the shared responsibility model: the cloud provider (AWS or Azure) secures the underlying physical infrastructure, hypervisor, and network, while the customer secures everything they deploy—identity and access management (IAM), virtual networks (VPC/VNet), compute instances (EC2/VMs), storage (S3/Blob), and applications. The PT0-002 exam tests your ability to assess the customer-controlled side.
How It Works Internally: AWS Pentesting
#### Step 1: Reconnaissance and Enumeration
The first phase is gathering information about the target AWS environment. This typically starts with the AWS account ID, which can sometimes be derived from public resources like S3 bucket names (e.g., my-bucket.s3.amazonaws.com reveals the bucket name but not the account ID). However, you can enumerate account IDs via the AWS API using tools like aws sts get-caller-identity if you have valid credentials. More commonly, you begin with leaked API keys, instance metadata, or public-facing services.
Key enumeration actions:
- S3 Bucket Discovery: Use s3:// URLs or tools like s3scanner to check for public buckets. Run aws s3 ls s3://bucket-name to list contents if the bucket is public.
- IAM Enumeration: If you have read-only credentials, use aws iam list-users, aws iam list-roles, and aws iam list-policies to map out identities and permissions.
- EC2 and VPC Enumeration: Use aws ec2 describe-instances, aws ec2 describe-security-groups, and aws ec2 describe-subnets to discover compute resources and network configurations.
- Lambda and Serverless: Use aws lambda list-functions and aws lambda get-function --function-name to retrieve code and configuration.
#### Step 2: Exploiting Misconfigurations
Common AWS misconfigurations:
- Public S3 Buckets: Buckets with ACLs allowing Everyone read/write. Use aws s3api get-bucket-acl --bucket name to check. If public, you can download or upload files without authentication.
- Overly Permissive IAM Roles: Roles that trust external AWS accounts or allow sts:AssumeRole without restrictions. Use aws iam get-role --role-name to inspect trust policies.
- Unsecured EC2 Security Groups: Inbound rules allowing 0.0.0.0/0 on SSH (port 22) or RDP (port 3389). Use aws ec2 describe-security-groups and look for IpRanges with CidrIp: 0.0.0.0/0.
- Instance Metadata Service (IMDS): If an EC2 instance has IMDSv1 enabled, you can access http://169.254.169.254/latest/meta-data/iam/security-credentials/ to retrieve temporary credentials for the attached IAM role. This is a classic privilege escalation.
#### Step 3: Privilege Escalation and Lateral Movement
Once you have initial access (e.g., a low-privilege IAM user or a compromised EC2 instance), you attempt to escalate privileges. Common techniques:
- AssumeRole: If you have sts:AssumeRole permissions, you can switch to a more privileged role. Use aws sts assume-role --role-arn arn:aws:iam::123456789012:role/AdminRole --role-session-name pentest.
- Modify IAM Policies: If you have iam:PutUserPolicy or iam:AttachRolePolicy, you can grant yourself admin access.
- Leverage Lambda: If you can create/update Lambda functions, you can inject code that executes with the function's IAM role. For example, create a function that calls sts:AssumeRole on an admin role.
- Use CloudFormation: If you can create stacks, you can define resources that grant you elevated permissions.
How It Works Internally: Azure Pentesting
#### Step 1: Reconnaissance and Enumeration
Azure pentesting often begins with discovering the target tenant ID and subscription. Use az account show if authenticated. Otherwise, you may discover Azure resources through DNS enumeration (e.g., storageaccount.blob.core.windows.net) or public endpoints.
Key enumeration actions:
- Azure AD Enumeration: Use az ad user list, az ad group list, and az ad app list to map users, groups, and applications.
- Storage Account Discovery: Use az storage account list to list storage accounts, then az storage container list --account-name to enumerate containers.
- VM and Network Enumeration: Use az vm list, az network nsg list, and az network vnet list to discover compute and network resources.
- Key Vault Enumeration: Use az keyvault list to find vaults, then az keyvault secret list --vault-name to list secrets (requires permissions).
#### Step 2: Exploiting Misconfigurations
Common Azure misconfigurations:
- Public Blob Containers: Containers with anonymous access enabled. Use az storage blob list --container-name with --auth-mode anonymous to list blobs.
- Overly Permissive RBAC Roles: Users assigned roles like Contributor or Owner at the subscription level. Use az role assignment list --assignee user@domain.com to check.
- Open Network Security Groups (NSGs): Inbound rules allowing * on ports like 22 or 3389. Use az network nsg rule list --nsg-name to inspect.
- Managed Identity Misuse: If a VM has a managed identity, you can access the Azure Instance Metadata Service (IMDS) at http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com to get an access token for the identity.
#### Step 3: Privilege Escalation and Lateral Movement
Azure privilege escalation often involves:
- Pass-the-PRT (Primary Refresh Token): If you compromise a device, you can extract the PRT to impersonate the user and access resources.
- Modify RBAC Assignments: If you have Microsoft.Authorization/roleAssignments/write (e.g., as Contributor), you can assign yourself the Owner role.
- Use Azure Automation or Logic Apps: These services run with managed identities; if you can modify their runbooks, you can execute code under that identity.
- Key Vault Access: If you can access a Key Vault, you can retrieve secrets, connection strings, and certificates stored there.
Key Components, Values, Defaults, and Timers
AWS IMDSv1 vs v2: IMDSv1 uses a simple HTTP request without session control. IMDSv2 uses a PUT request to get a token, which is then used in subsequent GET requests. Default is IMDSv1, but AWS recommends v2. Pentesters should check for v1 access.
AWS S3 Default Private: By default, S3 buckets are private. However, misconfigurations often make them public. The s3:ListBucket and s3:GetObject permissions control access.
Azure RBAC Role Definitions: Built-in roles include Owner, Contributor, Reader, and User Access Administrator. The Contributor role can create and manage resources but cannot grant access to others.
Azure AD Application Permissions: Applications can have delegated permissions (user context) or application permissions (app context). Misconfigured app permissions can allow privilege escalation.
Configuration and Verification Commands
AWS:
- aws configure – set up credentials.
- aws sts get-caller-identity – verify current identity.
- aws iam list-attached-user-policies --user-name – list policies attached to a user.
- aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress]' – list instances with IPs.
Azure:
- az login – authenticate.
- az account show – display current subscription.
- az role assignment list --assignee user@domain.com --output table – list RBAC assignments.
- az vm list --query '[].[name,osProfile.computerName]' – list VMs.
How It Interacts with Related Technologies
Cloud pentesting often involves tools like nmap for network scanning (though limited in cloud due to SDN), Burp Suite for web app testing, and custom scripts using SDKs (boto3 for AWS, Azure SDK for Python). Cloud-native tools like Pacu (AWS) and Stormspotter (Azure) automate enumeration and exploitation. Understanding how these tools interact with cloud APIs is essential for the exam.
Obtain Initial Access
Begin by acquiring credentials or an access token. This could be through phishing, leaked keys in public code repositories (e.g., GitHub), or exploiting an application vulnerability that exposes cloud credentials. In AWS, you might find an IAM user's access key ID and secret access key in a configuration file. In Azure, you might obtain a refresh token or a user's password. Once you have these, authenticate to the cloud provider's CLI or API. For AWS, run `aws configure` and provide the keys. For Azure, run `az login -u user@domain.com -p password` or use a device code flow. Verify access with `aws sts get-caller-identity` or `az account show`.
Enumerate Resources and Permissions
Map out the cloud environment to understand what resources exist and what permissions you have. Use commands like `aws iam list-users`, `aws s3 ls`, `aws ec2 describe-instances` for AWS; for Azure use `az ad user list`, `az storage account list`, `az vm list`. Pay special attention to roles and policies that allow privilege escalation, such as `iam:PassRole` or `Microsoft.Authorization/roleAssignments/write`. Document all findings in a structured format, noting public-facing services and open ports. This step is crucial because it reveals the attack surface and potential lateral movement paths.
Identify Misconfigurations
Look for common cloud misconfigurations that can be exploited. In AWS, check S3 bucket ACLs and policies for public access using `aws s3api get-bucket-acl` and `aws s3api get-bucket-policy`. Examine security groups for overly permissive inbound rules. For Azure, check blob container anonymous access using `az storage container list --account-name` with `--auth-mode anonymous`. Inspect NSG rules for open management ports. Also review IAM/RBAC policies for excessive permissions. Use tools like `Pacu` or `ScoutSuite` to automate this step, but understand the underlying API calls.
Exploit Weaknesses to Escalate Privileges
Using the misconfigurations found, attempt to escalate privileges. For example, if you find an AWS role that allows `sts:AssumeRole` and you have permissions to assume it, run `aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME --role-session-name test`. In Azure, if you have Contributor role on a subscription, you can assign yourself Owner via `az role assignment create --assignee user@domain.com --role Owner --scope /subscriptions/SUBSCRIPTION_ID`. Another technique: if an EC2 instance uses IMDSv1, access `http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME` to get temporary credentials for the attached role.
Pivot and Maintain Access
After escalating, use the new privileges to access additional resources. For instance, if you obtained credentials for a higher-privileged role, use them to access S3 buckets containing sensitive data, or to create a backdoor user. In Azure, you might retrieve secrets from Key Vault using `az keyvault secret list --vault-name VAULT_NAME` and `az keyvault secret show --vault-name VAULT_NAME --name SECRET_NAME`. To maintain access, create a new IAM user or Azure AD user with admin privileges, or set up a Lambda function that periodically re-establishes access. Ensure you clean up any changes after the test.
In a real-world engagement, a pentester might assess a large enterprise that uses AWS for its production workloads. The environment includes hundreds of EC2 instances, dozens of S3 buckets, and complex IAM roles. One common scenario is discovering an S3 bucket that is publicly writable due to a misconfigured bucket policy. The pentester uses aws s3 cp localfile.txt s3://bucket-name/ to upload a test file, confirming the vulnerability. This could allow an attacker to upload malware or exfiltrate data. The remediation is to enforce private ACLs and use bucket policies that restrict access based on source IP or VPC endpoints.
Another scenario involves an Azure environment where a development team left a storage account with anonymous blob access enabled. The pentester enumerates the container using az storage blob list --container-name data --account-name devstorage --auth-mode anonymous and discovers a backup file containing database credentials. This allows them to pivot to the SQL database. The fix is to disable anonymous access and use shared access signatures (SAS) for temporary access.
A third scenario is a company using AWS Lambda with overly permissive IAM roles. The pentester finds a Lambda function that can list all S3 buckets. By examining the function's code and environment variables, they find an API key for a third-party service. They then use that key to access the third-party service, demonstrating a supply chain risk. The solution is to apply the principle of least privilege to Lambda execution roles and store secrets in AWS Secrets Manager.
Performance considerations: Cloud pentests must be careful not to cause denial of service or incur high costs. For example, scanning all S3 buckets in a large account can generate thousands of API calls, which may be throttled or billed. Pentesters should use rate limiting and test in non-production environments first. Misconfigurations often arise from default settings, lack of automated policy enforcement, or human error during rapid deployment.
The PT0-002 exam tests cloud pentesting under Objective 3.5 (Attacks and Exploits) and also touches on related objectives like 2.3 (Vulnerability Scanning) and 4.1 (Tools). Expect scenario-based questions where you must choose the correct command, identify a misconfiguration, or select the next step in an attack chain.
Common wrong answers:
1. Choosing aws s3 sync instead of aws s3 ls to list bucket contents. Candidates often confuse sync (which requires write permissions) with listing. The correct command for enumeration is aws s3 ls s3://bucket-name.
2. Believing that Azure AD applications always require admin consent. In reality, users can consent to low-risk permissions, and attackers can abuse this to gain access to resources.
3. Thinking that AWS IMDSv2 is vulnerable by default. The exam may show a scenario where an attacker accesses IMDSv1; candidates might assume v2 is also accessible, but v2 requires a token.
4. Confusing AWS IAM roles with users. Roles are assumed, not authenticated directly. A question might ask how to escalate privileges: the correct answer is to use sts:AssumeRole on a role with higher privileges, not to modify a user's policy.
Specific numbers and terms: Remember that Azure RBAC has over 70 built-in roles, but the exam focuses on Owner, Contributor, Reader, and User Access Administrator. AWS S3 bucket policies have a size limit of 20 KB. The default maximum number of IAM roles per account is 5,000 (though this can be increased).
Edge cases: The exam may test scenarios where cross-account access is possible. For example, an AWS role that trusts another account allows that account's users to assume the role. In Azure, guest users in Azure AD can be assigned roles. Also, know that Azure Key Vault supports soft-delete (enabled by default) – you can recover deleted secrets within 90 days.
To eliminate wrong answers: Focus on the underlying mechanism. If a question asks about accessing S3 without credentials, the correct answer must involve anonymous access or pre-signed URLs. If it asks about privilege escalation, look for options that modify permissions or assume roles. Eliminate answers that require physical access or provider-side changes.
Cloud pentesting focuses on customer-controlled resources; the provider secures the underlying infrastructure.
Enumeration is the first step: use cloud CLI commands to list users, roles, storage, and compute resources.
Common AWS misconfigurations: public S3 buckets, overly permissive IAM roles, open security groups, IMDSv1 enabled.
Common Azure misconfigurations: anonymous blob containers, excessive RBAC roles, open NSGs, managed identity abuse.
Privilege escalation often involves assuming roles (AWS) or modifying role assignments (Azure).
IMDSv1 allows credential theft via HTTP request to 169.254.169.254; IMDSv2 requires a token.
Azure AD applications can be used to gain access if users consent to delegated permissions.
Always check for cross-account trust policies in AWS and guest user assignments in Azure.
Use automated tools like Pacu (AWS) and Stormspotter (Azure) to speed up enumeration.
Document all findings and clean up any changes after the test to avoid leaving backdoors.
These come up on the exam all the time. Here's how to tell them apart.
AWS Pentesting
Uses AWS CLI and SDK (boto3) for API calls.
Key services: S3, EC2, IAM, Lambda, VPC.
Common enumeration: `aws s3 ls`, `aws ec2 describe-instances`.
Privilege escalation via `sts:AssumeRole` and IMDSv1.
Tools: Pacu, ScoutSuite, S3Scanner.
Azure Pentesting
Uses Azure CLI and PowerShell for API calls.
Key services: Blob Storage, VMs, Azure AD, Key Vault, NSGs.
Common enumeration: `az storage blob list`, `az vm list`.
Privilege escalation via RBAC assignments and managed identities.
Tools: Stormspotter, MicroBurst, PowerZure.
Mistake
Cloud pentesting is the same as traditional network pentesting.
Correct
Cloud pentesting differs significantly due to the shared responsibility model, API-driven infrastructure, and ephemeral resources. Pentesters must use cloud-specific tools and focus on misconfigurations in IAM, storage, and compute services rather than network-level exploits.
Mistake
You can only test AWS/Azure if you have credentials.
Correct
Some attacks require no credentials, such as enumerating public S3 buckets or Azure blob containers with anonymous access. However, most in-depth testing requires at least low-privilege credentials to enumerate resources.
Mistake
AWS IMDSv2 is completely secure.
Correct
IMDSv2 mitigates SSRF attacks by requiring a token, but it is still vulnerable if the attacker can execute arbitrary HTTP requests on the instance. Additionally, if the IAM role attached to the instance has excessive permissions, the attacker can still escalate.
Mistake
Azure RBAC roles are static and cannot be modified.
Correct
RBAC roles can be assigned, modified, and removed by users with appropriate permissions (e.g., Owner or User Access Administrator). A Contributor can assign themselves Owner if they have the `Microsoft.Authorization/roleAssignments/write` permission.
Mistake
Cloud pentesters should never use automated tools.
Correct
Automated tools like Pacu, ScoutSuite, and Stormspotter are essential for efficient enumeration and exploitation. However, manual verification is required to avoid false positives and to understand the context.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Run `aws sts get-caller-identity` to verify the credentials and see the account ID and user/role ARN. This confirms you have valid access and shows the effective identity. Then proceed with enumeration commands like `aws iam list-users` and `aws s3 ls`.
You can enumerate public-facing resources like Azure blob containers with anonymous access by using `az storage blob list --container-name <container> --account-name <account> --auth-mode anonymous`. Also, you can discover Azure AD tenant information via the Azure AD Graph API or by using tools like `az ad tenant list` if you have any access.
IMDSv1 allows direct HTTP GET requests to 169.254.169.254 to retrieve metadata, including IAM credentials. IMDSv2 requires a PUT request to get a session token, which is then used in subsequent GET requests. IMDSv2 mitigates SSRF attacks but is not foolproof if the attacker can execute arbitrary requests.
As a Contributor, you can create and manage resources but cannot assign roles. However, you can create a new user and assign them Owner role if you have the `Microsoft.Authorization/roleAssignments/write` permission, which is not granted by default. Alternatively, you can modify a VM's managed identity to grant it additional permissions, then access the VM to use that identity.
Common tools include Pacu (open-source AWS exploitation framework), ScoutSuite (multi-cloud auditing tool), S3Scanner (enumerate public S3 buckets), and custom scripts using boto3. For Azure, tools like Stormspotter (Azure security graph), MicroBurst (PowerShell toolkit), and PowerZure (PowerShell) are popular.
Yes, if you have permissions to list and invoke Lambda functions. Use `aws lambda list-functions` to enumerate, then `aws lambda get-function --function-name` to download the code. You can also invoke the function to test for vulnerabilities like injection or excessive permissions.
The cloud provider (AWS/Azure) is responsible for the security of the cloud (physical data centers, hypervisors, network), while the customer is responsible for security in the cloud (OS, applications, IAM, data). Pentesters only test customer-controlled resources and must not attack provider infrastructure.
You've just covered Cloud Pentesting: AWS and Azure — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?