After Microsoft released security patches for two Active Directory vulnerabilities with the Tuesday, November 9, 2021 patch, Microsoft urged customers on December 20 to apply the patches immediately to prevent attackers from taking over Windows domains. In addition to patching, organizations can increase their defenses against attacks by executing a couple of actions that will help prevent the unauthorized creation of accounts. Unauthorized accounts could lead to the elevation of privileges to those of a Domain Admin once a regular user account has been compromised. An event like this can simply be regarded as an escalated attack.

In this post, I demonstrate how an attacker with standard user rights can gain access to privileged Domain Admin rights.

CVE-2021-42278 – sAMAccountName spoofing

By default, a standard domain user can join a computer to an Active Directory domain a maximum of 10 times. To distinguish user accounts from computer accounts, the latter should have a trailing $ in its sAMAccountName attribute. The problem is that Active Directory does not validate whether the $ sign has been added to the name.

If you want to know who can join computers to your AD domain, you can check the SeMachineAccountPrivilege setting (“Add workstations to domain”) of your Default Domain Controllers Policy in Computer Configuration\Windows Settings\Security Settings\User Rights Assignment\.

SeMachineAccountPrivilege in Default Domain Controller Policy

SeMachineAccountPrivilege in Default Domain Controller Policy

To verify the number of computer accounts that a user is allowed to create in a domain, you can run this PowerShell command:

Get-ADComputer client01 -Identity (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota
MS DS Machine Account Quota settings

MS DS Machine Account Quota settings

CVE-2021-42287 - Active Directory domain services elevation of privilege vulnerability

Once the sAMAccountName spoofing vulnerability is exploited, attackers request a ticket-granting ticket (TGT) for the modified computer object or identity. Then the attacker can attempt to remove or rename the original computer account. Upon receiving the TGT, attackers can request a service ticket using the computer object sAMAccountName that was previously tweaked.

Knowing fully that Kerberos Key Distribution Center (KDC) supplies session tickets and temporary session keys to users and computers within an Active Directory domain, the attacker can leverage the Active Directory domain service privilege escalation vulnerability to create a forgery of the with the flaws stated below.

  1. The ticket-granting service (TGS) can be requested for an account that doesn't exist on a Domain Controller, and KDC will attempt to search the identity or account name again, adding $.
  2. No attempt is made to validate the account requesting the service ticket to see if the requestor’s account is the same as that referenced in the original TGT.


Since the KDC cannot find the account used when the TGT was issued, it will attempt another lookup, including $ at the end of the account name. This will result in the sAMAccountName of the Domain Controller, for which the KDC will issue the service ticket. Combining the two flaws stated above, an attacker with domain user credentials can leverage these flaws, thereby elevating user access rights and privileges.

The following are required for successful exploitation:

  • Domain user credentials
  • MachineAccountQuota—anything above 0
  • SeMachineAccountPrivilege to authenticated users
  • Any of the Domain Controllers not patched with the November 2021 updates

The exploitation and its detection

A walkthrough of each exploitation step and its detection events are captured below to provide a brief overview of these flaws.

To begin, use Powermad's New-MachineAccount tool to construct a new computer, as shown in the figure below.

New-MachineAccount -MachineAccount PC03 -Domain -DomainController -Verbose
Create a machine account

Create a machine account

Then, using the PowerView module's set-DomainObject command, clear the service principal name of that computer.

Set-DomainObject "CN=PC03,CN=Computers,DC=teamcloudapex,DC=com" -Clear 'serviceprincipalname' -Verbose
Clear SPN of the machine account

Clear SPN of the machine account

Because you have the "creator owner" access in Active Directory for that object, you can change the sAMAccountName attribute's property. Run the command below to modify that attribute to be the same as that of the domain controller name (without the $).

Set-MachineAccountAttribute -MachineAccount TestSPN -Value "IDC1" -Attribute sAMAccountName  -Verbose
Modify the sAMAccountName attribute

Modify the sAMAccountName attribute

Here, event 4781 helps to identify the changes that were made against the computer object. As illustrated in the figure below, the sAMAccountName attribute has been modified from the value PC03$ to DC using the account teamcloudapex\krishna. It was reported that someone changed the computer's attribute to remove the $ symbol at the end, which is unusual.

Computer object modification event 4781

Computer object modification event 4781

Rubeus now requests a TGT token with the faked sAMAccountName as the username and password provided during the computer object creation process. Kerberos validates the request and provides a TGT token that can be used later.

.\Rubeus.exe asktgt /user:DC /password:12345 / /dc: /nowrap
Request a TGT using forged information

Request a TGT using forged information

Event 4678, which is triggered shortly after event 4781, can be used to track this exploitation activity. A Kerberos TGT token has been granted to the account "DC," as shown in the figure below, which was indicated in the previously created event 4781.

TGT request and successful Event 4768

TGT request and successful Event 4768

The computer's sAMAccountName has now been restored to its original value from the DC name using the command in the figure below.

Set-MachnineAccountAttribute -MachineAccount PC03 -Value 'PC03$' -Attribute 'samaccountname' -Verbose
Revert the sAMAccountName attribute

Revert the sAMAccountName attribute

An attacker can now request a TGS for the LDAP/ SPN on the Domain Controller, employing S4U for the Domain Administrator account, using that TGT. KDC is unable to locate the account with the name "DC" when the lookup occurs. As a result, it appends the $ symbol to the computer name and finds a match, which is nothing more than a DC account with the necessary rights to obtain a TGS for the Domain Admin.

Request a TGT using forged information 1

Request a TGT using forged information 1

The suspicious activity was logged in the event with ID 4769 and highlights the Domain Controller name (without the $ sign) used as an account name to request a service ticket, as shown in the figure below.

Service ticket auditing event 4769

Service ticket auditing event 4769

The obtained service ticket can then be used to consume any service on the Domain Controller.


Patch the Domain Controllers

Patching the Domain Controllers with the following patches is strongly recommended by Microsoft. KB5008102 prevents modifications to sAMAccountName properties, and KB5008380 protects against CVE-2021-42287, which adds extra security information about the original requester to Kerberos TGT PACs. Both security fixes are included in the cumulative update bundle for November 2021.

I tried to spoof the sAMAccountName after applying the update, but I couldn't get it to work. The figure below shows how Active Directory stopped that request and created an event with ID 16991.

Unauthorized computer object modification failure event

Unauthorized computer object modification failure event

Update SeMachineAccountPrivilege settings

The privileges around the setting SeMachineAccountPrivilege should be assigned to the group of users intended to perform administrative tasks such as Domain Join from the GPO deployed in the domain. It is very important to verify and remove inappropriate users and groups, perhaps any that have been added to this setting.

Subscribe to 4sysops newsletter!

Enable enforcement mode

Enforcement mode allows validating that the request has a new PAC (introduced as part of the November 2021 update). Authentication is denied if the request does not have a new PAC, which means attacks are no longer possible by using the obtained TGT with a different account name to request a service ticket. Microsoft will enforce this setting in the July 12, 2022 update. If you want to transition to the enforcement phase early, manually define the PacRequestorEnforcement registry as per this Microsoft article.

  1. Peter 2 years ago

    Great article.
    The PacRequestorEnforcement=2 has a number of problems. When you reset a users password through ADUC, you get an error event on the DC. Cluster Name Object, CNO fails the set the password for the cluster services. We have received a recommendation from the Directory Service Team to wait and leave it to 1 for now and wait for future updates.

  2. AG 2 years ago

    Great post. However, neither of those KB’s are available to install anymore (either from WSUS or searching Windows Update online [update catalog])

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account