Detecting ransomware: three research-based recommendations

It seems like new ransomware incidents are now almost a daily occurrence. Victims large and small represent a variety of sectors, including health and education providers, critical services, corporate enterprises, and government entities. And for every compromise involving ransomware that makes its way to the public, there are likely many more that are kept quiet. 

Our goal was to perform lab detonation of publicly available ransomware variants and identify commonality among the metadata and artifacts, in order to discover and suggest development of detection and/or prevention capabilities of this very damaging malware. 

You can read an executive summary version of this post here. Read on for the full details of the research:

Sponsorships Available

Sponsorships Available

Sponsorships Available

The problem

Functionally, the underlying age-old issue is still access. Malicious actors are: 

• gaining execution upon computer systems where they don’t belong
• uploading/executing additional tools and utilities, and/or employing “Living Off the Land” techniques
• elevating
• persisting
• surveying
• moving laterally
• identifying and exfilling data of value from the victim computers’ filesystems (likely over strongly encrypted paths)
• delivering and executing their ransomware payloads within the victim’s computing environment.

As indicated by the reporting of multiple incidents within many environments, these compromises aren’t being detected, and the actors keep profiting.

Vectors for gaining these accesses vary according to reporting, but usually include things like:

• obtaining “legitimate” user credentials that can be leveraged via commonly available services such as RDP and remote file sharing
• exploitation, whether via publicly known (but unpatched) software vulnerabilities or 0day
• social engineering and spear-phishing, often involving document-borne malicious software attacks.

All of these vectors are compounded by the likelihood that malicious actors are skilled in avoiding the latest cybersecurity products, which can make reliable and robust detection and alerting techniques extremely challenging.

In noting the recent evolution from automated to successful human-oriented ransomware campaigns, Microsoft correctly noted in March 2020 that “Organizations should focus less on resolving alerts in the shortest possible time and more on investigating the attack surface that allowed the alert to happen. This requires understanding the entire attack chain, but more importantly, identifying and fixing the weaknesses in the infrastructure to keep attackers out. Removing the ability of attackers to move laterally from one machine to another in a network would make the impact of human-operated ransomware attacks less devastating and make the network more resilient against all kinds of cyberattacks…”

IronNet’s detection capabilities and product offerings, through a combination of network behavioral detection models, fully enriched events, and prioritized alerts, are well-suited to address these types of malicious access activities within customer environments. As the leading provider of Collective Defense and Network Detection and Response (NDR) capabilities, IronNet is “leading the charge” against network-borne malicious activity, through combined behavioral analytics, signature-based detections, and shared human threat insights. 

All of that being said, in situations where the malicious actors’ accesses have not been addressed prior to executing their ransomware payloads, is there anything that could be done to detect and alert on the functionality of executed ransomware binaries themselves, and either stop that execution, or take action to minimize its impact within an enterprise?

Common characteristics of ransomware

Readings of technical resources detailing characteristics of assorted ransomware variants show that each of them implements different aspects of their attacks in different ways, helping cybercriminals to achieve greater efficiency/speed in delivery of their effect, and also to help evade detection.

Despite the differences in specific ransomware attacks, certain endpoint results are often much the same: 

• A pre-configured set of endpoint processes, services, and installed products that could aid in detecting execution of or helping with recovery from the ransomware attack are often surveyed, identified, disabled, and/or removed, prior to the encryption phase
• System backups, recovery partitions, and volume shadow copies are usually deleted, again to impact any potential for data recovery
• System event logs can be disabled and wiped
• Selected filesystem data content of value throughout the accessible victim enterprise is then encrypted, and
• Some form of “ransom note” is left behind, containing contact information (usually an e-mail address, and/or a web link) for the malicious actors, so the victims can negotiate possible remediation of the attack for a fee.

The files that are encrypted can vary, depending on:

• Tendencies of specific ransomware variants
• Potential parameters passed to the ransomware binary to tailor certain aspects of its execution
• Pre-configured characteristics, whether hard-coded within the ransomware binary itself, or set within ancillary actor scripts/tools used to execute the binary, such as…
  • Specification for inclusion or exclusion of files based on certain filename extensions or file types,
  • Certain filesystem directories specified for inclusion (to be encrypted, i.e. “C:Users”) or exclusion (to be avoided, i.e. “C:Windows”), 
  • Inclusion or exclusion of any available remote network file shares.

IronNet’s ransomware investigation

Seeing no need to repeat work reflected within the large number of excellent in-depth technical resources available detailing many distinct ransomware variants, this effort was focused on observable run-time behaviors of a few different ransomware families that have been recently noted in association with some high-profile compromises in public reporting over the last few months. 

A handful of representative Windows binary samples were chosen for each of the following ransomware strains:

• Maze
• Netwalker
• Ryuk
• Snake/Ekans
• Sodinokibi/REvil
• WastedLocker

The intent was to detonate these samples within a minimally configured, internal isolated lab network (no live C2), and collect any associated network and endpoint activity that might be used to seed potential development of corresponding network- and/or endpoint-based detections, if either might prove possible.

Set-up details

VMware Fusion was used as our hypervisor for these tests. Our run-time requirements were fairly simple: 

1. Provide us an internal lab virtual network that could be monitored and confidently isolated from any available “host” computing resources (hello: it’s ransomware)
2. Provide on-demand snapshotting, pausing, and resuming of our test virtual machines (VMs), as necessary.

Any other favored hypervisor may certainly have sufficed, if they met those two fundamental requirements; VMware Fusion happened to be available to us. 

Publicly available tools were used to perform collection of metadata/artifacts, to conveniently allow anyone else to easily reproduce or investigate similar results in their own lab environments, if so desired.

The lab configuration was kept as simple/minimal as practical, with firewalls turned off within each host: 

To maximize potential vulnerability, the same two interactive users (Administrator and vmuser) were present on both the Win7 victim VM and the Win10 remote share VM, with the same passwords.

Note that for purposes of these tests, we “skipped to the chase,” so to speak, assumed compromise, and executed everything as “Administrator.”

Here was the basic approach for detonation/collection of each selected ransomware binary: 

1. Configure the InetSim utility on the REMnux VM to serve as:

• The lab subnet’s DNS server (resolving all DNS requests to its own IP address)
• The lab subnet’s Web server (for both “http:” and “https:” requests), to provide innocuous Web content to any potential “phone home” requests, and catch and save off any potential URLs and data sent to intended C2 endpoints via “POST” requests.

Note that for certain variants (i.e. Maze), it was also necessary to configure additional logical interfaces on top of the default “eth0” NIC, to catch “POST” data intended for pre-configured C2 IP endpoints within each of those samples.

Also note that the default bundling of Wireshark was used within our REMnux VM for PCAP collection, until we encountered Ryuk, whose sudden, accumulated volume of network data crashed Wireshark. For Ryuk, and some other subsequent detonations, we used the default “dumpcap” executable to collect and save off our PCAP files without further incident.

2. Pre-load copies of each of the respective ransomware samples onto the Win7 victim VM.

Given that we were working solely with the executable binary samples, and had no detailed knowledge of how they are executed by the malicious actors in their target environments, each sample was executed in a default manner, with no specific command-line arguments (in “.exe” cases) or parameters (in “.dll“ cases) provided.

3. For contrast, collect a representative set of metadata/artifact enumerations both “before” and “after” detonation of each ransomware binary, for both (1) the Win7 victim VM and (2) the Win10 remote filesystem provider VM.

Artifacts collected and produced 

For the Win10 remote filesystem provider VM, we wrote 2 small PowerShell scripts (which performed much the same function for 3 different directories, so, in hindsight, they certainly could have been coded more elegantly) to produce: 

• a listing, for each file, containing a recursive directory walk from the “C:” root of its entire local NTFS filesystem, including the properties:

Mode
Length
Fullname
Stream (with any Alternate Data Streams reflected with a special notation)
CreationTimeUtc
LastWriteTimeUtc
LastAccessTimeUtc

• a listing containing a recursive directory walk of only the “C:WindowsSystem32” subdirectory, including the above properties for each file, plus a computation of a SHA256 hash for each file
• a listing containing a recursive directory walk of only the exported/shared “C:eat_this_ransomware” subdirectory, including the above properties plus SHA256 computation for each file.

All 3 filesystem share listings were produced on the WIn10 VM, not knowing beforehand whether any of the ransomware variants might attempt to perform network-based survey and encrypt of…

• Only the “C:eat_this_ransomware” subdirectory, exposed as a mountable filesystem share for use by the Win7 victim VM,
• The entire remote root “C:” root, in case the tested ransomware variant was somehow able to access remote filesystem data beyond only the exposed subdirectory “C:eat_this_ransomware“, and
• The “C:WindowsSystem32” subdirectory, in case of any direct modifications by the ransomware (just in case) to an area often perceived as a “system” area, and thus ignored.

For the Win7 victim VM, a broader set of “before” and “after” artifacts was collected, as we had no idea what might prove interesting and/or relevant as each of the respective ransomware samples was executed. These data included (but, in specific cases, were not limited to):

• Listings containing a recursive directory walk from the “C:” root of its entire local NTFS filesystem, collected in the following different ways: 
  • via The Sleuth Kit’s “fls -lrp” command to enumerate:
    • “inodes”, which is a “metadata address” Sleuth Kit construct that corresponds to each individual file or directory’s entry information in the NTFS Master File Table
    • pathnames
    • file modification, access, change and creation timestamps
    • file length.
  • via The Sleuth Kit’s “fls -m” command to produce similar information in a “bodyfile,” an intermediate file used to subsequently produce a relative timeline of file activity (a.k.a. “mactime format“) when fed to the “mactime” utility
  • via Cygwin’s “find” command, to produce similar information, in an alternative manner and format, for use in comparison and verification of The Sleuth Kit’s outputs (should that be needed), specifically for the file modification, access, and change timestamps.
• Interestingly, the “fls -m” and subsequent “mactime” outputs included metadata and timestamps that indicated changes not only to the file contents themselves, but also to each file’s corresponding “$FILE_NAME“ attribute from its NTFS file entry, which allowed us to easily view the additions of each ransomware’s traditional, specific filename extension to the filenames being encrypted.
• Various and sundry other “before” and “after” information, usually including: 
  • complete Registry dumps for the HKCC, HKCR, HKCU, HKLM and HKU hives, along with specific enumerations or extracted data such as “Auto Runs”, pending file moves/renames, currently configured Windows Services, and entries from the Boot Configuration Data store,
  • running processes (and threads) including enumeration of their currently loaded DLLs
  • loaded and unloaded kernel drivers
  • all open handles for currently running processes, and
  • network port information along with any discernible process association.

Additionally, when needed during these investigations, the Volatility framework was occasionally used to carve out memory segments of ransomware processes from paused or snapshotted VMs, providing a way to save time and more easily obtain and gain insight into certain run-time parameters and configurations that were sometimes heavily obfuscated within each of the original executable file samples.

Results and findings from the detonations…

1. North-South data? Not so much…

Traditionally, in terms of deploying and maintaining rigorous security configurations, advanced firewall and NDR technologies, and maintaining up-to-date software and firmware security patches, the North-South data communications path has normally been heavily defended, but the East-West data paths encompassing the enterprise’s internal and/or operational technology (in the case of critical systems) networks are sometimes neglected in this regard to some extent.

Additionally, NDR sensors are sometimes not afforded direct visibility into internal customer environments, due to restricted placements at North-South ingress/egress boundary points.

Unfortunately from a network-centric view, local endpoint execution of these selected ransomware samples did not produce much in the way of North-South data movement, overall. From an NDR perspective, that’s a little disheartening.

A slight exception is Maze, which delivered a set of two apparently encrypted or obfuscated “POST” data packets to a series of 10 pre-configured IP addresses. The first set was ~340-bytes each: 

Click the image to enlarge it.

And the other was ~47 bytes each: 

Click the image to enlarge it.

One of the Sodinokibi/REvil ransomware samples attempted DNS queries for 1223 different domain names, performing SSL connections and handshakes with our InetSim lab endpoint after each resolution, but sending no data, before each connection was TCP RESET from the Win7 Sodinokibi/REvil victim VM end: 

Click the image to enlarge it.

Here are the corresponding InetSim “service.log” entries for the above exchanges: 

Click the image to enlarge it.

It’s probable that the InetSim “info: Client sent no data” log messages are due to a lack of a perceivable HTTPS request from the Win7 victim VM, and we see they correspond with our REMnux VM’s InetSim server returning the “Encrypted Alert” TLSv1 packets, resulting in the connection shutdown in each case. Without taking the time to reverse one of the Sodinokibi/REvil binary samples, we’ll assume that either (1) Sodinokibi expects a custom response from his C2 server once he successfully connects (more likely), or (2) InetSim is somehow inadequate for these sessions (less likely).

For our purposes here, we’re aware that we have a Sodinokibi/REvil sample that’s configured to perform DNS queries and some sort of C2, which could be investigated down the road (keeping in mind that it would be SSL/TLS North-South data), should there be interest.

Some Snake/Ekans samples did issue a “location check” DNS query for a pre-configured hostname address within their targeted victim enterprise network (appears to likely be an internal corporate domain, in each case), and compared the resolution to a pre-configured IP address that is anticipated for that hostname before proceeding with any encryption activities. Within the actual, targeted subnet, these lookups would likely be resolved within a local internal DNS server, and possibly may not reach outside the internal enterprise net at all.

Despite not entailing much in the way of North-South traffic, we also should note that each of our variants did drop some number of ransom note files on the local Win7 victim VM’s filesystem, as well as upon the Win10 remote fileshare VM’s filesystem (when their default execution did perform survey and encryption of the remotely exposed filesystem), as their content does relate indirectly to North-South, if not natively to the ransomware executions.

Each of these ransom notes contains contact information for the malicious actors, to provide the victims a means to negotiate the fee for decryption of the encrypted data content:

Maze
Filename: “DECRYPT-FILES.txt”

File content and size: Unicode text, ~9400+ bytes

Contact points provided: 

• TOR Web site: “hxxp://XXXXXXXXXXXXXXXX[.]onion/XXXXXXXXXXXXXXXX“, where “XXXXXXXXXXXXXXXX” appears to be a string of hex digits.
• Alternate Web site: “hxxps://mazedecrypt[.]top/XXXXXXXXXXXXXXXX“, where “XXXXXXXXXXXXXXXX” is the same hex string as in the above TOR link.

Netwalker
Filename: “XXX…XXX-Readme.txt“, where “XXX…XXX” appears to be a string of 57 characters from the set “[0-9a-z]“.

File content and size: ASCII text, size varied per sample, ~1500-1800 bytes observed

Contact point(s) (sometimes more than one) provided: TOR Web site: “XXX…XXX[.]onion“, where “XXX…XXX” appears to be a string of 57 characters from the set “[0-9a-z]“.

Ryuk
Filename: “RyukReadMe.html“

File content and size: ASCII HTML text, 627 bytes

Contact point provided: A single “[@]protonmail[.]com” e-mail address.

Snake/Ekans
Filename: Either “Decrypt-Your-Files.txt” or “Fix-Your-Files.txt“

File content and size: Unicode text, ~9400+ bytes

Contact point provided: A single “[@]ctemplar[.]com”, “[@]protonmail[.]com”, or “[@]tutanota[.]com” e-mail address.

Sodinokibi/REvil
Filename: “NNNNNNNNNN-readme.txt“, where “NNNNNNNNNN” appears to be 5-10 chars from the subset “[a-zA-Z0-9]“.

File content and size: Unicode text, size varied per sample, ~3000-7100 bytes observed

Contact points provided: 

• TOR Web site: All Sodinokibi/REvil samples detonated provided the same, fixed TOR endpoint, “hxxp://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion/AF54E9CB0CDCA5C7“.
• An alternate Web site provided was also identical per sample: “hxxp://decryptor[.]top/AF54E9CB0CDCA5C7“.

WastedLocker
Filename: “filename.XXXXXXXXwasted_info” is written for every file encrypted, in the same containing directory, where…

• “filename” is actual filename of the encrypted file, and
• “XXXXXXXX” (actual length of the string varies per sample/target) is a lower-case abbreviation/acronym for the company being targeted/victimized.           

File content and size: Unicode text, ~1900+ bytes

Contact points provided: 2 e-mail addresses of the form “NNNNN[@]DOMAIN” were provided in the ransom note from our samples, where…

•  “NNNNN” appeared to be a 5-digit decimal string, and
• “DOMAIN” was one of: 
  • “AIRMAIL[.]CC”
  •  “ECLIPSO[.]CH”
  • “PROTONMAIL[.]CH”
  • “PROTONMAIL[.]COM” or 
  • “TUTANOTA[.]COM”

However, as these are contact points for negotiations that would be initiated by the victims, they are, most likely, of little value to us in detection of the actual ransomware itself.

And that’s pretty much it, for any real North-South data detection opportunities presented by executions of our ransomware samples. However, as our ransomware variants did access the Win10 remote fileshare, there was a significant amount of East-West data, almost all of it via SMB over IPv6.

2. East-West data? Our cup runneth over…

Maze starts out by authenticating from the Win7 victim to the Win10 remote fileshare VM, “Administrator“, please…

Click the image to enlarge it.

…followed by laying claim to the remote fileshare by writing the first Maze ransom note file, a 9456-byte “DECRYPT-FILES.txt”, at the top level of the shared “\WIN10-1909-X32eat_this_ransomware” subdirectory…

Click the image to enlarge it.

…and then we’re “off to the races”, so to speak, running rapidly through the remote share, finding files, and encrypting them, but all via East-West traffic, underneath the noses of most intelligent firewall and network security appliances, which are usually busy focusing on any available North-South traffic.

Here, Maze moves on to the next remote share subdirectory, “dont_forget_this_stuff“, finding the file named “Spotting-the-Adversary-with-Windows-Event-Log-Monitoring.pdf“, and begins reading its contents via (mostly) 32768-byte SMB2 read requests…

Click the image to enlarge it.

…after which Maze begins writing its new, encrypted file contents via SMB2 65536-byte requests…

Click the image to enlarge it.

…until the end of the encrypted data has been transferred, when Maze closes the “Spotting-the-Adversary-with-Windows-Event-Log-Monitoring.pdf” file, and then issues an “SMB2_FILE_RENAME_INFO” request to rename our file with its new Maze-generated file suffix, so it’s new filename will now become “Spotting-the-Adversary-with-Windows-Event-Log-Monitoring.pdf.cVcoYA3“…

Click the image to enlarge it.

Maze then moves onto the next file in the subdirectory, and so on and so on and so on…busily reading, encrypting, writing, and renaming.

All via East-West traffic, within the “friendly confines” of internal networks. 

In contrast to Maze, WastedLocker samples detonated in these tests performed no survey and encryption of the Win10 remote share. Kaspersky’s recent report indicates that there is a command-line sequence available for encrypting specified network shares with associated credentials, so by performing simplest-case, default executions, with no additional arguments or parameters specified to the executable, we (unfortunately) missed that functionality from WastedLocker.

Interestingly, of the 5 out of 6 ransomware variants that conducted business with the Win10 remotely shared filesystem, 4 of those 5 (Maze, Netwalker, Snake/Ekans and Sodinokibi/REvil) did things pretty much in the same manner as depicted above: SMB2 over IPv6.

Ryuk, however, was a bit different, choosing to interact with the Win10 remote share via SMB2 over IPv4…and also should be mentioned for conducting the most voluminous East-West traffic of all samples detonated in this investigation, by far.

Starting out, Ryuk transmitted the “magic packets” for its “Wake-On-LAN” over UDP port 7 to the two available subnet IPs (192.168.210.21 (our REMnux VM) and 192.168.210.102 (the Win10 remote share VM) it detected via the Win7 victim VM’s local ARP table, as described in open source reporting…

Click the image to enlarge it.

…and then embarks upon a repetitive ARP survey of the subnet, appearing to start with the couple of hosts that were in the Win7 victim VM’s local ARP table, and then issuing requests for the rest of the 192.168.210.0/24 subnet sequentially by decrementing the last octet…

Click the image to enlarge it.

…and as it reached the other two recently seen IPs (192.168.210.21 [REMnux VM] and 192.168.210.102 [Win10 remote share VM]), Ryuk “ping”ed them, to assess their availability…

…after which, Ryuk proceeded to survey and encrypt the Win10 remote filesystem, with an interesting difference from the other ransomware variants: Ryuk started looking for other remote shares…not solely the exported “\192.168.210.102eat_this_ransomware” share, but for drive letter shares, i.e. “\192.168.210.102A$”, “\192.168.210.102B$”, “\192.168.210.102C$”, etc., up through “\192.168.210.102Z$”.

Of course, Ryuk was able to succeed in accessing the remote “C$” share, and then proceeded to plant its ransom note flag “RyuykReadMe.html” there, followed by survey and encryption of files, starting with the remote “C:config.sys” file, which quickly was renamed to “C:config.sys.RYK”…

Click the image to enlarge it.

…in fact, while Ryuk busily generated “RyukReadMe.html” files (4534 of them), renamed files with its trademark “.RYK” file extension (3100 of them), and performed the file I/O involved with its encryptions, enough network traffic occurred to crash the collecting Wireshark instance running on the REMnux VM, putting a premature end to our first Ryuk detonation. We ultimately repeated the collection using the default copy of “dumpcap” on the REMnux VM, which, likely owing to its lack of GUI processing/updating overhead, was better able to collect the Ryuk traffic without further incident.

So, in summary, there does appear to be quite a bit of East-West traffic available for detection opportunities within 5 of our 6 (Maze, Netwalker, Ryuk, Snake/Ekans and Sodinokibi/REvil) ransomware variants detonated here, and probably for the 6th (WastedLocker) as well (when executed with the correct command-line arguments).

Again, the problem is often that East-West data is not always made available to NDR sensors within customer environments. Hopefully, that situation will improve in the future.

3. Endpoint data

Yes, there is an abundance of locally evidenced metadata available on the endpoint devices related to ransomware execution, but unfortunately, this means that the malicious actors have gained access to the endpoint system, and have executed their ransomware variant upon that system.

As discussed at the beginning of this post, various effects are delivered upon the endpoint by malicious actors and their techniques (including the execution of the ransomware binaries themselves), and the resultant metadata involved may vary, resulting in somewhat different and specific artifacts evidenced per ransomware variant.

Focusing on finding commonality across all the variants detonated here, some things do appear interesting:

Endpoint: Filesystem timestamps…

We did note some “hot” timestamps evident across…

• the files that are selected and encrypted within the local filesystem
• the “$FILE_NAME” attribute within each of those files’ Master File Table (MFT) file entries, as the typical ransomware filename extension is   added to each filename
• ransom note files, which in each case, are newly manufactured.

By ransomware variant, those timestamps, evidenced within the timeline presented via the “mactime” outputs, are reflected as the following: 

Note that the timestamp mnemonics are indicated in a “macb” format, expanded at the Sleuth Kit Wiki as…

Timestamp findings:

1. As would be expected, since both are newly manufactured files, both the ransom note files, and the corresponding “$FILE_NAME” attributes for those ransom note files have all 4 timestamps (i.e. “macb”) marked as “hot”
2. Encrypted files for all ransomware variants executed do show an updated ‘c’ (“MFT Modified”) timestamp.

4 of the 6 variants also reflect an updated ‘m’ (“Modified”) timestamp (Maze, Ryuk, Snake/Ekans and Sodinokibi/REvil). However, 2 of the 6 (Netwalker and WastedLocker) do not evidence updated ‘m’ (“Modified”) timestamps for their encrypted files.

This may be due to incorporation of specific anti-detection techniques. WastedLocker, as noted by Sophos: “WastedLocker uses a trick to make it harder for behavior based anti-ransomware solutions to keep track of what is going on: using memory-mapped I/O to encrypt a file.” It’s plausible that NetWalker may also contain an alternate I/O technique, or employs some form of “timestomping“, and that these result in a lack of file modification timestamp updates for files being encrypted.

However, as the files encrypted by each of our variants also have an associated filename change as each ransomware variants’ characteristic string is added to some portion of that filename, the “$FILE_NAME” attribute within the corresponding MFT entry is modified, so the encrypted file’s “MFT Modified” timestamp is updated accordingly.

Endpoint: Filesystem directories considered for encryption

It should be noted that there was also some commonality indicated across the executions of the ransomware variants with respect to the local filesystem directories descended, or NOT descended:

Notes on those directory summaries…

• Maze results did not reflect the “C:7968dfbf928fd3d53ccd” directory, as it wasn’t yet present at the time of the Maze detonations. Those 2 oddly named directories (“C:d3cde10b0e3d62cbd9cbe478” and “C:7968dfbf928fd3d53ccd”) were software installation directories generated by (1) Windows Update and (2) installation of PowerShell 5.1 and .Net 4.5.2, respectively, on the Windows 7 victim VM. The PowerShell and .Net upgrades were installed following the Maze detonations, which were the first performed.
• “C:System Volume Information” was descended/encrypted by one Maze sample, but ignored by the other Maze samples.
• Everybody went after “C:Users” to some extent, descending, encrypting and leaving ransom notes. Snake/Ekans was an exception for ransom notes: the only copies of ransom notes observed were written to the “C:” and “C:UsersPublicDesktop” directories.
• Everybody ignored “C:Windows” (with the exception of Snake/Ekans’ foray into “C:WindowsTemp”). This makes sense, to help assure that the underlying computer system remains minimally functional while access to its data content can be held hostage.

For different variants, different file types/extensions may have been chosen for encryption. That will change per variant, and likely between targeted samples of particular variants, so is ignored here.

We also need to point out that different internal configurations from sample to sample for particular ransomware variants, as well as any malicious actor directives passed to the ransomware at run time, could alter these observed sets of directories.

Endpoint: Encrypted files and entropy valuations

There have been numerous academic papers and posts over the last few years pointing out that, in a nutshell, contents from data files encrypted by ransomware often tend to reflect a higher level of entropy than the pre-encrypted data from those same files.

Using a small, concise and publicly available utility from the “Ransomware-Scan-and-Replicate” package (thanks, Rob!), let’s see what full-file entropy values might be for some targeted data files, both pre- and post-encryption from some of our encryption runs.

Before we get into that, remember that we’re seeking commonality among variants here. As such, while there can be several thousand files encrypted by runs of certain variants, we’re trying to gain a quick sense of just how those encrypted contents might look across all variants. We were hoping to find that some encrypted files would be found in common among multiple variants…and, fortunately, there were some.

The search for commonality made us scale down to the lowest common set of shared filepaths that were observed as being encrypted in all of our tests. On our Win7 victim VM, we found 131 local files (largely under the “C:Users” and the “C:7968dfbf928fd3d53ccd” software installation directory) that were modified by Netwalker, Ryuk, Snake/Ekans, Sodinokibi/REvil, and WastedLocker variants. Our Maze tests, as noted earlier, were conducted prior to a PowerShell and .Net upgrade on the VM, so our Maze runs only shared 56 local files, as the “C:7968dfbf928fd3d53ccd” software installation directory did not yet exist at the time of those runs.

Additionally, also remember that we had a Win10 remote share VM, on which we had a few accessible files as bait, 23 of which were chosen for remote encryption via SMB over either IPv4 (Maze) or IPv6 (the others, except WastedLocker, as previously noted). While those numbers aren’t terribly large, they do indicate commonality, and give us a chance to demonstrate our point: Entropy values of encrypted files do appear to be somewhat higher among all variants observed here.

With the disclaimer that all post-infection VM snapshots were not kept on hand for all executed samples due to disk space considerations, we did still have a few VM snapshots on hand from which to subsequently extract the encrypted files and measure entropy. For the remotely encrypted files, we had file content available from some Maze, Netwalker and Sodinokibi samples, so we’ll see the “before” and “after” entropy values for each of those same files following each of several test runs…

Click the image to enlarge it.

Notes: 

• You’ll note that one of the Sodinokibi runs did not choose to encrypt 4 specific files (#12, #21, #22 and #23, noted as “n/a”), for some unknown reason, while the other two Sodinokibi samples had no problem doing so.
• There were five files (#2, #3, #21, #22 and #23) whose “after” entropy values were somewhat similar to those for “before” in the two Netwalker runs, and three of the files (#21, #22 and #23) also had similar, somewhat lower entropy values not only for Netwalker, but for two of the three Sodinokibi/REvil runs, as well.

Not all ransomware variants employ full-file encryption. Some have algorithms for determining how much of a file to encrypt, and/or what portions of a particular file they may choose to encrypt…based on things like file size, file type, pre-configuration settings, etc….and these considerations could be at play here. For example, in their excellent report on Netwalker, Crowdstrike has noted it employing these types of capabilities within its encryption functionality.

• Other than those exceptions, the other “after” entropy values all appear to be fairly high, across the board.

The summary data for the lowest and highest individual file entropy values in each case, along with the average entropy value observed across all 23 encrypted files on the Win10 remote share….

…yep, entropy appears to be a bit higher for Maze, Netwalker and Sodinokibi/REvil, following encryption.

For the local file encryptions (again, 131 files observed in common for Netwalker, Ryuk, Snake/Ekans, Sodinokibi/REvil, and WastedLocker…56 for Maze), we had file content available from some Maze, Netwalker, Ryuk, Snake/Ekans and WastedLocker runs. We’ll just portray the lowest, highest, and average full-file entropy values here, to save space…

…and we clearly note an increase in the average entropy values for file content encrypted locally, as well.

Summary and conclusions

Mitre’s ATT&CK technique T1486 “Data Encrypted for Impact” recommends, in part, “…DETECTION…Monitor for the creation of suspicious files as well as unusual file modification activity. In particular, look for large quantities of file modifications in user directories.”

We agree. But that type of detection may be a sophisticated and complex undertaking. As stated earlier, the underlying age-old issue is still access. If the malicious actors can gain access to your computing infrastructure and resources, and can deliver and execute code within that space, an assortment of malicious activity can potentially occur, including ransomware incidents.

As always, the best security methods involve robust “defense in depth” implementations. Defenses must evolve, however, to “raise the bar” against malicious actors who are continually devising and honing anti-defensive techniques within their tools, techniques and procedures (TTP).

Ransomware is a significant problem, capable of causing tremendous financial losses across many different sectors, and just recently, being directly and publicly associated with loss of human life. Anything that can be done to address this needs to be done.

Detection can most-likely occur across 3 fronts: 

1. North-South data flow, where traffic flows between internal and external network entities. This is, traditionally, where network-based detection is afforded the most access. Unfortunately, detection here is often signature-based (i.e., using domain resolutions or IP addresses), or possibly involving detection of domain generation algorithms (DGA), which aren’t always employed by ransomware variants.
2. East-West data flow, where traffic occurs among various internal components within the enterprise infrastructure. Obtaining access to real-time East-West data is sometimes a challenge, as can be the often staggering volume of data exchanged there.
3. Within endpoint computing assets themselves.

Specifically concerning execution and impact of ransomware binaries themselves, from the simplified tests we performed here, it appears that there is likely a great deal of data available for potential analysis and detection/alerting within East-West network exchanges, and also within the endpoint computing devices themselves…

• East-West will reflect any authentication and file I/O occurring between an endpoint running a ransomware binary, and any remote systems that are serving out filesystem content for sharing across an enterprise environment. Note that enabling SMB encryption may be an added consideration during design and development of relevant SMB-based analytics here.
• Any endpoint systems that are actively executing ransomware provide an opportunity for real-time detection, alerting and potentially an opportunity for abort or interruption of the associated thread of ransomware execution itself.

There is, however, a much lesser chance for direct North-South detection, given recent trends away from North-South data transfer within the evolution to human-oriented ransomware attacks noted earlier.

We’ve also been able to suggest some metadata (i.e. encrypted file timestamp modifications/transitions, encrypted filename changes, ransom note creation, and increased entropy values within encrypted/modified files) that, when correlated, could likely provide a high-confidence detection of a ransomware attack within the endpoint, and/or across an enterprise’s East-West network paths.

Recommendations

First, please keep pursuing ways to arrive at secure and greater access to real-time or close to real-time East-West network data for your network security vendors and their sensors. Malicious actors will target internal enterprise and operational technology networks whenever possible.

Second, more research is needed to arrive at a fundamental capability that can deliver a valid, real-time detection of ransomware execution within the endpoint, however that detection can be performed. And that capability should be implemented in a fashion that makes it available to the widest possible user base.

Microsoft currently provides a “Controlled Folder Access” capability within its Microsoft Defender for Endpoint product, a feature that “…works by allowing only trusted apps to access protected folders. Protected folders are specified when controlled folder access is configured. Typically, commonly used folders, such as those used for documents, pictures, downloads, and so on, are included in the list of controlled folders.” While this is probably suitable for large, production-oriented enterprise environments with tied-down sets of applications regulated for fixed usage by corporate users, one could see where this solution might prove a bit onerous in a general computing environment. There may be room for an additional capability here.

It sometimes seems as if ransomware might almost be considered a vulnerability of sorts, that begs “patching”: addressing not with a completely separate add-on solution or product, but fundamentally as an optional feature (perhaps a kernel driver/module) of an operating system product itself, so the solution can provide protection to all users of that operating system.

Many current security solutions are often detected and defeated in userspace during ransomware incidents by either the malicious actors’ TTP, or their ransomware binaries. A suitable implementation might be something kernel-based, that could only be enabled or disabled in conjunction with a system reboot (an event that would hopefully be detected/alerted/investigated by an enterprise’s Security Information and Event Management (SIEM) system), instead of a more easily accessible Registry or configuration change, or process/service start or restart.

Such a feature might involve an algorithm that could correlate things such as the following from within the kernel’s I/O implementation:

• groups of corresponding reads/writes to/from multiple files at speed, possibly monitored within pre-configured sets of directories (a.k.a. “Controlled Folder Access”) differences (whether portional or whole buffer) between corresponding I/O buffers, possibly based on before/after computations of entropy, and possibly changes to timestamps including those on the filenames of the affected files (where available).
• A high-confidence detection might result in…
• a network-based alert, to sidestep/avoid malicious actor interference with default local system event logging processes and file content
• a subsequent termination and quarantine of the offending, suspected ransomware processes/threads and their causal binaries

 an induced kernel crash, similar to the effect delivered by Microsoft’s Kernel Patch Protection (a.k.a. “Patch Guard”), when a modification of any of its monitored sets of kernel code is detected as part of its code integrity assurance, as “on x64-based systems, kernel code and certain kernel data structures are protected from modification“

…to provide the best possible chance at minimizing damage and effect of the ransomware, and help possibly reduce the impact of a potentially disastrous ransomware attack to only a few computer systems affected, instead of a few dozen, hundred, or several thousand computer systems impacted, throughout an entire enterprise.

Final thoughts

The point is to detect, and get a network-based alert out to somebody or something, as soon as possible, while the first ransomware execution is live and occurring. A “take down” of the offending processes/threads or the victim computer system itself could be an additional plus.

There may, depending on the degree of confidence in any detection assessment, be a certain degree of “false positive” that may need occasional vetting/chasing by incident response personnel.

There would, of course, be some amount of overhead/latency to such an implementation. Hopefully, that could be minimized to a point that provides an acceptable tradeoff to a customer base: run with ransomware protection enabled (and possibly just be a little bit slower), or disabled (and increase your potential susceptibility to ransomware).

Again: any alerting needs to be network-based, to minimize any potential interference with the local anti-detection capabilities of the ransomware itself. This could be as simple as a single, custom network packet that could be detected by a deployed monitoring sensor in your environment.

Additional Reading

Here are some references to interesting and applicable articles from the past few years. A detection scenario that correlates multiple metadata/artifacts that are common among many ransomware variants has obviously been and is actively being pursued by a number of security researchers. That bodes well for potential development of usable solutions in the future.

Most Ransomware Isn’t As Complex As You Might Think

Using File Entropy to Identify ‘Ransomwared’ Files

UNVEIL: A Large-Scale, Automated Approach to Detecting Ransomware

Ransomware identification for the judicious analyst

Multilayer ransomware detection using grouped registry key operations, file entropy and file signature monitoring

An I/O Request Packet (IRP) Driven Effective Ransomware Detection Scheme using Artificial Neural Network

The Inadequacy of Entropy-Based Ransomware Detection