Blog

Two weeks ago, the U.S. Department of Homeland Security (DHS) conducted a national-level exercise, Cyber Storm V, designed to test the nation’s Emergency Preparedness procedures. Palo Alto Networks participated by providing cybersecurity expertise during the planning process and as players by using the exercise to test our own internal cyber incident crisis management plan.

The players, located across the United States and around world, cut across multiple sectors and spanned numerous industries, provided real-time input in order to test our ability to combat cybersecurity threats.

The game’s diabolical scenario tested the participants and forced all the game players into a Sophie’s Choice: picking the better of two really bad choices. The exercise scenario highlighted a compelling case for taking proactive preventative measures as a necessary precursor to detection and remediation.

The Creation of Cyber Storm

Cyber Storm is DHS’s name for a nationwide cybersecurity exercise that assesses response capabilities during a nationally significant cyber incident. DHS conducted the first exercise in 2006 and has conducted similar exercises every two years since.

Last week, DHS completed Cyber Storm V and Palo Alto Networks participated by providing cybersecurity expertise during the Exercise planning process, and by actively participating in the game play as a representative organization, in this case a cybersecurity vendor, where the leadership had to react to the escalating cyber events occurring during the exercise. At the end of the exercise, we briefed the Palo Alto Networks executive staff – the CEO, CFO, Chief Legal Counsel, along with the heads of Product Management, Engineering, Corporate Communications, and others – about the exercise and posed to them the many decisions they would have to make if the exercise events were a real situation. In other words, Palo Alto Networks used Cyber Storm V as a way to exercise our internal response procedures to a crisis situation.

Cyber Storm V Takeaways

The Department of Homeland Security conducted an exercise “hotwash” at the conclusion of the exercise and will conduct a more detailed After Action Review (AAR) after soliciting input from all the participants over the course of the coming weeks and months. We expect DHS to publish the results of that review sometime following the completion of this formal process. I am not at liberty to discuss the specific scenario that DHS unleashed upon the game players until after they publish their report, but let me just say that it was diabolical. They designed the ever-escalating events to put the entire nation into a Sophie’s Choice in which government and commercial leaders had to choose between two bad options, both of which could result in a significant material impact to the commercial and government entities involved in the incident, and might even cause effected entities to cease to function. Like I said: diabolical.

It occurred to me while Palo Alto Networks was playing the game, however, that a substantial portion of the impact from this diabolical cyber incident progression can be avoided with prevention measures applied strategically in the initial phases of the attack cycle, rather than solely relying upon the notion of detection and response (although I’m not making light of the fact that many exercise objectives in Cyber Storm V were clearly designed to test the ability of the public and private sectors to coordinate detection and response, which is certainly important).

In the exercise, by the time the network defender community detected the seriousness of the event progression, it was already too late, and they were all forced into the aforementioned Sophie’s Choice. This raises a key point and an important takeaway from the exercise: prevention is a precursor to detection and remediation. By putting strong prevention components in place, the diabolical scenario would never have escalated as far as it did.

Throughout the exercise, we observed that delivering new preventative controls to the impacted parties would significantly reduce the impact of the attacks, mitigating a significant portion of the damage. Bottom line: while detection and remediation must be practiced, it must be a supplement to strong, swift prevention measures.

Threat prevention, threat detection, and threat eradication accomplish key and indispensable network defender activities. Individually, each is important but by itself not sufficient to prevent high-risk material impact to the organization. They are inextricably linked: atomic and irreducible. They are the network defender’s trinity, and the network defender must be proficient at all three.

Trinity programs will not stop all adversary groups immediately. What they will do – when installed properly – is provide a framework to block every threat that is known, allow network defenders to discover new threats as they emerge, and provide a mechanism to mitigate any newly discovered adversary campaign activity within their organization.

It All Boils Down to the Network Defender Trinity Program

The Cyber Storm V exercise provided a good scenario to exercise both the nation, as DHS matures its Emergency Preparedness plan, and the executives of Palo Alto Networks as we continue to hone our own internal crisis planning procedures. We believe that in order to combat these types of threats, our nation’s network defenders must put the trinity program in place, specifically threat prevention. If we implement aggressive preventative measures, as part of a fully formed Network Defender Trinity Program, it will transform these types of diabolical scenarios into just another routine day.

References

“Informing Cyber Storm V: Lessons Learned from Cyber Storm IV,” by Homeland Security, June 2015

“Cyber Storm: Securing Cyber Space,” by Homeland Security, 1 December 2016

“Cyber Storm exercise tests cyber defense strategies,” by Michael Hardy, Federal Times, 8 March 2016

Rick Howard

[Palo Alto Networks Research Center]

Network outages and cyberattacks cause unplanned downtime. And most organizations are seeing dramatic growth both in data center traffic and the use of web-scale ready applications. These trends have resulted in an increased density of business-critical workloads driving requirements for high availability network designs that can handle workload mobility and business continuity.

To ensure highly available and continuous protection of network infrastructures, Palo Alto Networks Next-Generation Security Platform supports active/passive and active/active high availability deployment modes. Active/passive high availability remains the most commonly deployed method of stateful failover for three reasons:

• Active/passive (A/P) designs are simple to implement and maintain over a period of time.
• State information associated with all network flows is synchronized with no loss of connectivity between endpoints on either side of the next-generation firewall.
• With A/P high availability implementation, the passive unit can effectively handle the network load in case of active unit failure.

In certain networks requiring continuous protection and the ability to handle asymmetric traffic, or run active routing protocols on all firewalls within a high availability configuration, active/active high availability features can address those requirements.

Palo Alto Networks next-generation firewalls provide comprehensive high availability options with features such as sub-second stateful failover, link and path monitoring capabilities. Organizations have the flexibility to implement advanced high availability deployments in full mesh active/passive and active/active failover configurations. This provides customers with continued protection from network-based attacks and secures connectivity to meet today’s business requirements.

For more information, please visit:               

• Palo Alto Networks High Availability Website
• 5 Reasons Why You Should Consider High Availability Deployment of Next-Generation Firewalls

Sai Balabhadrapatruni

[Palo Alto Networks Research Center]

In 2015, Sucuri published two blog posts, one in March describing a pseudo-Darkleech campaign targeting WordPress sites, and another about its evolution the following December. Sites compromised by this campaign redirected unsuspecting users to an exploit kit (EK). The Sucuri posts describe patterns in the injected script related to this campaign. Since December 2015, patterns associated with pseudo-Darkleech have continued to evolve. Our blog post today will examine these changes.

However, before we look at the recent developments, we should understand how EKs fit into the overall picture and review the history of Darkleech.

Path to an Exploit Kit

An EK is used by criminals to infect unsuspecting users while they are browsing the web. EKs are hosted on servers dedicated to the EK. The EK will check if a user’s computer is vulnerable and send the appropriate exploit. That exploit is used by the EK to send malware, execute it as a background process, and infect the user’s computer.

This malware is the EK payload. Most payloads are designed to infect computers running Microsoft Windows. Different EKs are available to criminals for this purpose. Notable EKs in recent months include Angler, Neutrino, Nuclear, and Rig.

How are web browsers directed to these EK severs? Since users won’t intentionally view an EK, criminals must establish a path behind-the-scenes. The first step in this process is a compromised website. These compromised websites are legitimate pages with hidden script that initiates a network connection to the EK. This is the most direct path to an EK.

Criminals sometimes use another server as a gate between the compromised website and the EK server. In some cases, you’ll find more than one gate in this path. However, pseudo-Darkleech traffic doesn’t appear to rely on gates. From what we can tell, the injected script most often points directly to an EK’s landing page.

Enter Darkleech

Darkleech is the name of a campaign that infected thousands of Apache servers starting in 2012. More specifically, Darkleech refers to an Apache module available on the black market that was used for malware distribution. In 2013, many organizations had reported on Darkleech. At the time, servers infected with Darkleech led to Blackhole EK.

Below are examples of injected script from compromised websites running the Darkleech module in July and August 2012.

Figure 1: Example of injected script from July 2012.

Figure 2: Example of injected script from August 2012.

Patterns for this injected script remained relatively consistent throughout 2013. But changes were coming. By October 2013, Russian authorities had arrested Paunch, who allegedly created the Blackhole EK. Within a few months, Blackhole EK disappeared from the scene. By early 2014, the same Darkleech pattern was pointing to No-IP.com domains (hopto.org, ddns.net, myftp.biz, serveftp.com, etc). These No-IP domains were either gates to an EK, or they directly hosted EKs like Fiesta.

Figure 3: Injected script from March 2014 pointing to Fiesta EK.

Figure 4: Another example of injected script from November 2014.

Enter Pseudo-Darkleech

In March of 2015, Sucuri published a blog identifying these newer patterns of injected script from early 2014 as “pseudo-Darkleech.” Why use “pseudo” to describe this campaign, especially if the injected script looked the same as before? Because the injected script was now seen from IIS sites, where previously it had only been noticed on Apache servers. As the year progressed, pseudo-Darkleech script was found pointing to Angler EK and delivering ransomware like CryptoWall].

Figure 5: Injected script pointing to an Angler EK landing page in July 2015.

These patterns remained consistent until late September 2015. At that time, injected script caused by pseudo-Darkleech dramatically changed. The script became highly-obfuscated. It looked nothing like previous Darkleech patterns, and you couldn’t easily determine the URL it would generate.

Figure 6: Injected script from September 2015.

An example of this injected script from October 2015 has been isolated and posted to Pastebin. Using a tool named Revelo from Kahu Security, you can quickly see what the script does. As shown below, the script tries to access a URL, and the URL matches patterns for Angler EK.

Figure 7: Injected script from October 2015 run through Revelo.

Later in 2015, pseudo-Darkleech injected script occasionally switched between Angler EK or Neutrino EK as it delivered ransomware like CryptoWall or TeslaCrypt. By December 2015, Sucuri published a new blog post covering these most recent updates on pseudo-Darkleech injected script. Even with the injected script’s new patterns, Sucuri reported that server-side indicators remained the same as it had reported in March 2015. This activity was still pseudo-Darkleech.

Recent Developments

Since September 2015, patterns associated with pseudo-Darkleech have evolved. Any changes were minor until early February 2016, when we saw the addition of a sizable block containing numeric characters in the injected script.

Figure 8: Start of pseudo-Darkleech injected script from early February 2015.

Figure 9: End of pseudo-Darkleech injected script from early February 2015.

Since that time, the characters separating the numbers in that large block of numeric characters have changed. For example, on 2016-02-24 they switched from spaces to commas. By 2016-02-29, pseudo-Darkleech had switched to semicolons. By 2016-03-07, we saw asterisks. On 2016-03-14, the patterns had changed yet again.

Figure 10: Start of pseudo-Darkleech injected script from 2016-03-07.

Figure 11: Start of pseudo-Darkleech injected script from 2016-03-14.

Conclusion

Since it was first called pseudo-Darkleech by Sucuri in March 2015, members of the security community have found websites compromised through this campaign on a daily basis. Withtens of thousands of compromised sites reported in 2013 under the original Darkleech banner, pseudo-Darkleech continues the onslaught with no signs of slowing down.

In recent weeks, this campaign has led to Angler EK delivering a ransomware payload, especially TeslaCrypt. Pseudo-Darkleech and the associated Angler EK traffic remain a persistent and evolving threat. Both Darkleech and Angler frequently change patterns to avoid detection. Palo Alto Networks researchers have already examined Angler EK and published an in-depth report containing indicators in January 2016. We continue to investigate pseudo-Darkleech and Angler EK for applicable indicators to inform the community and further enhance our threat prevention platform.

Indicators of Compromise

Domains and IP addresses from websites compromised through this campaign are continually changing. Below are recent examples of the injected script caused by pseudo-Darkleech that have been isolated and posted to Pastebin:

• 2015-10-13 – http://pastebin.com/XCe7ZHz8
• 2015-12-16 – http://pastebin.com/DrUtXgxM
• 2016-02-05 – http://pastebin.com/Knz2bYR0
• 2016-02-24 – http://pastebin.com/K053dSti
• 2016-02-29 – http://pastebin.com/EcHHmu0p
• 2016-03-07 – http://pastebin.com/zmjRguGW
• 2016-03-14 – http://pastebin.com/QWb09vJJ

Brad Duncan

[Palo Alto Networks Research Center]

In February 2016, Unit 42 published detailed analysis of Locky ransomware. We certainly weren’t the only ones who saw this malware, and many others have also reported on it. Since that time, Locky has been frequently noted in various campaigns using malicious spam (malspam) to spread this relatively new strain of ransomware.

When we initially reported on Locky, attackers were distributing the malware using Microsoft Office documents with malicious macros to download and execute the ransomware. Attackers quickly added another tactic, sending e-mails with zip attachments containing malicious Javascript files to accomplish the same goal. However, exploit kits (EKs) have also been used to infect users with Locky from casual web browsing. This activity suggests that there are effectively two paths to Locky: one through malspam and another through EK traffic.

Figure 1: An example of two paths to Locky from February 2016.

The EK path is rarely mentioned. So far, we have seen very little reporting on Locky’s propagation through EK traffic. Some sources noted Neutrino EK was used to send this malware, but no more has been publicly announced on the subject.

In recent days we have noticed Locky attempting to infect systems using the Nuclear EK.

Details

In February 2016 when Neutrino EK was first reported delivering Locky, we found a pcap of the traffic and saw the following pattern:

Figure 2: Wireshark display of Locky sent by Neutrino EK on 2016-02-16.

Proofpoint reported similar traffic and stated it was Locky distributed by a Neutrino EK thread known for spreading Necurs. This month, we ran across the same type of gate. This time, traffic patterns after the gate were similar to what we’ve seen for Nuclear EK. The payload was either Locky, or it was a downloader that retrieved Locky from another domain.

Figure 3: Wireshark display of Locky sent by Nuclear EK on 2016-03-15.

Figure 4: Wireshark display of Nuclear EK on 2016-03-16 sending a payload that downloaded Locky.

A Windows host infected with these Locky samples looks similar to previously-infected hosts when we first reported about the ransomware in February 2016.

Figure 5: A Windows host after being infected with Locky on 2016-03-16.

Conclusion

As noted in our previous blog post about Locky, Palo Alto Networks customers are protected from Locky through our next-generation security platform. WildFire continues to detect Locky, and AutoFocus identifies this threat under the Unit 42 “Locky” tag.

We continue to investigate Locky and EK traffic for applicable indicators to inform the community and further enhance our threat prevention platform.

Indicators of Compromise

Date/time range: 2016-03-15 and 2016-03-16
Gate IP address: 91.195.12.177
Gate domain: sed.poudelkamal.com.np
Nuclear EK IP address: 46.101.8.169
Nuclear EK domains: lotos.castrumtelcom.com.br , here.jninmobilaria.com.ar
Follow-up malware IP address: 46.148.20.32
Follow-up malware domain: js.cefora.com.ar
IP addresses from post-infection traffic caused by Locky ransomware:

• 51.254.181.122
• 51.255.107.8
• 78.40.108.39
• 149.202.109.205

Exploits and malware noted:

• Description: 2016-03-15 Nuclear EK Flash exploit
• SHA256 hash: 94bd74514cc9e579edf55dd1bac653ceca1837d930d109c6e701afe309b23310

• Description: 2016-03-16 Nuclear EK Flash exploit
• SHA256 hash: 4228036684f4f519704a102cd9322ac9edb1bfb5b20558a7a6873818f0e6a7b4

• Description: 2016-03-15 Nuclear EK payload – Locky ransomware
• SHA256 hash: faf4f689683f3347738ef0a8370a78d504b513d44f3a70f833c50de3d138c3b2

• Description: 2016-03-16 Nuclear EK payload – file that downloaded Locky ransomware
• SHA256 hash: a9dac0a0389c463b063cb30f647b3d1610e6052570efe2dfb1fca749d8f039fc

• Description: Locky ransomware downloaded by Nuclear EK payload (soft.exe)
• SHA256 hash: cc2355cc6d265cd90b71282980abcf0a7f3dcb3a608a5c98e7697598696481af

Brad Duncan

[Palo Alto Networks Research Center]