Month: March 2016

Ransomware is often in the headlines as new families are discovered on an almost weekly basis. Historically, these families have shared one similarity – they have all been deployed by attackers casting a wide net and largely being victim-agnostic. In most cases, the adversaries have used phishing emails and exploit kits in a ‘spray and pray’ style tactic.

However, in recent months, a new trend seems to be emerging: targeted attacks where ransomware is deployed by threat actors after successfully gaining unauthorized access to an organization’s network. One malware family seen in such attacks is known as ‘SamSa’, ‘Samas’, ‘samsam’, or most recently, ‘MOKOPONI’. Reports on this malware family have previously been published by both Intel Security and Microsoft.

Palo Alto Networks has collected over 20 samples of this particular malware family, and we have identified over $70,000 USD in Bitcoin payments to the attacker (Cisco Talos yesterday reported this figure to be closer to $115,000 USD). This blog details the evolution of this malware family, which was first witnessed in December 2015, as well as provides various indicators of compromise (IOCs) that can be used by the security community.

How the Malware Is Installed

As reported by both Microsoft and Intel Security, the malware is installed in a very targeted manner and appears to be in use post-compromise. First, the attacker will gain unauthorized access to a victim network, then begin mapping out the network in order to move laterally and discover more potential victim hosts. Once the attacker has sufficiently found enough victim systems, SamSa is deployed manually, using common system administrator utilities, such as PSExec.

After deploying the malware on various victim hosts, it will be installed using a RSA public key that is generated specifically for that particular attack. Additionally, a batch script is deployed that is responsible for deleting volume shadow copies on the victim machine to prevent restoration of files, executing SamSa, and finally self-destructing after successful encryption.

Malware Details

With the exception of the earliest known samples of SamSa, the malware expects an RSA public key file to be provided manually as a command-line argument. This is quite different from other ransomware families that retrieve the public keys automatically from command and control servers. The initial samples of SamSa actually embedded the public RSA key within the malware itself. More information on these changes can be seen in the ‘SamSa Evolution’ section below. In the event a public key is not provided as a command-line argument, the malware will exit, which provides minimal contextual evidence when run in a sandbox environment.

Figure 1 SamSa code looking for RSA Public Key

The malware proceeds to create a directory that will subsequently be used to store a batch script that is responsible for removing the SamSa executable after it completes its operation.

The following folders have been identified over the 23 analyzed samples:

%APPDATA%\FontCachedManager
%APPDATA%\MacroReder
%APPDATA%\SystemAccountManager

These folders will eventually contain an embedded file that is dropped by the malware called either ‘selfdel.exe’ or ‘del.bat’, which is responsible for removing SamSa.

The malware then seeks out a number of files based on an embedded list of file extensions. Presumably for performance reasons, SamSa will ignore the Windows directory, paths containing ‘Reference Assemblies\\Microsoft’ and the recycle bin.

Figure 2 Malware ignoring certain directories

The number of file extensions changes slightly over the course of the malware’s evolution. It averages between 327 to 345 different file extensions.

After identified files are discovered, they are encrypted using the supplied RSA public key and have the ‘.encryptedRSA’ file extension appended to them.

Figure 3 SamSa encryption routine

The malware then writes a ‘HELP_DECRYPT_YOUR_FILES’ file with an extension of either .html or .txt. This file contains instructions on how the victim may recover their files.

Each sample has a unique bitcoin address where the victim must provide payment. Payments vary based on the victim. Some instances require the victim to pay per machine, while others require the organization to pay a lump sum. A breakdown of payments is shared later in this post.

SamSa Evolution

Since witnessing the first sample with a compile time of December 9, 2015, we’ve observed that the malware author has made a number of small changes to the code base. The oldest sample actually appears to be a test executable, where the author placed a number of obviously fake placeholders instead of actual data, as seen below:

Figure 4 Snippet of ransom page from initial test SamSa file

Only a day after this first executable was compiled, we saw the attacker create two unique samples with actual bitcoin addresses, blog addresses, and demands for 37 BTC and 50 BTC respectively.

Code Changes

As the malware continued to evolve, the author included simple code obfuscation routines, such as hex-encoding sensitive strings, adding underscores in variable and function names, and in some cases, inclusion of garbage code.

Figure 5 Code obfuscation added by the malware author

File Extension Changes

Initially, the malware authors included 344 file extensions. Starting in mid-December 2015, this number changed to eventually settle on 327 extensions. The following file types were added and removed during this transition:

Added:

‘.kbx’, ‘.php5’, ‘.phtml’, ‘.xml’, ‘.tif’, ‘.tib’

Removed:

‘.vmsn’, ‘.vmsd’, ‘.gif’, ‘.chm’, ‘.nvram’, ‘.vb’, ‘.bin’, ‘.cnf’, ‘.vmem’, ‘.cab’, ‘.dat’, ‘.log’, ‘.vbs’, ‘.data’, ‘.js’, ‘.jse’, ‘.xls’, ‘.vmdk’, ‘.jin’, ‘.vmx’, ‘.vmxf’, ‘.gz’, ‘.conf’

Another change occurred in mid-February 2016, when the attacker added the ‘.xls’ file extension. Finally, starting in mid-March 2016, the following three extensions were added:

‘.config’, ‘.asmx’, ‘.vb’

Figure 6 Number of file extensions in SamSa over time

Ransom Notice Changes

Over the course of SamSa’s lifetime, the ransom notice changed from a simple txt file to HTML files. These changes can be seen below:

Figure 7 Ransom page version 1

Figure 8 Ransom page version 2

Figure 9 Ransom page version 3

Domain Changes

Over the past four months, the attacker has changed hosting providers for the victim’s payment website. Initially, the attacker made pages using the anonymous ‘www.anonyme[.]com’ web service. Starting in January 2016, the attacker switched tactics to instead use web pages hosted by wordpress[.]com. Finally, starting in mid-February 2016, the anonymous TOR network was used to host these web pages.

Figure 10 SamSa domain changes over time

Bitcoin Demands

Unlike other ransomware families, the attacker behind SamSa will either demand a large lump sum for the decryption key for all infected machines in an organization, or will demand a smaller amount for each infected machine. Initially, in December 2015, the attacker favored a lump sum. In January 2016, the attacker changed tactics and instead asked for either 1 or 1.5 Bitcoin (BTC) per infected machine. Finally, since February 2016, the attacker appears to have returned to requesting a large sum of BTC. The breakdown can be seen below:

Internal Filename

Another curious development occurred in mid-March 2016, when the malware author changed the internal name of the malware from ‘samsam’, which is likely how the malware was originally named, to ‘MOKOPONI’. It’s unclear why this change was made. It is worth noting that all samples named ‘MOKOPONI’ have been observed using the same C2 address of ‘roe53ncs47yt564u[.]onion’ with unique URIs.

SamSa Attacker Profits Gained

By tracking the unique BTC addresses found within all of the collected samples, we were able to determine when victims made specific payments. The following table shows payments made to the various BTC wallets:

By adding up the paid amounts, we get a total of 166.422305 Bitcoin, which, based on the current Bitcoin exchange rate, amounts to roughly $70,000 USD made by the attacker since December 2015. (A report by Cisco Talos yesterday put this figure as high as $115,000 USD.)

The two payments of 40 BTC are particularly interesting, as they took place on February 3 and 5 respectively. These payments were made at roughly the same time that reports came out of the Hollywood Presbyterian Medical Center meeting demands for 40 BTC to ransomware that hit their organization. While evidence is circumstantial, it is possible that SamSa was directly responsible for this particular incident.

Another interesting piece of evidence comes in the form of public notes attached to the payments made to 1KwgwwWdoL9VFcg9VuCDGBiVZ2LNzGnrov. Specifically, the following notes are present for payments of 22 BTC and 18 BTC respectively:

Public Note: For HPMISDTJRTJBM1 and HPMGPS01
Public Note: For HPMISDTJRTJBM1 AND HPMGPS01 FOR ALL AFFECTED PC

Again, this is purely speculative, but it’s certainly possible that these strings are hostnames, and the ‘HPM’ characters may stand for Hollywood Presbyterian Medical.

Conclusion

Overall, SamSa has been a serious threat that has stayed under the radar until recently. The malware has been seen since December 2015, and is likely responsible for a number of large ransomware infections across organizations. While the malware itself is not terribly sophisticated, the tactics used by the attackers, such as the lack of command and control infrastructure, the ability to compromise external facing systems to gain unauthorized access, and movement towards more obfuscation, make SamSa a serious threat.

IOCs for SamSa collected by Palo Alto Networks can be found here.

Palo Alto Networks’ customers are protected from this threat in the following ways:

1. WildFire accurately identifies all SamSa malware samples as malicious.
2. Domains used by SamSa have been flagged as malicious in Threat Prevention.
3. AutoFocus users can view malware related to this attack using the SamSa

Josh Grunzweig and Bryan Lee

[Palo Alto Networks Research Center]

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]