Basic Dynamic Tools in Practice

All the tools discussed in this chapter can be used in concert to maximize the amount of information gleaned during dynamic analysis. In this section, we’ll look at all the tools discussed in the chapter as we present a sample setup for malware analysis. Your setup might include the following:

  1. Running procmon and setting a filter on the malware executable name and clearing out all events just before running.

  2. Starting Process Explorer.

  3. Gathering a first snapshot of the registry using Regshot.

  4. Setting up your virtual network to your liking using INetSim and ApateDNS.

  5. Setting up network traffic logging using Wireshark.

Figure 3-12 shows a diagram of a virtual network that can be set up for malware analysis. This virtual network contains two hosts: the malware analysis Windows virtual machine and the Linux virtual machine running INetSim. The Linux virtual machine is listening on many ports, including HTTPS, FTP, and HTTP, through the use of INetSim. The Windows virtual machine is listening on port 53 for DNS requests through the use of ApateDNS. The DNS server for the Windows virtual machine has been configured to localhost (127.0.0.1). ApateDNS is configured to redirect you to the Linux virtual machine (192.168.117.169).

If you attempt to browse to a website using the Windows virtual machine, the DNS request will be resolved by ApateDNS redirecting you to the Linux virtual machine. The browser will then perform a GET request over port 80 to the INetSim server listening on that port on the Linux virtual machine.

Example of a virtual network

Figure 3-12. Example of a virtual network

Let’s see how this setup would work in practice by examining the malware msts.exe. We complete our initial setup and then run msts.exe on our malware analysis virtual machine. After some time, we stop event capture with procmon and run a second snapshot with Regshot. At this point we begin analysis as follows:

  1. Examine ApateDNS to see if DNS requests were performed. As shown in Figure 3-13, we notice that the malware performed a DNS request for www.malwareanalysisbook.com.

    ApateDNS request for www.malwareanalysisbook.com

    Figure 3-13. ApateDNS request for www.malwareanalysisbook.com

  2. Review the procmon results for file system modifications. In the procmon results shown in Figure 3-14, we see CreateFile and WriteFile (sequence numbers 141 and 142) operations for C:WINDOWSsystem32winhlp2.exe. Upon further investigation, we compare winhlp2.exe to msts.exe and see that they are identical. We conclude that the malware copies itself to that location.

    Procmon output with the msts.exe filter set

    Figure 3-14. Procmon output with the msts.exe filter set

  3. Compare the two snapshots taken with Regshot to identify changes. Reviewing the Regshot results, shown next, we see that the malware installed the autorun registry value winhlp at HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun location. The data written to that value is where the malware copied itself (C:WINDOWSsystem32winhlp2.exe), and that newly copied binary will execute upon system reboot.

    Values added:3
----------------------------------
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunwinhlp: C:WINDOWSsystem32winhlp2.exe

  4. Use Process Explorer to examine the process to determine whether it creates mutexes or listens for incoming connections. The Process Explorer output in Figure 3-15 shows that msts.exe creates a mutex (also known as a mutant) named Evil1 ❶. We discuss mutexes in depth in Chapter 7, but you should know that msts.exe likely created the mutex to ensure that only one version of the malware is running at a time. Mutexes can provide an excellent fingerprint for malware if they are unique enough.

  5. Review the INetSim logs for requests and attempted connections on standard services. The first line in the INetSim logs (shown next) tells us that the malware communicates over port 443, though not with standard Secure Sockets Layer (SSL), as shown next in the reported errors at ❶.

      [2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043] connect
  [2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043]
❶ Error setting up SSL:  SSL accept attempt failed with unknown error
  Error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
  [2010-X] [15013] [https 443/tcp 15199] [192.168.117.128:1043] disconnect
    Process Explorer’s examination of an active msts.exe process

    Figure 3-15. Process Explorer’s examination of an active msts.exe process

  6. Review the Wireshark capture for network traffic generated by the malware. By using INetSim while capturing with Wireshark, we can capture the TCP handshake and the initial data packets sent by the malware. The contents of the TCP stream sent over port 443, as shown in Figure 3-16, shows random ACSII data, which is often indicative of a custom protocol. When this happens, your best bet is to run the malware several more times to look for any consistency in the initial packets of the connection. (The resulting information could be used to draft a network-based signature, skills that we explore in Chapter 14.)

    Wireshark showing the custom network protocol

    Figure 3-16. Wireshark showing the custom network protocol

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset