Blog

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


The History of XXShenqi and the Future of SMS Phishing

On Aug 3rd, Chinese social media websites reported on the latest and largest SMS phishing (smishing for short) attack in China. The public security authorities of multiple cities in Guangdong, Jiangxi, and Jiangsu provinces have posted on their blogs warning Android users of this latest phishing attempt. As shown in Fig. 1, by the time the exploitation attempts were identified, over 100,000 Android users were infected and over 20 Million SMS were sent by the phishing malware. On average, each user was charged ¥30 (RMB) or about US$5.

android1

Fig. 1. Timeline of the XXShenqi malware infecting over 100,000 Android users

The package name of this new SMS phishing malware is com.example.xxshenqi and the app name appears as XX神器 (XX Powerful Equipment). As shown in Fig. 2, the icon and the title of the malware give the impression of a video player to attract common Android users.

According to QQ WeChat news, the malware was written out of boredom by a 19 year old freshman student of Central South University on Jul 24th and sent out from his cell phone on Jul 28th. By Aug 3rd, the malware had drawn attention from public media; nine hours later, police authorities had identified and detained the hacker.

Not only is the Android software being distributed a costly nuisance, but it also contains another embedded, malicious apk file that intercepts and sends SMS messages to the hacker’s email address. The behavior has been detected by FireEye Mobile Threat Protection platform in Fig. 8 and will be explained in detail later. Both the main malware and the embedded malware are not publicly well known according to VirusTotal until very recently:

The detection of the main malware is just 5 out of 53 anti-virus vendors:

android2

Fig. (a)

Out of 53 different anti-virus vendors, only two were able to detect it the embedded Trogoggle malware:

android3

Fig. (b)

Prequel – Known SMS Phishing Malware:

SMS phishing is a well-known type of malware in the Android world. It collects personal information through SMS while masquerading as a trustworthy app.

For example in 2012, a Russian smishing malware – neobook.rubakov.strah (version 1.8), sent premium SMS text message with hashed contents to a predefined number that would enable in-app purchases. Based on FireEye Dynamic Threat Intelligence, that app was downloaded thousands of times before it was taken down from Google Play.

Another Spanish smishing malware popular in 2013 was com.ikangoo.whatssex (version 1.7). It mimicked the Whatsapp icon with title Wassapp del Sexo, or Sex Wassapp in English. It has been removed from Google Play but is still available from the developer’s website. This malware would send SMS with user’s device ID for payment purposes at least in one of the older versions.

There have been many smiting malwares to appear in the last few years and the XXShenqi is not as novel as it seems to be.

New SMS Regulation in Android:

Due to the historical prevalence of SMS phishing, the Android platform began to tighten the reading and writing rights of SMS for Android developers.

In Android 4.4 (KitKat), the concept of the default SMS app was introduced, allowing users to choose their default SMS app. Only the default SMS app would be allowed receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Furthermore, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.

However in Android 4.4, non-default SMS apps can still send SMS if it has the SEND_SMS permission.  In the Android developer’s page of sendMultipartTextMessage method, it reads: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).

As shown in Fig. 3 and Fig. 8, the XXShenqi SMS phishing malware can still operate in Android 4.4 however because it has the SEND_SMS permission.

Technical Analysis of XXShenqi:

After installation, the icon of the malware appears as the following:

android4

Fig. 2. The icon of the “XX神器“ (XXShenqi) malware

Most Android applications use MainActivity class as an entry point, however, according to the AndroidManifest.xml configuration file in the malicious application, XXShenqi calls WelcomeActivity class to evade signature-based anti-virus detection. The WelcomeActivity class is then used to send SMS phishing to contacts located in the Android user’s contact list.

android5

As shown in the source code above, the ReadCONTACTS()method is called to send the link to the malicious apk file to all contacts. Below is a detailed analysis of the ReadCONTACTS()method:

android6

WelcomeActivity.this.phoneString is the phone number of the entry in the contact list, and WelcomeActivity.this.nameString is the contact name of the entry.

android7

Fig. 3. The abnormal SMS traffic detected by the FireEye MTP platform

Individuals who are a member of the victim’s contact list will then receive a copy of the link to the malicious apk. Assuming the individual receives the text, downloads the file, opens the file and side loads the APK file into the phone, the individual will then spread the malware to other individuals who are in the their contact list. It’s important to note that these methods for downloading apps are common in many regions where Google Play is not the dominant Android app market.

While sending the SMS, the malware starts the MainActivity, popping up a window to install the trojan SMS uploader embedded in the XXShenqi app – com.example.com.android.trogoogle . The message reads: Please install the installation package which has been included into the app. The installation can be done by clicking the install button.  After the install button is clicked, the trojan SMS sender will be installed on the device and run in the background because it kills its processes once the job is done.

android8

Fig. 4. The pop up window asking for permission to install the embedded malware

The malware then shows the two pages depicted in Fig. 5: the login page and the registration page. The login page asks for the username and password and has two buttons: login and register.

If the user clicks register, a registration page opens, as shown in the right picture of Fig. 5, requesting a username, password, citizen ID number, and their real name. The bottom button is the register button.

android9

Fig. 5. The login page (Left) and the registration page (Right) of XXShenqi

Usernames for either of the pages are not connected to any real services. The registration page does however verify the citizen ID number by checking the format, the length, and the inherent coding of the number. A random number of “1234567890” will trigger a pop up of Please input the correct citizen ID number, as shown on the bottom right of Fig. 5.

After inputting an acceptable citizen ID number, as shown in the left picture of Fig. 6, and clicking the register button, a pop up of Successful registration! is displayed at the bottom, as shown on the right picture of Fig. 6.

android10

Fig. 6. The malware checks the format, the length and the inherent coding of the 18-digit citizen ID number in the registration page (Left) before showing successful registration! (Right)

As demonstrated in the code snippet below, the credentials do not attempt to log into any accounts.

android11

In the code, if the log in is successful, it just shows being verified; please wait… and wrong password, or username doesn’t exist. The two toasts are shown at the bottom of both screenshots in Fig. 7:

android12

Fig. 7. The fake pages of verification (Left) and the error message of wrong password or the account doesn’t exist. (Right)

While the Android user is distracted by the login and registration pages, in the MainActivity class, a subclass of BroadcastReceiver called MyReceiver is started. The MyReceiver class is to start the com.example.com.android.trogoogle to send SMS messages to the hacker.

As shown in the source code below, it sends the SMS to an email address and kills its process after completing so that neither thread is seen from the Android system setting tab, nor is the icon shown in the home screen of the phone.

android13

 

android14

Fig. 8. More abnormal SMS traffic in the embedded malware as detected by the FireEye MTP platform

Even when the hacker was finally identified and detained, the only way that authorities could stop the exponential expansion of infected users was by removing the app from its web hosting service. Yet the malware can easily be resurrected when repackaged and hosted in numerous cloud storage services. As few security mechanisms and detection capabilities exist for mobile malware, it’s easy to see why 20 million SMS were sent and 100,000 users were infected in only a few days.

Another reason for the spread is the social engineering aspect of smartphones where individuals tend to trust the links sent by someone on their contact lists. This is particularly true as we do share links containing pictures or even executable files over the SMS to groups from time to time.

Finally, many individuals believe that they cannot get malware on their devices still. This lowers the guard for the individual using the phone, making them more likely to click on a random link. Individuals should be educated that unexpected links such as bargain recommendation or prize information may be not only harmless tricks but also malicious phishing attempts. Even if the device in question is just smart phone or tablet, the same precautions that are taken on a PC should be the same as those on a mobile device.

Prediction of Further SMS Phishing Attacks:

FireEye analysis of this series of SMS phishing and sending malware that infected over 100,000 users in China and charged $500,000 SMS fees in a few days could continue to expand exponentially even though the hacker has been detained.

The growth rate of this SMS phishing malware reveals the fact that such app can be developed easily and spread epidemically in the future. Although the Android OS has received certain fixes to its wide open permissions for reading and sending SMS in KitKat, malware can still send out SMS in those versions, meaning the newer versions of Android can’t prevent the prevalence of such malware.

Black Hat USA Talks: Investigating PowerShell Attacks

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

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

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

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 Poisoned Hurricane: Lessons for CISOs

The tactics described in “Operation Poisoned Hurricane” should come as a stark reminder that advanced threat actors do not stand still. They continue to refine their tradecraft, finding new and innovative ways to bypass security controls and evade detection.

The technical details of the evasion techniques are complex, but the lessons for the CISO are clear:

  1. Traffic to a legitimate website is not always legitimate traffic – malware could be hiding command and control communications in traffic to reputable sites.
  2. Don’t allow direct Internet access, ever. The DNS hijacking described in the blog relies on directly sending DNS queries.
  3. File-based malware controls are being successfully evaded in the wild.

What can you do to protect your organisation from these threats? My suggestions are:

  1. Make sure you have a well-architected Internet proxy architecture that prevents direct connectivity from your network:
    • Never allow hosts other than your secure external DNS resolver to send DNS queries to the Internet. Period.
    • Record all internal DNS queries, these are a possible sign of a compromised machine.
  2. Put in place a malware detection solution that can identify multi-vector, multi-stage malware execution:
    • These attacks used legitimate, signed binaries from a known security company to load malicious code contained in other files as part of a multi-stage attack. File-oriented security controls do not detect these attacks, you need a full behavioural analytics engine to see the attack.
    • Don’t assume that a signed binary is safe. Automated analysis of code behaviour in an execution environment is critical.
  3. Ensure you can detect and block command & control traffic from compromised users, even if it is to legitimate websites:
    • Sophisticated attackers can use blogs, code repositories, even comments on social media, to send and receive command & control signals.
    • Reputation-based detection is not sufficient, you need detection and protection that can understand new command and control tactics based on automated behavioural analysis.

The attackers are evolving their attacks, are you evolving your defenses fast enough to keep them out?

Your Locker of Information for CryptoLocker Decryption

Ransomware is a particularly nasty piece of malware that takes infected machines hostage. CryptoLocker was successful at garnering  multi-millions in ransom payments the first two months of CryptoLocker’s distribution, according to a recent blog by FireEye regarding the takeover of CryptoLocker infrastructure – Operation Tovar.

Operation Tovar helped tear down the infrastructure used by attackers, but there are still many instances where users are still being infected with ransomware. After the success of Operation Tovar, there were few resources available to help decrypt files that were still encrypted with the attacker’s private key.

While not particularly innovative, CryptoLocker was successful because it encrypts the files of computers it infected and then demanded a ransom for a private key to decrypt those files. The harsh reality of a situation like this is, not many people back up their data. In some cases, the backups would be encrypted if mounted to an infected machine. As a result, many of the victims felt helpless at this point, and paid the ransom – typically around $300. A simple description of the way that CryptoLocker works can be found below:

  1. CryptoLocker arrives on a victim’s machine through a variety of techniques such as spear-phishing emails or watering hole attacks.
  2. CryptoLocker then connects to randomly generated domain (via DGAs) to download a specific RSA public key.
  3. At that point, an AES-256 key is created for each file on the system.
  4. CryptoLocker then encrypts all of the supported files using the generated key from step 3.
  5. The generated key is then encrypted with the downloaded RSA public key from step 2.
  6. And finally, the AES-key is written to the beginning of the encrypted files, thus requiring the private key to decrypt.
crypto1

Figure 1: Screenshot of victim machine infected with CryptoLocker

Not all CryptoLocker variants are created equal. There are several copycats and hybrid versions of Crytpolocker that exist, ranging from programs like CryptoDefense, PowerLocker, TorLocker and CryptorBit, to variants that are not necessarily named but have modified functionality, such as using Yahoo Messenger as a propagation technique.

Decryption Assistance

To help solve the problem of victims’ files still being encrypted, we leveraged our close partnership with Fox-IT. We developed a decryption assistance website and corresponding tool designed to help those afflicted with the original CryptoLocker malware. Through various partnerships and reverse engineering engagements, Fox-IT and FireEye have ascertained many of the private keys associated with CryptoLocker.  Having these private keys allows for decryption of files that are encrypted by CryptoLocker.

FireEye and Fox IT have created a webpage, https://www.decryptcryptolocker.com, where a user can upload an encrypted CryptoLocker file.  Based on this upload, the user will be provided with the option to download a private key that should decrypt their affected files. The site also provides instructions on how to apply this key to the files encrypted by CryptoLocker to decrypt those files.

To use the site, simply upload an encrypted file without any confidential information. (Please keep in mind, we will not permanently store, view, or modify your file in any fashion.) Enter your email address, to ensure the private key associated with the file is sent to the correct individual. Ensure you enter the correct number or phrase in the Captcha entry field.

crypto2

Figure 2: Screenshot of https://www.DecryptCryptoLocker.com

After clicking “Decrypt It!”, you will be presented with instructions to download the Decryptolocker.exe tool from https://www.decryptCryptoLocker.com (Figure 3). In addition, your private key will be sent to the email addresses specified.

crypto32

Figure 3: DecryptCryptoLocker decryption result page

After receiving the email (Figure 4), you will then select the key and utilize it in conjunction with Decryptolocker.exe.

crypto4

Figure 4: Email containing private key

At this point, the user opens a Windows Command Prompt, and browses to the directory of the Decryptolocker.exe tool and the locked file.  (Please note that the directory of the locked file must be specified if the file is not local to the tool’s directory.) The user must enter the command exactly as specified on the successful decryption page. The command structure should be used as the following:

Decryptolocker.exe –key “<key>” <Lockedfile.doc>

Upon successful execution of the tool, the user should be presented with a prompt indicating decryption was successful (Figure 5).

crypto5

Figure 5: Successful decryption of File1-1.doc

Conclusion

Operation Tovar made a clear impact on the distribution of and infection of machines by CryptoLocker. However, there have been no known avenues available designed to help users get their encrypted files back without making significant payments to those responsible for infecting machines in the first place. While the remediation of infected machines can be somewhat difficult, hopefully with the help of https://www.decryptCryptoLocker.com and Decryptolocker.exe, we can help you get back some of the valuable files that may still be encrypted.

As always, to help prevent a threat like this from affecting you and your data, ensure you backup your data. Ideally, this would be done in at least two locations: One would be on premises (such as an external hard drive), and the other would be off premises (such as cloud storage).

View the free, on-demand webinar DeCryptoLocker: Relief for CryptoLocker Victims for additional information.

FAQ

Are all encrypted files afflicted with CryptoLocker decryptable with this tool?

We believe we recovered everything the from the CryptoLocker database. However, we are aware that there could be a limited data chunk that could be missing which is related to either the takedown or interruptions of the CryptoLocker backend infrastructure. As a result, certain files may not be decryptable. Also, new variants of CryptoLocker may be released at any time, and the tools we discuss here or have made available may not be able to decrypt files infected with these more recent variants.

Does this tool work against CryptoLocker variants?

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, this tool may not be successful in all decryption processes because of code and functionality variances.

Does any of our data get stored by FireEye or Fox-IT?

Under no circumstances does personal data get stored, processed or examined by FireEye or Fox-IT when using this tool.

Is this service free?

The Decryptolocker.exe tool is available at no cost via the website to anyone that has been compromised with CryptoLocker.

How can I use the Decryptolocker.exe tool?

The Decryptolocker.exe tool is designed to perform a few different types of functions.  Here are some examples of various prompts you can enter, depending on the result you would like to obtain.

1) If you would like to test a file if it is encrypted with CryptoLocker, you can enter:
Decryptolocker.exe –find File1.doc

2) If you would like to find all files encrypted with CryptoLocker in a directory, you can enter:

Decryptolocker.exe –find -r “C:\FolderName”

Note: Remember to include the “-r”

3) If you would like to decrypt a file encrypted with CryptoLocker, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” File1.doc

4) If you would like to decrypt all files in a folder, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” C:\FolderName\*

Note: Remember to include the “*” at the end

5) If you would like to decrypt all the files in a folder or drive recursively, you can enter:

Decryptolocker.exe –key  “<your private key provided in email>” -r C:\

Note: Decryptolocker.exe creates a backup of all encrypted files in the same directory before writing the decrypted file. If you do not have enough space for these files, then the prompt may not execute, and your computer may run more slowly.  Ensure you have sufficient file space before proceeding.

 

Disclaimers

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, the tools discussed here may not successfully decrypt files encrypted by every variant because of differences in the programs or for other reasons. Also, while we have many unlocking keys, there is a possibility that we will be unable to decrypt your files.

References


http://www.fireeye.com/blog/technical/2014/07/operation-tovar-the-latest-attempt-to-eliminate-key-botnets.html

http://blog.fortinet.com/A-Closer-Look-at-CryptoLocker-s-DGA/

https://www.fox-it.com/en/

Operation Arachnophobia: An Introduction

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

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

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

Threat Research


Filter by Category:


The History of XXShenqi and the Future of SMS Phishing

On Aug 3rd, Chinese social media websites reported on the latest and largest SMS phishing (smishing for short) attack in China. The public security authorities of multiple cities in Guangdong, Jiangxi, and Jiangsu provinces have posted on their blogs warning Android users of this latest phishing attempt. As shown in Fig. 1, by the time the exploitation attempts were identified, over 100,000 Android users were infected and over 20 Million SMS were sent by the phishing malware. On average, each user was charged ¥30 (RMB) or about US$5.

android1

Fig. 1. Timeline of the XXShenqi malware infecting over 100,000 Android users

The package name of this new SMS phishing malware is com.example.xxshenqi and the app name appears as XX神器 (XX Powerful Equipment). As shown in Fig. 2, the icon and the title of the malware give the impression of a video player to attract common Android users.

According to QQ WeChat news, the malware was written out of boredom by a 19 year old freshman student of Central South University on Jul 24th and sent out from his cell phone on Jul 28th. By Aug 3rd, the malware had drawn attention from public media; nine hours later, police authorities had identified and detained the hacker.

Not only is the Android software being distributed a costly nuisance, but it also contains another embedded, malicious apk file that intercepts and sends SMS messages to the hacker’s email address. The behavior has been detected by FireEye Mobile Threat Protection platform in Fig. 8 and will be explained in detail later. Both the main malware and the embedded malware are not publicly well known according to VirusTotal until very recently:

The detection of the main malware is just 5 out of 53 anti-virus vendors:

android2

Fig. (a)

Out of 53 different anti-virus vendors, only two were able to detect it the embedded Trogoggle malware:

android3

Fig. (b)

Prequel – Known SMS Phishing Malware:

SMS phishing is a well-known type of malware in the Android world. It collects personal information through SMS while masquerading as a trustworthy app.

For example in 2012, a Russian smishing malware – neobook.rubakov.strah (version 1.8), sent premium SMS text message with hashed contents to a predefined number that would enable in-app purchases. Based on FireEye Dynamic Threat Intelligence, that app was downloaded thousands of times before it was taken down from Google Play.

Another Spanish smishing malware popular in 2013 was com.ikangoo.whatssex (version 1.7). It mimicked the Whatsapp icon with title Wassapp del Sexo, or Sex Wassapp in English. It has been removed from Google Play but is still available from the developer’s website. This malware would send SMS with user’s device ID for payment purposes at least in one of the older versions.

There have been many smiting malwares to appear in the last few years and the XXShenqi is not as novel as it seems to be.

New SMS Regulation in Android:

Due to the historical prevalence of SMS phishing, the Android platform began to tighten the reading and writing rights of SMS for Android developers.

In Android 4.4 (KitKat), the concept of the default SMS app was introduced, allowing users to choose their default SMS app. Only the default SMS app would be allowed receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Furthermore, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.

However in Android 4.4, non-default SMS apps can still send SMS if it has the SEND_SMS permission.  In the Android developer’s page of sendMultipartTextMessage method, it reads: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).

As shown in Fig. 3 and Fig. 8, the XXShenqi SMS phishing malware can still operate in Android 4.4 however because it has the SEND_SMS permission.

Technical Analysis of XXShenqi:

After installation, the icon of the malware appears as the following:

android4

Fig. 2. The icon of the “XX神器“ (XXShenqi) malware

Most Android applications use MainActivity class as an entry point, however, according to the AndroidManifest.xml configuration file in the malicious application, XXShenqi calls WelcomeActivity class to evade signature-based anti-virus detection. The WelcomeActivity class is then used to send SMS phishing to contacts located in the Android user’s contact list.

android5

As shown in the source code above, the ReadCONTACTS()method is called to send the link to the malicious apk file to all contacts. Below is a detailed analysis of the ReadCONTACTS()method:

android6

WelcomeActivity.this.phoneString is the phone number of the entry in the contact list, and WelcomeActivity.this.nameString is the contact name of the entry.

android7

Fig. 3. The abnormal SMS traffic detected by the FireEye MTP platform

Individuals who are a member of the victim’s contact list will then receive a copy of the link to the malicious apk. Assuming the individual receives the text, downloads the file, opens the file and side loads the APK file into the phone, the individual will then spread the malware to other individuals who are in the their contact list. It’s important to note that these methods for downloading apps are common in many regions where Google Play is not the dominant Android app market.

While sending the SMS, the malware starts the MainActivity, popping up a window to install the trojan SMS uploader embedded in the XXShenqi app – com.example.com.android.trogoogle . The message reads: Please install the installation package which has been included into the app. The installation can be done by clicking the install button.  After the install button is clicked, the trojan SMS sender will be installed on the device and run in the background because it kills its processes once the job is done.

android8

Fig. 4. The pop up window asking for permission to install the embedded malware

The malware then shows the two pages depicted in Fig. 5: the login page and the registration page. The login page asks for the username and password and has two buttons: login and register.

If the user clicks register, a registration page opens, as shown in the right picture of Fig. 5, requesting a username, password, citizen ID number, and their real name. The bottom button is the register button.

android9

Fig. 5. The login page (Left) and the registration page (Right) of XXShenqi

Usernames for either of the pages are not connected to any real services. The registration page does however verify the citizen ID number by checking the format, the length, and the inherent coding of the number. A random number of “1234567890” will trigger a pop up of Please input the correct citizen ID number, as shown on the bottom right of Fig. 5.

After inputting an acceptable citizen ID number, as shown in the left picture of Fig. 6, and clicking the register button, a pop up of Successful registration! is displayed at the bottom, as shown on the right picture of Fig. 6.

android10

Fig. 6. The malware checks the format, the length and the inherent coding of the 18-digit citizen ID number in the registration page (Left) before showing successful registration! (Right)

As demonstrated in the code snippet below, the credentials do not attempt to log into any accounts.

android11

In the code, if the log in is successful, it just shows being verified; please wait… and wrong password, or username doesn’t exist. The two toasts are shown at the bottom of both screenshots in Fig. 7:

android12

Fig. 7. The fake pages of verification (Left) and the error message of wrong password or the account doesn’t exist. (Right)

While the Android user is distracted by the login and registration pages, in the MainActivity class, a subclass of BroadcastReceiver called MyReceiver is started. The MyReceiver class is to start the com.example.com.android.trogoogle to send SMS messages to the hacker.

As shown in the source code below, it sends the SMS to an email address and kills its process after completing so that neither thread is seen from the Android system setting tab, nor is the icon shown in the home screen of the phone.

android13

 

android14

Fig. 8. More abnormal SMS traffic in the embedded malware as detected by the FireEye MTP platform

Even when the hacker was finally identified and detained, the only way that authorities could stop the exponential expansion of infected users was by removing the app from its web hosting service. Yet the malware can easily be resurrected when repackaged and hosted in numerous cloud storage services. As few security mechanisms and detection capabilities exist for mobile malware, it’s easy to see why 20 million SMS were sent and 100,000 users were infected in only a few days.

Another reason for the spread is the social engineering aspect of smartphones where individuals tend to trust the links sent by someone on their contact lists. This is particularly true as we do share links containing pictures or even executable files over the SMS to groups from time to time.

Finally, many individuals believe that they cannot get malware on their devices still. This lowers the guard for the individual using the phone, making them more likely to click on a random link. Individuals should be educated that unexpected links such as bargain recommendation or prize information may be not only harmless tricks but also malicious phishing attempts. Even if the device in question is just smart phone or tablet, the same precautions that are taken on a PC should be the same as those on a mobile device.

Prediction of Further SMS Phishing Attacks:

FireEye analysis of this series of SMS phishing and sending malware that infected over 100,000 users in China and charged $500,000 SMS fees in a few days could continue to expand exponentially even though the hacker has been detained.

The growth rate of this SMS phishing malware reveals the fact that such app can be developed easily and spread epidemically in the future. Although the Android OS has received certain fixes to its wide open permissions for reading and sending SMS in KitKat, malware can still send out SMS in those versions, meaning the newer versions of Android can’t prevent the prevalence of such malware.

Black Hat USA Talks: Investigating PowerShell Attacks

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

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

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

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

Security Perspective


Filter by Category:


Operation Poisoned Hurricane: Lessons for CISOs

The tactics described in “Operation Poisoned Hurricane” should come as a stark reminder that advanced threat actors do not stand still. They continue to refine their tradecraft, finding new and innovative ways to bypass security controls and evade detection.

The technical details of the evasion techniques are complex, but the lessons for the CISO are clear:

  1. Traffic to a legitimate website is not always legitimate traffic – malware could be hiding command and control communications in traffic to reputable sites.
  2. Don’t allow direct Internet access, ever. The DNS hijacking described in the blog relies on directly sending DNS queries.
  3. File-based malware controls are being successfully evaded in the wild.

What can you do to protect your organisation from these threats? My suggestions are:

  1. Make sure you have a well-architected Internet proxy architecture that prevents direct connectivity from your network:
    • Never allow hosts other than your secure external DNS resolver to send DNS queries to the Internet. Period.
    • Record all internal DNS queries, these are a possible sign of a compromised machine.
  2. Put in place a malware detection solution that can identify multi-vector, multi-stage malware execution:
    • These attacks used legitimate, signed binaries from a known security company to load malicious code contained in other files as part of a multi-stage attack. File-oriented security controls do not detect these attacks, you need a full behavioural analytics engine to see the attack.
    • Don’t assume that a signed binary is safe. Automated analysis of code behaviour in an execution environment is critical.
  3. Ensure you can detect and block command & control traffic from compromised users, even if it is to legitimate websites:
    • Sophisticated attackers can use blogs, code repositories, even comments on social media, to send and receive command & control signals.
    • Reputation-based detection is not sufficient, you need detection and protection that can understand new command and control tactics based on automated behavioural analysis.

The attackers are evolving their attacks, are you evolving your defenses fast enough to keep them out?

Your Locker of Information for CryptoLocker Decryption

Ransomware is a particularly nasty piece of malware that takes infected machines hostage. CryptoLocker was successful at garnering  multi-millions in ransom payments the first two months of CryptoLocker’s distribution, according to a recent blog by FireEye regarding the takeover of CryptoLocker infrastructure – Operation Tovar.

Operation Tovar helped tear down the infrastructure used by attackers, but there are still many instances where users are still being infected with ransomware. After the success of Operation Tovar, there were few resources available to help decrypt files that were still encrypted with the attacker’s private key.

While not particularly innovative, CryptoLocker was successful because it encrypts the files of computers it infected and then demanded a ransom for a private key to decrypt those files. The harsh reality of a situation like this is, not many people back up their data. In some cases, the backups would be encrypted if mounted to an infected machine. As a result, many of the victims felt helpless at this point, and paid the ransom – typically around $300. A simple description of the way that CryptoLocker works can be found below:

  1. CryptoLocker arrives on a victim’s machine through a variety of techniques such as spear-phishing emails or watering hole attacks.
  2. CryptoLocker then connects to randomly generated domain (via DGAs) to download a specific RSA public key.
  3. At that point, an AES-256 key is created for each file on the system.
  4. CryptoLocker then encrypts all of the supported files using the generated key from step 3.
  5. The generated key is then encrypted with the downloaded RSA public key from step 2.
  6. And finally, the AES-key is written to the beginning of the encrypted files, thus requiring the private key to decrypt.
crypto1

Figure 1: Screenshot of victim machine infected with CryptoLocker

Not all CryptoLocker variants are created equal. There are several copycats and hybrid versions of Crytpolocker that exist, ranging from programs like CryptoDefense, PowerLocker, TorLocker and CryptorBit, to variants that are not necessarily named but have modified functionality, such as using Yahoo Messenger as a propagation technique.

Decryption Assistance

To help solve the problem of victims’ files still being encrypted, we leveraged our close partnership with Fox-IT. We developed a decryption assistance website and corresponding tool designed to help those afflicted with the original CryptoLocker malware. Through various partnerships and reverse engineering engagements, Fox-IT and FireEye have ascertained many of the private keys associated with CryptoLocker.  Having these private keys allows for decryption of files that are encrypted by CryptoLocker.

FireEye and Fox IT have created a webpage, https://www.decryptcryptolocker.com, where a user can upload an encrypted CryptoLocker file.  Based on this upload, the user will be provided with the option to download a private key that should decrypt their affected files. The site also provides instructions on how to apply this key to the files encrypted by CryptoLocker to decrypt those files.

To use the site, simply upload an encrypted file without any confidential information. (Please keep in mind, we will not permanently store, view, or modify your file in any fashion.) Enter your email address, to ensure the private key associated with the file is sent to the correct individual. Ensure you enter the correct number or phrase in the Captcha entry field.

crypto2

Figure 2: Screenshot of https://www.DecryptCryptoLocker.com

After clicking “Decrypt It!”, you will be presented with instructions to download the Decryptolocker.exe tool from https://www.decryptCryptoLocker.com (Figure 3). In addition, your private key will be sent to the email addresses specified.

crypto32

Figure 3: DecryptCryptoLocker decryption result page

After receiving the email (Figure 4), you will then select the key and utilize it in conjunction with Decryptolocker.exe.

crypto4

Figure 4: Email containing private key

At this point, the user opens a Windows Command Prompt, and browses to the directory of the Decryptolocker.exe tool and the locked file.  (Please note that the directory of the locked file must be specified if the file is not local to the tool’s directory.) The user must enter the command exactly as specified on the successful decryption page. The command structure should be used as the following:

Decryptolocker.exe –key “<key>” <Lockedfile.doc>

Upon successful execution of the tool, the user should be presented with a prompt indicating decryption was successful (Figure 5).

crypto5

Figure 5: Successful decryption of File1-1.doc

Conclusion

Operation Tovar made a clear impact on the distribution of and infection of machines by CryptoLocker. However, there have been no known avenues available designed to help users get their encrypted files back without making significant payments to those responsible for infecting machines in the first place. While the remediation of infected machines can be somewhat difficult, hopefully with the help of https://www.decryptCryptoLocker.com and Decryptolocker.exe, we can help you get back some of the valuable files that may still be encrypted.

As always, to help prevent a threat like this from affecting you and your data, ensure you backup your data. Ideally, this would be done in at least two locations: One would be on premises (such as an external hard drive), and the other would be off premises (such as cloud storage).

View the free, on-demand webinar DeCryptoLocker: Relief for CryptoLocker Victims for additional information.

FAQ

Are all encrypted files afflicted with CryptoLocker decryptable with this tool?

We believe we recovered everything the from the CryptoLocker database. However, we are aware that there could be a limited data chunk that could be missing which is related to either the takedown or interruptions of the CryptoLocker backend infrastructure. As a result, certain files may not be decryptable. Also, new variants of CryptoLocker may be released at any time, and the tools we discuss here or have made available may not be able to decrypt files infected with these more recent variants.

Does this tool work against CryptoLocker variants?

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, this tool may not be successful in all decryption processes because of code and functionality variances.

Does any of our data get stored by FireEye or Fox-IT?

Under no circumstances does personal data get stored, processed or examined by FireEye or Fox-IT when using this tool.

Is this service free?

The Decryptolocker.exe tool is available at no cost via the website to anyone that has been compromised with CryptoLocker.

How can I use the Decryptolocker.exe tool?

The Decryptolocker.exe tool is designed to perform a few different types of functions.  Here are some examples of various prompts you can enter, depending on the result you would like to obtain.

1) If you would like to test a file if it is encrypted with CryptoLocker, you can enter:
Decryptolocker.exe –find File1.doc

2) If you would like to find all files encrypted with CryptoLocker in a directory, you can enter:

Decryptolocker.exe –find -r “C:\FolderName”

Note: Remember to include the “-r”

3) If you would like to decrypt a file encrypted with CryptoLocker, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” File1.doc

4) If you would like to decrypt all files in a folder, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” C:\FolderName\*

Note: Remember to include the “*” at the end

5) If you would like to decrypt all the files in a folder or drive recursively, you can enter:

Decryptolocker.exe –key  “<your private key provided in email>” -r C:\

Note: Decryptolocker.exe creates a backup of all encrypted files in the same directory before writing the decrypted file. If you do not have enough space for these files, then the prompt may not execute, and your computer may run more slowly.  Ensure you have sufficient file space before proceeding.

 

Disclaimers

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, the tools discussed here may not successfully decrypt files encrypted by every variant because of differences in the programs or for other reasons. Also, while we have many unlocking keys, there is a possibility that we will be unable to decrypt your files.

References


http://www.fireeye.com/blog/technical/2014/07/operation-tovar-the-latest-attempt-to-eliminate-key-botnets.html

http://blog.fortinet.com/A-Closer-Look-at-CryptoLocker-s-DGA/

https://www.fox-it.com/en/

Black Hat USA 2014: The Ultimate Cybersecurity Event

Black Hat USA is about to return for its 17th year in Las Vegas, NV. The show will bring together the brightest minds in the world of cybersecurity for a six-day period where learning, networking, and skill-building top the activity list. FireEye will be there in full force.

Here is what you need to know:

  • Be on the Look Out: FireEye and Mandiant will have a presence at the conference in booths 411 and 246, respectively. You’ll be able to watch live demos, attend presentations, and get the latest updates on our full platform of technologies and services.
  • Jump into the Trenches: Join FireEye CTO Dave Merkel on Thursday, August 7 from 1-2PM for his insightful presentation “Lessons from the Trenches: Advanced Techniques for Dealing with Advanced Attacks” which will review the latest approaches attackers are using to compromise organizations and, more importantly, what the most innovative security teams are doing to stay ahead. Mr. Merkel will be drawing on data and anecdotes from hundreds of organizations, and will outline how leading security teams have reorganized, re-architected and realigned their security strategies.
  • Take a Practical View: Visit the FireEye booth (411) for ongoing presentations with a focus on various case studies that can be applied to everyday activities. Presentations will be interactive and include audience responses.
  • View Live Demonstrations: FireEye will have eight demo stations networked to live products and solutions to recreate real and recognizable environments.
  • Come out and Party: Join the FireEye crew for an event co-sponsored by Rapid7 on Wednesday, August 6 at XS Nightclub in Wynn/Encore. Register for the party here!
  • M After Dark: There is nothing quite like Mandiant’s “M After Dark” party, which will take place on August 5, from 7-9PM at the Eye Candy Sound Lounge at Mandalay Bay. Click here for registration information.

We hope to see you in Las Vegas the week of August 2 through August 7. If you are unable to attend, check back on the blog for insights from the conference.

 

 

Security as a Differentiator: Investis Partners With FireEye Managed Defense to Offer Its Clients the Very Best in Cybersecurity

This is a contributed post from Alex Booth, COO, Investis

As a provider of digital corporate communication services to many of the world’s leading companies, information security is of critical importance to us here at Investis. In order to be the world’s safest platform for managing digital communications and hosting corporate sites, we wanted the strongest security partner in the business. As COO of Investis, this was a critical decision which is why I wanted to share the reasons we chose FireEye Managed Defense. To give you the short version, though, the choice was easy – the long version of which you can see in the video below or get a synopsis of in this post…

We are an ISO 27001 certified company and a member of CISP, the UK government’s cybersecurity information partnership. We believe you can never take security too seriously, especially in a digital landscape with increasingly sophisticated cybercrime. With that in mind, we wanted the most advanced solution to protect our environment and clients, and FireEye was the perfect partner to help us safeguard against advanced threats.

FireEye is the cybersecurity partner of choice for many of the US’s largest firms and its subsidiary, Mandiant, was selected by the UK Government Communications Headquarters (GCHQ) as one of four vendors certified to respond to cybersecurity attacks targeting the UK’s national infrastructure.

As a result of an on-site assessment by Mandiant consultants, we chose to augment our security team with the FireEye Managed Defense service.

We are looking forward to working with the great team over at FireEye to ensure we offer our clients the very best in cybersecurity.

US GAO Report Highlights Incident Response Shortcomings

On May 30th, 2014, the US Government Accountability Office (GAO) released a report titled “Information Security: Agencies Need to Improve Cyber Incident Response Practices.” GAO conducted its research by randomly selecting six government agencies, then selecting a statistically significant number of incident reports (40 from each organization), documented during 2012. GAO then evaluated how the agencies performed, based on the reports. GAO compared the documented incident response actions to requirements set by the Federal Information Security Management Act of 2002 (FISMA) and National Institute of Standards and Technology (NIST) Special Publication 800-61, Computer Security Incident Handling Guide. The results were surprising and I will explain the significance of several excerpts in this post.

First, “agencies had recorded actions to halt the spread of, or otherwise limit, the damage caused by an incident in about 75 percent of incidents government-wide. However, agencies did not demonstrate such actions for about 25 percent of incidents government-wide.”

This comment references the need to contain an intrusion. If a government agency fails to completely contain an intrusion, any gaps leave the adversary freedom of maneuver. He can exploit the containment failure to proliferate to other systems and remain in control of an organization’s systems. Anything less than 100% containment is essentially 0% containment.

Second, “for about 77 percent of incidents government-wide, the agencies had identified and eliminated the remaining elements of the incident. However, agencies did not demonstrate that they had effectively eradicated incidents in about 23 percent of incidents.”

This comment references the need to remove an intruder from a compromised organization. Similar to the need for 100% containment, one must also achieve 100% removal in order to completely frustrate the adversary. If an adversary retains access to even one system, he can rebuild his position and retake control of the victim.

Third, “agencies returned their systems to an operationally ready state for about 81 percent of incidents government-wide. However, they had not consistently documented remedial actions on whether they had taken steps to prevent an incident from reoccurring. Specifically, agencies did not demonstrate that they had acted to prevent an incident from reoccurring in about 49 percent of incidents government-wide.”

This comment describes the need to learn from intrusions and implement remediation. If a victim fails to make the environment tougher for the adversary, the intruder will likely return using the same techniques that he utilized to first gain access.

Finally, a search of the entire GAO report for the word “strategy” produced zero hits. Beyond being disappointed by the three excerpts I highlighted above, I am dismayed to not hear GAO discuss the need for a security strategy for organizations. Incident response is not a technical action. IR should be part of a business process, done as part of an operation that implements a strategy understood and approved by the highest levels of management. Furthermore, the GAO report did not really evaluate the consequences of the three documented failures and the lack of concrete security strategies. Had GAO taken that step, they might have concluded that the agencies continue to face severe security challenges.