Keep your friends close; keep ransomware closer

“How to avoid being a ransomware victim?” is one of the main questions every single company and organization asks themselves every day. Unfortunately there is no silver bullet against that, but there are several good practices we can follow to minimize our exposure.

We can start by enumerating what are the main vectors that attackers use to get into victims: phishing, brute forcing and the use of exploits. Let's use this information to understand what exactly are attackers doing from a technical point of view, but more importantly, to monitor how their campaigns evolve. And here we want to highlight the importance of continuously tracking malicious activity in order to feed our systems accordingly: attackers evolve their methods and the IOCs used constantly change. We need the whole movie, not just a static picture.

This post describes different examples of techniques we can use to monitor ransomware campaigns, with a special focus on the infection vectors previously mentioned in order to minimize the risk of becoming a victim.

For more details, you can check our recorded anti-ransomware webinar in English and Spanish.

Ransomware in phishing attacks

Phishing is the most common technique used to distribute ransomware. We want to be able to discover how it is being used in new ransomware campaigns and to obtain the infrastructure behind the attack, gathering valuable IOCs and TTPs to feed our defenses.

We can start looking for emails involved in phishing campaigns uploaded this year to VirusTotal:

engines:ransom type:email fs:2020-01-01+

We get a list of generic ransomware email files. We can specify a certain malware family we are interested in. For instance, the following query returns emails related to some of the most common campaigns:

(engines:bitpaymer OR engines:maze OR engines:Ryuk OR engines:gandcrab OR engines:clop OR engines:revil OR engines:sodibiniki OR engines:matrix) type:email

Trickbot is a malware family frequently used to distribute ransomware. By searching for recent samples delivered by email (engines:trickbot fs:2020-09-01+ type:email) we can quickly find an interesting sample implementing an exploit and pretending to be a well known financial institution. We can quickly expand all the domains, URLs and IP addresses embedded into this file into our investigation graph, getting a broader overview of the campaign:


Expanding different nodes uncovers new IOCs to feed our defenses and unfolds this campaign, showing domain names that were used to bait victims into opening the malicious word document attached to the phishing email. 

This kind of phishing attacks where legitimate logos, domains and brand images are used to bait victims into executing malware can hurt a company's reputation, not to speak of being used against the company itself. The sooner we detect a campaign the faster we can perform actions to shut it down. VirusTotal’s Livehunt checks any submitted file against a search criteria written in Yara.

For example, to check for embedded domains in emails detected as phishing, we could use:

import "vt"
rule brandmon_google {
    strings:
        $domain1 = "accounts.google.com"
        $domain2 = "mail.google.com"
        $domain6 = "drive.google.com"
    condition:
        for any engine, signature in vt.metadata.signatures : (
            signature contains "phishing" and vt.metadata.file_type == vt.FileType.EMAIL and (any of them)
        )
}

Exploits used in ransomware attacks

Exploits are commonly used for installing malware or for escalating privileges into your system.

According to this report, the four CVEs that are most frequently used for performing ransomware attacks this year are:

• CVE-2019-19781 → Revil/Sodinokibi, Ragnarok, DopplePaymer, Maze, CLOP y Nephilim.
• CVE-2019-11510 → Revil/Sodinokibi y Black Kingdom
• CVE-2012-0158 → EDA2 y RASOM
• CVE-2018-8453 → Revil/Sodinokibi

We can add to the list a couple of recent remarkable exploits: zerologon (CVE-2020-1472) and SMBGhost (CVE-2020-0796). We observed several ransomware lookups in VirusTotal tagged with this last vulnerability during the last months:




We could use the following query to get more detailed information about what CVEs were used in ransomware attacks during 2020:

engines:ransom tag:exploit fs:2020-01-01+ tag:CVE-2020*

We can once again filter by malware families. For instance, the previous query is mostly GandCrab malware, which can be easily checked using the query: (engines:ransom and not engines:gandcrab) tag:exploit fs:2020-01-01+ tag:CVE-2020*).

Now, we are ready to create a Livehunt rule to find new files tagged with one of the exploits frequently used by ransomware. 

import "vt"
rule ransomware_exploits {
    condition:
        for any tag in vt.metadata.tags : (
            tag == "cve-2019-19781" or
            tag == "cve-2019-11510" or
            tag == "cve-2012-0158" or
            tag == "cve-2018-8453" or
            tag == "cve-2020-1472" or
            tag == "cve-2020-0796"
        ) and not vt.metadata.file_type == vt.FileType.CAP
}

This will result in an immediate notification, allowing us tracking any new IOCs we can use to protect our system.

More importantly, this is very valuable information we can use on a regular basis to manage our patching policy, prioritizing patches based on fresh data of how different exploits are being used in real attacks.

Tracking fresh campaigns

Now, we want to make sure that we monitor any new ransomware campaign in order to understand how it evolves and what new artefacts and techniques they use.

As an example, we can start with a recent DFIR Report investigation revealing Ryuk exploiting zerologon. There are many ways to track campaigns, however VT Graph is a great choice to get together all the discovered observables and extend our knowledge in a visual way. Here are some tips that could help you during this process:

• Start by adding all the known observables to a new VT Graph.
• Expand domains, URLs and IPs to unfold relations and obtain new observables.
• In order to keep our list of observables up to date, we can translate common Yara rules into Livehunt rules to catch new files, injecting Livehunts results directly into the graph.
• Additionally, we can use Retrohunt rules to look for similar samples in our collection.

We start the investigation dropping one of the files included in the publication in a new graph, showing domains, urls and ip addresses embedded in the file, ITW URLs hosting the file and network observables contacted by this sample when executed. This file is detected as “bazar” malware, used to install Ryuk. We dropped all this information in our graph:



Additionally to keep pivoting using our graph and indicators, we can also translate the Yara rules from the DFIR report into Livehunt rules.




We can integrate Livehunt results into our graph in just two clicks. Just click on the target icon at the right in the VTGrap interface, select the rule desired and choose "Load results". This will add all the new observables that match our rules to the current graph. We can expand these new nodes to unveil new observables and create relationships.



All these new IOCs are fresh observables that are clearly related to this campaign. All this continuous flow of fresh indicators will help us improve our security mechanisms to stop Ryuk from passing through our defenses.

Summarizing, the knowledge of what attackers are using is the first necessary step for us to minimize our exposure to different campaigns. It wouldn't be right to put all the different ransomware attacks under the same umbrella, as they became highly specialized and protecting from different actors is not exactly the same. The techniques described in this post are a good starting point for automatically minimizing our exposure to more spread ransomware campaigns, however they can be applied both for generic and targeted attacks.

Stay safe and happy hunting!

This post was co-authored by Vicente Diaz.

Read More

Tracing fresh Ryuk campaigns itw

Ryuk is one of the most dangerous Ransomware families. It is (allegedly) run by a specialized cybercrime actor that during the last 2 years mainly focused on targeting enterprise environments. The amount of bitcoins demanded in their ransom attacks varies depending on the target. Some of the wallets used by the group to collect the ransom payments reached millions of dollars in a few weeks.

Protecting against such attacks is one of the main priorities for any CISO or security team. This is a problem that should be approached from different perspectives, being prevention (likely) the most relevant one.

Now, what can be done in terms of prevention? Information is power, the first thing we need is understanding how the new campaigns are operating. Is this distributed through phishing or exploiting any vulnerabilities? Do they use brute force attacks? Maybe all together?

In addition to the TTPs described above, we want as many technical details as possible. This will result in very valuable Indicators of Compromise we can use for protecting our infrastructure: deploying networking indicators to disrupt malware communication, making sure our Yara rules will detect all the components of the attack, launching regular scans in our infrastructure to detect any artefact used in the campaign.

We need to quickly deploy our fishing nets to catch everything related to fresh new campaigns! And then to keep monitoring for a while to make sure we keep our systems updated as attackers evolve.

In this blogpost we will describe how we used VirusTotal to detect and monitor new Ryuk activity. However this is a very specific case where we want to show how our IDA plugin can save us a lot of time when dealing with certain samples.

If you want to learn more about how you can keep your organization safe from ransomware and how to easily leverage VirusTotal to monitor ransomware activity, please join us for our next Anti-ransomware workshop - English (Live November 4th, 1pm ET) and Spanish (Live October 28th, 17:00 CEST) versions available.

Starting the investigation

Two weeks ago new files were uploaded to VirusTotal (1, 2). According to the crowdsourced YARA rule that identified them, these files looked like Ryuk malware.




A closer look revealed that these samples have been probably dumped from memory: the disassembled code showed plenty of memory mapped addresses, the import table was missing and the samples crashed when executed - they were definitively corrupted PE files.

Given these were fresh samples, we certainly wanted to know more about them, especially if they were part of a bigger campaign. In such cases, one of our best allies is looking for similar samples that could also be part of the attack. However, when working with memory dumps we need to be careful, given that probably some segments and memory mapped addresses will be execution specific. If we include any of such specifics in our search, we won't be able to find other samples.

IDA plugin to the rescue

One of the options would be to rebuild the samples we found, which is an extremely time consuming process. Instead, we can use the VirusTotal IDA plugin (see original blog post announcement) to help us search for the original sample. Using the "search for similar code" functionality we can create a query that will ignore all the memory mapped addresses, being a perfect choice for our problem.

Taking a look at the samples with IDA, we can see there are many functions that aren't properly identified by the disassembler engine given the use of anti-disassembly techniques. Precisely for this reason, they are good choices for searching for code similarity.



We just need to select the code, right-button, and search for similar code. The resulting query will take care of ignoring all the memory mapped addresses we wanted to get rid of.



The resulting listing with all the files found shows very close first submission time. Also, some of them report behaviour activity, meaning they executed in the sandboxes without crashing: maybe one of them could be our original sample.

Picking one of our initial samples and another one with behavioural information, we can see that:

• They don't show up as similar when doing a similarity search (as expected).
• They have some long sequences of bytes in common.

Is this our sample?

At this point we feel confident that the new sample found is the one we were looking for. Indeed, starting from this sample and taking a look at the (undetected) function located at 0x35008A60, we select a large sequence of instructions with the IDA plugin (as we did before) for a new search. This results in only 4 files that match the query generated: our two initial samples, another file that's also corrupted, and the previously chosen sample that detonated in our sandboxes. Therefore, this is the second time that we get this file when looking for similar code.

Going deeper, we'll see that it shares the same PE entry point that our two initial corrupted files. Furthermore, their WinMain functions are the same. Initially it looks like a quite simple function, composed of only three blocks of code. But, after overcoming the anti-disassembly trick implemented to confuse IDA, we can compare both function graphs to see the similarity. We conclude that we found the original sample.

What now?

At the time of this research there isn't any Yara rule detecting the original sample and it has 28/71 positives. Inside this file we can find encrypted strings that are extremely useful for pivoting to find additional samples. These strings are included in the corrupted files as well, stored in the ".gfids" segment at the end of the file. In other words, they aren't located in the ".data" segment as seen in the original sample. This new location reveals that probably these strings were initially encrypted and became decrypted after execution, thus they can be seen as footprints of the original sample.



Using the VT-IDA plugin we can search for other files that contain these encrypted strings. As expected, the four files found before are listed now, but there are two other samples that were submitted three days prior to our original sample and can also be investigated.

Moreover, all these new strings can be used to improve the original Yara rule that brought us here, or to create a new one! Remember to keep it running as a LiveHunt to make sure you keep track of any new Indicators of Compromise and to detect anything new attackers use in their campaigns. You can find all the details about the campaign described in this blogpost in the following VT-Graph.

This post was co-authored by Vicente Diaz.

Read More