Practical Malware Analysis - Lab 14-1
While the executables in Practical Malware Analysis are considered safe, best practice will be used for the environment. The malware used in this lab can be found here: https://practicalmalwareanalysis.com/labs/
Virtual Machine Specifications:
Windows XP Service Pack 3 (32 Bit)
- HDD: 20 GB
- RAM: 2 GB
- Network: Host Only VM Network 1
- HDD: 35 GB
- RAM: 2GB
- Network: Host Only VM Network 1
The labs in Practical Malware Analysis were developed for study on Windows XP. The malware will be ran and Execute on the XP machine, however monitoring of networking traffic will take place on the Kali VM. Further details on the networking set up can be found in the Dynamic Analysis section of this report.
When running an analysis on Lab14-01.exe using PEiD, it was found that the executable had an entropy of 5.98 as seen in the image to the right. This means that the executable is not packed and no further steps will be required in order to continue static analysis.
Also seen to the right, the executable appears to be compiled with Microsoft Visual C++ 6.0.
Found below is the outputs when running strings on the executable file to see what sort of functions or strings the file contains. Note the images below are the output broken into 3 parts and the images can be clicked on to view them easier. Their analysis follows:
Strings Part 1:
Looking at the first part of the strings output, interesting strings included a full upper and lowercase alphabet. There were also strings relating to error reports, including one that mentions a DOMAIN ERROR. This could hint at potential networking activity. There was also a string R6028, but its significance is not known yet. Knowing the chapter focuses on network activity and encoding is an advantage as when seeing large strings of letters and numbers, it is likely encoding is occurring.
Strings Part 2:
In the second part of the output, a lot of strings seen before are recognized in Labs 11, 12, and 13. A lot of them have to do with the windows environment and interacting with it. Because of this, it is likely that the malware will interact with the windows environment and attempt to parse some information. What really stands out in the second output is the strings GetUserNameA and GetHWProfileA. These hint at some sort of credential usage by the malware. Also seen is APIADV32.dll and Kernel32.dll along with VirtualAlloc (Seen in part 3) which was seen creating memory space to inject .dll files into processes. Overall from output part 2, some of the internal inter-workings are seen. Finally, urlmon.dll is seen, which has not been encountered yet, but hints at the usage of connecting to urls / monitoring.
Output Part 3:
VirtualAlloc which was seen creating memory space to inject .dll files into processes in prior labs and shows up again in this strings output. With the various .dll files seen in the second part of the output, it is likely that the malware will either create a new process or inject itself into another. Seen in the 3rd output as well is a url. While it is known that the book being worked through is practical malware analysis, it should be noted in a real world encounter this would hint at where the malware may have came from or what its C&C server may be.
Overall strings relating to process injection, networking, as well as a url were found. With interesting strings including GetUserNamA, the strings hint at the malware attempting to grab credentials or information from the windows environment and then callback to a website. This speculation can be explored further by examining the executable in IDA Pro.
Opening the Lab14-01.exe into IDA resulted in some interesting results. The main function (Seen in the respective image above) shows data being pushed over and over into the register with a change in value following the previous line. Then, a formatting string follows. This is most likley some form of encoding taking place and should be noted. At the end of the the main function, sprintf is called.
Following the graphical view further, a loop can be seen with a sleep function. Seen in Loop & Call to Download above, the code is comparing some data before being sent off. Following this sub routine (sub_4011A3) the string that stood out in earlier analysis can be found as seen in the Sub_4011A3 image above.
Examining this subroutine more closely, it can be determined that the malware is pushing a url: http://practicalmalwareanalysis.com/ into a register and then calling the function found earlier URLDownloadToCacheFileA.
Overall, from the basic strings analysis and IDA disassembly, it is likley that the malware is using some form of encoding, likley a modified version of Base 64, as well as reaching out to download an executable from the internet.
As mentioned above, the VMs are on a host only network. This allows the Windows XP virtual machine to be pointed to the Kali virtual machine to think it is its gateway. This allows for INetSim to be ran and intercept all web traffic.
Using INetSim with Wireshark running on the Kali VM will safely intercept any malware web traffic when starting the dynamic analysis. The images to the right show the networking setup for both the Windows XP and Kali VMs and shows INetSim running (IE Test Window).
When the dynamic analysis was ready to begin, a Wireshark capture was started.
Execution of the Malware
Upon running the malware by double clicking on the executable, a blank command prompt window opened (As seen in the image to the left). This window stayed open the entire time that the malware was running. It is likely that the loops seen previously in IDA do not terminate the command prompt window even if waiting.
The window staying open as well as the malware simply running as its own process (See 'Task Manager') when checking Task Manager show that there is no attempt by the malware to hide itself.
Turning attention to the the Wireshark capture performed on the Kali VM while the execution took place yielded some interesting results. To filter for any web traffic coming from the Windows XP machine, a search for HTTP was done. (Note: since the network was a local one consisting of only the two VMs, there was very little traffic to actually dig through).
For the duration of the malware being run, 4 different HTTP packets were intercepted as seen in the image below:
Upon opening these packets and following the full TCP stream as seen in the image to the right, an encoded string is seen calling for a .png type file. The malware is attempting to pull an image from the website http://practicalmalwareanalysis.com.
This confirms the suspicion of the malware attempting to reach out to the website seen in the static analysis and hows how the encoding seen in the static analysis is being used.
When exploring the other packets, they are repeats of the same request. This is likley the loop seen earlier in IDA. The malware reaches out to the website and attempts to download, since it cannot (traffic is hitting INetSim not the PMA related website) it tries again after a set interval.
Seen in this lab are the functions and artifacts used by malware that seeks to communicate out to the internet. Finding strings and tell tale functions in IDA, a estimate of the malwares intent to reach out to download more files was established. After dynamic analysis, it is now known and confirmed that the malware reaches out to a website to download a file. While doing so, the malware uses no obfuscation techniques nor any injections / hooking.
This lab in Practical Malware Analysis does a great job at showing both how encoding takes place as well as how networking is used by malware. It offers a great opportunity to employ a small virtual network to expand dynamic analysis beyond one virtual machine as well.