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:

• http[:]//cdn.applight[.]mobi/applight/2015/1442824462res.bin

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.

Appendix

Psneuter.script Contents

Rootnik Samples

Package Name: com.freeinternet1
SHA256: c1775e5fe89a0c8b1254e4d8a95686c56554b47f13e36d4f5cb551cb340f7021

Package Name: com.farproc.wifi.analyzer
SHA256: 0d612eb6d3ca2bbbc2aa33493065d8b4c3237f3cb262d48602181887ccea1afb

Package Name: com.name.costgeoUyI19
SHA256: 17a00e9e8a50a4e2ae0a2a5c88be0769a16c3fc90903dd1cf4f5b0b9b0aa1139

Package Name: net.three.basicIeVwjf43
SHA256: f6b7b22bbe572c1ac1d7ac7135e076da87491eb78a37f17654a4aa92d88ded24

Additional APK files written to system partition byRootnik

Package Name: com.android.providers.network
SHA256: 3bab02ec7ab2480c65b824350b387b00fc7fd9359ebca34fb42dda340ccbf5b6

Package Name: com.android.providers.wifi
SHA256: dc76856ff79cfdda7b227635f204ff3341e01ea537022497f5c6a70dc46b0cea

Package Name: com.yc.aika
SHA256: ae4be03204419fd96c4e5085b6e3ddd542f39c53f9c9d0fed4eecaf823a1b26e

Package Name: mobi.superflashligh.supertorch
SHA256: 690d44802b3638688c7e93bf9dc85b39fbfa2e03b5763a571caf665c8803b13b

Wenjun Hu, Claud Xiao and Zhi Xu

[Palo Alto Networks Blog]

Most of our users in ICS/SCADA during their initial evaluation of our products went through an evaluation called an “SLR” or Security Lifecycle Report (formerly called an Application Visibility and Risk Report).

We offer this free assessment as a way to provide users a detailed view of what applications and risks are running in their industrial control systems environment. Among other benefits, the SLR can be conducted in a monitor-only configuration where the next-generation firewall, instead of being deployed inline, is installed passively in “tap mode” to monitor network traffic. While passive, the appliance provides detailed layer-7 visibility to applications, ICS protocols, content, threats, and users. The SLR tool has been a big eye-opener to many OT security professionals as “interesting” and unexpected findings always come up. Some findings are immediately actionable and other findings give insight to risks that may need further planning and investment to be properly addressed in the long term.

The SLR allows end users to validate that the traffic (apps, users, content) expected to be running in the ICS/SCADA environment is indeed present. These include the common ICS protocols and applications, management applications, database/historian apps and on some occasions, custom applications. ICS environments are usually static and if change happens, it is often implemented methodically over a longer period than is typically seen in IT networks. This static nature makes it easy to identify anomalies against a baseline. The SLR for this reason is ideal for detecting risky and malicious traffic.

Some examples for this category of traffic that we have found in ICS/SCADA networks include the following:

• Risky internet-facing applications – Engineers wanting to use internet-based apps for work collaboration, remote access, or leisure find ways to connect to the Internet whether via the business network or by setting up ad-hoc broadband networks in the OT. We have found Dropbox and Wuala (cloud storage), Bittorrent and eMule(P2P filesharing), TeamViewer (collaboration), Skype (Voice/Video), Facebook (social media) and similar applications. We’ve even found gaming applications on an offshore rig! While not malicious in nature, these applications are highly risky in terms of compromising network performance and opening pathways that could be used by attackers to breach the ICS.
• Unknown / Encrypted Traffic – Sometimes this ends up being legitimate, custom traffic created by the end-user. For example, we sometimes run into cases where a serial protocol such as IEC 60870-5-101 traffic is tunneled over TCP. This can be easily fingerprinted subsequently through the creation of a custom application identifier or “App-ID”. For unassignable, unknown traffic, further analysis is required to determine whether it may be associated with risky/malicious applications or command and control traffic. We also sometimes run into encrypted traffic like SSL/SSH, which may be normal. For example, SSH is frequently used in ICS for remote system management. SSL is more rare in ICS and when found typically prompts investigation to determine what exactly the SSL traffic is and why it is needed in the environment.
• Known Malware and Exploits – In five recent SLRs conducted in South America, four of the networks we analyzed were found to have the Conficker malware. Accidental malware infection is very common in ICS and initiated via adjacent networks, dual-environment mobile devices (IT & OT), or removable media. Whatever the case, this discovery often prompts a revisiting of network segmentation as well as mobile device and removable media policies. We are also able to identify risky ICS protocol commands, for example warm restarts. These commands are so significant in terms of disrupting uptime that they may be deemed as exploits. When found, they typically are part of normal routine or maintenance events, but may also be anomalous when sourced from unusual security zones, machines, or users.
• Zero-day Malware/APTs –In those same five networks in South America, of the three that used Palo Alto Networks WildFire service, two of them found zero-day malware. Zero-day attacks are of course much more serious than known malware in that the unknown nature may be indicative of a targeted campaign from an Advanced Persistent Threat (APT).
• Command and Control Traffic – Using our Threat Prevention service and behavioral botnet report, we are able to detect suspicious outbound traffic to domains and websites. When present, such traffic may suggest an advanced malware infection. For example both Conficker and even ICS-specific attacks like Stuxnet and Energetic Bear have associated CNC fingerprints that can be detected and stopped. The behavioral botnet report is a more heuristic approach to assessing potential malware infections with callback features when specific fingerprints are not available.

Don’t be one of those users who assume that their ICS is safe just because there is a firewall at the IT-OT perimeter and because there are strict usage policies. Attackers and internal employees are creative and motivated to get their respective “jobs” done and could intentionally or inadvertently introduce risks and threats even with these basic controls in place.

Find out the state of your ICS more conclusively with an SLR risk assessment. It is free, non-disruptive, confidential, and provides a wealth of actionable information that can be used to better secure your critical infrastructure. Contact your local Palo Alto Networks sales representative today for more information.

Del Rodillas

[Palo Alto Networks Blog]

This is the sixth in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

This was originally posted on EnergyCentral.com.

The future, modernized state of Industrial Control Systems goes by many names.  Some are general such as “Industrial Internet of Things (IIoT)” and “Industry 4.0.” Others are more sector-specific names, such as “Smart Factories” (Manufacturing), “Smart Grid” (Electric), and “Digital Oilfield” (Oil & Gas). Modernization not only includes the deployment of enabling technologies but also broader and deeper connectivity.

Both will be great for economics, but with them will come an increase in potential attack vectors. One technology that I feel should be of particular concern to asset owners is mobility.  Not only do I see it gaining adoption in 2016, I believe that attackers will also start to use it as a stepping stone for compromising the automation environment.

Read the full prediction on EnergyCentral.com:
http://energycentral.com/utilitybusiness/informationtechnology/articles/3303

We’ve Got You Covered for Mobility in the IIoT

As a Palo Alto Networks user, you already have the infrastructure to help you securely adopt mobility in your IIoT architecture with our GlobalProtect mobile security technology. It extends your next-generation security posture out into the mobile environment, ensuring consistency of access control and threat prevention.  This is just one of the many integrated components of our security platform, which was designed to work cohesively with the rest. Learn more about GlobalProtect.

In part three of the Adversaries and Their Motivations blog series, we’ll explore the following top-level actor motivations: Cyber Warfare, Cyber Terrorism, and Cyber Mischief.

Even Fuzzier Boundaries

The high-level actor motivations covered earlier in this blog series introduced challenges in identifying and attributing activity between Cyber Espionage, Cyber Crime, and Cyber Hacktivism.

Analysis of the remaining motivations covered in this blog post can be even fuzzier considering the following:

• Political debate on definitions: Especially when it comes to international activity that directly results in loss of life, physical destruction of facilities, or negative economic hits, arguments persist over how these should be treated by nation state governments, military, and law enforcement agencies. The most serious debate concerns whether computer network related incidents constitute acts of war between countries.
• Hand-off between motivations: A number of motivations benefit from leveraging Tactics, Techniques, and Procedures (TTPs) and associated tools of another motivation either before or after focal activity. For example, Cyber Espionage can benefit Cyber Warfare operations, and Cyber Hacktivism can extend into Cyber Terrorism.

Cyber Warfare

Cyber Warfare describes operations that alone or complementary to kinetic military activityeliminate or degrade capabilities of a nation-state oriented target.

Associated Actors

Actors operating under this motivation include:

• Military units: Nation states recognize that computer warfare contributes to successful overt and covert operations against traditional military targets, such as adversary command and control (C2) systems, defense networks, and weapons systems.
• Intelligence services: These services often operate distinctly or in conjunction with military units to enable Cyber Warfare objectives through covert means.

Their Objectives

Associated actors seek to accomplish the following, on a nation state level:

• Disrupt operations: Established and critical military and civilian capabilities within a nation can present high value targets to an adversary, especially when combined with concurrent kinetic operations.
• Degrade / corrupt underlying capabilities: This includes sabotage that reduces the effectiveness or resilience of a capability to enable exploitation of that vulnerability in future kinetic and non-kinetic operations.
• Destroy key physical targets: Some attacks leverage Computer Network Attack (CNA) to destroy facilities for political and/or military advantage.

Additional Context for this Motivation

While this blog post attempts to simplify the definition of Cyber Warfare, political and military debate persists over how to define and respond to this class within the international community. Most operations that fall under this motivation are well funded, assessed as highly sophisticated, and backed by government, military, and intelligence resources. Associated activity is often paired with or conducted concurrent to Cyber Espionage operations to maximize effectiveness in progressive targeting, identification of associated weaknesses, and development of attack strategies. Otherwise, none of the other top-level malicious actor motivations typically mixes with Cyber Warfare operations.

Examples

Some examples of Cyber Warfare activity follow:

• The Stuxnet Attack On Iran’s Nuclear Plant Was ‘Far More Dangerous’ Than Previously Thought
• S., Israel Developed Flame Computer Virus to Slow Iranian Nuclear Efforts, Officials Say

Cyber Terrorism

Cyber Terrorism is the convergence of cyberspace and terrorism, distinguished by the threatened or realized loss of life, severe economic damage, and/or disruption of core infrastructure.

Associated Actors

Actors operating under the Cyber Terrorism motivation include:

• Officially recognized terrorist groups: Official terrorist organizations usually maintain public facing venues for communications and marketing.
• Government, military, or intelligence services: The end goal of these services is similar to that of officially recognized terrorist groups; however, it usually focuses internally to the originating country. As an example, in countries known for their human rights violations, respective agencies often use all available mediums to discourage dissent and identify (and “neutralize”) perceived opposition.
• Destructive black hat groups and individuals: The moment a malicious actor employs a virtually or physically destructive CNA method to affect an end goal or send a message their associated motivation is at least partially Cyber Terrorism.

Their Objectives

Actors operating under this motivation focus on:

• Disruption of opposing assets or services: This tactic is mostly used to gain visibility and potential media coverage for an organization based on the inconvenience or material damages accomplished through attacking various government, military, or corporate infrastructure targets. It is most often associated with extremist forms of hacktivism.
• Intimidation of a populace: This can take several forms, depending on the target country, culture, industry organization, and/or circumstances. Some associated attacks go so far as to leverage Computer Network Exploitation (CNE) to expose dissidents and their families to severe consequences within certain countries, extending as far as enabling assassination of key opposing personnel for political and/or military advantage.

Additional Context for this Motivation

These are the extreme cyber bullies of the world, relying on fear and destruction as their preferred tools. Similar to Cyber Warfare, public agreement on a definition for this motivation remains elusive. Kevin G. Coleman of the Technolytics Institute took a commendable stab at a definition:

“The premeditated use of disruptive activities, or the threat thereof, against computers and/or networks, with the intention to cause harm or further social, ideological, religious, political or similar objectives. Or to intimidate any person in furtherance of such objectives.”

Yet, even this definition generates significant overlap across subsets of malicious activity found within other motivations. Focusing on the context and severity of associated activity will often disambiguate underlying motivation; however, certain outliers will always fall in a mixed category and/or rely on less than moderate levels of confidence.

Enlisted participants in affecting campaign objectives can range in technical ability and sophistication. From contractors to hacktivists, certain third parties may be recruited to affect principle actor objectives in attack campaigns associated with this motivation.

While most actors under this motivation currently focus on disruption through techniques such as Distributed Denial of Service (DDoS), we’ve seen some lean towards destructive activity. This includes the use of tools such as wiper malware to perform the digital equivalent of sacking a city – but in this case, sacking an enterprise. In the future, similar tools and techniques as those successfully employed by Cyber Espionage and Cyber Warfare actors may lead to more devastating attacks against Cyber Terrorism targets.

Examples

Some examples of Cyber Terrorism activity follow:

• Kazakhstan: The Alleged Killer of Journalist Gennady Pavlyuk – Known Kyrgyz Special Services Officer
• Russia Accused of Unleashing Cyberwar to Disable Estonia
• Inside the “Wiper” Malware That Brought Sony Pictures to its Knees [Update]

Cyber Mischief

Cyber Mischief encompasses a majority of the remaining cyber threat noise on the Internet.

Associated Actors

In general, Cyber Mischief is associated with any malicious actor that doesn’t fit into the other high-level motivations. Examples include:

• Fledgling hackers: Individuals or groups that are new to the malicious hacking discipline and typically use publicly available attack tools without a deeper comprehension of underlying concepts and techniques. These parties are sometimes referred to as “script kiddies,” and in some cases they may cause damage but they generally do not harbor malicious intent.
• Internet nuisances: Individuals or groups that are experimenting with their TTPs and tools in arbitrary or capricious ways that do not directly lead to objectives of other motivations. Instead, these parties are often cultivating their skills and proficiencies to eventually apply them towards another top-level malicious actor motivation when they feel suitably prepared and confident.

Their Objectives

The objectives of actors that fall under the Cyber Mischief motivation can include:

• Small-scale personal benefit: Some actors execute related activity for minor tangible and/or intangible gains.
• Seeking to learn and/or teach: Knowledge and excellence in execution require extensive practice. Once comfortable enough, this practice often moves to the wild (i.e., Internet), to test an actor’s skill against live targets.
• Refining tradecraft: In the course of navigating through and beyond the fledgling hacker stage, some actors focus on strengthening their associated skills and proficiencies to elude detection and attribution.
• Exploring identity: The modern Internet offers a medium for bonding and integration of new experiences that can lure susceptible personality types and age ranges into this category of behavior.
• Just to be a nuisance: As in the physical world, some folks just like to stir up trouble.

Additional Context for this Motivation

A tricky aspect of Cyber Mischief is that it builds up the Internet noise that defenders must wade through to find threats posed by other high-level malicious actor motivations. As actor experience and competence increases, respective activity may begin to look more like the progressive high-level motivation that the party is evolving towards. Additionally, savvy actors under other motivations may tailor certain activity to blend in with this noise or employ these techniques to distract defenders.

Examples

Some examples of Cyber Mischief activity follow:

• Teens Expelled in Keylogging of School Computers
• Teen Pays for DDoS on School, Faces Felony Charges
• Lizard Squad claims responsibility for Black Friday PSN Outage

Closing Thoughts

As with any attempt to standardize or generalize, exceptions and outliers are a very real possibility. It’s often better to be approximately right than precisely wrong when it comes to tailoring a framework for any environment. Regardless of how you might break out and define categories of malicious actors attacking a network, one thing should remain consistent: assessment methodology. This ensures a basis for comparative analysis and subsequent prioritization of threats.

Finally, it can often be just as important to eliminate a given motivation or attribution from consideration as it is to isolate those with the highest confidence. After all, it’s about making the best-informed decisions possible about these threats given incomplete situational awareness and limited resources, such as people, technology, and – often the most critical – time.

Happy hunting and tracking!

Rob Downs

[Palo Alto Networks Blog]

This is the fifth in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

Service providers are in the thick of major changes, all of which have significant security implications. As we close out 2015, let’s take a look at major trends that will gain prominence for service providers in 2016.

Rapid Growth in the Industrial Internet of Things (IIoT)

Gartner predicts the Internet of Things (IoT) market will grow from about 4.8 billion connected devices in 2015 to 25 billion in 2020. While growth in the consumer space (e.g., personal gadgets, sensors in the home) is rapid, IoT in the industrial realm may, in fact, be the bigger story. Electric utilities, manufacturers, automotive, and governments will make major IoT investments to bring their respective industries into the IoT age. The potential for returns in operational efficiencies are compelling, but these returns come with risk.

For example, utilities and manufacturing facilities have, for the most part, been isolated from public networks to date. Cybersecurity was mostly a matter of maintaining that isolation – ensuring SCADA systems were kept apart from the general purpose network used by the rest of the enterprise. The IIoT is changing that paradigm and service providers have a critical role to play in securing that infrastructure. Some of the new requirements to emerge from this:

• Service providers will need to elevate network security past the network layer and into the application layer to identify and isolate compromised endpoints.
• IIoT systems are often highly time sensitive (ultra-low latency requirements). Service providers will need to ensure quality of service and protect against attacks that would degrade performance.
• Increased segmentation. With industrial systems in effect “on the Internet,” Service providers will need to replace the physical isolation these systems used to enjoy with logical isolation based on ensuring only authorized traffic gets into these networks. They will need to ensure only authorized applications, users, and content have access to these critical systems.

More Virtualized Network Services – NFV/SDN Taking Off

In 2015 we saw the commercial release of virtualized services by major service providers. In fact, Infonetics forecasts a fivefold increase in the NFV/SDN market by 2019. With many more projects in the pipeline and more of the service provider infrastructure being virtualized, 2016 will see the release of more SDN/NFV-based services. Key security elements of this trend:

• Look for greater availability of virtualized “security-as-a-service” offerings. Public cloud offerings (e.g., AWS) are already available. Look for more private offerings from service providers, such as virtual CPE and virtualized hosted security. Competition among service providers will heat up, and customers will gain the benefits of more choices in plans and pricing, along with faster provisioning and improved service. The winners: providers who build services on tightly integrated security platforms with strong hooks into orchestration, OSS, and BSS.
• Security will be become part of the DNA of NFV-enabled network services. As service providers leverage SDN/NFV to move up the customer value chain, security will be embedded as a VNF (virtualized network function). And, as core infrastructure is virtualized, service providers will gain new capabilities to embed security into the network.
• In order to transform networks from hardware- to software-centric, service providers face a skills gap that threatens to emerge on the critical path of major projects. Vendor partnerships will be key in mitigating this gap. Service providers will look to NFV suppliers with well-integrated solutions and a successful track record with early adopters.

Emerging Security Opportunities for Service Providers

Security concerns have been longstanding barriers to adopting cloud technologies by larger enterprises. While large enterprises have embraced private cloud, public and hybrid cloud adoption are running into headwinds due to security concerns. A survey conducted by the Cloud Security Alliance found security to be the top concern holding back cloud projects.

Service providers have an opportunity to move up the value chain with their enterprise customers by deploying comprehensive security solutions for the cloud-enabled enterprise. These security offerings will include:

• Secure network connectivity to the public cloud.
• Secure employee access to cloud services.
• Breach protection for cloud assets.
• Policy management and enforcement for cloud-hosted services and data.

Customers will demand integrated offerings that deliver comprehensive security and can be tailored to their needs. They will require a security architecture that treats the assets they hold in the cloud with at least the same security as those assets receive in house. They will need security assurance that public cloud services do not open new attack vectors into the private network. The key to operational and financial success with these service initiatives will be integrated security platforms that address the full range of security requirements enterprises are demanding.