Heist · windows · ad · – views
Heist: a gMSA read all the way to SYSTEM
This was one of my favourite Windows boxes from my prep. Nothing here is a crazy exploit, it's a chain of small, normal-looking Active Directory settings that add up to full control. Get a hash off the wire, crack it, read a service account's password because I'm allowed to, then abuse one privilege to become SYSTEM. Each step is boring on its own. Together they own the domain controller.
Getting a foothold
I started with a listener on the network using Responder. When a Windows machine tries to resolve a name it can't find, it falls back to broadcast protocols, and anything listening can answer. Responder answers, the machine tries to authenticate to me, and I catch its NetNTLM hash. That's not the password, it's the challenge-response, so I ran it through hashcat with rockyou and it cracked.
With a username and password in hand, I logged in over WinRM. That gave me a normal user shell on the box. Foothold done.
Finding the way up
Next question on any Windows box: what can this user actually do? I ran
BloodHound to map the domain, and it drew the answer for me. My user was a
member of a group, and that group had a ReadGMSAPassword edge
pointing at a service account.
enox ──MemberOf──▶ WEB ADMINS ──ReadGMSAPassword──▶ svc_apache$
A gMSA (group managed service account) is one where Windows manages the password for you and rotates it automatically. The catch is that any account allowed to read it can pull the current password out of the directory. My group was on that allowed list. So I read the service account's hash straight out of AD, no cracking needed.
Pass the hash
I didn't have the service account's plaintext password, just its NT hash.
That's fine. NTLM lets you authenticate with the hash directly, so I passed
it and logged in as the service account. Now I was svc_apache$,
a more privileged account than the one I started with.
SeRestore to SYSTEM
Checking the service account's privileges, it held SeRestore.
That privilege lets you write files anywhere on the system, including places
a normal user can't touch. There's a well-known trick with it: the
accessibility button on the Windows login screen runs
utilman.exe as SYSTEM. If you can overwrite utilman.exe
with cmd.exe, then clicking that button at the login screen gives
you a SYSTEM shell.
SeRestore gave me exactly the write access to do that. I swapped
utilman.exe for a command prompt, triggered it from the lock
screen, and got a shell running as nt authority\system. Full
control of the domain controller.
The chain, in one line
Responder catches a hash, hashcat cracks it, WinRM gets a shell, ReadGMSAPassword hands over the service account, pass-the-hash logs in as it, and SeRestore turns a file write into SYSTEM.
What I took from it
This box is a good reminder that Windows privilege escalation is usually not about finding a memory bug. It's about noticing what an account is quietly allowed to do. A group membership, a "read this password" permission, one dangerous privilege. Each is a setting someone chose on purpose. My job was just to line them up. When I test AD now, the first thing I do is exactly this: map who can do what, and look for the short path from where I am to where I want to be.