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:

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

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.

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.