2026-04-25 –, Track 1
What started as a Cloud Village CTF at DC33 turned into a private API for CloudShell with persistent access to free compute, networking, and storage. We’ll look at console/non-API/API barriers, automation of a non-API service, IAM obfuscation, logging/monitoring, user lock out, overcoming file/container resets, and backdoors.
The average dwell time in cloud breaches ranges from weeks to months, so persistence is key to the initial abuse as well as continued access. We explore the use of AWS CloudShell for persistence of compute, data, and access, that started with a Cloud Village CTF @ DEFCON 33 (2025) then turned into a private CloudShell API. We dive deep into the technical aspects of CloudShells that can be exploited:
- Do we really need Console access or can a private API expose CloudShell functionality for abuse?
- That dang temporal system disk…do we really need to hide things in $HOME on top of keeping the user unawares?
- Can we manipulate and use CloudShell storage directly?
- The advantages of abusing an interactive, user service that is sometimes free!
- The trifecta of actions on host: identity/access, compute, data
- What’s the biggest bang: mine, email, or attack others?
- Data exfil…who’s watching outbound network traffic?
- Grab cached credentials, ssh keys, and more
- Backdoors aka your best one-line reverse shells from you Linux beards!
- That dang container reset timeout…how can we persist beyond these?
- Persistent access of sessions beyond session revocations!
- Don’t let the user muck with things…the best way to lock a sudo user out…
We’ll then look at this from the defensive side:
- What’s the bill say!
- What can/can't be locked down
- What can/can't be detected from logs
- Whether the API, OS monitoring, root lockout can be used to flip the table on threat actors
Although the implementation is based on AWS CloudShell, we’ll also compare/contrast with Azure and GCP CloudShell, discuss defensive controls that do and don’t work, and share some open-license scripts for participants to further research the subject.
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, and has over 20 years in engineering and product roles at various security startups in vulnerability scanning, AV/AS, pen-testing/exploits, L3/4 appliances, threat intel, and windows security.
