Category: Palo Alto Networks

In March of this year, Unit 42 investigated the SamSa actors that were attacking the healthcare industry with targeted ransomware. With this group being active for roughly one year, we decided to revisit this threat to determine what, if any, changes had been made to their toolset. In doing so, we discovered that it’s been a very profitable year for SamSa, with an estimated $450,000 in ransom payments from samples we have identified. This blog serves to discuss changes made by this group and the SamSa malware family since we last discussed them.

Updates to Malware Toolset

In the past 12 months, Unit 42 has collected and analyzed 60 unique samples that have been identified as belonging to the SamSa malware family. SamSa has a very small number of samples overall when compared to more common ransomware families such as Locky, Cerber, and CryptoMix. This is simply a byproduct of the targeted nature of SamSa, which targets specific organizations instead of a wide number of Internet users.

During the past 12 months, a number of changes were made by the authors to make analysis and reverse-engineering more difficult. While we classify all of these samples as “SamSa,” the attackers have used various names to identify their projects. The following chart shows the various internal .NET project names used by SamSa from December 2015 until November of 2016.

Figure 1 Versions of SamSa Ransomware over time

The following list of internal .NET project names were witnessed, in order:

• samsam
• MIKOPONI
• RikiRafael
• showmehowto
• wanadoesme
• wanadoesme2
• gonomore
• gotohelldr
• WinDir

The majority of the name changes took place after April of this year. When discussing changes made internally to the code base, we witnessed the following events since we last discussed SamSa:

Figure 2 SamSa modifications over time

1. A number of internal .NET name changes, starting with RikiRafael.
2. A number of changes to the encrypted filename extensions used after encryption took place.
3. Changes to the format of the encrypted file header.
4. Modifications to the dropped helper HTML file that informs the victim of what has occurred.
5. Different temporary folder names used to hold SamSa while it is running.
6. Encryption of embedded strings using the AES-128 algorithm.
7. Internal PDB debug strings obfuscated.
8. Internal PDB debug strings removed altogether.

Profits

When we originally discussed SamSa, there were confirmed profits of $70,000 for the threat actors, with estimates by other researchers as high as $115,000. Unlike most ransomware, SamSa ransomware executables often contain the Bitcoin Wallet address victims are supposed to use to pay the ransom. Since March 24^th 2016, we’ve witnessed 24 unique SamSa samples containing 19 unique Bitcoin (BTC) addresses. This allows us to monitor the blockchain for transfers to those wallets and identify ransom payments.  In one unusual case, we saw a version of SamSa where the BTC address was input as a second argument, preventing us from seeing what payment, if any, was received by the actors. This not only makes tracking monetary payments extremely difficult, but also is yet another example of how the SamSa actors take a very targeted approach to their victims, generating unique data for each victim they infect.

Of those 19 unique BTC addresses we observed since March 24th, 14 of these have received payments totaling roughly 394 BTC. Prior to March 24, 2016, we observed roughly 213 BTC received, giving us a total of 607 BTC received by the SamSa actors. Using today’s current BTC rate of $744.43, this allows us to estimate that the attackers have obtained roughly $450,000 since their operations began. It’s important to also note that there are likely a number of samples that exist, which we were unable to obtain, causing the actual figure to likely be much higher. A visual of the money obtained by the SamSa actors can be seen in the following figure:

Figure 3 SamSa BTC profits over time

As we can see, there is a large gap in between June and September of 2016. This is most likely due to the sample set used during research, as there were only a few samples obtained in recent months.

Conclusion

In the past year, the SamSa actors have showed no sign in stopping their attacks. They’ve successfully compromised a number of organizations, and continue to reap significant rewards for their efforts. In the past year alone, they’ve collected an estimated $450,000 from their scam. As the group continues to make money, it is unlikely we shall see them stop in the near future. Palo Alto Networks customers are protected from this threat via the following ways:

1. All malware is classified as malicious in WildFire.
2. Domains used by SamSa have been flagged as malicious in Threat Prevention.
3. AutoFocus users can track this family using the SamSa tag.

A full list of indicators of compromise (IOCs) related to SamSa can be found here.

Josh Grunzweig

[Palo Alto Networks Research Center]

Organizations must concentrate on a prevention-focused security architecture for cloud deployment — designed to stop threats across all potential attack vectors.

The key questions to consider when adopting cloud services include:

1. Who’s really responsible for our data?
You. In public cloud environments, as the data owner, you’re responsible for your data — not the cloud service provider (CSP). And although the CSP will secure the underlying infrastructure, the safety of your applications and data is your responsibility. So you need a consistent security posture.

2. Who has access to our applications and data?
A role-based access policy can help mitigate the risk of data loss. Although the CSP will have authorisation messages in place, it’s important you decide who should have access and whether additional assurance is required.

3. What happens if there’s a security breach?
What kind of support will the CSP give if there’s a breach? It’s important to know this before launching a cloud strategy.

Understanding the risks, and the challenges is a vital first-step as your organization moves to make the most of the cloud. Get your copy of our new whitepaper with BT Security, “Securely Enabling Cloud Adoption” and start your next conversation.

Will Howerton

[Palo Alto Networks Research Center]

This post originally appeared on Context: By New America

Where were all the Japanese women?

I was asking myself that question while participating in the Grace Hopper Celebration of Women in Computing conference last month, one of the largest global conferences for women in IT.

At the conference, I spoke with dozens of female college students majoring in computer science and cybersecurity in the United States. About half of the women I spoke with were American students, while the other half were students from India and China who were studying in the U.S. and ultimately hoped to stay and work in cybersecurity after graduation. But during my time at the conference I found myself asking, where were the women from my home country, Japan?

At the 2016 Grace Hopper Conference.

Seven years ago, I moved from Japan to the U.S. to pursue my graduate degree in international relations and economics at Johns Hopkins University and later conducted research on Japan–U.S. cybersecurity cooperation as a Fulbright scholar. I’ve also worked at the Japanese Ministry of Defense, a U.S. think tank that specializes in international security, and at Japanese and American tech companies. During this time, I’ve met few Japanese women working in the cybersecurity and tech industries overseas.

I began to investigate why and found a few factors that may explain why more Japanese women aren’t pursuing cyber jobs. It’s important now, more than ever, for women to enter this field.

First, some demographic context: The number of Japanese students matriculating in overseas universities and graduate programs has continued to decrease since 2004. This could be partly attributed to the decline in the number of children born in Japan since the 1980s. On the other hand, some observers, such as Aoyama Gakuin University Professor Kazuo Ogoura, have questioned whether the Japanese have become more introverted as Japan’s economic prosperity and affluence has grown, and thus are less inspired to seek new frontiers overseas.

This demographic reality is compounded by gendered one: a smaller percentage of Japanese girls report that they want to pursue professional careers in engineering and computing than the global average, according to an OECD survey report in 2012. While the global average is approximately five percent, the figure is about three percent in Japan and the U.S. On the other hand, the global average of boys who want to pursue careers in engineering and computing is 18 percent. Broken out, that figure is 15 percent in Japan and 17 percent in the U.S.

One survey report by the Japanese Ministry of Education in March 2015found that 9.1 percent of Japanese male college students work in the Information and Communications Technology (ICT) field, compared with just 6 percent of Japanese female students. The ratio of female students (44.9 percent) to male students (40.0 percent) who pursue a bachelor’s degree is noticeably higher in Japan. It indicates that fewer female students in Japan are choosing to pursue a career in tech.

Perhaps this is why I rarely see Japanese men or women (particularly the latter) at international cybersecurity conferences outside of Japan, particularly in the U.S., U.K. and France. There are also practical and cultural reasons for this: It is often challenging for non-native English speakers to draft proposals and deliver complex technical or international security conference presentations in their non-native tongue. Additionally, Japanese culture traditionally discourages people to speak up in a meeting to challenge a different opinion or idea because it disrupts group harmony, a priority in Japanese culture. Based on my own experience, the pressure of this tradition is even greater for women.

This lack of visibility is problematic because Japan is losing out on opportunities to provide and learn from different perspectives in global cybersecurity discussions. And it needs to be part of this global dialogue more than ever. That’s because Japan is hosting the Tokyo Summer Olympic Games in 2020, which prompted the government to publish the Japanese Cybersecurity Strategy in 2015, a vision about how to secure Japan and prepare for Tokyo 2020 for the next three years. One of its key arguments is that top-notch cybersecurity professionals need to be global and should play an active role beyond national borders since cybersecurity is a global challenge. As of 2014, Japan had approximately 265,000 information security professionals (160,000 of this group reportedly need more training) and a shortfall of roughly 80,000 professionals.

Like the rest of the world, Japan’s cybersecurity workforce shortfall is one that could hurt the country’s security in the long term. The Japanese government is well aware of the risk and finding ways to address the challenge.

That’s one reason why Japan’s efforts to cultivate a larger and global cybersecurity workforce will soon need to include diversity discussions like those happening in the U.S., determining how to recruit and retain groups that have been underrepresented in the cybersecurity workforce — like women. This is a place where Japan could be a global leader, if the private and public sectors make some of the necessary changes together, learning from the best practices of other nations and creating some of their own.

Still, it will be tough to remove some of the obstacles that are holding back women (and men) from the global cybersecurity workforce, and it won’t happen overnight. Japanese cybersecurity professionals will still face a language barrier and encounter cultural differences when joining international cybersecurity discussions and conferences. But joining in these discussions will ultimately help Japan, and the world, become more secure.

It can be scary to some women — particularly Japanese women — to be the minority in a conference room. It might require courage to speak up at a meeting. But as cybersecurity challenges grow increasingly complex and global, these perspectives representing different cultures and backgrounds will become even more important and valuable to the discussion. Think of yourself as an ambassador, paving the way and bridging the gap for other people from your community, country or culture. And you’re not alone; I will do my part and look forward to seeing you at future conferences, or hopefully, as a colleague.

Mihoko Matsubara

[Palo Alto Networks Research Center]

Most traditional security products are built to act based on known threats. The moment they see something that is known to be malicious, they block it. To get past security products that successfully block known threats, attackers are forced to create something that is previously unknown. How do they do it, and what can we do to prevent both known and unknown threats?

Let’s look at a few scenarios:

Recycle the Threat

Recycled threats are considered to be the most cost-effective attack method, which is why attackers often recycle existing threats using previously proven techniques. What makes these recycled threats somewhat “unknown” lies within the limited memory of security products. All security products have limited memory, and security teams choose the most up-to-date threats to protect against, hoping they can block the majority of incoming attacks. If an old threat not tracked by the security product attempts to enter the network, it could bypass the security product because it is not categorized as something seen before.

To protect against these “unknown” recycled threats, it is critical to have access to a threat intelligence memory keeper, these days often placed in an elastic cloud infrastructure capable of scaling to address the volume of threat data. In the event that a security product doesn’t have a particular threat identified and stored, access to the larger knowledge base of threat intelligence could help determine if something is malicious and enable the security product to block it.

Modify Existing Code

This method is somewhat more expensive than recycling threats. Attackers take an existing threat and make slight modifications to the code, either manually or automatically, as the threat actively transitions in the network. This results in polymorphic malware or a polymorphic URL. Like a virus, the malware continuously and automatically morphs and changes rapidly. If a security product identifies the original threat as known and creates a protection for it based on one variation only, any slight change to the code will turn that threat into an unknown. Some security products match threats using hash (#) technology, which generates a number based on a string of text in such a way that it is extremely unlikely that some other text will produce the same hash value. In our context, the hash value only matches one variation of the threat, so any new variation of the threat will be considered new and unknown.

To better protect against this threats security products needs to use smart signatures. Smart signatures are based on the content and patterns of traffic and files, rather than on a hash, and can identify and protect against modifications and variations of a known threat. The focus on the behavior, rather than the appearance of fixed encoding, allows for the detection of patterns in modified malware.

Create a New Threat

Attackers who are more determined and willing to invest the money will create an entirely new threat with purely new code. All aspects of the cyber attack lifecycle have to be new for an attack to truly be considered a previously unknown threat.

Focus on Business Behavior

Protecting against these new threats requires focus on your unique business behavior and data flows. This information can then be implemented into cybersecurity best practices. As an example, leveraging zoning with user ID and application ID, can help prevent new threats from spreading around your organization and block downloads from new, unknown and unclassified websites.

Utilize Collective Intelligence

No single organization will ever initially experience all new threats globally, which is why it is so important to be able to benefit from collective threat intelligence. Targeted attacks with unknown, never-before-seen threats can quickly become known with global information sharing. When a new threat is analyzed and detected in one organization, the newly identified threat information can be distributed across the community, with mitigations deployed a head of time to limit the spread of attacks and their effectiveness globally.

Turning unknown threats into known and actively prevent against them can happen in a combined environment. First, you need to predict the next attack step and location. Second, you need to be able to develop and deliver protection quickly to the enforcement point in order to stop it.

Automate Protections

When a truly new threat enters your organization, the first line of defense is having cybersecurity best practices that are specific to the organization. At the same time, you should be sending unknown files and links for analysis. The effectiveness of sandbox analysis is depended on the time it takes to provide an accurate verdict on an unknown threat and the time necessary to create and implement protections across the organization. Your security posture needs to be changed fast enough to block the threat before it has the ability to progress – in other words, as soon as possible. And to ensure that this threat does not further traverse the network, preventions need to be created and implemented automatically across all security products faster than the threat can productively spread.

A recent SANS survey reported that 40 percent of attacks have previously unknown elements. The ability to detect unknown threats and prevent successful attacks defines the effectiveness of your security deployment. A true next-generation security platform is agile, quickly turning unknown threats into known protection and prevention on a global level. Automatically sharing new threat data while extending new protections throughout the organization to stop the spread of an attack. Learn more about the Palo Alto Networks Next-Generation Security Platform.

Karin Shopen

[Palo Alto Networks Research Center]