CVE-2025-26685 – Spoofing to Elevate Privileges with Microsoft Defender for Identity 

NetSPI discovered a spoofing vulnerability in the Microsoft Defender for Identity (MDI) sensor that abused the Lateral Movement Paths (LMPs) feature and allowed an unauthenticated attacker on the local network to coerce and capture the Net-NTLM hash of the associated Directory Service Account (DSA), under specific conditions. When present with other vulnerabilities, the unauthenticated attacker can elevate privileges to the DSA account and obtain a foothold in the Active Directory environment. This blog covers how NetSPI identified CVE-2025-26685, reported the vulnerability to MSRC, and will also walk through replicating the vulnerability in a lab environment. 

TL;DR

1. The MDI sensor (installed on a Domain Controller) uses a DSA to query systems for members of the Local Administrators group and attempts to map LMPs inside an environment. 
2. An unauthenticated attacker with local network access can initiate a connection to a Domain Controller that triggers the MDI sensor to authenticate and query the attacker’s system for members of the Local Administrators group. 
3. The authentication is done using the SAM-R protocol where authentication can be downgraded from Kerberos to NTLM and results in the DSA’s Net-NTLM hash being captured. The hash can be taken offline for password cracking. 
4. When present with other vulnerabilities, the authentication can be relayed resulting in the attacker elevating privileges and obtaining a foothold in the target Active Directory environment.  

Considerations 

For the attacker to successfully exploit this vulnerability, two conditions must be met: 

• The attacker system must have a DNS record associated with it, which can be done automatically when a Windows DHCP Server is used with an Active Directory environment. 
• The attacker must also initiate an anonymous connection to a Domain Controller that results in a specific Windows Event ID being generated. 

When these conditions are met, the MDI sensor will authenticate to the attacker’s system and attempt to map LMPs by querying members of the Local Administrators group. 

LMPs with the MDI Sensor 

MDI provides insights around LMPs inside the network where an attacker may be able to use a non-sensitive account to gain access to a sensitive account or system. The LMPs feature attempts to identify potential paths and provide visual guidance to help mitigate the risk associated with them.  

References:

• https://learn.microsoft.com/en-us/defender-for-identity/understand-lateral-movement-paths 
• https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-riskiest-lmp 
• https://learn.microsoft.com/en-us/defender-for-identity/deploy/remote-calls-sam 

Configuring the MDI Sensor and DSA 

In an Active Directory Environment, deploy the MDI sensor by navigating to Microsoft Defender > Settings > Identities > “Add Sensor”:

Download the installer and copy the Access Key

Copy the installer to a Domain Controller and begin the installation by providing the Access Key. Continue with the default installation as a Domain Administrator and verify the MDI sensor is showing in Microsoft Defender once finished: 

Configure the DSA as a standard user (not a gMSA) and add the required permissions using the DefenderForIdentity PowerShell Module. This requires the use of a Domain Administrator on the Domain Controller: 

PS C:\Windows\system32> Install-Module DefenderForIdentity 
PS C:\Windows\system32> IPMO DefenderForIdentity 
PS C:\Windows\system32> New-MDIDSA -Identity "DefenderIdentity" -ForceStandardAccount 
True 
PS C:\Windows\system32> Test-MDIDSA -Identity "DefenderIdentity" -Detailed 
 
Test                              Status Details 
----                              ------ ------- 
SensitiveGroupsMembership           True {} 
ExplicitDelegation                  True {} 
DeletedObjectsContainerPermission   True {SPECIAL ACCESS, LIST CONTENTS, READ PROPERTY} 
ManagerOf                           True {} 
PS C:\Windows\system32> Set-MDIConfiguration -Mode Domain -Configuration All -Identity “DefenderIdentity” 
PS C:\Windows\system32> Get-MDIConfiguration -Mode LocalMachine -Configuration All -Identity “DefenderIdentity” 
 
Configuration                  Mode         Status Details 
-------------                  ----         ------ ------- 
CAAuditing                     LocalMachine   True [TRUNCATED] 
NTLMAuditing                   LocalMachine   True [TRUNCATED] 
ConfigurationContainerAuditing LocalMachine   True [TRUNCATED] 
DomainObjectAuditing           LocalMachine   True [TRUNCATED] 
AdfsAuditing                   LocalMachine   True [TRUNCATED] 
AdvancedAuditPolicyDCs         LocalMachine   True [TRUNCATED] 
ProcessorPerformance           LocalMachine   True [TRUNCATED] 
AdvancedAuditPolicyCAs         LocalMachine   True [TRUNCATED] 
PS C:\Windows\system32> Test-MDISensorApiConnection 
True 

References:

• https://learn.microsoft.com/en-us/powershell/module/defenderforidentity/?view=defenderforidentity-latest  

Next, set a strong password for the DSA that was created above for later use when we add it to the MDI sensor in the Defender Portal: 

C:\Windows\system32>net user DefenderIdentity [REDACTED] /domain 
The command completed successfully.

Enable ADCS Certificate Authority Auditing as a Domain Administrator: 

C:\Windows\system32>certutil -setreg CA\AuditFilter 127 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\SEVENKINGDOMS-CA\AuditFilter: 
 
New Value: 
  AuditFilter REG_DWORD = 7f (127) 
CertUtil: -setreg command completed successfully. 
The CertSvc service may need to be restarted for changes to take effect. 
 
C:\Windows\system32>net stop certsvc && net start certsvc 
The Active Directory Certificate Services service is stopping. 
The Active Directory Certificate Services service was stopped successfully. 
 
The Active Directory Certificate Services service is starting. 
The Active Directory Certificate Services service was started successfully. 
 

Refresh Microsoft Defender and verify the MDI sensor is in a healthy status: 

Navigate to the Directory Service Account section of Microsoft Defender and add the DSA user that was created: 

Tag the Domain Controller as “Sensitive”: 

On the Domain Controller, use the DNS Manager to create a new “Reverse Lookup Zone” for the subnet that the Attacker system is on: 

Create a “Pointer” for the Attacker system with the corresponding IP address and specified DNS name: 

As stated earlier, this is necessary for the attack to work as the MDI sensor requires a DNS name to be associated with the offending IP address for the function to be called that initiates the LMPs mapping from the MDI sensor.  

While we are manually creating the “Pointer” record to replicate the vulnerability, it should be noted that Windows DHCP servers can be used in an Active Directory environment, resulting in these DNS records being added automatically. 

Exploiting the MDI Sensor 

Before we get started, it should be noted that there may have been other potential actions that could be taken as an unauthenticated attacker to trigger the vulnerability which were unknown; as such, we will only demonstrate with this example since the vulnerability has been remediated. 

Kali Linux was utilized during the following demonstration as the attacker system as it comes with many relevant tools already installed. The vulnerability was replicated in the GOAD (Game of Active Directory) labs to demonstrate the impact when other vulnerabilities are present in an environment. 

On the attacker system, start an SMB listener with Impacket’s “smbserver”: 

Use “rpcclient” in Kali Linux (a utility in the Samba toolset) to initiate an SMB Anonymous Null Session to the target Domain Controller with an MDI sensor installed. This action is unauthenticated: 

Note: The SMB Null Session does not need to be established for the attack to work. The following alternative command can be executed from a Windows system to trigger the vulnerability: 

Command: net use \\{DC IP}\ipc$ "" /user:""

The attempt will generate a specific Windows Event ID that will trigger the MDI sensor to query the attacker’s system for members of the Local Administrators group and attempt to map LMPs. This results in the MDI sensor authenticating using the DSA over the SAM-R protocol which gets downgraded from Kerberos to NTLM authentication: 

Observe that the Net-NTLMv1 hash for the DSA is captured. An attacker could then take the captured hash offline and attempt to crack it using tools such as Hashcat. If successful, this would allow the attacker to escalate privileges to the DSA. 

This attack is also possible when Net-NTLMv2 is enforced: 

Spoofing to Elevate Privileges 

The vulnerability present with the MDI sensor can be used in conjunction with other vulnerabilities to gain a foothold in the target Active Directory environment such as ADCS related vulnerabilities or LDAP relaying to create a Domain Machine Account. This is not a part of the MDI sensor vulnerability, but an opportunity to demonstrate the impact it has on the environment.  

While there are many attack paths that can be utilized with this finding, we will demonstrate this attack by using the ESC8 vulnerability which is a misconfiguration with the ADCS Certificate Authority where the Enrollment Service is installed and allows for HTTP-based Web Enrollment with NTLM authentication. 

The attacker can relay the captured authentication data to the enrollment endpoint to request a certificate in the context of the DSA. This will result in the attacker retrieving a TGT and NT hash for the DSA account. This attack is done as an unauthenticated attacker on the local network. 

Required Tools:

• https://github.com/ly4k/Certipy
• https://github.com/Pennyw0rth/NetExec (available on Kali Linux) 

Use “Certipy” to start the relay listener and specify a target Certificate Authority that is vulnerable to ESC8: 

Command: certipy relay -target 'http://[ADCS-CA]

Use “rpcclient” to initiate an SMB Anonymous Null Session to the target Domain Controller with an MDI sensor installed. This action is unauthenticated: 

Command: rpcclient -U "" -N [DC-IP]

Observe that the authentication is immediately captured in the Certipy listener. Certipy will default to the User template to request a certificate in the context of the DSA account and output the certificate/private key to a PFX file. 

Use Certipy’s “auth” command to retrieve a TGT and NT hash for the DSA using the PFX file output in the previous step: 

Command: certipy auth -pfx [PFX] -dc-ip [DC-IP] -domain [Domain] -user [User]

Use NetExec in Kali Linux to authenticate as the DSA to the Domain Controller with the NT hash and retrieve information from the domain over LDAP: 

Command: nxc smb [DC-IP] -d [Domain] -u [User] -H [NT-Hash]

Detection Opportunities 

Below is a list of potential detection opportunities that can be used to identify anomalous activities that may indicate the DSA account has been compromised. Detection Opportunities 2-4 will cover ADCS as that escalation path was outlined in this blog post; other additional detection opportunities are available depending on what escalation path is used in conjunction with the MDI sensor vulnerability such as LDAP relaying to create a Domain Machine Account. 

Please note that not all of these will work in every environment due to false positives generated by legitimate applications and processes. However, in some environments it may be possible to modify thresholds or create allow-lists of known-good examples to reduce the number of false positives to an acceptable level. 

Detection Opportunity # 1: Authentication events that do not originate from a Domain Controller 

• Data Source: Authentication Events 
• Detection Strategy: Anomaly 
• Detection Concept: Detect on any authentication event, such as Windows Event ID 4624 for the DSA account where the source IP address is not a Domain Controller. 
• Detection Reasoning: The DSA account should only ever authenticate from the Domain Controller via the MDI sensor. 
• Known Detection Considerations: None 

Detection Opportunity # 2: ADCS – LDAP Requests looking for vulnerable certificate templates 

• Data Source: LDAP Request 
• Detection Strategy: Signature 
• Detection Concept: Detect on any LDAP requests that contain any of the following strings in the query field.
  (objectCategory=pKIEnrollmentService)(objectClass=certificationAuthority)(objectclass=pKICertificateTemplate)
• Detection Reasoning: A threat actor may try to enumerate certificate templates to find vulnerable ones before exploiting the vulnerability. An easy way to find vulnerable templates is to query LDAP. 
• Known Detection Considerations: None 

Detection Opportunity # 3: ADCS – Certificate issued

• Data Source: Active Directory Credential Request 
• Detection Strategy: Behavior 
• Detection Concept: Detect on when a certificate is issued using Windows Event ID 4887. 
• Detection Reasoning: A threat actor must request a certificate and get it issued in order to use it 
• Known Detection Considerations: This detection is only worthwhile in environments where certificates are never issued, so every issue can be seen as suspicious or where certificates are only issued to a small subset of users, and these users can be added as exceptions. In environments where certificates are used this is likely to generate too many false positives. 

Detection Opportunity # 4: ADCS – TGT requested using Certificate

• Data Source: Active Directory Credential Request 
• Detection Strategy: Behavior 
• Detection Concept: Detect on users requesting a Kerberos TGT ticket using a certificate for pre-authentication. This is shown by a Windows Event ID 4768 having a pre-authentication type of 16. 
• Detection Reasoning: Once a threat actor has requested a certificate, they would need to use it to authenticate as the new user. Requesting a TGT is a common way of doing this. 
• Known Detection Considerations: If certificate-based authentication is commonly used throughout the environment, this may produce too many false positives. 

Conclusion

This vulnerability allows an unauthenticated attacker on the local network to elevate privileges (under specific conditions) to the DSA account used by the MDI sensor via the LMPs feature. When present, this vulnerability can significantly increase the risk of an attacker obtaining a foothold in the Active Directory environment as the complexity is low. The DSA is typically lower-privileged, but would allow an attacker to gather additional information about the domain as it has read privileges over all Active Directory objects (including the Deleted Objects Container). Additionally, the DSA would be able to query all systems on the local network for members of the Local Administrators group if configured to support SAM-R. The DSA account should be monitored in existing EDR solutions for anomalous activities that could indicate the account has been compromised.  

Remediation

Microsoft recommends migrating to the unified XDR sensor (version 3.x), which they note was never vulnerable to begin with since it utilizes different detection methods. The classic MDI sensor will no longer use SAM-R queries and will be replaced with WMI queries that are locked to Kerberos authentication. 

When in use, the DSA (as a standard user) should be provisioned as a low-privileged user. The DSA can also be configured as a gMSA which would limit the impact of this vulnerability as the password would not likely be cracked offline. Additionally, you can contact support and open a case to request the Lateral Movement Paths data collection feature be disabled altogether. 

MSRC Disclosure Timeline