noPac Explained: sAMAccountName Spoofing to Domain Admin (CVE-2021-42278 & 42287)

Few privilege-escalation chains are as blunt as noPac. Give it a single set of low-privileged domain credentials — a standard user account with no special rights — and it hands you a Kerberos ticket for Administrator on a domain controller. No password cracking, no relay, no waiting. Disclosed in late 2021 as the pairing of CVE-2021-42278 and CVE-2021-42287, it remains one of the most reliable full-domain compromises red teams reach for, because so many environments never fully closed the door.

The two bugs, and why they only matter together

Active Directory lets authenticated users create machine accounts. By default, ms-DS-MachineAccountQuota is set to 10, meaning any domain user can join up to ten computers — creating MACHINE$ objects they control. That default is the seed of the attack.

• CVE-2021-42278 (name validation): AD failed to enforce that a machine account's sAMAccountName must end in $. An attacker who owns a machine account can rename it to impersonate another object — specifically, to match a domain controller's name minus the trailing $.
• CVE-2021-42287 (PAC confusion): When the KDC can't find the account named in a service ticket request, it appends $ and searches again. Combined with the rename, this makes the KDC issue a ticket whose Privilege Attribute Certificate (PAC) describes the real domain controller.

The chain, step by step

1. Create a machine account (quota permitting), e.g. evilPC$.
2. Rename its sAMAccountName to match a DC — DC01 (no trailing $).
3. Request a Kerberos TGT as DC01. You get a valid TGT.
4. Rename the machine account back to something else, so DC01 no longer resolves to your object.
5. Use the TGT to request a service ticket (S4U2self) for a privileged service. The KDC can't find DC01, retries as DC01$, and stamps the PAC with the domain controller's group memberships — including Domain Admins.

The result is a service ticket you can use against the DC — for example to run a DCSync and dump every credential in the domain. Public tooling (the original noPac.py, and modules in Impacket and Rubeus) automates the whole sequence into a single command.

The frightening part is the entry cost: one ordinary user account and the default machine-account quota. There is no privileged foothold required.

Are you actually patched?

Microsoft's November 2021 updates fix the KDC behavior, but two things keep noPac alive in real fleets: DCs that never received the update, and the machine-account quota that still lets any user mint the accounts the attack needs. Patching is necessary; hardening the quota is the durable control.

Set the quota to zero and delegate machine-account creation explicitly to the teams that need it:

Set-ADDomain -Identity (Get-ADDomain).DistinguishedName `
  -Replace @{"ms-DS-MachineAccountQuota"="0"}

Then confirm no unexpected accounts were created recently, and that your DCs report the patched build:

Get-ADComputer -Filter * -Properties whenCreated, ms-DS-CreatorSID |
  Where-Object { $_.ms-DS-CreatorSID } |
  Select-Object Name, whenCreated, ms-DS-CreatorSID

Detection: what noPac leaves behind

The attack is loud if you're listening. Watch domain controller security logs for:

• Event 4741 (computer account created) from a non-admin user, followed shortly by
• Event 4781 (the name of an account changed) — the tell-tale sAMAccountName rename to and from a DC name.
• Event 4768/4769 where the requested account name equals a domain controller's hostname without the $, or where an account name flip-flops within seconds.
• A machine account requesting a TGT and then immediately performing replication (DCSync) — Event 4662 with the replication GUIDs from a non-DC principal.

The signal is the rename: legitimate machine accounts effectively never change their sAMAccountName to a DC's name and back. A single correlation rule on 4781 targeting DC-shaped names catches nearly every noPac attempt.

Where WinSentinel fits

WinSentinel's identity and Kerberos audit modules flag the preconditions that make noPac trivial, so you fix them before an attacker finds them. On any single Windows machine — free, with all 64 modules and no limits — it reports a non-zero ms-DS-MachineAccountQuota, surfaces machine accounts created by standard users, checks that Kerberos hardening (PAC validation, patch level) is in place, and reviews delegation and replication rights that turn a spoofed ticket into full DCSync.

For organizations running domain controllers and member servers at scale, WinSentinel Pro rolls those findings up across the fleet from a central node: it tells you which DCs are missing the noPac patch, alerts on drift when someone re-enables the machine-account quota, and tracks whether the 4741→4781 detection posture stays enforced everywhere — not just on the one box an engineer remembered to check. One misconfigured DC is enough for domain compromise, so posture has to be measured everywhere at once.

The takeaway

noPac isn't exotic. It's the predictable result of two defaults — patch lag and an open machine-account quota — meeting two Kerberos bugs. Patch your DCs, set the quota to zero, alert on machine-account renames, and audit continuously so the fix doesn't quietly regress. A domain-admin ticket should cost an attacker far more than one stolen standard-user password.