noPac: any domain user to Domain Admin, no exploit code required
CVE-2021-42278 and CVE-2021-42287 chain into 'noPac,' which takes a standard domain user to Domain Admin in about one command. There's no memory corruption, just abused Active Directory name handling, riding on a default that lets ordinary users create computer accounts.
The “noPac” technique does something that should not be possible: it takes any authenticated domain user, no special privileges, to Domain Admin, in roughly a single command, with no exploit code in the memory-corruption sense. It chains two Active Directory flaws, CVE-2021-42278 and CVE-2021-42287, that abuse how AD and Kerberos handle computer-account names. And it works because of a default almost every domain ships with: ordinary users are allowed to create computer accounts. CISA lists both with the ransomware flag, and tooling like noPac.py automates the whole thing.
How the chain works
The two bugs are complementary:
- CVE-2021-42278 (sAMAccountName spoofing). Computer account names are supposed to end with a
$. AD didn’t enforce that, so an attacker could rename a computer account they control to match a domain controller’s name without the trailing$. - CVE-2021-42287 (KDC PAC confusion). When the Kerberos KDC processes a service ticket and can’t find the account, it searches again with a
$appended. Combined with the spoofed name, this lets the attacker obtain a ticket as the domain controller account.
The full sequence: a standard user creates a new computer account, renames it to impersonate a DC (dropping the $), requests a Kerberos TGT for it, then uses S4U2self to get a service ticket that the KDC resolves to the real domain controller. The result is a ticket with domain-controller privileges, which is game over for the domain. Microsoft patched both on November 9, 2021.
The enabling default is the real story
The step that makes this possible for a normal user is “create a new computer account.” By default, Active Directory’s ms-DS-MachineAccountQuota is set to 10, meaning any authenticated user can join up to ten computers to the domain, which means any authenticated user can create computer accounts. That default exists for convenience in environments where users self-provision machines, but it’s a standing privilege-escalation enabler that noPac and several other AD attacks (RBCD, among others) depend on. Most organizations don’t need ordinary users creating computer accounts at all.
This is the broader lesson, and it’s distinct from the perimeter bugs that dominate the catalog: a large share of the most dangerous attacks are intra-domain, abusing legitimate Active Directory features and permissive defaults rather than exploiting a memory bug. There’s no internet-facing service to patch; the attacker is already an authenticated user (from phishing, a foothold, or a low-priv account), and they walk to Domain Admin through AD’s own machinery. Defending AD means hardening configuration and permissions, not just applying CVE patches.
What to do
- Patch domain controllers with the November 2021 (and subsequent) updates. This is the direct fix for both CVEs and is non-negotiable on every DC.
- Set
ms-DS-MachineAccountQuotato 0. Unless you have a specific, documented need for ordinary users to join computers to the domain, set the quota to zero and delegate machine-joining to a controlled process or designated accounts. This removes the prerequisite for noPac and a family of related AD attacks, a high-leverage hardening change beyond any single patch. - Detect the rename signature. Watch for the spoofing tell: a computer-account rename where the old name ends in
$and the new one doesn’t, and computer-account creations followed quickly by Kerberos ticket requests impersonating a DC. Event-log and EDR detections for this pattern are published and worth deploying. - Treat AD configuration as a security surface in its own right. Audit
MachineAccountQuota, dangerous delegations (unconstrained and resource-based constrained delegation), and over-permissive ACLs. These configuration weaknesses are how foothold-to-domain-admin happens, independent of patch level.
The reframe is to widen your model of “vulnerability” to include Active Directory’s defaults and permissions, not just CVEs. noPac is a patchable bug, but it only works because AD ships letting every user create computer accounts, and that default, not the Kerberos flaw, is the part many environments can harden today and never have. Patch your DCs, set the machine-account quota to zero, watch for the rename pattern, and start treating AD configuration review as core security work. We flag the AD-internal privilege-escalation entries specifically, because they’re the bugs that turn one phished user into the whole domain, with nothing on the perimeter involved.
Sources
Share
Related field notes
-
PetitPotam: make a domain controller authenticate to you, relay it, own the domain
CVE-2021-36942 lets an attacker coerce a Windows machine, including a domain controller, into authenticating to them. Relay that to Active Directory Certificate Services and you can mint a certificate as the DC. It's an Active Directory configuration problem as much as a patch.
-
Two years of Patch Tuesdays, one message: the exploited Windows bug is almost always a privilege escalation
Across 2025 and 2026, Microsoft kept fixing already-exploited Windows flaws, storage drivers, Hyper-V, the network stack, even a 20-year-old third-party modem driver. They don't each need their own post. Together they make one point about patching Windows fast.
-
A clickable link in a SYSTEM dialog is a SYSTEM shell waiting to happen
CVE-2019-1388 turned a hyperlink in the UAC certificate dialog into a path to NT AUTHORITY\SYSTEM. No exploit code, just clicks: open the cert, click 'Issued by,' and the browser launches as SYSTEM. The lesson is what any interactive element in a privileged process really is.
One email, every weekday morning.
You're in. Check your inbox.