2014 | FireEye Blog

Black Hat USA Talks - Leviathan: Command And Control Communications On Planet Earth

August 7, 2014 | By FireEye Inc. | |

Comments

Every day, computer network attackers leverage a Leviathan of compromised infrastructure, based in every corner of the globe, to play hide-and-seek with network security, law enforcement, and counterintelligence personnel.

This presentation draws a new map of Planet Earth, based not on traditional parameters, but on hacker command and control (C2) communications. The primary data points used in this worldwide cyber survey are more than 30 million malware callbacks to over 200 countries and territories over an 18-month period, from January 2013 to June 2014.

First, this talk covers the techniques that hackers use to communicate with compromised infrastructure across the globe. The authors analyze the domains, protocols, ports, and websites used for malicious C2. They explain how covert C2 works, and how attackers keep their communications hidden from network security personnel.

Second, this talk looks at strategic impact. The authors examine relationships between the targeted industries and countries and the first-stage malware servers communicating with them. Traffic analysis is used to deduce important relationships, patterns, and trends in the data. This section correlates C2 communications to traditional geopolitical conflicts and considers whether computer network activity can be used to predict real world events.

In conclusion, the authors consider the future of this Leviathan, including whether governments can subdue it – and whether they would even want to.

Attend this presentation on August 7 at 10:15am PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Operation Poisoned Hurricane

August 6, 2014 | By Ned Moran, Joshua Homan and Mike Scott | |

Comments

Introduction

Our worldwide sensor network provides researchers at FireEye Labs with unique opportunities to detect innovative tactics employed by malicious actors and protects our clients from these tactics. We recently uncovered a coordinated campaign targeting Internet infrastructure providers, a media organization, a financial services company, and an Asian government organization. The actor responsible for this campaign utilized legitimate digital certificates to sign their tools and employed innovative techniques to cloak their command and control traffic.

Hurricane Electric Redirection

In March of 2014, we detected Kaba (aka PlugX or SOGU) callback traffic to legitimate domains and IP addresses. Our initial conclusion was that this traffic was the result of malicious actors ‘sleeping’ their implants, by pointing their command and control domains at legitimate IP addresses. As this is a popular technique, we did not think much of this traffic at the time.

Further analysis revealed that the HTTP headers of the traffic in question contained a Host: entry for legitimate domains. As we have previously observed malware families that forge their HTTP headers to include legitimate domains in callback traffic, we concluded that the malware in this case was configured in the same way.

An example of the observed traffic is as follows:

POST /C542BB084F927229348B2A34 HTTP/1.1 Accept: */* CG100: 0 CG103: 0 CG107: 61456 CG108: 1 User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Host: www.adobe.com Content-Length: 0 Cache-Control: no-cache

As we continued to see this odd traffic throughout the summer we began a search for malware samples responsible for this behavior. Via this research, we found a malware sample that we believe was responsible for at least some of the strange traffic that we had observed. The identified sample had the following properties:

MD5: 52d2d1ab9b84303a585fb81e927b9e01 Size: 180296 Compile Time: 2013-10-15 05:17:37 Import Hash: b29eb78c7ec3f0e89bdd79e3f027c029 .rdata: d7b6e412ba892e9751f845432625bbb0 .text: ed0dd6825e3536d878f39009a7777edc .data: 1bc25d2f0f3123bedea254ea7446dd50 .rsrc: 91484aa628cc64dc8eba867a8493c859 .reloc: f1df8fa77b5abb94563d5d97e5ccb8e2 RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample was signed with a legitimate digital certificate from the ‘Police Mutual Aid Association’. This certificate has a serial number of ‘06 55 69 a3 e2 61 40 91 28 a4 0a ff a9 0d 6d 10’.

Analysis of this Kaba sample revealed that it was configured to directly connect to both www.adobe.com and update.adobe.com. Obviously, this configuration does not make a lot of sense, as the actor would not be able to control their implants from anywhere on the Internet since they did not have direct control over these domains – unless the attackers were able to re-route traffic destined for these domains from specific victims. Indeed, further analysis of this Kaba variant revealed that it was also configured to use specific DNS resolvers. This sample was configured to resolve DNS lookups via Hurricane Electric’s nameservers of 216.218.130.2, 216.218.131.2, 216.218.132.2 and 216.66.1.2.

We found this interesting, so we investigated how these Hurricane Electric’s nameservers were configured. Subsequently, we found that anyone could register for a free account with Hurricane Electric’s hosted DNS service. Via this service, anyone with an account was able to register a zone and create A records for the registered zone and point those A records to any IP address they so desired. The dangerous aspect of this service is that anyone was able to hijack legitimate domains such as adobe.com. Although these nameservers are not recursors and were not designed to be queried directly by end users, they were returning results if queried directly for domains that were configured via Hurricane Electrics public DNS service. Furthermore, Hurricane Electric did not check if zones created by their users were already been registered or are otherwise legitimately owned by other parties.

As we continued this research, we identified 21 legitimate fully qualified domain names that had been hijacked via this technique by at least one APT actor. In addition to the adobe.com domain mentioned above, another one of the poisoned domains is www.outlook.com. A lookup of this domain via Google’s DNS resolvers returns expected results:

$ dig +short @8.8.8.8 www.outlook.com www.outlook.com.glbdns2.microsoft.com. www-nameast.outlook.com. 157.56.240.246 157.56.236.102 157.56.240.214 157.56.241.102 157.56.232.182 157.56.241.118 157.56.240.22

A quick lookup of these addresses reveal that Microsoft owns them:

157.56.240.246 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.236.102 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.240.214 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.241.102 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.232.182 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.241.118 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION 157.56.240.22 | 8075 | 157.56.0.0/16 | MICROSOFT-CORP-MSN-A | US | MICROSOFT.COM | MICROSOFT CORPORATION

However, as recently as August 4, 2014 a lookup of the same www.outlook.com domain via Hurricane Electric’s resolvers returned entirely different results[1]:

$ dig +short @216.218.130.2 www.outlook.com 59.125.42.167

$ dig +short @216.218.131.2 www.outlook.com
59.125.42.167

$ dig +short @216.218.132.2 www.outlook.com
59.125.42.167

$ dig +short @216.66.1.2 www.outlook.com
59.125.42.167

Passive DNS research on the 59.125.42.167 IP address revealed that multiple APT actors have previously used this IP address.

IP Address	Domain	First Seen	Last Seen
59.125.42.167	ml65556.gicp[.]net	2014-06-23	2014-07-23
59.125.42.167	wf.edsplan[.]com	2014-05-12	2014-05-14
59.125.42.167	gl.edsplan[.]com	2014-05-12	2014-05-14
59.125.42.167	unix.edsplan[.]com	2014-05-12	2014-05-14

Additional researched uncovered more Kaba samples that were configured to leverage Hurricane Electric’s public DNS resolvers. Another sample has the following properties:

MD5: eae0391e92a913e757ac78b14a6f079f Size: 184304 Compile Time: 2013-11-26 17:39:25 Import Hash: f749528b1db6fe5aee61970813c7bc18 Text Entry: 558bec83ec1056ff7508ff1518b00010 .rdata: 747abda5b3cd3494f056ab4345a909e4 .text: 475c20b8abc972710941ad6659492047 .data: d461f8f7b3f35b7c6855add6ae59e806 .rsrc: b195f57cb5e605cb719469492d9fe717 .reloc: d6b23cb71f214d33e56cf8f6a10c0c10 RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample is signed with a recently expired digital certificate from ‘MOCOMSYS INC’. This certificate has a serial number of ‘03 e5 a0 10 b0 5c 92 87 f8 23 c2 58 5f 54 7b 80’.

This sample used Hurricane Electric’s public DNS resolvers to route traffic to the hijacked domains of www.adobe.com and update.adobe.com. We also noted that this sample was configured to connect directly to 59.125.42.168 – one IP address away from the IP that received traffic from the hijacked www.outlook.com domain.

Passive DNS research revealed that this IP hosted the same set of known APT domains listed above:

IP Address	Domain	First Seen	Last Seen
59.125.42.168	ml65556.gicp[.]net	2014-04-23	2014-07-24
59.125.42.168	wf.edsplan[.]com	2014-04-23	2014-05-14
59.125.42.168	gl.edsplan[.]com	2014-05-04	2014-05-14
59.125.42.168	unix.edsplan[.]com	2014-05-04	2014-05-14

While this problem does not directly impact users of www.adobe.com, www.outlook.com, or users of the other affected domains, it should not be dismissed as inconsequential. Actors that adopt this tactic and obfuscate the destination of their traffic through localized DNS hijacks can significantly complicate the job of network defenders.

Via our sensor network, we observed the actor responsible for this activity conducting a focused campaign. We observed this actor target:

Multiple Internet Infrastructure Service Providers in Asia and the United States
A Media Organization based in the United States
A financial institution based in Asia
An Asian government organization

Google Code Command and Control

Furthermore, we also discovered this same actor conducting a parallel campaign that leveraged Google Code for command and control. On August 1, 2014 we observed a malicious self-extracting executable (aka sfxrar) file downloaded from 211.125.81.203. This file had the following properties:

MD5: 17bc9d2a640da75db6cbb66e5898feb1 Size: 282800 bytes

A valid certificate from ‘QTI INTERNATIONAL INC’ was used to sign this sfxrar. This certificate had a serial number of ‘2e df b9 fd cf a0 0c cb 5a b0 09 ee 3a db 97 b9’. The sfxrar contained the following files:

File	Size	MD5
msi.dll	11680	029c8f56dd89ceeaf928c3148d13eba7
msi.dll.dat	115218	62834d2c967003ba5284663b61ac85b5
setup.exe	34424	d00b3169f45e74bb22a1cd684341b14a

Setup.exe is a legitimate executable from Kaspersky used to load the Kaba (aka PlugX) files – msi.dll and msi.dll.dat.

These Kaba files are configured to connect to Google Code – specifically code.google.com/p/udom/. On August 1, this Google Code project contained the encoded command “DZKSGAAALLBACDCDCDOCBDCDCDOCCDADIDOCBDADDZJS”.

def NewPlugx_C2_redir_decode(s):

rvalue = “”
for x in range(0, len(s), 2):
tmp0 = (ord(s[x+1]) - 0×41) << 4

rvalue += chr(ord(s[x]) + tmp0 - 0×41)
return rvalue

The command ‘DZKSGAAALLBACDCDCDOCBDCDCDOCCDADIDOCBDADDZJS’ decodes to 222.122.208.10. In a live environment, the Kaba implant would then connect to this IP address via UDP.

Further analysis of project at code.google.com/p/udom/ revealed the project owner, 0x916ftb691u, created a number of other projects. We decoded the commands hosted at these linked projects and found that they issued the following decoded commands:

112.175.143.22
59.125.42.167
153.121.57.213
61.82.71.10
202.181.133.169
61.78.32.139
61.78.32.148
202.181.133.216
59.125.42.168
119.205.217.104
222.122.208.10
112.175.143.16
222.122.208.9
27.122.13.204

It is likely that other yet to be discovered Kaba variants are configured to connect to these related Google Code projects and then redirect to this list of IP addresses.

Passive DNS analysis of these IP addresses revealed connections to the following known malicious infrastructure:

IP Address	Domain	First Seen	Last Seen
27.122.13.204	bq.cppcp[.]com	2014-03-21	2014-05-08
112.175.143.16	uj.verisignss[.]com	2013-06-30	2013-08-13
112.175.143.16	www.verifyss[.]com	2013-06-30	2013-07-22
112.175.143.16	uj.byonds[.]com	2013-06-24	2013-07-22
112.175.143.16	uj.verifyss[.]com	2013-06-30	2013-07-22
59.125.42.168	ml65556.gicp[.]net	2014-04-23	2014-07-24
59.125.42.168	wf.edsplan[.]com	2014-04-23	2014-05-14
59.125.42.168	gl.edsplan[.]com	2014-05-04	2014-05-14
59.125.42.168	unix.edsplan[.]com	2014-05-04	2014-05-14
59.125.42.167	ml65556.gicp[.]net	2014-06-23	2014-07-23
59.125.42.167	wf.edsplan[.]com	2014-05-12	2014-05-14
59.125.42.167	gl.edsplan[.]com	2014-05-12	2014-05-14
59.125.42.167	unix.edsplan[.]com	2014-05-12	2014-05-14
61.78.32.148	door.nexoncorp[.]com	2014-04-30	2014-06-22
61.78.32.148	verisignss[.]com	2014-04-30	2014-06-22
61.78.32.148	th.nexoncorp[.]com	2014-04-30	2014-06-22
61.78.32.148	tw.verisignss[.]com	2014-04-30	2014-06-22
61.78.32.148	sd.nexoncorp[.]com	2014-04-30	2014-06-22
61.78.32.148	mail.nexoncorp[.]com	2014-04-30	2014-06-22
112.175.143.22	door.nexoncorp[.]com	2014-04-01	2014-04-30
112.175.143.22	th.nexoncorp[.]com	2014-04-01	2014-04-30
112.175.143.22	sd.nexoncorp[.]com	2014-04-01	2014-04-30
112.175.143.22	mail.nexoncorp[.]com	2014-04-01	2014-04-30
112.175.143.22	verisignss[.]com	2013-12-29	2014-04-30
112.175.143.22	tw.verisignss[.]com	2013-12-29	2014-04-30

Relationships Between Campaigns

As mentioned above the Kaba variant eae0391e92a913e757ac78b14a6f079f shared a common import hash of f749528b1db6fe5aee61970813c7bc18 with many of the samples listed in this post. This samples was to use Hurricane Electric’s nameservers as well as connect directly to the IP address 59.125.42.168.

Note that we identified the same C2 IP 59.125.42.168 via our analysis of the malicious Google Code projects. Specifically, the Google Project at code.google.com/p/tempzz/, which is linked to the project at code.google.com/p/udom/, issued an encoded command that decoded to 59.125.42.168.

We also identified another related Kaba variant that connected to code.google.com/p/updata-server. This variant had the following properties:

MD5: 50af349c69ae4dec74bc41c581b82459 Size: 180600 bytes Compile Time: 2014-04-01 03:28:31 Import Hash: f749528b1db6fe5aee61970813c7bc18 .rdata: 103beeefae47caa0a5265541437b03a1 .text: e7c4c2445e76bac81125b2a47384d83f .data: 5216d6e6834913c6cc75f40c8f70cff8 .rsrc: b195f57cb5e605cb719469492d9fe717 .reloc: f7d9d69b8d36fee5a63f78cbd3238414 RT_VERSION: 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9

This sample was signed with a valid digital certificate from ‘PIXELPLUS CO., LTD’ and had a serial number of ‘0f e7 df 6c 4b 9a 33 b8 3d 04 e2 3e 98 a7 7c ce’.

In addition to sharing the same Import hash of f749528b1db6fe5aee61970813c7bc18 seen in other samples listed throughout this post, 50af349c69ae4dec74bc41c581b82459 contained a RT_VERSION resource of 9dd9b7c184069135c23560f8fbaa829adc7af6d2047cf5742b5a1e7c5c923cb9. This same RT_VERSION was used in a number of other related samples including:

MD5	C2	Uses Hurricane Electric
7e6c8992026a79c080f88103f6a69d2c	h.cppcp[.]comu.cppcp[.]com	NO
52d2d1ab9b84303a585fb81e927b9e01	www.adobe[.]comupdate.adobe[.]com	YES
787c6cf3cb18feeabe4227ec6b19db01	ns.lovechapelumc[.]orgns1.lovechapelumc[.]org	NO

Conclusion

These coordinated campaigns demonstrate that APT actors are determined to continue operations. As computer network defenders increase their capabilities to identify and block these campaigns by deploying more advanced detection technologies, threat actors will continue to adopt creative evasion techniques.

We observed the following evasion techniques in these campaigns:

The use of legitimate digital certificates to sign malware
The use of Hurricane Electrics public DNS resolvers to redirect command and control traffic
The use of Google Code to obfuscate the location of command and control servers

While none of these techniques are necessarily new, in combination, they are certainly both creative and have been observed to be effective. Although the resultant C2 traffic can be successfully detected and tracked, the fact that the malware appears to beacon to legitimate domains may lull defenders into a false sense of security. Network defenders should continue to study the evolution of advanced threat actors, as these adversaries will continue to evolve in pursuit of their designated objectives.

Related MD5s
17bc9d2a640da75db6cbb66e5898feb1
eae0391e92a913e757ac78b14a6f079f
434b539489c588db90574a64f9ce781f
7e6c8992026a79c080f88103f6a69d2c
52d2d1ab9b84303a585fb81e927b9e01
787c6cf3cb18feeabe4227ec6b19db01
50af349c69ae4dec74bc41c581b82459
d51050cf98cc723f0173d1c058c12721

Digital Certificates
MOCOMSYS INC, (03 e5 a0 10 b0 5c 92 87 f8 23 c2 58 5f 54 7b 80)
PIXELPLUS CO., LTD., (0f e7 df 6c 4b 9a 33 b8 3d 04 e2 3e 98 a7 7c ce)
Police Mutual Aid Association (06 55 69 a3 e2 61 40 91 28 a4 0a ff a9 0d 6d 10)
QTI INTERNATIONAL INC (2e df b9 fd cf a0 0c cb 5a b0 09 ee 3a db 97 b9)
Ssangyong Motor Co. (1D 2B C8 46 D1 00 D8 FB 94 FA EA 4B 7B 5F D8 94)
jtc (72 B4 F5 66 7F 69 F5 43 21 A9 40 09 97 4C CC F8)

Footnotes
[1] As of August 4, 2014 Hurricane Electric was no longer returning answers for www.outlook.com or the other affected domains.
[2] This same encoding algorithm was previously described by Cassidian at http://blog.cassidiancybersecurity.com/post/2014/01/plugx-some-uncovered-points.html

Pacific Ring of Fire: PlugX / Kaba

July 24, 2014 | By Geok Meng Ong, Chong Rong Hwa and Shinsuke Honjo | |

Comments

As depicted in earlier FireEye blogs, advanced cyber attacks are no strangers to the Asia Pacific region. In this blog, we take a deeper look at some of the advanced persistent threat (APT) malware that have significant presence in the APAC region, starting with PlugX (we detect it as Backdoor.APT.Kaba).

The PlugX / Kaba malware is a well-known remote access tool (RAT) believed to have been around for several years that continues to evolve itself in new attack campaigns. It is often seen used in APT campaigns alongside two other infamous RATs – PoisonIvy and Taidoor. For this blog, FireEye Labs has investigated PlugX samples discovered throughout 2013 as well as recent variants detected between January and June 2014. Countries on both sides of the Pacific incuding the United States as well as Northeast Asian countries such as South Korea, Hong Kong, Japan and Taiwan were most hit by this malware, with attacks spanning multiple industry verticals. The top 5 most targeted verticals include Technology, Aerospace / Defense, Entertainment / Media, Telecommunications and Government (Federal).

Figure 1: PlugX / Kaba Infections (by Country)

Figure 1: PlugX / Kaba Detections (by Country)

Table 1: Top 5 Affected Verticals

Delivering the Attacks

PlugX is most commonly distributed via an exploit, but may also be delivered using a RAR self-extracting executable. Amanda Stewart has written an excellent blog and paper about the common components of the PlugX / Kaba RAT and how it capitalizes on the DLL side-loading technique. In general, the RAT consists of DLL components that are injected into the process memory of svchost.exe. To deliver the DLL components, a “dropper” must first be executed through the use of an exploit, or via social-engineering tactics over e-mail or web to entice the victims to load an executable file.

Figure 2: Primary PlugX “Dropper” File Types

While RTF files exploiting CVE-2012-0158 are nothing new, they are still most frequently used in the delivery of PlugX to its targets. The same vulnerability has also been exploited through Excel spreadsheets and Word document files. More recently, a Flash zero-day vulnerability has been exploited to deliver a PlugX payload.

Where an exploit is not used, RAR self-extracting executable (SFX) files were commonly used throughout 2013. These files often appear to have a Word or PDF icon and launch a decoy document that is displayed to the victim. The PlugX RAT is then loaded in the background without the user’s knowledge. While we have noticed a decrease in the use of this vector to deliver PlugX in 2014, it continues to be an effective technique for PlugX and other malware, so we do not expect its use to disappear entirely.

In the below example, the RAR SFX contains a script that loads the RAT (config.exe) and the decoy document (notice.doc).

Figure 3: RAR SFX Script and Files

Command and Control

We have found two dominant variants, SideBar and RasTLS, using 4 of the top 10 domains associated with the PlugX / Kaba command and control (C2) infrastructure. In fact, the 4 domains resolved to the same IP range based in Hong Kong likely operated by the same threat group(s).

Table 2: Top Domains used in PlugX / Kaba Callbacks

SideBar

The SideBar variant is delivered through RTF, Word and Excel files. Upon successfully exploitation, it drops “dw20.dll” to the %TEMP% folder. This “dw20.dll” continues to install the following files:

%ALLUSERS%\WS\Gadget.exe (MD5: 6b97b3cd2fcfb4b74985143230441463)
%ALLUSERS%\WS\SideBar.dll (MD5: 123e1841cc596c1f40e2e6693ea7dcac)
%ALLUSERS%\WS\SideBar.dll.doc (MD5: a0c93bdc089e1338cc392108a0e57f2f)

A service registry key is created to start “Gadget.exe” upon reboot of the infected system.
“Gadget.exe” is part of a benign “TENCENT Sidebar” application digitally signed by “Tencent Technology(Shenzhen) Company Limited “. Using the DLL-side loading method, a malicious version of“SideBar.dll” is loaded and executes the exported function “Main”.

“SideBar.dll” is a loader for “SideBar.dll.doc”, executing code at offset 0. “SideBar.dll.doc” decodes a part of its own data and is responsible for deflating a backdoor component. It spawns a new svchost.exe process and injects the backdoor into memory. This backdoor component remains only in memory, and is never saved to disk.

Figure 4: Decompressing Encoded Data

Version information can often be found in PlugX’s process memory. In SideBar, a DWORD value storing the internal version number was 0×20120123. The path names found in the deflated backdoor’s process memory indicating that this PlugX variant is version 6.0:

“d:\work\plug6.0(360)(gadget)”

The variant connects to fast.bacguarp.com and bbs.zuesinfo.com over port 8080.

RasTLS

While the RasTls variant is also dropped by document exploits, the dropped files are different. RasTls does not use the DLL side-loading method found in older variants [3]. The DWORD used to store the internal version number of RasTls was 0×20130810.

%ALLUSERS%\DRM\RasTls\RasTls.exe

“RasTls.exe” spawns “svchost.exe” and injects a deflated backdoor component into memory. The deflated backdoor component in memory contains a “XV” marker, instead of “MZ” and “PE” as found in regular Windows portal executable (PE) files. This is because “RasTls.exe” manually loads each section of deflated file into memory, so the file does not have to be a complete PE image.

Figure 5: Backdoor Component with “XV” maker instead of “MZ” and “PE”

The variant doesn’t contain strings implying version. The variant accept commands like as “ST1”, “ST2”, “TT1”,”TT2” which are different from version 6.

In memory space in the “svchost.exe”, we can see the decoded configuration information:

Figure 6: Decoded Configuration Information

All RasTls variants have largely identical configuration and connects to scqf.bacguarp.com and scqf.zuesinfo.com over port 443. The “My_Name” mutex is also common to all RasTls variants.

PlugX Encryption Algorithm

PlugX has a variety of encryption algorithms used to encrypt its data across variants. However, the encryption style is largely similar as depicted in Figure 7.

Figure 7: PlugX Decryption Algorithm

In RasTls, the DWORD decryption key was found in the first four bytes of the encrypted string. It was also less aggressive in encrypting and hiding its data. In older variants such as “win3dx.DLL” (MD5: 7ADAE0335C9D6C9F3826CDE9747438B7), most API names were decrypted before loading and nullified after use. This makes understanding the malware slightly more difficult for malware analysts.

The supported functionalities are largely similar where it uses the identical command code. Below is a list of PlugX commands for file system manipulation:

0×3000: GetDiskRelatedInformation
0×3001: SearchDirectoryForFiles
0×3002: SearchDirectoryRecursively
0×3004: ReadFile
0×3007: WriteFile
0x300A: CreateDirectory
0x300C: CreateWindowsDesktop
0x300D: PerformSH_FileOperation
0x300E: ExpandEnvironmentVariable

Some improvements were made by its developers. For example, the key logger function was updated to utilize the GetRawInputData API to collect keystrokes. “RegisterRawInputDevices” and “GetRawInputData” were two of the few API names that remain encrypted in RasTls.

Figure 8: Updated Key Logging Component

PlugX / Kaba Trending

Figure 9 shows the trending of total PlugX / Kaba infections and their variants: SideBar and RasTLS. The spike in September 2013 was caused by SideBar. In 2014, we see SideBar and RasTLS on an inverse trend, with the latter on a steady increase.

Figure 9: Trending of Overall PlugX / Kaba , SideBar, RasTLS Infections

Figure 10 shows the distribution of SideBar/RasTls variants by country. The C2 servers are located in Hong Kong, where much of the attacks have occurred. We also find a variety of countries targeted by these variants. In some of the exploit documents delivering these variants, the content revolves around the theme of NGOs and socio-political events in China and Japan. These are content that would likely be of interest to the victims who would be opening the documents.

Figure 10: Distribution of SideBar/RasTls Variants by Country

Conclusion

The Asia Pacific region remains a highly attractive target of advanced cyber-attacks. Many threat groups have a particular in interest in this region, and are likely continue to launch new attacks against targets here. We recommend that users in this region block access to the above C2 servers. FireEye Labs will continue to monitor and report on new PlugX / Kaba developments.

Havex, It’s Down With OPC

July 17, 2014 | By Kyle Wilhoit | |

Comments

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1^{^[3]}). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).

Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno^{^[1]} as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers^{^[2]} (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.

Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).

Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer^{^[1]}, which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.

Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll” file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.

Analysis

The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function. The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions. Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking. The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:

Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls. The encryption process uses an RSA public key obtained from the PE resource TYU. The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”. A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.

00000000 32 39 0a 66 00 66 00 30 00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010 00 30 00 66 00 66 00 30 00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020 00 30 00 66 00 66 00 30 00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030 00 30 00 66 00 66 00 30 00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040 0a 31 32 38 0a 96 26 cc 34 93 a5 4a 09 09 17 d3 .128..&.4..J….00000050 e0 bb 15 90 e8 5d cb 01 c0 33 c1 a4 41 72 5f a5 …..]…3..Ar_.00000060 13 43 69 62 cf a3 80 e3 6f ce 2f 95 d1 38 0f f2 .Cib….o./..8..00000070 56 b1 f9 5e 1d e1 43 92 61 f8 60 1d 06 04 ad f9 V..^..C.a.`…..00000080 66 98 1f eb e9 4c d3 cb ee 4a 39 75 31 54 b8 02 f….L…J9u1T..00000090 b5 b6 4a 3c e3 77 26 6d 93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0 08 6a 22 89 b7 d3 72 d4 1f 8d b6 80 2b d2 99 5d .j”…r…..+..]000000B0 61 87 c1 0c 47 27 6a 61 fc c5 ee 41 a5 ae 89 c3 a…G’ja…A….000000C0 9e 00 54 b9 46 b8 88 72 94 a3 95 c8 8e 5d fe 23 ..T.F..r…..].#000000D0 2d fb 48 85 d5 31 c7 65 f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k

-Truncated-Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72 94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file

Execution

When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:

Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:

Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.

Conclusion

Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant. We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.

Acknowledgements

We would like to thank Josh Homan for his help and support.

Related MD5s

ba8da708b8784afd36c44bb5f1f436bc

6bfc42f7cb1364ef0bfd749776ac6d38

4102f370aaf46629575daffbd5a0b3c9

References

http://www.matrikonopc.com/products/opc-desktop-tools/opc-explorer.aspx

http://arduino.cc/en/Main/arduinoBoardUno

http://www.st4makers.com/arduino-opc-server/arduino-opc-server

http://www.f-secure.com/weblog/archives/00002718.html

http://www.opcdatahub.com/WhatIsOPC.html

Mergers and Acquisitions: When Two Companies and APT Groups Come Together

June 12, 2014 | By Jen Weedon | |

Comments

With Apple’s purchase of Beats, Pfizer’s failed bids for AstraZeneca, and financial experts pointing to a rally in the M&A market, the last month was a busy one for mergers and acquisitions. Of course, when we first see headlines of a high profile company’s plans for a merger or acquisition, we rush to think of the strategic and industry implications of such a deal. But underneath the “what ifs” and “visions for the future,” is a darker side of M&A that doesn’t make the headlines: the routineness with which companies are breached and crucial data is stolen when two high-profile organizations look to join together.

Over the last few years, concerns over economic espionage have led to greater scrutiny of mergers and acquisitions involving foreign companies – particularly in industries with sensitive technologies and operations that could pose broader economic and security threats. However, entering into a merger or acquisition with a foreign company is not the only way nation-states conduct economic espionage via cyber means, nor are nation-states the only perpetrators of intellectual property theft.

From our experience responding to these breaches, we’ve seen targeted threat actors actively pursuing companies involved in mergers and acquisitions in two ways:

Breaching one of the merging or acquired company’s subsidiaries’ and/or partners’ networks to ultimately gain access to the targeted company’s environment and information
Compromising and stealing information from a company involved in business talks with a foreign enterprise in order to provide the other side with an insider advantage in the negotiations

From One Friend to Another: Taking Advantage of Trusted Relationships Between Companies

Some threat groups compromise an organization’s environment and then move laterally over a connected network to a partner or subsidiary, while others rely on social engineering tactics, such as the use of phishing emails that appear to be from employees at the partner company. We have seen China-based threat groups previously compromise targets by taking advantage of trusted relationships and bridged networks between companies. Regardless of their method of entry, these actors are often in search of the same thing: intellectual property and proprietary information that can provide their own constituents with a business advantage, whether through adopting a rival’s technology and products, securing advantageous prices, or any other tactic that could give them a leg up.

We investigated one incident in which two threat groups compromised a company shortly after it acquired a subsidiary. The threat actors used their access to the initial company’s network to move laterally to the subsidiary, which had recently developed a proprietary process for a significant new healthcare product. Once inside the subsidiary’s network, the threat groups stole data that included details on the product’s test results. We believe the threat groups sought to give that data to Chinese state-owned companies in that industry for fast-tracking the development of their own version of the groundbreaking product.

Cheating the System: Insider Advantages in Negotiations

We have also seen threat groups compromising organizations involved in merger or acquisition talks with Chinese entities, likely in an effort to steal data that could give negotiators and decision makers valuable insider information with which to manipulate the outcome of the proposed transaction. Unlike other types of economic espionage operations, the threat groups in this type of scenario are generally not in search of a company’s intellectual property. Instead, these actors look for data such as executive emails, negotiation terms, and business plans and information; all of which could benefit the negotiators by giving them insight into the victim company’s financial situation and negotiation strategy.

During one investigation, we found that a China-based threat group had compromised a company that was in the process of acquiring a Chinese subsidiary – a move that would have significantly increased the victim company’s manufacturing and retail capacity in the Chinese market. The threat actors accessed the email accounts of multiple employees involved in the negotiations in what was likely a search for information pertaining to the proceedings. We believe that the threat group then used the stolen information to inform Chinese decision makers involved in the acquisition process, as the Chinese government terminated the talks shortly after the data theft occurred.

What can we expect?

Companies involved in mergers and acquisitions need to be aware of the risks they face from threat actors intent on conducting economic espionage. Entering into a merger or acquisition with an organization that has unidentified intrusions and unaudited networks places a company at risk of compromise from threat actors who may be waiting to move laterally to the newly integrated target.

Similarly, companies, and the law firms representing them, involved in negotiations with Chinese enterprises face risks from threat groups seeking to provide the Chinese entity with an advantage in negotiations. Compromise and economic espionage can have profound impacts on a company’s finances and reputation at any time, but particularly when they are risking hundreds of millions to billions of dollars on M&A.

In many cases as well, there are broader issues of national security, so it’s imperative that companies seek to recognize and mitigate these risks as part of their M&A processes moving forward. Even governments sometimes attempt to mitigate these risks by conducting national security reviews and occasionally rejecting bids based on their findings.[i] Threat actors from many countries engage in economic espionage, making for a wide and varied threat landscape that cannot be handled by the government alone. For examples of just how diverse and crowded a space the targeted threat landscape is becoming, see our recent blog posts on Molerats, Saffron Rose, and Russia and Ukraine.

[i] “The Committee on Foreign Investment in the United States (CFIUS).” U.S. Department of the Treasury. 20 Dec. 2012. Web. 28 May 2014.

Clandestine Fox, Part Deux

June 10, 2014 | By Mike Scott | |

Comments

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.

Filename	MD5 Hash
resume.rar	8b42a80b2df48245e45f99c1bdc2ce51
readme.txt	8c6dba68a014f5437c36583bbce0b7a4
resume.pdf	ee2328b76c54dc356d864c8e9d05c954
ttcalc.exe	e6459971f63612c43321ffb4849339a2

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:

Description	MD5 hash
md5	1a4b710621ef2e69b1f7790ae9b7a288
.text	917c92e8662faf96fffb8ffe7b7c80fb
.rdata	975b458cb80395fa32c9dda759cb3f7b
.data	3ed34de8609cd274e49bbd795f21acc4
.rsrc	b1a55ec420dd6d24ff9e762c7b753868
.reloc	afd753a42036000ad476dcd81b56b754
Import Hash	fad20abf8aa4eda0802504d806280dd7
Compile date	2014-05-27 15:48:13

Contents of vc.bat:

@echo offcmd.exe /C start rundll32.exe “C:\Documents and Settings\admin\Application Data\mt.dat” UpdvaMt

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.”

Filename	MD5 hash
my resume and projects.rar	ab621059de2d1c92c3e7514e4b51751a
SETUP.exe	510b77a4b075f09202209f989582dbea
my resume.pdf	d1b1abfcc2d547e1ea1a4bb82294b9a3

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.

Filename	MD5 hash
CHANGELOG	4692337bf7584f6bda464b9a76d268c1
COPYRIGHT	7cae5757f3ba9fef0a22ca0d56188439
README	1a7ba923c6aa39cc9cb289a17599fce0
ttcalc.chm	f86db1905b3f4447eb5728859f9057b5
ttcalc.exe	37c6d1d3054e554e13d40ea42458ebed
ttcalcBAK.exe	3e7430a09a44c0d1000f76c3adc6f4fa

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.

Filename	MD5 hash
chrome_frame_helper.dll	98eb249e4ddc4897b8be6fe838051af7
chrome_frame_helper.dll.hlp	1b57a7fad852b1d686c72e96f7837b44
chrome_frame_helper.exe	ffb84b8561e49a8db60e0001f630831f

Metadata	MD5 hash
chrome_frame_helper.dll	98eb249e4ddc4897b8be6fe838051af7
.text	dfb4025352a80c2d81b84b37ef00bcd0
.rdata	4457e89f4aec692d8507378694e0a3ba
.data	48de562acb62b469480b8e29821f33b8
.reloc	7a7eed9f2d1807f55a9308e21d81cccd
Import hash	6817b29e9832d8fd85dcbe4af176efb6
Compile date	2014-03-22 11:08:34

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.

Molerats, Here for Spring!

June 2, 2014 | By Timothy Dahms | |

Comments

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:

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.
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.”

New Attacks, Same Old Tactics

With the reuse of command and control (CnC) infrastructure and a similar set of TTPs, Molerats activity has been tracked and expanded to a growing target list, which includes:

Palestinian and Israeli surveillance targets
Government departments in Israel, Turkey, Slovenia, Macedonia, New Zealand, Latvia, the U.S., and the UK
The Office of the Quartet Representative
The British Broadcasting Corporation (BBC)
A major U.S. financial institution
Multiple European government organizations

Previous Molerats campaigns have used several garden-variety, freely available backdoors such as CyberGate and Bifrost, but, most recently, we have observed them making use of the PIVY and Xtreme RATs. Previous campaigns made use of at least one of three observed forged Microsoft certificates, allowing security researchers to accurately tie together separate attacks even if the attacks used different backdoors. There also appears to be a habitual use of lures or decoy documents – in either English or Arabic-language – with content focusing on active conflicts in the Middle East. The lures come packaged with malicious files that drop the Molerats’ flavor of the week, which happen to all be Xtreme RAT binaries in these most recent campaigns.

Groundhog Day

On 27 May we observed at least one victim downloading a malicious .ZIP file as the result of clicking on a shortened Google URL – http://goo[.]gl[/]AMD3yX – likely contained inside of a targeted spearphishing email. However, we were unable to confirm for this particular victim:

molerats2

1) “حصري بالصور لحظة الإعتداء على المشير عبد الفتاح السيسي.scr”  (MD5: a6a839438d35f503dfebc6c5eec4330e)

Malicious download URL was sent to a well-known European government organization.
The shortened URL breaks out to “http://lovegame[.]us/ Photos[.]zip,” which was clicked/downloaded by the victim.
The extracted binary, “حصري بالصور لحظة الإعتداء على المشير عبد الفتاح السيسي.scr,” opens up a decoy Word document and installs/executes the Xtreme RAT binary into a temp directory, “Documents and Settings\admin\Local Settings\Temp\Chrome.exe.”
The decoy document, “rotab.doc,” contains three images (a political cartoon and two edited photos), all negatively depicting former military chief Abdel Fattah el-Sisi.
Xtreme RAT binary dropped: “Chrome.exe” (MD5: a90225a88ee974453b93ee7f0d93b104), which is unsigned.
As of 29 May, the URL has been clicked 225 times by a variety of platforms and browser types, so the campaign was likely not limited to just one victim.
Two of the download referrers are webmail providers (EIM.ae” and “Sltnet.lk”) further indicating the malicious URL was likely disseminated via spearphishing emails.

On 29 April we observed two unique malicious attachments being sent to two different victims via spearphishing emails:

2) 8ca915ab1d69a7007237eb83ae37eae5

Malicious file sent to both the financial institution and Ministry of Foreign Affairs targets.
Drops an Arabic language decoy document titled “Sisi.doc”, which appears to contain several copy/pasted excerpts of (now retired) Egyptian Major General Hossam Sweilem, discussing military strategy and the Muslim Brotherhood.
The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic. As noted in our August 2013 blog post, this could possibly be a poor attempt to frame China-based threat actors for these attacks.
Xtreme RAT binary dropped: “sky.exe” (MD5: 2d843b8452b5e48acbbe869e51337993), which is unsigned.

3) “Too soon to embrace Sisi _ Egypt is an unpredictable place.scr” (MD5: 7f9c06cd950239841378f74bbacbef60)

Malicious file only sent to a European government organization.
Drops an English language decoy document also titled “Sisi.doc”, however this one appears to be an exact copy of a 23 April Financial Times’ news article about the uncertainties surrounding former military chief Abdel Fattah el-Sisi running for president in the upcoming Egyptian elections.
Drops the same Xtreme RAT binary: “sky.exe” (MD5: 2d843b8452b5e48acbbe869e51337993), which is unsigned.

Another attribute regularly exhibited by Molerats malware samples are that they are often archived inside of self-extracting RAR files and encoded with EXECryptor V2.2, along with several other legitimate looking archived files.

Related Samples

Both of the malicious files above have a compile date/time of 2014-04-17 09:43:29-0000, and, based on this information, we were able to identify five additional samples (one sample only contained a lure but no malicious binary), related to the 29 April attacks. These samples were a little more interesting, because they contained an array of either attempted forged or self-signed Authenticode certificates.

All of the additionally identified samples were sent to one of the same European government organizations mentioned previously.

4) 2b0f8a8d8249402be0d83aedd9073662

Drops an Arabic language Word Document titled “list.doc”.
The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
Xtreme RAT binary dropped: “Download.exe” (MD5: cff48ff88c81795ee8cebdc3306605d0). This malware is signed with a self-signed certificate issued by “FireZilla” (see below).Certificate serial number: {75 dd 9b 14 c6 6e 20 0b 2e 22 95 3a 62 7b 39 19}.

Forged FireZilla certificate

5) 4f170683ae19b5eabcc54a578f2b530b

Drops an Arabic language Word Document titled “points.doc,” which appears to be an online clipping from a news article about ongoing Palestinian reconciliation meetings between Fatah and Hamas in the Gaza strip.
The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
Xtreme RAT binary dropped: “VBB.exe” (MD5: 6f9585c8748cd0e7103eab4eda233666). Though the malware appeared to be signed with a certificate named “Kaspersky Lab”, the real hash did not match the signed hash (see below).Certificate serial number: {a7 ed a5 a2 15 c0 d1 91 32 9a 1c a4 b0 53 eb 18}.

(Forged Kaspersky Lab certificate)

6) 793b7340b7c713e79518776f5710e9dd & a75281ee9c7c365a776ce8d2b11d28da

Both drop an Arabic language Word Document titled “qatar.doc,” which appears to be an online clipping for a new article concerning members of the Gulf Cooperation Council (GCC) and the ongoing conflicts between Saudi Arabia, the United Arab Emirates (UAE), and Bahrain – all against Qatar because of the country’s support for the Muslim Brotherhood.
The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
Xtreme RAT binary dropped by the first sample: “AVG.exe” (MD5: a51da465920589253bf32c6115072909), which is unsigned.

7) Pivoting off one of the fake Authenticode certificates we were able to identify at least one additional related binary, “vmware.exe” (MD5: 6be46a719b962792fd8f453914a87d3e), also Xtreme RAT, but doesn’t appear to have been sent to any of our customers. The malicious binary is also encoded with EXECryptor V2.2–similar to the samples above–and the CnC domain has resolved to IPs that overlap with previously identified Molerats malware.

Indicators of Compromise

Although the samples above are all Xtreme RAT, all but two samples communicate over different TCP ports. The port 443 callback listed in the last sample is also not using actual SSL, but instead, the sample transmits communications in clear-text – a common tactic employed by adversaries to try and bypass firewall/proxy rules applying to communications over traditional web ports. These tactics, among several others mentioned previously, seem to indicate that Molerats are not only aware of security researchers’ efforts in trying to track them but are also attempting to avoid using any obvious, repeating patterns that could be used to more easily track endpoints infected with their malware.

Conclusion

Although a large number of attacks against our customers appear to originate from China, we are tracking lesser-known actors also targeting the same firms. Molerats campaigns seem to be limited to only using freely available malware; however, their growing list of targets and increasingly evolving techniques in subsequent campaigns are certainly noteworthy.

MD5 Samples

a6a839438d35f503dfebc6c5eec4330e
7f9c06cd950239841378f74bbacbef60
8ca915ab1d69a7007237eb83ae37eae5
2b0f8a8d8249402be0d83aedd9073662
4f170683ae19b5eabcc54a578f2b530b
793b7340b7c713e79518776f5710e9dd
a75281ee9c7c365a776ce8d2b11d28da
6be46a719b962792fd8f453914a87d3e

Older Molerats samples from Dec 2013 (not listed above)

34c5e6b2a988076035e47d1f74319e86
13e351c327579fee7c2b975b17ef377c
c0488b48d6aabe828a76ae427bd36cf1
14d83f01ecf644dc29302b95542c9d35

References & Credits

A special thanks to Ned Moran and Matt Briggs of FireEye Labs for supporting this research.

“Operation Clandestine Fox” Now Attacking Windows XP Using Recently Discovered IE Vulnerability

May 1, 2014 | By Dan Caselden and Xiaobo Chen |

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.

New Zero-Day Exploit targeting Internet Explorer Versions 9 through 11 Identified in Targeted Attacks

April 26, 2014 | By Xiaobo Chen, Dan Caselden and Mike Scott |

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.

Spear Phishing the News Cycle: APT Actors Leverage Interest in the Disappearance of Malaysian Flight MH 370

March 24, 2014 | By Ned Moran and Alex Lanstein |

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:

IP Address	First Seen	Last Seen
103.31.241.110	2013-08-27	2013-08-28
174.139.242.19	2013-08-28	2013-08-31
58.64.153.157	2013-09-03	2014-03-07
59.188.0.197	2014-03-07	2014-03-19

White Paper

Protecting Your Data, Intellectual Property, and Brand from Cyber Attacks

Webcast

Product Demo

White Paper

Advanced Targeted Attacks

White Paper

Spear Phishing Attacks

Video

The New Threat Landscape

Brochure

FireEye Corporate Overview

Blog

Category Archives: Targeted Attack

Black Hat USA Talks - Leviathan: Command And Control Communications On Planet Earth

Operation Poisoned Hurricane

Pacific Ring of Fire: PlugX / Kaba

Delivering the Attacks

Command and Control

SideBar

RasTLS

PlugX Encryption Algorithm

PlugX / Kaba Trending

Conclusion

Havex, It’s Down With OPC

Mergers and Acquisitions: When Two Companies and APT Groups Come Together

Molerats, Here for Spring!

“Operation Clandestine Fox” Now Attacking Windows XP Using Recently Discovered IE Vulnerability

Mitigation

Details

New Zero-Day Exploit targeting Internet Explorer Versions 9 through 11 Identified in Targeted Attacks

The Details

Exploitation

• Preparing the heap

• Arbitrary memory access

• Runtime ROP generation

• ROP and Shellcode

Mitigation

Threat Group History

Spear Phishing the News Cycle: APT Actors Leverage Interest in the Disappearance of Malaysian Flight MH 370