Last week, Palo Alto Networks received the 2015 Australia Network Security Vendor of the Year award from Frost & Sullivan. Armando Dacal, vice president for Palo Alto Networks Australia/New Zealand, attended the awards banquet in Sydney to accept the award.
The awards recognise ‘exemplary practices and best-in-class companies’ in Australia, across four markets, including ICT, Healthcare, Energy and Environment, Chemicals and Materials. This year was particularly special as it marked the 10th year that Frost & Sullivan hosted the excellence awards in Australia to recognise and celebrate exemplary practices and best-in-class companies in the country.
What a great way to close 2015. Congratulations Australia team!
Armando Dacal, vice president for Palo Alto Networks Australia/New Zealand
Niccolò Paganini’s Caprice No. 24 in A Minor is a famous and notoriously difficult composition that only the most advanced violinists can play. It’s made up of a theme, along with Paganini’s own variations. But as respectable as it is on its own, it’s been discovered and rediscovered by a large number of composers and artists over the years for new audiences, many of whom may not have realized they were listening to Paganini in the first place.
Each variation on a theme can provide new insights, because they challenge the audience to hear things that they may not have otherwise noticed. But without knowledge of the original theme, there’s also a chance of missing out on the big picture. In some ways, the discussion around mobile security takes on its own variations of a theme, because many people share common concepts on risk but their priorities on what must be done vary greatly.
I’ve had discussions with people who see mobile security as a data at rest issue, namely how to protect and remove data once it reaches the mobile device. That argument may address some of the issues with lost and stolen devices, but it does not address what happens if there is a malicious adversary trying to control the device.
Then there are networking teams who see mobile security as a network blocking issue, namely that they’ll do whatever they can to keep BYOD and unsanctioned devices off their corporate network. That may be a way to keep infected mobile devices out of sight, out of mind, but it doesn’t really make the sanctioned devices any safer to use.
There are also networking teams who see mobile security as being a remote access issue, but as applications move to the cloud, the use case for remote access becomes fuzzy, and the use of standalone VPN appliances even fuzzier.
It’s important to ask whether you’re addressing the problem itself, or a variation of the problem. For example, while each of the problems above are valid in their own right, the bigger issue is that organizations often lack ways to enforce security policies that could prevent improper application traffic and threats from reaching the device in the first place.
These thoughts come to mind as I read through NIST Special Publication 1800-4, which outlines the problem in mobile security. Section 4.4.1 discusses threats (including mobile malware) and Section 4.4.2 discusses exploitable vulnerabilities, both of which are at the heart of modern cyberattacks.
At Palo Alto Networks, we believe that prevention is a necessary and critical measure to prevent exploits and malware from reaching the device in the first place. The next-generation security platform provides an integrated approach toward the use of global threat intelligence to stop threats in application traffic. With GlobalProtect, all corporate application traffic is inspected by the next-generation security platform, regardless of where the user is located. This enables the organization to take a prevention-first approach by applying security policy to stop both known and unknown mobile threats.
As mobile security becomes better understood, it is important to develop strategies and frameworks that will help foster broader understanding of the issues at play – not just one or two variations. Stopping threats won’t come from solving the variations of the theme, but rather by addressing the core of the problem itself. Plan for prevention first in order to strengthen your mobile security strategy.
2015 was a rough year for the healthcare industry – more than 112 million healthcare records were breached, according to the HHS breach portal. That’s nine times (9x) higher than 2014. C-level executives at healthcare organizations understand that cyberattacks can have a direct impact on patient care, but they still struggle to advance their security maturity to the point that other industries with a longer history of regulation (i.e., financial services) have reached.
2016 will prove to be a year of innovation for healthcare organizations as they rush to implement new technologies that enhance the patient experience, such as remote patient monitoring and video visits, while many of the same core information security challenges persist.
Here’s a look at my top 2016 predictions for the healthcare industry.
The number of breached healthcare records caused by sophisticated cybersecurity attacks will continue to increase
In addition to the fact that there were nine times (9x) more breached healthcare records in 2015 compared to 2014, the top six healthcare breaches in 2015 account for over 98 percent of the 112 million total breached records for the year. Each of the top six was caused by an advanced cyberattack. All signs indicate that sophisticated and targeted cyberattacks in the healthcare industry are increasing with a few of the largest breaches linked to China-sponsored attackers.
In 2016, we will continue to see an increased number of targeted cyberattacks, resulting in major breaches in the healthcare industry. The healthcare providers who will be least impacted are those who:
Conduct regular end-user security training to reduce successful phishing.
Enforce a robust threat and vulnerability management program to identify risks.
Deploy an advanced integrated security architecture to prevent cyberattacks on the network, on the endpoint, and in the cloud.
The IoT revolution will take off in the healthcare industry
For those who don’t know, the Internet of Things (IoT) revolution will go mainstream in 2016. The IOT refers to the vast array of WiFi-enabled sensors that will be available to track everything from the level of milk in your fridge to the angle of your blinds, according to the time of day. According to Gartner, there will be 6 billion of them by 2018. The IoT revolution has many applications within the healthcare industry, including remote patient monitoring for high-risk patients and behavior modification to help with obesity and smoking problems. As these devices get smaller and less expensive, we will see more healthcare practices use them to treat patients.
I wrote a blog post recently in response to the FDA’s alert for all healthcare providers to stop using Hospira’s Symbiq drug infusion pump due to a cybersecurity vulnerability that presented a significant risk to patient safety – the first ever alert of its kind. Billy Rios is the name of the amateur security researcher who identified the vulnerability working out of his garage. This gives you an idea of the amount of research that has been conducted on medical devices (generally, very little). In my recent job as a security lead for a hospital network, I worked directly with multiple medical device manufacturers and was surprised at the extent to which medical device security is an afterthought.
If the IoT devices used in healthcare are produced in the same manner (innovation first, security as an afterthought) they are likely to be compromised by two types of attackers: those interested in profiting (by stealing health data) and those who desire to impact patient safety justbecause they can. The healthcare providers who will be least impacted are those who adopt strict security standards for their medical devices and make efforts to reduce risk by segmenting their network-connected medical devices.
Healthcare organizations will begin to move critical applications and infrastructure to the cloud
“Cloud” has been a buzzword in healthcare IT for years now as industry leadership strategizes to adopt such technology that has significant opportunities for cost savings, performance and scalability. 2016 will be a transition year for many healthcare organizations that will migrate a portion of their critical infrastructure and applications to the private cloud by the end of the year.
Big players in the EMR application space (e.g., Epic, Cerner, McKesson) will begin to offer cloud-hosted EMR solutions, and healthcare providers will start executing two-year plans to migrate their EMR to a fully managed private cloud service model.
Healthcare providers will begin to deploy certain elements of critical infrastructure to cloud services like Amazon Web Services and virtualize things like Active Directory domain controllers and next-generation firewalls.
Cloud-based file sharing and collaboration sites like Box.com will become more prevalent in the healthcare industry, as users urge leadership to provide an easier method to share data.
Attackers will look to mobile devices as the next best vector into healthcare networks
In 2015, we saw a tremendous amount of spear phishing and email malware in the healthcare industry, but mobile devices are likely to be the next target. In a recent HIMSS survey, 90 percent of responders in the healthcare industry said they maintain mobile devices to engage patients in their organizations. Mobile devices in hospitals are often used to connect to EMRs and view PHI, which introduces a slew of risks, most notably: 1) The ability to connect to unsecured public Wi-fi allows eavesdropping, and 2) Normally benign mobile apps can be poisoned with malicious code, such as the recent discovery of XCodeGhost by Palo Alto Networks Unit 42, which allows the attacker to phish passwords and URLs through infected iPhone apps.
Healthcare is already a targeted industry for attackers, and mobile devices are becoming more integrated into patient care services. It’s only a matter of time before mobile devices become a popular vector to steal health records.
The best mitigation for the risks outlined in these healthcare cybersecurity predictions is a combination of improving both security processes and security technology. Read more about joining the community of 1100+ healthcare organizations who trust Palo Alto Networks to provide the technology required to prevent cyberattacks and protect patient care.
Have a happy and prosperous 2016!
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
Today we are releasing a whitepaper describing how malicious actors are stealing private mobile device data by accessing local backup files stored on PC and Mac computers. We have identified 704 samples of six Trojan, adware and HackTool families for Windows® or Mac® OS X® systems that used this technique to steal data from iOS and BlackBerry® devices. These attacks have been in the wild for over five years, and we have observed them deployed in over 30 countries around the world.
Since these families use a common attack technique to access the backup files, we categorize all of them as using the “BackStab attack,” defined as “an attack approach that captures private mobile device data through the theft of local backup files stored on PC and Mac computers.”
The BackStab attack technique poses a risk to many mobile users for the following reasons:
The technique itself has been known to the security and forensic communities for over seven years. There are many publicly available articles and video tutorials describing how to conduct the attack using tools and/or open source projects available to the public.
Almost all private data stored in mobile devices can be stolen using this attack.
The attack doesn’t require the mobile device to be jailbroken or rooted.
The attack requires malware or adware running on PC or Mac, but doesn’t require the malware or adware to have any special privileges, such as root or administrator.
The attack requires at least one backup file to exist on the PC or Mac. In some situations, official backup software, like that of Apple iTunes, will automatically create backups of mobile devices without the user’s interaction and without encryption. It is also possible for malware to initiate a backup when the device is attached to an infected computer in some cases.
The attack is not theoretical and is occurring in the wild, as we have observed 704 malware samples in six Trojan, adware and HackTool families using it. Two of these families adopted the technique at least five years ago.
iOS and BlackBerry have been affected by real world attacks.
How BackStab Works
Under certain conditions, mobile devices automatically create un-encrypted backup files on a local computer when they are attached through a USB port. Apple iOS devices began doing this when iTunes backup was introduced with the first generation iPhone in 2007. When users choose the default backup options, the contents of their phone is stored, unencrypted on their computers local hard drive in a well-known location. Forensics experts have known about this behavior for years and have exploited it to gain access to iOS device content even when they cannot directly access an iPhone due to it’s strong protections.
Mitigate the BackStab Attack
As a successful BackStab attack allows a miscreant to steal almost all private data from a mobile device, we suggest users take the following actions (iOS is used as the example here):
When using iTunes backup, always enable encryption with a strong, unique password.
When using iCloud backup, set a strong, unique password for the iCloud account, andenable two-step verification.
Upgrade the iOS system to newest version (i.e., iOS 9.1).
Don’t jailbreak your iOS device.
Before entering your Apple account and password in a web browser, carefully check the current website’s domain name and SSL certificate to ensure you’re visiting Apple’s official website.
When connecting the iOS device to an untrusted computer or charger via a USB cable, don’t click the “Trust” button in the dialog box that displays.
Use an antivirus product or service on your computer or in your network. This will be helpful to find and prevent some known malware families, such as DarkComet.
Palo Alto Networks has adopted these steps to protect our customers from the BackStab attack:
WildFire™ has added a new feature to detect possible BackStab attack behavior.
WildFire properly classifies all six families mentioned in this report as malware. When those samples are transferred through a network protected by our products, they will be blocked.
A public tag has been added to our AutoFocus service to identify potential BackStab attack behavior.
AutoFocus also has tags that identify the DarkComet RAT, although not all variants of this malware use BackStab.
Endpoints using Traps are protected from this threat through their connection to WildFire.
We recently analyzed a Trojan named “Rootnik” which uses a customized commercial root tool named “Root Assistant” to gain root access on Android devices. By reverse engineering and repackaging this tool, the creators of Rootnik successfully stole at least five exploits that give them root access to Android devices that are running Android 4.3 and earlier. Root Assistant was developed by a Chinese company to help individuals gain root access to their own devices. However, Rootnik uses this tool to attack phones all over the world. Based on the data we have collected, Android users in United States, Malaysia, Thailand, Lebanon and Taiwan have been affected by the Trojan thus far.
Rootnik was able to spread by being embedded in copies of legitimate applications:
WiFi Analyzer
Open Camera
Infinite Loop
HD Camera
Windows Solitaire
ZUI Locker
Free Internet Austria
So far, we have observed more than 600 samples of Rootnik in the wild.
After a deep analysis of the malware, we determined that it’s able to perform the following actions.
Abuse a customized version of “Root Assistant” to exploit Android vulnerabilities including CVE-2012-4221, CVE-2013-2596, CVE-2013-2597, CVE-2013-6282.
Install several APK files on the system partition of the compromised device to maintain persistence after successful gaining root access.
Install and uninstall both non-system and system apps without users’ awareness.
Download executable files from remote servers for local execution.
Aggressively promote other applications. The app promotion advertisements are displayed to the user regardless of the current activity and even pop up in full screen mode when the user is viewing their home screen.
Steal WiFi information including passwords and keys as well as SSID and BSSID identifiers.
Harvest victims’ private information including their location, phone MAC address and device ID.
Rootnik connects to remote servers using the following domain names.
applight[.]mobi
jaxfire[.]mobi
superflashlight[.]mobi
shenmeapp[.]info
The earliest creation time of these domains date back to February 2015. At the time of this publication, all of these remote servers are active. Additional indicators related to this attack are available in the appendix.
How Rootnik Works
The Rootnik Malware Workflow
As shown in Figure 1, Rootnik distributes itself by repackaging and injecting malicious code into legitimate Android apps. After it is installed on an Android device, Rootnik launches a new thread to gain root privileges if certain conditions are met. Meanwhile, it begins an “app promotion” procedure that displays advertisements for other apps to the user. To gain root access, Rootnik first downloads encrypted payloads from a remote server if they do not exist locally then proceeds to attempt exploitation of one of four vulnerabilities. After achieving root access successfully, the malware writes four APK files to the system partition and reboots the compromised device.
Figure 1: An overview of Rootnik’s workflow
These four APK files serve as system apps after rebooting, and primarily fall into three categories based on their functionality. Based on the samples we have collected so far the file names of these four APKs are static.
AndroidSettings.apk
BluetoothProviders.apk
WifiProviders.apk
VirusSecurityHunter.apk
AndroidSettings.apk is responsible for promoting Android apps and has similar logic to the host malware’s app promotion procedure. BluetoothProviders.apk and WifiProviders.apk actually perform identical tasks, they act as a remote control component that can install and uninstall apps as well as download and execute new code from remote servers.
VirusSecurityHunter.apk is totally a private data-harvesting component, which can steal WiFi information, a victim’s location and other potentially sensitive data.
Root Payload Preparation
If an infected device is running Android version 4.4 or earlier, and this device isn’t located in certain countries specified in the AndroidManifest.xml file, Rootnik will attempt to gain root privileges. Thus far, all samples we analyzed were configured to attempt to gain root access in all locations except inside China. This is noteworthy as the root utility this malware has co-opted is developed in China.
Before beginning the rooting process, Rootnik prepares the payloads for execution. It first looks for an asset named “res.bin”, and if this asset does not exist it will access the following remote location:
http[:]//api.jaxfire[.]mobi/app/getTabsResBin
This URL is Base64 encoded in the Rootnik code. The remote server returns a response that is encrypted using AES/CBC/PKCS5Padding. Decrypting the response results in the following URL:
Rootnik then downloads this file from the decrypted URL using an HTTP GET request. The res.bin is actually a ZIP archive that is encrypted using DES using the key “#xaj&kl+”. Once decrypted, the following files are extracted from the archive.
busybox
psneuter.script_bak
install-recovery.sh
su
realroot, newrealroot, miroot, onekeyroot
log_sdk.dex
The log_sdk.dex is an encrypted DEX file that is decrypted, renamed to a.dex and temporarily stored under the app’s own data directory. This a.dex file is then dynamically loaded into the app process. The optimization directory for a.dex during dynamic loading is set to a hidden folder named .opt_log, and a.dex file will be finally deleted as soon as dynamic loading finishes. This entire process is completed using native code in the library libabm.so.
After investigating the a.dex file, we found it’s actually a customized version of the original commercial root utility named “Root Assistant,” developed in China.
Customizing a Commercial Root Utility
The original “Root Assistant” provides a “one-click root” functionality by exploiting vulnerabilities in the Android system, and “can support the most number of devices with the highest successful rooting rate” according to the official website. “One-key root” means the user can get root access by clicking a single key. The latest version of the utility, 1.5.1, uses a commercial packer to protect itself from reverse-engineering. However, we have located earlier versions of this utility that only used basic obfuscation techniques, which are simple to reverse engineer. The earlier version (1.3.0) of this utility follows this basic procedure to again root privileges:
(1). Report Device Specific Information
“Root Assistant” first sends device specific information to its remote server. After receiving this information, the remote server returns data guiding the selection of proper root exploits. It is important to note that there is no access authentication during this network connection.
(2). Prepare Root Exploits
The root utility stores all of the root exploits in local storage and will choose exploits according to the guidance from its remote server. These root exploits are embedded into four executable files, which are named realroot, newrealroot, miroot and onekeyroot. After investigating these executable files, we found that some exploit methods come from open source projects includingandroid-rooting-tools , libmsm_acdb_exploit and libfj_hdcp_exploit. Table 1 shows some of the vulnerabilities exploited by this root tool.
ID
Exploit Method
CVE ID
1
sock_diag
CVE-2012-4221
2
fb_mem
CVE-2013-2596
3
msm_acdb
CVE-2013-2597
4
put_user
CVE-2013-6282
5
fj_hdcp
N/A
Table 1: Root exploits used by “Root Assistant”
(3). Apply Exploits
All four of the files mentioned above are ELF executables and are invoked directly through shell commands. It’s important to note that a magic string is required when running these executables, otherwise they will refuse to exploit the device. For example, to run the executable onekeyroot, the magic string “www_onekeyrom_com” should be provided, as shown in Figure 2. This can be considered a type of self-protection to prevent third parties from co-opting executables for their own use.
Figure 2: A magic string is required when executing onekeyroot
(4). Post Process
After gaining root access successfully, one of the scripts named psneuter.script or onekeyrootseckill.sh (depending on which file is executed to gain root access) is executed with super user privilege. The main purpose of these scripts is to install a root privilege management application and to copy a modified “su” file to the system partition.
As demonstrated above, “Root Assistant” in version 1.3.0 can be easily reverse-engineered, introducing security concerns which are detailed as below:
As the tool is made up of multiple individual components that each perform a specific tasks without any user interaction, they could be easily extracted and re-used by an attack.
No authentication is required during the network connection between clients and the remote server, which means an attacker who re-uses this code can also re-use the Root Assistant server to help identify the best exploits for a device.
Root exploits are stored locally without any protection. Although magic strings are required to run the rooting executables, this scheme is not effective when the whole app can be reverse-engineered.
These security holes made it possible for “Root Assistant” to be co-opted by the Rootnik malware. The attacker repackaged this root utility to generate a dex file, which is dynamically loaded during the attack to achieve root access.
Figure 3 shows the class constructions of this root utility and Rootnik’s a.dex file. Comparing them shows us that the primary difference between them is Rootnik’s class android.core.utils.RootUtil. In this class, a thread named RootAThread is started to launch a root-gaining procedure by invoking the “rooting” entry point in the original utility.
As described above, psneuter.script or onekeyrootseckill.sh are executed once root privileges are acquired. Rootnik customized this root utility to always execute psneuter.script and also modified this script file by adding several shell commands to maintain persistent execution on the device. Figure 4 depicts parts of those added shell commands, from which we can find that four APK files are written to the /system/app directory. The whole content of psneuter.script is included in the appendix.
Figure 3: Class constructions of “Root Assistant” (v1.3.0, left) and a.dex (right)
Figure 4: Shell commands writing APK files to the system partition
Each of these APK files are named to look like system applications. Finally, Rootnik reboots the compromised device and the new APK files are installed as system applications. To avoid being caught by common users, these four apps have no icons on a victim’s device after being installed.
App Promotion
In addition to gaining root privileges on the device, Rootnik promotes apps to generate revenue for its creator. As depicted in Figure 1, the AndroidSettings.apk file, which is installed on the device, has similar app promotion functionality to the host sample. To avoid detection, all those individual parts of the app promotion logic are implemented through a delegate that is dynamically loaded from an encrypted JAR file.
Information about which apps to promote is downloaded from the following URL every 15 minutes.
http[:]//cs.applight[.]mobi/c2s
Figure 5 shows the network traffic between a Rootnik sample and the remote server. The information retrieved from the server is stored in a local database named com_av_ad.db as shown in Figure 6. It appears Rootnik chooses different apps to promote based on the infected device’s geographic location. It’s noteworthy that the local database includes a column named pay_out, which appears to list the amount of revenue for each app installation.
Figure 5: Network traffic between Rootnik and the remote server
Figure 6: Promoted apps’ information stored into a local database
Rootnik’s app promotion is especially aggressive and annoying to users. Advertisements pop up periodically regardless of current activity and are even shown in full screen mode. If a victim clicks one of those advertisements, Rootnik will launch the Google Play app and show the promoted app’s page (Figure 7).
Figure 7: App on Google Play shown when an advertisement is clicked
Remote Control
BluetoothProviders.apk and WifiProviders.apk have identical functionality and serve as a remote controlling component. Network data transferred between the remote control component and the remote server is encrypted using AES/CBC/PKCS5Padding, and the remote servers validate incoming connections by checking values embedded in the HTTP headers. To increase the robustness of the remote control channel, Rootnik uses two more domains to identify the command and control server, api.applight[.]mobi and api.superflashlight[.]mobi, in addition to the already mentioned api.jaxfire[.]mobi.
The remote control component is capable of performing multiple malicious functions, including but not limited to the following:
(1). Silent Application Installation
With root privileges, the malware can install both non-system and system apps without alerting the user. As shown in Figure 8, Rootnik retrieved information about new apps to install from a remote server. After decrypting data from the server we can see that it includes all of the information required to retrieve and install the new app, as depicted in Figure 9.
To install a new app, Rootnik makes an HTTP request to the URL listed in the “parameter” value as shown in Figure 9, and installs the downloaded result as non-system or system app, based on the value in the “action” field of the response data. There are two possible “action” values:
library.root.action.install_app_ex: install a non-system app
library.root.action.install_app_system: install a system app
Rootnik uses the pm utility of the Android system to install non-system apps, while it writes APK files into the /system/app directory to install system apps as shown in Figure 10. After installing an app successfully, the “shell” value in response data will be executed as a command. For example, the “shell” value shown in Figure 9 will result in the new app starting its main activity using “am” utility of the Android system.
Figure 8: Network traffic when fetching information about new apps to install
Figure 9: A section of the decrypted information from the remote server
Figure 10: Command used to install system applications
(2). Silently Uninstall Applications
In addition to installing apps, the remote control component is also capable of silently uninstalling apps. During the app installation procedure described above, an installed app’s package name is stored in a shared preference file named uninstall_set.xml. These package names are later used as parameters to uninstall specific apps. Rootnik executes the “pm uninstall” command to uninstall non-system apps, while it invokes the “pm disable” command and then removes the corresponding APK files from the /system/app directory to uninstall system apps (Figure 11).
Figure 11: Command used to uninstall system apps
(3). Download and Execute DEX Files
Rootnik was developed to be highly flexible as it can also download and execute dex files from remote servers. Descriptions of the dex files to be executed is first fetched from remote servers and the resulting data contains download URLs for the dex files as well as the class names that should be invoked within them. After retrieving the descriptive information, Rootnik downloads the dex files from the specified URLs and validates their CRC32 values. All downloaded dex files are encrypted using DES and their decryption keys are specified in the response data. After decrypting the dex files they are dynamically loaded and a method named doInBackground is invoked as shown in Figure 12.
Figure 12: Executing a dex file downloaded from the remote server
In addition to the behaviors described above, this remote controlling component also has the ability to self-update, and upload information about installed applications to the C2 server.
Private Data Theft
VirusSecurityHunter.apk, at first glance of its filename, appears to be an antivirus app but in reality has nothing to do with antivirus. This component actually harvests WiFi passwords, device location information, the device MAC address and other private information before sending it to a C2 server using the domain api.shenmeapp[.]info.
This component implements a service named mobi.hteam.hunter.ser-vice.HunterService, which is mainly in charge of harvesting WiFi information. After investigating this service, we found that WiFi information is collected in two different ways. One is to use APIs in the WifiManager class provided by the Android system. Rootnik first invokes the startScan method to scan for WiFi access points, then it extracts BSSID (address of the access point), SSID (network name) and encryption scheme data from the scan results and stores them in a local database.
The component also parses the contents of the file located at /data/misc/wifi/wpa_supplicant.conf which stores information about all of the WiFi access points that a device has ever connected to. This file is owned by the system user, and can’t normally be read by non-system applications. This is not a problem for Rootnik, as it has already gained root privileges at this point in execution. Figure 13 shows some contents of a wpa_supplicant.conf file from a Nexus 7 device running Android 4.3. Note that the psk value holds the password used to access the WiFi network listed. Information including the SSID, BSSID, psk and key_mgmt values are extracted from this file and stored into a local database.
Figure 13: A part of a wpa_supplicant.conf file on a Nexus 7 device running Android 4.3
Another service in the information collection component named org.myteam.analyticssdk.AnalyticsIntentService is responsible for uploading information including the victim’s location, device MAC address, device id to the C2 server every 24 hours (Figure 14).
Figure 14: Uploading private information
Protection and Prevention
Rootnik customizes an earlier version of a commercial root utility named “Root Assistant” from China, and is capable of gaining root privileges on devices running Android OS prior to version 4.4. We strongly suggest to users who want to mitigate the threat from Rootnik and similar malware to keep their Android devices updated to avoid being vulnerable to known exploits. Users should also avoid installing applications from unknown sources.
Palo Alto Networks provide comprehensive protections against Rootnik through our platform. Our WildFire service is able to identify samples of this malware family and we have created theRootnik tag for AutoFocus users to identify these files. We have also released DNS signatures to detect and block all malicious network traffic related to Rootnik.
