Account or group outside Tier Zero can log on to domain controllers
Accounts outside Tier Zero can open a remote session on domain controllers, one privilege escalation away from the whole domain.
- Category
- Hygiene
- Severity
- High; Critical for broad groups.
- Typical owner
- AD / identity team
- Data needed
- Local group data for the domain controllers, from SharpHound or the built-in collector* with
--user --scope all.
On this page
In plain language
A domain controller holds every password hash in the domain. Ordinary accounts should never be able to sign in to one. When they can (through Remote Desktop, PowerShell remoting or DCOM), the attacker who compromises them lands on the most sensitive server in the company and needs only one local privilege escalation to take everything.
On domain controllers these rights come from the domain's built-in groups, which every DC shares, so one change fixes all of them. Pathwarden doesn't draw this as a full attack path (a session isn't control), but treats it as a serious weakness.
What Pathwarden flags
A user, computer or group outside Tier Zero can open a session on domain controllers through Remote Desktop, PowerShell remoting (WinRM) or DCOM. On a domain controller these rights do not come from a local group, because DCs have no local accounts database. They come from the domain's built-in groups: Remote Desktop Users (S-1-5-32-555), Remote Management Users (S-1-5-32-580) and Distributed COM Users (S-1-5-32-562). These groups are shared by every DC in the domain. A GPO linked to the Domain Controllers OU can also grant them.
Pathwarden does not draw this as an attack path: a session alone is not control of the domain. It is one step from it, though.
How attackers use it
A logon on a DC puts an attacker's code on the most sensitive server in the domain. One local privilege escalation (an unpatched driver, a misconfigured service, a token impersonation bug) turns it into SYSTEM on the DC, which means the NTDS.dit database, every password hash and the krbtgt key (OS Credential Dumping: NTDS, T1003.003). It also lets the attacker read whatever the DC exposes to logged-on users: scripts, shares and memory left by other sessions.
Find it with Pathwarden
Data needed: Local group data for the domain controllers, from SharpHound or the built-in collector* with --user --scope all.
In the web UI or the HTML report, open the Findings tab and expand PW-023: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-023
# the step-by-step guide on this page, offline
pathwarden guide PW-023
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-023Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Find out who uses the access and why. Helpdesk and monitoring teams are often given RDP to DCs "temporarily", and some monitoring agents use WinRM.
- Monitoring and management tools that need WinRM on DCs should use a dedicated, tightly scoped account, ideally in Tier Zero and managed as such, or a pull model that needs no inbound logon.
- Check whether the right comes from group membership (most common) or from a GPO user right on the Domain Controllers OU; the finding's fix lists both.
How to fix it
Option A: Empty the built-in groups (recommended)
- In Active Directory Users and Computers, open the Builtin container of the domain.
- Open Remote Desktop Users, Remote Management Users and Distributed COM Users, and remove the account or group from the finding (and anything else that is not Tier Zero).
- Leave Domain Admins and other Tier Zero administrators as they are: they can already log on to DCs through Administrators.
Option B: Remove GPO-granted logon rights
- In Group Policy Management, review every GPO linked to the Domain Controllers OU (usually only the Default Domain Controllers Policy).
- Under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment, check Allow log on through Remote Desktop Services and Access this computer from the network, and remove the account or group from both.
PowerShell
Import-Module ActiveDirectory
# Who is in the built-in remote access groups?
'Remote Desktop Users', 'Remote Management Users', 'Distributed COM Users' |
ForEach-Object { Get-ADGroupMember -Identity $_ -Recursive | Select-Object @{ n = 'Group'; e = { $_ } }, Name, objectClass }
# Remove the account or group from the finding
Remove-ADGroupMember -Identity 'Remote Desktop Users' -Members '<Account>' -Confirm:$falseVerify the fix
A Remote Desktop or Enter-PSSession attempt by the account to a listed DC
must be refused. Collect again (or use Retest on the finding) and confirm the finding ID is gone.
Roll back
Add the account or group back with
Add-ADGroupMember -Identity '<Group>' -Members '<Account>', or restore the
user right in the GPO and run gpupdate /force on the domain controllers.
References
- Microsoft: Implementing least-privilege administrative modelslearn.microsoft.com
- Microsoft: Active Directory security groupslearn.microsoft.com
- SpecterOps BloodHound docs: CanRDPbloodhound.specterops.io
- SpecterOps BloodHound docs: CanPSRemotebloodhound.specterops.io
- MITRE ATT&CK T1003.003: OS Credential Dumping: NTDSattack.mitre.org
- MITRE ATT&CK T1021.001: Remote Services: Remote Desktop Protocolattack.mitre.org
- MITRE ATT&CK T1021.006: Remote Services: Windows Remote Managementattack.mitre.org
- MITRE ATT&CK T1021.003: Remote Services: Distributed Component Object Modelattack.mitre.org
Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.