2026¶

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.