Day: December 1, 2016

Posted on

2017 Cybersecurity Predictions: IoT Security Flaws Awareness Will Be Magnified

This post is part of an ongoing blog series examining “Sure Things” (predictions that are almost guaranteed to happen) and “Long Shots” (predictions that are less likely to happen) in cybersecurity in 2017. 

The endpoint security market will experience some dramatic shifts in 2017. Everything from the disposition of the threat actors to the players in the security vendor space to the nature of endpoints is undergoing significant changes. This will most certainly catch many organizations off guard. But there are options for those security professionals who care to prepare for it. In this post, I will outline four changes that security professionals might see in 2017.

Sure Things

Rapid Consolidation in the Endpoint Security Market

According to the research firm Cybersecurity Ventures, there were more than three dozen vendors and startups in the endpoint security market in 2016. For an evaluator or buyer of security products, that’s too many options, too many disparate approaches, and too much confusion – clear signs of saturation in any market.

Investors also seemed to recognize that the endpoint security market is reaching its saturation point: 2016 marked a slowdown in funding of new security startups, compared to 2015. As fewer (new and existing) startups receive funding, those that cannot deliver enough value to buyers in order to gain a foothold in this crowded market will inevitably die out. Others will be acquired by the traditional antivirus (AV) vendors who recognize the need for rapid retooling of their offerings to stay competitive.

As the pace of cyberattacks continues to increase, so does the pace of this market consolidation. Endpoint security vendors will recognize that they must move fast to keep pace with the threat landscape and the market conditions. These conditions will lead to a rapid, Darwinian consolidation in the endpoint security market.

Dramatic Increase in Use of Exploit Kits

Recent research from Unit 42, the Palo Alto Networks threat intelligence team, outlined the three main reasons cybercriminals continue to rely heavily on exploit kits:

  1. Exploit kits present cyberattackers with a much stealthier option for infecting Windows hosts with malware.
  2. The exploitation process is automatic.
  3. Criminals can use exploit kits to essentially outsource malware distribution.

In other words, exploit kits turn cyberattacks into an automatic, outsourced, and scalable operation for criminals. And with the ability to rent access to any number of exploit kits for a few hundred dollars a month, launching an attack with exploit kits is now far more affordable than ever before.

Information security has always been a “cops and robbers” problem. And with exploit kits, the robbers add automation, outsourcing, and scalability to their side of the equation. This is a trend that will certainly continue to escalate in 2017. The security industry, on the other hand, seems only recently to have recognized that it must match those capabilities or risk losing this battle. Fortunately, there are advanced endpoint protection solutions that already offer these automated, scalable prevention capabilities to forward-thinking organizations.

Long Shots

Marked Increase in macOS-based Malware

In March 2016, Unit 42 discovered KeRanger, the first instance of a macOS-based ransomware. Since then, the team has discovered several new types of malware exclusive to macOS. This is not a surprising trend – what’s surprising is that it took so long.

macOS-based systems present cybercriminals with a perfect set of circumstances:

  • A false perception of security among end-users: The traditionally low occurrence of security breaches on macOS-based systems may lead users to be far less vigilant about cybersecurity hygiene, despite risks that are similar to Windows-based systems (for example, these systems share many of the same vulnerable applications, such as Adobe Flash).
  • A lack of sophisticated endpoint security solutions: The majority of macOS-based systems either have no endpoint security solutions deployed, or they use the same traditional AV solutions that have proven to be ineffective against today’s cyberthreats.
  • Increased organizational adoption of Apple’s technology ecosystem (from iPhones to iPad to Mac computers): In a recent research report by Nomura (October 2016 CIO Survey), the firm reported that 42 percent of the CIOs they surveyed “indicated Apple’s products are becoming more pervasive in their IT infrastructure.”

A large and increasing population of enterprise users who practice poor cybersecurity hygiene and do not have automated, sophisticated endpoint security solutions to protect their systems? Sounds like the perfect target for crafty cybercriminals looking for new sources of ransomware revenue in 2017.

Increased Awareness of IoT Security Flaws

The proliferation of the Internet of Things (IoT) is already underway. According to the research firm Gartner, there were an estimated 6.4 billion IoT devices in use in 2016. The firm forecasts that there will be over 20 billion connected IoT devices by 2020. Despite the large number of devices, IoT security still seems to be an afterthought. This is concerning, considering:

  • The increased interconnectivity between IoT devices
  • The potential for collecting and sharing data among IoT devices and their supporting data services
  • The unknown but potentially significant and increasing number of vulnerabilities within the IoT ecosystem

The IoT ecosystem is still in its technological infancy. The extent and the impact of existing security flaws may not be obvious yet because of the limited computing and connectivity capabilities of the devices in use today.

This was very likely the same argument used to justify distributing unsecure systems in the automotive industry – until researchers demonstrated their ability to remotely hack a car traveling at highway speeds in 2015.

As the IoT device counts and capabilities continue to increase in 2017, the inherent security flaws that may have been ignored in the past will become more prominent, complex and unnerving. Organizations that develop, produce, and host these devices must make a concerted effort to integrate security into these devices and the networks they operate in. Being the first organization to deal with the public repercussions of a breach in IoT security is not a “first mover advantage” in any industry.

What are your cybersecurity predictions around endpoint security? Share your thoughts in the comments and be sure to stay tuned for the next post in this series where we’ll share predictions for healthcare.

[Palo Alto Networks Research Center]

Posted on

Shamoon 2: Return of the Disttrack Wiper

In August 2012, an attack campaign known as Shamoon targeted a Saudi Arabian energy company to deliver a malware called Disttrack. Disttrack is a multipurpose tool that exhibits worm-like behavior by attempting to spread to other systems on a local network using stolen administrator credentials. More importantly, its claim to fame is the ability to destroy data and to render infected systems unusable. The attack four years ago resulted in 30,000 or more systems being damaged.

Last week, Unit 42 came across new Disttrack samples that appear to have been used in an updated attack campaign. The attack targeted at least one organization in Saudi Arabia, which aligns with the targeting of the initial Shamoon attacks. It appears the purpose of the new Disttrack samples were solely focused on destruction, as the samples were configured with a non-operational C2 server to report to and were set to begin wiping data exactly on 2016/11/17 20:45. In another similarity to Shamoon, this is the end of the work week in Saudi Arabia (their work week is from Sunday to Thursdays), so the malware had potentially the entire weekend to spread.  The Shamoon attacks took place on Lailat al Qadr, the holiest night of the year for Muslims; another time the attackers could be reasonably certain employees would not be at work.

Composition of Disttrack

Disttrack is comprised of three distinct parts: the dropper, communications and wiper components. The main Disttrack executable is a dropper that extracts additional tools from embedded resources and coordinates when to save and execute them. Embedded within each Disttrack sample is a component responsible for communicating with a C2 server and a separate component used to carry out the wiping functionality.

The dropper extracts the communications and wiper components from resources named “PKCS7” and “PKCS12” respectively, while the x86 sample extracts the x64 variant of Disttrack from a resource named “X509”. To extract the components, the dropper is configured to seek specific offsets within the resource, read a specified number of bytes and decrypt the contents using a specified key. The key exists in the sample as a base64 encoded string that the dropper will decode then use each byte of the resulting string to XOR the data obtained from the resource. When determining the location of the ciphertext within the resource, the dropper subtracts 14 from the offset value in the sample’s configuration as an additional layer of obfuscation. Table 1 shows the resources within the Disttrack x86 sample, the component it contains and the values needed to decrypt its contents.

Component Resource Name Offset Size Base64 key
x64 Variant X509 812 -14 = 798 717312 5tGLQqku0m02…
Communications PKCS7 879 -14 = 865 159744 UPi0IzQOAyiL…
Wiper PKCS12 792 -14 = 778 282112 3Lmqr/nJgzFZ7…

Table 1 Resources containing Disttrack components

Disttrack Functionality

Disttrack is mainly focused on data destruction and attempting to damage as many systems as possible. To do so, this malware attempts to spread to other systems on network using what are likely stolen administrator credentials. This is again similar to the 2012 Shamoon attacks, where compromised but legitimate credentials obtained in advance of the attacks were also hard coded into the malware to aid in its propagation. Disttrack also has the ability to download and execute additional applications to the system, as well as remotely set the date to start wiping systems.

Local Network Spreading

The Disttrack malware spreads to other systems automatically using stolen credentials. The Disttrack we analyzed contained the internal domain names and administrator credentials associated with the targeted organization. The internal domain and credentials appear to be stolen prior to the creation of this tool, as it is not a public domain and the credentials are not weak enough to have obtained through guessing, brute force or dictionary attacks.

Disttrack uses the internal domain names and credentials to log into remote systems on the same network segment. The malware determines the local network segment associated with the target system (call to gethostname) by obtaining the IP address for the system (call to gethostbyname). It then uses the system’s IP addresses to enumerate the /24 network (x.x.x.0-255) that the system is networked with, and will attempt to spread to each of these remote systems.

The dropper then attempts to open the service manager on each remote system to start the RemoteRegistry service, which it will connect to using RegConnectRegistryW. Once connected, the dropper attempts to disable UAC (User Access Control) remote restrictions by setting the following registry key to a value of “1”:

SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

After disabling UAC, the dropper connects to the remote system (using NetUseAdd) and logs in using the embedded stolen credentials. The dropper then checks to see if it has administrator privileges on the remote system by attempting to open “\system32\csrss.exe”, which allows it to determine if it can write its payload to the “\system32” folder on the remote system. The dropper then has two different methods in which it can pivot to the remote system.

The first method involves the dropper writing itself to “\system32\ntssrvr32.exe” on the remote system. After writing itself to the remote system, the dropper creates a service named “ntssrv”, with a display name of “Microsoft Network Realtime Inspection Service” and a description of “Helps guard against time change attempts targeting known and newly discovered vulnerabilities in network time protocols” to execute the payload.

The second, alternative method also involves the dropper copying itself to “\system32\ntssrvr32.exe” on the remote system; however, instead of creating a remote service, this method calls the NetScheduleJobAdd function within the Windows netapi32 library to create a scheduled task to run the payload. Scheduled tasks require a time in which the task will run, which the dropper determines by calling the function NetRemoteTOD to obtain the time of day from the remote system. The dropper then adds 90 seconds to the time of day value on the remote system and uses this value as the “JobTime” to run the task in three minutes, which executes the payload on the remote system. The following pseudo-code shows the scheduled task creation process:

C2 Communications

Disttrack extracts the communication component from its resource named “PKCS7”, decrypts it and saves the resulting cleartext to the file %WINDOWS%\system32\netinit.exe.

The communication module interacts with its C2 server using HTTP requests. The communications modules in both the x86 and x64 variants of Disttrack we analyzed were configured to use “1.1.1.1:8080” for its C2 server, which does not host an operational Disttrack C2 server. The lack of an operational C2 server suggests that the threat actors did not desire remote access to infected systems, rather the actors sought to render them unusable instead. If the modules were configured with an operational C2 server,  the module would generate an HTTP GET request that resembles the following:

The interesting part of the request above is that the host “server”, the URL “category/page.php”, the parameter “shinu” and the user-agent “Mozilla/5.0 (MSIE 7.1; Windows NT 6.0)” are hardcoded into the tool. The data in “shinu” parameter is a combination of the system’s tickcount, local IP address, operating system version, keyboard layout and the contents of %WINDOWS%\inf\netimm173.pnf. The C2 server can respond to this HTTP request with one of the following two commands:

Command Description
E Provides an executable to run on the system. The executable is saved to %TEMP%\Temp\filer\<tickcount>.exe
T Sets the time to start wiping the system, by writing the date to %WINDOWS%\inf\usbvideo324.pnf.

We believe the HTTP host value of “server” and the non-operational “1.1.1.1” C2 address may suggest that the communication module is created with a builder tool, which in this case the actor mistakenly or purposefully did not provide an active C2 server when building this module. While completely speculative, the word “shinu” used as a parameter could be a reference to the Arabic slang for the word “what”, as well as a reference to a village name in northwestern Iran.

Disttrack Data Destruction

The Disttrack dropper is responsible for installing the wiper component of this Trojan, however, it will only activate this component if the system time is greater than a preset date. The dropper obtains a date used to activate the wiping functionality by reading a specific file, or using a hardcoded timestamp of “2016/11/17 20:45”. The file containing this timestamp is named “\inf\usbvideo324.pnf”, which is not initially installed but is provided by the C2 server if it sends the communications module the “T” command. The “usbvideo324.pnf” file would have the following structure:

BYTE year;
BYTE month;
BYTE day;
BYTE hour;
BYTE year;
BYTE minute;

If the dropper determines the system date is larger than the specified date, the dropper will extract the wiper component from a resource named “PKCS12” and save it to the “system32” folder with one of the following filenames appended with a “.exe” extension:

  • caclsrv
  • certutl
  • clean
  • ctrl
  • dfrag
  • dnslookup
  • dvdquery
  • event
  • findfile
  • gpget
  • ipsecure
  • iissrv
  • msinit
  • ntfrsutil
  • ntdsutl
  • power
  • rdsadmin
  • regsys
  • sigver
  • routeman
  • rrasrv
  • sacses
  • sfmsc
  • smbinit
  • wcscript
  • ntnw
  • netx
  • fsutl
  • extract

The dropper then runs the wiper component with a command line argument of “1”. The wiper component extracts a driver from its resource section and decrypts it with a 226 byte XOR key. The wiper saves the extracted driver to “C:\Windows\System32\Drivers\drdisk.sys” and installs the kernel driver by creating a service named “drdisk” with the following command line commands:

The kernel driver is a commercial product that the attackers are abusing called RawDisk by EldoS Corporation, which provides direct access to files, disks and partitions. It appears that the “drdisk.sys” driver (SHA256: 4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6) is the exact same driver as used in the Shamoon attack in 2012. With the kernel driver installed, the wiper can begin writing to protected system locations, such as the master boot record (MBR) and partition tables of storage volumes. The wiper can be configured to overwrite files in three different ways, specified by a configuration setting of “F”, “R” or “E”. If configured with the “F” setting, the wiper loads a resource named AJKEOA, which extracts a JPEG image to use to overwrite files and partition tables. If the wiper is configured with the “E” setting, the wiper will encrypt the contents of the file using a random value as a key and the RC4 algorithm. If configured with the “R” setting, the wiper will overwrite files with the random values that would be used as a key in “E”.

The sample we analyzed was configured with “F”, meaning it would overwrite files with an image obtained from its resource section. The image extracted is a picture of a Syrian boy named Alan Kurdi, whose drowning on September 2, 2015 received international attention in regards to the ongoing Syrian refugee crisis. The previous Shamoon attack in 2012 used an image of a burning American flag, continuing the political image theme.

From a functionality standpoint, the wiper relies on EldoS’ RawDisk driver to overwrite files on the system. During this activity, we noticed the wiper changing the system time to August 2012, as the temporary license key for the RawDisk driver requires the system time to not exceed the month of August, which is when the temporary license would expire. This modification to the system time was seen in the previous campaign, and the temporary license key within the wiper component is the exact same as wiper component from the 2012 attacks. The wiper itself queries the following registry keys to obtain a list of partitions to overwrite:

In addition to these partitions, the wiper attempts to overwrite files and subfolders within in the following folders:

After overwriting these files and the partition tables, the wiper issues the following command to restart the system:

The arguments and switches used in the “shutdown” command above forces all running applications to close and causes the system to reboot (‘-r’) after 2 seconds (‘-t 2’). This command does result in a dialog prompt, seen in Figure 1, that informs the user that the system is shutting down.

Figure 1 Dialog prompt displayed when the Wiper component runs the ‘shutdown’ command

With the partition tables overwritten, the system will no longer be able to properly boot, which renders the system unusable. During analysis, our analysis system was rendered unusable, as the virtual machine was unable to find the operating system during boot up, as seen in Figure 2.

Figure 2 Analysis virtual machine unable to boot after executing Disttrack Wiper

Conclusion

After a four year hiatus, threat actors likely associated with the Shamoon attack campaign have used their Disttrack malware to target at least one organization in Saudi Arabia. The current attack campaign has several TTP overlaps with the original Shamoon campaign, especially from a targeting and timing perspective. Also, Disttrack malware used in the recent attacks is very similar to the variant used in the 2012 attacks, which uses the exact same RawDisk device driver as well (down to the same, temporary license key).. The main purpose of the Disttrack malware is to overwrite files and storage partitions in an attempt to destroy data and render the system unusable. To maximize its destruction, the Disttrack tool attempts to spread to other systems on the network using stolen administrator credentials, which suggests that the threat actors had previous access to the network or carried out successful phishing attacks prior to the attack using Disttrack.

Palo Alto Networks customers are protected from Disttrack:

  • All known samples have a malicious verdict in WildFire
  • AutoFocus customers can monitor Disttrack activity via the Disttrack tag

Indicators of Compromise

Disttrack Droppers

47bb36cd2832a18b5ae951cf5a7d44fba6d8f5dca0a372392d40f51d1fe1ac34 (x64)
394a7ebad5dfc13d6c75945a61063470dc3b68f7a207613b79ef000e1990909b
(x86)

Communication Components

772ceedbc2cacf7b16ae967de310350e42aa47e5cef19f4423220d41501d86a5 (x64)
61c1c8fc8b268127751ac565ed4abd6bdab8d2d0f2ff6074291b2d54b0228842 (x86)

Wiper Components

c7fc1f9c2bed748b50a599ee2fa609eb7c9ddaeb9cd16633ba0d10cf66891d8a (x64)

128fa5815c6fee68463b18051c1a1ccdf28c599ce321691686b1efa4838a2acd (x86)

EldoS RawDisk Samples

5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (x64)
4744df6ac02ff0a3f9ad0bf47b15854bbebb73c936dd02f7c79293a2828406f6 (x86)

[Palo Alto Networks Research Center]

Posted on

PluginPhantom: New Android Trojan Abuses “DroidPlugin” Framework

Recently, we discovered a new Google Android Trojan named “PluginPhantom”, which steals many types of user information including: files, location data, contacts and Wi-Fi information. It also takes pictures, captures screenshots, records audios, intercepts and sends SMS messages. In addition, it can log the keyboard input by the Android accessibility service, acting as a keylogger.

PluginPhantom is a new class of Google Android Trojan: it is the first to use updating and to evade static detection. It does this by leveraging the Android plugin technology. It abuses the legitimate and popular open source framework “DroidPlugin”, which allows an app to dynamically launch any apps as plugins without installing them in the system. PluginPhantom implements each element of malicious functionality as a plugin, and utilizes a host app to control the plugins. With the new architecture, PluginPhantom achieves more flexibility to update its modules without reinstalling apps. PluginPhantom also gains the ability to evade the static detection by hiding malicious behaviors in plugins. Since the plugin development pattern is generic and the plugin SDK can be easily embedded, the plugin architecture could be a trend among Android malware in the future.

Evolution of PluginPhantom

We believe PluginPhantom is a successor to the Android Trojan “Android.Trojan.Ihide”, which was discovered by TrustLook in July of 2016, since they share the same certificate and package name. PluginPhantom not only includes and improved all malicious functionalities from “Android.Trojan.Ihide”, but also adopts a very innovative design architecture. In the new architecture, the original malware app is divided into multiple apps (plugin apps) and a single app (a host app). The host app embeds all plugin apps in resources, which implement different functional modules. After victims install the host app, it can directly load and launch plugin apps without installing plugin apps, by abusing the legitimate open source plugin framework – DroidPlugin [2].

1. Introduction of DroidPlugin:

DroidPlugin is an innovative application-level virtualization/proxy framework, which was originally developed for purposes of hot patching, reducing the released APK size, and removing the 65535 methods limitation. The popular application scenario of DroidPlugin is launching multiple instances of apps on the same device (e.g. using multi-accounts in social apps). Fundamentally, DroidPlugin is very different from the widely known dynamic code loading (e.g. loading a dex or jar file), since it can directly load and launch an app from its APK file without installation. There are five basic concepts or mechanisms in the implementation of DroidPlugin:

  • Shared UID. All plugin apps share the same UID with the host app.
  • Pre-defined stub components and permissions. The host app has pre-defined components and permissions for plugin apps.
  • Dynamic Proxy Hook. The host app has hooked API invocations of plugin apps by the dynamic proxy technique, so that the Android system thinks that all API requests and components are from the host app.
  • Resource loading. As the plugin app is not installed in the system, so the host app must take over the process of loading app resources in the plugin app process.
  • Component Lifecycle Management. When the component in the plugin process is ready to be destroyed, the corresponding stub component should also be destroyed simultaneously.

2. Plugin Design of PluginPhantom:

In the plugin design architecture, PluginPhantom has one host app (i.e. the malicious APK we captured) and nine plugin apps that are embedded in the host app as assets files.  In these nine plugins, there exists 3 core plugins (“task”, “update” and “online”) and six additional plugins (“file”, “location”, “contact”, “camera”, “radio” and “wifi”), shown in Figure 1.

Figure 1 Plugin Architecture of PluginPhantom

The host app, as the controller and the entry point of PluginPhantom, schedules plugin apps by launching them and sending commands. In the initialization stage, the host app loads nine APK files in asset files and installs them as plugins in the DroidPlugin framework. Then, the host app can launch and communicate with plugins the same way it would with normal Apps installed on Android.

The online plugin, connects to the command and control (C2) server to upload device information (e.g. the screen state, the battery volume and the free RAM size) and retrieve commands to execute. The online plugin firstly finishes a “ThrowOut” step to probe the remote server by sending the “UUID” (from “java.util.UUID.randomUUID()”) in a UDP socket.  If the “UUID” is sent successfully, then, the online plugin continues to utilize the WebSocket to pull the command data from the server.

The task plugin, fetches the command data through the bridge of the host app. According to different command types, the task plugin forwards commands to six additional plugins to launch different attacks. The task plugin also uploads stolen data to the remote server through the WebSocket. In addition, the task plugin launches the update plugin to download new plugin APK files and update plugins, if it receives the “update” command type. Once the update plugin finishes downloading plugins, the task plugin sends a message to the host app to reload and relaunch plugins.

3. IPC and Data Sharing in PluginPhantom:

In the DroidPlugin framework, the host app and all plugin apps share different PIDs, but same UID. Thus, the IPC between the host app and plugin apps or among plugin apps is same as the IPC mechanism in the Android system. The IPC in PluginPhantom includes the Intent and AIDL. The host app can launch all plugin apps by starting the entry service of plugin apps with an Intent. In particular, to keep plugin services alive, the host app uses the alarm manager to restart the entry service of plugin apps in an interval. In addition, AIDL is used for IPC between the host app and plugin apps.  For example, “AbsAidl” is used by the task plugin to send commands to the host app for hooking keyboard inputs. The update plugin uses “ClientAidl”, “InfoAidl” and “PluginAidl” to synchronize the updated plugin information with the host app.

Even though the Intent and AIDL can share parts of data, PluginPhantom mainly uses the Content Provider and the file system to share data between the task plugin and six additional plugins. For example, the radio plugin gets commands from the task plugin by the URI “content://***.task.cntPrv/Command”, and stores the command response and recorded audio file paths into the URI “content://***.task.cntPrv/CmdRespond” and “content://***.task.cntPrv/CmdRespondFile” respectively.  Later, the task plugin parses last two content providers, and then reads and uploads recorded audio files from the external storage path “/sdcard/AndroidMedia/.audio/record”.

Stealing Information through Plugins

1. File Plugin

The file plugin scans a specific directory and retrieves information (e.g. file name, file type, file size, create time, edit time, file path, canonical path and read state), from the files inside it. It also scans media files in the external storage and can download and delete specific files.  During the file operation, the root privilege is used by the file plugin if necessary. In existing samples, PluginPhantom is trying to use the root privilege, but does not root the device. If the attacker wanted root access on the device, they could use the C2 channel to install an APK which exploits an unpatched local root vulnerability, but we have not yet observed this occur with PluginPhantom infections.

2. Location Plugin

The location plugin obtains both fine-grained and coarse-grained location information. It converts coordinates in the Android default geographic coordinate system to coordinates in two other coordinate systems, which are used by Baidu Maps and Amap Maps, the top two navigation apps in China.  To successfully obtain the location, the plugin can enable WIFI, GPS (under Android 4.4) and mobile data (under or in Android 5.0) options.

3. Contact Plugin

The contact plugin intercepts incoming SMS and phone calls for specific numbers received from the remote server. To avoid detection, it turns off the ringtone and phone screen and deletes call logs when SMS and phone calls are coming in. The contact plugin also steals call logs, device IDs and contacts info (including deleted contacts) in both the phone contact list and the SIM card contact list. Additionally, it sends SMS messages to specific numbers, which is finished after checking the current phone bill balance.

4. Camera Plugin

The camera plugin takes pictures in the background through either the front or the back camera. It uses a surface view with 0.1*0.1 size for camera previewing, and a full screen Activity with the transparent theme and no title, so victims may be not aware of this behavior. It also takes screen shots by the command “screencap –p” if it has obtained root privileges on the device.

5. Radio Plugin

The radio plugin records the audio in the background with two trigger conditions: commands from the remote server and incoming/outgoing phone calls. To avoid detection, it doesn’t record audio if other apps are also recording.

6. WIFI Plugin

The WIFI plugin steals WIFI information (e.g. SSID, password, IP address, mac address), software information (e.g. app name, version, last update time, is system app), running process information (e.g. PID, process name, app name, app resource path, app data path, timestamp), and trace information (e.g.  browser visiting history and bookmarks).

Stealing Keyboard Inputs through Accessibility in the Host App

In the host app, a developer defined service named “AutoService” extends the “AccessibilityService” to hook all GUI events in the system (Figure 2). First it needs to trick users into enabling the accessibility permission to this app using it’s description shown in Figure 3, which pretends describes a fake “memory cleaning service.”

Figure 2 Accessibility Service for hooking

Figure 3 Lure users to enable the accessibility service

The host app uses the Android Accessibility feature to hook and operate on the specific Activity and package by referring the class name and package name, for two purposes:

1. Grant or activate if a GUI dialog asks for authorizations. If the text of a clickable button matches keywords in “this.b” (Figure 4), or the text of a checkbox matches keywords “Don’t show this again” in “this.c” (Figure 4), the app will automatically click the button or the checkbox.

2. Record the keyboard inputs for specific apps.  PluginPhantom logs user inputs, such as the text and window id, for all leaf nodes in the UI tree (Figure 5). Thus, the victims’ inputs in the EditText element can be logged. Note that password inputs cannot be logged. The text of password EditText node is always empty since the password attribute of this node is true.

Figure 4 Matched keywords for clicking

Figure 5 Log the text and window id of the UI node

Conclusion

While the Android plugin technology is very hot in the Android app development, it also gives a chance to malware developers to redesign malware in a more flexible way. Like the PluginPhantom family, malware can easily update or add modules by updating or installing plugin apps. In terms of evasion, the plugin malware can hide all malicious behaviors in plugin apps, which can be downloaded and launched to bypass static detection. Additionally, the plugin technology might be a replacement of the repackage technique in the future. The plugin malware only needs to launch the original app as one plugin, and later launch malicious modules as other plugins. Even though the PluginPhantom is the first malware using the legitimate DroidPlugin framework, we will continue to watch and report this threat as attackers may use other plugin frameworks and launch more attacks.

Customers of Palo Alto Networks are protected with our WildFire, URL filtering and IPS services. AutoFocus users can identify samples of this malware using the PluginPhantom tag.

Acknowledgments

We greatly appreciate the help from Zhi Xu, Claud Xiao, Xin Ouyang, Ryan Olson and others from Palo Alto Networks in working on the analysis of PluginPhantom family.

Sample Hashes

002e568047074093ca43153b806fb29ec60bcf1b3040487f8ec727ace1209316
1f739108dc2a6520ad736249cd8ed0dbc674e59e687337005b3fa3ab52956bb2
1fe181823dbab09aee5cc72b83822977c64ec17cdbf739f5e6edf9b2f5697d11
8255149b6d3ffaa029c6302659aec00d17418fefc5cde9572fbf23bb996d9fde
91f7d9663d259b0c57619bbdd73fb763b6567cce0c1ae05542d8f55644e12d20
92b6a68ea66c73d5d05dff7d8d290ea8ba242846b05d6d4e2e477eb662944cac
b642b9de56218696cf5fe7f47aa914bfe3fec22a754d68c03e0e8d130efbb14f
d56f9157d5b9aabd01bc0476c1a5e5e398a90c75efb9da37f0f7fcaf61b896b8
e4977499171b475e8fd450477574b36b8d1bf0af62a5782fb77c702bcf4fb408

C2 Domains and URLs

1519j010g4[.]iok[.]la
58[.]222.39.215:8088/dmrcandroid/ws/httpsData/command

and

[Palo Alto Networks Research Center]

English
English
Exit mobile version