CryptoWall v4 Emerges Days After Cyber Threat Alliance Report

Less than a week after the publication of a thorough report by the Cyber Threat Alliance on the CryptoWall version 3 malware family, it appears that the actors behind the malware have updated the underlying code.

Beginning on October 30, 2015, Palo Alto Networks began seeing instances of this new version of CryptoWall, which some researchers have begun calling version 4. This new version CryptoWall includes multiple updates, such as a more streamlined network communication channel, modified ransom message, and the encryption of filenames. These changes not only make it more difficult for the victim to identify what files have been encrypted, but also may thwart security protections currently in place for the CryptoWall threat.

CryptoWall is a type of malware known as ransomware, which encrypts a victim’s files and subsequently demands payment in exchange for the decryption key. The ransom payment is typically collected using a form of crypto-currency, such as Bitcoin. Ransomware has been responsible for many millions of dollars in damages, and CryptoWall is one of the most lucrative ransomware families in use today.

CryptoWall Infections

To date, Palo Alto Networks has identified 10 unique instances of CryptoWall version 4. In total, 57 attempted infections have been witnessed.

Figure 1 CryptoWall v4 attempted infections

The samples have reportedly originated from phishing emails; however, this has yet to be confirmed. The following two URLs have been witnessed delivering this new version of CryptoWall:

Both of the above IP addresses are located in Moscow, Russia, and are hosted by Eurobyte VPS hosting provider.

CryptoWall Modifications

The CryptoWall authors have made multiple modifications to the malware in this version. Fortunately, the majority of the code base has remained consistent with version 3. As such, reverse engineers may use structures and decryption scripts that worked on previous samples. One of the more noticeable changes in the newest revision of CryptoWall is the updated ransom notification. As we can see below, it appears that the actors behind this threat have gotten a bit snarky with their verbiage.

Figure 2 New CryptoWall ransom message (HTML)

Readers might also notice a change in the color scheme, as the actors are now using a red, yellow, and grey combination. Previously, this color scheme used blue, green, and grey. It doesn’t appear as though this change has made its way to the PNG file provided to victims, which still has the same appearance as the previous CryptoWall version. Additionally, version information was removed from these messages, as previous notices specifically called the malware ‘CryptoWall 3.0’. This revision simply calls it ‘CryptoWall’.

Figure 3 New CryptoWall ransom message (PNG)

Another noticeable change is the fact that the malware will now encrypt not only the contents of targeted files, but the names of these files as well, as we can see in the screenshot below.

Figure 4 CryptoWall v4 encryption of filenames

Encryption of the filenames makes it much more difficult for victims to identify what files exactly were encrypted.

On the network communications side, the CryptoWall authors have streamlined the process a bit to minimize the number of HTTP requests made. Network encryption appears to remain consistent with previous versions, using RC4 with a key provided in the GET request (note that the key is sorted prior to decryption). However, the outbound requests to the following URLs are no longer present:

Additionally, the PNG file hosted by the C2 server is no longer provided in a separate response. Instead, it is included when the C2 server provides the RSA public key.

These changes limit the network-based exposure of the malware, making it more difficult for network-based security solutions to detect it.

Conclusion

As of this writing, it appears that this new version of CryptoWall is still in early use by attackers. Palo Alto Networks has witnessed 10 unique samples being used to conduct 57 attempted infections. The malware itself includes multiple modifications, including how files are encrypted as well as how network communications occur. Additionally, the content as well as the look and feel of the ransom notification have changed and appear to still be in development based on the discrepancies between the HTML files and PNG files shown to victims.

CryptoWall has been responsible for many millions of dollars in damages worldwide. The threat of ransomware has remained active for a number of years now, and shows no signs of stopping in the future. Individuals should remain vigilant about ensuring that suspicious emails are not opened and skeptical about navigating to unknown websites that are not trusted.

Palo Alto Networks WildFire customers are protected against this threat. Additionally, the latest version of CryptoWall is identified via the ‘CryptoWall’ tag in AutoFocus.

Appendix

The following SHA256 hashes of CryptoWall version 4 have been identified.

4ae64579fa0efd0be978c6797efe05d31517985b28ebd95dcadfacf3bb551f56
2d04d2a43e1d5a6920a806d8086da9c47f90e1cd25aa99b95af182ee9e1960b3
4c2d28a7ed5cf44b3641a9f6a5dfedd97b420e720376cb986062580cbda5ad3d
41fa6b1f25ae106a1a1c1734e6018e7c10efb4e31e4851d8fdc1a028d0249d63
bf352825a70685039401abde5daf1712fd968d6eee233ea72393cbc6faffe5a2
3a73bb154506d8a9a3f4f658bac9a8b38d7590d296496e843503323d5f9b7801
3509700469dfe290fa10f67490d763d14443ba7e571c974132bac0b385e69667
9bd0e36a9cc6a0754d695b27433fafba4f6c8ef82b71ccf20903d3d109e8e804
299b298b433d1cc130f699e2b5c2d1cb3c7e5eb6dd8a5c494a8c5022eafa9223
dd64fb6df49a21bfc3f59ac25346beec05f1f9414de6584b4469a6085e7efdd2

[Palo Alto Networks Blog]

WATCH: Nir Zuk Talks Cyber Spending, Automation and Balancing Security and Compliance

Palo Alto Networks was a sponsor of this week’s NYT Dealbook conference in New York, where our founder and CTO Nir Zuk discussed why too many companies throw “panic” money at cybersecurity and instead need to rethink how they can prevent advanced attacks using an automated, integrated security architecture.

Watch Nir being interviewed by New York Times President and CEO Mark Thompson:

[Palo Alto Networks Blog]

Insecure Mobile Apps: An Urgent Call for Best Practices in App Development

Application security continues to be a growing concern according to respondents of the latest (ISC)2 2015 Global Information Security Workforce Study.  Consistent with the past two (ISC)² studies in 2011 and 2013, application vulnerabilities and malware are at the top of the list. These concerns are trending upward as 72 percent of survey respondents in the 2015 study selected this vulnerability and threat as either a top or high concern. As mobile platforms increasingly become the choice for delivering services, applications on the mobile devices are also a top concern for information security professionals.

As more sensitive data and transaction data is transmitted on mobile communication channels, the security risks associated with unreliable communications, such as public Wi-Fi, have to be addressed. Secure Sockets Layer/Transport Layer Security (SSL/TLS) has been widely used for authentication and encryption. However, fraudsters can set up fake Wi-Fi access points and fake Secure Sockets Layer (SSL) certificates to conduct man-in-the-middle (MITM) attacks to capture sensitive data.

Fig.1 Testing Environment – Simulate MITM attack; Source: “Best Practice Guide (SSL Implementation) for Mobile App Development” jointly published by PISA & HKCERT

In view of the growing concerns, Hong Kong Professional Information Security Association (PISA), the (ISC)2 Hong Kong Chapter, the Special Interest Group of PISA and Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) conducted a study on transaction security of mobile applications in Hong Kong. Based on our target scope of the study and search criteria, we tested a total of 130 mobile apps. One-third of mobile apps that involved payment transactions and personal information collection were found to be insecure. Thirty-four percent were vulnerable (i.e. vulnerable and serious); and 62.5 percent of financial securities apps did not validate the SSL certificates. With a vision to raise the awareness of public and mobile developers on the security of SSL implementation of mobile apps, we also released a report on “Best Practice Guide (SSL Implementation) for Mobile App Development” for mobile app owners and developers to use as a reference.

The collaboration between PISA & HKCERT was a perfect match, as PISA was responsible for providing technical advice on the Guide while HKCERT utilized its proven incident response mechanism for the study. While conducting the study, we were in contact with regulatory agencies and organizations in public and private sectors to follow up on rectifying the vulnerabilities found in the mobile apps.

Fig.2 Level Distribution of 130 Apps

The release of the report is only the beginning of our efforts to raise the awareness of mobile apps security. If we, as information security professionals, can conduct this study in various economies and compare the results, we can help raise attention and foster collaboration between government, regulatory and industry stakeholders in regards to application security. — Frankie Wong, CISSP, and Eric Fan

For more information about the study, the full report and Best Practice Guide are available at:

HKCERT Security Bloghttps://www.hkcert.org/my_url/en/blog/15092402

September 2015 PISA Journalhttp://issuu.com/pisajournal/docs/pisa_j22

About the authors:

Frankie Wong, CISSP, (frankie.wong@pisa.org.hk), Vice-Chairperson, PISA, Hong Kong

Eric Fan (eric.fan@pisa.org.hk), Hon. Secretary & Treasurer, PISA, Hong Kong

[(ISC)² Blog]

Connecting the Dots in Cyber Threat Campaigns, Part 2: Passive DNS

This is the second part of our series on “connecting the dots,” where we investigate ways to link attacks together to gain a better understanding of how they are related. In Part 1, we looked at how domain WHOIS information can be used to identify connections between malicious domains and potentially the actors who own them. In Part 2 we dive into Passive DNS (PDNS), which allows analysts to look back in time and discover how a domain has been used in the past.

Why Passive DNS?

Before we jump into PDNS, we need to understand DNS, or the Domain Name System.  DNS is often described as the phonebook of the Internet (For our younger readers who may be wondering what a phonebook is, Wikipedia can explain.) Rather than ask users to remember individual IP addresses, DNS instead maps numerical addresses to easy-to-remember domain names, much like a person’s name might be associated with a specific phone number. So instead of memorizing that Google hosts their search engine on 65.199.32.22, you simply need to remember http://www.google.com. The system solved an enormous usability issue at the onset of the Internet, but unfortunately left room for abuse as well.

Unlike a paper phonebook, which remains static until a new version is published, DNS allows for constant dynamic updates that allow the system to be more flexible. Domain name owners can update their Domain-> IP mapping as often as they like and users will always be able to get the correct results because the lookups are dynamic.

When your computer needs to find the IP address associated with a domain, it sends a query to a recursive DNS server, which reaches out to a series of DNS servers to retrieve a response. A DNS response contains an answer to the query, which contains the information your computer needed. Below is a simplified answer for a query for http://www.google.com.

http://www.google.com  A    65.199.32.22

First we have the queried name, followed by “A” the record type, and finally an IPV4 address which Google has associated with the domain. This answer is good for a set period of time (known as a time to live or TTL), which can be days or longer, but is often quite short.

As the system is dynamic, the mapping of a domain to an IP is ephemeral; there’s no way for a DNS server to tell you what IP address a domain name resolved to five minutes ago, let alone five years ago. Additionally, there’s no way to perform the reverse mapping, where one can find all of the domain names that have resolved to a specified IP address. Passive DNS was introduced to solve these and other problems with investigating DNS abuse.

How PDNS Works

PDNS was created in 2004 by Florian Weimer and introduced widely at the FIRST conference in 2005. The technology is a fairly simple concept: a network device (sensor) captures all DNS answer messages and forwards them into a central database that logs the relevant information, the queried domain, the answer and a timestamp of when the request occurred. This creates a historical index of IP to domain and domain to IP mappings that have occurred on the monitored network.

The fact that the database only contains information from the network your sensor monitors is one of the major challenges for users of PDNS. Unless the data from these systems is melded into a single query interface, the analysts using them will have different data sets. If a domain has never been queried inside your network, you’ll have no data on it at all. There are multiple partial solutions to this problem, which we’ll discuss in later sections.

What can PDNS do for you?

For an intelligence analyst, making a connection between two components in an attack can provide new insight into an investigation. You may find that two previously unlinked attacks actually share a command and control server, or find out about infrastructure that may have been used in attacks you have not yet discovered.

In July 2015, we published an article describing an attack on the US government by an APT group known as UPS a.k.a. APT3. Our data showed that two subdomains of a seemingly legitimate website, rpt.perrydale[.]com and report.perrydale[.]com had been involved in the attack. DNS queries for these subdomains compared to the legitimate “www” domain (www.perrydale[.]com) revealed that “www” was hosted on an IP address in the United States, where the other subdomains mapped to an IP address in Ukraine.

We used PDNS to search for any other domains associated with the Ukrainian IP, which immediately produced three additional subdomains with suspect names (such as wwww) that may have been part of the attack campaign.

Additional analysis was required at this point to confirm these subdomains were also malicious, but PDNS allowed us to discover the fact that these subdomains existed and were associated with a the Ukrainian IP.

PDNS Pitfalls

Now that you have seen the benefits of using PDNS to connect attacks, it’s critical to understand that not every connection is valid.

Here are some of the situations to be weary of when using PDNS to make connections in your analysis.

  • Domain Names Change Hands: A domain used in an attack three years ago has likely expired and been re-registered by a completely unrelated entity. This could be a domain name reseller or just a regular individual. You can use WHOIS data to discover when these changes happened, which will help you gauge the validity of these connections.
  • IP Addresses Change Hands (and may be shared): In the same way that a domain name can be transferred from one individual to another, IP addresses are often used by many different entities, sometimes at the same moment. This has become especially important in the era of cloud services, where a server can be created and destroyed with the press of a button. Without knowledge of when the IP address was in an actor’s control to back you up, an IP->domain connection may be invalid.
  • Sinkholes (and parking websites) are everywhere: In the course of your analysis, you may come across an IP address hosting thousands of domain names. One common scenario is that the domain name has expired and an individual has re-registered it in case someone else purchases it in the future for a higher price. These domains are typically “parked” on a server that states the domain name is for sale, and this IP address should be considered invalid for all connections. The second common scenario is when security researchers create a “sinkhole” to which many previously malicious domain names point in order to collect data. Similar to the parking websites, these sinkholes are not useful for making connections, but should be a clear indication that someone else is investigating your subject.

How can I get started?

As mentioned above, you could run your own passive DNS sensor (like dnslogger), which will give you information about your own network, but that’s only going to show you a small section of the world. Having insight into your own DNS requests is certainly valuable, but from an intelligence perspective you may want a broader view.

There are many PDNS sources on the web, which can be queried to expand the amount of information available, here are just a few:

You may also consider the FarSight Passive DNS service, which aggregates data from a large number of PDNS sensors. Finally, if you want to make your life as easy as possible you should take a look at PassiveTotal, which aggregates many of these sources into a single interface with additional features.

Regardless of how you may choose to implement PDNS in your workflow, it is an important tool to have during intelligence analysis and collection. You can leverage this tool to not only identify active, real time threats, but also begin visualizing and mapping out adversary infrastructure to help answer the questions of who, what, when, why, and how.

[Palo Alto Networks Blog]

New on SecurityRoundtable.org: Considerations When Hiring a CISO and More!

This week on SecurityRoundtable.org, Kal Bittianda, who leads the cybersecurity practice at global executive search and assessment firm Egon Zehnder, discusses what boards and C-level executives need to consider when hiring a CISO.

In a highly competitive market, Kal notes, even organizations that can effectively evaluate candidates must be prepared from the start to sell the CISO opportunity and understand the mentality from which qualified CISO candidates approach the job.

We also have a new video featuring Brian Kelly, Chief Security Officer at Rackspace. He advises that organizations should have outside experts in place to help with everything from incident response to crisis communications. Watch his video to hear him share more lessons learned around cybersecurity.

Palo Alto Networks partnered with the New York Stock Exchange to produce Navigating the Digital Age: The Definitive Cybersecurity Guide for Directors and Officers. We intend this book to be both a how-to guide and an anthology, and it includes advice and cybersecurity best practices from some of the community’s sharpest minds.

Join us at SecurityRoundtable.org to get your copy of the guide and help us keep the conversation going.

Follow us for the latest on SecurityRoundtable.org:

[Palo Alto Networks Blog]

English
Exit mobile version