Dota mdrfckr: Two Bot Pools, Coordinated Timing
A behavioral analysis across seven days of attack data shows that Dota mdrfckr appears to operate through two largely IP-segregated bot pools. On two clean observation days, Stage 2 begins approximately 50 seconds after Stage 1 completes - a timing pattern consistent with centralized coordination.
Background
In UPD-1 we documented a two-stage kill chain operating within individual sessions: a fast Stage 1 (SSH key injection, <3 commands, under 10 seconds) followed by a brief gap and then a full Stage 2 deployment (20–28 commands, CPU recon, payload download, miner launch). The median within-session gap was 2.9 seconds.
What remained unanswered: are the IPs executing Stage 1 and Stage 2 the same infrastructure, or distinct bot pools? And does the two-stage sequence hold at campaign scale - across hours and days - not just within a single session?
Seven days of session data from node1-de (Germany) answer both questions.
Two Functionally Distinct Bot Pools
Every session executed by Dota mdrfckr falls into one of two behavioral profiles, distinguishable by command count and atom composition:
The two pools share zero IP addresses on clean observation days. On noisier days (higher raw volume), overlap is at most 1–2 IPs out of 80–180 total - consistent with measurement noise rather than shared infrastructure.
| Date | Pool A (S1) IPs | Pool B (S2) IPs | Overlap | Separated? |
|---|---|---|---|---|
| Mar 24 | 22 | 80 | 1 | ~1.2% |
| Mar 25 | 35 | 19 | 1 | ~1.8% |
| Mar 26 | 159 | 59 | 2 | ~0.9% |
| Mar 27 | No worm activity observed | |||
| Mar 28 | 0 | 13 | 0 | Yes |
| Mar 29 | 1 | 49 | 0 | Yes |
| Mar 30 | 3 | 70 | 0 | Yes |
| Mar 31 | 12 | 48 | 0 | Yes |
The IP separation is not a daily artifact - it holds across every day with sufficient data. Dota mdrfckr appears to operate through two largely distinct infrastructure pools for key injection and payload deployment. On clean days the separation is complete; the small overlap on Mar 24–26 (1–2 IPs out of 80–180 total) may reflect measurement noise or incidental shared scanning infrastructure rather than structural overlap.
The 50-Second Synchronization Gap
On days where the temporal boundary is unambiguous - where all Stage 1 activity completes before Stage 2 begins - a consistent timing signature emerges.
Two clean examples, observed on separate days with independent IP sets:
March 29, 2026
March 31, 2026
On March 29, Pool A ran exactly one session - a single IP at 01:10:24. Pool B activated 54 seconds later. On March 31, Pool A ran 12 sessions over two hours, with the final injection at 02:21:38. Pool B activated 47 seconds after the last injection completed. In both cases, Stage 2 begins only after Stage 1 is entirely finished. The repeated short gap is notable, though the clean-day sample remains small (n=2 independent observations).
What This Implies About the C2
A ~50-second gap between two infrastructure pools, observed on two independent days with zero IP overlap, is consistent with a coordination mechanism. One interpretation: Pool A bots signal task completion to a central node, which then dispatches Pool B. Other mechanisms - shared scheduling, coordinated polling intervals, an external trigger - cannot be ruled out from timing data alone.
The 50-second window is consistent with a lightweight acknowledgment loop: Pool A bot completes injection → reports to C2 → C2 evaluates readiness → dispatches Pool B.
This also connects to a finding from UPD-1: within individual sessions, Stage 1 and Stage 2 appeared to share the same Cowrie session (2.9s within-session gap). The campaign-level view operates at a different scale: Pool B bots are not waiting for a single Pool A session to end - they appear to wait for Pool A's entire wave to complete before activating. The two observations are consistent with a coordinated two-pool architecture, though they reflect different levels of the same campaign.
Pool A Command Signature
Across all Stage 1 sessions in the 7-day window, Pool A executes exactly two commands with no variation in content - only the SSH public key string changes between observed variants:
No reconnaissance. No CPU probe. No download. The session terminates immediately after key injection. Pool A bots are purpose-built for a single task: establish an SSH backdoor via key injection.
Note on Cowrie behavior and causal claims: Two inferences carry uncertainty. First, Pool B's authentication via Pool A's injected key cannot be confirmed in a Cowrie AuthRandom environment - any credential succeeds. Second, the timing correlation between pools is consistent with C2 coordination but does not prove it; the clean-day sample is small (n=2), and alternative synchronization mechanisms cannot be excluded. What is directly confirmed: two structurally distinct pools, near-complete IP separation across seven days, and a consistent sub-60-second ordering on the days measured.
Summary of Findings
| Finding | Evidence | Confidence |
|---|---|---|
| Two structurally distinct bot pools | 0 IP overlap on 5/7 days, <2% on remaining days | Strong |
| Pool A executes only SSH key injection (2 cmds) | Consistent across all 178 Stage 1 IPs, zero deviation | Strong |
| Pool B activates only after Pool A completes (on clean days) | Stage 2 absent on all hours where Stage 1 is active | Strong |
| ~50-second synchronization gap | 54s (Mar 29), 48s (Mar 31) - two independent observations | Moderate (n=2 clean days) |
| C2-coordinated dispatch | Inferred from timing; C2 infrastructure not directly observed | Inferred |
Combined with ERR-1 (randomized passwords per session) and UPD-1 (identical playbook across geographically distributed nodes), this finding sharpens the behavioral picture: Dota mdrfckr shows strong evidence of functional role separation and coordinated multi-pool behavior consistent with centralized or shared dispatch logic. The evidence does not, on its own, prove a single C2 node - but taken together, the randomized credentials, cross-node playbook consistency, IP-segregated pools, and repeated timing signature are difficult to reconcile with a simple self-propagating worm.
Methodology
Sessions were extracted from node1-de (T-Pot Cowrie, AuthRandom 1/1/10) across 7 consecutive
daily log files (March 24–31, 2026). Stage 1 sessions were identified as authenticated Cowrie
sessions containing only chattr/rm -rf .ssh/authorized_keys
atoms with no CPU reconnaissance or download activity. Stage 2 sessions were identified by the
presence of cpuinfo, /var/tmp/dota, or kill atoms and
command count >5. Classification used the NullRoute Behavioral Genome Framework v0.1
(fingerprint engine + atom extraction). Raw session counts were validated manually on the two
clean days presented in the timeline section.
The dataset reflects a single sensor node. Cross-node confirmation of the two-pool structure awaits accumulation of authenticated sessions on node2-us and node3-fr, where current UserDB auth prevents Dota logins (supporting the cross-persona asymmetry documented in UPD-1).