Advanced Endpoint Protection Versus Sandboxing

There are a couple of different ways that advanced protection solutions can detect unknown malware. The first is through behavioral detection, which is what end-point solutions like those from Carbon Black, CrowdStrike, FireEye, and SentinelOne do. As mentioned previously, there are certain things that ransomware has to do in order to install itself and encrypt the hard drive. Those tasks include:

1. Install itself onto the system using either exploitation or through someone clicking on a file.
2. Inject into a process that has administrator access to the system.
3. Maintain persistence between reboots.
4. Enumerate the files on the file system and possibly on shared drives.
5. Access the native encryption libraries on the victim machine.
6. Read and write whole or chunks of files in rapid succession.
7. Call out to the command-and-control infrastructure.
8. Most, but not all, ransomware also works by deleting Volume Shadow Copies.

There are only so many ways to perform these tasks, so advanced end-point protection systems monitor for these types of behaviors on the desktop and in memory. When the end-point agent sees activity that looks suspicious, it either blocks the activity from occurring or reports it. These solutions are highly effective and provide protection beyond that offered by traditional, signature-based, antivirus solutions.

The alternative method for detecting new attacks is to use sandboxing technologies. These solutions from companies like Cisco, FireEye, and Palo Alto and hybrid solutions from companies like Cylance are effective because they execute new unknown applications in a virtual environment. They allow both “good” and “bad” unknown files to fully execute in a virtual environment to see what happens and then report on it. The advantage of this method is that it can detect new types of ransomware (as well as other types of malware) and attack methods that have not been used before, and do it in a way that does not impact the intended victim.

Just as security researchers are always finding new ways to detect ransomware, the teams behind ransomware are always looking for new ways to exploit and install ransomware. CryptXXX is no different. There have been at least three different versions of CryptXXX, each one improving some aspect of the code. Sandboxing is one way to discover new methods that even advanced end-point solutions may miss.

But there are downsides to sandboxing, and that is where the sandbox avoidance techniques that the team behind CryptXXX implemented come into play. The first problem is that sandboxing solutions rely on virtual environments, and most security vendors use VMWare or another well-known vendor for their virtual solution. There is nothing wrong with these solutions, but it is also trivial for an attacker to determine if they are running in a well-known virtual environment.

One way ransomware can detect if it is running in a virtual environment is simply by checking the output of the systeminfo command. If the system manufacturer is listed as “VMWare,” then the attacker knows it is a virtual environment and the ransomware should not run. That is a simple example and one that is easy to fix, but there are more advanced techniques that attackers can use to check the victim environment and prevent execution.

The second thing the team behind CryptXXX did to avoid detection by sandbox technologies is to put a delay in the ransomware. Some researchers report that CryptXXX will often wait as long as an hour before it executes. Because most sandbox vendors need to execute incoming files rapidly, they do not have the ability to wait an extended period for a file to execute. The assumption is that once a system is exploited the ransomware will execute immediately, so the virtual machines are shut down quickly. To avoid detection, ransomware developers will put the delay in, and the sandbox will not be able to record the malicious behavior; it may even think the file is benign. A second trick some ransomware developers implement is to wait until after a system reboots to launch the encryption process, again, foiling many sandboxing vendors.

The other advantage of delaying the start of the encryption process is that it puts separation between the initial exploit and the ransomware activity. This creates a potential problem for incident-response or forensics teams trying to reconstruct the attack. Over the course of an hour it is possible for a user to visit dozens of websites and, with the way ad networks work, hundreds of URLs. Trying to identify which of those sites were responsible for the original attack, especially if that site is not always serving up exploits, becomes a significant challenge. This makes it more difficult for the security team to protect the network by identifying and blocking a potentially bad domain name or the exploit that was used to launch the attack.

Crypt + XXX

The main thing that ties the CryptXXX developers to the team that created the Reveton ransomware is the name itself. The researchers at Proofpoint who named the file did so based on the fact that the ransomware appends the .crypt extension to the end of the newly encrypted files (though later versions of CryptXXX append the extension .cryp1 to the end of newly encrypted files). The XXX originates from the fact that the code security engineers who reverse-engineered it referred to themselves as XXX. This is also how the developers of the Angler exploit kit referred to their codebase.⁴

There has been speculation that the team behind the Reveton ransomware family was also the developer of the Angler exploit kit and all three groups (Angler, Reveton and CryptXXX) seem to operate out of the same general area. Of course, it is possible that the CryptXXX team expected to use the Angler exploit kit from the start and simply built the ransomware to fit into their model.

Whoever is ultimately behind it, it is very clear that they are sophisticated group that has a professional development process, fixing bugs, countering countermeasures, and adding enhancements in a timely fashion.

The first report of CryptXXX appeared April 2016, and by April 26, Kaspersky had released a decryption tool.⁵ In late April 2016, the CryptXXX team introduced version 2 of their ransomware, which bypassed the Kaspersky decryption tool. On May 13, Kaspersky released an updated tool. On May 16, the CryptXXX developers delivered version 3. At the time of this writing no one has released a decryptor tool for version 3 or higher. A fourth version of CryptXXX was uncovered by Fortinet on August 22.⁶ Figure 9-1 outlines the release timeline of CryptXXX to date.⁷

Figure 9-1. Timeline for CryptXXX releases (all dates in 2016)

This type of rapid release schedule makes it difficult for security vendors to stay ahead the CryptXXX team and continue to offer protection. In addition to changing their code, the CryptXXX team has also changed up their tactics, techniques, and procedures migrating from using only the Angler exploit kit as a delivery mechanism to adding in the Neutrino exploit kit (this change was most likely caused by the demise of the team behind Angler and the sudden disappearance of Angler activity) and, in version 5, adding delivery as a PE instead of relying on just DLLs.⁸ There is also a report of CryptXXX being delivered via spam, which most likely stems from the fact that Angler exploit kit activity disappeared completely in early June 2016.⁹

Exploit Kits

When an unsuspecting target visits a web page (either one controlled by the hacker group, or one that they have compromised) the exploit kit fingerprints the person making the request to determine what applications, and more importantly, what versions of the applications are running on the target host. Based on the results of the fingerprinting, the exploit kit decides which of its exploits to attempt to use against the visitor.

Again, if the vulnerable or targeted plug-in is not installed, there is nothing there for the exploit kit to attempt attack. Unless, of course, there is an known exploit against the browser itself. Fortunately, browser exploits are a lot more rare than they used to be and when they do pop up they are patched a lot faster.

Whenever possible, try not to install browser plug-ins if it can be avoided. Adobe PDF Reader is a perfect example of this. Almost everyone has Adobe PDF Reader installed. Many documents used in the workplace require a PDF reader and Adobe is the most common. But there is rarely any reason to install it as a browser plug-in. There is no productivity loss when a user has to download a PDF and read it outside of the browser. Given that PDF vulnerabilities occur with some frequency, why introduce the additional risk of having the PDF vulnerability directly in the browser?

Of course, that doesn’t stop an attacker from loading a PDF with a malicious JavaScript that can execute a vulnerability and download malicious code, but today that is not a technique that the CryptXXX team is using.

It is not always possible to avoid browser plug-ins. There are always specialized applications that require the Java or Adobe Flash plug-ins. In cases where these plug-ins must be installed, it is important that they are kept up to date. As discussed in Chapter 5, an asset management platform should be in place that catalogs browser and plug-in type and version information across the enterprise.

It is also important for security teams to track updates to the Angler (assuming it resumes operations) and Neutrino exploit kits. There are a number of great sites out there that track changes to the different exploit kits and provide timely updates to new exploits and payloads that are being used by the different exploit kits. One of the best is Malware-Traffic-Analysis. Beyond the great work that Malware-Traffic-Analysis is doing, there are number of great resources from different security vendors. Security teams that have good relationships with their security vendors should find out where those vendors publish updated analysis information and track those sites closely. This helps security teams understand what types of ransomware their current solutions protect against and can be used to question ransomware families for which their vendors might not have coverage.

DNS Firewalls and IDS

Another significantly more challenging way to prevent a CryptXXX attack is blocking access to the infected domains the exploit kits are using. Generally, the team behind CryptXXX does not set up malicious websites to launch attacks. Instead, they rely on being able to compromise websites like those using WordPress or Joomla or take advantage of poor security monitoring in ad networks to deliver their ransomware.¹¹

At any one time, there are a large number of websites that are compromised and being used to attack unsuspecting victims. There is also a large group of researchers who spend their days scanning for and listing those compromised websites. For example, the Ransomware Tracker Website and the previously mentioned Malware Domain List are both good ways to track current malware activity.

Since, at the time of writing, the CryptXXX team relies primarily on web-based exploit kits to deliver their ransomware being able to block these compromised domains can help protect a network.

DNS firewalls

The first advantage is that they are able to black hole any traffic to the domain. While some solutions focus only on ports 80 and 443, a DNS firewall, when configured to block, will stop any requests to a malicious domain from even leaving the organization’s network. This means that attackers looking to bypass traditional proxies by sending out command-and-control information embedded in a DNS request will still be stopped.

Secondly, some DNS firewalls, like the offerings from eSentire, OpenDNS, and ThreatSTOP, have curated intelligence to provide the most up-to-date information. This significantly reduces the chances of false positives and false negatives. Some DNS firewall vendors, such as ThreatSTOP even have intelligence around ransomware families and can specifically block traffic destined for known ransomware command-and-control infrastructure, as shown in Figures 9-4 and 9-5.

Figure 9-4. ThreatSTOP ransomware indicator of compromise

Figure 9-5. ThreatSTOP report on a ransomware domain

DNS firewalls also have the advantage of being able to ingest third-party intelligence. So, if an organization is working with its industry Information Sharing and Analysis Center (ISAC) or other intelligence sharing organization, it is able to take the indicators provided and feed them into its DNS firewall for added protection.

Remember These Are Exploit Kit Preventions

All of this talk around domain names applies to protecting against the exploit kits that deliver CryptXXX, not to stopping CryptXXX communication itself. CryptXXX communicates using IP addresses rather than domain names, so a DNS firewall will not be effective in stopping that communication unless it has a separate component, as ThreatSTOP does, designed to block IP addresses at the firewall level.

Again, a DNS firewall should not be the only solution to protecting against the exploit kits but one can significantly improve the chances of stopping an exploit kit from infecting targets within the network and preventing CryptXXX from ever reaching its victim. For even better protection, combine a DNS firewall with an IDS that has an updated signature set.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any 
(msg:"EXPLOIT-KIT Neutrino exploit kit landing page detected"; 
flow:to_client, established; file_data; content:"return"; 
content:"join"; within:8; 
content:"MSIE |28 5C|d+|5C|.|5C|d+|29 3B|"; distance:0; 
content:"navigator["; within:60; content:!"]"; within:10; 
metadata:policy balanced-ips drop, policy security-ips drop, 
service http; classtype:attempted-user; sid:36535; rev:3;)

Keeping users informed

User education is a very important part of protecting an organization against ransomware, which is why Chapter 5 is dedicated to the topic. User education is an ongoing process, and sometimes it takes a few times before the message sticks. In the world of marketing there is an old adage called the rule of seven, which means that customers have to hear a message seven times before they will “take action” (a euphemism for “buy your stuff”).

One of the ways that security teams can provide continuous training to users is to set up informative redirect pages when a user attempts to visit a ransomware site. Most organizations simply block or blackhole malicious traffic, so users don’t know why they couldn’t get to their intended site. If a redirect page is set up, it is often uninformative and doesn’t help users correct their behavior.

Many security vendors give security teams the ability to set up more informative redirect pages that can actually be used to educate the user, like the one shown in Figure 9-6, but not enough security teams take advantage of these capabilities. It is worthwhile for security teams to investigate the redirect capabilities of their security tools and start using them as educational tools.

Figure 9-6. ThreatSTOP redirect page

Stopping CryptXXX

Despite the best attempts of security teams to detect and prevent exploitation by the exploit kits, the truth is it is still possible that CryptXXX will bypass defenses and attempt to infect a machine. Those infections may come because the hacker group behind CryptXXX changes their tactics, such as using email as an attack vector, or users may infect their end-point while outside of the organization’s network defenses. This means that there needs to be systems in place to detect and stop CryptXXX itself, or at least minimize the damage.

One of the unique things about CryptXXX is that the initial callout to its check-in command-and-control host is to an IP address instead of a domain name. It also uses TCP port 443 for communication, but the traffic is not TLS. Any organization actively monitoring TLS traffic can alert on malformed TLS traffic to an IPS address and have a high level of confidence that even if it is not CryptXXX, it is most likely something bad.

There are also Snort signatures that are in place to specifically check CryptXXX check-in traffic (line breaks added for clarity):

alert tcp $HOME_NET any -> $EXTERNAL_NET 443 
(msg:"MALWARE-CNC CryptXXX initial outbound connection"; 
flow:to_server,established; content:"|20|"; depth:1; 
content:"|91 70 00 00 00 00 00 00 00 00 00 00|"; within:12; 
distance:35; metadata:impact_flag red, policy balanced-ips alert, 
policy security-ips alert; 
reference:url,virustotal.com/en/file/0b12584302a5a72f467a08046814
593ea505fa397785f1012ab973dd961a6c0e/analysis/; 
classtype:trojan-activity; sid:38784; rev:2;)

Blocking on the initial check-in traffic will prevent the CryptXXX variant from connecting with the command-and-control infrastructure, but it may not prevent the encryption process from happening. Basically, this alerts security teams that someone is infected, so they can respond quickly and prevent more damage across the network.

CryptXXX is unique in that, most of the time, it installs at as a DLL instead of an executable, which is unusual. The loader also usually drops it into the AppData folder, something like this (line break added for clarity):

C:Users\%Username%AppDataLocalTemp
{FA68702D-3D3D-5724-9808-175329768396}
api-ms-win-system-advpack-l1-1-0.dll

Using Microsoft’s group policy editor it is possible to restrict installing files, even DLLs into that directory. If CryptXXX cannot be installed into that directory, it will fail and the target system will not be infected. The same effect can be achieved, often with more precision, by using an advanced end-point protection system like Carbon Black or SentinelOne.

Another unique feature of CryptXXX is that it will scan for more drives and attempt to encrypt the data on those drives. CryptXXX does this in two ways:

1. Looks on the local system for mapped drives from B: to Z:
2. Scans the network on port 445 looking for open shared drives or folders

Addressing the second problem is easy—don’t allow any open shared drives or folders on the network, which is something that can be enforced as a policy in Windows and should be.

Addressing the first problem is also easy, but will undoubtedly be unpopular. It is also possible to set policy so that a user is required to reauthenticate to a shared drive every time they access it. By setting a policy that does this, CryptXXX may infect a single system, but it will not wreak havoc across the entire organization.

Enabling some of the security options outlined here will allow an organization to better protect against CryptXXX, as well as other ransomware families. Remember, only using one of these security options is not enough. A multilayered security strategy is the most effective way to combat a threat like ransomware.

Of course, as discussed in Chapter 5, multilayered security is not as effective if the different systems and security options in place do not talk to one another. Windows alerts, end-point alerts, DNS firewall alerts, firewall alerts, and IDS alerts should all be correlated in a single place. Whatever tool is used to correlate those events should be easily accessed by all members of the security team, allow security teams to have a big-picture understanding of what happened, and allow them to take meaningful action based on the correlation of events.