Active Directory Reconnaissance is a critical step for threat actors who want to conduct reconnaissance on a targeted network. One popular tool used for this purpose is the ADRecon PowerShell script. This tool is frequently used by ransomware groups, and has recently been used as a post-exploitation technique by the Black Cat ALPHV ransomware. In this blog post, we'll discuss methods for detecting post-exploitation Active Directory Reconnaissance using the ADRecon.ps script and provide detailed technical steps for identifying such activities.
Many Threat Intelligence feeds flag ADRecon as a malicious. Even the latest versions of Windows include Microsoft Virus and Threat Protection, which automatically flag this file as a virus and block it from downloading. Unfortunately, attackers can often bypass these protections and compromise systems using similar PowerShell commands for Active Directory reconnaissance. It's important to exercise caution when using tools like ADRecon in your environment and make sure you have proper security approvals in place.
A Virtual Box VM hosting Windows Server 2022 with log event forwarding to DNIF HYPERCLOUD.
In order to detect post-exploitation Active Directory Reconnaissance using the ADRecon.ps script, we need to enable logging on the targeted Windows Server 2022. To do this, we must enable several types of logging:
- Windows Event Logs
- Windows Sysmon
- Windows PowerShell
- Windows PowerShell - Script block logging
- Audit Process Tracking (Success and Failure both)
To understand how the ADRecon.ps script works, we executed it on a Windows Server 2022 operating system and analyzed the information it gathered. This tool is capable of gathering a wide range of information, including:
- Default and Fine Grained Password Policy (if implemented)
- Domain Controllers, SMB versions, whether SMB Signing is supported and FSMO roles
- Users and their attributes
- Service Principal Names (SPNs)
- Groups and memberships
- Organizational Units (OUs)
- Group Policy Object and gPLink details
- DNS Zones and Records
- Computers and their attributes
- PasswordAttributes (Experimental)
- LAPS passwords (if implemented)
- BitLocker Recovery Keys (if implemented)
- ACLs (DACLs and SACLs) for the Domain, OUs, Root Containers, GPO, Users, Computers and Groups objects
- GPOReport (requires RSAT)
- Kerberoast (not included in the default collection method)
- Domain accounts used for service accounts (requires privileged account and not included in the default collection method)
After ingesting the log events into DNIF HYPERCLOUD, we analyzed the data and made the following systemic observations:
SYSMON DNS EVENTS
We observed a sudden burst of DNS queries from the process powershell.exe, with QueryStatus set to '9003' in a second. This behavior may indicate a reconnaissance activity by an attacker attempting to gather information about the network.
Crucial to note that this type of activity could also indicate a DNS tunneling attack. This technique involves an attacker using DNS queries to send or receive data from a target system. Attackers may use this technique to bypass security controls that are in place and exfiltrate data from a network.
SYSMON PROCESS and WINDOWS AUDIT EVENTS
We observed process hierarchy in sequence as parent-child for powershell.exe, csc.exe, cvtres.exe. This may indicate a multi-stage attack, where the attacker is attempting to compile and execute a malicious payload.
It's important to note that the process hierarchy we observed in Sysmon Process and Windows AUdit could indicate the use of a technique called living-off-the-land (LOLBin). This technique involves attackers using legitimate system processes to execute malicious code. In this case, the attackers appear to be using powershell.exe to execute csc.exe and cvtres.exe, which are legitimate Windows compilers. These compilers could be used to compile malicious code or to evade detection by security controls that may be looking for known malicious processes.
SYSMON FILES CREATED EVENTS
Files are created within AppData\Local\Temp in a second from the above processes.
Both .cmdline and .dll files are created. This may indicate an attempt by the attacker to execute a harmful program by executing a payload or creating a backdoor. The AppData\Local\Temp directory is a common location used by attackers to store temporary files.
A point to reflect on is that the files created in the AppData\Local\Temp directory are often used by attackers to store and execute malicious code. Therefore, it is essential to examine the contents of these files to determine if they pose a threat. Failure to investigate could result in missed indicators of compromise and leave the system vulnerable to further attacks.
We can create a detection logic based on the observations made during the ADRecon.ps script execution. This mechanism can be designed to identify not only the execution of the ADRecon.ps1 script but also any PowerShell script used for AD reconnaissance activities in general.
Below are the detection ideas that can be implemented:
- Check for $Image = powershell.exe AND $QueryStatus = '9003'
- Check for a communication burst on Destination Port - 389 (should be customized to type of AD authentication used or port used) from the host.
- Check for the sequence of processes created - powershell.exe -> csc.exe or cvtres.exe and file creation at the same time in AppData\Local\Temp.
- Look for EVENT ID = 4103 observed in burst with INVOKE-COMMAND executed from PowerShell.
Here is a GIF showcasing AD recon activity based on above detection logic for reference:
Post-exploitation Active Directory Reconnaissance using ADRecon.ps script is a common technique used by threat actors. Detecting and preventing such activities is critical to avoid any potential harm to the targeted network. Proper logging and implementing the detection logic as described above can aid in identifying these activities and taking prompt action to mitigate the risk of damage.
It is crucial to detect such activities to prevent any potential damage to the targeted network. Enabling proper logging and implementing the detection logic mentioned above can help detect such activities and take appropriate actions to prevent any potential damage.
- ADRecon Detection - DQL Cheat sheet
- Guidelines to build your own threat detection strategy
- Other articles related to ADRecon