Blog Post

Microsoft Security Community Blog
4 MIN READ

SAM Name impersonation

Daniel Naim's avatar
Daniel Naim
Iron Contributor
Dec 20, 2021

27/12/2021 update: From version 2.166, Microsoft Defender for Identity can now natively detect this vulnerability. This version includes a new security alert: Suspicious modification of a sAMNameAccount attribute (CVE-2021-42278 and CVE-2021-42287 exploitation) (external ID 2419)

During the November security update cycle, Microsoft released a patch for two new vulnerabilities, CVE-2021-42287 and CVE-2021-42278. Both vulnerabilities are described as a ‘Windows Active Directory domain service privilege escalation vulnerability’.

 

A few weeks later, on December 12, 2021, a proof-of-concept tool leveraging these vulnerabilities was publicly disclosed.

 

When combining these two vulnerabilities, an attacker can create a straightforward path to a Domain Admin user in an Active Directory environment that hasn’t applied these new updates. This escalation attack allows attackers to easily elevate their privilege to that of a Domain Admin once they compromise a regular user in the domain

 

As Defender for Identity’s mission is to secure Active Directory and your environment against advanced and sophisticated identity threat attacks, our research team reacted fast and published a query that can be used to identify suspicious behavior leveraging these vulnerabilities. This query can help detect abnormal device name changes (which should happen rarely to begin with) and compare them to a list of domain controllers in your environment.

 

As always, we strongly advise deploying the latest patches on the domain controllers as soon as possible.

 

  KB5008102—Active Directory Security Accounts Manager hardening changes (CVE-2021-42278)
KB5008380—Authentication updates (CVE-2021-42287)
KB5008602(OS Build 17763.2305) Out-of-band

 

To investigate if these vulnerabilities might have been exploited in your environment before the hotfixes were deployed, we highly recommend you follow the step-by-step guide below.


Our research team continues its effort in creating more ways to detect these vulnerabilities, either with queries or out-of-the-box detections.

 

 

Let’s do a quick dive into each of these vulnerabilities:

 

CVE-2021-42278 – SAM Name impersonation

Internally, Active Directory (AD) uses several naming schemes for a given object. Like userPrincipalName (UPN), and sAMAccountName (SAM-Account).

 

How do I find the sAMAccountNames in my Active Directory?

With Active Directory Users and Computers open:

  • Click View > Advanced Features
  • Open the properties of an object > Attribute Editor tab > Scroll down to sAMAccountName

 

(figure 1 – sAMAccountName of computer object)

 

In cases of computers – these sAMAccountName attributes usually end with “$” in their name. Traditionally, this $ was used to distinguish between user objects and computer objects. It is important to mention there are no restrictions or validations for changing this attribute to include or not include the $ sign.

With default settings, when the relevant patch is not applied, a normal user has permission to modify a machine account (up to 10 machines) and as its owner, they also have the permissions to edit its sAMAccountName attribute.

 

CVE-2021-42287 - KDC bamboozling

This CVE addresses a vulnerability that allows a potential attacker to impersonate the domain controllers directly.

 

When performing an authentication using Kerberos, Ticket-Granting-Ticket (TGT) and the following Ticket-Granting-Service (TGS) are being requested from the Key Distribution Center (KDC). In case a TGS was requested for an account that could not be found, the KDC will attempt to search it again with a trailing $.

 

For example, if there is a domain controller with a SAM account name of DC1$, an attacker may create a new machine account and rename its SAM account name to DC1, request a TGT, rename it again for a different name, and request a TGS ticket, presenting the TGT he has in hands.


When processing the TGS request, the KDC will fail its lookup for the requestor machine DC1 the attacker had created. Therefore, The KDC will perform another lookup appending a trailing $. The lookup will succeed. As a result, the KDC will issue the ticket using the privileges of DC1$.


Combining the two CVEs, an attacker with domain user credentials can leverage them for granting access as a domain admin user in a few simple steps.

 

Step by Step Guide to Identify Potential Compromised Computers via Advanced Hunting Query

 

  1. The sAMAccountName change is based on event 4662. Please make sure to enable it on the domain controller to catch such activities. Learn more of how to do it here.
  2. Open Microsoft 365 Defender and navigate to Advanced Hunting.
  3. Copy the following query (which is also available in the Microsoft 365 Defender GitHub Advanced Hunting query):
    IdentityDirectoryEvents
    | where Timestamp > ago(1d)
    | where ActionType == "SAM Account Name changed"
    | extend FROMSAM = parse_json(AdditionalFields)['FROM SAM Account Name']
    | extend TOSAM = parse_json(AdditionalFields)['TO SAM Account Name']
    | where (FROMSAM has "$" and TOSAM !has "$")
            or TOSAM in ("DC1", "DC2", "DC3", "DC4") // DC Names in the org
    | project Timestamp, Application, ActionType, TargetDeviceName, FROMSAM, TOSAM, ReportId, AdditionalFields

     

  4. Replace the marked area with the naming convention of your domain controllers
  5. Run the query and analyze the results which contains the affected devices. You can use Windows Event 4741 to find the creator of these machines, if they were newly created
  6. We recommend investigating these compromised computers and determine that they haven’t been weaponized.
  7. Make sure to update the devices with the following KBs:

 

The Microsoft Defender for Identity security team

Updated Jan 12, 2022
Version 2.0

8 Comments

  • pro79's avatar
    pro79
    Copper Contributor

    Does the first also apply to people who had - based on their certification or other source of knowledge - ms-DS-MachineAccountQuota set to zero? This is a nasty thing that I suppose many admins do not know and then wonder how regular users could ever join computer to the domain. We found that out by accident over 10 years ago and even a highly-certified consultant was puzzled by this; seems he didn't take his certifications that seriously because I learned about that behavior in my own MCITP 2008 Server/Enterprise Admin studies based on the MS certification books.

     

    https://docs.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota

  • RashaSilmi's avatar
    RashaSilmi
    Copper Contributor

    Preventing domain users from joining/creating machine account could eliminate to attack from the beginning. This privilege should be restricted to authorized accounts only (i.e. IT)

    https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain  

    https://blog.compass-security.com/2020/03/domain-join-computers-the-proper-way/

     

  • rpodric's avatar
    rpodric
    Bronze Contributor

    The other one encouraging user action (at least the Event Viewer messages do) is CVE-2021-42291:

    https://support.microsoft.com/en-us/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1

     

    But that article just assumes you know how to change dSHeuristics. This article points the way more specifically:

    https://ldapwiki.com/wiki/Enable%20UserPassword%20in%20Microsoft%20Active%20Directory

     

    The article is for a different purpose, so don't make the changes it suggests. I point to it merely for ADSI Edit, since that article is also about making a change to dSHeuristics. ADSI Edit can be found in the Tools menu of Server Manager.

  • November 9th '21 - Initial deployment - support for registry key - let's you manually transition to Enforcement mode (2) - PS: registry key not created by update

    April 12th '22 - Second deployment - removes setting = 0 - Everything is treated as 1 

    July 12 '22 - Enforcement phase - will remove registry key if exists - Enforced at 2 (can't change)

    • DCs updated not compatible with DCs that did not install November 9th update
    • Domain controllers that installed the November 9, 2021 or later updates but have not yet installed the April 12, 2022 update AND who have a PacRequestorEnforcement registry value of 0.

    However, Windows domain controllers that have installed the July 12, 2022 update will remain compatible with:

    • Windows domain controllers that have installed the July 12, 2022 or later updates

    • Window domain controllers that have installed the November 9th, 2021 or later updates and have a PacRequestorEnforcement value or either 1 or 2

     

     

  • JeenT's avatar
    JeenT
    Copper Contributor

    Duncan1528 - if you don't enable enforcement - then you still have to monitor the eventlog for breaches via monitoring Event 4662 or 37 as per default the installation of the patch only warns you of Ticket without the requestor in the PAC. Enforcement relieves you from that - as in it denies such tickets. So as is, just by installing the patch you still have to monitor  

  • JeenT's avatar
    JeenT
    Copper Contributor

    paulyberg - the registry key is not needed; per default your DC is in the "1" mode. The key is needed if you want to either disable "0" or enforce "2" its. Though ironically 2 is the recommendation - so you need the key 🙂

  • Duncan1528's avatar
    Duncan1528
    Brass Contributor

    Is it required to manually activate the Enforcement Mode to be safe against CVE-2021-42287 and CVE-2021-42278, or is it sufficient to only install the November Patches and wait for the Enforcement-Phase-Update on 07/12/2022 ?

  • paulyberg's avatar
    paulyberg
    Copper Contributor

    As seen in https://docs.microsoft.com/en-us/answers/questions/632804/november-2021-updates-events-35-37-on-dcs-pacreque.html, servers that got the Nov 9 update are not seeing the PacRequestorEnforcement key created automatically, as the https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 states it would. Could the documentation be updated to inform admins that they'll need to manually create the key? There seems to be much confusion on this point. Thanks!