Dota mdrfckr: One Family, Three Execution Programs
SSH client fingerprinting and cross-node behavioral analysis of 2,741 sessions across four geographically distributed honeypot nodes show that the dota_mdrfckr worm family contains three structurally distinct execution programs. Each uses a different SSH client, injects a different primary SSH key, and follows a different post-authentication playbook. Cross-program IP overlap on a dedicated VPS supports the conclusion that at least two of the three programs share infrastructure.
Why This Matters
Tracking dota_mdrfckr as a single behavioral unit, as most detection systems currently do, masks internal structure that matters operationally. If a worm family contains multiple programs with different SSH clients, different keys, and different behavioral depths, then a detection rule tuned to the dominant 20-command playbook may not match the 3-command fast-inject variant. Campaign tracking that aggregates all Dota sessions into one count loses the ability to see when one program is active and another is not.
Recognizing internal program structure within a worm family improves detection coverage, sharpens campaign tracking, and produces a more accurate picture of how the underlying infrastructure operates.
Observation Basis
Data was collected from four Cowrie-based SSH honeypot nodes in Germany, the United States, France, and Singapore, operating between March 14 and April 8, 2026. Each node runs a distinct persona (generic server, healthcare PACS gateway, AI/ML analytics platform, security operations). Authentication modes include both AuthRandom (node1-de) and UserDB (nodes 2-4).
Program classification uses three independent discriminators applied to each session:
- HASSH fingerprint - the SSH client key-exchange hash, identifying the SSH implementation used by the connecting bot
- SSH key injected - the public key written to
authorized_keysduring the session - Post-authentication command pattern - the sequence and depth of commands executed after login
A session is classified as belonging to a program when all three discriminators are consistent. The classification was validated by reading all available Cowrie JSON logs across all four nodes, including gzip-compressed historical rotations. HASSH correlation was verified per-session, not sampled.
Program A - Full Compromise Playbook
Program A is the dominant execution program documented in all prior NullRoute Dota research. It accounts for 97.6% of all classified sessions and represents the canonical dota_mdrfckr behavior: disable SSH directory protections, inject the mdrfckr SSH key, change the account password, probe CPU and memory resources, evict competing processes, establish cron-based persistence, and fingerprint the system.
Program A uses HASSH 03a80b21afa810682a776a7d42e5e6fb with 99.9%
consistency (2,673 of 2,675 sessions). Two sessions used rare alternative HASSH
values not seen in any other program, likely reflecting minor SSH client
configuration variants rather than a different program.
Program A is present on node1-de (2,583 sessions, 1,403 IPs) and node3-fr (92 sessions, 52 IPs). It is absent from node2-us and node4-sg across the entire observation window.
Program B - Fast Inject
Program B executes a compact 3-command sequence built around a single compound shell statement. It is structurally different from Program A in every measurable dimension.
The compound structure is distinctive: architecture detection, CPU count, password
change, and SSH key injection are all packed into a single shell command. Steps 2
and 3 repeat the uname -m and nproc probes as standalone
commands, likely as fallbacks in case the inline variable assignments fail. There is
no reconnaissance, no competitor eviction, no persistence check, and no payload download.
Program B uses a different SSH key from Program A. It also embeds the password
change within the compound command, making it invisible to per-command atom
classifiers that expect passwd as a standalone step.
HASSH 0a07365cc01fa9fc82608ba4019af499 correlates at 100% (35 of
35 sessions). No Program A session has ever used this fingerprint, and no
Program B session has ever used Program A's fingerprint.
Program B operates exclusively on node2-us (28 sessions, 6 IPs) and node3-fr (7 sessions, 2 IPs). It has never appeared on node1-de, where Program A dominates. This non-overlapping primary node distribution is one of the more distinctive structural features of the three-program model.
Activity spans March 24 to April 8, 2026. A dense initial burst (26 sessions in 4 days, March 24-27 on node2-us) is followed by sporadic activity on node3-fr and then a resurgence on both nodes in early April after a 7-day quiet period. Seven distinct source IPs were observed, all hosted on OVH infrastructure.
Program C - Lightweight Key Injection
Program C is the smallest and most constrained of the three programs. Every session executes exactly one command, terminates immediately, and originates from one of only two source IPs.
The command references clean.sh and setup.sh scripts,
executes them, then deletes them. It then injects an SSH key and exits. No password
change. No reconnaissance. No persistence. No competitor eviction. The entire
session is a single-purpose key installation.
HASSH 5f904648ee8964bef0e8834012e26003 correlates at 100% (31 of
31 sessions). This fingerprint does not appear in any Program A or Program B session.
Program C is the only program observed on all four nodes: node1-de (14 sessions), node3-fr (12), node4-sg (3), and node2-us (2). It operates from exactly two source IPs (130.12.180.x and 213.209.159.x), both of which have been observed across the full observation window. Neither IP has ever executed Program A or Program B.
The observed timeline shows node1-de first (March 14), then node2-us and node3-fr (March 26), then node4-sg (April 1). This cross-node spread, combined with the dedicated source IPs and single-purpose behavior, is structurally consistent with a staging or key-preparation function. However, because our honeypot sensors do not log public-key authentication events, we cannot confirm whether the injected keys are subsequently used for follow-on access. This interpretation remains a structural observation, not a confirmed operational sequence.
Three SSH Clients, One Family
The strongest evidence for three distinct programs is the HASSH fingerprint separation. HASSH captures the SSH key-exchange algorithm negotiation, which identifies the SSH client implementation. Three different HASSH values map to three different behavioral patterns with near-perfect correlation:
| HASSH | Program | Sessions | Match Rate |
|---|---|---|---|
03a80b21...e5e6fb |
A | 2,673 | 99.9% |
0a07365c...af499 |
B | 35 | 100% |
5f904648...26003 |
C | 31 | 100% |
There is zero HASSH crossover between programs. No session classified as Program B or C uses Program A's HASSH, and vice versa. The two outlier sessions in Program A use rare HASSH values not seen in any other program. This means the three programs use three different SSH client implementations, and this distinction holds across all four nodes and the full observation window.
In this dataset, HASSH fingerprinting alone was sufficient to classify Dota sessions into their respective programs before any post-authentication behavior was observed. For defenders operating SSH honeypots with HASSH logging enabled, this provides an early pre-behavioral signal for program identification.
Shared Infrastructure Evidence
Cross-program IP overlap provides direct evidence that at least Programs A and B operate from shared infrastructure.
IP 148.113.204.x executes:
- Program A on node1-de: 2 sessions (March 15 and 17), 20
commands each, HASSH
03a80b21... - Program B on node2-us: 9 sessions (March 25, rapid burst
over 24 minutes), 3 commands each, HASSH
0a07365c... - Program B on node3-fr: 1 session (March 28), 3 commands,
HASSH
0a07365c...
The same host connected using two different SSH clients, executed two different
behavioral programs, and was observed on different nodes with each. AbuseIPDB identifies this IP as
a dedicated OVH VPS (vps-6cf7124c.vps.ovh.ca), not a shared proxy,
VPN exit, or Tor relay. The other Program B source IPs are also dedicated OVH
VPSes, suggesting a fleet of rented servers.
What this supports and what it does not: A single rented server running both Program A and Program B supports the conclusion that these programs share infrastructure. It does not, by itself, prove that a single operator controls both programs, or that the programs are deliberately coordinated. Multiple bot components can be co-deployed to the same server fleet without requiring a unified control plane. We describe this as shared infrastructure, not shared control.
No cross-program IP overlap exists between Programs A and C, or between Programs B and C. Program C's two dedicated source IPs have never executed any other Dota program. This absence does not refute shared infrastructure for C, but it means the evidence for infrastructure sharing is currently limited to the A-B pair.
What Is Strong, What Remains Uncertain
| Finding | Evidence | Confidence |
|---|---|---|
| Three structurally distinct programs within dota_mdrfckr | 2,741 sessions, three HASSH values, three keys, three behavioral patterns | Strong |
| Each program uses a different SSH client | 99.9-100% HASSH correlation, zero crossover | Strong |
| Programs A and B share infrastructure | Dedicated OVH VPS runs both programs on different nodes | Strong |
| Non-overlapping primary node distribution | Program A: node1 + node3. Program B: node2 + node3. No A on node2. | Strong |
| Program C operates as a staging or key-preparation layer | Structurally consistent (pure key injection, dedicated IPs, all-node reach) | Structural inference only |
| Task division between programs is intentional / coordinated | Shared infrastructure supports but does not require coordination | Uncertain |
| Program C's keys are used by subsequent programs | Cannot be confirmed; Cowrie does not log public-key authentication | Not observable |
Detection and Operational Implications
For defenders and detection engineers, the three-program model has practical consequences:
- Detection coverage: Rules tuned to Program A's 20-command playbook (the dominant documented behavior) may not match Program B's 3-command compound inject or Program C's single-command key injection. SSH-layer HASSH matching can provide an early signal for all three programs before any commands are executed.
- Campaign tracking: Aggregating all Dota sessions into a single count hides program-level activity patterns. Program B's intermittent bursts and Program C's cross-node spread become visible only when sessions are classified by program.
- Infrastructure analysis: The non-overlapping primary node distribution (A absent from node2, B absent from node1) may reflect credential-surface differences, network-level factors, or other causes not visible in session data. Defenders seeing only the fast-inject variant may not realize the full playbook variant operates on other targets.
- Key management: Each program injects a different SSH key.
Incident responders checking
authorized_keysfor the documented mdrfckr key may miss backdoors planted by Programs B and C, which use different keys.
Limitations
Single platform: All observations come from Cowrie, a medium-interaction SSH honeypot. Cowrie's command emulation determines which commands succeed or fail, which may influence post-authentication session depth. However, the HASSH and SSH key evidence are independent of command emulation, as they are captured before any commands are executed.
No public-key auth visibility: Cowrie logs password-based authentication but does not record public-key authentication events. This means we cannot determine whether the SSH keys injected by any program are subsequently used for follow-on access. The Program C staging hypothesis, while structurally consistent, cannot be confirmed or denied from available sensor data.
Sample size asymmetry: Program A (2,675 sessions) is well-sampled. Programs B (35 sessions) and C (31 sessions) are structurally unambiguous but represent small absolute counts. Their HASSH correlation is perfect, but the small sample means rare edge cases may not yet be visible.
External validation: The three-program structure has not been independently reported by other honeypot operators or threat intelligence sources. Confirmation from deployments with different configurations, credential surfaces, and network locations would strengthen the model.
Conclusion
What is tracked as a single SSH worm family, dota_mdrfckr, contains at least three structurally distinct execution programs. Each uses a different SSH client implementation, injects a different primary SSH key, and follows a different post-authentication behavioral pattern. The programs show non-overlapping primary node distributions and, in the case of Programs A and B, were observed sharing infrastructure.
The implication for detection is direct: a single signature or behavioral rule based on Program A's 20-command playbook may not catch the fast-inject or key-injection variants. The implication for campaign tracking is equally clear: a monolithic count masks operationally meaningful program-level structure.
Whether the three programs represent coordinated task division, independently scheduled tools from the same infrastructure, or a more complex operational arrangement remains an open question. The data shows shared infrastructure and structural separation. It does not show the operator's intent.