For many years, a topic of conversation in the utilities space has been that the traditional corporate IT and operational technology (OT) worlds are converging.
In the IT world, it’s the hardware, software, network resources and other devices used for back-end functions that perform various business operations, such as sales, development, maintaining customer information, billing, and revenue collection. Predominantly, these devices are located in offices, server rooms and data centers. In the OT world, there are field-based devices that are used to perform actual operations. These OT systems are usually proprietary technologies, which are vendor-specific. They operate in a real-time or near to real-time environment.
So, the convergence of the IT and OT worlds is about integrating operational technologies, such as SCADA, remote terminal units, sensors, meters and smart meters. These technologies are working in real time or near to real time with IT systems to ultimately promote a single view of an organization’s information and process management to help ensure that every user, application, sensor, switch or other device has the right information, in the right format, at the right time.
With these operational benefits in mind, we now need to think about cybersecurity threats that the converged IT and OT worlds create for utilities. Unlike systems in the IT world, where they can be (sometimes are) updated with service packs, new releases and bug fixes, systems in the OT world are rarely, if ever, updated. It’s very common, if not the norm, that these systems are running the same software they were initially set up with, which, in many cases, can be 10 or more years old.
Furthermore, these devices have very little security capability because they were installed at a time when, even with an “air gap” or physical separation from systems in the IT world, they were considered to be “secure.” Traditional firewalls were used to create the silos between the two worlds. Whilst still being used today, they alone are not enough. In the OT world, where security lags, this will usually be a softer target than in the IT world, and so, compensating measures, such as physical perimeter and cyber perimeter protections, will always be more important for OT than for IT.
In the IT world, the number of applications, devices and services now used creates a larger attack surface, which creates a bigger target, if left unprotected, or a focus is placed on preventing new or unknown attacks. If the basic hygiene (patching operating systems and applications) is not maintained on these systems, this could allow for a compromise. Take a look at the US-CERT’s recently released alert regarding the 30 most prevalent vulnerabilities in targeted attacks that took place in 2014. The startling fact is that vulnerabilities from 2012 and backwards comprise more than half of the list.
Moreover, once a host is compromised, it would allow for an attack to “cross over” to the OT world. One recent example is a targeted attack against a German steel mill where the blast furnace suffered “massive” damage [1]. Attackers were able to compromise the steel mill’s IT network and, from there, reach into the OT network.
So what are the fundamentals needed to secure this environment?
We need to see what is traversing our systems and understand the risks by gaining visibility. Whilst many people may see this as an arduous process, the capability exists in most advanced network appliances, which can provide deeper visibility with no disruption to daily operations in either the IT or OT worlds. Once that is done, a process can begin to segment the OT systems into security zones based on risk profiles and security requirements to control who the users accessing the systems are and what applications they are using. This allows a “least privileged” access model, in which only explicitly authorized protocols, applications, and users are allowed.
Network segmentation is an effective method to reduce the scope of attack and reduce risk, but only if it is deployed correctly with prevention in mind. Merely turning a device on and logging does not give you the control needed. Protecting data with tighter segmentation, based on application whitelisting, a user access control model based on least privileged access, and systematically inspecting all payloads, including those of authorized applications, will reduce risk significantly, enabling security teams and advanced security tools to operate at their best.
Additional security best practices that should be implemented to complement the convergence should include organizational processes, such as the establishment of ongoing risk management procedures, routine self-assessments, periodic security audits and reviews with teams skilled on a streamlined approach to focus on least privilege and inspect and prevent attacks from crossing between the two worlds.
Cybersecurity needs to be an integral part of the conversation about IT and OT convergence. For all of the operational benefits convergence brings, it also carries significant risk. Proactive cybersecurity as part of that convergence is the most effective way to mitigate that risk. If treated as an afterthought, the chances of success are much lower.
Network security management is a critical aspect of any security deployment. However, most administrators would agree that configuring and managing a complete security network could at best be described as a nightmare.
According to AlgoSec, 64% of organizations are consumed with complex management, such as time consuming manual processes, obscured security policies, poor change management, and more. Manual processes also mean a greater likelihood of human error. According to Infonetics, 25% of security network outages are directly related to human error — a scary statistic.
Most security vendors don’t pay much attention to streamlining and simplifying the network configuration and management aspects of deployment. In fact, most security deployments are separate from each other, with differing management consoles and independent rule bases, lacking the ability to communicate with each other.
Ask yourself the following questions to understand if you are spending too much time managing your security deployment:
How many UIs and security rule-bases (URL filter, IPS, firewall, etc) do I manage to keep my network security current?
Can I manage my distributed security network from a central location, or do I need local administrators for each firewall?
What tools do I have that help with reducing manual processes during network configuration or policy development?
Does my security network structure match my organizational structure for a more logical deployment of security policies, or is it unnecessarily complex?
At Palo Alto Networks, network security management is a critical part of a security deployment. This translates not only into efficient management of individual firewalls but also of large distributed networks using our Panorama network security management solution.
Palo Alto Networks next generation security platform offers the convenience of a single user interface, as well as a single security rule-base that can be used to manage security policies for your application control, threat prevention, URL filtering, and more. This significantly streamlines policy management.
Panorama also offers tools that help reduce manual tasks and human errors such as the utilization of template stacks that eliminate manual replication of configuration elements across a distributed network. The ability to import existing firewall configurations with the click of a few buttons eliminates manual re-typing of configurations.
Other focus areas include intuitive network and policy management that enables you to deploy a security network that matches your organizational structure, making management of the security deployment significantly easier and logical.
Click here to learn more about Palo Alto Networks network security management capabilities.
We are excited to announce that Telstra has become the first channel partner in Asia Pacific to achieve the highest level of Diamond Partner Status in our NextWave Partner Program.
Telstra has been a partner of Palo Alto Networks in Australia since 2012. Over the past several years, Telstra has been instrumental in successfully bringing Palo Alto Networks offerings to market in Australia, especially with large enterprise customers.
This recognition was marked with an official signing ceremony at 11 AM today at the Hilton Hotel in Melbourne, Australia. The event was attended by John Ieraci, Director of Security Practices and Euan Prentice, Director of Services Business Development from Telstra, and Steve Redman, Vice President of Asia Pacific and Armando Dacal, Vice President of Australia/New Zealand from Palo Alto Networks.
A June 23 FireEye blog post titled “Operation Clandestine Wolf” discussed a cyber espionage group, known as APT3, that had been exploiting a zero-day vulnerability in Adobe Flash. Unit 42 also tracks the APT3 group using the name UPS, which is an intrusion set with Chinese origins that is known for having early access to zero-day vulnerabilities and delivering a backdoor called Pirpi.
The UPS group has exploited several zero-day vulnerabilities, most recently using the zero-days released in the Hacking Team breach that we discussed in our July 10 blog post, “APT Group UPS Targets US Government with Hacking Team Flash Exploit”. However, the most recent original zero-day released by this group is tracked by CVE-2015-3113, which has similarities to the once zero-day vulnerabilities CVE-2014-1776 and CVE-2014-6332 exploited by UPS in May and November 2014, respectively. We’ll discuss here the similarities observed between the various components used to exploit these two vulnerabilities, specifically focusing on the malicious Flash files and the payloads delivered.
Malicious Flash Files
Recent zero-day vulnerabilities exploited by UPS exploit or leverage Adobe Flash to exploit other applications on the system. Unit 42 recently analyzed malicious Flash files that exploitedCVE-2015-3113, which was a zero-day vulnerability in Adobe Flash that was patched on June 23, 2015.. During the analysis, we noticed similarities between this malicious Flash file, those that UPS used to exploit CVE-2014-1776, and the proof-of-concept code for CVE-2014-6332, albeit these two Flash files were used to exploit zero-day vulnerabilities in Internet Explorer.
Overlaps within ActionScript
Unit 42 analyzed the ActionScript within malicious Flash files created by UPS that exploited CVE-2014-1776 and CVE-2015-3113 and discovered shared code between the two. First, both ActionScripts contain a function named “hexToIntArray”, which Figure 1 displays side-by-side for comparison. Not only do these files contain the same function name, but they also share the same exact operation codes (opcodes) to carry out its functionality. The existence of the hexToIntArray function in the CVE-2015-3113 sample is rather interesting, as it is never called or used within the ActionScript. We believe that the threat actor used the CVE-2014-1776 ActionScript as the basis for the CVE-2015-3113 file and forgot to remove the unused hexToIntArray function.
Figure 1. Side-by-side comparison of opcodes in hexToIntArray functions
Also, the Flash file exploiting CVE-2015-3113 had a main class named “flappyMan”. This class name was also used in the Flash file that Unit 42 analyzed and discussed in its November 26, 2014 blog titled “Addressing CVE-2014-6332 SWF Exploit”, as well as the proof-of-concept (PoC) for CVE-2014-6332 that is now publicly available in exploit-related forums. According to FireEye’s “Operation Double Tap“, UPS exploited CVE-2014-6332 in its November 2014 attacks; however, UPS used a VBScript to exploit the vulnerability instead of a Flash file. While purely speculation, this overlap in class names between the CVE-2014-6332 PoC and the Flash file exploiting CVE-2015-3113 may suggest that UPS also used Flash files to exploit CVE-2014-6332.
Shellcode Similarities
As with most remote code execution vulnerabilities, UPS’ malicious documents execute shellcode in the event of successful exploitation of either CVE-2014-1776 or CVE-2015-3113. The shellcode found in the UPS delivery documents exploiting both of these vulnerabilities are not the same, but have similarities worth noting.
First, the delivery documents share the same technique of locating API functions, which involves using the rotate right (ror 7 to be specific) instruction on the function name in kernel32.dll and checking it with a specific value. The use of the same rotate right algorithm results in several common constants, such as 0xC917432 that both shellcodes use to locate LoadLibraryA. Second, both shellcodes use a similar method of creating the Unicode string “kernel32.dll”, seen in Figure 2. The shellcodes use the Unicode string and the same method to find the base address of the loaded kernel32.dll module from the LDR structures obtained from the process environment block (PEB). Third, both shellcodes have similar single byte XOR algorithms used to decrypt and later execute the functional payload.
Figure 2. Comparison of Instructions in UPS Shellcodes that Builds Kernel32.dll Unicode String
Steganography to Conceal Payloads
While analyzing the malicious Flash file exploiting CVE-2015-3113, Unit 42 discovered that the ActionScript loaded an animated GIF image. The malware author used steganography to embed an encrypted payload within this animated GIF image. The payload in the CVE-2014-1776 was also embedded within an animated GIF. Ultimately, the shellcode executed in the event of successful exploitation of either of these vulnerabilities decrypt and execute the embedded payload, as mentioned in the previous section. While the animated GIFs themselves are vastly different, as seen in Figure 3 and 4 (payloads removed), the use of steganography and animated images as the carrier of the payload is common between the two campaigns.
Figure 3. Animated GIF “v.gif” from UPS Campaign Exploiting CVE-2015-3113 (click to see .gif)
Figure 4. Animated GIF “anyway.gif” from UPS Campaign Exploiting CVE-2014-1776
Payload Comparison
With the amount of overlap between the other components in these separate campaigns, we decided to compare the Pirpi payloads delivered by the UPS group using CVE-2014-1776 and CVE-2015-3113. From here on, we will refer to these two payloads as Pirpi.2014 (CVE-2014-1776) and Pirpi.2015 (CVE-2015-3113), whose details are listed in Table 1. Unit 42 discovered several similarities between the two Pirpi variants, as well as a few equally important differences, both of which are worth discussing. We also compared the Pirpi.2014 and Pirpi.2015 payloads to other known Pirpi samples in an attempt to determine which variant they most closely resemble.
Table 1. File Details of Pirpi.2014 and Pirpi.2015 Samples
Similarities in C2 Communications
Both Pirpi variants perform an initial check to see if a configuration file exists at %APPDATA%\vcl.tmp or %TEMP%\vcl.tmp depending on the operating system. If it finds one, it decodes it and uses the configuration data it finds inside for C2 communication, otherwise it uses hardcoded C2 domains encoded inside the binary. The malware then creates threads to begin C2 communication.
The Pirpi.2014 and Pirpi.2015 payloads communicate with their C2 by issuing HTTP GET requests to the C2 domain hardcoded inside the payload or within its “vcl.tmp” configuration file. While the structure of the C2 URL differs between the two variants, both use the HTTP Cookie field to transmit data in encrypted form to the C2 domain. Figure 6 shows examples of C2 communications from Pirpi.2014 and Figure 7 shows communication with the C2 of Pirpi.2015 malware variants, both containing data within the Cookie field.
Figure 5. Pirpi.2014 C2 Communication using Cookie Field for Exfiltration
Figure 6. Pirpi.2015 C2 Communication using Cookie Field for Exfiltration
The GET request will return a web page that the malware will parse, specifically looking for encoded commands within two of the HTML tags.
Command Loop Overlap
Once the two Pirpi variants successfully communicate with their C2 server and parse the returned HTML for commands, Pirpi enters a command loop that processes the commands and carries out the respective activities. The command loop for the backdoor remains largely unchanged between Pirpi.2014 and Pirpi.2015 with only two of the commands differing between the two. Table 2 shows the commands that each malware can accept with only the 35 and 36 commands differing between the two Pirpi variants.
Value
Pirpi.2014 Command
Pirpi.2015 Command
1
Launch Process
2
Process Listing
3
Terminate Process
4
Download a file from the C2, launch it, and then delete it
5
Exit the malware
6
Sleep
7
Update C2 configuration and save it to %APPDATA%\vcl.tmp
8
Download a file, load it into memory, then delete the file
9
Load a DLL from %APPDATA% and execute one of its exported functions
10
Do nothing
11
Do nothing
12
List all servers in the domain
13
Get network adaptor information
14
List TCP connection status (netstat)
15
Retrieve information about connected users
16
List servers in the primary domain
17
Locates DCs on a domain
32
Directory listing
33
Upload a file to the C2
34
Delete file
35
Copy file and delete original
Copy file
36
Download and save file
Do Nothing
37
Echo
38
Execute Process
49
Get location of configuration file and set as current working directory
Table 2. Commands Available within Pirpi.2014 and Pirpi.2015
Anti-Disassembly
The UPS threat group is a fan of one anti-disassembly trick that can be seen in both Pirpi.2014 and Pirpi.2015. It plays upon the order IDA Pro disassembles instructions. As you can see in the code sample in Figure 6 from Pirpi.2014 there is a “jump above” instruction, followed by a “jump below or equal” instruction which just falls through to the next instruction. This fall-through code path will never get executed since the jump occurs if 0x58693C96 > 0x0D7F31B4.
Figure 7. Code Showing Anti-Disassembly Technique used in Pirpi Tool
IDA Pro’s disassembly sequence follows the fall-through branch of conditional jumps first, and thus in the previous instruction sequence, IDA keeps disassembling one instruction after another. When IDA goes back to disassemble the jump target for 0x10009133, it finds it pointing to the middle of an instruction. This stops IDA from being able to draw function borders, view a function in graph mode, or decompile with Hex-Rays. To solve this, undefine all of the code that will not be executed, and define code starting from the target of the conditional branch (in this case 0x1000913E), as seen in Figure 7.
Figure 8. Fixing Anti-Disassembly Trick used by Pirpi Tool by Undefining Errant Instructions
You will now be able to create a function to improve your ability to do analysis. To make this easier, use an IDA Pro script to fix these anti-disassembly tricks. Please note that this script specifically targets the anti-disassembly used in Pirpi and other UPS samples. It may cause issues with malware that uses other anti-disassembly tricks. Use with caution.
Notable Differences
The first major difference between the Pirpi.2014 and Pirpi.2015 variants is in the way the command loop is executed in each backdoor. In Pirpi.2014, the malware uses a simple state machine that executes code blocks that correspond to a state value, which the malware updates at the end of each code block. Many of these code blocks include sleep functions, however, if the state value is set to the correct value, the malware executes a code block that contains the command loop. The purpose of this state machine is to intentionally delay the malware’s execution of the command loop.
In Pirpi.2015, the malware implements a second state machine that executes the Pirpi.2014 state machine as one of its code blocks. The second state machine introduces a large number of randomized sleep functions, causing the malware to take much longer to execute its command loop. The majority of code blocks in the second state machine either sleep, or create threads and wait for them to finish. The malware author likely implemented these state machines as an anti-debugging technique and to defeat most modern sandbox solutions.
The second difference between the two Pirpi variants involves the encoding algorithm, which has improved greatly in the past year. Contained in the binary is an invertible math function for encoding and decoding of data. In Pirpi.2014 this function is rather simple, involving a few mathematical operations. However, in Pirpi.2015, the algorithm when decompiled is more than 300 source code lines of mathematical operations.
Other Pirpi Samples
FireEye released two reports in 2014 about APT3 phishing campaigns, Operation Doubletap and Operation Clandestine Fox. Each report containins md5s of other Pirpi samples that were available on VirusTotal. In addition, simple VirusTotal searches resulted in a few more Pirpi samples that came from the same code base. Table 3 contains the file information for each of these Pirpi samples.
Table 3. Details of Pirpi Samples from FireEye Reports and Samples that Share the Same Code Base
The sample listed as “{FireEye Report Sample}” in Table 3 is simply a dropper and loader for msupd.dll sample. Unit 42 compared all of the DLL samples listed in the table above and found that they are most closely related to Pirpi.2014. Table 4 below shows the statistics from Zynamics BinDiff from comparing each of the DLLs with Pirpi.2014 and Pirpi.2015.
Sample MD5
Pirpi.2014 Bindiff
Pirpi.2015 Bindiff
Similarity
Confidence
Similarity
Confidence
FA3578C2ABE3F37DDDA76EE40C5A1608
89.5%
98.6%
29.8%
69.5%
1A4B710621EF2E69B1F7790AE9B7A288
92.7%
98.8%
29.4%
69.5%
F4884C0458176AAC848A911683D3DEF5
91.4%
98.7%
29.6%
71.6%
4CA97FF9D72B422589266AA7B532D6E6
93.7%
98.7%
30.7%
71.6%
B48E578F030A7B5BB93A3E9D6D1E2A83
100%
100%
34.3%
73.0%
1B0E6BA299A522A3B3B02015A3536F6F
34.3%
73.0%
100%
100%
Table 4. Resulting Similarity and Confidence Rates of Pirpi Samples
Conclusion
The UPS threat group continues to exploit zero-day vulnerabilities in their campaigns, which shows that this group is quite sophisticated and has access to significant resources. Within their attack campaigns involving zero-days, UPS has consistently reused delivery techniques and code within various components of the attack. UPS has relied on steganography to conceal the payloads delivered after exploitation of zero-days by embedding payloads, specifically the Pirpi backdoor within animated GIFs. This group also reuses portions of their ActionScript within their malicious Flash files used to exploit vulnerabilities, as well as sharing portions of shellcode that executes after exploitation.
In regards to similarities amongst payloads, UPS delivers variants of the Pirpi backdoor that are typically very similar to each other. The Pirpi backdoors we analyzed use the same configuration file, a common C2 communications channel and a similar command handler. Also, the author of Pirpi includes several notable fingerprints within the code, specifically using a unique state machine and anti-disassembly techniques. Organizations can use all of these overlaps and similarities to track and hopefully protect themselves from this advanced adversary. AutoFocus users can identify Pirpi payloads with the Pirpi tag (Figure 9). WildFire automatically classifies Pirpi samples as malicious and we have released IPS signature 14643 to detect Pirpi C2 communications.
Cyber attacks are on the rise and the costs to businesses are increasing – recent estimates show that this could be as much as $USD500,000 and take an average of 24 days to identify and resolve. These figures in isolation make the situation appear dire. But understanding the cyberattack lifecycle before it reaches your data center – how a breach occurs, what happens once it’s in, and even just how long it takes to resolve – means you’re in the best position possible to prevent a successful attack from taking place at all.
Think about securing your organisation not as a house, with your security at front and back doors, but as a hotel, with security segmented by rooms and access levels. Network segmentation means multiple layers of protection that prevent hackers from moving freely within the network should they break through one layer.
