TryHackMe — ItsyBitsy Challenge Walkthrough
Incident Response Challenge using the Elastic Stack
Introduction:
Welcome to my weekly walkthrough!
Are you curious about investigating incidents using the Elastic (ELK) stack? Well you're in luck — we’re about to tackle the ItsyBitsy challenge from TryHackMe!
ItsyBitsy is a DFIR challenge where we will analyze the HTTP network connection logs captured from a device. The not great news is that this device was making some suspicious network calls to a potential command and control server. To figure out what happened, we’ll use the Kibana module within the Elastic Stack to search the through logs, visualize the data, and determine what was downloaded.
But first, a high-level infographic of where Kibana fits into the Elastic Stack:
Want more? Go check out the full Investigating with ELK 101 room on TryHackMe which covers the ELK stack fundamentals in much more detail.
So, whether you’re here to learn more about investigating with Elastic, or are just looking for a reference walkthrough for the ItsyBitsy challenge, you’ve stumbled on the right blog. In the spirit of learning, I am not going to be revealing any flags in this write-up, so I encourage you to go hands-on and try it for yourself — you got this!
Now let’s put on our detective hats and have some fun with forensics!
Thanks for reading along!
Challenge Link: https://tryhackme.com/r/room/itsybitsy
Challenge Scenario:
During normal SOC monitoring, Analyst John observed an alert on an IDS solution indicating a potential C2 communication from a user Browne from the HR department. A suspicious file was accessed containing a malicious pattern THM:{ ________ }. A week-long HTTP connection logs have been pulled to investigate. Due to limited resources, only the connection logs could be pulled out and are ingested into the
connection_logsindex in Kibana.Our task in this room will be to examine the network connection logs of this user, find the link and the content of the file, and answer the questions.
Question 1: How many events were returned for the month of March 2022?
First things first, we’ll enter the Elastic web console and then navigate to the Kibana > Discover Analytics module. Kibana is used to search logs and visualize them, so using the Discover module will enable us to query and explore the provided network connection_logs index.
To access the Discover tab, we can either input “discover” into the search box at the top of the dashboard or use the menu on the left-hand sidebar.
For Question 1, our objective is to narrow the search scope to a single month. To do this, we will need to adjust the time filter so that we can focus only on the events that occurred in March of 2022. Let’s modify the dates in the time selection field.
We’ll filter the first date/time to Absolute and set the start date to March 1, 2022, at 0:00 and then the end date to March 31, 2022, at 23:30. This selection should give us the entire month of March 2022.
Once we apply the date/time filter, we’ll see our results displayed as a total number of hits and now we have some data to analyze and the answer to Question 1.
Question 2: What is the IP associated with the suspected user in the logs?
Since we have so many log entries, we’ll want to filter this to a manageable level. To do this, let’s check out the source_ip field filter which will help us to determine how many source hosts we have captured in our logs.
On the fly-out menu, we will have some analytics about the top 5 values that appear in the logs. Fortunately for us, there are only two entries.
One IP accounts for 99.6% of the traffic, and the second only accounts for 0.4%.
Before we go too crazy wading through a massive number of records, let’s check the IP address with the fewest number of hits by adding the source IP to the filter. I searched it manually in the query box, but you can also simply hit the + next to the value to add it to the filter.
This IP address only has two logged events which makes it a bit easier for us to analyze. Right away, there are a few suspicious indicators but let’s do some reconnaissance on the destination IP address to see if we can locate any intelligence.
We’ll start with VirusTotal to get an overview and see if there are any hits for malicious activity associated with this IP address:
Interestingly, there are no hits for malware, however the banner shows that there are “10+ detected files communicating with this IP address” — that’s odd, let’s take a closer look at that.
The files communicating with this domain seem to have a high number of hits for malicious activity. This is giving us some confidence that we have found the host IP address of the infected user. But let’s double-check with another service as well, Hybrid Analysis.
Hybrid Analysis also assesses that this IP has been associated with some malicious activity. So, would have enough information to say that we found the correct local IP address for the victim. Let’s enter our answer to check our work.
Question 3: The user’s machine used a legit windows binary to download a file from the C2 server. What is the name of the binary?
Now that we know the victim’s local IP address and have an idea of what IP address the infected device was communicating with for command and control (C2), we need to determine what application or service was being used for the connection. Let’s focus on the user_agent field to answer Question 3.
If you aren’t familiar, user-agents are request headers that servers use to identify requesting client details like the operating system, web browser version, or application.
In this log, we have an unusual user_agent that isn’t something typical like a web browser, for example. This indicates that the malware might be living off the land and using a legitimate Microsoft command-line tool.
I don’t want to spoil the fun but if we do a little research about this user agent, we’ll stumble on some helpful information from Microsoft Learn — this particular tool can be leveraged to:
create, download or upload jobs, and to monitor their progress.
In other words, this information confirms that this utility can be used to download files. Let’s submit our findings and move on to the next question.
Question 4: The infected machine connected with a famous filesharing site in this period, which also acts as a C2 server used by the malware authors to communicate. What is the name of the filesharing site?
In Question 2, we found evidence that the victim’s device communicated with a destination IP address that resolves to a web-based file sharing service. According to MITRE ATT&CK (T1102), this site has been used for command and control by some threat actors and malware families.
Let’s confirm that our IP intelligence is correct by looking at the host field.
Since the host matches the intelligence that we found about the IP address, we have our answer.
Question 5: What is the full URL of the C2 to which the infected host is connected?
Okay, to answer Question 5, we have the simple task of combining the host domain from Question 4 with the uri field of the event. This will form the hostname/path combination of the URL that we are looking for to answer this question!
Questions 6 & 7:
A file was accessed on the filesharing site. What is the name of the file accessed?
The file contains a secret code with the format THM{_____}.
All right, we made it to the last two questions! So far, we have determined the IP address, application, domain, and URL that the victim’s infected device accessed. The last step for this challenge is to determine the name and content of the file hosted on this file sharing site.
Unfortunately, the connection_logs index does not seem to contain any of the file data that we are looking for, so we have to pivot. What if we navigate to the URL that we assembled in Question 5 to view the public site directly?
Once there, it looks like our research paid off! We found both the file that was accessed and can view the contents. Let’s submit our answers and wrap up this investigation!
Conclusion:
Hey, nice job with the investigation! We successfully completed the listed objectives and analyzed the HTTP connection log file, found the required evidence, and have an understanding of the payload to complete the ItsyBitsy challenge! It’s time to close the case.
A big thank you to TryHackMe for hosting this awesome challenge! I haven’t had an opportunity to jump into Elastic so this was a fantastic challenge to learn about the tool and get a high-level overview of how it can be leveraged to analyze large data sets and apply that to incident response. While I’m sure this barely scratches the surface of what the tool is capable of, I gained plenty of valuable hands-on experience with Kibana and am looking forward to the next time I’ll get to practice with Elastic!
I hope that you had as much fun as I did and learned something new, too!
Thank you so much for reading along and working through this investigation with me. Until next week — stay curious!
Tools & References:
VirusTotal: https://www.virustotal.com/
Hybrid Analysis: https://www.hybrid-analysis.com/
MITRE ATT&CK — Command and Control: https://attack.mitre.org/tactics/TA0011/
Mozilla Developer (User Agent): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
Microsoft bitsadmin: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin
MITRE ATT&CK — Web Service: https://attack.mitre.org/techniques/T1102/
