Learn All About CryptoWall 3 and the Cyber Threat Alliance

Recent research from the Cyber Threat Alliance yielded a breakthrough in analyzing CryptoWall, a worldwide cybersecurity threat that has caused an estimated $325 million in damages worldwide. Join us for a new webinar to learn more about the motivations and tactics of malicious actors behind CryptoWall, and also understand why the Cyber Threat Alliance is leading the way when it comes to peer information sharing and actionable threat intelligence.

Join us on Tuesday, December 1 for “Lucrative Ransomware Attacks: Analysis of the Cryptowall Version 3 Threat.” The research team behind the Cyber Threat Alliance report will walk through:

  • The full anatomy of the CryptoWall 3 attack lifecycle, propagation vectors, malware analysis, and campaign infrastructure.
  • Global impact of this lucrative and broad-reaching crimeware campaign.
  • Recommended protections and mitigation actions, including all Indicators of Compromise (IOCs)

The Cyber Threat Alliance was co-founded by Fortinet, Intel Security, Palo Alto Networks and Symantec to share threat intelligence on advanced cyber attacks and to enhance protections from these damaging attacks. Read more about the mission of the CTA and why this is so important to the Palo Alto Networks community in Rick Howard’s recent blog post.

[Palo Alto Networks Blog]

Global Privacy Study: How Does Your Organization Compare?

Major privacy breaches of customer data records are becoming common news headlines, shattering the trust of customers who expected the affected enterprises to protect their personal information. Almost 75 percent of the respondents to ISACA’s 2015 Privacy Survey indicate that their enterprises’ use of privacy policies, procedures, standards and other management approaches is mandatory, while 19 percent indicate that their use is “recommended.” This finding is a reflection of good practice because written policies and procedures should be at the heart of every enterprise, regardless of size.

However, less than one-third of the surveyed privacy professionals are very confident in their enterprise’s ability to ensure the privacy of its sensitive data. This is confirmed by the fact that more than half of surveyed privacy professionals believe that consumers should not be confident that enterprises are protecting their personal information.

Slightly more than 90 percent of the respondents to the survey report that the privacy function has a significant or moderate level of interaction with information security. This may explain why the CISO/CSO is a consistent selection as the role with primary accountability for privacy across all enterprise sizes. Unfortunately, nearly 8 percent report that no one is assigned to privacy accountability.

More than half of the respondents identify a lack of training or poor training as the most common type of privacy-related failure. This put an emphasis on the fact that privacy governance/management depends on regular, consistent monitoring of the program effectiveness, coupled with a commitment to making changes when weaknesses are spotted.

Any enterprise program as complex as privacy—requiring the coordinated efforts of many departments and individuals—requires a formal system of governance and management. Having the appropriate leadership and staff structures is an integral part of privacy governance and management. Increased (and increasingly diverse) regulation adds to the complexity, making an effective system of governance and management that involves frameworks, standards, policies and metrics a requirement. Operating in multiple jurisdictions adds a layer of complexity to privacy programs because it requires knowledge of and compliance with a wide variety of differing global regulations.

All of this is why ISACA is developing privacy principles for enterprises to use to develop a privacy program that is adaptable, flexible and applicable to the global population, with plans to publish the principles in the near future. These principles will use the COBITframework to provide structure and an implementation road map to guide practitioners through privacy management activities.

Yves Le Roux, CISM, CISSP
Chair, ISACA’s Privacy Task Force
CA Technologies

[ISACA Now Blog]

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 Blog:  https://www.hkcert.org/my_url/en/blog/15092402

September 2015 PISA Journal:  http://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]

English
Exit mobile version