Five paths to Domain Admin that still work

Active Directory is a flat structure of trust: whoever takes over one badly configured element can get all the way to the top and from there set ransomware loose across the domain. Escalation to Domain Admin needs no zero-day. A combination of settings is enough: each one looks harmless on its own, and they have been piling up in the domain for years.

The five paths below have two things in common. They work from the position of an ordinary domain user, meaning from anywhere once the first identity has been taken, and they need no hole in Windows itself. Default or convenient settings that nobody has changed are enough for them. Phishing is not the only route to that first identity either: Wi-Fi is a way into the internal network from the area around the building. Whether anyone in the company notices is another question, and we cover it separately under how the same thing behaves in a covert operation.

Kerberoasting takes advantage of the fact that any signed-in user can request a Kerberos service ticket (TGS) for an account with an SPN. The ticket is encrypted with the hash of that service account’s password, so the attacker carries it off and cracks it offline. Nothing that anyone could catch ever runs against the domain.

The targets are service accounts with a manually set password. Rotation gets postponed for them, because changing the password brings down the service that uses it, so the password ages and stays weak. When such an account belongs to a group with high privileges, cracking it ends the game. Worse still is encryption running on RC4, which cracks substantially faster than AES.

• Move service accounts to gMSA, or give them a random password of 25 characters or more that can’t be cracked.
• Enforce AES and turn off RC4 where the environment can take it.
• Take service accounts out of privileged groups. A service account has no business in Domain Admins.
• Watch event 4769 with encryption type 0x17 (RC4-HMAC) and an unusual volume of ticket requests.

AS-REP roasting aims at accounts that have Kerberos pre-authentication turned off. For those, anyone can pull out the part of the response encrypted with the account password and crack it offline. The principle is the same as with Kerberoasting, except that not even a valid account is needed.

The DONT_REQ_PREAUTH flag shows up on old accounts and integrations where someone once turned it on for compatibility and forgot. One such account with a weak password is enough, and the attacker has the first identity in the domain for free.

• Search the domain for accounts with the DONT_REQ_PREAUTH flag and turn pre-authentication back on wherever you can.
• Give the accounts that genuinely need the flag a long random password and keep an eye on them.
• Audit event 4768 with Pre-Authentication Type 0, that is, a sign-in without pre-authentication.

NTLM relay doesn’t abuse the password but the authentication itself: the attacker forces the victim to authenticate to them and forwards that authentication in real time to another service, where it passes for the victim. When the target is LDAP or the web enrollment of certificates in AD CS, a domain identity can be escalated quickly.

Authentication can be forced with a range of tricks, from a spoofed SMB path to making a server sign in on its own. If the authentication received has no enforced signing or channel binding, the relay goes through. By forwarding it to AD CS, the attacker has a certificate issued for someone else’s account and signs in as them.

• Enforce SMB signing and LDAP signing plus LDAP channel binding.
• On the AD CS web enrollment, turn on Extended Protection for Authentication and turn off HTTP.
• Restrict or turn off NTLM where nothing needs it anymore.
• Narrow access to the interfaces through which authentication can be forced, so not everyone on the network can abuse them.

ESC1 is a misconfigured certificate template in Active Directory Certificate Services where the requester may set whom the certificate is issued to, while the template allows sign-in (Client Authentication). An ordinary user has a certificate issued in the name of a Domain Admin account and signs in as that account.

Exploiting it takes three settings at once: a template with the “subject supplied by the requester” flag, an EKU for sign-in, and enroll rights for a broad group of users. The certificate is valid for months on top of that, even after the victim changes their password, which makes it convenient persistence as well.

• On templates with Client Authentication, turn off “subject supplied by the requester” (ENROLLEE_SUPPLIES_SUBJECT).
• Turn on manager approval where the requester has to set the subject.
• Restrict enroll rights to the groups that need them, not to Domain Users.
• Audit the templates and permissions with Certify or PSPKIAudit, and go through them regularly.

Group Policy Preferences once let you set a password through a GPO and store it in XML in SYSVOL. It was encrypted with a key Microsoft published itself. Every domain user may read that directory, so such a password is public in practice and can be decrypted in seconds.

The MS14-025 update from May 2014 removed the option of handing out passwords through these GPP extensions, but old XML files with leftovers of the cpassword attribute stay in SYSVOL. Microsoft writes it straight into the bulletin: the update does not remove existing GPOs. When such a password is there and still in use, or matches an account with higher privileges, that is a ready-made way onward.

• Search SYSVOL for the string cpassword and delete every XML file you find.
• Change every password that was ever handed out through GPP.
• Don’t hand out passwords through GPO; use Windows LAPS for the local administrator password.
• Go through the other places in SYSVOL where scripts and GPOs tend to keep passwords in plaintext: logon scripts, drive mappings.