An Inside Look into a Customized Threat

Recently, we came across a customized threat that, per our current understanding, was customized for a single individual—the president of a billion dollar corporation. As the goal of this posting is to share the findings about the targeted attack, the individual and corporation's identity have been withheld and will not be discussed in this blog. 

Delivery Method

As shown in Figure 1 below, the malware was delivered via an email message to the president of a corporation. The email claimed that it was sent by the senior vice president and CFO of the corporation. To initiate the threat, the recipient must click on the link, thereby opening an attached zip file. Disguised as a financial report, the zip file is the malicious sample. 

Email delivering malicious content

Figure 1. Email delivering malicious content

Analysis of the Malicious File

The malicious file does not make use of any packing or obfuscation techniques generally used by malware. Broadly speaking, the malicious file has two main components: the first component, as shown in Figure 2, creates another executable file titled "mctask.exe" in the folder c:\DOCUMENTS AND SETTINGS \ADMNISTRATOR\LOCAL\Temp\ with write permissions. 

Figure 2. Code creating the file.

Figure 2. Code creating the file

The second component of the malware, shown in Figure 3, executes this created mctask.exe.

Figure 3. Code of the malicious file which executes mctask.exe.

Figure 3. Code of the malicious file which executes mctask.exe

In Figure 4, we see that when the mctask.exe is executed in the debugger, it makes an HTTP request with "P3i.htm" as its URI parameters.

Figure 4. HTTP URI generated by the mctask.exe

Figure 4. HTTP URI generated by the mctask.exe

When the mctask.exe is executed in a controlled environment, the result of its dynamic behavior is the same as it was when observed by executing the sample in a debugger. Mctask.exe generates a GET request with p3i.htm as the parameter for URI and, in the response, gets a jpg file. This HTTP request is  sent to a server located in Taiwan. At first glance, the network communication, shown in Figure 5, seems to be normal. 

Figure 5. Malicious communications by dropped executable

Figure 5. Malicious communications by dropped executable

However, when we observe the jpg file closely, as in Figure 6, we notice that, at offset 0, it has "SZDD." SZDD file format is the compressed executable format with a fixed header. The fixed header is followed by the compressed data making use of a form of LZSS algorithm.

Figure 6. Contents of wmiapsrver.jpg

Figure 6. Contents of wmiapsrver.jpg

When the "wmiaprserv.jpg" is decompressed and executed, it establishes SSL communication on the compromised computer. Upon static analysis of the file (see Figure 7), more or less the same information is revealed

Image9

Figure 7. API's imported by the decoded executable file

To summarize, when the malicious file—disguised as a financial report—is executed, it drops an executable file in a temporary folder and executes it. The dropped file then requests an HTML page from a server located in Taiwan and downloads a compressed executable file. This downloaded file establishes SSL communication on the compromised computer.

Key Observations:

  1. The entire exploitation was customized for a specific individual—in this case, the president of a billion dollar corporation. The implications of this are tremendous: if the president's computer were to be compromised, the malware author behind the attack would then have access to a goldmine of sensitive company information.
  2. When analyzed alone, the malicious files used for exploitation may seem innocuous and give the impression that the files may simply be corrupted zip files or corrupted jpg files. Only when they work together do they demonstrate the potential of carrying damage to the compromised computer.
  3. Similar behavior is observed for network communications. The generated HTTP requests seem like either normal requests or that they are using SSL. As a result, no alerts will be generated by network inspection signatures.