The Cloud Penetration Tester / Red Team Role

What a cloud penetration tester actually does

Strip away the mystique and the job is this: you are hired to attack a cloud environment the same way a real adversary would, find the paths that lead to meaningful damage - data exfiltration, account takeover, lateral movement across accounts - document every step, and hand the customer a report specific enough that their engineers can fix it. You are a structured threat, operating under contract, inside agreed rules, and your measure of success is a kill chain the customer's security team didn't know existed until you found it.

On a normal engagement that means:

• Reconnaissance and enumeration. Starting from a set of initial credentials (or sometimes no credentials, for assumed-breach or external-initial-access scenarios), mapping the IAM landscape: what roles exist, what trust policies govern them, what services are in scope, where over-permissioned configurations sit. This is not Nmap - it is iam:List*, iam:Get*, sts:GetCallerIdentity, and API calls that look legitimate from the outside.
• Privilege escalation. Finding the chain of role assumptions, permission grants, and service integrations that leads from a low-privilege starting point to administrative access. The attack surface is IAM policies, trust relationships, cross-account configurations, and service-linked roles - not kernel exploits.
• Lateral movement. Moving from a compromised principal to other accounts, services, and data stores through role assumptions, resource-based policies, and the interconnectedness of managed services (SQS triggering Lambda triggering S3 triggering RDS is a chain, and every link is a potential pivot).
• Impact demonstration. Reaching a meaningful objective - access to sensitive data, the ability to run arbitrary compute in production, exfiltration of secrets from a key management service - to prove the path is real, not theoretical.
• Documentation and reporting. Writing a kill-chain narrative that walks the reader from initial foothold to impact, mapped to MITRE ATT&CK for Cloud, with exact API calls, affected principals, and risk-ranked remediation for each step.

How the work is structured depends on whether you're at a consultancy or an internal red team. Consultants run time-boxed engagements - typically one to four weeks per client, with a deliverable at the end and a new client immediately after. Internal red teamers run longer, more realistic campaigns with assumed-breach or full-cycle adversary simulation, often with a purple-team debrief where the findings are immediately handed to the detection and response team to build countermeasures.

Why the cloud version is a different job

People assume cloud pentesting is traditional pentesting plus a few AWS-specific modules. It isn't. The attack surface, the tooling, the exploitation techniques, the rules of engagement, and what a good report looks like are all fundamentally different. These are the twists that define the role and catch on-prem pentesters off guard when they first work a cloud engagement.

1. The attack surface is IAM and APIs, not open ports

Nmap finds almost nothing useful in a cloud environment. The attack surface is the IAM layer and the provider's API. A single over-permissioned role, a trust policy with a wildcard principal, or an EC2 instance with an attached role that has iam:PassRole and ec2:RunInstances is a privilege-escalation path to arbitrary code execution - with no CVE, no exploit, and no vulnerability in the traditional sense. The "vulnerability" is a configuration. Traditional pentesting intuition ("where are the open ports, where are the unpatched services") is actively misleading for someone who hasn't made this shift.

2. Privilege escalation runs through role assumption and trust policies

On-prem privilege escalation typically means local exploits, token impersonation, or credential reuse. In cloud it runs through sts:AssumeRole, trust policy misconfigurations, and service integrations. A common pattern: a developer credential has iam:PassRole and the ability to create a Lambda function. They can assign a highly privileged execution role to that Lambda, invoke it, and harvest the resulting temporary credentials. The whole chain is legitimate API calls - no exploit, just permissions that were granted more broadly than intended. The practitioner who can enumerate these paths systematically and trace them to impact is doing work that on-prem pentesting training doesn't prepare you for.

3. New managed services are new attack paths nobody has mapped yet

Every time AWS, Azure, or GCP ships a new managed service, that service has an IAM model, resource policies, and service-to-service trust relationships that are, initially, poorly understood by both defenders and attackers. The attacker who reads the new service's documentation faster than the blue team can review it has an asymmetric advantage. This is not theoretical - every major cloud breach in the last four years involved a managed service whose permissions model was either misunderstood or under-documented at the time of the incident. Research never stops in this role; every new service is a potential new attack path, and the community of people who've mapped them is small enough that genuine contributions get noticed.

4. "Living off the cloud" - no malware, all native APIs

A sophisticated cloud adversary never touches a payload. Every action - reconnaissance, privilege escalation, lateral movement, data exfiltration - is a legitimate API call using valid credentials. The AWS CLI, the Azure SDK, and the GCP client libraries are the attack toolkit. This has two implications. First, endpoint detection misses most of it because there's nothing on an endpoint to detect. Second, the only log trail is CloudTrail or equivalent, and a practitioner who understands which API calls are noisy versus silent can evade detection at an API level - or, from the red team perspective, can demonstrate that the blue team's detections have gaps at exactly these chokepoints.

5. Instance metadata and SSRF create cloud-specific credential chains

The instance metadata service (IMDS) at 169.254.169.254 (or the newer IMDSv2 equivalent) is a credential dispenser. An application running on an EC2 instance or a Kubernetes pod can call it to get temporary credentials for the attached IAM role. A server-side request forgery (SSRF) vulnerability in a web application that makes that call is a direct path to cloud credentials - and those credentials have the permissions of whatever role was attached to the instance, which in poorly governed environments can be substantial. The Capital One breach was this pattern at scale. Cloud pentesters test for it explicitly; the on-prem equivalent doesn't exist.

6. Provider rules of engagement constrain what you can and can't test

AWS, Azure, and GCP all have acceptable use policies that govern penetration testing. The practical constraints: you can test resources you own or have explicit written permission to test; you cannot test the provider's own infrastructure; certain high-volume testing (DDoS simulation, port scanning at scale) requires advance notification. Violations can result in account suspension. A cloud pentester who doesn't start every engagement by reviewing the current rules of engagement from each provider in scope is running legal and contractual risk. This is bureaucratic, but it's a real part of the job that on-prem practitioners don't have to think about in the same way.

Traditional pentesting asks "what services are running and are they patched?" Cloud pentesting asks "what can these credentials do, and where does that chain lead?"

The learning treadmill, in detail

Every cloud security role carries a learning treadmill. The offensive version is its most demanding form, for a structural reason: the attack surface expands every time a new managed service ships, every time a provider changes a permission model, and every time a researcher publishes a new privilege-escalation technique. The defender can wait for someone else to find the issue; the attacker has to find it first. So the treadmill never stops, and the practitioners who stay current are the ones who treat research as a core deliverable, not background reading.

Specific dimensions of the treadmill for this role:

• New services, new attack paths. AWS alone shipped several hundred new services and features in 2025. Each service has an IAM model; many have resource policies; some have service-to-service trust patterns that have never been audited offensively. A cloud pentester who doesn't have a habit of reading "what's new" and thinking "what can I do with this that wasn't possible before?" will miss the paths that matter in the next year's engagements.
• Provider permission model changes. AWS occasionally changes what an action permits, adds new condition keys, or deprecates patterns. Privilege-escalation techniques that worked last year may be patched; new ones emerge. The community maintains running lists (Rhino Security Labs, Bishop Fox, and the open-source cloud attack technique databases), but the practitioner who can find novel paths independently, not just execute known ones, is significantly more valuable.
• Tooling must keep pace. Stratus Red Team adds new techniques as researchers identify them. Pacu modules are community-maintained and coverage varies. CloudGoat scenarios are updated to reflect real attack patterns. If your tooling is six months behind, you're testing for last year's attack surface. The practitioners at the frontier write their own modules and contribute upstream.
• Cross-service exploitation chains. As organizations adopt more managed services and wire them together, the attack paths become cross-service: a compromise of a CI/CD pipeline credential leads to an ECR push leads to a Lambda deployment leads to an execution role grab. These chains are specific to the target environment and require real-time reasoning rather than playbook execution.
• AI and ML service attack surface. Inference endpoints, model hosting services, embedding APIs, and agentic frameworks each introduce new identity and data exposure patterns. The cloud red team that understands how to abuse overpermissioned model invocation roles, extract data through LLM interfaces, or exploit trust relationships between AI orchestration services and backend datastores will be ahead of the field for the next several years.

A week in the life

The shape of the week depends heavily on whether you're at a consultancy (time-boxed, client-switching, deadline-driven) or an internal red team (longer campaigns, more collaboration with blue). This is a composite Tuesday-Thursday for a senior consultant at a boutique cloud security firm, mid-engagement on a two-week AWS red team for a fintech client. The specific findings are illustrative, not transcripts.

Monday - kickoff and scoping. Two-hour kickoff call with the client's security team. Agree on scope (three AWS accounts, no production databases in scope for data access, executive simulation objectives: "can an attacker with access to a compromised developer laptop reach production data?"). Confirm the rules of engagement, the emergency contact chain, and the notification requirement if you hit a critical finding mid-engagement. Spend the afternoon in documentation: review the last engagement against this client, read their org structure in the provided scope document, set up a clean lab account and fresh credential store. Nothing has happened yet, but the setup is the work.

Tuesday - initial access and enumeration. Starting credentials: a set of developer IAM access keys from a simulated phishing compromise. The first hour is reconnaissance: sts:GetCallerIdentity to confirm the identity, iam:GetUser, iam:ListAttachedUserPolicies, iam:ListGroupsForUser. The policy attached looks innocuous - it's a managed policy for a developer role - but a custom inline policy turns up with iam:PassRole and lambda:CreateFunction. That's a privilege escalation path. Run through the Pacu IAM enumeration module to get a broader map. Two hours in, there are four potential escalation paths identified. Document each with the exact API calls and the impact if exploited. The afternoon is spent tracing one of the paths manually before automating - the manual trace catches a condition key that Pacu missed.

Wednesday - privilege escalation and lateral movement. Execute the Lambda privilege escalation: create a Lambda function, assign an execution role with broad IAM permissions, invoke the function, harvest the resulting session token via the execution context. The escalated credentials turn out to have cross-account AssumeRole access to a staging account. Spend three hours mapping the staging account's IAM model - it's messier and richer than production, as staging accounts almost always are. Find an EC2 instance with an attached instance profile that has read access to a Secrets Manager path containing production database credentials. That path technically stays in scope (it's a secrets value, not a database query); document it as a critical finding. Write the kill chain while the details are fresh: initial developer credential → IAM inline policy → Lambda escalation → cross-account trust → EC2 instance profile → Secrets Manager read → production credentials. Six steps, all legitimate API calls, no exploit, no CVE.

Thursday - impact demonstration and cleanup. Demonstrate that the harvested Secrets Manager credentials can authenticate to the production RDS endpoint from within the VPC (staying within scope - no actual data access). Take a screenshot of the successful authentication and a CloudTrail excerpt showing the complete chain. Begin the cleanup: remove the Lambda function, revoke the escalated session tokens, document every resource created during the engagement for the client's post-engagement cleanup runbook. Spend the afternoon drafting the executive summary - one page, plain English, what you found and what it means if a real attacker got there first. The technical findings follow, but the executive summary is what the CISO reads.

Friday - report and debrief prep. Write the full technical findings document: one finding per privilege escalation path, each with description, impact, affected principals, proof of exploitation (API call log and screenshot), and specific remediation (the exact IAM policy change, not "restrict permissions"). Prepare the debrief slide deck - fifteen slides, no more. The goal is for the client's engineering team to leave the debrief with a prioritized list of remediations they understand well enough to implement without a follow-up call. Send a draft to the engagement manager for review. End the week with two hours of research: there's a new IAM action in the AWS changelog that wasn't there last week, and it's worth understanding whether it opens a new path in the policy patterns you found this week.

Notice what the week doesn't look like: there's no port scanning, no CVE exploitation, no payload deployment. The entire engagement is API calls, IAM analysis, and writing. The technical depth required is substantial, but it's the depth of cloud IAM - not the depth of exploit development.

The anatomy of a cloud attack path

Cloud attack paths have a consistent structure, regardless of provider. Understanding the template helps both in executing engagements and in writing reports that defenders can act on.

Initial access

How did the attacker get their first cloud credential? The most common initial access vectors in real-world cloud incidents and in red team simulations: exposed access keys committed to GitHub (AWS scanner, truffleHog, and the like find these daily), SSRF vulnerabilities that hit the instance metadata endpoint (the Capital One pattern), stolen credentials from a developer's laptop or CI/CD environment, misconfigured public-facing storage buckets that contain credential files, and compromised CI/CD pipeline tokens. Red team engagements usually specify the starting credential as part of scope; the initial access vector is assumed or provided rather than demonstrated, unless the engagement is a full-cycle adversary simulation.

Enumeration and reconnaissance

With initial credentials in hand, the attacker enumerates what they can see. This is where cloud reconnaissance differs most from on-prem: you're not scanning a network, you're calling APIs. The key calls: iam:GetUser, iam:ListAttachedUserPolicies, iam:GetPolicy, iam:GetPolicyVersion, iam:ListRoles, iam:GetRole, sts:GetCallerIdentity. Enumeration tools like Pacu, ScoutSuite, and enumerate-iam automate the broad sweep; manual review finds the non-obvious paths the tools miss.

Privilege escalation

This is the core technical skill of cloud offensive work. The Rhino Security Labs privilege escalation research (maintained as an open-source reference) documents over twenty distinct privilege escalation paths in AWS IAM alone. The canonical ones: iam:CreatePolicyVersion on an existing policy, iam:PassRole combined with the ability to create compute (Lambda, EC2, ECS), iam:SetDefaultPolicyVersion, iam:AttachUserPolicy or iam:AttachRolePolicy without resource-level constraints. Each path requires slightly different prerequisites; the practitioner who can identify which path applies given an observed permission set - without a tool - is demonstrating genuine IAM depth.

Lateral movement

After escalation within one account, lateral movement to other accounts or services. The primary lever is cross-account trust relationships: a role in account A that trusts a principal in account B, exploitable if you control any principal in account B. Service-to-service trust (a Lambda that can call STS to assume a role in a different account, an EC2 instance profile that has cross-account S3 access) creates movement paths that aren't visible from the IAM console without dedicated analysis. The blast radius expands significantly at this stage: a single compromised developer account in one org can, in a poorly governed multi-account structure, chain into an administrative role in the root account.

Impact

What does "impact" look like in a cloud engagement? The classic objectives: read from a sensitive S3 bucket or database, exfiltrate secrets from Secrets Manager or Parameter Store, create a backdoor IAM user or access key for persistence, deploy a cryptominer or ransomware (in a sandbox account if the client has one), or demonstrate the ability to delete or corrupt production infrastructure. The report needs to show which objective was reached or could be reached if the engagement scope permitted it - "here is the credential we could use to authenticate to the production database" is a complete finding even if we stopped before actually running the query.

The skill stack

There's a stable core and a moving edge. Build the core deliberately; the edge is where you distinguish yourself from tool operators.

The stable core

• IAM at depth. Not "I know what IAM is" - you need to be able to read any IAM policy, trust policy, or permission boundary and immediately identify what it allows, what it prevents, and what paths it opens or closes. This takes months of deliberate practice in real environments. It is the single most-tested skill in cloud offensive interviews.
• One traditional pentesting foundation. Web application testing, network pentesting, or both. Cloud attack paths often start from a web app SSRF, a Kubernetes RBAC misconfiguration, or a container escape. The pure-cloud-API attacker misses the seam between application and cloud infrastructure.
• Scripting. Python or Bash, minimally. The ability to write a script that chains three API calls to demonstrate a multi-step privilege escalation path, and to clean up after yourself, is non-negotiable. Most custom cloud tooling is Python against boto3 (AWS) or the equivalent Azure/GCP SDKs.
• Attack chain reasoning. Given a set of permissions, trace the full graph of reachable principals and actions. This is graph reasoning - the mental model is a directed graph where edges are trust relationships and AssumeRole calls. Tools like PMapper visualize it; you need to understand it without a tool to catch the cases tools miss.
• Report writing. A kill-chain report is the deliverable. The ability to write clearly, explain a complex technical finding to a CISO who isn't an IAM expert, and produce a remediation recommendation specific enough to implement is as important as the testing skill. Many good testers plateau because their reports are weak; the senior practitioners who get referred back are usually excellent writers.
• Operational security. Cloud API calls land in CloudTrail. An engagement where you immediately trigger every detection the client has deployed is useful for testing those detections, but a real adversary wouldn't. Understanding which API calls are logged, which logs are retained, and how detection logic works lets you model both the covert path and the noisy path - and explain both in the report.

The moving edge

• New managed service IAM models and resource policies as the providers ship them (the treadmill).
• Container and Kubernetes offensive: pod escape, RBAC escalation, projected service account token attacks. See Kubernetes security and containers.
• Serverless attack patterns: function injection, event-source abuse, cold-start credential harvesting.
• AI/ML service exploitation: model hosting permissions, inference endpoint abuse, data extraction through LLM interfaces. See AI/ML security.
• Supply chain attack paths through CI/CD pipelines: OIDC token abuse, workflow injection, artifact tampering.
• Federation and SSO exploitation: SAML injection, OIDC misconfiguration, federated identity trust abuse.

Tools of the trade

Cloud offensive tooling is younger and more fragmented than the on-prem toolkit. Understand the categories and the leading tools in each; expect to write custom scripts to fill the gaps.

AWS offensive tooling

• Pacu - the open-source AWS exploitation framework from Rhino Security Labs. Modular: enumeration, privilege escalation, persistence, exfiltration modules. The starting point for any AWS engagement, though modules vary in currency. Understand what each module does before running it in a client environment.
• enumerate-iam - brute-forces what API actions a given credential set can call, by trying them all. Noisy but thorough; useful in a permissive scope or as a baseline before targeted enumeration.
• PMapper (Principal Mapper) - graphs IAM relationships and privilege escalation paths across an account or organization. The visualization is the clearest way to show a client a multi-hop escalation path in a report.
• WeirdAAL (Weird Amazon AWS Labs) - a collection of reconnaissance and post-exploitation modules for specific services. Useful for targeted service enumeration after you know what's in scope.
• AWS CLI + boto3 - the native toolkit. For any chain more than three steps, a custom Python script against boto3 is cleaner and easier to clean up than running discrete CLI commands.

Azure offensive tooling

• ROADtools - Dirk-jan Mollema's toolkit for Azure Active Directory / Entra ID enumeration and attack. Essential for any Azure engagement with an identity component - which is all of them. The roadrecon tool builds a local graph database of the tenant's identity relationships.
• AADInternals - PowerShell module for Azure AD and Microsoft 365 attacks. Token manipulation, password spray, Golden SAML, and tenant enumeration. The most comprehensive Azure identity offense tool.
• MicroBurst - PowerShell module for Azure service enumeration and post-exploitation. Storage account enumeration, App Service configuration extraction, key vault access.
• BloodHound with AzureHound - the original BloodHound is for Active Directory; AzureHound extends the graph collection to Azure RBAC and Entra ID relationships. Increasingly useful as Azure environments become more complex.

GCP offensive tooling

• GCP-IAM-Privilege-Escalation - the research and tooling from Rhino Security Labs that documents and demonstrates GCP IAM privilege escalation paths, analogous to their AWS work. The starting reference for GCP offensive IAM work.
• GCPBucketBrute - Google Cloud Storage bucket enumeration. Less critical than on AWS since GCP default permissions are generally better, but still useful in poorly governed environments.
• gcloud CLI + Python client libraries - same principle as AWS: for multi-step chains, write a script.

Multi-cloud and cross-cutting tooling

• Stratus Red Team - atomic cloud attack techniques from Datadog's security research team, mapped to MITRE ATT&CK for Cloud. Designed for purple teaming and detection validation as much as red teaming; the most rigorous current reference for cloud attack technique coverage.
• ScoutSuite - multi-cloud security auditing tool (AWS, Azure, GCP, Oracle). More blue-team posture assessment than red-team exploitation, but essential for rapid reconnaissance at the start of an engagement to understand the overall environment.
• CloudGoat - Rhino Security Labs' intentionally vulnerable AWS lab environment. The standard training environment; scenarios are aligned to real-world attack patterns. The most useful CloudGoat scenarios to work through: "vulnerable lambda," "iam_privesc_by_attachment," "cloud_breach_s3," and "misunderstood_permissions."
• IAM-Vulnerable - a Terraform-provisioned intentionally misconfigured AWS account with multiple privilege escalation paths. A useful companion to CloudGoat for IAM-specific practice.
• AWSGoat / AzureGoat / GCPGoat - intentionally vulnerable environments from INE Security, covering application-to-cloud attack chains rather than pure IAM paths. Good for practicing the web-app-to-cloud-credential scenario.

Rules of engagement and provider constraints

This is the operational reality of the job that no training environment prepares you for. Cloud pentesting operates inside legal and contractual constraints that have no direct on-prem equivalent, and violating them - even accidentally - can result in account suspension and voided contracts.

Provider acceptable use policies

All three major providers have customer agreements that govern what testing is and isn't permitted on their platforms. The practical rules as of 2026:

• AWS: You may test resources you own or have explicit written authorization to test. Certain activities - DDoS simulation, DNS zone walking, port scanning at volume - require advance notice to AWS. Social engineering of AWS support is not permitted. The full policy is in the AWS Customer Agreement and the AWS Penetration Testing FAQ; read both before every engagement.
• Azure: Microsoft's Penetration Testing Rules of Engagement are a separate document requiring review. You must submit a Penetration Testing Notification form for engagements targeting Azure resources. The rules are similar to AWS: test what you own or have authorization for, no attacks on Microsoft infrastructure itself.
• GCP: Google permits security testing within your own organization's Google Cloud resources without prior approval for most testing activities, with exceptions for certain high-traffic or cross-customer scenarios. Review the current Google Cloud Terms of Service and Acceptable Use Policy.

Getting authorization right

Before starting any engagement: confirm that the scope document explicitly names every account ID, subscription ID, and project ID in scope. Confirm that the client has written authorization to test those resources (they own them or have contractual rights to authorize testing). Keep a copy of that authorization with you during the engagement - you may need it if an automated alert generates a call from the provider's abuse team. Engagements that accidentally drift out of scope (a cross-account trust chain that leads to an account not listed in the scope doc) need to stop and confirm authorization before proceeding.

Evidence collection and cleanup

Every resource created during an engagement - Lambda functions, IAM users, EC2 instances, access keys - needs to be documented and cleaned up at engagement close. The cleanup runbook is a deliverable, not an afterthought. Leaving test resources in a client environment is a direct liability: they may be discovered by real attackers, or trigger compliance findings during an audit. Senior practitioners build cleanup into their workflow in real time rather than leaving it as a post-engagement task.

Writing the kill-chain report

The report is the product. A brilliant exploit chain that's written up poorly does less for the client than a moderate finding with a clear narrative and specific remediation. This is where the best cloud pentesters separate themselves from the tool operators - and where many good technical testers plateau.

Structure of a cloud pentest report

The format that works: executive summary (one page, no jargon, written for the CISO and the board), followed by attack path narrative (the full kill chain in chronological order, written like a breach story), followed by individual findings (one per exploitable path, each with description, risk rating, evidence, and remediation), followed by recommendations summary and remediation roadmap.

Writing the kill chain narrative

The attack path narrative should read like a breach post-mortem, not a list of commands. "The tester compromised a developer credential via simulated phishing, identified an inline policy granting iam:PassRole and lambda:CreateFunction, used those permissions to create a Lambda function with an execution role granting sts:AssumeRole into the production account, and harvested production secrets manager values from within that execution context" is a narrative. "Step 1: enumerate IAM. Step 2: run Pacu module. Step 3: escalate privileges" is not. Map each step of the narrative to the relevant MITRE ATT&CK for Cloud technique - Initial Access, Execution, Privilege Escalation, Lateral Movement, Collection, Exfiltration as appropriate.

Individual findings

Each finding needs: a clear title (not "IAM misconfiguration" - "Developer role with iam:PassRole enables Lambda privilege escalation to AdminAccess"), a risk rating with a brief rationale, the affected principal(s) with ARNs or object IDs, proof of exploitation (CloudTrail excerpt, API call log, screenshot), and remediation that is specific enough to implement. "Restrict IAM permissions" is not a remediation. "Remove the iam:PassRole permission from the dev-role managed policy (arn:aws:iam::123456789012:policy/dev-role-policy) or add a resource-level condition restricting PassRole to non-administrative roles" is a remediation.

The remediation roadmap

At the end of the findings section, a prioritized remediation roadmap: the five things to fix first, ordered by exploitability times impact, with time estimates. This is the part the security engineering team reads. If your fifteen-page findings section doesn't have this summary, the team will prioritize based on whichever finding they read first - which is rarely the most important one.

The multi-cloud dimension

Cloud pentesting is not "cloud pentesting" - it's AWS pentesting, Azure pentesting, and GCP pentesting, each with a distinct IAM model, distinct tooling, and distinct privilege escalation patterns. The three are not interchangeable, and the practitioner who advertises "multi-cloud" without specific depth in at least two providers is usually a generalist in reconnaissance with specialist-level gaps in exploitation.

AWS

The largest market, the most mature attack research, and the most well-documented privilege escalation paths. AWS IAM is explicit - every permission must be granted - which means misconfiguration almost always looks like overly broad grants rather than implicit permissions. The attack surface is well-mapped by Rhino Security Labs, Bishop Fox, and the open-source community. Pacu is the primary toolchain. The most productive escalation vectors: iam:PassRole, iam:CreatePolicyVersion, iam:AttachUserPolicy, and EC2 instance metadata abuse. Cross-account trust via Organizations and the AWS shared account model creates lateral movement paths that are unique to AWS's architecture. See AWS security.

Azure

Azure's attack surface is dominated by Entra ID (formerly Azure AD). Every Azure resource has an identity layer, and the Azure RBAC model layered on top of Entra ID creates a rich target for offensive work. ROADtools and AADInternals are the primary tools. The most productive Azure attack paths run through service principals with excessive permissions, Managed Identity abuse (analogous to EC2 instance profiles on AWS), and the IMDS endpoint at 169.254.169.254 (same IP, same pattern as AWS but Azure-specific credential chains). Azure's strong default integration with Microsoft 365 means a compromised Azure credential often opens paths into Exchange, SharePoint, and Teams as well - a scope question you need to clarify upfront. See Azure security.

GCP

GCP's IAM model is arguably the cleanest of the three providers, which doesn't mean it's unexploitable - it means the misconfigurations tend to be more deliberate and less accidental. The GCP attack surface centers on service accounts, the primitive roles (Owner, Editor, Viewer at project level - which are still in use in many organizations), the Workload Identity Federation, and the GCP metadata server. GCP privilege escalation research is less mature and less publicly documented than AWS, which means a practitioner who invests here has asymmetric knowledge advantage. The default audit logging in GCP is better than AWS's, which raises the bar for evasion. See GCP security.

Which to specialize in first

AWS, by default, for the largest job market and the most mature attack tooling and research. Once you can trace and exploit privilege escalation paths in AWS IAM from memory, adding Azure takes roughly three to six months of deliberate practice - you're mapping concepts, not starting from zero. GCP comes faster after Azure because the conceptual models rhyme. The practitioners who command the highest consulting rates are genuinely fluent in at least two providers, not surface-level familiar with all three.

How the role changes by company stage

• Boutique cloud security consultancy. Time-boxed engagements, 3-12 clients simultaneously in the queue, high client diversity, broad service exposure. The fastest way to see a large variety of cloud misconfigurations in a compressed timeframe. Comp is typically lower than large tech but the learning curve is steep and the portfolio fills quickly. Utilization rate pressure is real; non-billable time for research and tooling has to be negotiated.
• Big-4 and large consulting firms. Bigger brand, larger deal flow, more process. Cloud pentesting is often a subset of a broader security practice, and you'll be asked to do traditional pentesting alongside cloud work. Better entry-level comp and structure; the pure cloud offensive depth tends to be shallower than boutiques unless you join a specific cloud-native practice within the firm.
• Internal red team at a large tech company. The highest-comp option and the most realistic scenario work - you're simulating adversaries against the same environment you'd be a real target in. Longer campaigns, more collaboration with the detection and response team, less report writing, more purple-team work. Entry requires significant prior external consultancy experience; these teams are small and selective. The trade-off is less variety - you're learning one (large, complex) environment deeply rather than many environments broadly.
• Internal red team at a non-tech enterprise. Financial services, healthcare, and critical infrastructure companies with mature security programs run internal red teams. The work is more compliance-adjacent (penetration testing as a SOC 2, PCI, or FedRAMP requirement) than pure adversary simulation. Comp is lower than tech; the work is more predictable; the policy and governance context is richer.
• Government and national security contractors. Classified and cleared work at agencies or contractors is a separate track. Comp is competitive (especially with cleared roles), the adversary models are more sophisticated, and the career path can diverge significantly from the commercial track. A security clearance is required; the application process takes months to years.

Salary & compensation

US, 2026, approximate. The offensive security market is small enough that individual negotiating leverage is high for senior practitioners - the numbers below are ranges, and the top end reflects what genuinely scarce talent can command.

• Junior consultant / associate (0-2 yrs offensive experience): $90K-$130K base. Often at a large consultancy where cloud pentesting is a subset of broader work. Utilization-based bonus common at consultancies.
• Mid-level consultant / senior associate (2-5 yrs): $140K-$200K base. Starting to specialize in cloud; running engagements semi-independently. Boutique cloud firms pay at the higher end of this range.
• Senior consultant / principal (5-8 yrs): $190K-$260K base. Independent engagement ownership, client relationship management, research and tooling contributions. Internal red team roles at large tech companies sit here.
• Lead / staff / principal red team engineer (8+ yrs): $250K-$350K+ base at tech companies, with total comp pushing $400K-$500K+ at the FAANG tier via equity. This is a genuinely small population - these roles exist at fewer than 50 companies. The practitioners at this level are recognizable names in the community.

Consulting firms often pay bonuses tied to individual utilization or team performance; tech companies pay equity with four-year vests. Outside the US, halve the numbers and add a question mark. For current data, check levels.fyi, the BLS information security analysts data, and compensation threads on r/cybersecurity. The full picture is on the careers salary section.

The interview loop for this role

Cloud offensive interviews are more technically specific and harder to fake than most security interviews. Hiring managers in this niche have usually done the work themselves and can tell the difference between "ran the tools" and "understands what the tools do and why." Expect a technical screen that goes deep fast.

• IAM policy analysis. They give you an IAM policy, a trust policy, or a permission set and ask what it allows, what escalation paths it opens, and how you'd exploit it. The single most common screen - practice it on real policies until it's reflexive. The CloudGoat scenarios are excellent preparation because the policies are realistic.
• "Walk me through an attack chain." Describe a multi-step cloud attack path from initial credential to impact. They want to hear specific API calls, specific IAM actions, and specific service names - not abstract descriptions. They're testing whether you've done this, not read about it.
• Take-home lab. A provisioned AWS account or an intentionally vulnerable environment (often a custom scenario similar to CloudGoat). Find the paths, write the kill chain and report. This is the strongest signal in both directions: it shows what you actually do when no one is watching, and it filters out candidates who can talk the talk but not exploit the policy.
• Tool discussion. "Tell me about a Pacu module you use regularly - what does it do at the API level, and what does it miss?" The question is probing whether you understand the tool or just invoke it. Same for ROADtools, ScoutSuite, and any other tools you list on your resume. If you listed it, know it at depth.
• Report review. Some loops ask you to bring a sanitized sample from a real engagement or to critique a sample report they provide. They're checking whether you can write a clear finding, not just find the vulnerability.
• Rules of engagement and ethics discussion. Especially at consultancies. How do you handle finding something out of scope? What do you do if an engagement turns up evidence of a prior breach? What's your process for cleanup? These are practical judgment questions, not gotchas.

Portfolio projects that prove the role

More than any other cloud security role, the penetration tester portfolio needs to show active offensive work, not just theoretical knowledge. Published write-ups of exploited chains - even from training environments - are the closest signal to real work that a hiring manager can evaluate before the interview.

1. Work through CloudGoat scenarios and publish write-ups. Every scenario you complete should be a published post: the initial credentials, the enumeration steps, the specific IAM actions you identified, the escalation chain, and the remediation for each finding. The Misunderstood Permissions and IAM Privesc by Attachment scenarios are the highest-signal ones to start with. Quality over quantity - one detailed write-up is worth five brief ones.
2. Contribute a module or technique to an open-source tool. A Pacu module you wrote, a new CloudGoat scenario, a detection gap you identified in Stratus Red Team. This is the clearest possible signal of genuine depth and community engagement. Even a modest contribution to a recognized tool demonstrates you understand the underlying API behavior, not just the tool's interface. See open-source contribution portfolio project.
3. Recreate the Capital One breach chain in a lab. Provision an EC2 instance with an SSRF vulnerability, expose it to a metadata endpoint, harvest the instance profile credentials, and demonstrate the S3 enumeration and access chain that followed. Then write the defensive recommendations. This demonstrates both offensive technique and the ability to map a known incident to your own hands-on work.
4. Build and publish a privilege escalation path in a personal AWS account. Provision IAM roles and policies in your own account, find the escalation paths (use IAM-Vulnerable as a template), document each path with the specific API calls and the resulting access, and write the remediation. The home lab guide covers the setup; this project builds on top of it.
5. Design an AWS Organization with preventive controls that block the escalation paths you've exploited. This proves you can see both sides - find the path and close it. Hiring managers for senior roles specifically want to see this defensive counterpart, because it demonstrates the understanding that makes a report actionable rather than theatrical.

How to break in (and pivot from adjacent roles)

Nobody enters cloud pentesting from zero. The standard path runs through traditional offensive security first, then adds cloud - but there are real on-ramps from several adjacent backgrounds. You're a natural fit if you currently:

• Do traditional pentesting and hold OSCP, OSEP, PNPT, or similar. This is the most common path. The foundational offensive mindset - enumerate, hypothesize, exploit, document - translates directly. What you need to add is deep AWS or Azure IAM knowledge, cloud-specific tooling (Pacu, ROADtools), and hands-on time in CloudGoat and IAM-Vulnerable. Six months of deliberate weekend practice, a few published write-ups, and the interview is very approachable. SANS SEC588 as a structured on-ramp is worth the investment if your employer will fund it.
• Compete in CTFs, especially cloud-specific ones. CTFs have a direct on-ramp into this role more than almost any other security specialty. If you compete and - critically - write up your solutions publicly, hiring managers see exactly what kind of thinker you are. CloudGoat, the HackTheBox cloud challenges, and fwd:cloudsec CTFs are the most aligned. The write-up discipline is important - many CTF players solve challenges but never publish their work, and the published work is what builds the reputation.
• Were a red-teamer in on-prem environments. If you've run adversary simulation exercises against Active Directory and Windows environments, adding cloud scope is a narrower gap than starting from web app testing. Your mental model for attack chains, persistence, and report writing is already there. Focus your study time on the cloud IAM models (AWS first) and the cloud-specific tooling. BloodHound to PMapper is a natural conceptual bridge.
• Did the SANS offensive track (SEC560, SEC588). SEC588 is the most direct cert-course path to this role. It covers AWS and Azure attack techniques with lab exercises, and the GPEN / GPEN credentials carry weight at consultancies that hire from this pool. The course is expensive; if your current employer has a training budget, this is the allocation to argue for.
• Are a cloud security engineer (defensive) who wants to move offensive. This is an underrated pivot. You already have IAM depth, cloud service knowledge, and the defensive mental model - you need to add the offensive technique set. The advantage is that you understand why controls are configured the way they are, which makes your attacks more targeted and your reports more actionable. The gap is usually tooling familiarity and the "think like an attacker" mindset shift, which CloudGoat solves faster than any other approach.

The mechanics of the search - resume, referrals, where hiring actually happens - are in the careers pivot guide. The learning path covers the skills foundation; the certifications guide covers which credential is worth pursuing at each career stage for this specific track.

Where this role leads

The career trajectory for cloud offensive practitioners branches more than most security specialties, because the skills are genuinely rare and the market is willing to pay for them in several different directions.

• Senior/principal red teamer. The IC track upward within offensive security. At large tech companies this is a real title with meaningful scope - leading multi-week adversary simulation campaigns, owning tooling and research, briefing senior leadership. Comp at the top of this track in tech is exceptional; the path is narrow and competitive.
• Detection engineer. A natural counter-rotation: someone who understands attack paths deeply is well-positioned to build detections that catch them. Many experienced pentesters make this transition around year 7-10. The shift requires building out the defensive tooling skill set (SIEM, query languages, telemetry pipelines), but the threat model knowledge is immediately valuable. Purple team roles explicitly combine both.
• Incident responder. Cloud incident response benefits enormously from practitioners who understand how attackers move through cloud environments. An IR lead who has personally executed the privilege escalation chains they're now hunting for is a meaningful step up from one who has only read about them.
• Cloud security architect. Senior pentesters who develop a taste for building things rather than breaking them sometimes make this transition. The architecture role benefits from knowing every attack path the architecture needs to prevent; the consulting background gives you pattern recognition across a wide range of environments that internal architects often lack.
• Research and tooling. A small but well-compensated path: security researcher at a vendor, a think tank, or as an independent. The practitioners who publish novel privilege escalation techniques, author CVEs against cloud services, and contribute foundational tooling are a tiny community with outsized influence on the whole field. The financial ceiling is lower than enterprise tech roles (unless you found a company), but the career satisfaction is high and the community recognition is significant.
• Founder or practice lead at a boutique. Many experienced cloud pentesters eventually start their own shops. The barriers are lower than most industries - a strong technical reputation, a few anchor clients, and a handful of practitioners who want to work with you is the starting package. The risk is on the business side, not the technical side.

Common mistakes

• Running tools without understanding them. "I ran Pacu and got these findings" is not a cloud pentest. Hiring managers ask what the tool does at the API level. If you can't answer, you won't be hired - and if you land the role anyway, you'll miss the paths the tools don't cover, which are often the most interesting ones.
• Skipping the traditional pentesting foundation. Jumping straight to cloud attack tooling without a solid base in web application security and general network pentesting produces practitioners who can exploit IAM misconfigurations but can't find the SSRF that harvests the instance metadata credentials. The chains start from somewhere.
• Writing bad reports. The report is the deliverable. A technically excellent engagement with a poorly written report is a missed opportunity for the client and a weak signal to future employers. Write every report as if it's your portfolio piece - because it is.
• Not publishing your work. The cloud offensive community is small and public contributions get noticed. A published CloudGoat write-up, an open-source tool contribution, a conference talk - these build the reputation that generates inbound interest from hiring managers and interesting clients. The practitioners who wait until they feel ready to publish usually wait forever.
• Ignoring the learning treadmill. Cloud IAM and service models change faster than most attack surfaces. A practitioner who mastered AWS privilege escalation paths two years ago and hasn't kept up has missed new services, new escalation vectors, and new detection evasion patterns. The research habit is the job, not the prerequisite.
• Testing outside authorized scope. A cross-account trust chain that leads to an account not in the scope document is an out-of-scope finding, even if it's the most interesting path you've found. Stop, document, notify the client, and get authorization before proceeding. The legal and reputational cost of testing without authorization is career-ending; the cost of pausing to get written authorization is a few hours.
• Forgetting the defensive context. The best cloud pentesters understand what the blue team can and can't see. If you don't know which API calls land in CloudTrail with high visibility, you're not modeling realistic adversary behavior - you're just finding misconfigurations. Understand the detection landscape at least at the level of "what would a competent detection engineer catch of what I just did, and what would they miss?"

How AI is changing the role

The net effect of AI on cloud offensive work is probably more nuanced than either "AI will make pentesting irrelevant" or "nothing changes." The realistic picture as of mid-2026:

What AI is doing for offense: Large language models are genuinely useful for accelerating the early phases of reconnaissance and enumeration - feeding an IAM policy dump into a model and asking "what escalation paths exist here?" is faster than manual review for the well-understood patterns. AI is also useful for drafting the first version of a privilege escalation Python script against boto3, for translating Pacu module logic across providers, and for the initial draft of a findings summary in a report. Practitioners who use AI for these acceleration tasks are meaningfully faster than those who don't.

Where AI falls short: Novel attack path discovery - finding a privilege escalation chain in a new managed service that nobody has mapped before - requires reasoning about undocumented or poorly documented behavior that models don't reliably know. The hands-on intuition developed from running hundreds of engagements ("this policy pattern looks like the one I saw in a fintech engagement two years ago where the custom inline policy had an overly broad PassRole") is not in any model's training data. And the social and contextual dimensions of a real engagement - explaining a complex finding to a CISO who is scared, managing scope discussions mid-engagement, making judgment calls about edge-case authorization questions - remain firmly human.

AI as a new attack surface: AI and ML services are themselves a growing attack surface that cloud pentesters are increasingly expected to cover. Overpermissioned model invocation roles that can be used to exfiltrate data through inference endpoints, prompt injection in agentic pipelines that have cloud API access, and embedding store poisoning are emerging techniques that the offensive community is actively mapping. The practitioner who understands both the cloud IAM model and AI/ML service architectures is well-positioned for the next five years of this work. See AI/ML security for where the defensive community is tracking this.

The net headcount effect is probably slight growth in demand for genuine offensive practitioners, with compression at the bottom of the market (AI can do basic "run the tool and summarize the output" work), and a raising of the floor for what "cloud pentesting" means to a sophisticated buyer. The practitioners who will be in demand in 2028 are the ones doing original research, writing novel tooling, and delivering reports that read as genuinely expert - none of which is meaningfully replaceable by current AI capabilities.

Quick answers

What does a cloud penetration tester actually do?

Attacks cloud environments under contract to find the paths from initial credential to meaningful impact - data access, account takeover, lateral movement. The attack surface is IAM and APIs, not open ports. The deliverable is a kill-chain report mapped to MITRE ATT&CK for Cloud with specific remediation at every step.

Why is cloud pentesting different from traditional pentesting?

The attack surface is entirely in the IAM layer and the provider's API - there's no Nmap scan, no CVE to exploit. Privilege escalation runs through role assumptions and trust policies, not kernel exploits. Every action is a legitimate API call with stolen or assumed credentials. Provider rules of engagement constrain what you can test and how.

How much do cloud penetration testers make?

US 2026 approximate: consultants $120K-$200K base, senior consultants $170K-$260K. Internal red team at large tech $180K-$280K+ base with total comp significantly higher via equity. The market is small; top performers command significant premiums.

What tools do cloud penetration testers use?

AWS: Pacu, enumerate-iam, PMapper, the AWS CLI and boto3. Azure: ROADtools, AADInternals, MicroBurst, BloodHound with AzureHound. Cross-cloud: Stratus Red Team, ScoutSuite. Training: CloudGoat and IAM-Vulnerable for AWS, AzureGoat for Azure. Custom Python scripts for multi-step chains.

Do I need OSCP to become a cloud penetration tester?

Not strictly required, but it's a strong baseline that most hiring managers look for because it proves you can execute traditional offensive techniques under pressure. SANS SEC588 is more directly relevant to cloud-specific work. For pure cloud offensive roles at boutique shops, published CloudGoat write-ups and a demonstrated IAM attack chain are more convincing than any single cert.