Studying “BazarCall to Conti Ransomware via Trickbot and Cobalt Strike”: Part 3

Salim Salimov
10 min readApr 13, 2024

--

Investigating & Hunting in Sysmon Logs using
Elasticsearch and Kibana.

Please check out part1 and part 2 if you have not done yet.

Hello everyone , welcome back to the part 3 of this blog series.This time I will be looking at Sysmon event logs using Elasticsearch and Kibana.

Elasticsearch

is a versatile search and analytics engine known for its speed and scalability. It’s well-suited for handling large volumes of data across various applications. For more information, you can visit the official website: Elasticsearch Website.

Kibana

is the user-friendly web interface of Elasticsearch, assisting you in visualizing and exploring your data for easy understanding and analysis.

Installation and configuration

You can read and follow instructions on the official website.They provide free download and setup instructions here.

The Sysmon logs

I have extracted them from Kape VHDX disk images, By simply mounting them in my Windows VM.

In Windows 11 you can easily mount VHDX disc images by right click and mount option. So after mounting them all i have searched in file browser entire computer’s memory for Sysmon logs with typing following path in the search box :

Microsoft-Windows-Sysmon%4Operational.evtx

Then selected the the results from the mounted “Kape” drives only, copied and saved them to a new folder i named “sysmonlogs”.

Uploading the log files

To upload evtx files to Elasticsearch was not straightforward, but with some patience and bit of research i have figured how to do it. Here is in few steps how i did it for all of my readers who don’t know :

1. Downloading the winlogbeat.zip file.

Winlogbeat is a lightweight agent for Windows operating systems that monitors event logs and forwards them to Elasticsearch or Logstash for centralized logging and analysis.It is designed to automate on-time event log sending, but I have used it to upload previously saved log files with CMD command. See next steps below.

2. Extracting the zip to an easy to access location.

I have extracted to my Desktop.

3. Creating custom evtx.yml file.

  • Navigate to newly extracted “winlogbeat” folder with your file browser
  • Create new plain text document and name it something like this winlogbeat_evtx.yml (name can be anything but extension should be .yml)
  • open this file with any text editor or visual studio code and copy the following script inside:
winlogbeat.event_logs:
- name: "C:\\Users\\T11prox\\Desktop\\winlogbeat-8.13.0-windows-x86_64\\sysmonlogs\\DC1.evtx"
no_more_events: stop
- name: "C:\\Users\\T11prox\\Desktop\\winlogbeat-8.13.0-windows-x86_64\\sysmonlogs\\FS1.evtx"
no_more_events: stop
- name: "C:\\Users\\T11prox\\Desktop\\winlogbeat-8.13.0-windows-x86_64\\sysmonlogs\\SERV5.evtx"
no_more_events: stop
- name: "C:\\Users\\T11prox\\Desktop\\winlogbeat-8.13.0-windows-x86_64\\sysmonlogs\\WIN81.evtx"
no_more_events: stop
# Add more entries for additional EVTX files as needed

winlogbeat.shutdown_timeout: 30s
winlogbeat.registry_file: evtx-registry.yml

output.elasticsearch:
hosts: ['https://192.168.1.207:9200']
protocol: "https"
username: "elastic"
# password: 'xxxxxxxxxxxx'
ssl.verification_mode: none
  • adjust the script according to your needs like the number of files you uploading , correct path to the files and Elasticsearch host IP and port.

please note: use double slashes in the paths to the files according to Elasticsearch syntax rules. If NOT previously modified Elasticsearch.yml the hosts address should be hosts: [‘https://localhost:9200']

4. CMD Command

  • make sure you have Elasticsearch and Kibana running
  • open another instance of CMD and navigate to winlogbeat folder
  • execute following command :
.\winlogbeat.exe -e -c .\winlogbeat-evtx.yml -E output.elasticsearch.password="your_password_for_elastic_user"

If preferred password can be provided inside .yml file by UN-commenting the relevant entry, instead of the command line. Uploading logs may take some time to complete.

Investigating & Hunting in Sysmon Logs using
Elasticsearch

1.When successfully completed steps above data should be available for searching in Kibana UI, but to do so needs to be created a data view.

2.Lastly after changing the time range all should be set and ready to go.

Delving in and Exploring the logs

1.Once I was ready with configuring my tools and logs I have started investigating, and to begin I brought up my findings list from previous searches.

In part 2 blog i found out that velociraptor.exe and related events are most likely the the security team’s actions. Therefore I ignored them this time,thinking to come back to them later on and switched my focus on those TDR*.exe files.

2. I started with my first search query :

This query aims to identify if any malicious files or documents that tried to connect to suspicious domains or websites.

event.code:22 and winlog.event_data.Image:(*tdr*.exe)
  • Used asterisks to represent any path that files can be located in and as i have similarly named files I placed another asterisk where the in the filenames have different characters.
  • Event code 22 in sysmon logs is representing a DNS requests. All about Sysmon Event codes and what each number represents can be found on this official webpage here.
On the second screenshot here I have made a customized table view for this fields in Kibana

This domain “gmbfrom.com” and the IP address “88.80.147.101” are already in my suspicious findings list, so it was not a surprise to get to them again confirming the activities with different tools and logs. “Win81” and “10.10.100.22” are local machine domain and it’s local IP address.

Looked deeper into one of these events shows that a DNS query for the domain “gmbfrom.com” was made from the system. The query was successful, and the IP address “88.80.147.101” was returned. The process responsible for this query had a Process ID of 7416 and was associated with the image “tdr615.exe” located in the temporary directory of the user “H**********”.

3. To see list all websites, domains or IPs that has been contacted by this specific process given its PID, I have used the query below:

event.code:3 and winlog.event_data.ProcessId:7416

The Results brought up 45 events with same destination details which indicate that a network connection was detected from the system with the IP address “10.100.100.22” to the destination IP address “88.80.147.101” on port “443” over TCP. The process with ID “7416”, associated with the image “tdr615.exe”, initiated this connection. The user associated with this activity is “H**********” from the domain “lakestatebank”.

The rule name suggests that this event may be related to the masquerading technique (T1036), which involves disguising malicious activity as legitimate activity to bypass detection.

All these events indicate that they are part of local network discovery , beaconing and possibly malicious payloads communicating back to threat actors’ C2 center . To validate my theory i have continued to dig bit more into these events.

4. Went back to tdr*.exe files

This time i have searched and focused on their locations.I wanted to check if there was other processes running from same location.

  • Searching just for tdr*.exe got me 50108 events, where the very first one is file create event: wermgr.exe process with PID 748 created the file tdr5BDD.exe in the specified location.
  • The second log entry indicates the creation of a process named “tdr5BDD.exe”, launched by the “wermgr.exe” process.The process’s current working directory was “C:\Users\H**********\AppData\Roaming\TDir5LFNHX”.

5. Searching for *TDir5LFNHX .

From the results here I see other process create event from same current work directory :

esentutl.exe, ipconfig.exe, net.exe, nltest.exe under parent.image: svchost.exe, net1.exe under parent.image: net.exe

as well as

tdrE934.exe, tdr615.exe, tdr2269.exe, tdr3F89.exe, tdr5BDD.exe under parent.image: wermgr.exe

All The processes I found have been launched from the temp directory: “C:\Users\H**********\AppData\Roaming\TDir5LFNHX”, some of them are legitimate windows components, but they normally they should not run in unusual locations like this. Legitimate apps that are part of Windows OS very often can be abused by attackers to run their malicious codes and software. This website is a great place to check out such apps and what abilities they have.

However it is still possible Attackers to abuse some other apps that are not listed in here. For example i didn’t find any information about wermgr.exe but surely it has been involved in creation of a malicious files as we have seen above.

6. After few more searches

Tracing these processes and files I found that they are involved in DNS requests to several websites like “ident.me”, wtfismyip.com” to discover local IP address and other information of “Win81.lakestatebank.localand” and possibly other machines in the network too.

7.Finding other malicious IPs

As i remember from my previous searches in the MDE logs there was another malicious remote IP that has been connected many times. Searching for activities about external connection should show it up in Sysmon logs too. In Kibana I have looked into available fields similar to Splunk’s interesting fields in the left side panel clicked on “winlog.event_data.DestinationIp” then visualize.Also when I search for that IP from the result, looking in to “winlog.event_data.QueryName” field i found the domain name of this IP.

To make sure I can see all the events associated to this Ip and domain i have crafted this query :

winlog.event_data.DestinationIp : "149.248.52.187"  or winlog.event_data.QueryName: "onlineworkercz.com" 

By adding some more search arguments I observed DNS requests made to “onlineworkercz.com" from all 4 machines in the local network, initiated by “rundll32.exe and powershell.exe” resolved to the IP address 149.248.52.187. These requests are made with elevated privileges with “SYSTEM” username.

8.Rundll32.exe associated activities

To find activities i have crafted my next query like this:

rundll32.exe and winlog.event_data.CommandLine: (*) 
customized the view table for simplicity

Scrolling through the results I observed many malicious activities and collected more IOCs. To keep the article shorter i am not going in deep details here.

9.Powershell.exe associated activities

PowerShell is a powerful tool that can do a lot of things on a computer. It’s like finding out that someone has opened a toolbox in your house — it’s not necessarily bad, but you want to make sure they’re using it for the right reasons.

  • In part 2 I have looked at some powershell scripts and “Velociraptor.exe” app events which this time i want to exclude I have mentioned the reason earlier. I used this query in Kibana:
powershell.exe and winlog.event_data.CommandLine: (*encoded*) and not *velociraptor.exe

this search returned 4 process creation events from “Serv5.lakestatebank.local” machine that includes very interesting base64 code in the command line. To understand if this is malicious code or not i have tried to decode this base64 string using CyberChef and Base64decode.org websites. However it appeared that this string contains another base64 inside it which was bit more difficult to decode. That seems to be representing an archived file, I was not able to decode with these online tools. After some more research I have found another website Base64.guru that successfully decoded the inner base64 string and let me download the results in “.gz” format.

here, I have observed base64 inside base64
  • After I downloaded the .gz archive I have been able to see what is in it, and that was a PowerShell script that contains another Base64-encoded string embedded within it which appears to represent a binary file.
  • Finding hidden layers of Base64-encoded strings within PowerShell scripts is a strong indication of malicious intent. This technique is often used by cybercriminals to hide their actions from security measures. When combined with attempts to conceal the decoding process, such as burying encoded strings within one another or using archived files, it suggests a sophisticated attack strategy.
  • In simpler terms, these activities are like finding hidden compartments within a toolbox, indicating someone is trying to sneak something past security measures. This could involve attempts to plant harmful software or execute unauthorized commands on a computer system.

To be continued

A lot more still can be found in these logs, but I think I have discovered many malicious activities and collected quiet a bit IOCs so probably it is a good point to end to this blog here and continue my investigation with Digital forencics in my next one. Thanks to everyone for being here ,Hope you have enjoyed reading my article and also hope to see you on my next one.

--

--