The Third Amigo: detecting Ryuk ransomware

Ryuk started out as just another name in the vast ocean of ransomware that hit the internet like a tsunami a few years ago. Since then Red Canary has watched it quickly rise up the ranks, hitting the news on a near-daily basis as hospitals, local governments, businesses, and schools find themselves unprepared to deal with the sophisticated threat actors behind Ryuk. The organizations that experience the most damage are those without functional backups, incident response (IR) plans, and the means to detect and prevent the chain of behavior that leads to a Ryuk outbreak.

The Three Amigos

The Red Canary CIRT sees Ryuk on a daily basis; we’ve dubbed it one of the “Three Amigos,” along with Emotet and TrickBot. Like Steve Martin, Chevy Chase, and Martin Short, our Three Amigos either ride into town on the same horse or aren’t far behind the other, with Ryuk usually bringing up the rear.

Wherever there is suffering you’ll find us there…

Unfortunately, it’s fairly common these days to get a call from our IR partner Kroll as they take on a new customer who has spotted Ryuk in their environment. Ryuk operators typically target enterprises that want to quickly resume normal business operations. In other words, they know Grandma isn’t going to buy BTC to get her pictures back, but a major corporation will.

Ryuk is typically not the first sign of trouble we see on a customer’s environment. The operators behind Ryuk follow a tried-and-true plan to quickly penetrate a network, identify sensitive infrastructure, and move laterally.

Initial infection is usually achieved through a weaponized Word document dropping Emotet. Shortly after Emotet, TrickBot arrives on the scene and starts enumerating the network, stealing credentials, and moving laterally. After surveying the victim’s environment and plundering valuable data, Ryuk is quickly deployed to high-value targets (typically domain controllers, web servers, databases, etc).

Son of a motherless goat

Researchers have theorized that the Russian actors behind Emotet and TrickBot purchased the source code for Hermese, a commodity ransomware family that popped up on hacking forums in 2017. They have since developed Hermese into the destructive ransomware we see today as Ryuk. It’s also possible that the Emotet and TrickBot actors sell off access to the group behind Hermese. Either way, the authors behind Ryuk are constantly changing techniques and adding or removing tooling.

No two Ryuk outbreaks are the same, but there are a few common techniques we have observed between different versions and victim environments. Of all the detailed analysis of Ryuk published in the past few months, not much of it has focused on behaviors one would expect to see reflected in endpoint detection and response (EDR) telemetry gleaned from Sysmon or another commercial platform. What follows is an analysis of Ryuk from the endpoint perspective, along with a few detection tips that may be helpful for security teams looking to locate Ryuk in their environment.

A plethora of piñatas (behaviors)

During IR engagements we often see Ryuk spread all over a network with a priority of effort on high-value targets like domain controllers, databases, and web servers. The method employed to spread Ryuk can be different depending on the customer’s architecture and the level of access the operators have.

A particularly effective method we’ve observed involves the Ryuk operator leveraging Group Policy shutdown scripts to deploy a Ryuk binary:

We typically see Ryuk placed in the “Public” user profile:

A malicious binary executes the Command Processor cmd.exe, which leverages Microsoft’s Console Registry Tool (reg.exe) to establish persistence via a Registry run key. Ryuk often uses the Registry run key svchos, although we’ve seen other variations. You might notice how closely this resembles the trusted Windows Service Host Process svchost.exe.

Recent versions of Ryuk have started leveraging Wake-On-LAN by sending a specially crafted “magic packet” to remote machines so they can be brought out of sleep states. Ryuk proceeds to mount the remote endpoint’s C$ administrative share and begins encrypting files and dropping ransom notes.

At some point, Ryuk will typically proceed to encrypting locally attached drives. But first, to ensure it doesn’t run into any permission issues, it will leverage Microsoft’s Discretionary Access Control List tool (icacls.exe) to grant the group “Everyone” full access to the root of the drive while propagating permissions down folder structure.

The invisible swordsman

Perhaps one of the most notable aspects of Ryuk, as well as its other two partners in crime, is its abuse of core Windows processes. In particular, Ryuk looks for running trusted processes in which to inject malicious logic. This sets Ryuk apart from other, more monolithic ransomware families that directly encrypt files or leverage PowerShell to do their dirty work. Ryuk attempts to evade detection by injecting a thread into at least one trusted running process.

In the following example, our unsuspecting process is the Windows Remote Desktop Clipboard process (rdpclip.exe). This makes identifying and stopping Ryuk more difficult for defenders as multiple trusted processes could be encrypting and deleting files on an endpoint.

Well, it wouldn’t be ransomware if it didn’t delete shadow copies. Ryuk doesn’t disappoint and adds its own unique touch by injecting logic into the legitimate VMware Tools process (vmtoolsd.exe):

To keep us all on our toes, Ryuk will also occasionally leverage Windows Management Instrumentation Command Line interpreter (wmic.exe) to delete all shadow copies.

Ryuk will attempt to stop many security services, and alerting on all of them could prove to be noisy. The Security Account Manager service (samss) is a constant among all of our Ryuk detections .

Oh GREAT! REAL bullets!

If everything you’ve read already isn’t scary enough… it gets worse. In order to make recovery from an infection more difficult, Ryuk leverages the Boot Configuration Data Editor (bcdedit.exe) to disable the built-in Windows Automatic Startup Repair.

The boot status policy is also changed to ignore all failure.

Finally, Ryuk ends by displaying a ransom note in Internet Explorer that typically instructs the victim to not turn off their computer. Early versions of Ryuk did not take many precautions and often encrypted core Windows files, which would leave the machine in an unstable state. More often than not, machines would not survive a reboot after being infected by Ryuk.

We have a plan

Many of the behaviors we’ve outlined are rare in enterprise environments. If you were to just build out detection logic around these behaviors you would likely be left with a high signal-to-noise ratio and a solid ability to detect Ryuk. However, it would be beneficial to ensure that you have good coverage for Emotet and TrickBot so you can catch the string of behavior leading up to Ryuk. We wrote a blog with some detection ideas about Emotet last year, and we also have more extensive guidance on detecting that trojan as well. The Three Amigos can propagate around a network very quickly. If you have the ability to quickly isolate any endpoints infected with Emotet and TrickBot you may never have the opportunity to meet the third amigo, Ryuk.

Detection tips

A Ryuk outbreak can be devastating for even well prepared organizations. Restoring files from backups or purchasing a decryptor may recover sensitive files, however, unexpected downtime will still take a toll as many endpoints may be left in an unstable state and require a complete rebuild to resume operation. The best defense is to have a detection plan and some level of automation in place to quickly stop the malware and prevent lateral movement to sensitive infrastructure.

Security teams should look out for the following:

• Statistically rare or new binaries establishing persistence via Registry run keys. In many samples, Ryuk leverages Microsoft’s Console Registry Tool (reg.exe) to create a registry key named svchos
• Changes to security services. In particular, Ryuk leverages Microsoft’s Net Command tool (net.exe) to stop the Security Account Manager service (samss)
• Binaries executing from the public user profile (e.g., C:\Users\public\Ryuk.exe)
• Excessive permissions being granted to the root of network-attached drives by Microsoft’s Discretionary Access Control List tool (icacls.exe)
• Shadow copies being deleted via the Windows Management Instrumentation Command Line interpreter (wmic.exe) or the Volume Shadow Service Administration Utility (vssadmin.exe)