Here at Reynholm Industries we pride ourselves on everything. It’s not easy to admit, but recently one of our most valuable servers was breached. We don’t believe in host monitoring so all we have is a network packet capture. We need you to investigate and determine what data was extracted from the server, if any.
The challenge provides only a captured network traffic, of a malicious attack, and asks to investigate what data was stolen from the server of the Reynholm Industries. The flag it’s inside these data.
The network traffic has captured an exploit of CVE-2017-7269, this vulnerability exploits a buffer overflow present in the WebDAV service in Internet Information Services (IIS) 6.0 in Microsoft Windows Server 2003. This CVE allows remote attackers to execute arbitrary code via a long header beginning with “
If: <http://” in a PROPFIND request.
In the network traffic captured there are a lot of HTTP requests, against a Microsoft IIS 6.0 server, each one differs only on the length of padding until it guesses the correct one that will start the ROP chain that will lead to an RCE.
The code to be executed is inside the request and it is encoded in an alphanumeric string, created using the Metasploit encoder ‘AlphanumUnicodeMixed’. Metasploit alphanumeric payloads have an initial decoder STUB that will decode the rest of the payload.
If the attack goes well then the server will establish a new connection to the attacker’s port 4444, followed by another one on port 1337.
The new connections established with the server seem to be encrypted in some way, so to see what’s inside that communication first it is needed to understand what all those requests do.
Starting to debug the first payload it can be seen that it loads functions library by using a technique that consists of calculating a sort of hash code of the dll names, if one match with the one it is searching for then it continues with the same technique for each function inside that library. Once it found the right function then it saves its pointer, ready to be used during the rest of the execution.
By using the functions loaded, it will open a connection to the IP 192.168.68.21 on port 4444, there it will wait to receive any data. Arrived at this point I decided to change the IP of my virtual machine to 192.168.68.21, using a python script to wait for the connection and sends back the same bytes extracted from the captured connection that the server has received at the same time. Once send those bytes my python script will wait for a connection at port 1337.
from pwn import * import libnum EXTRACTED_RESPONSE = "\x9c\x5c\x4f\x52..." l = listen(4444) l2 = listen(1337) l.wait_for_connection() print() raw_input("received a connection on 4444! press a key to continue...") print("continuing...") l.send(EXTRACTED_RESPONSE) l2.wait_for_connection() s = l.recv(10) # receive some bytes print("l ", s)
The bytes received will be stored in a VirtualAlloced area, decrypted, and then continued the execution into it.
Inside this second payload, it will use the same technique used before to load some function that will use for this last part. The functions are for example “CreateFile”, “ReadFile” and other functions useful to establish socket connections.
The CreateFile function will be used to access the file “C:\accounts.txt”, then it will read the content, encrypt it by xoring with a generated key and finally sends the content to port 1337 of the attacker. By debugging this part the xoring key could be dumped and used to retrieve back the original file send xored and captured in the network traffic!
roy:email@example.com:goat moss:Pot-Pocket-Pigeon-Hunt-8:narwhal jen:Straighten-Effective-Gift-Pity-1:bunny richmond:Inventor-Hut-Autumn-Tray-6:bird denholm:123:dog