Cloud Offensive Security & DevSecOps: Attacking the Control Plane

When traditional network penetration testers pivot to the cloud, they repeatedly make the same fatal error: they hunt for IP addresses. In a modern AWS, Azure, or GCP environment, IP addresses are ephemeral. Virtual machines are cattle. The traditional perimeter is dead.

In the cloud, Identity is the new perimeter. The API Control Plane is the golden ticket.

This is an After-Action Report detailing a multi-cloud Red Team engagement against a heavily defended, compliance-bound financial organization. It is not a list of automated tools. It is a mapping of the modern attacker mindset: entry, pivot, IAM abuse, and ultimate control.

1. Entry Strategy (The Cloud Mindset)

Upon receiving our initial foothold—a low-privileged set of AWS Access Keys belonging to a junior developer—my first move is not to fire up Nmap and scan the VPC. Nmap is irrelevant here.

My first move is answering three API-driven questions: Who am I? What can I assume? Where are the secrets? Traditional pentest mindsets fail here because they attack the workload (the web app). A Cloud Red Teamer attacks the fabric (the AWS/Azure API). If I exploit a server, I win a server. If I exploit an overly permissive IAM policy, I win the entire datacenter.

2. IAM Enumeration: The Core Attack Surface

I immediately profile the compromised key’s permissions using aws sts get-caller-identity. I am arn:aws:iam::123456789012:user/dev-jdoe.

I don’t look for what I can do; I look for what I can become. I pull the inline and attached policies to map Privilege Escalation paths. I am specifically hunting for dangerous combinations: iam:PassRole, iam:CreatePolicyVersion, or sts:AssumeRole. Thinking: “I don’t need Admin rights right now. I just need the ability to attach a policy to an EC2 instance profile, and then pass a highly privileged role to that instance.”

3. Initial Recon (Cloud-Specific)

I silently map the environment explicitly via the AWS CLI and custom Boto3 scripts to avoid triggering GuardDuty anomalies.

• IAM Roles: Mapping Trust Relationships across the AWS Organization.
• S3 Storage: Hunting for loosely secured Terraform state files (.tfstate).
• Compute: Listing EC2 metadata and attached instance profiles.
• Serverless: Dumping Lambda function environmental variables.

I am not firing vulnerability scanners. I am mapping logical boundaries and misconfigurations. Logic flaws are invisible to standard TVM (Threat Vulnerability Management) scanners.

4. The Critical Decision Point

Within 20 minutes, my recon scripts highlight three targets:

1. s3://finance-backup-assets is allowing s3:GetObject to any authenticated AWS user.
2. arn:aws:iam::role/Lambda-Execution-Role has an overly permissive trust policy.
3. An internal API Gateway endpoint lacks AWS WAF association.

The Decision: I ignore the API and the Lambda role. I go straight for the S3 bucket. Why? The API requires me to start fuzzing for logic flaws (which is loud). The Lambda role requires assumption chains (which generates heavy CloudTrail logs). But a misconfigured S3 bucket in a DevOps environment almost always contains infrastructure-as-code files. Reading a .tfstate file is entirely silent and provides me the blueprint of their entire network, including hardcoded pipeline secrets.

5. Privilege Escalation Path: The IAM Chain

Inside the Terraform state file recovered from the bucket, I find a legacy GitLab Runner access token. I pivot into their CI/CD environment.

I find that the GitLab Runner possesses an AWS role: arn:aws:iam::role/gitlab-deployment-runner. Because this role is designed to tear down and stand up infrastructure, it has iam:PassRole and ec2:RunInstances.

The Chain:

1. From GitLab, I trigger a rogue pipeline job.
2. The job uses ec2:RunInstances to spin up a tiny Linux instance.
3. Critically, it uses iam:PassRole to attach the arn:aws:iam::role/Prod-Database-Admin role to this new instance.
4. I pull the temporary metadata credentials (http://169.254.169.254/latest/meta-data/iam/security-credentials/Prod-Database-Admin) from my rogue instance.

I just escalated from a junior developer to a Production Database Administrator without ever triggering an exploit payload. It is 100% legitimate API architecture, maliciously chained.

6. Cloud Misconfiguration Exploitation

With my new high-privileged role, my lateral movement expands. I look at their network boundaries.

I find an Open Security Group (0.0.0.0/0 on Port 6379) attached to an ElastiCache Redis cluster, presumably created temporarily for troubleshooting and forgotten. Because the identity boundary was weak (I am now an Admin) and the network boundary was open, the attack path is trivial.

Real-world impact: Redis data is completely unauthenticated inside that VPC. I dump the cached JWT session tokens of active banking customers.

7. Container & Kubernetes Attack

The bank operates a massive Azure Kubernetes Service (AKS) cluster. We pivot scopes.

I find a pod running a custom reporting application. The application is vulnerable to a simple Command Injection. I pop a reverse shell inside the container. A traditional pentester might run uname -a and look for kernel exploits. I look for the run/secrets/kubernetes.io/serviceaccount/token.

Because of an RBAC (Role-Based Access Control) misconfiguration, the developer assigned a default ServiceAccount to this pod that possesses cluster-admin privileges. I immediately query the Kubernetes API:

curl -ik -H "Authorization: Bearer $(cat token)" https://kubernetes.default.svc/api/v1/namespaces/kube-system/secrets

I successfully dump every TLS certificate, database password, and API key stored in the entire cluster. Containers drastically increase the attack surface because a single compromised microservice often shares incredibly powerful underlying identity contexts.

8. Serverless & API Attack Surface

Back in AWS, I turn to their Serverless footprint. I identify a Lambda function triggered by an API Gateway (/process-ledger).

Lambda functions scale infinitely. I discover the function parses user input via evaluating a Python eval() statement. By crafting a specific JSON payload, I achieve Remote Code Execution inside the Lambda container. I immediately dump os.environ. Lambda functions pass their IAM execution credentials as ambient environment variables.

I just stole the execution role of the Lambda tier, granting me direct access to the DynamoDB tables behind it. Function-as-a-Service (FaaS) is just someone else’s server temporarily running your code; you can still exploit the host.

9. CI/CD Pipeline Compromise: The Apex Attack

Targeting the CI/CD pipeline is the apex predator of cloud attacks. If I compromise production, I win once. If I compromise the pipeline, I own the entire supply chain forever.

The developers stored infrastructure secrets inside Jenkins Environment Variables rather than a mature Vault solution. Since I compromised a Jenkins worker node via a weak plugin, I read the memory space.

I extract the master deployment keys. The Impact: I do not need to exploit their cloud anymore. I can simply commit malicious code to their master repository, and their own trusted pipeline will beautifully, cleanly deploy my backdoor into the production Azure environment automatically.

10. TVM & Automation Strategy: System Design Thinking

As an offensive operator, my goal is to make my own attacks obsolete. Traditional TVM (Threat Vulnerability Management) relies on weekly authenticated scans using Nessus or Nexpose. In the cloud, infrastructure stands up and dies in minutes. Weekly scans are useless.

I integrate continuous scanning natively into their pipeline:

• Trivy / Checkov: Running on every commit to block overly permissive IAM roles inside Terraform before they are applied.
• Feedback Loop: If an engineer attempts to deploy 0.0.0.0/0, the pipeline breaks, the build fails, and a Slack alert fires. Security becomes immediate code-quality assurance.

11. Custom Tooling & Scripting

Tools like ScoutSuite or Pacu are excellent, but highly monitored SOCs footprint their default user-agent strings and API call patterns immediately.

I don’t run default tools in a mature environment. I build custom Python/Boto3 scripts designed specifically to jitter and sleep between API calls. When I need to automate IAM abuse path tracking (like querying BloodHound for AWS), I write the exact programmatic logic required to ingest their specific JSON policy structures. Standard tools are for known environments; custom scripts are for surviving in hostile ones.

12. Threat Modeling (Advanced)

I sit with their architecture team. We don’t draw network diagrams; we draw Identity Graphs.

• Entry: Compromised GitHub PAT (Personal Access Token).
• Movement: PAT accesses Terraform repository -> modifies AWS IAM AssumeRole policy -> pipeline deploys changes.
• Data Access: Attacker uses modified Identity to silently replicate S3 datalake to an external AWS account using native s3 sync.

By modeling the Attacker Constraints, we realize that blocking external data replication (aws:RestrictAccessToTrustedIPs) breaks the entire final stage of the attack, neutralizing the risk entirely regardless of the initial entry point.

13. Detection vs. Evasion

Every API call I made in AWS was logged to CloudTrail. Every executed pod command in Azure was shipped to Log Analytics.

The Trade-off: Stealth versus Speed. To evade detection, I use “Living off the Cloud.” I do not generate anomalous API calls. I use aws s3 sync instead of custom Python exfiltration scripts because the SOC expects DevOps engineers to synchronize buckets. I hide in the noise of administrative telemetry. I deliberately sacrifice speed, taking three days to exfiltrate data that could have been pulled in an hour, simply to remain beneath the SIEM’s volume threshold alerts.

14. Exploitation Translating to Business Impact

Technical vulnerabilities mean nothing to a Board of Directors.

• IAM Misconfig: “A junior contractor’s compromised laptop allowed a total, unrecoverable takeover of our AWS Root Organizational structure.”
• S3 Exposure: “A single public-read misconfiguration exposed 5 million unencrypted banking transactions, triggering an immediate GDPR breach and reputational immolation.”
• Pipeline Compromise: “Because Jenkins was weak, the adversary poisoned our proprietary trading algorithm software. We inadvertently pushed malware to our own institutional clients.”

15. Risk Rating (Enterprise Level)

A vulnerability scanner calls a missing HTTP security header a “Medium.” I call it a “Low.” A vulnerability scanner calls a misconfigured IAM policy a “Medium.” I call it a “Critical.”

My risk rating requires three inputs:

1. Exploitability: Can a script kiddie do this, or does it require an expert?
2. Blast Radius: If this triggers, does one server fall, or does the entire VPC burn?
3. Data Sensitivity: Is this public marketing data or SWIFT transfer logs?

16. Remediation: The Consultant Mode

Fixing this isn’t just “Delete the open port.” My advisory encompasses structural design changes.

Prioritized Fixes:

1. Identity Boundaries First: Implement explicit aws:SourceIp conditions on all high-privileged IAM roles instantly. Even if an access key leaks, it cannot be used outside the corporate VPN.
2. Network Segmentation: Enforce strict Calico network policies in Kubernetes. Pod A should mathematically never be able to route to Pod B unless explicitly declared.
3. Secure Pipeline: Strip static credentials out of Jenkins entirely; migrate to dynamically generated, short-lived OIDC (OpenID Connect) tokens between the pipeline and the Cloud Provider.

17. Collaboration in the Real World

During the readout, an Infrastructure Manager pushes back: “Removing iam:PassRole from the GitLab runner will shatter our entire automated deployment cycle. We can’t do it.”

I don’t argue with them; I collaborate. “I agree. Let’s not remove it. Let’s restrict it strictly using iam:PermissionsBoundary. The runner can still create roles, but it can mathematically never create a role with more permissions than a standard developer.” We find the architectural compromise that secures the environment without breaking production.

18. Mentorship & Leadership

Offensive security is a team sport. During this engagement, I pair a junior tester with me. I don’t let them click buttons; I make them read the raw Terraform code. I conduct code reviews on their Python recon scripts to ensure they handle exceptions so they don’t accidentally cause infinite loops against the cloud APIs and rack up a $10,000 billing DoS attack against our client. Knowledge transfer is the true legacy of a senior operator.

19. Continuous Improvement

The true sign of organizational maturity isn’t passing a penetration test. It’s when the security team transitions from reactive panic to proactive engineering. They stop trying to play Whac-A-Mole with open ports and start engineering CI/CD guardrails that make deploying an open port structurally impossible.

20. Why Cloud Offensive Security is Different

Traditional penetration testing relies on the assumption that the network is the ultimate boundary. In the cloud, the network is merely an abstraction layer.

Cloud offensive security requires a fundamentally different psychological approach. You are not breaking into servers; you are manipulating highly complex, interconnected trust relationships. IAM is the new perimeter. Infrastructure-as-Code is the new target.

If you do not master automation, if you do not understand the intricate nuances of Cloud Service Provider API mechanics, and if you cannot translate deeply technical architectural flaws into catastrophic business risk, you cannot secure the modern enterprise.