Analyze Sysmon logs in Elastic SIEM to investigate REvil ransomware attack behaviors, decode recovery sabotage commands, and identify IOCs including the C2 onion domain.
You are a Threat Hunter working for a cybersecurity consulting firm. One of your clients has been recently affected by a ransomware attack that caused the encryption of multiple of their employees' machines. The affected users have reported encountering a ransom note on their desktop and a changed desktop background. You are tasked with using Splunk SIEM containing Sysmon event logs of one of the encrypted machines to extract as much information as possible.
Easy - Threat Hunting | Completion Achievement
We are given a Splunk instance with logs ready to be analyzed.
- To begin your investigation, can you identify the filename of the note that the ransomware left behind?
First, let's remember that Sysmon logs use the Event Code 11 to log file creation. Let's add event.code==11 and | table winlog.event_data.TargetFilename to our Splunk query to see which files were created inside our logs:
That's too many files... . Knowing that we are looking for a ransomware note, let's try using common words used in these types of files to find a match: HACK, NOTE, txtREADME...
That's our ransom note!
- After identifying the ransom note, the next step is to pinpoint the source. What's the process ID of the ransomware that's likely involved
Let's filter the events to display only those with the ransom note filename by adding the name of the file to the SPL query. To find the process ID, we need to look at the winlog.event_data.ProcessId field and see what is the process ID behind the creation of the ransom notes:
There's a single process ID, which corresponds to the process that created these ransom notes.
- Having determined the ransomware's process ID, the next logical step is to locate its origin. Where can we find the ransomware's executable file?
Looking at the raw logs with index=revil winlog.event_data.ProcessId=5348, we can find the path of the executable file responsible for this process ID by focusing in the winlog.event_data.Image field through | stats count by winlog.event_data.Image:
- Now that you've pinpointed the ransomware's executable location, let's dig deeper. It's a common tactic for ransomware to disrupt system recovery methods. Can you identify the command that was used for this purpose?
We can filter command execution by adding the string cmd or powershell to find any commands ran through these CLIs. Additionally, the field winlog.event_data.CommandLine should display the command that was executed inside the CLI. Let's look at the commands executed in powershell:
The first command is encoded in Base64, let's decode using From Base64 > Remove null bytes in CyberChef to find what the actual command was:
- As we trace the ransomware's steps, a deeper verification is needed. Can you provide the sha256 hash of the ransomware's executable to cross-check with known malicious signatures?
Sysmon often creates hashes of executables running commands. Using the index=revil winlog.event_data.Image="C:\\Users\\Administrator\\Downloads\\facebook assistant.exe" "event.code"=1 query and looking at the winlog.event_data.Hashes field will return the hashes corresponding to the malicious executable:
- One crucial piece remains: identifying the attacker's communication channel. Can you leverage threat intelligence and known Indicators of Compromise (IoCs) to pinpoint the ransomware author's onion domain?
After doing some OSINT research through VirusTotal, Any.run, and Malshare, I eventually found a more detailed report from tria.ge that showed the onion domain inside the ransom notes.
