Dota SSH Worm: Corrected Credential Model

Correction to Investigation #1: 98% of SSH Intrusions Come from One Worm. We incorrectly reported 345gs5662d34 as the credential Dota sets and reuses on infected hosts.

What we got wrong

This erratum corrects a factual error in our original analysis: we incorrectly reported 345gs5662d34 as the credential Dota sets and later reuses on infected hosts.

In the original investigation we observed IPs that first appeared as TESTER sessions (using 345gs5662d34) and later returned as WORM sessions. We inferred that Dota used 345gs5662d34 as its infection credential. We relied on session-level correlation before completing payload-level re-analysis. That was a mistake.

Re-analysis of 241 decoded base64 payloads showed the earlier claim was incorrect. Dota never uses 345gs5662d34 for initial infection. Initial access is standard weak-password brute-force. The unique random password is set during the infection sequence. 345gs5662d34 appears only in a separate post-infection session.

Does this affect the 98% headline? No. The correction applies specifically to the credential mechanism, not to the behavioral clustering or session attribution on which the broader finding rests. We re-reviewed all claims that depended on credential semantics; this is the only one that required correction.

The evidence

Corrected kill chain

Reconstructed from 241 decoded base64 payloads across 243 WORM sessions:

Dual-credential system

Dota maintains two independent access mechanisms on each infected host. We misread the verification probe as a third mechanism:

345gs5662d34 is neither of these. It is a hardcoded probe credential - the same value sent from all infected hosts in the verification phase. Its purpose appears to be confirming that the SSH key injection succeeded on the new host.

Credential recycling in propagation

Step 5 of the infection sequence saves the victim's original credential to /tmp/up.txt. This is then fed directly into the propagation scanner (kthreadadd). If one host was running demo/demo123!, all 192.168.x.x nodes get scanned with that same credential - a targeted reuse of known-working credentials rather than a full wordlist spray.

Variant housekeeping

The infection sequence explicitly deletes earlier variants:

The directory names suggest an ongoing variant numbering scheme. X291 is the current dominant variant, but prior variants were still present on enough hosts that active cleanup remains part of the infection routine.

What this erratum does not change

This correction is narrow. The following findings from the original paper are unaffected:

• → Dota dominates the classified sessions in the original dataset (~98%)
• → Observed worm behavior is highly consistent across sessions
• → The mdrfckr RSA key is a core behavioral marker and persistence mechanism
• → The infection sequence (cleanup → persist → propagate) is confirmed by payload analysis
• → Credential recycling via /tmp/up.txt into internal propagation is confirmed

Methodology

Of the 1,021 sessions in the original paper, 243 were attributed to the Dota worm cluster and contained sufficient telemetry for payload-level re-analysis. "Worm session" here means sessions behaviorally attributed to the Dota cluster using the same family markers as the original paper. We successfully decoded 241 of 243 embedded payloads; 2 were truncated or incomplete in capture.

Single sensor · Node 1, Germany · Cowrie SSH honeypot with AuthRandom

Limitations

The credential mechanics described here - unique random password, mdrfckr key injection, 345gs5662d34 verification probe - are derived from deterministic command sequences consistent across all 243 sessions. We have high confidence in the mechanism as observed on this sensor.

What we cannot confirm from this sensor alone: whether the verification probe always co-occurs with mdrfckr key injection, whether credential behavior differs across variants (.X13 through .X291), and whether the unique random password is ever reused for return access on real infrastructure. The honeypot accepts arbitrary credentials; we cannot observe what actually succeeds on real hosts.

Updated defender guidance

Host-level

• → Treat unauthorized authorized_keys entries containing mdrfckr-associated material as the strongest host-level signal
• → Audit recent passwd command executions alongside SSH persistence artifacts
• → Look for /tmp/up.txt, .X291-unix/, and kthreadadd processes

Network-level

• → SSH authentication attempts using 345gs5662d34 are a high-value behavioral indicator associated with post-compromise Dota activity - treat as evidence of a compromised host in your network running the verification phase
• → Do not treat 345gs5662d34 as the initial infection credential - blocking it will not address the actual brute-force access path, which uses standard weak passwords

What to stop assuming

• → Seeing 345gs5662d34 in logs does not mean an attacker set that password on a system
• → Successful authentication with 345gs5662d34 on a honeypot is a measurement artifact, not evidence of credential reuse