Who Was Behind Ryuk?

3 days ago

4 min read

KEEPING SAVANNAH MOVING · INVESTIGATION 2 OF 8

Ryuk was identified; the operators were not publicly named. That is the clearest answer the Coast Guard’s public account gives us. In When Ransomware Stops the Port, we examined a maritime facility whose primary operations stopped for more than 30 hours. The December 2019 Coast Guard bulletin identifies the ransomware but names neither an attacker group nor the facility. It provides no basis for identifying Savannah as the victim.

There is still a useful investigation to pursue. What did researchers learn about the people deploying Ryuk? How much of that knowledge applies to this particular incident? And what should a Savannah logistics business do while those questions remain unanswered?

Start with the tool, then examine the operator

Ryuk is a ransomware family: malicious software used to encrypt files and deny their owners access. Identifying it gives responders a starting point for investigating a compromise. The person who deployed it, the person who obtained access, and the person who developed the software may be different participants. Establishing those relationships requires additional evidence.

That distinction matters when reading a headline. A report about a Ryuk infection and a report attributing an intrusion to a particular criminal group answer different questions. A careful account should make clear which claim its evidence supports.

The criminal ecosystem around Ryuk

In its research on Ryuk operations, CrowdStrike associated the ransomware with WIZARD SPIDER, a criminal group it assessed as operating from Russia and already associated with TrickBot malware. Its incident responders found TrickBot in environments affected by Ryuk. The research described intruders examining networks, obtaining privileges, and distributing ransomware across systems. These findings concern CrowdStrike’s investigations; they do not establish who conducted the maritime attack.

The Canadian Centre for Cyber Security’s October 2019 assessment described a possible sequence involving Emotet, then TrickBot, then Ryuk. Earlier malware could provide access and help intruders explore the network before encryption began. The agency also cautioned that finding Emotet or TrickBot did not necessarily mean Ryuk was present. The sequence was a pattern investigators had to assess, not an inevitable progression.

For an owner, that history changes the significance of an early malware alert. The questions should include whether the intruder obtained credentials or reached another system. The business may still appear to be functioning when those questions need attention. Waiting for a ransom demand would set the response threshold too late.

Why the names can become confusing

Security researchers group activity according to the evidence they can observe. Mandiant’s explanation of its UNC designations describes clusters built from infrastructure, tools, and behavior. Those clusters can change as evidence accumulates. It first discussed UNC1878 in connection with an intrusion following TrickBot access, then linked a later Ryuk incident to that activity cluster. A tracking name is an analytical conclusion with a defined scope.

In later research on FIN12, Mandiant described a group specializing in ransomware deployment while relying on partners for initial access. It distinguished that group from other actors operating within related malware ecosystems. This illustrates the larger problem with assigning every incident involving one ransomware family to a single crew: the work can be divided among participants with different roles.

An owner does not need to memorize this catalog. The useful question for anyone presenting an attribution is straightforward: what connects this incident to that actor, and how confident are you? A responsible answer should explain both the evidence and its limits.

Magnifying glass over an orange fingerprint, evidence files and log records, with obscured profiles and a faint port skyline. — Original AI-generated conceptual illustration. Malware identification and attribution to an operator are separate investigative findings.

What a useful incident briefing should answer

Our recommendation is to ask for a short briefing that separates observations, assessments, and unanswered questions. It should help the person running the business make decisions, even while specialists continue investigating. Four questions provide a useful starting point:

What was observed? Ask which alert, login, file change, or other record supports the finding, and when it occurred.
What could the affected account reach? Identify the relevant applications, shared files, administrative functions, and recovery systems, then distinguish possible access from access actually observed.
What remains uncertain? Ask which systems or time periods have not been examined and whether missing records limit the investigation.
What decision is needed now? Identify the proposed action, the person authorized to approve it, the business impact, and when the team will reassess.

This structure also improves communication with customers. A business can explain an observed interruption and its response without making premature claims about the attacker or promising that the investigation is complete.

A Savannah example: act on the access you can see

Consider a hypothetical Savannah trucking contractor. Its provider reports an unauthorized remote session on a dispatch computer. Assignments remain available, drivers are working, and no ransom note has appeared. The owner asks whether this is the same gang from a recent news story. The responder cannot yet say.

The business still has immediate decisions to make: who can restrict that session, whether the computer can be isolated while dispatch uses a safe fallback, and what evidence the provider needs to retain. The CISA #StopRansomware Guide supports coordinated isolation, preserving evidence that could otherwise be lost, and using separate communications when necessary. Applying that discipline does not require a confirmed criminal identity.

A practical step this week

Take that hypothetical dispatch incident to your IT or security provider. Ask them to walk through who receives the alert, who can authorize containment, how dispatch continues, and what records they would preserve. Record any unanswered question and assign someone to resolve it.

Attribution deserves careful work. Business continuity deserves a response that can begin while that work proceeds. The most useful outcome for a local contractor is a team that can explain what it knows, acknowledge uncertainty, and take proportionate action to protect the next day’s operations.

Next in the series: How Ransomware Spreads Through a Business.