AI
The CTF Genesis: Why Cloud Shell Became the Target
The talk started with a CTF built for Cloud Village at Defcon. The idea: hide the flag in a cloud shell environment because no API call can reach it. Cloud shells are unmanaged compute environments aimed at admin use, not wrapped by any API. Jenko Hwong described the genesis as a “screw you attitude” to force participants out of their tooling. The challenge had three cloud provider headquarters. Entry was a website with an IDOR vulnerability to warm up participants. The real path required exploiting an SSRF in a search form to reach the AWS Instance Metadata Service.
Pivoting from API to Browser: The Federated URL Trick
Chris Ryan demonstrated the pivot from API tokens to browser-based cloud shell. After dumping temporary credentials via the SSRF, he used a script to generate a federated sign-in URL. That URL opened the AWS console in the browser, where cloud shell was accessible. Jenko noted the insecurity: stealing an API token normally does not grant console access, but the federated SSO model leaks that ability. The script used the stolen credentials to assume a role and produce a console session URL. This step moved the attacker from API land into the browser-based cloud shell environment.
The Hunt: Finding the Flag in Cloud Shell
Once inside cloud shell, Chris had a full Linux environment but no root access. Jenko had removed sudo and locked down the home directory. The only persistent location in cloud shell is the home directory; containers reset every 12 hours. Hidden in .bashrc files was a reference to a netcat binary and a listener on port 1024. The script monitored /tmp for file creation. When Chris created a temp file, the backdoor fired and sent the flag to his listener. The flag revealed a next-step hint pointing toward Azure, completing one leg of the multi-cloud challenge.
Real-World Red: Reverse Shells and Websocket Attacks
Chris switched to a red team scenario. Using the cloud shell environment, he launched a reverse shell to a Digital Ocean listener, gaining OS-level control. He then demonstrated a more advanced attack: by reversing the cloud shell websocket protocol, he connected to the same environment from a Python script outside the browser. This bypassed the browser altogether and gave him an interactive shell that survived API token revocation. He also pointed out the built-in upload feature uses a curl command, which an attacker can abuse to transfer malware. Finally, he abused the role session name parameter in AssumeRole calls to spawn separate cloud shell containers per session name, potentially creating hundreds of persistent environments across all 17 AWS regions.
Blue Team Countermeasures: Detection and Remediation
Jenko outlined three defense options: ban cloud shell entirely, harden it via API provisioning, or replace it with an API-enabled compute service like SSM or ECS. He showed how to enumerate cloud shell usage per region and per identity through undocumented APIs. Logging captures session start, upload, and download events but not individual commands. Detection signals include session bursts, beaconing every minute to keep the idle timeout alive, and long-running sessions that hit the 12-hour reset limit. The nuclear option is the delete-user API call, which destroys the home directory where persistence hooks reside. However, the role session name trick complicates cleanup because each session creates a separate home directory the blue team may not know exists.
The Multi-Cloud Picture and Ongoing Research
Chris and Jenko noted that Azure and GCP have similar cloud shell environments, all Linux-based with websocket protocol. Most troubling: a free Gmail account can access GCP cloud shell with no explicit permission grant. They are releasing a tool called “cloud-shell-runner” as a work-in-progress, but held back full disclosure to avoid arming threat actors before defenders get solid countermeasures. They urged attendees to think about the net security impact of such research and to approach them directly for details.
Notable Quotes
we got to describe how packed the theater is. Standing room only. We got about 300 people in the AMC Jenko Hwong · ▶ Watch (0:23)
the dirty secret AWS has but it attaches this timebased thing saying any tokens for API access created before 2 seconds ago which is what you had before earlier in this presentation should fail Jenko Hwong · ▶ Watch (30:11)
Think about that model. Most people try to be deny you have no privileges till I explicitly grant you. That’s the complete opposite. Jenko Hwong · ▶ Watch (43:53)
I just don’t want um the bots of the day to come in, suck this up, throw it in, and suddenly someone some script kitty is using this to launch some attacks. Jenko Hwong · ▶ Watch (45:59)
Key Takeaways
- Cloud shell environments are unmanaged, API-less compute that provide persistent OS-level access across all major cloud providers.
- Attackers can pivot from API tokens to browser console via federated URLs and abuse websocket protocols for stealthy reverse shells.
- Blue teams can detect cloud shell abuse through session logging, beaconing patterns, and use the delete-user API to destroy attacker persistence.
About the Speakers
Jenko Hwong is a Principal Security Researcher at Huntress Labs, focusing on identity-based attacks and abuse. Prior to Huntress, he spent 6 years at Netskope Threat Labs, speaks regularly at RSA and DEFCON, and is a Cloud Village CTF Lead. He has over 20 years in engineering and security.
Chris Ryan is a Principal Security Researcher at Huntress Labs. A series of oddly configured server banners, a JARM fingerprint, curious fields in a security certificate – these aren’t just technical details, but are instead threads in a narrative tapestry woven like a John le Carre novel. For over 20 years, Chris has dedicated his life to studying adversary tradecraft and cloud abuse.