Conti Ransomware Note

This article provides my approach for solving the TryHackMe room titled “Conti, created by heavenraiza. An Exchange server was compromised with ransomware and we must use Splunk to investigate how the attackers compromised the server. I have also provided a link to TryHackMe at the end for anyone interested in attempting this room.

Disclaimer

I like to add a brief disclaimer before a writeup to encourage people to attempt the CTF before reading this article, since there will obviously be spoilers in this writeup. I believe you will enjoy the CTF more if you attempt it yourself first and then come back to this writeup if you get stuck or need a hint. So without any further delay, lets get started!

Challenge Scenario

Some employees from your company reported that they can’t log into Outlook. The Exchange system admin also reported that he can’t log in to the Exchange Admin Center. After initial triage, they discovered some weird readme files settled on the Exchange server. Below is a copy of the ransomware note.Challenge Ransomware Note.You are assigned to investigate this situation. Use Splunk to answer the questions below regarding the Conti ransomware.

Initial Setup

I decided to start by going to “Settings → Indexes” after logging in to Splunk. Here, I can see the index being used is “main”, Splunk’s default index where all the processed data is stored.

Splunk Index

Next, I checked if Splunk could successfully access the ingested/loaded data. I changed the time range to “All time” and then, submitted the following search:

index=”main” earliest=0

I can see there are 28,145 events and I confirmed Splunk can successfully access the ingested/loaded data:

Overall Number of Events in Splunk.

Finally, I used the search below to identify all SourceTypes (i.e. data categories) in order of highest to lowest for number of events:

index=”main” earliest=0 | stats count by sourcetype | sort -countAvailable SourceTypes in Splunk

A source type determines how Splunk Enterprise formats the data during the indexing process. We can see that there are seven available event SourceTypes listed above:

“WinEventLog:Security”: Contain events related to Windows authentication and security processes.“WinEventLog:Application”: Contain events logged by various applications and/or user programs, including any errors or info that an application is deigned to report.“WinEventLog:System”: Contain events logged by various Windows system components.“iis”: contains data from Internet Information Services (IIS), web pages, and apps. It includes basic items such as IP and username, request date and time, service status and number of bytes received, as well as detailed items of target files.“WinEventLog:Mircrosoft-Windows-Sysmon/Operational”: commonly used add-on for Windows logging. With Sysmon logs, you can detect malicious activity by tracking code behavior and network traffic, as well as create detections based on the malicious activity.“WinEventLog:Setup”: contains Windows setup performance events.“misc_text”: contains miscellaneous text that does not match any predefined source types in Splunk.

Challenge Questions

1. Can you identify the location of the ransomware?

I started by using the SourceType Sysmon and identify what event codes were available under the field “EventCode”:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational”Sysmon Event ID’s.

You can learn more about Sysmon ID’s using the link below:

Sysmon – Windows Sysinternals

I can see Event ID 11 FileCreate, which is logged when a file is created or overwritten and can be useful to identify if any suspicious files were created. I used the search below to filter for this type of event:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” EventCode=11

Looking at the Interesting fields, we see under the Image field that the cmd.exe executable is stored in a strange location:

Location of the Ransomware.2. What is the Sysmon event ID for the related file creation event?

Refer to solution for question 1 above.

3. Can you find the MD5 hash of the ransomware?

To find the MD5 hash of the ransomware, I included the “Image” value seen in question 1 earlier and typed “md5” to identify any fields that have an MD5 hash value:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” Image=”c:\****\***\cmd.exe” md5

A single event is returned which contains the MD5 hash for the ransomware:

Ransomware MD5 Hash4. What file was saved to multiple folder locations?

Still working with Sysmon Event ID 11, I found an interesting field called “TargetFilename”. Using the search below, I was able to identify the same filename being stored in multiple locations:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” EventCode=11
| stats count by TargetFilenameFile saved to multiple folder locations.5. What was the command the attacker used to add a new user to the compromised system?

Performing a quick search online, we see that the windows net command is used to add users to a system:

net user username password /add

Using Sysmon, the field commandline could be used to filter for commands. I used a wildcard for the commandline field value in the search query to find any commands that contained “/add”:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” CommandLine=”*/add*”

Looking at the interesting fields, I could see under the “CommandLine” field the command used to add a new user to the compromised system:

Command used by the attacker to add a new user to the compromised system.6. The attacker migrated the process for better persistence. What is the migrated process image (executable), and what is the original process image (executable) when the attacker got on the system?

To answer this question, we can use Sysmon Event ID 8 Create Remote Thread, which detects when a process creates a thread in another process. This technique is used by malware to inject code and hide in other processes. I used the search below to filter for event ID 8:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” EventCode=8

Only two events are returned. I further refined my search to identify the source and target processes using the search query below:

index=main sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” EventCode=8
| table SourceImage, TargetImageMigrated process image (executable) and original process image (executable).

Looking at the image above, we see that powershell.exe was launched and then we’re migrated to unsecapp.exe.

7. The attacker also retrieved the system hashes. What is the process image used for getting the system hashes?

If we refer to the output from the search used in question 6 earlier above, we can see that a second process migration takes place between unsecapp.exe and lsass.exe:

Migrated process image (executable) and original process image (executable).

The Local Security Authority Subsystem (LSASS) is responsible for user authentication and generating access tokens specifying security policies and/or restrictions for the user and the processes spawned in the user session. This process is commonly attacked by hackers and malware. It is targeted to dump password hashes and is often used to hide in plain sight.

8. What is the web shell the exploit deployed to the system?

I found the following resource helpful for identifying web shells:

ThreatHunting/webshells.md at master · ThreatHuntingProject/ThreatHunting

To answer this question, I started by changing my SourceType from Sysmon to IIS events, since it collects events related to web pages. Next, I filtered IIS events for POST requests and common web shell file types (.php, .asp, .aspx, .jsp):

index=main sourcetype=iis cs_method=POST
| search *.php* OR *.asp* OR *.aspx* OR *.jsp*

Under the “cs_uri_stem” field, I can see a suspicious looking filename with a “.aspx” file extension:

Web Shell Exploit9. What is the command line that executed this web shell?

I changed my SourceType back to Sysmon and filtered for the .aspx web shell

index=main i3gfPctK1c2x.aspx sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational”

Under the CommandLine field, I can see the command used to execute the web shell:

Command Line used to execute webshell.10. What three CVEs did this exploit leverage?

This took me sometime to find but after searching for conti ransomware “CVE” list in the Google search engine, I found the following article which contains a number of CVE’s related to the Conti ransomware:

Is Conti Ransomware on a roll?

Closing Remarks

I really enjoyed working through this room and getting the opportunity to learn more about hunting for Conti ransomware using Splunk. Thank you for reading till the end and keep hacking ?!

TryHackMe | Cyber Security Training

Conti Ransomware— Threat Hunting with Splunk was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.