Cloud Security¶

Weaponizing AWS MWAA's Default Execution Role: Full C2 Over Airflow Workers Via SQS

TL;DR

AWS Managed Workflows for Apache Airflow (MWAA) ships with a mandatory IAM policy that grants the execution role sqs:SendMessage and sqs:ReceiveMessage to arn:aws:sqs:*:*:airflow-celery-* — any queue, in any AWS account, matching that prefix. This is not a misconfiguration; it's the documented default required for the service to function. Tightening it breaks MWAA.

We built CeleryStrike, a tool that exploits this policy to establish a full command-and-control channel over Airflow workers. A single DAG upload gives an attacker an interactive implant with credential harvesting, cross-account recon, event injection, and arbitrary command execution — all tunneled through SQS queues that are indistinguishable from legitimate Celery traffic.

This post walks through a live engagement against a real MWAA environment, from initial deployment to full credential harvest.

Breaking Out of GCP Cloud Workstations: Docker Socket = Game Over

During a recent pentest against a GCP-heavy environment, I landed inside a Cloud Workstation. Pretty locked down at first glance — I was a regular user (no root), the docker CLI wasn't installed, and network restrictions blocked me from installing anything with apt or pip. The client thought they'd hardened it.

Within about 10 minutes, I had a root shell on the underlying Compute Engine VM and was holding the project's service account token. None of those "hardening" measures mattered.

The whole thing felt too easy, so I dug deeper. Turns out, every single predefined Cloud Workstation image Google ships is vulnerable to this.

Kill the Keys: Building a SageMaker Vending Machine to Stop Lateral Movement

In my last post, we talked about how SageMaker Presigned URLs are effectively "Golden Tickets" to your ML environment. We established that giving users direct IAM permission to generate these tickets (sagemaker:CreatePresigned*) is a recipe for disaster—specifically, lateral movement disaster.

The Golden Ticket: Why SageMaker Presigned URLs are Your New Favorite Pivot Point

Let’s be real: usually, when we talk about cloud security, we’re talking about S3 buckets left open to the world or over-permissive IAM roles attached to EC2 instances. But while everyone is watching the front door, the Data Science team is building a massive side entrance with Amazon SageMaker.

I’ve been deep-diving into SageMaker security assessments lately, specifically looking at how we access these environments. The verdict? SageMaker Presigned URLs are the "Golden Tickets" of the AWS ecosystem.

If you are a pentester or a Cloud Sec engineer, you need to understand how these URLs work because they are effectively bearer tokens that bypass your IDP, your MFA, and potentially your sanity.

AWS IAM Policy Types → Threat Models Mapping

A policy-to-threat-model mapping table showing exactly which IAM policy types mitigate which attack classes, why they matter, and what they do not protect against.

This is the reference table cloud security engineers, auditors, and pentesters use when analyzing IAM blast radius and privilege escalation paths.

Cloud Red Team TTPs: Operationalizing AWS Console Credential Extraction

For years, one of my go-to TTPs during red team engagements has been bridging the gap between AWS Console access and the CLI. We've all been there: you land on a compromised workstation, or you're stuck in a restrictive VDI environment. You have access to the AWS Console via the browser, but you're handcuffed. You can't run scripts, you can't use tools like Pacu, and you can't mass-enumerate resources efficiently.

I knew the credentials had to be somewhere. AWS doesn't use magic; the browser has to authenticate API calls somehow.