Cloud Offensive Security & DevSecOps: Attacking the Control Plane

When traditional penetration testers move into cloud environments, they often make one critical mistake: they still hunt for IP addresses. But in AWS, Azure, or GCP, IP addresses are temporary. Virtual machines spin up and down like containers. The old-school network perimeter simply doesn’t exist anymore.

In the cloud, identity is your real boundary. Control the API, and you control the infrastructure.

This is a real After-Action Report from a multi-cloud red team engagement against a major financial institution—one that was heavily defended and compliance-focused. Rather than walking through a toolkit, this is a walkthrough of how modern attackers actually think: how they get in, move laterally, abuse identity systems, and ultimately gain complete control.

1. Entry Strategy: Thinking Like a Cloud Attacker

We start with an initial foothold: low-privileged AWS Access Keys from a junior developer. My first instinct? Don’t run Nmap. Don’t scan the VPC. Those tools belong in traditional network testing, not here.

Instead, I answer three critical questions: Who am I? What can I assume? Where are the secrets?

This is where traditional penetration testing breaks down. Most attackers target the workload—the web application, the server. Cloud attackers target the infrastructure itself—the AWS and Azure APIs. Compromising a single server gets you access to one machine. Compromising an overly permissive IAM policy? You just gained control of the entire cloud environment.

2. IAM Enumeration: Mapping Your Real Permissions

First, I check what user this key actually represents using aws sts get-caller-identity. The response shows arn:aws:iam::123456789012:user/dev-jdoe. Now I know exactly who I am on the AWS side.

The critical move here isn’t asking “What can I do?” It’s asking “What can I become?” I pull all inline and attached policies and look for privilege escalation paths. I’m hunting for specific permissions that chain together: iam:PassRole, iam:CreatePolicyVersion, or sts:AssumeRole.

Here’s the thinking: I don’t need Admin access right now. I just need one thing—the ability to attach a policy to an EC2 instance profile. Then I can pass a highly privileged role to an instance I create. That’s the chain.

3. Reconnaissance: Mapping the Cloud Landscape

Now I quietly map out the environment using the AWS CLI and custom Boto3 scripts. I’m careful to avoid triggering GuardDuty’s anomaly detection.

What I’m looking for:

• IAM Roles: Trust relationships across the entire AWS organization.
• S3 Buckets: Terraform state files (.tfstate files often contain infrastructure secrets).
• Compute: EC2 instances and their attached roles.
• Serverless: Lambda function environment variables—these often contain credentials.

Notice I’m not running vulnerability scanners. I’m not looking for software bugs. I’m mapping logical architecture and configuration mistakes. Most threat scanning tools miss these completely because they’re looking for known vulnerabilities, not fundamental design flaws.

4. The Turning Point: Choosing Your Target

Within 20 minutes, recon reveals three potential attack paths:

1. s3://finance-backup-assets allows any authenticated AWS user to read objects.
2. arn:aws:iam::role/Lambda-Execution-Role has an overly permissive trust policy.
3. An internal API Gateway is missing AWS WAF protection.

The decision: Target the S3 bucket, ignore the rest.

Why? The API Gateway would require fuzzing and testing—noisy activity that gets logged heavily. The Lambda role requires building assumption chains—again, loud in CloudTrail. But a misconfigured S3 bucket in a DevOps environment? It almost always contains Terraform state files. Those .tfstate files are silent to read and contain the complete blueprint of the infrastructure, including hardcoded secrets for the CI/CD pipeline.

5. Privilege Escalation: Building the Attack Chain

Inside the Terraform state file, I find something valuable: a GitLab Runner access token. This gives me access to their CI/CD system.

I check what that GitLab Runner can do in AWS. It has the role arn:aws:iam::role/gitlab-deployment-runner—which makes sense, since it’s designed to deploy infrastructure changes. This role has permissions to ec2:RunInstances and iam:PassRole.

Here’s the chain:

1. I trigger a rogue pipeline job in GitLab.
2. That job spins up a new EC2 instance using ec2:RunInstances.
3. When launching it, I attach the arn:aws:iam::role/Prod-Database-Admin role using iam:PassRole.
4. Once the instance is running, I pull temporary credentials from its metadata service at http://169.254.169.254/latest/meta-data/iam/security-credentials/Prod-Database-Admin.

I’ve now escalated from a junior developer to production database admin—without running any exploit code. It’s all legitimate AWS API calls, just chained maliciously.

6. Network Exploitation: An Open Door

With my new admin-level role, I now look at the network layer. I find an open security group on port 6379—that’s Redis—allowing traffic from 0.0.0.0/0 to an ElastiCache cluster. This port was probably opened temporarily during troubleshooting and never closed.

Combined with my new high-privileged identity, this is a complete win. The Redis instance has no authentication configured inside the VPC, so I can read everything. I dump the cached JWT session tokens for active banking customers.

7. Kubernetes Compromise: Lateral Movement to Containers

The bank runs a large Azure Kubernetes Service (AKS) cluster. I find a pod running a custom reporting application with a command injection vulnerability. I get a shell inside the container.

At this point, a traditional penetration tester would look for kernel exploits or unpatched system services. I’m looking for something different: the Kubernetes service account token at run/secrets/kubernetes.io/serviceaccount/token.

The developer made a critical mistake: the pod’s ServiceAccount was assigned cluster-admin privileges. With that token, I query the Kubernetes API:

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

This dumps every TLS certificate, database password, and API key from the entire cluster. This is why containerized environments are so dangerous—a single compromised microservice can inherit the identity and permissions of the entire platform.

8. Serverless Exploitation: Lambda Functions

Back in the AWS environment, I find a Lambda function exposed via API Gateway at /process-ledger. The function parses user input and evaluates it as Python code using eval().

I craft a malicious JSON payload to execute arbitrary code. Once inside the Lambda environment, I check the environment variables—this is where Lambda stores its IAM execution credentials.

I’ve now compromised the Lambda execution role, which has direct access to the DynamoDB tables behind it. This is a critical point: serverless functions may seem ephemeral, but they’re still code executing somewhere, and they still have identity and credentials.

9. CI/CD Pipeline Compromise: The Supply Chain Attack

Attacking the CI/CD pipeline is the most effective cloud attack. Compromising production gives you access once. Compromising the pipeline gives you permanent access to everything the pipeline touches.

The developers stored infrastructure secrets in Jenkins environment variables instead of a proper secrets management tool like Vault. I exploited a vulnerability in one of Jenkins’ plugins to compromise a worker node and dumped the memory.

I extracted the master deployment keys. Now I don’t need to exploit their cloud directly anymore. I can simply commit malicious code to their main repository, and the trusted pipeline will automatically deploy my backdoor to production. The organization’s own security infrastructure becomes your delivery mechanism.

10. Defense: Shifting Left with Continuous Scanning

Once I’ve shown how the attacks work, the conversation shifts to defense. Traditional vulnerability management—running Nessus scans once a week—doesn’t work in the cloud. Infrastructure changes in minutes. Those weekly scans are obsolete before they run.

The fix is to catch problems before they’re deployed. Tools like Trivy and Checkov should run on every code commit, scanning Terraform for overly permissive IAM policies before they’re applied. When an engineer tries to deploy open security groups or excessive permissions, the pipeline should fail immediately and alert the team via Slack. Security becomes part of the code review process, not a separate after-the-fact check.

11. Custom Tooling: Evading Detection

Tools like ScoutSuite and Pacu are useful, but mature SOCs recognize their default signatures immediately. When running automated scanning against a well-defended environment, I write custom Python and Boto3 scripts instead.

These scripts deliberately add delays and random jitter between API calls to avoid triggering rate-limit alerts. When I need to map IAM privilege escalation paths, I write custom logic tailored to how that specific organization structures their policies. The goal is to stay invisible—standard tools leave footprints that detection teams expect.

12. Threat Modeling: Building Identity Graphs

Rather than drawing traditional network diagrams, effective cloud defense requires mapping identity flows. Here’s a real attack scenario:

Attack Chain:

1. Attacker compromises a GitHub Personal Access Token (PAT).
2. That PAT gains access to the Terraform repository.
3. The attacker modifies the IAM AssumeRole policy.
4. The pipeline automatically deploys those changes to production.
5. The attacker uses the new identity to silently copy sensitive S3 data to an external account.

The Defense: By restricting outbound data replication based on IP address (aws:RestrictAccessToTrustedIPs), you break the final exfiltration step. Even if the attacker compromises the identity layer, they can’t actually move the data out. This single control neutralizes the entire attack regardless of where the initial breach happens.

13. Detection vs. Evasion: The Speed-Stealth Tradeoff

Every API call in AWS is logged to CloudTrail. Every command in Azure containers is logged to Log Analytics. But the key is: most organizations aren’t actively monitoring all of it.

To evade detection, I use legitimate tools and normal workflows—a practice called “Living off the Cloud.” Instead of writing custom exfiltration scripts (which look suspicious), I use aws s3 sync, which is exactly what DevOps engineers do every day. I deliberately hide my activity in normal administrative traffic.

This requires patience. I might take three days to exfiltrate data that could be stolen in an hour. But the slower approach keeps me invisible to SIEM threshold alerts and volume-based anomaly detection.

14. Turning Technical Risks into Business Language

When presenting findings to the board, technical jargon doesn’t land. You need to translate into business impact:

• IAM Misconfiguration: “A contractor’s compromised credentials allowed complete takeover of the entire AWS organizational root account.”
• Exposed S3 Bucket: “A single misconfigured bucket exposed 5 million unencrypted banking transactions, violating GDPR and causing severe reputational damage.”
• Pipeline Compromise: “An attacker could inject malicious code into our proprietary trading algorithms, causing us to automatically distribute malware to our clients.”

These stories resonate because they connect directly to revenue, legal liability, and brand damage.

15. Risk Assessment: Beyond CVSS Scores

Automated scanners often get cloud risks wrong. A missing HTTP security header gets marked “Medium.” I’d call it “Low.” But a misconfigured IAM policy that automated tools also mark “Medium”? That’s “Critical.”

Proper cloud risk assessment requires three dimensions:

1. Exploitability: Does this require expertise or can a beginner exploit it?
2. Blast Radius: If compromised, does one server get affected or the entire cloud environment?
3. Data Sensitivity: What’s actually at risk—public marketing materials or customer financial records?

16. Remediation: Strategic Fixes

Fixing cloud security isn’t about patching one vulnerability. It’s about architectural redesign.

Top priorities:

1. Identity Boundaries: Add aws:SourceIp conditions to all high-privilege IAM roles. Even if credentials leak, they can’t be used from outside the corporate network.
2. Network Isolation: Deploy strict network policies in Kubernetes so pods can’t talk to each other unless explicitly allowed.
3. Pipeline Secrets: Remove hardcoded credentials from Jenkins. Use short-lived OIDC tokens that the pipeline obtains dynamically from your cloud provider.

17. Practical Collaboration: Finding Real Solutions

At the debrief, the infrastructure team resists: “We can’t remove iam:PassRole from GitLab—our entire deployment process depends on it.”

The right response isn’t to argue; it’s to collaborate. “You’re right. Instead of removing it, let’s add iam:PermissionsBoundary. The runner can still create roles, but it can never create roles with more permissions than a standard developer.” This approach keeps deployments working while preventing privilege escalation.

18. Mentorship: Building Better Security Teams

Offensive security requires teams, not individual operators. During this engagement, I pair junior testers with experienced ones. Rather than letting them run automated tools, I have them read raw Terraform code and understand how it maps to security risks.

When they write Python reconnaissance scripts, we review them together to make sure they include proper error handling and API rate limiting. Careless reconnaissance scripts can accidentally trigger massive API charges or set off alarms. The knowledge transfer—understanding not just the tools but the reasoning—is what creates stronger security teams.

19. Long-Term Security: From Reactive to Proactive

The mark of a mature security organization isn’t passing one penetration test. It’s building systems that prevent the same mistakes from happening again. Rather than responding to each discovered vulnerability individually, teams should engineer controls into their deployment pipeline. If the pipeline won’t let you deploy an open security group, the problem is solved permanently.

20. The Fundamental Difference: Cloud vs. Traditional Security

Traditional penetration testing is built on the idea that the network is your boundary. Defend the perimeter, and you’re safe. In the cloud, the network is just an abstraction layer running in someone else’s data center.

Cloud security requires a different mindset entirely. You’re not attacking servers; you’re manipulating identity and trust relationships. Your real targets are IAM policies and Infrastructure-as-Code files, not firewalls and ports.

To protect modern cloud infrastructure, you need to understand API mechanics deeply. You need to automate defenses at scale. And most importantly, you need to translate technical vulnerabilities into language executives understand—business risk, regulatory liability, and reputational damage. That’s what separates cloud-native security from outdated approaches.