Threat Actors Using Mandiant APT1 Report as a Spear Phishing Lure: The Nitty Gritty

As we noted yesterday, Brandon Dixon's 9B+ blog and Symantec reported the discovery of two malicious versions of our APT1 report. We wanted to provide follow-on details based on our analysis of these samples. Additionally, we have attached Indicators of Compromise (IOCs) so folks can begin using them to detect the malware.

PDF1 - "Mandiant_APT2_Report" Lure

MD5: 14A6E24977FF6E7E8A8661AADFA1A1F3

This is a password protected PDF using the password "hello" and exploits the CVE-2011-2462 vulnerability from back in December of 2011. Once opened it drops %TEMP%AdobeArm.tmp (4D9A1144E08E7FAE7D6DB8BC606F5BE5) and %TEMP%Mandiant_APT2_Report.pdf (29E9494E2EBA1D8F8AD9EE308FFE53EF). The newly dropped report is opened and the AdobeArm.tmp binary is executed.

The AdobeArm.tmp malware is a variant of the Bisrala downloader Trojan outlined here: http://www.symantec.com/security_response/writeup.jsp?docid=2011-061607-2451-99&tabid=2. The malware can download and execute additional malware, list processes and files, load additional DLLs, and overwrite system files. The malware executes its main functionality from an embedded shellcode payload.

Before executing its payload the malware creates a thread that will monitor for windows created containing text related to AVG firewall notifications. The malware attempts to dismiss these notifications by selecting the button that will add an exception for this connection in the AVG firewall. The malware then extracts its main payload and initially decodes it using a single byte XOR key of 0x99. An additional buffer is then decoded within the decoded shellcode using a single byte XOR key of 0xFF. Throughout execution, shellcode and configuration data are re-encoded to prevent the malware from being fully decoded in memory. This buffer contains configuration data that will be used later by the malware and is shown below.

Figure 1: Decoded configuration data
Figure 1: Decoded configuration data

The malware's main payload is implemented using multiple shellcode buffers that are decoded and re-encoded throughout their execution. The malware then attempts to load the following DLLs and call an exported function from each which are listed below:

  • The malware attempts to load the DLL named %SYSTEMROOT%system32appmgmt.dll and calls an exported function named dll.
  • The malware attempts to load the DLL named %SYSTEMROOT%system32PurpleTrans.dll and calls an exported function named RealWork.

The malware copies its embedded configuration data to a file named %TEMP%winbha.dat that is used to store additional configuration information encoded with a large XOR key. The malware then attempts to connect to the configured server at itsec.eicp.net using TCP port 443 to download files to the infected system.

Other indicators include:

  • It creates the following mutexes: "0x1A7B4C9F" and "0123456AB"
  • Creates the registry key: HKCUSoftwareMicrosoftWindowsCurrentVersionRunLoad: %TEMP%AdobeArm.tmp

PDF2 - Japanese email reported by Symantec

MD5: 2A42BF17393C3CAAA663A6D1DADE9C93

The second PDF appears to be targeting Japanese entities, as identified by Symantec. The PDF exploits the CVE-2013-0641 vulnerability in Adobe Reader. This causes the PDF to drop the file %TEMP%D.T (CB33E97F46A219804DDB373FF982D694). The binary has already been discussed previously at http://www.symantec.com/connect/blogs/new-adobe-pdf-zero-day-unleashes-trojanswaylib. D.T is responsible for decrypting and dropping the next piece at %TEMP%L2P.T (A7310E731271BBB98FF09818E06f4A4D), loading and executing L2P.T and displaying the following message box:

Figure 2
Figure 2: Message box displayed by the D.T DLL loaded within Adobe Reader

The L2P.T that is executed is different from what was previously described elsewhere. It drops a clean PDF at %TEMP%Adobe Reader.pdf (44374BE2AEAA7E46DEFE3DA50569EB9E) and a malicious binary at %TEMP%AdobeARM.exe (41915B34FC50FFDD2A6A0969E3F55FF1). The clean PDF is then displayed for the user while AdobeARM.exe is executed in the background.

AdobeARM.exe first copies itself to C:Documents and SettingsAll UsersDocumentsMy MusicAcroRd32Info.exe and then points the following Run key to its new copy: HKCUSoftwareMicrosoftWindowsCurrentVersionRunShStatEXE. At this point AdobeARM.exe has the ability to communicate out to several different servers on port 80. The GET request URIs are created by using the hostname along with the language ID of the infected system. The malware takes the hostname string (up to 0x14 characters), increments each character by one and then appends the language ID string. Potential servers and URI's include:

Figure 3: Servers and URI's hardcoded in AdobeARM.exe
Figure 3: Servers and URI's hardcoded in AdobeARM.exe

If successful, the malware downloads data to %TEMP% mp.dat. The data received is encrypted using RC4 where the key is seeded with the string "http://.www. " repeated for a total of 256 characters. After the received data is decrypted, the malware verifies that it begins with "MZ" and then executes the binary. The malware sleeps for 15 minutes before it tries to connect out again.

Special shout-out to Will Gibb and the Mandiant Intel Team for their contributions!

Download related IOCs here

ZIP Attachment MD5: ABD9DE4EFE115EAF5FA4338557395739