Adjacent campaigns and a defender's playbook [3/3]

Series navigation

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

This third part of the series is the operational follow-up. We covered the campaign-level discovery context in Part 1 and the binary-level analysis of the Sorry-worm sample itself in Part 2 . What follows is the material a SOC, MSSP, or detection-engineering team needs to put hunts in production: the adjacent campaigns running on the same target hosts that defenders will need to disambiguate from Sorry-worm, indicators in three confidence tiers, YARA and Sigma rules, hunting queries, a reproducible activity timeline, and defensive recommendations.

1. Adjacent campaigns observed alongside Sorry-worm

Part 1, §4 established that Sorry-worm propagation events sit alongside three other unrelated campaigns on the same target, with no IP overlap between any of them. We expand on each here so defenders can cleanly separate them in their own telemetry.

1.1 Multiverze sshd backdoor family

The Multiverze SSH-bruteforce backdoor toolkit is a long-standing Linux malware family in circulation since at least 2022. Microsoft labels variants of this family under its Multiverze umbrella (e.g. Trojan:Linux/Multiverze), with multiple builds observed under that umbrella over the years. The reference binary we observed corresponds to SHA-256 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00 - first seen on VirusTotal on 2022-04-20 with over a thousand submissions across multiple years and current detection at 45 / 75. This is mature, well-documented malware.

What is operationally significant about Multiverze in our observation is not the binary itself but the deployment pattern:

• The backdoor is dropped to ~/.<16-to-19 random digits>/sshd. The randomized digit-only directory name acts as a planque that is unobtrusive in ls -la and is generated freshly on each drop.
• The backdoor is itself a directed SSH scanner: it is launched with a target IP list passed via argv. We observed four drops in a four-hour window, each with a fresh 51-IP target list, totaling 198 unique target IPs across the four lists. The lists are disjoint, suggesting the operator pushes target batches of 51 IPs as fresh propagation tasks.
• No IP overlap with Sorry-worm: the seven Multiverze drop source IPs we recorded are entirely separate from the two Sorry-worm propagation relays. We assess this as evidence of unrelated operators or unrelated propagation pools, not a single coordinated operation.
• Persistence via ~/.ssh/authorized_keys: in adjacent sessions during the same window we observed installation of an SSH public key labeled rsa-key-20230629. This is a generic PuTTYgen-style export label, but the specific public key is, in our telemetry, consistently used by this operator class. Defenders observing a key labeled rsa-key-20230629 in ~/.ssh/authorized_keys on an unexpected account should treat it as a high-priority finding.

1.2 Diicot/Opera updated build (KillerWorm cleaner cluster)

The shell pipeline used by the cleaner cluster we observed is a near-exact match for the Diicot/Opera Linux loader documented in December 2024 by Wiz Threat Research , and corroborated by Darktrace , Hackread , and CSO Online . Diicot is a Romanian-speaking threat actor group that operates an SSH-bruteforce-driven Linux loader, drops an XMR miner (“Opera”), and runs a small Mirai-derived DDoS botnet alongside.

Our observation is consistent with an updated 2026 build of the same campaign:

• Same anti-competition cleanup behavior described by Wiz: crontab -r, chattr -iae ~/.ssh/authorized_keys, removal of /dev/shm/.x and /dev/shm/rete* and /var/tmp/payload and /tmp/.diicot and /tmp/kuak, pkill xmrig, pkill cnrig, killall xmrig cnrig, plus a ps aux | awk '$3 > 40.0 && $11 !~ /sshd/' filter that kills any non-sshd process consuming more than 40% CPU.
• Same orchestration pattern: a cleaner script, then a drop, then a chmod, then an execution, then history -c and rm -rf .bash_history.
• Different drop path compared to the prior reporting: where Wiz documented /var/tmp/Documents/.diicot, we observed the loader staged at /tmp/cache (an UPX-packed ELF with VirusTotal label vsnta826, ~31/75 detection).
• Different C2 infrastructure: the prior reporting referenced 2024-vintage C2 IPs (87.120.116.35, 80.76.51.5, 91.92.250.6). We observed the current campaign reaching out to 5.189.149.171:80 (Stage 1, ~181 flows) and then transitioning to 64.89.161.144:28816 (Stage 2, ~88 flows, atypical destination port with token-style URL paths).
• Cleaner source IPs: 45.156.87.69, 45.156.87.204, 45.156.87.253, 45.153.34.71. The clustering inside 45.156.87.0/24 and 45.153.34.0/24 is consistent with a multiplexed operator on bulletproof hosting.

We do not duplicate the prior reporting on Diicot/Opera here; readers who want the full background should start with the Wiz analysis . Our contribution is fresh 2026 indicators for an actively-running variant of the same campaign.

1.3 Mirai-derived sshscan kit and magicPussy variants

Independently from Sorry-worm and from Multiverze, we observed a Mirai-derived multi-architecture SSH scanner kit on the same target. The kit ships seven architectures of a binary named ScBr_<arch> (x86_64, i586, larm, mips, mips64, mipsel, powerpc, plus an armv4l stub described separately below), alongside two variants named magicPussySon (32-bit) and magicPussyMommy (64-bit). The binaries match VirusTotal labels in the mirai, sshscan, gafgyt, and pyvol families with detection ranging from 34 / 75 to 41 / 75.

The runtime behavior includes a prctl(PR_SET_NAME) rename that reports the process under bracketed names like [syystytt] or [soololss], mimicking kernel threads. A ps -e listing on a host where this kit is running will show what looks like an unusual kernel thread - but the parent PID will not be kthreadd (PID 2). A Sigma rule for this pattern is in §6.3 .

1.4 Low-detection adjacent samples worth attention

Several of the adjacent samples we collected are noteworthy for being not detected at the time of analysis, despite living on the same compromised infrastructure as the well-detected Multiverze and Mirai binaries:

• Mirai stub ScBr_armv4l at 8 KB, SHA-256 b9b7bc26ebeef8ddce35c15aa9a966fe924434a5753d69e6bfa7e4aa6f3a25ad, VirusTotal: unknown. This stub uses the same filename as the 1.3 MB ScBr_armv4l variant - a deliberate confusion of triage tooling that name-matches the well-known sample. The 8 KB version is likely a stage-0 dropper that fetches the full kit in a second step.
• Stub of 348 bytes, SHA-256 f74a8b06db4f8f48f4a19ea5c01bade2a0dfb9290c4ed04a3f1a3eaa298a843d, VirusTotal: 0 / 76, in circulation since at least 2026-03-02. Two months of free circulation across multiple incident corpora without a single detection. We have not characterized this binary further. It is the smallest fully-formed ELF in our corpus.
• zsvc, 449 KB, SHA-256 2746f15888ea58f46ffd2f44b2b4de69e974cc2f8a46becf00e047efe938e077, VirusTotal: unknown. An ELF named to mimic a systemd service. We have not characterized it further. The size and lack of detection make it a candidate for reverse-engineering attention.
• A 42-byte tracker file observed at /tmp/.<8 random lowercase chars> (path varies per host). Contents are exactly <PID>\n<path-to-payload>. The format is too small to be a malware sample in its own right, but the pattern - a tiny path-to-PID-mapping file in /tmp - appears to be a worm-family bookkeeping artifact. Family attribution in our observation maps to a Multiverze sshd backdoor PID rather than to the Sorry-worm process; we report it here as adjacent infrastructure rather than as a Sorry-worm runtime artifact. Defenders running filesystem hunts can match on the size (≤ 64 bytes), the location, the dot-prefixed name, and the two-line <digits>\n<path> format.

These four artifacts collectively make a defensive case: detection lag is real, and adjacency to known malware is not a substitute for behavioral hunting.

2. Indicators in three confidence tiers

We split indicators into three operational tiers. Confirmed indicators are observed directly in our analysis and tied to specific Sorry-worm or adjacent runtime artifacts. Associated indicators are tied to the same activity set on the basis of co-occurrence, identical orchestration patterns, or shared infrastructure ranges. Pivot-only indicators are useful for hunting and enrichment but are not, on their own, sufficient to call a host compromised.

2.1 Confirmed indicators

2.2 Associated indicators

2.3 Pivot-only indicators

3. Hunting logic

The hunts below are written in product-neutral terms and adapted to Sigma where applicable. Adapt to your SIEM (Splunk SPL, Elastic KQL, KQL/Defender, etc.) - the patterns are intentionally simple.

3.1 Process and command-line hunts

Sorry-worm execution sequence:

process.command_line contains '/tmp/.sorry_'
AND process.command_line contains 'nohup'
AND process.command_line contains '.log 2>&1'

Diicot/Opera anti-competition cleanup:

process.command_line contains 'crontab -r'
AND process.command_line contains 'chattr'
AND process.command_line contains '/dev/shm'

Diicot/Opera high-CPU competitor kill:

process.command_line contains 'ps aux'
AND process.command_line contains '$3 > 40.0'
AND process.command_line contains 'kill -9'
AND process.command_line contains 'sshd'

Loader fetch with triple fallback (curl → wget → bash /dev/tcp):

process.command_line contains 'curl -sSL'
AND process.command_line contains '|| wget'
AND process.command_line contains '/dev/tcp/'

3.2 Filesystem hunts

Sorry-worm post-execution markers:

find / -path /proc -prune -o \( \
       -name '.sorry_exist' -size 0 \
    -o -name '*.sorry' \
    -o -name 'sorry_id_*.sorry' \
    -o -name 'Sorry.lock' \
\) -print 2>/dev/null

Multiverze planque:

find /home /root -maxdepth 2 -type d -regex '.*/\.[0-9]\{16,19\}$' 2>/dev/null

Tracker file pattern (42 bytes, two-line <PID>\n<path> format):

find /tmp -maxdepth 1 -type f -size -64c -name '.*' \
  -exec sh -c 'awk "NR==1{exit !(/^[0-9]+$/)} NR==2{exit !(/^\//)} END{exit NR!=2}" "$1" && echo "$1"' _ {} \;

3.3 Network hunts

• Connections to 5.189.149.171:80 with URI /f/x86_64/.16 or other path under /f/ → loader fetch, Diicot/Opera updated build.
• Connections to 64.89.161.144:28816 with token-style URI → Diicot/Opera Stage 2.
• High-volume outbound TCP/22 from a single PID, where the PID’s executable path resolves to a deleted file under /tmp/.sorry_* → Sorry-worm SSH propagation in flight.
• Authorization log entries matching [+] SUCCESS <ip>:<port> user=<user> pass=<pass> - this is the Sorry-worm SSH-success log line; on a host where it appears in syslog or any process logs, the host is running Sorry-worm.

4. YARA - Sorry-worm encrypted file prefix

rule SorryWorm_EncryptedFile_48byte_Prefix : ohiiho sorry_worm encrypted_file
{
    meta:
        author      = "OHIIHO Research"
        date        = "2026-05-01"
        description = "Detects files encrypted by Sorry-worm based on the 48-byte fixed prefix consistent across all encrypted artifacts observed for this campaign. The prefix corresponds to a fragment of the operator's hardcoded RSA-2048 public key formatted as an OpenPGP Public-Key Packet header."
        sample_sha256       = "2fc0a056fd4eff5d31d06c103af3298d711f33dbcd5d122cae30b571ac511e5a"
        rsa_pubkey_sha256   = "02cffd86bcfae828ca5cdea65b794a47079f49cc52c72b32570ed5abff24fd99"
        prefix_sha256       = "5bfbdd128ceef2d6820897f1af9cc4060e9c53cd5042dc4b3cf6de0a9f58af82"
        reference           = "https://research.ohiiho.com/part-2-sorry-worm-anatomy"
        license             = "CC0-1.0"

    strings:
        $prefix = {
            99 00 00 08 00 6D 02 1B C7 93 E1 23 D5 AF 31 12
            E8 32 C3 DE 6D 40 D1 0E 1A 57 1C DE DF 93 E7 8E
            CA D8 03 E6 56 FE 9F 9F 92 E6 43 0B 1C 12 F6 F0
        }

    condition:
        $prefix at 0
}

A complementary YARA rule to detect the binary itself, by string indicators:

rule SorryWorm_Binary_StringIndicators : ohiiho sorry_worm linux ransomware
{
    meta:
        author      = "OHIIHO Research"
        date        = "2026-05-01"
        description = "Detects the Sorry-worm Linux ransomware-worm hybrid binary by characteristic strings."
        sample_sha256 = "2fc0a056fd4eff5d31d06c103af3298d711f33dbcd5d122cae30b571ac511e5a"
        reference   = "https://research.ohiiho.com/part-2-sorry-worm-anatomy"
        license     = "CC0-1.0"

    strings:
        $sorry_id_str   = "Sorry-ID" ascii
        $qtox_repo      = "github.com/qTox/qTox" ascii
        $taobao_str     = "taobao.com" ascii
        $marker_lock    = "/tmp/Sorry.lock" ascii
        $marker_exist   = "/tmp/.sorry_exist" ascii
        $marker_id_pfx  = "sorry_id_" ascii
        $log_template   = ".sorry_%s.log" ascii
        $err_killdb     = "error killing database processes" ascii
        $ssh_success    = "[+] SUCCESS %s:%d user=%s pass=%s" ascii

    condition:
        uint32(0) == 0x464C457F
        and filesize > 4MB and filesize < 8MB
        and 5 of them
}

5. Sigma rules

5.1 Sigma rule 1 - Sorry-worm exec sequence

title: Sorry-worm Linux Ransomware Drop and Exec
id: 26cf8fb9-340a-455f-b9a0-cf6fd4b6aef2
status: experimental
description: |
    Detects the SCP push, chmod +x, and nohup execution sequence used by the
    Sorry-worm Linux ransomware-worm hybrid, dropping into /tmp with a
    .sorry_<8 random> prefix and redirecting stdout/stderr to a sibling .log file.
references:
    - https://research.ohiiho.com/part-1-catching-sorry-worm
    - https://research.ohiiho.com/part-2-sorry-worm-anatomy
author: OHIIHO Research
date: 2026-05-01
logsource:
    product: linux
    category: process_creation
detection:
    drop_path:
        CommandLine|contains: '/tmp/.sorry_'
    nohup_redirect:
        CommandLine|contains|all:
            - 'nohup'
            - '.log 2>&1'
    chmod_drop:
        CommandLine|contains|all:
            - 'chmod +x'
            - '/tmp/.sorry_'
    condition: drop_path and (nohup_redirect or chmod_drop)
falsepositives:
    - The /tmp/.sorry_ prefix is highly specific. Legitimate use cases are not expected.
level: critical
tags:
    - attack.execution
    - attack.t1059.004
    - attack.impact
    - attack.t1486

5.2 Sigma rule 2 - Diicot/Opera anti-competition cleanup pipeline

title: Diicot/Opera Linux Loader Anti-Competition Cleanup
id: a28ee454-6b2c-43c2-a16b-a27b8efe668c
status: experimental
description: |
    Detects shell pipelines characteristic of the Diicot/Opera Linux loader,
    including crontab removal, chattr reset on authorized_keys, /dev/shm
    cleanup, removal of competitor artifact paths, and high-CPU process killing
    excluding sshd.
references:
    - https://research.ohiiho.com/part-3-adjacent-campaigns-defender-playbook
    - https://www.wiz.io/blog/diicot-threat-group-malware-campaign
author: OHIIHO Research
date: 2026-05-01
logsource:
    product: linux
    category: process_creation
detection:
    base:
        CommandLine|contains|all:
            - 'crontab -r'
            - 'chattr'
            - '/dev/shm'
    competitor_paths:
        CommandLine|contains:
            - '/tmp/.diicot'
            - '/tmp/kuak'
            - '/dev/shm/rete'
            - '/dev/shm/.x'
    high_cpu_kill:
        CommandLine|contains|all:
            - 'ps aux'
            - 'kill -9'
            - 'sshd'
    condition: base and (competitor_paths or high_cpu_kill)
falsepositives:
    - System administrators running ad-hoc cleanup pipelines are
      unlikely to combine all three patterns.
level: high
tags:
    - attack.execution
    - attack.t1059.004
    - attack.defense_evasion

5.3 Sigma rule 3 - Mirai bracketed comm rename

title: Linux process comm renamed to bracketed kernel-thread mimicry
id: a7adc4e8-33dd-4dbe-92f4-c7b25bb55764
status: experimental
description: |
    Detects user-space processes whose comm field has been renamed via
    prctl(PR_SET_NAME) to a bracketed pseudo-random string (e.g. [syystytt],
    [soololss]), mimicking kernel threads, but whose parent PID is not
    kthreadd (PID 2). Mirai-derived sshscan kits use this pattern to confuse
    process listing during triage.

    Field names vary by Linux telemetry source. Map ProcessName to comm /
    proc.name / process.name depending on auditd, eBPF, osquery, Sysmon for
    Linux, or your EDR's schema before deployment.
references:
    - https://research.ohiiho.com/part-3-adjacent-campaigns-defender-playbook
author: OHIIHO Research
date: 2026-05-01
logsource:
    product: linux
    category: process_creation
detection:
    bracketed_process_name:
        ProcessName|re: '^\[[a-z]{6,12}\]$'
    not_kthreadd:
        ParentProcessId: 2
    condition: bracketed_process_name and not not_kthreadd
falsepositives:
    - True kernel threads with PPID 2; expected to be filtered by the
      not_kthreadd clause but verify in your environment.
    - Field-mapping mismatches will silently produce zero matches;
      verify the ProcessName field maps to comm in your telemetry pipeline.
level: medium
tags:
    - attack.defense_evasion
    - attack.t1036.005

6. Reproducible activity timeline

The timeline below reproduces the observable activity of the Sorry-worm and adjacent campaigns on a single target across approximately five days. Times are UTC. J denotes the day Sorry-worm executed; earlier days are J-1, J-2, etc. The pattern is intended to be searchable in a SIEM dataset where the source IPs are known.

7. Defensive recommendations

The recommendations below assume an SSH-accessible Linux fleet and a SOC with reasonable visibility into process creation and outbound network flows. They are ordered from “do today” to “review and prioritize”.

1. Block, alert, and review traffic to:

• 5.189.149.171:80
• 64.89.161.144:28816
• The seven Multiverze drop relays listed in §2.2
• The two Sorry-worm propagation relays 103.131.95.37 and 18.175.33.238

2. Hunt for Sorry-worm post-execution markers:

• /tmp/.sorry_exist (zero-byte file, unique path)
• *.sorry files in user data
• sorry_id_<19 digits>.sorry in any user home
• /tmp/Sorry.lock if not yet unlinked

3. Add the YARA rules from §4 to your file-scanning pipeline. The 48-byte prefix rule is high-precision and cheap; the string-based rule is broader and may trigger on memory-resident copies of the binary on actively running hosts.
4. Add the Sigma rules from §5 to your SIEM. The Sorry-worm exec rule is high-precision (the /tmp/.sorry_ path is highly specific). The Diicot/Opera cleanup rule may trigger on legitimate cleanup pipelines; tune the conjunction in your environment.
5. Authorize SSH only with public-key authentication and disable password authentication on internet-exposed Linux hosts. The 123456, ubuntu, deploy, tomcat, and qwerty passwords listed in the embedded wordlist (Part 2 §9) cover a large fraction of weak-password successes.
6. Block or rate-limit inbound TCP/22 at the network edge for hosts that do not need to be SSH-reachable from the internet. The 198 unique IPs in the captured Multiverze target lists indicate that these brute-force operations are reaching a wide address space.
7. Audit ~/.ssh/authorized_keys on every host for unexpected entries. Treat any key labeled rsa-key-20230629 as an indicator of compromise warranting immediate investigation.
8. Monitor /proc for processes whose exe symlink resolves to a deleted path under /tmp/. This catches Sorry-worm at runtime, before encryption completes, and is also a reliable indicator for many other unlink-after-exec malware families.
9. Notify abuse contacts for compromised relays where you have a confirmed observation. The Sorry-worm propagation pool is small enough today that proactive notification can plausibly affect propagation; tomorrow it may not be.

8. About OHIIHO Research

OHIIHO Research tracks targeted threat campaigns and APT-grade attackers through high-intensity, intelligence-grade honeypot infrastructure worldwide. We publish defensive indicators, behavioral analysis, and campaign write-ups based on activity observed live in our own environments.

We do not publish live samples, operator TOX addresses, embedded RSA public keys in cleartext, or per-victim material derived from observed attacks. We welcome inbound indicator submissions, vendor cross-checks, and CERT-channel exchanges under coordinated-sharing arrangements.

Contact: cyber@ohiiho.com

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
• Wiz Threat Research - Unpacking the Diicot Malware Targeting Linux Environments (December 2024). https://www.wiz.io/blog/diicot-threat-group-malware-campaign
• Darktrace - Tracking Diicot: An Emerging Romanian Threat Actor. https://www.darktrace.com/blog/tracking-diicot-an-emerging-romanian-threat-actor
• CSO Online - Romanian cybercrime gang Diicot builds DDoS botnet with Mirai variant. https://www.csoonline.com/article/641583/romanian-cybercrime-gang-diicot-builds-ddos-botnet-with-mirai-variant.html
• Hackread - New Diicot Threat Group Targets SSH Servers with Brute-Force Malware. https://hackread.com/diicot-hackers-ssh-servers-brute-force-malware/
• CIRCL - hashlookup service.

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