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.
I ran a default run of Kerberoasting using Impacket.
python3 GetUserSPNs.py -request -dc-ip 192.168.0.150 test.lab/t -outputfile kerberoast.txtThis led to the following alert in the Microsoft 365 Defender Portal, which is the control panel for Defender for ID among other tools:
Selecting the timestamp at the bottom, we see the “Search Filter” is an LDAP query used to identify Kerberoastable accounts:
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:
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:
python3 GetUserSPNs.py -request -dc-ip 192.168.0.150 test.lab/t:Password123 -outputfile kerberoast.txt -usersfile ~/krbusers -debugRunning an AS-REP roasting attack using a list of common usernames resulted in a Medium-Risk alert in the portal.
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.txtThis generated the following alert in the Defender Portal:
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:
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:
Several common methods of code execution were performed against a host using credentials as well as NTLM via pass-the-hash for authentication.
Executing commands via Powershell remoting was performed using evilwinrm. Code execution using credentials and pass-the-hash both resulted in a medium-risk alert:
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:
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!’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:
Further research to determine what artifacts trigger the Impacket detection would be interesting but was beyond the scope of this blog.
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 qHowever, 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:
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:
There are three common methods for dumping NTDS.dit from a domain controller: DRSUAPI (DCSync), Volume Shadow Copies (VSS), and ntdsutil.exe.
The following CrackMapExec method for dumping NTDS uses DRSUAPI by default:
crackmapexec smb 192.168.0.150 -u t -p Password123 --ntdsThe default Impacket secretsdump.py method for dumping NTDS also uses DRSUAPI by default:
python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150Both of these result in a high-severity alert in the Defender Portal:
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 vssThis results in successful execution, but still generates the medium-severity alerts associated with CrackMapExec code execution:
Impacket uses the following syntax for dumping NTDS via VSS:
python3 secretsdump.py -just-dc-ntlm test/t@192.168.0.150 -use-vssThis 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 wmiexecUsing 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 mmcexecThis 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.
Using ntdsutil.exe surprisingly did not generate any alerts:
ntdsutil.exe ‘ac i ntds’ ‘ifm’ ‘create full C:\Windows\Temp\testasdf’ q qThis method requires elevated remote command execution as well as a way to retrieve the local files from the domain controller.
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.
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
Read more from our technical experts...