LMG Network Forensics Puzzle #5
09 Sep 2018

After completing school and a few certifications, I finally have time to devote to research and learning what I want to learn, not constrained to school. The above puzzle may be pretty old, but I love a good network analysis challenge, and I wouldn’t dare pass up an opportunity to play with some malware.
After reading through the scenario, we are tasked with answering seven questions:
- As part of the infection process, Ms. Moneymany’s browser downloaded two Java applets. What were the names of the two .jar files that implemented these applets?
2. What was Ms. Moneymany’s username on the infected Windows system?
3. What was the starting URL of this incident? In other words, on which URL did Ms. Moneymany probably click?
4. As part of the infection, a malicious Windows executable file was downloaded onto Ms. Moneymany’s system. What was the file’s MD5 hash? Hint: It ends on “91ed”.
5. What is the name of the packer used to protect the malicious Windows executable? Hint: This is one of the most popular freely-available packers seen in “mainstream” malware.
6. What is the MD5 hash of the unpacked version of the malicious Windows executable file?
7. The malicious executable attempts to connect to an Internet host using an IP address which is hard-coded into it (there was no DNS lookup). What is the IP address of that Internet host?
For this puzzle, I will be utilizing Wireshark, NetworkMiner, and IDA Pro, along with a few command line commands. My approach to this may be a little different, but that is what makes things interesting.
I will use Wireshark to answer a few of the questions, although I understand NetworkMiner has them readily available for me. This servers two purposes, 1) I can strengthen my Wireshark filter command muscles, and 2) I may not always have NetworkMiner available to me.
Enough rambling, let’s dig into the puzzle pcap with Wireshark. It would be easy to export both jar files that are suspected of causing the infection, however I am more comfortable identifying the IP address, host name, and client that we are dealing with.

I was able to locate the host name filtering for the NetBIOS name service. We now have a host name of TICKLAB and IP address of 192[.]168[.]23[.]129.
Moving onto identifying the username, I was not able to find any sign of Kerberos or LDAP in use, so moving to NetworkMiner gives us some interesting information.

Under the “Parameters” tab, we can see the guid of “ADMINISTRATOR!TICKLABS. This string will prove important in just a few. We now have question two answered, so we can work back and knock out the first question.
Navigating to File > Export Objects > HTML in Wireshark gives us a long list of files we can save and peruse.

Now on question three, we need to find what started this whole mess. Simply filtering for HTTP in Wireshark, we can start to work through the requests and see the first URL the victim visited.

The suspect page in this case is /true.php, with the URL being http[.]//nrtjo[.]eu/true[.]php at 59[.]53[.]91[.]102. With a good certainty, we can identify this as the beginning of the infection. Moving to question four.
Back in NetworkMiner, the Files tab so graciously has the Windows executable listed for us and includes a MD5 hash of the file.

Without having to do research, we can take a wild guess and say that UPX is most likely the program that packed the malicious executable.

Packed malware is no fun to play with, so the next question wants us to unpack the executable and get another MD5 hash. Using UPX, we can decompress the file and get the hash.

For kicks we can look at the sizes of the two files in the terminal. Note*** These are the same files for the challenge, I just switched over to my Kali VM for analysis.

Hopefully I haven’t lost you and you remember the admin string from earlier. Our next question asks us about a hardcoded IP address that connects after the infection.
Again in Wireshark, we can easily find the suspicious IP address (that communicates on ports 444 & 80).

The IP address 212[.]252[.]32[.]20 connects over port 444 and 80 after the initial infection. The connection over port 80 errors out, however port 444 communicates with our malicious URL. It appears that this hard-coded IP address may be a C2 as we can see in the picture above it sends back a wealth of information (user & host names (remember this?), the version of the malicious software, a familiar md5, etc. ).

It appears the victim visited the above site, which downloaded two malicious Java applets: sdfg.jar & q.jar. The two jar files downloaded and executed the malicious executable.
Since it wouldn’t be any fun having a malware sample and not looking at a little bit further, lets do just a bit more analysis. Before we fire up IDA, lets see if we can find any obfuscated strings in the unpacked executable.

While strings.exe is a great tool to use for static analysis of malware, it would not have been able to find and decode the above stack strings. I usually use FireEye’s FLOSS tool for my string needs. Not only do we see an additional executable that were weren’t previously aware of, but we also have a number of dll’s and system paths.
After fumbling around in IDA for what seemed like forever, I have found a few of the above dll’s:

These libraries are hard-coded into the program accompanied by a number of switch statements and mov instructions. We can move on from here and keep snooping.

The above string I first thought was a mutex, is most likely a password of some kind. After wiping my eyes for the thousandth time, I broke down and started searching for other instances where the string appeared.
The malicious executable appears to be a SpyEye trojan virus. Furthermore, it appears once the executable is run on the target system, the file nestles in the system path as cleansweep.exe and uses some hooking to establish persistence.
Overall, this puzzle wasn’t too challenging but was a good refresher in malware analysis. As long as I learned something (and hopefully you as well), it’s all good.
Until the next time!
