Windows and AD Concepts Through Pirate

This page explains mechanisms that appear in the Pirate writeup. Read the writeup to follow the attack sequence, or this page to understand the roles of Responder, RBCD, and other components.

What is Responder?

Responder is a tool that listens for queries when Windows falls back to other name resolution methods. It responds to LLMNR, NBT-NS, mDNS, and WPAD queries to induce NTLM authentication over SMB or HTTP.

A typical sequence is:

Windows host -> Name resolution fails
Windows host -> Queries nearby systems via LLMNR/NBT-NS
Responder -> Claims that name belongs to it
Windows host -> Connects over SMB/HTTP or another protocol
Responder -> Captures the NTLM challenge/response

For this to work, the target must be able to reach the listening address. In environments such as HTB where traffic passes through routing or a pivot, check the return path in particular.

In Pirate, the successful path did not capture a hash with Responder. Instead, WEB01$ connected back to the SMB listener in ntlmrelayx, which relayed the authentication to LDAPS.

What does Coercer do?

Coercer uses Windows RPC interfaces to trigger outbound authentication from a target. By making the target access a UNC path, it sends the computer account’s NTLM authentication to a listener.

The sequence in this case was:

attacker -> Coercer -> Calls an RPC endpoint on WEB01
WEB01 -> Tries to access \\<listener>\share\file.txt
WEB01 -> Authenticates to the listener via NTLM as WEB01$
ntlmrelayx -> Relays that NTLM authentication to LDAPS/DC01

Coercer’s ERROR_BAD_NETPATH or NO_AUTH_RECEIVED may look like failures for individual methods even when another method triggers authentication. The accurate final check is whether ntlmrelayx reports PIRATE/WEB01$ ... SUCCEED.

Where ntlmrelayx relays authentication

ntlmrelayx listens for SMB or HTTP connections on the attacker’s side and relays the received NTLM authentication to another service.

The successful sequence here was:

WEB01$ --SMB NTLM--> attacker:445 / ntlmrelayx
ntlmrelayx --relays NTLM--> ldaps://DC01
DC01 LDAP modify -> Add MS01$ to WEB01$'s RBCD

coercer -l sets the address that WEB01 calls back to. If it points to an old VPN IP or an IP that WEB01 cannot reach, Coercer can call an RPC method but ntlmrelayx receives nothing.

HTTP/WebDAV relay depends on the WebClient service and firewall settings. In Pirate, the HTTP callback failed; directing the SMB callback to the attacker’s VPN IP succeeded.

Why MS01$ mattered

MS01$ was more than just a computer account; several important signals came together:

• Membership in Domain Secure Servers
• Domain Secure Servers can read the gMSA password
• MS01$ is a pre-created computer account
• The initial password pattern for MS01$ is ms01

Therefore, obtaining MS01$:ms01 allows the gMSA password to be read. After the relay, MS01$ could also serve as the delegating account for RBCD, making it the pivot account for the entire attack path.

What the RBCD success message means

The message means that MS01$ was added to WEB01$‘s msDS-AllowedToActOnBehalfOfOtherIdentity.

In simplified terms:

WEB01$:
  "MS01$ may obtain a service ticket for WEB01 on behalf of any user"

In Kerberos, impersonate here is closer to “act on behalf of a user” than to simply “pretend to be someone.” MS01$ acted on behalf of Administrator and obtained a service ticket for cifs/WEB01.pirate.htb.

The S4U operations have these roles:

• S4U2self: A service account obtains a service ticket to itself for any user.
• S4U2Proxy: It uses that user context to obtain a ticket for another service.

With RBCD, the target machine’s allowlist controls where S4U2Proxy may delegate.

From WriteSPN to changing an SPN

WriteSPN is permission to change the servicePrincipalName attribute. A common use is targeted Kerberoasting: adding an arbitrary SPN to a user and Kerberoasting it.

Pirate used it in a more powerful way.

a.white_adm can perform KCD to HTTP/WEB01
IT has WriteSPN on WEB01$ and DC01$
Move HTTP/WEB01 from WEB01$ to DC01$
KDC resolves HTTP/WEB01 as an SPN of DC01$
a.white_adm's KCD effectively points to DC01

This is SPN-jacking. The service name remains WEB01, but ownership of the SPN changes to DC01$, so a ticket that DC01 can decrypt can be obtained.

Why ldapmodify was chosen

SPN-jacking requires changing the servicePrincipalName attribute of an AD object. An LDAP modify operation can do this.

The reasons for using ldapmodify were:

• It can specify delete and add explicitly.
• It can move only the necessary value instead of replacing the entire servicePrincipalName attribute.
• An LDIF provides a record of what was changed.
• It is easy to prepare an LDIF to restore the SPN.

bloodyAD set object can also change attributes, but its implementation replaces the entire attribute. To avoid breaking existing SPNs, the current values must be recorded and replaced with the complete list.

hashcat rules

A hashcat rule transforms each candidate in a wordlist. For example, it can generate many variations like these:

password -> Password
password -> password1
password -> password!
summer   -> Summer2026!

best64.rule is a well-known small rule set from John the Ripper. When hashcat uses John rules, it may skip lines containing unsupported rules. In Pirate, a Kerberoast hash was obtained, but rockyou and the rules did not crack a.white_adm’s password.

Muffin was shown as candidate generation progress, not as a cracked password. Use hashcat --show to confirm whether the password was cracked.