DualToy: New Windows Trojan Sideloads Risky Apps to Android and iOS Devices

This post is also available in: 日本語 (Japanese)

Over the past two years, we’ve observed many cases of Microsoft Windows and Apple iOS malware designed to attack mobile devices. This attack vector is increasingly popular with malicious actors as almost everyone on the planet carries at least one mobile device they interact with throughout any given day. Thanks to a relative lack of security controls applied to mobile devices, these devices have become very attractive targets for a broad range of malicious actors. For example:

• WireLurker installed malicious apps on non-jailbroken iPhones
• Six different Trojan, Adware and HackTool families launched “BackStab” attacks to steal backup archives of iOS and BlackBerry devices
• The HackingTeam’s RCS delivered its Spyware from infected PCs and Macs to jailbroken iOS devices and BlackBerry phones

Recently, we discovered another Windows Trojan we named “DualToy” which side loads malicious or risky apps to both Android and iOS devices via a USB connection.

When DualToy began to spread in January 2015, it was only capable of infecting Android devices. However, within six months the malicious actors added the capability to infect iOS devices. DualToy is still active and we have detected over 8,000 unique samples belonging to this Trojan family to date. It mainly targets Chinese users, but has also successfully affected people and organizations in the United States, United Kingdom, Thailand, Spain, and Ireland.

In addition to found in traditional Windows PC malware such as process injection, modifying browser settings, displaying advertisements et al, DualToy also performs the following activities on Android and iOS devices:

• Downloads and installs Android Debug Bridge (ADB) and iTunes drivers for Windows
• Uses existing pairing/authorization records on infected PCs to interact with Android and/or iOS devices via USB cable
• Downloads Android apps and installs them on any connected Android devices in the background, where the apps are mostly Riskware or Adware
• Copies native code to a connected Android device and directly executes it, and activates another custom to obtain root privilege and to download and install more Android apps in the background
• Steals connected iOS device’s information including IMEI, IMSI, ICCID, serial number and phone number
• Downloads an iOS app and installs it to connected iOS devices in the background; the app will ask for an Apple ID with password and send them to a server without user’s knowledge (just like AceDeceiver)

Several years ago, Android and iOS began requiring user interaction to authorize a device to pair to another device to prevent the kind of sideloading attack used by DualToy. However, DualToy assumes any physically connected mobile devices will belong to the same owner as the infected PC to which they are connected, which means the pairing is likely already authorized. DualToy tries to reuse existing pairing records to directly interact with mobile devices in the background. Although this attack vector’s capability can be further limited by additional mechanisms (e.g., ADB enabling, iOS sandbox) which make this threat not so severe, DualToy reminds us again how attackers can use USB sideloading against mobile devices and how malware can be spread between platforms.

Infecting Android Devices

Almost all samples of DualToy are capable of infecting Android devices connected with the compromised Windows PC via USB cable. This functionality is usually implemented in a module named NewPhone.dll, DevApi.dll or app.dll.

DualToy assumes ADB is enabled on the connected Android device. If ADB isn't enabled (which is the default option), the . However, some users, especially those who want to install Android apps from a PC or Mac, or who want to do advanced operations with their Android devices, This is because ADB is both the only official interface for a Windows or Mac computer to operate an Android device via USB and it is a debugging interface.

Install ADB drivers

Once loaded, the module will first download universal Windows ADB drivers from its C2 server (e.g., from http[:]//www.zaccl.com/tool/new_tool.zip) and install them.

Figure 1 Windows ADB driver files downloaded from the  C2 server

Then, some variants will directly drop a file named adb.exe which is the standard ADB Windows client. Other variants have compiled the ADB client’s source code into the module so that they could also perform ADB operations. Instead of adb.exe, the newest variant will drop tadb.exe, a customized ADB client from Tencent’s Android management software.

Note that since version 4.2 (released in early 2013), Android requires a user’s manual confirmation to authorize a PC before building an ADB session. This was designed to prevent attacks such as sideloading apps via USB. However, if a user has authorized his PC in the past, the related key files will be stored in the %HOME%/.android directory on the PC. DualToy reuses these key files to bypass the intended security check.

Download and install apps

After the ADB environment is set up, DualToy will wait for an Android device to connect via USB. Once connected, it will fetch a list of URLs from the C2 server, download the apps, and install them on Android device in the background via the “adb.exe install” command.

Figure 2  Android app downloading URLs on the C2 server

Figure 3  Apps installed on the  Android device  by DualToy

Figure 3 shows the apps downloaded and installed by DualToy. They’re all games which use Chinese as the default language, and none of them are available in the official Google Play store.

Install and execute binary code

In a recent variant, DualToy will download a PE executable named “appdata.exe” as well as an ELF executable file named “guardmb” from the C2 server. The appdata.exe file was compiled from ADB’s source code with some customizations -- DualToy will execute it with the command line “appdata.exe shell am start”. When invoked by this command line, the appdata.exe copies the guardmb file to connected Android device’s /data/local/tmp directory, and executes it.

Figure 4  appdata.exe executes guardmb on the Android device

Figure 5  guardmb starts a specific service on the Android device

The guardmb file is an ELF executable for ARM architecture. Its functionality is simple – execute Android’s system command “am” to start the service “com.home.micorsoft.service.BootWakeService”. Guardmb also specified the same service was implemented in a third party app with package name of “com.home.micorsoft”.

During the analysis, we weren't able to find the “com.home.micorsoft” app. However, we discovered another Android app with a similar package name “com.mgr.micorsoft”. Due to the same typo (“micorsoft”) and same binary code fingerprints, we believe these two apps have the same sources and likely have identical functionalities.

The app embedded a modified SU daemon program which was re-compiled from SuperSU project’s source code. We named this specific Android Trojan “RootAngel”. After the service is started by guardmb, and install the SU daemon. It will also connect with its C2 server, download more Android apps and install them in background through “pm install” command.

Figure 6  RootAngel installs Android apps downloaded from the C2 server

Infecting iOS Devices

We observed the first sample of DualToy capable of infecting iOS devices on June 7, 2015 (SHA-256: f2efc145d7d49b023d97a5857ad144dd03a491b85887312ef401a82b87fb1b84). Later in 2016, a new variant appeared. Our analysis below focuses primarily on the first variant.

During execution, the sample will drop some PE and .ini files. Among them, insapp.dll is the module used to infect an iOS device. It was developed using Delphi and C++ and then packed with a standard UPX packer. There’s another file, insapp.ini, which contains configurations including URLs to download iTunes drivers as well as iOS apps to install.

Download and install iTunes

After being loaded, the insapp.dll will check whether iTunes is installed on the infected computer. If not, it will download two MSI format installers from its C2 server. For example, for a 64-bit Windows PC, “AppleMobileDeviceSupport64.msi” and “AppleApplicationSupport64.msi” will be downloaded. These two installers are part of Apple’s official iTunes for Windows software that contains all necessary driver files that iTunes uses to interact with iOS devices.

After that, DualToy will execute “msiexec.exe” to install the installers shown in Figure 8 in background via the “/qn” parameter.

Figure 7  The config file specifies URLs of the iTunes installer and iOS app(s)

Figure 8  DualToy install iTunes installers via msiexec.exe

Operate iOS devices

In order to operate iOS devices through installed iTunes drivers, DualToy reused an open source project “iphonetunnel-usbmuxconnectbyport”. Using this, DualToy invokes APIs in iTunes’ iTunesMobileDevice.dll file via reflection, so that it can interact with iOS devices just like iTunes does.

Figure 9  DualToy reflects symbols from iTunesMobileDevice.dll

DualToy will watch for USB connections. Once there’s a valid iOS device connected, it will try to connect to it using iTunes APIs. Like Android, Apple also introduced manual user authorization starting with iOS 7 to prevent sideloading. As it does with Android devices, DualToy will check whether the iOS device was previously paired so that it can reuse existing pairing record (Figure 10).

Figure 10  DualToy checks whether the device was paired by owner before

Steal iOS device information

After successfully connecting with an iOS device, DualToy will collect device and system information, encrypt them and send to its C2 server. The collected information includes:

• Device name, type, version and model number
• Device UUID and serial number
• Device baseband version, system build version, and firmware version
• Device IMEI
• SIM card’s IMSI and ICCID
• Phone number

Figure 11   DualToy collects iOS device information

Download and install app

In addition to collecting device information, DualToy also tries to download IPA file(s) from the C2 server and install them on the connected iOS device. The URL it used to fetch the downloading list is http://www.zaccl[.]com/tool/apple/wj_app.xml. During our analysis in April and in August 2016, this URL always returned a single file, “kuaiyong.ipa”. After downloading it, DualToy will copy the IPA file via the AFC service to the iOS device’s /var/mobile/Media/PublicStaging directory, and then install it via the installation_proxy service.

Figure 12   DualToy fetch iOS app downloading URLs

Figure 13  Install iOS app via iTunes API

The downloaded kuaiyong.ipa has an obfuscated bundle ID of “pWsbshWBn5XN9kk0twBUECAVt2E.dsE7UfuXZdinV60edM4u1Ul0d6hSf66akdZrmp”. It was signed by an enterprise certificate issued to “Ningbo Pharmaceutical Co., Ltd.” The certificate the app won’t be successfully installed on iOS devices anymore. However, the attacker could easily change the URL list replied by C2 server to push other apps.

Figure 14  The iOS app was signed by enterprise certificate

AceDeceiver-like behavior

Since the kuaiyong.ipa has an expired certificate, we resigned it with a personal development certificate and then installed it on our testing device.

The app is yet another third party iOS App Store just like “ZergHelper”. It also has exactly the same behavior as AceDeceiver. When launched for the first time, the app will ask the user to input his or her Apple ID and password (Figure 15). The nearby disclaimer says the credentials won’t be uploaded to any server. However, through our reverse engineering and debugging, we discovered the Apple ID and password will be encrypted by DES algorithm by a fixed key of “HBSMY4yF” and 4 of “\x12\x34\x56\x78\x90\xab\xcd\xef”, and sent to the server proxy.mysjzs[.]com after encoding the ciphertext with Base64. Figure 16 shows the output by hooking the CCCrypt function with Frida. And Figure 17 shows the credentials being uploaded to the server.

Note that, since the C2 traffic was HTTP instead of HTTPS, and the credential payload was just encrypted by DES with a fixed key, an attacker could sniff network traffic to capture the payload and steal the Apple ID and password in the payload.

Figure 15  Kuaiyong.ipa asks user to input Apple ID and password

Figure 16  Apple ID username and password was encrypted with DES

Figure 17  Encrypted Apple ID and password was sent to a server

Mitigation

Palo Alto Networks WildFire has successfully . URL Filtering has also blocked its C2 traffic so that it can’t download drivers, malicious payloads or apps. We have also created an AutoFocus tag to identify known DualToy samples.

To prevent similar attacks, we suggest users and organizations deploy both endpoint and network-based malware prevention solutions. We also suggest users avoid connecting their mobile phones to untrusted devices via USB. The popularity and ubiquitous nature of mobile devices ensures malicious attackers will only continue to refine and develop new mobile malware, which means users and organizations will need to employ similar levels of protection and user awareness historically provided to desktops, laptops, and networks.

Acknowledgements

We would like to thanks Zhi Xu and Josh Grunzweig from Palo Alto Networks for their assistance during the analysis.

Appendix

SHA-256 of selected samples

b028137e54b46092c5349e0d253144e2ca437eaa2e4d827b045182ca8974ed33  jkting.zip
bbe5fcd2f748bb69c3a186c1515800c23a5822567c276af37585dab901bf550c  new5.zip
26ff76206d151ce66097df58ae93e78b035b3818c24910a08067896e92d382de  NewPhone.dll
24c79edc650247022878ddec74b13cf1dc59a6e26316b25054d015bdc2b7efc7  new_tool.zip
cd432a8a0938902ea3016dae1e60c0a55016fd3c7741536cc9f57e0166d2b1b8  appdata.exe
42290cefc312b5f1e4b09d1658232838b72d2dab5ece20ebf29f4d0d66a7879a  guardmb
7f7a3ed87c63bd46eb8b91a5bb36b399b4eebaf7d01342c13ef695340b9964a6  Mgr_700003.apk
9f84665a891e8d9d3af76b44c1965eba605f84768841dfb748cb05ec119ffd9d  phonedata.exe
c8695fe9decbeedfe1f898464b6aa9da511045721c399486d00b889d888c8121  zWDLzv.dll
f2efc145d7d49b023d97a5857ad144dd03a491b85887312ef401a82b87fb1b84
c32c64196bb4e038657c3003586563407b5a36db74afb837a5b72f71cf1fadf1  DevApi.dll
dee13984156d1b59395126fcac09f407ef7c7d7308643019ccee6e22683ea108  insapp.dll
eae9fda5ca026d2cc0fbdd6f6300d77867dae95a5c1ab45efdb4959684f188d2  insapp.ini
899e3c72e2edf720e5d0f3b0dfbf1e2dcc616277c11cf592ab267a9fa0bfbac9  kuaiyong.ipa
c8695fe9decbeedfe1f898464b6aa9da511045721c399486d00b889d888c8121

C2 Domains

www.zaccl[.]com
pack.1e5[.]com
rsys.topfreeweb[.]net
abc.yuedea[.]com
report.boxlist[.]info
tt.51wanyx[.]net
hk.pk2012.info
center.oldlist[.]info
up.top258[.]cn
dl.dswzd[.]com