Splunk BOTS v1: Following an Attack from Reconnaissance to Cerber Ransomware.

I recently worked through the Splunk Boss of the SOC (BOTS) v1 dataset as a practical way of testing my investigation skills across different types of security telemetry.

Rather than treating it as a list of questions to answer, I tried to approach it the same way I would approach an investigation — start with what I know, follow the evidence, and use each finding to decide where to look next.

The investigation took me across Sysmon, Windows Security events, Suricata, SMB traffic, Registry data and other log sources, with Splunk and SPL being the main tools I used to work through the data.

I ended up documenting 30 findings, starting with web reconnaissance and attacker infrastructure before moving into credential attacks, malware activity and eventually Cerber ransomware.

This write-up covers the main parts of the attack and how I worked through them.

Question 1: What is the likely IP address of someone from the Po1s0n1vy group scanning imreallynotbatman.com for web application vulnerabilities?

I started by looking at the web traffic hitting the Wayne Enterprises website. Since I was looking for vulnerability scanning, I wanted to see which external source was generating suspicious activity against the web server.

After reviewing the traffic and comparing the source IPs, one address stood out with the scanning activity:

40.80.148.42

This gave me my first indicator and something I could use as a pivot for the next part of the investigation.

Answer: 40.80.148.42

Question 2: What company created the web vulnerability scanner used by Po1s0n1vy? Type the company name. (For example "Microsoft" or "Oracle")

After identifying 40.80.148.42 as the IP responsible for the scanning activity, I used that IP as my next pivot instead of starting a completely new search.

I narrowed the web traffic down to requests coming from that address and looked at the HTTP user-agent information to see if it could tell me what tool was generating the requests.

The user-agent information pointed to Acunetix, identifying the vulnerability scanner being used against the website.

Answer: Acunetix

Question 3: What content management system is imreallynotbatman.com likely using?(Please do not include punctuation such as . , ! ? in your answer. We are looking for alpha characters only.)

After identifying Acunetix as the scanner, I continued looking through the web traffic to understand more about the website being targeted.

I searched the HTTP requests for paths and files that could reveal the technology running behind the site. The traffic contained several requests associated with Joomla, which gave me a clear indication of the CMS in use.

This was useful because identifying the technology being targeted gives more context around what the attacker may have been scanning for or trying to exploit.

Answer: Joomla

Question 4: What is the name of the file that defaced the imreallynotbatman.com website? Please submit only the name of the file with extension (For example "notepad.exe" or "favicon.ico")

After identifying Joomla as the CMS, I continued following the web activity to see whether the attacker had moved beyond scanning and actually made changes to the website.

I looked through the HTTP traffic for suspicious file activity and found a JPEG file with a very unusual name being uploaded to the server.

The filename was poisonivy-is-coming-for-you-batman.jpeg.

At this point, the activity was no longer just reconnaissance. The uploaded defacement file gave me evidence that the attacker had successfully interacted with the website.

Answer: poisonivy-is-coming-for-you-batman.jpeg

Question 5: This attack used dynamic DNS to resolve to the malicious IP. What fully qualified domain name (FQDN) is associated with this attack?

After identifying the website compromise, I continued following the attacker's infrastructure to see what other systems or domains were connected to the activity.

I looked through the network traffic for DNS activity associated with the attacker and found a hostname using the jumpingcrab.com dynamic DNS service.

The FQDN was prankglassinebracket.jumpingcrab.com.

This gave me another indicator that I could use to continue following the attacker's infrastructure.

Answer: prankglassinebracket.jumpingcrab.com

Question 6: What IP address has Po1s0n1vy tied to domains that are pre-staged to attack Wayne Enterprises?

After identifying the dynamic DNS domain, I continued following the infrastructure connected to the attacker.

I used the information I had already found as a pivot and looked further into the network activity to identify the IP address behind the infrastructure.

This led me to 23.22.63.114.

I kept this IP as an indicator because it could be useful when checking other parts of the attack, and it later appeared again during the investigation.

Answer: 23.22.63.114

Question 7: Based on the data gathered from this attack and common open source intelligence sources for domain names, what is the email address that is most likely associated with Po1s0n1vy APT group?

After identifying some of the infrastructure connected to the attacker, the next part of the investigation involved finding information that could be associated with the person behind the activity.

I followed the available information around the po1s0n1vy identity and found an email address associated with it:

lillian.rose@po1s0n1vy.com

This added another indicator to the information I had already collected about the attacker.

Answer: lillian.rose@po1s0n1vy.com

Question 8: What IP address is likely attempting a brute force password attack against imreallynotbatman.com?

This was where an indicator from earlier in the investigation became useful again.

While looking through the brute-force activity, I found that the login attempts were coming from 23.22.63.114 — the same IP I had already identified while investigating the attacker's infrastructure.

Seeing the same IP appear across different stages helped connect the brute-force attempts back to the activity I had already been following.

Answer: 23.22.63.114

Question 9 : What is the name of the executable uploaded by Po1s0n1vy? Please include file extension. (For example, "notepad.exe" or "favicon.ico")

After confirming the brute-force activity, I continued following the attack to see what the attacker did after gaining access.

Looking through the file activity, I found an executable named 3791.exe being uploaded.

This was an important finding because I now had a specific file that I could use as a pivot to investigate the malware further, including identifying its hash and checking its reputation.

Answer: 3791.exe

Question 10: What is the MD5 hash of the executable uploaded?

After identifying 3791.exe as the executable uploaded by the attacker, I used the filename as my next pivot to investigate the file further.

From the available event data, I was able to identify the MD5 hash associated with the executable:

AAE3F5A29935E6ABCC2C2754D12A9AF0

Having the hash gave me a stronger indicator than the filename alone and something I could use for further malware analysis and threat intelligence checks.

Answer: AAE3F5A29935E6ABCC2C2754D12A9AF0

Question 11: GCPD reported that common TTPs (Tactics, Techniques, Procedures) for the Po1s0n1vy APT group, if initial compromise fails, is to send a spear phishing email with custom malware attached to their intended target. This malware is usually connected to Po1s0n1vys initial attack infrastructure. Using research techniques, provide the SHA256 hash of this malware.

For this part of the investigation, I had to move beyond the information available directly in Splunk and use OSINT to investigate the malware further.

Using the indicators I had collected, I was able to identify the malware and obtain its SHA256 hash:

9709473ab351387aab9e816eff3910b9f28a7a70202e250ed46dba8f820f34a8

This was a useful example of using SIEM findings as a starting point and then using external threat intelligence to add more context to the investigation.

Answer: 9709473ab351387aab9e816eff3910b9f28a7a70202e250ed46dba8f820f34a8

Question 12: What special hex code is associated with the customized malware discussed in question 111? (Hint: It's not in Splunk)

After identifying the malware in the previous investigation, I continued the OSINT investigation using VirusTotal.

Looking through the information associated with the malware, I found a hexadecimal string in the VirusTotal community comments.

The hex code was:

53 74 65 76 65 20 42 72 61 6e 74 27 73 20 42 65 61 72 64 20 69 73 20 61 20 70 6f 77 65 72 66 75 6c 20 74 68 69 6e 67 2e 20 46 69 6e 64 20 74 68 69 73 20 6d 65 73 73 61 67 65 20 61 6e 64 20 61 73 6b 20 68 69 6d 20 74 6f 20 62 75 79 20 79 6f 75 20 61 20 62 65 65 72 21 21 21

Question 13: One of Po1s0n1vy's staged domains has some disjointed "unique" whois information. Concatenate the two codes together and submit as a single answer.

For this question, the answer wasn't in Splunk, so I had to use OSINT and WHOIS information connected to the attacker's infrastructure.

I investigated domains associated with the IP address I had already identified and eventually found unusual WHOIS information for waynecorinc.com.

Two fields contained hexadecimal values instead of normal text. I combined both values into one string as required by the question.

Answer: 31 73 74 32 66 69 6E 64 67 65 74 73 66 72 65 65 62 65 65 72 66 72 6F 6D 72 79 61 6E 66 69 6E 64 68 69 6D 74 6F 67 65 74

Question 14: What was the first brute force password used?

I returned to the brute-force activity from 23.22.63.114 and focused on the HTTP POST requests targeting the Joomla administrator login page.

I reviewed the login attempts in chronological order and checked the submitted form data to identify the first password attempted by the attacker.

The first password used was:

12345678

Answer: 12345678

Question 15: One of the passwords in the brute force attack is James Brodsky's favorite Coldplay song. Hint: we are looking for a six character word on this one. Which is it?

After identifying the first password used in the brute-force attack, I continued analysing the attempted passwords.

This question required correlating the password attempts with the clue about a six-character Coldplay song. Reviewing the attempted values revealed a match:

yellow

Answer: yellow

Question 16: What was the correct password for admin access to the content management system running "imreallynotbatman.com"?

After reviewing the passwords used during the brute-force attack, I needed to determine which one actually provided access to the Joomla administrator account.

I compared the authentication activity and found that one password appeared again outside the normal sequence of failed brute-force attempts, indicating that the attacker had identified and used the valid credential.

The correct administrator password was:

batman

Answer: batman

Question 17: How many seconds elapsed between the time the brute force password scan identified the correct password and the compromised login? Round to 2 decimal places.

After identifying the passwords involved in the brute-force attack, I calculated the length of each attempted password and then calculated the average across the attempts.

The raw average from my investigation was approximately 6.17, which rounds to:

6

Answer: 6

Question 18: How many unique passwords were attempted in the brute force attempt?

After calculating the average password length in the previous step, I stayed with the same brute-force activity and looked at the password values themselves.

I counted the distinct passwords attempted by the attacker rather than the total number of login attempts.

The investigation showed:

412

Answer: 412

Question19: What was the most likely IP address of we8105desk on 24AUG2016?

After the brute-force section, the investigation moved into the ransomware activity affecting the internal workstation we8105desk.

I reviewed the Sysmon network activity for that host and focused on the source IP associated with its outbound connections. The same address appeared consistently across the events, identifying the workstation as:

192.168.250.100

Answer: 192.168.250.100

Question 20: Amongst the Suricata signatures that detected the Cerber malware, which one alerted the fewest number of times? Submit ONLY the signature ID value as the answer. (No punctuation, just 7 integers.)

I moved into the Suricata network alerts associated with the Cerber ransomware activity and compared the signature IDs by the number of times each one appeared.

After identifying the Cerber-related signature with the lowest alert count, the corresponding signature ID was:

2816763

Answer: 2816763

Question 21: What fully qualified domain name (FQDN) does the Cerber ransomware attempt to direct the user to at the end of its encryption phase?

After identifying the Cerber-related Suricata activity, I continued following the network indicators to determine which domain was associated with the ransomware infrastructure.

Reviewing the Cerber network activity revealed the following FQDN:

cerberhhyed5frqa.xmfir0.win

Answer: cerberhhyed5frqa.xmfir0.win

Question 22: What was the first suspicious domain visited by we8105desk on 24AUG2016?

I continued following the Cerber activity from we8105desk and reviewed the network events chronologically to identify the earliest suspicious domain contacted during the infection chain.

The first suspicious domain observed was:

solidaritedeproximite.org

Answer: solidaritedeproximite.org

Question23: During the initial Cerber infection a VB script is run. The entire script from this execution, pre-pended by the name of the launching .exe, can be found in a field in Splunk. What is the length in characters of the value of this field?

I moved from the network activity into the Sysmon process events on we8105desk to investigate what was executed on the endpoint.

I focused on the VBScript-related process activity and examined the associated command line. The suspicious command was heavily obfuscated and significantly longer than normal command-line activity.

After calculating the length of the full command line, the result was:

4490

Answer: 4490

Question 24: What is the name of the USB key inserted by Bob Smith?

I investigated the Windows Registry activity on we8105desk to identify evidence of removable USB devices connected to the workstation.

By narrowing the registry events to USB storage entries and reviewing the device FriendlyName information, I identified the connected USB device as:

MIRANDA_PRI

Answer: MIRANDA_PRI

Question 25: Bob Smith's workstation (we8105desk) was connected to a file server during the ransomware outbreak. What is the IP address of the file server?

I continued investigating activity from the infected workstation we8105desk and moved into the SMB traffic to understand which internal systems it was communicating with.

I compared the destination IP addresses contacted by 192.168.250.100 over SMB. One destination accounted for the majority of the SMB activity, identifying the internal file server as:

192.168.250.20

Answer: 192.168.250.20

Question 26: How many distinct PDFs did the ransomware encrypt on the remote file server?

I continued investigating the impact of the Cerber infection and focused on file activity involving PDF documents.

Using the Windows Security events, I isolated .pdf files accessed from the infected workstation 192.168.250.100 and counted the distinct file names rather than the total number of events.

This showed that Cerber affected:

257 distinct PDF files.

Answer: 257

Question27: The VBscript found in question 204 launches 121214.tmp. What is the ParentProcessId of this initial launch?

I continued tracing the Cerber execution chain on we8105desk using Sysmon process creation events.

Rather than relying on the earliest event containing 121214.tmp, I traced the execution back to the event where the malicious VBScript 20429.vbs launched the command responsible for starting 121214.tmp.

That process had the Parent Process ID:

3968

Answer: 3968

Question 28: The Cerber ransomware encrypts files located in Bob Smith's Windows profile. How many .txt files does it encrypt?

I continued the investigation by focusing on the file activity generated during the Cerber ransomware attack.

I first searched for .txt files to identify Bob Smith's Windows profile path. After identifying the profile directory, I narrowed the search to .txt files within that specific path and counted the distinct filenames.

The result showed that Cerber encrypted 406 .txt files in Bob Smith's Windows profile.

Answer: 406

Question 29: The malware downloads a file that contains the Cerber ransomware cryptor code. What is the name of that file?

I already had the infected host IP address, 192.168.250.100, and the suspicious domain identified earlier, solidaritedeproximite.org.

I used those indicators to investigate the HTTP traffic generated by the infected workstation and looked specifically for files being downloaded from the suspicious domain.

The HTTP request showed a GET request for:

/mhtr.jpg

I then researched the filename outside Splunk to verify that it was associated with the Cerber ransomware cryptor rather than treating the filename alone as proof.

Answer: mhtr.jpg

Question 30: Now that you know the name of the ransomware's encryptor file, what obfuscation technique does it likely use?

After identifying mhtr.jpg as the file containing the Cerber ransomware cryptor code, I needed to understand why the attacker would use a .jpg extension for what was actually malicious content.

I researched the file and the Cerber infection technique using OSINT outside Splunk. The use of an image file to conceal malicious code points to steganography, where data is hidden inside another file or media type.

This also explains why the encryptor was presented as a .jpg file rather than an obvious executable.

Answer: steganography

Conclusion

This investigation involved tracing a multi-stage attack against Wayne Enterprises, starting with web reconnaissance and progressing through website compromise, brute-force activity, malicious file uploads and ultimately Cerber ransomware activity.

I used Splunk to correlate activity across different sources, pivot between IP addresses, domains, files and other indicators, and build a clearer picture of how the attack developed. Where additional context was required, I used OSINT and malware research to validate findings and investigate indicators that were not immediately available within the SIEM data.

The investigation covered several areas that are important in day-to-day SOC operations, including SPL-based investigation, log correlation, IOC enrichment, endpoint and network analysis, threat intelligence and incident investigation.

I have documented the full investigation, including the queries, findings and supporting evidence, in the GitHub repository below.

Sodiq Muftau SOC Analyst | Security Operations | Incident Response | Threat Intelligence

GitHub: Adisasoc LinkedIn: Sodiq Muftau