To understand the malware's behavior, the dynamic analysis tools discussed in this chapter were used, and the following dynamic analysis steps were followed:

1. Both the Windows VM and the Linux VM were reverted to the clean snapshots.
2. On Windows VM, Process Hacker was started with administrator privileges to determine process attributes, and the Noriben Python script was executed (which in turn started Process Monitor) to inspect the malware's interaction with the system.
3. On the Linux VM, INetSim was launched to simulate network services, and Wireshark was executed and configured to capture the network traffic on the network interface.
4. With all the monitoring tools running, the malware was executed with administrator privileges (right click | Run as Administrator) for around 40 seconds.
5. After 40 seconds, Noriben was stopped on the Windows VM. INetSim and Wireshark were stopped on the Linux VM.
6. Results from the monitoring tools were collected and examined to understand the malware's behavior.

After performing dynamic analysis, the following information about the malware was determined from different monitoring tools:

1. Upon executing the malware sample (sales.exe), a new process, iexplorer.exe, was created with a process ID of 1272. The process executable is located in the %Appdata% directory. The following screenshot is the output from Process Hacker showing the newly created process:

2. By examining the Noriben logs, it can be determined that the malware dropped a file called iexplorer.exe in the %AppData% directory. The name of the file (iexplorer.exe) is similar to the file name of the Internet Explorer (iexplore.exe) browser. This technique is a deliberate attempt by the attacker to make the malicious binary look like a legitimate executable:

[CreateFile] sales.exe:3724 > %AppData%iexplorer.exe

After dropping the file, the malware executed the dropped file. As a result of that, a new process iexplorer.exe was created. This was the process that was displayed by the Process Hacker:

[CreateProcess] sales.exe:3724 > "%AppData%iexplorer.exe"

The malware then drops another file called MDMF5A5.tmp_melt.bat, as shown in the following output. At this point, it can be deduced that the  _melt.bat string that we found during static analysis is concatenated with another string called MDMF5A5.tmp, which is used to generate a file name, MDMF5A5.tmp_melt.bat. Once the filename is generated, the malware drops a file with this name on the disk:

[CreateFile] sales.exe:3724 > %LocalAppData%TempMDMF5A5.tmp_melt.bat

It then executes the dropped batch (.bat) script by invoking cmd.exe:

[CreateProcess] sales.exe:3724 > "%WinDir%system32cmd.exe /c %LocalAppData%TempMDMF5A5.tmp_melt.bat"

As a result of cmd.exe executing the batch script, both the original file (sales.exe) and the batch script (MDMF5A5.tmp_melt.bat) were deleted, as shown in the following code snippet. This behavior confirms the delete functionality of the batch (.bat) file (if you recall, batch commands to delete files were found during the string extraction process):

[DeleteFile] cmd.exe:3800 > %UserProfile%Desktopsales.exe
[DeleteFile] cmd.exe:3800 > %LocalAppData%TempMDMF5A5.tmp_melt.bat

The malicious binary then adds the path of the dropped file, as an entry in the RUN registry key for persistence, which allows the malware to start even after the system reboots:

[RegSetValue] iexplorer.exe:1272 > HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunHKLM Key = C:Users	estAppDataRoamingiexplorer.exe

3. From the network traffic captured by Wireshark, it can be seen that the malware resolves the C2 domain and establishes a connection on port 80:

The TCP stream of the port 80 communication, as shown in the following screenshot, is not standard HTTP traffic; this suggests that the malware probably uses a custom protocol or encrypted communication. In most cases, the malware uses a custom protocol or encrypts its network traffic to bypass network-based signatures. You need to perform code analysis of malicious binaries to determine the nature of the network traffic. In the upcoming chapters, you will learn the techniques to perform code analysis in order to gain an insight into the inner workings of a malware binary:

Comparing the cryptographic hash of the dropped sample (iexplorer.exe) and the original binary (sales.exe) shows that they are identical:

$ md5sum sales.exe iexplorer.exe
51d9e2993d203bd43a502a2b1e1193da sales.exe
51d9e2993d203bd43a502a2b1e1193da iexplorer.exe

To summarize, when malware is executed, it copies itself into the %AppData% directory as iexplorer.exe and then drops a batch script whose job is to delete the original binary and itself. The malware then adds an entry into the registry key so that it can start every time the system starts. The malicious binary possibly encrypts its network traffic and communicates with the command and control (C2) server on port 80 using a non-standard protocol.

By combining both static and dynamic analysis, it was possible to determine the characteristics and the behavior of the malicious binary. These analysis techniques also helped in identifying the network and host-based indicators associated with the malware sample.