Catching Sorry-worm in the wild [1/3]

Series navigation

• Part 1/3 - Catching Sorry-worm in the wild: discovery and propagation pattern (this article)
• Part 2/3 - Inside Sorry-worm: anatomy of a Go ransomware-worm hybrid
• Part 3/3 - Adjacent campaigns and a defender’s playbook

Executive summary

We have been tracking the in-the-wild propagation of a previously undocumented Linux ransomware-worm hybrid we refer to as Sorry-worm, named after the consistent .sorry extension and sorry_id_<digits>.sorry victim-identifier convention used by the binary.

The sample (SHA-256 2fc0a056fd4eff5d31d06c103af3298d711f33dbcd5d122cae30b571ac511e5a, 5.3 MB Go ELF, statically linked, stripped) was first publicly observed on 2026-04-30 with a Triage / Recorded Future sandbox analysis (uploaded as pic.ico, score 9/10). On VirusTotal at the time of our analysis it showed 6 detections - sub-detected for active ransomware behavior.

Within approximately eight hours of that first public submission, we captured two independent propagation events of the same sample on our threat-tracking infrastructure, originating from two unrelated source IPs. Across the same target host and within the same eight-hour window, we also observed unrelated SSH brute-force activity from a separate set of IPs deploying instances of the long-standing Multiverze SSH-bruteforce backdoor toolkit, and a third campaign from a different IP cluster running a Diicot/Opera-aligned loader rotation previously documented by Wiz Threat Research, Darktrace, Hackread, and CSO Online.

The three parts of this report cover, in order:

• Part 1 (this article) - discovery context, the two-relay propagation pattern, the geographic distribution of related scan activity across our infrastructure, and a clear separation between Sorry-worm activity and the two unrelated campaigns it co-existed with.
• Part 2 - a deep technical analysis of Sorry-worm: Go binary internals, hardcoded RSA-2048 attribution-stable indicator, AES-CBC encryption pipeline, ransom channel via TOX/qtox with a taobao.com fallback, the 48-byte fixed prefix prepended to every encrypted file, the UNIX-nanosecond–derived victim identifier, the embedded SSH wordlist with username templating, and the layered SSH scan that runs concurrently with encryption.
• Part 3 - the adjacent SSH brute-force campaigns (Multiverze backdoor family, Diicot/Opera updated build, Mirai-derived sshscan kit, low-detection adjacent samples), indicators consolidated into three confidence tiers, YARA and Sigma rules, hunting queries, a reproducible activity timeline, and defensive recommendations.

Key findings

• We caught Sorry-worm propagating from compromised SSH relays approximately 8 hours after the sample’s first public sandbox submission. Two independent propagation events from unrelated IPs, separated by ~7 hours, are more consistent with autonomous worm-style propagation through a pool of compromised SSH-accessible hosts than with a single interactive hands-on-keyboard session.
• The binary combines local file encryption with concurrent SSH target enumeration in a single process - encryption and propagation are not sequential.
• Microsoft detects the sample on VirusTotal as Ransom:Linux/Multiverze!rfn. We treat this as an automated umbrella classifier label around Linux SSH-bruteforce/ransomware behavior, not as evidence of shared code or operator identity with the long-running Multiverze sshd backdoor family observed concurrently on the same target.
• The .sorry extension and sorry_id_<digits> ransom-ID naming convention echo an unrelated 2018 Windows ransomware family (Sorry, documented by pcrisk). The present sample shares no code, infrastructure, or ransom channel with that 2018 family - only English vocabulary.
• Across our threat-tracking infrastructure, which spans more than 20 countries, we observed notable strikes related to this campaign in Estonia, Germany, India, Malaysia, Taiwan, the United States, and Singapore. Associated SSH brute-force scan activity is global; we do not assess regional targeting.

1. Discovery context

The Sorry-worm sample was first publicly observed on 2026-04-30. Recorded Future’s Triage sandbox analyzed the binary that day, classifying it at 9/10 with the following behaviors recorded on an Ubuntu 18.04 amd64 environment without specific hardening:

• renames 93 files with an added extension (consistent with ransomware encryption);
• creates and modifies cron jobs (persistence);
• writes into /usr/bin (system binary directory);
• deletes audit logs, journal logs, and additional log files (defense evasion, MITRE T1070.002);
• enumerates running processes (discovery, T1082).

The sandbox uploaded the binary under the filename pic.ico - a deliberate .ico extension disguise, suggesting at least one operator vector relies on web download or attachment-based delivery rather than direct SSH drops. We did not directly observe an .ico-disguised vector in our own telemetry; in our case the binary arrived as /tmp/.sorry_<8 random alphanumeric characters> over SSH.

At the time of analysis the sample showed 6 detections on VirusTotal, with Microsoft returning Ransom:Linux/Multiverze!rfn. We treat this as an automated umbrella-style classifier label around Linux SSH-bruteforce/ransomware behavior, not as evidence that Sorry-worm shares code or operator identity with the long-running Multiverze sshd backdoor family observed concurrently on the same host (see Part 3 §1.1 for that backdoor family). CIRCL hashlookup (NSRL and other public corpora) returned Non existing SHA-256, indicating the sample had not been submitted to widely-shared malware corpora at the time of writing. Direct web search for the SHA-256 returned zero indexed hits beyond the Triage report.

We refer to this family as Sorry-worm based on:

• the .sorry extension applied to encrypted files;
• the sorry_id_<digits>.sorry victim-identifier naming convention;
• the embedded “Sorry-ID” string referenced inside the ransom note template.

At the time of writing we were unable to identify prior public reporting using this name, or another established family name, for the same sample or the same activity set. The naming convention is reminiscent of an unrelated 2018 Windows ransomware (Sorry, documented by pcrisk), but the binary, crypto stack, ransom channel, and targeted platform are entirely distinct. The naming overlap is, in our assessment, a coincidence of English vocabulary.

2. Propagation pattern: two independent relays in eight hours

We captured Sorry-worm execution on our infrastructure on 2026-05-01. Across an eight-hour window we observed two independent propagation events of the same SHA-256 binary, originating from two unrelated source IPs, both following the same SSH-exec session pattern:

  T+0    SCP push of /tmp/.sorry_<8 random alphanumeric chars>
  T+~3s  chmod +x /tmp/.sorry_<random>
  T+~5s  nohup /tmp/.sorry_<random> >/tmp/.sorry_<random2>.log 2>&1 &

Both events used the same exec template (chmod +x; nohup … &), the same drop directory (/tmp/), the same filename prefix (.sorry_), the same length of the random suffix (8 alphanumeric characters), and the same redirection pattern for stdout and stderr to a sibling unlinked log file. The differences were the two random suffixes (one per event) and the two source IPs.

Several observations follow.

Two unrelated relays, more consistent with autonomous worm propagation than with a single operator. The two source IPs are in unrelated address blocks, on different hosting providers, in different geographies. Two independent propagation events from unrelated IPs, separated by approximately seven hours, are more consistent with autonomous worm-style propagation through a pool of already-compromised SSH-accessible hosts than with a single interactive hands-on-keyboard session - though we acknowledge an operator with two relays and basic automation could in principle produce a similar pattern.

Pre-existing relay pool, not just-in-time conscription. For Sorry-worm to propagate from two unrelated relays within 8 hours of its first public sandbox submission, the operator either had a pre-established botnet ready to receive a new payload, or the worm’s auto-propagation reached small-scale effectiveness extremely quickly. Both interpretations point to an operator with prior SSH-bruteforce infrastructure that pre-dates this specific payload. This matters for defenders: the same relays are likely pushing other payloads to other targets.

Identical session template across both events. The byte-for-byte identical SSH exec template strongly suggests both relays were running the same SSH propagation module - almost certainly the SSH worm leg embedded in the Sorry-worm binary itself, which we describe in Part 2.

3. Session-level delivery evidence

In addition to the binary itself, our controlled SSH collection infrastructure captured session-level exec and SCP activity. The exec sequence for the second propagation event (drop #2 in §2) is reproducible to the second:

2026-05-01 07:20:27 UTC   scp -qt /tmp/.sorry_3yHQYnl1                    [push, 5.3 MB ELF inline]
2026-05-01 07:20:28 UTC   chmod +x /tmp/.sorry_3yHQYnl1
2026-05-01 07:20:32 UTC   nohup /tmp/.sorry_3yHQYnl1 >/tmp/.sorry_eCFWXSNX.log 2>&1 &

Each of the three lines is a separate SSH session - three distinct session identifiers - all originating from 18.175.33.238 within a five-second window. The SCP-pushed binary’s SHA-256 matches the running process’s /proc/<pid>/exe SHA-256 to the byte, providing cryptographic continuity from network-layer observation through to runtime artifact.

The same SHA-256 has appeared under different operational filenames depending on the observer:

The hash is stable, the names are contextual. A defender hunting on filename will miss it; a defender hunting on hash, on RSA pubkey fingerprint, or on the chmod-and-nohup command pattern will not.

For SOC teams, the practical takeaway is the chmod-and-nohup-into-/tmp pattern itself. Even when the binary self-deletes immediately after execution and disappears from the filesystem, the command line that created and launched it is observable in properly configured Linux audit, eBPF, EDR, or process-creation telemetry. Detection on the command pattern is robust to binary self-deletion. The Sigma rule is in Part 3 §5.1 .

This level of capture is the operational difference between low-interaction and high-interaction observation. The same SHA-256 has been observed by other honeypot infrastructure submitting the binary to public sandboxes, but those submissions provide the binary alone - not the operator-level command sequence: the exact SCP destination path, the chmod, the nohup invocation, the redirection target, the session-by-session timing.

After the second Sorry-worm execution at 07:20:34 UTC, our SSH-layer telemetry continued to record activity from a separate set of source IPs running unrelated post-compromise routines - eight Diicot/Opera-aligned KillerWorm cleaner cycles between 07:24 and 10:08 UTC, and a Multiverze sshd backdoor drop at 08:36 UTC. These adjacent campaigns are described in §4.

4. Concurrent activity on the same target - and why it is not Sorry

During the same window, the target host received SSH-exec traffic from a number of other source IPs running unrelated brute-force and post-compromise activity. We have separated this activity from Sorry-worm based on source IP, command pattern, and payload:

There is no IP overlap between any of these clusters. There is no shared pattern of orchestration: the Multiverze drops are themselves directed scans (the backdoor binary takes a 51-IP target list as argv), the Diicot/Opera cleaner runs a long anti-competition shell pipeline before installing its own miner, and the initial-stage actor is on an entirely different timeline (days earlier). The fact that all of these arrive on the same target host within a short window reflects how exposed an SSH-accessible Linux host is on the open internet today: multiple unrelated worms and brute-force campaigns will land on the same machine and operate concurrently without coordination.

Microsoft detects the Sorry-worm sample on VirusTotal as Ransom:Linux/Multiverze!rfn. We treat this as an automated umbrella-style classifier label around Linux SSH-bruteforce/ransomware behavior - the suffix !rfn indicates the verdict is generated by automated classification rather than analyst-assigned attribution - not as evidence that Sorry-worm shares code or operator identity with the long-running Multiverze sshd backdoor family that arrived on the same target from a different set of relays.

The Diicot/Opera-aligned loader pipeline is a separate matter and is treated in Part 3, where we cross-reference it against Wiz Threat Research’s December 2024 analysis and provide updated 2026 indicators (fresh C2 infrastructure, updated drop paths) compared to the prior coverage.

5. Geographic distribution

Across our threat-tracking infrastructure, which spans more than 20 countries, we observed scan and propagation activity associated with this campaign as well as the adjacent Multiverze and Diicot/Opera campaigns. Notable strikes related to Sorry-worm and adjacent worms hit our environments in Estonia, Germany, India, Malaysia, Taiwan, the United States, and Singapore, among others. We do not assess regional targeting: the SSH brute-force scan activity we associate with this campaign reaches a global address space, with target lists extracted from the Multiverze drops alone covering hundreds of IPs across continents.

We do not publish per-country breakdowns of victim or hit counts in this report. The point we want to make for defenders is the simpler one: any internet-exposed Linux host with SSH on port 22, anywhere in the world, is in scope for this activity right now. Two-factor authentication, public-key-only authentication, fail2ban-style brute-force throttling, and inbound rate limits are first-line measures regardless of geography.

6. Why this matters for defenders

A few takeaways from the campaign-level view, all of which are unpacked in detail in Part 2 and Part 3 :

• Encryption is not the last step. Sorry-worm encrypts files concurrently with active SSH propagation. Network-layer detection that waits until file encryption is observed will miss the propagation phase entirely.
• Filename-based detection works once. The .sorry extension on freshly modified files and the sorry_id_<digits>.sorry victim-ID name are strong post-encryption indicators. They fire after the damage is done. The earlier indicators to hunt for are described in Part 3.
• Generic auto-classifications can mislead triage. The Microsoft Multiverze!rfn label and the casual co-presence of long-running Multiverze instances on the same target make it easy to assume Sorry-worm is a Multiverze module. It is not. Treat them as separate campaigns until evidence demands otherwise.
• The relay pool is the real story. Each compromised SSH-accessible host that the worm reaches becomes part of the propagation surface. Hardening individual targets is necessary but not sufficient. Identifying and notifying compromised relays - particularly those in 45.156.87.0/24, 45.153.34.0/24, and the IPs listed above - is where the next round of attention needs to go.

7. Top-level network indicators

A small set of indicators, in order of operational confidence. Full IOCs in three confidence tiers, including filesystem patterns, RSA pubkey fingerprints, and YARA/Sigma rules, are in Part 3 .

Continue with Part 2 - Inside Sorry-worm for the binary analysis, or skip to Part 3 - Adjacent campaigns and the defender’s playbook for hunting rules and timelines.

References

• Triage / Recorded Future - Sample 260430-w1vvkact8m. https://tria.ge/260430-w1vvkact8m
• VirusTotal - File 2fc0a056…. https://www.virustotal.com/gui/file/2fc0a056fd4eff5d31d06c103af3298d711f33dbcd5d122cae30b571ac511e5a
• Microsoft - Multiverze family description (umbrella label observed on VirusTotal for this sample).
• pcrisk - Sorry Ransomware (Windows variant, 2018) - unrelated despite naming convention overlap. https://www.pcrisk.com/removal-guides/12528-sorry-ransomware

OHIIHO Research - Independent threat research. Contact: cyber@ohiiho.com .