Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
Most traditional security products are built to act based on known threats. The moment they see something that is known to be malicious, they block it. To get past security products that successfully block known threats, attackers are forced to create something that is previously unknown. How do they do it, and what can we do to prevent both known and unknown threats?
Let’s look at a few scenarios:
Recycle the Threat
Recycled threats are considered to be the most cost-effective attack method, which is why attackers often recycle existing threats using previously proven techniques. What makes these recycled threats somewhat “unknown” lies within the limited memory of security products. All security products have limited memory, and security teams choose the most up-to-date threats to protect against, hoping they can block the majority of incoming attacks. If an old threat not tracked by the security product attempts to enter the network, it could bypass the security product because it is not categorized as something seen before.
To protect against these “unknown” recycled threats, it is critical to have access to a threat intelligence memory keeper, these days often placed in an elastic cloud infrastructure capable of scaling to address the volume of threat data. In the event that a security product doesn’t have a particular threat identified and stored, access to the larger knowledge base of threat intelligence could help determine if something is malicious and enable the security product to block it.
Modify Existing Code
This method is somewhat more expensive than recycling threats. Attackers take an existing threat and make slight modifications to the code, either manually or automatically, as the threat actively transitions in the network. This results in polymorphic malware or a polymorphic URL. Like a virus, the malware continuously and automatically morphs and changes rapidly. If a security product identifies the original threat as known and creates a protection for it based on one variation only, any slight change to the code will turn that threat into an unknown. Some security products match threats using hash (#) technology, which generates a number based on a string of text in such a way that it is extremely unlikely that some other text will produce the same hash value. In our context, the hash value only matches one variation of the threat, so any new variation of the threat will be considered new and unknown.
To better protect against this threats security products needs to use smart signatures. Smart signatures are based on the content and patterns of traffic and files, rather than on a hash, and can identify and protect against modifications and variations of a known threat. The focus on the behavior, rather than the appearance of fixed encoding, allows for the detection of patterns in modified malware.
Create a New Threat
Attackers who are more determined and willing to invest the money will create an entirely new threat with purely new code. All aspects of the cyber attack lifecycle have to be new for an attack to truly be considered a previously unknown threat.
Focus on Business Behavior
Protecting against these new threats requires focus on your unique business behavior and data flows. This information can then be implemented into cybersecurity best practices. As an example, leveraging zoning with user ID and application ID, can help prevent new threats from spreading around your organization and block downloads from new, unknown and unclassified websites.
Utilize Collective Intelligence
No single organization will ever initially experience all new threats globally, which is why it is so important to be able to benefit from collective threat intelligence. Targeted attacks with unknown, never-before-seen threats can quickly become known with global information sharing. When a new threat is analyzed and detected in one organization, the newly identified threat information can be distributed across the community, with mitigations deployed a head of time to limit the spread of attacks and their effectiveness globally.
Turning unknown threats into known and actively prevent against them can happen in a combined environment. First, you need to predict the next attack step and location. Second, you need to be able to develop and deliver protection quickly to the enforcement point in order to stop it.
When a truly new threat enters your organization, the first line of defense is having cybersecurity best practices that are specific to the organization. At the same time, you should be sending unknown files and links for analysis. The effectiveness of sandbox analysis is depended on the time it takes to provide an accurate verdict on an unknown threat and the time necessary to create and implement protections across the organization. Your security posture needs to be changed fast enough to block the threat before it has the ability to progress – in other words, as soon as possible. And to ensure that this threat does not further traverse the network, preventions need to be created and implemented automatically across all security products faster than the threat can productively spread.
A recent SANS survey reported that 40 percent of attacks have previously unknown elements. The ability to detect unknown threats and prevent successful attacks defines the effectiveness of your security deployment. A true next-generation security platform is agile, quickly turning unknown threats into known protection and prevention on a global level. Automatically sharing new threat data while extending new protections throughout the organization to stop the spread of an attack. Learn more about the Palo Alto Networks Next-Generation Security Platform.
The Lone Wolf
Some months ago I responded to a question in the ISACA forum posed by a person who described himself as a lone wolf security professional. In being alone, he was involved in all information security tasks, in every phase of the Deming circle—Plan, Do, Check and Act. The question asked if it was possible and ethical to check his own policy, plan and progress; this is a very good question, and a dilemma that is known by many information security professionals.
In 2010, the Dutch government forced all hospitals to implement information security. This resulted in the creation of my own job as information security officer in one of the larger hospitals in the south of The Netherlands. It was a huge challenge; I had a willing management, but very limited resources, and I was the only information security professional in the organization. In other words, I was a lone wolf. And I had, like the person on the forum, to check my own work. Not because nobody was willing to check my work, but the knowledge was simply not there. Like the person on the forum, I felt very uncomfortable with that situation.
The Lone Wolf Seeks a Pack; the Expert Group I was lucky; I had a full-time position, although my duties were many. Many colleagues in other hospitals had part-time positions. Thus, a common pool of knowledge did not exist. That is why I started my CISM training, became an ISACA member and contacted security colleagues from the other Dutch hospitals. Not surprisingly, everybody found themselves in the same situation as I did: limited resources and a deadly deadline set by the government. We decided to meet up. The first meeting with my fellow hospital information security colleagues numbered about 40 persons. A meeting room was kindly sponsored by the Dutch Hospital Association (NVZ). And so the expert group was born, and the lone wolf found himself a pack.
First, cooperation was limited to dividing work. Two of us looked into behavior training and a code of conduct, others wrote a security policy fit for hospitals, the third pair worked out a risk method, others took ICT security as their focus, etc. A digital forum was established to facilitate the cooperation of the group and the exchange of work.
After 2 meetings we started to discuss the inevitable experience in various hospitals with serious security incidents. But we needed a base of trust for discussing these sensitive topics. We agreed as a group to use the Chatham House Rule for discussions, supported by a signed agreement to do so. We learned from each other, and I dare say that 1 meeting with this expert group would have taken me at least 4 weeks to accomplish had I done the work myself. By the end of 2010 all participants to the expert group successfully passed the obligatory external audit.
Success! The expert group decided to continue. The improvements to information security were made, but there were many other issues. One was how to continue with auditing. We agreed that the external audit process for hospitals was poor. The auditors had mostly no clinical experience, the audits were expensive, and audit approach used was so diverse that the results between hospitals had no base for comparison.
Together with a colleague I proposed to organize audits between hospitals that were to be carried out by members of our expert group. Within 2 years’ time we trained over 60 persons as CISA auditors, and within 1 year the first audits took place. A team of 2 auditors from different hospitals audited a third hospital. Thus we solved several problems at once. We no longer had to check our own work, and we got relevant feedback against low costs.
This system is currently still working, and about 70% of the Dutch hospitals are participating. I decided some years ago to leave the hospital and start my own company. Currently, I help health care organizations with information security. Building expert groups is still part of my strategy.
Gilbert van Zeijl, MSc, CISA, CISM, Clinical Informatician
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:
Exploit kits present cyberattackers with a much stealthier option for infecting Windows hosts with malware.
The exploitation process is automatic.
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.
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”:
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:
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:
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:
1
2
3
4
C:\Documents andSettings
C:\Users
C:\Windows\System32\Drivers
C:\Windows\System32\Config\systemprofile
After overwriting these files and the partition tables, the wiper issues the following command to restart the system:
1
shutdown–r–f–t2
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
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.
