Year: 2016

Our team recently discovered a new Android Trojan called SpyNote which facilitates remote spying. The builder, which creates new versions of the malware, recently leaked on several malware discussion forums. SpyNote is similar to OmniRat and DroidJack, which are RATs (remote administration tools) that allow malware owners to gain remote administrative control of an Android device.

Like these other RATs, SpyNote has a large feature set including the following:

• No root access required
• Install new APKs and update the malware
• Copy files from device to computer
• View all messages on the device
• Listen to calls made on the device
• List all the contacts on the device
• Listen live or record audio from the device’s microphone
• Gain control of the camera on the device
• Get IMEI number, Wi-Fi MAC address, and cellphone carrier details
• Get the device’s last GPS location
• Make calls on the device

Figure 1: SpyNote Control Panel

The SpyNote APK requires victims to accept and give SpyNote many permissions, including the ability to edit text messages, read call logs and contacts, or modify or delete the contents of the SD card. We have found that a sample of SpyNote was uploaded to the VirusTotal and Koodousmalware analysis websites.

Analysis

Upon installation, SpyNote will remove the application’s icon from the victim’s device. Also apparent is that the SpyNote builder application is developed in .NET

The application is neither obfuscated nor protected with any Obfuscator or Protector.

Figure 2: Decompiled SpyNote Builder

The uploader might be following the instructions described in YouTube videos on using SpyNote, considering the port number used is exactly the same as in the videos (https://www.youtube.com/watch?v=E9OxlTBtdkA) and the uploader only changes the icon of the APK file.

Furthermore, this RAT has been configured to communicate to the command and control (C&C) IP address (141.255.147.193) over TCP port 2222 as shown in the image below.

Figure 3 – Dalvik bytecode view using Cerbero profiler

Figure 4 – SpyNote opening a socket connection

Based on the information we have already found, we now know that the malware is using the hard-coded SERVER_IP and SERVER_PORT values (Figure 4) for this socket connection. We can now create an extractor for the C2 information using Androguard (https://github.com/androguard/androguard) as shown below. The spynote.C2.py script (shown below) parses these values from the APK file and prints them to the command line (Figure 5).

Figure 5 – Extracted C2 information

Conclusion

Installing apps from third-party sources can be very risky — those sources often lack the governance provided by official sources such as the Google Play Store, which, even with detailed procedures and algorithms to weed out malicious applications, is not impregnable. Side-loading apps from questionable sources exposes users and their mobile devices to a variety of malware and possible data loss.

Thus far we have not observed SpyNote used in active attacks but we suspect cyber criminals will begin using it as the building of SpyNote is freely available. Palo Alto Networks AutoFocus users can identify this RAT using the SpyNote tag.

Indicators

SHA256 of SpyNote Samples

85c00d1ab1905ab3140d711504da41e67f168dec837aafd0b6327048dd33215e
ed894f9c6f81e2470d76156b36c69f50ef40e27fd4e86d951613328cdbf52165
4fb2d8be58525d45684f9ffd429e2f6fe242bf5dbc2ed33625e3616d8773ed0d
98e2b14896e85362c31b1e05f73a3afddde09bd31123ca10ff1cc31590ac0c07
51e0d505fb3fba34daf4467ca496bca44e3611126d5e2709441756ba632487f0
4b60fff88949181e2d511759183cdf91578ece4a39cd4d8ec5da4015bb40cbed
c064679c42e31a4f340e6a1e9a3b6f653e2337aa9581f385722011114d00aa1e
3323ff4bcdb3de715251502dfb702547b6e89f7973104b3da648163b73b72eef
f0646b94f1820f36de74e7134d0bb9719a87afa9f30f3a68a776d94505212cbd
2ec734fd0f7320b32568ab9c229146a3dab08f951ca5c3114f6af6c77f621929
4e80d61994ee64dadc35af6e420230575553aba7f650bc38e04f3702b21d67c4
357ca2f1f3ea144bdd1d2122ec90ed187e8d63eb8a206794e249d5feb7411662
ac482e08ef32e6cb7e75c3d16a8ea31bcc9bf9400bd9f96b4ec6ed7d89053396
89a5ebf0317d9a3df545cfd3fbcb4c845ea3528091322fd6b2f7d84d7a7d8ae0

Jacob Soo

[Palo Alto Networks Research Center]

Until recently, the healthcare industry has been up in arms on whether ransomware infections should be considered reportable Health Insurance Portability and Accountability Act (HIPAA) breaches. The argument for considering ransomware a HIPAA breach was centered on the fact that covered entities lose control of protected health information (PHI). A counterargument is that ransomware is not known to exfiltrate data outside the network, and hence should not be considered a HIPAA breach.

The U.S. Health and Human Services (HHS) Office for Civil Rights finally weighed in on the discussion with new HIPAA guidance released on July 11, 2016. It covers how activities required by HIPAA can help mitigate ransomware incidents, but more importantly, it directly answers questions related to whether ransomware infections are considered reportable HIPAA breaches.

As a former sec ops lead for a large hospital network, I’ll highlight what I think are the most important excerpts of the HHS guidance and help you interpret some of the language to make it more actionable in a hospital environment.

Excerpt 1:

Is it a HIPAA breach if ransomware infects a covered entity’s or business associate’s computer system?

Whether or not the presence of ransomware would be a breach under the HIPAA Rules is a fact-specific determination. A breach under the HIPAA Rules is defined as, “…the acquisition, access, use, or disclosure of PHI in a manner not permitted under the [HIPAA Privacy Rule] which compromises the security or privacy of the PHI.” See 45 C.F.R. 164.402.6

When electronic protected health information (ePHI) is encrypted as the result of a ransomware attack, a breach has occurred because the ePHI encrypted by the ransomware was acquired (i.e., unauthorized individuals have taken possession or control of the information), and thus is a “disclosure” not permitted under the HIPAA Privacy Rule.

Unless the covered entity or business associate can demonstrate that there is a “…low probability that the PHI has been compromised,” based on the factors set forth in the Breach Notification Rule, a breach of PHI is presumed to have occurred. The entity must then comply with the applicable breach notification provisions, including notification to affected individuals without unreasonable delay, to the Secretary of HHS, and to the media (for breaches affecting over 500 individuals) in accordance with HIPAA breach notification requirements. See 45 C.F.R. 164.400-414.

In short, the guidance is “Yes, a successful ransomware infection is considered a reportable HIPAA breach unless the covered entity can demonstrate that there is a ‘…low probability that the PHI has been compromised.’”

That makes sense, but how do you demonstrate there is a low probability that PHI has been compromised? HHS answers this question directly as well. Hospital IT Security and Compliance teams will want to pay close attention to the following section:

Excerpt 2:

How can covered entities or business associates demonstrate “…that there is a low probability that the PHI has been compromised” such that breach notification would not be required?

To demonstrate that there is a low probability that the protected health information (PHI) has been compromised because of a breach, a risk assessment considering at least the following four factors (see 45 C.F.R. 164.402(2)) must be conducted:

1. the nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification;

2. the unauthorized person who used the PHI or to whom the disclosure was made;

3. whether the PHI was actually acquired or viewed; and

4. the extent to which the risk to the PHI has been mitigated.

A thorough and accurate evaluation of the evidence acquired and analyzed as a result of security incident response activities could help entities with the risk assessment process above by revealing, for example: the exact type and variant of malware discovered; the algorithmic steps undertaken by the malware; communications, including exfiltration attempts between the malware and attackers’ command and control servers; and whether or not the malware propagated to other systems, potentially affecting additional sources of electronic PHI (ePHI). Correctly identifying the malware involved can assist an entity to determine what algorithmic steps the malware is programmed to perform. Understanding what a particular strain of malware is programmed to do can help determine how or if a particular malware variant may laterally propagate throughout an entity’s enterprise, what types of data the malware is searching for, whether or not the malware may attempt to exfiltrate data, or whether or not the malware deposits hidden malicious software or exploits vulnerabilities to provide future unauthorized access, among other factors. […]

Frequently, ransomware, after encrypting the data it was seeking, deletes the original data and leaves only the data in encrypted form. An entity may be able to show mitigation of the impact of a ransomware attack affecting the integrity of PHI through the implementation of robust contingency plans including disaster recovery and data backup plans. […]

The risk assessment to determine whether there is a low probability of compromise of the PHI must be thorough, completed in good faith and reach conclusions that are reasonable given the circumstances. […]

The above few paragraphs of commentary are perhaps the most important guidance from HHS because they outline what HHS defines as reasonable evidence and documentation for a covered entity to determine that a ransomware incident is not considered a reportable HIPAA breach.

Here are some conclusions based on my interpretation of the above HHS statements:

A ransomware incident may not be reportable if a reasonable number of the following three statements are true (I’ll leave it up to you to determine how many of these statements need to be true in order to consider a ransomware incident non-reportable.):

1. The PHI involved was sufficiently encrypted or de-identified.
2. The ransomware variant is identified and determined to not exfiltrate data.
3. The PHI data has been successfully restored from backups.

You’ll notice I ignored the HHS factor related to who the unauthorized person is as I would consider all malware operators to be equally malicious.

The PHI involved was sufficiently encrypted or de-identified: It is clearly a best practice to de-identify PHI data that is exported from your electronic health record (EHR) application, even if it is intended to remain on the internal hospital networks. Doing so can contribute to the likelihood of concluding that a ransomware incident is not reportable.

The ransomware variant is identified and determined to not exfiltrate data: As I described following the second quoted statement, it is critical to understand the specific ransomware variant that infected the hospital network. If you know the ransomware variant, you can research it and confidently conclude that the ransomware did not exfiltrate data. At the time of this blog post, our Unit 42 threat intelligence team is not aware of a ransomware variant designed to exfiltrate data. Malware operators use a different family of malware for data exfiltration.

As strange as it sounds, ransomware operators tend to be trustworthy; they know that, in order for their business model to continue to work (i.e., for them to be paid), they need to provide the key to decrypt the files once they have been paid. Malware operators who exfiltrate data from a hospital network follow a different business model – one based on the sale of health data in underground networks.

Identifying the particular ransomware variant that infected a hospital can be difficult without the right technology because there are many ransomware variants. Our WildFire malware analysis service has evaluated over a million unique ransomware samples, which gives you an idea of the wide variety of ransomware in the wild.

Security architectures that are capable of identifying ransomware variants in hospitals are usually founded on a next-generation firewall designed to prevent malware at the network level, combined with advanced endpoint protection to stop malware at the endpoint.

The PHI data has been successfully restored from backups: As I mentioned in my previous blog posting outlining Tips to Prevent Ransomware in Healthcare Environments, it’s important to review and validate server backup processes in order to restore accessibility to ransomed PHI. Some organizations don’t realize their backups are compromised or were configured improperly until a critical restoration process fails.

Conclusion

HHS’s guidance has made it clear that healthcare organizations should be prepared for ransomware incidents. Hospitals that employ encryption or de-identification of their data at rest, build security architectures based on next-generation firewalls, deploy advanced endpoint protection, and test their backups periodically are better positioned to protect patient data, and hence are much less likely to be required to disclose a breach due to ransomware.

Additional Reading on Ransomware:

• Top Recommendations to Prevent Ransomware: an advisory report for security teams
• The Rise of Ransomware, a recent paper from our threat intelligence team, Unit 42 on the history of ransomware

Disclaimer – Do not consider any of the above statements as legal advice. You will need to review HHS’s guidance with your own compliance and legal teams.

Matt Mellen

[Palo Alto Networks Research Center]

n our May 2016 blog post, we described Japan’s new Cybersecurity Guidelines for Business Leadership Version 1.0, issued by the Japanese Ministry of Economy, Trade, and Industry (METI) and its Information-Technology Promotion Agency (IPA), and the positive progress seen in Japanese industry since the Guidelines’ release in December 2015. This follow-up blog post analyzes one of METI’s specific recommendations: that companies undertake more cyberthreat information sharing. We provide our thoughts on what more can be done to improve and enhance the cybersecurity of Japanese industry to benefit both Japan and the world.

METI puts information sharing as the Cybersecurity Guidelines’ Action Item 8, which states that leadership should “actively participate in and contribute to cyberthreat information-sharing activities” to the extent possible to minimize incidents or damage to companies’ networks. This is an essential recommendation. To dramatically shift the balance of power, close the competitive gap between the attacker and victim, and realize exponential leverage against cyber adversaries to restore trust in the digital age, we must operationalize cyberthreat information sharing. What is the current status in Japan, what are the obstacles to greater cyberthreat information sharing by companies, and how might things be improved?

Despite varied levels of success, all countries are struggling to establish effective cyberthreat information sharing frameworks in which members can exchange information about threats and incidents—such as botnet command and control servers, malware samples, malware analysis results, and indicators of compromise—in a timely manner. There are myriad reasons that might slow adoption of this practice: technical (many systems cannot adequately share at volume, and there are still a number of different sharing standards), regulatory and legal concerns, and trust issues.

Although all countries need to improve cyberthreat information sharing, Japan seems to lag behind its global peers in adopting the practice. PricewaterhouseCoopers (PwC) reported in its Global State of Information Security Survey 2016 that Japanese companies are less willing to share information about cybersecurity threats than other companies across the globe. While 30.4 percent of Japanese companies share such information, PwC reports that 64.7 percent of companies in the world do. (PwC interviewed more than 10,000 C-level executives and board members in charge of IT in 127 countries between May and June 2015 for this survey report.)

The top reason Japanese companies reported for not wanting to share threat information is that they do not have adequate information sharing frameworks (39%). Until cyberthreat information sharing programs are set up to leverage automation – which requires both technical work and strong privacy protections – such frameworks are dependent upon skilled people to actually do the work. At present, Japan lacks adequate human resources to participate more in information sharing. According to a 2015 METI study, Japanese companies lack IT and cybersecurity professionals who can judge which threat intelligence should be shared, when, and with whom, largely because Japanese companies tend to outsource cybersecurity-related work to system integrators. METI compared Japan to the United States, where large companies, such as banks, sometimes have a cybersecurity team and even an in-house cyberthreat intelligence team. According to METI’s statistics, 24.8 percent of IT professionals in Japan work in-house, whereas 75.2 percent work at IT services companies (e.g., system integrators and others providing cybersecurity to other companies). By comparison, in the United States, 71.5 percent of IT professionals work in-house, with 28.5 percent at IT services companies. Other top reasons cited in the PwC study for low participation of Japanese companies in information sharing are the lack of trust in competitors and in third parties’ information.

We believe cultural attitudes also may contribute to reluctance to participate in cyberthreat information sharing in Japan. As described by anthropologist Ruth Benedict in 1946, Japanese culture has a shame factor, where the desire to avoid “loss of face” is extremely powerful. Although many companies around the world may not wish to admit they have been the victim of a cyber incident, or reveal the fact that they were targeted, admitting so—even within a “trust”-based environment, as cyberthreat information sharing groups are meant to be—may be inordinately difficult for Japanese companies.

Additionally, volunteerism—in the sense of contributing to a community—is likely a factor in the success of information sharing among participants. A Japanese government-affiliated foundation has noted that the United States has had a long history of volunteer-based activities to complement public administration and social welfare, dating from as far back as the 17th century. Japan, on the other hand, started to develop American-style volunteerism only after the end of World War II, and Japanese volunteer activities have tended to focus on social welfare activities for their own residential communities. This history could make it challenging for the Japanese to contribute to a larger, much more distributed volunteer community for information sharing.

To help Japanese companies rapidly embark on more information sharing, it would be useful for other countries to discuss their information sharing best practices with Japan. In fact, some Japanese organizations already are modeled on U.S. approaches. For example, the United States has numerous industry-specific Information Sharing and Analysis Centers (ISACs) which are now being complemented by a broader category of Information Sharing and Analysis Organizations (ISAOs). In fact, Japan launched its first ISAC, the Telecom-ISAC, in 2002, followed by the Financials ISAC in 2014. This ISAC is modeled after the U.S. Financial Services ISAC, or FS-ISAC, arguably one of the most successful ISACs, and it is trying to learn lessons from this body. The Japanese Financial Services Agency’s guidelines for the financial sectorencourage financial institutions to share threat intelligence via relevant information sharing frameworks, including the Financials ISAC.

Like its counterpart in the United States, the Financials ISAC has multiple levels of membership for financial institutions and vendors to disseminate and access threat intelligence. Core and associate members—banks and insurance companies—can receive more sensitive threat intelligence, and they can participate in working groups on such issues as best practices, cyber exercises, global information sharing with the FS-ISAC, and incident response. This type of arrangement generates a comfortable environment in which to exchange sensitive information among trusted members belonging to the same industry.

Japan realizes it needs more ISACs. The Japanese Ministry of Internal Affairs and Communications (MIC) plans to expand and rename the Telecom-ISAC to the “ICT-ISAC” to include not only telecom companies and Internet Service Providers (ISPs), to which membership has traditionally been restricted, but also ICT companies—including security vendors—and system integrators. In addition, a new Electric Power-ISAC will also be established in Japan and work closely with both the U.S. Electricity ISAC and European Energy-ISAC.

These cross-border efforts are commendable. For one thing, they can help to raise the global bar by allowing Japanese companies to share intelligence uniquely seen in Japan to help multinational companies with a presence in the market better protect themselves from threats.

ISACs have traditionally developed in industry verticals (e.g., financial services, healthcare, energy) in which each participating company uses the information it receives to protect its own network and share threats to their specific sector. However, ISACs are not the only form of information sharing organizations in the U.S.

For example, the Cyber Threat Alliance (CTA), established in September 2014 is a group of cybersecurity companies who have chosen to work together in good faith to share threat information for the purpose of improving defenses against advanced cyber adversaries across member organizations and their customers. Palo Alto Networks is proud to be one of the four founding members of the CTA. The CTA reflects a departure from the traditional philosophy of cybersecurity companies, which are known for competing against each other based on the threat information each company has. The CTA enables security companies to act upon a common knowledge of shared cyberthreats. Unlike ISACs, the CTA is tailored to the unique capabilities of the security industry, and a requirement for every member to share previously unknown – or zero-day – threats. Consequently, the shared information is then used by the participating companies to protect their clients across all verticals (financial, health, energy, etc.).

Trust and cultural factors that might impact information sharing are important for any country to address. In fact, trust is a key ingredient to cyberthreat information sharing. It takes time to build mutual confidence and share cyberthreat intelligence among members of any information sharing framework. Personal relationships often make a big difference and can lead to institutionalizing those ties. Japanese companies are beginning to talk more frankly with each other about cybersecurity and share ideas and best practices, as we noted in our May blog, which we believe will lead to greater trust.

Thought leadership engagements are indispensable in helping reduce feelings of shame. Business executives in any country need to understand that all companies are being targeted by cyberattacks and that threat intelligence sharing is an essential ingredient to prevent the expansion of similar attacks. Being targeted is not a shame. It is simply another risk to business operations.

As with many of Japan’s cybersecurity activities, the actions toward greater cyberthreat information sharing reflect the fact that Japan’s government and industry aim to enhance cybersecurity to make the Tokyo Olympic Games 2020 successful, setting the stage for a positive legacy and national cybersecurity capability toward 2020 and beyond. But there also is the larger goal of building cyber resilience throughout the economy. We agree with the Japanese government that cyberthreat information sharing is a crucial part of that equation, as highlighted in METI’s Cybersecurity Guidelines.

This is the third in a series of blogs co-authored by Mihoko Matsubara and Danielle Kriz aimed at introducing Japan’s cybersecurity efforts and their significance to a global audience, including governments, global industry, and other thought leaders. Subsequent blogs are expected to cover Japan’s role in global cybersecurity capacity-building, the cybersecurity ramifications of planning for the Tokyo Olympic Games 2020, and other topics.

Mihoko Matsubara and Danielle Kriz

[Palo Alto Networks Research Center]