Skip to main content

Flying Under The Radar – An Introductory Guide To Bypassing Microsoft Defender For Identity Detections

Bypassing Microsoft Defender For Identity Detections By white oak security

Bypassing Microsoft Defender For Identity Detections

On a few recent internal penetration tests, I found common tools and techniques for Active Directory attacks being detected by Microsoft Defender for Identity (formerly known as Azure Advanced Threat Protection/Azure ATP. Defender for ID is incredibly powerful in its default configuration and relatively easy to set up. Additionally, it includes functionality for custom queries and threat hunting, making it an excellent tool for defenders. I will not go into install steps in this post, as they are well-documented already. 

I decided to install the default configuration of Defender for Identity in my small Active Directory test lab to test certain methodologies and gain insight into the detections provided by Defender for ID. This blog post will detail how detections are implemented in Defender for ID for several common attack paths, along with some bypass options that are working as of Nov. 3rd, 2023.

Kerberoasting

I ran a default run of Kerberoasting using Impacket.

python3 GetUserSPNs.py -request -dc-ip 192.168.0.150 test.lab/t -outputfile kerberoast.txt

Detection

This led to the following alert in the Microsoft 365 Defender Portal, which is the control panel for Defender for ID among other tools:

Kerberos SPN exposure screenshot by white oak security

Selecting the timestamp at the bottom, we see the “Search Filter” is an LDAP query used to identify Kerberoastable accounts:

LDAP query used to identify Kerberostable by white oak security

Bypass

This information tells us that Defender for Identity uses the LDAP query for initial detection, and then appears to pull SPN ticket requests that immediately follow the LDAP query. This likely is done to cut down on false positives but means that we can easily bypass this detection.

Examining the code within Impacket’s GetUserSPNs.py we see the following LDAP query used for a search filter:

Examining the code within Impacket’s GetUserSPNs.py we see the following LDAP query used for a search filter screenshot by white oak security

I attempted to bypass detections by rearranging the parameters within the query, but the modified query was still detected. It might be possible to break up the filter with individual queries to get a list of all Kerberoastable users, but this information can also be obtained via other tools such as Bloodhound or “Active Directory Users and Computers”. Once that list is obtained, individually requesting Kerberos SPNs does not result in any alerts.

The screenshot shows executing an undetected Kerberoast attack via Impacket with a single user:

The screenshot shows executing an undetected Kerberoast attack via Impacket with a single user by white oak security 
python3 GetUserSPNs.py -request -dc-ip 192.168.0.150 test.lab/t:Password123 -outputfile kerberoast.txt -usersfile ~/krbusers -debug
Screenshot of code by white white oak security shows the Microsoft defender bypass

AS-REP Roasting

Running an AS-REP roasting attack using a list of common usernames resulted in a Medium-Risk alert in the portal.

Detection

Kerbrute was used to perform the AS-REP Roasting:

kerbrute userenum –dc 192.168.0.150 –delay 100 -d test.lab -o kerbrute.log -v ~/opt/testusernames.txt

This generated the following alert in the Defender Portal:

New alert in the defender portal screenshot by white oak security during AS-REP Roasting through kerbrute and impacket

Bypass

There appeared to be no way to bypass this detection, and the account performing the reconnaissance was automatically disabled by Defender for ID, resulting in the inability to perform further enumeration:

Kerbrute screenshot by white oak Security for bypassing Microsoft Defender for identifying

One interesting note is that the number of guess attempts and successfully guessed users in the console appeared to be incorrect. My run included 919 usernames and 8 valid accounts:

One interesting note is that the number of guess attempts and successfully guessed users in the console appeared to be incorrect. My run included 919 usernames and 8 valid accounts.

However, the Defender Portal showed only 156 guess attempts and 6 valid accounts:

However, the Defender Portal showed only 156 guess attempts and 6 valid accounts Screenshots by white oak security

Code Execution

Several common methods of code execution were performed against a host using credentials as well as NTLM via pass-the-hash for authentication. 

Powershell Remoting

Executing commands via Powershell remoting was performed using evilwinrm. Code execution using credentials and pass-the-hash both resulted in a medium-risk alert:

Executing commands via Powershell remoting was performed using evilwinrm. Code execution using credentials and pass-the-hash both resulted in a medium-risk alert Screenshot by white oak security
Executing commands via Powershell remoting was performed using evilwinrm. Code execution using credentials and pass-the-hash both resulted in a medium-risk aler in the defender portal by white oak security

However, it appears that the actual commands that were run did not get logged. An interactive session via EvilWinRM resulted in the following logged output in the Defender Portal:

However, it appears that the actual commands that were run did not get logged. An interactive session via EvilWinRM resulted in the following logged output in the Defender Portal By white oak security

RDP

Connecting to a device via RDP with credentials did not trigger any alerts in my test lab, although this may be dependent on the Defender for ID learning period determining which RDP logins are suspicious or not:

xfreerdp /v:192.168.0.150 /u:t /p:’Password123!’
Connecting to a device via RDP with credentials did not trigger any alerts in my test lab, although this may be dependent on the Defender for ID learning period determining which RDP logins are suspicious or not Screenshots by white oak security

PSexec & WMIexec

Using either Impacket’s psexec.py or wmiexec.py with credentials or pass-the-hash results in a high-severity alert in the Defender Portal:

Using either Impacket’s psexec.py or wmiexec.py with credentials or pass-the-hash results in a high-severity alert in the Defender PortaL screenshot by white oak security

Further research to determine what artifacts trigger the Impacket detection would be interesting but was beyond the scope of this blog. 

DCOMexec/MMCexec

Using Impacket’s dcomexec.py did not generate any alerts using password or pass-the-hash:

python3 dcomexec.py -debug -silentcommand t:’Password123!’@192.168.0.150 ntdsutil.exe ‘ac I ntds’ ‘ifm’ ‘create full C:\Windows\Temp\169108586’ q q
Using Impacket’s dcomexec.py did not generate any alerts using password or pass-the-hash Screenshot by white oak security

However, any commands that require elevated execution will result in a UAC prompt and will require a UAC bypass to gain code execution as SYSTEM.

The reasoning for DCOM/MMC not generating alerts is hinted at in a CrackMapExec comment, noting that it does not generate noisy event log messages:

Crackmapexec/NetExec

Using CrackMapExec for command execution essentially uses smbexec under the hood by default, but results in a Medium-severity alert instead of a high-severity alert in the Defender Portal:

Using CrackMapExec for command execution essentially uses smbexec under the hood by default, but results in a Medium-severity alert instead of a high-severity alert in the Defender Portal Screen shot by white oak security

Dumping NTDS

There are three common methods for dumping NTDS.dit from a domain controller: DRSUAPI (DCSync), Volume Shadow Copies (VSS), and ntdsutil.exe. 

DRSUAPI

The following CrackMapExec method for dumping NTDS uses DRSUAPI by default:

crackmapexec smb 192.168.0.150 -u t -p Password123 --ntds
The following CrackMapExec method for dumping NTDS uses DRSUAPI by default Screenshot by white oak security

The default Impacket secretsdump.py method for dumping NTDS also uses DRSUAPI by default:

python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150
The default Impacket secretsdump.py method for dumping NTDS also uses DRSUAPI by default Screenshot by white oak security

Both of these result in a high-severity alert in the Defender Portal:

Both of these result in a high-severity alert in the Defender Portal Screenshot by white oak security

Volume Shadow Copy

Crackmapexec and secretsdump both have options to use Volume Shadow Copy (VSS) instead of DRSUAPI. 

Crackmapexec uses the following syntax for dumping NTDS via VSS:

crackmapexec smb 192.168.0.150 -u t -p Password123 –ntds vss
Crackmapexec uses the following syntax for dumping NTDS via VSS screenshot of code by white oak security

This results in successful execution, but still generates the medium-severity alerts associated with CrackMapExec code execution:

This results in successful execution, but still generates the medium-severity alerts associated with CrackMapExec code execution Screenshot by white oak security

Impacket uses the following syntax for dumping NTDS via VSS:

python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150 -use-vss
Impacket uses the following syntax for dumping NTDS via VSS Screenshot by white oak security

This method still results in the above “Suspicious service creation on one endpoint” alert due to secretsdump.py using SMBexec under the hood.

Attempting secretsdump using WMIexec results in the command failing to create a Volume Shadow Copy to dump NTDS and generating a new alert:

python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150 -use-vss -exec-method wmiexec
Attempting secretsdump using WMIexec results in the command failing to create a Volume Shadow Copy to dump NTDS and generating a new alert Screenshot by white oak security
Attempting secretsdump using WMIexec results in the command failing to create a Volume Shadow Copy to dump NTDS and generating a new alert In the defender portal by white oak security

Using secretsdump with the MMCexec option successfully dumps NTDS without generating any alerts:

python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150 -use-vss -exec-method mmcexec
Using secretsdump with the MMCexec option successfully dumps NTDS without generating any alerts Screenshot by White Oak Security

This is interesting as well because it implies that secretsdump includes a UAC bypass that can be used in conjunction with MMC/DCOM execution that is not included in the dcomexec.py script. 

Ntdsutil.exe

Using ntdsutil.exe surprisingly did not generate any alerts:

ntdsutil.exe ‘ac i ntds’ ‘ifm’ ‘create full C:\Windows\Temp\testasdf’ q q
Using ntdsutil.exe surprisingly did not generate any alerts Screenshot by white oak security

This method requires elevated remote command execution as well as a way to retrieve the local files from the domain controller.  

Microsoft Defender For ID Conclusion

Microsoft Defender for ID is very robust right out of the box and makes life difficult for attackers attempting to fly under the radar. It provides excellent insight into attacks and automatically disables accounts suspected of being compromised or used in an attack. However, as this post demonstrates there are several methods for bypassing these detections that can be used by red teamers or penetration testers to achieve their objectives. From my testing, RDP appeared to be the most reliable way of achieving code execution without setting off alerts, with unmodified pass-the-hash capable tools being difficult to use without detection.

MORE FROM WHITE OAK SECURITY 

White Oak Security provides deep-dive offensive security testing. We are a highly skilled and knowledgeable cyber security and penetration testing company that works hard to help organizations strengthen their security posture by getting into the minds of opponents to try to protect those we serve from malicious threats through expertise, integrity, and passion. 

Our unique industry experience allows us to offer a wide range of services to help analyze and test information security controls and provide guidance to prioritize and remediate vulnerabilities.

Read more from White Oak Security’s pentesting team.