cdbee59f8144be30634bf4994d51e1a0 — A Beginner‘s Malware Diary 2
If you are someone who suddenly jumps into this jungle, here is a time tunnel to the previous article.
After finishing simple static analysis, we have to do further analysis to see how the program actually works and what behaviors make it malicious.
Environment Setup
Before we actually conduct the dynamic analysis, several things have to be done beforehand. First of all, we have to assure the virtual machine is unable to connect with Internet by host network card. Otherwise, the virus may cause infection to other hosts who are in the same LAN.
In my case, I use VMware Fusion as the virtualization platform and the methods of settings on different platforms are varied.
Let’s go to the setting of virtual machine and choose Network Adapter. In the menu, choose the option Private to my Mac. Once finish the setting, we can restart the guest OS then the new setting will work out. What Private to my Mac does is to virtualize a new network interface that separates private LAN between host OS and guest OS. The new private LAN, so called VMNet, is used for creating a private virtual LAN among guest OSes.
As we have already known, one of the most common way for malware to spread is through USB, CD-ROMs or other peripheral devices. To prevent the spreading, it is better to remove those devices from a virtual machine.
To remove CD-ROM, just go to CD/DVD(SATA) in the menu and click remove CD/DVD Drive.
Remove USB is very similar to the above instruction. Go to USB & Bluetooth from the setting panel and choose Remove USB Controller and everything just works fine. 😆
Before Malware Activated
Explore Processes
Even a user does not actually run a software, there are many processes running in the background in OS and not easy to be seen by users. Before we activate the malicious executable, it is a good idea to see what processes are running in the clean OS.
Here, we are going to introduce a new tool Windows’ Process Explorer which can monitor the working status of processes and observe the relation between them. Most of processes are under a process named wininit.exe, which is a system process that initializes many critical services like Local Security Authentication Subsystem Server (a.k.a Lsass.exe), Local Session Manager (a.k.a Lsm.exe) and Service Control Manager (a.k.a Services.exe). The svchost.exe processes are also beneath wininit.exe and are managed by Service.exe.
Now, we open Process Monitor and record all system calls conducted by the processes for 10 minutes. Then, we can save the monitor result in a log file. There are two advantages of this method for analysis: first, we are able to use some simple inferential statistic techniques to see the normal behavior pattern of a clean OS. Second, we can easily compare the patterns between original record and the processes record that is generated after malicious code is activated.
First of all, we load the record with pandas in jupyter notebook and there are 7 columns in the dataframe. They are Time of Day, Process Name, PID, Operation, Path, Result.
Then we can combine each PID and its corresponding name; There are 59 processes working in this short period of time. For examples: the PID 4 is always reserved for InitialSystemProcess in Windows. Explorer.EXE is the file manager application. svchost.exe is an implementation of shared service process whose job is to host one to multiple Windows Services. The idea of “shared” means that the process can group multiple Windows Services to reduce resource consumption (ex: Services use the same DLL). In addition, the malware often pretends that it is a “svchost.exe” such that user is not easy to identify it among other system processes. conhost.exe is regarded as an interface between Windows Explorer and the Command Prompt.
Then we combine the processes and their operations and plot them up. We use time as x axis, operations as y axis and different colors of circles for different processes. As the below picture illustrates, most frequently used operations are at the bottom of the chart. (Sadly, the chart is not cleared enough after upload, so I crop a part of it for demonstration)
According to the chart, operations RegQueryValue, RegCloseKey, RegQueryKey, CreateFile, QueryDirectory and CloseFile are used frequently. In addition, operation UDPSend is used frequently too but it’s not cropped in the picture. Next, we are going to count how many times the processes conduct the operations.
CreateFile is a Windows API that creates or opens file and IO devices. The processes used the API are following:
The given figure shows us the wmiprvsi.exe, PID: 1512, has the highest number of calls. The process provides a standard way to request a state and data of Windows.
In windows, software accesses registry to get the latest configuration during runtime. In our record, operations like RegOpenKey and RegQueryValue are highly used. Looking deeper, the processes using RegOpenKey frequently call RegQueryValue a large amount of times too. These processes seem to repeat an action: They retrieve keys from the registry and access corresponding value of the keys.
Networking
Since a high portion of malwares are internet required to connect their C2 servers, the analysis of network behaviors becomes significant vital. Just like we have done in processes monitoring, we record network traffics in the clean system as a reference for the comparison when the system is infected.
There are several ip addresses displayed. 255.255.255.255 is a broadcast address and is used for DHCP cllients to find their servers. 127.255.255.255 is a loopback address and host the service named Browser Service, a network features of Windows which allow different Windows hosts in the same LAN to share information over Network Neighborhood. The VMNet virtualizes a private LAN and assign an IP address 172.16.95.136 to our Guest OS. The 172.16.95.255 is the broadcast address in the virtual LAN. 239.255.255.250 is the multicast address of Simple Service Discover Protocol (a.k.a SSDP) in IPv4. The last one, 224.0.0.252, similar to 239.255.255.250, is a multicast address for Link-Local Multicast Name Resolution protocol (a.k.a LLMNR). So sum up, there is no a host communicating with our system over the Internet. The system is absolutely isolated.
Registry
The last step before we run the malware, we should take a snapshot for our registry.
Malware is Activated
Passing through all sort of setting and understanding some basic info, we are finally going to do the most exciting experiment, running the malware.
To execute the binary, we can easily add the extension name .exe after the malware and execute it as administrator.
A simple click can trigger a big disaster.
Once we activate the malware, it has done many malicious things. Before every software starts running, it needs to register itself to the registry in Windows such that it can be authorized to run. In other words, it has to make some modification in the registry. Thanks for the Regshot, we can simply compare the state of registry before the malicious code starts and afterward.
In addition, something interesting can be seen in the Process Explorer. We have seen strings in the image with command string (check previous article). Because the malware unpacks itself when it is activated, we can see many special strings that are not seen in static analysis.
Based on the above observation, the malware actually does an action called process replacement, which runs a process on the system and write malicious executable into the memory space. Hence, we know that the malware import many additional modules dynamically. To see what modules are called by the malware while it is running, we use Dependency Walker to do profiling.
The profiler loads modules one by one and put them into their corresponding parent module; If a parent module is not found, the module will be put at the root level of Module Dependency Tree View where is the top left part of Dependency Walker view. Interestingly, except SECHOST.DLL, the modules EXPLORERFRAME.DLL, TIPTSF.DLL, SFC.DLL and SFC_OS.DLL are newly discovered and are put at the root level of the view.
Not only the registry becomes different, there is some suspicious network traffic captured by wireshark too. The below screenshot shows abnormal name query to www.sina.com.cn. Due to no Internet connection, the software is not able to communicate with world outside.
Sadly, we are not able to see the outcome when the application successfully connects to its wanting host if there is no Internet connection. But the thing will be changed if we use FakeNet to simulate an “Internet” environment such as DNS Server, HTTP Server etc.
The Fakenet’s DNS Server received a DNS request www.sina.com from cdbee59f8144be30634bf4994d51e1a0.exe. Furthermore, we discover more domain names we haven’t seen before: since Fakenet played a trick to the malware, it believes it can reach www.sina.com so it continued to request other domain names www.163.com and coll.elevatorbigdata.com to Fakenet’s DNS Server. After the three domains are requested, the HTTP Listener on port 80 suddenly received a HTTP GET from the malware!!! It makes us so interested about what kind of information it was trying to grab from the http server.
Fakenet is so handy that it saved all traffic in the .pcap file. We clearly see that after the three domains were resolved, TCP connections were established to the three hosts stimulated by the Fakenet DNS. Every time the DNS server was queried, it always answered IP address 192.0.2.123 to the malware.
After the TCP connection to coll.elevatorbigdata.com was built, A suspicious HTTP GET request with complex parameters was sent out.
Open up the HTTP GET packet, we can see the host is coll.elevatorbigdata.com:9018; URI is /supp.aspx and its query has 10 parameters. The extension name in URI shows that the service running on port 9018 is a .NET service. The User-Agent of the malware is WinHttp which is Windows Http Service. Hence, we can determine that this malware, no doubt, is designed for Windows.
What did our fake service reply the GET request? Well, it sends malware a default HTML page. Clearly, this “You are connecting to the Fakenet” is definitely not the expected response for the malware so the it did not continue further tasks. Don’t feel disappoint about the result, because in future we can do more advanced configuration to change Fakenet’s default response.
Wait … we haven’t checked what system calls were used by the malware after activation. Let’s write couple lines of code.
It seems there is no abnormal behaviour in the point of view of system calls. How a pity!
THE END
Thanks for your precious time. In the next chapter, we are going to start disassembly to the malware.
