Investigation March 2026

98% of SSH Intrusions Come from One Worm

A single honeypot sees around 1.4 million events per day. Most of it is noise. Very little results in actual compromise. We followed every real SSH intrusion over 8 days. Almost all of them led to the same system - or more precisely, the same worm family.

dataset: 1,021 sessions period: March 15–22, 2026 sensor: Cowrie (T-Pot) source IPs: 605 countries: 69 variants: 10 behavioral
Erratum #1 | This investigation contains a correction to the 345gs5662d34 credential mechanism. The 98% finding is unaffected. read →

It looks noisy. In practice, it isn't.

Daily averages from a single honeypot:

LayerVolumeDescription
All sensors~1.4MRaw events (passive scans, fingerprinting, background radiation)
SSH-related~60,000Connection attempts, authentication events
Successful logins~531Authenticated SSH sessions
Post-login commands~4,700Actual attacker interaction
all sensors
1,400,000
raw events / day
95.7% noise
cowrie ssh
60,000
SSH-related events
99.1% fail auth
auth success
531
successful logins / day
▼ classified over 8 days
post-auth
1,021
sessions with commands
98% one worm family
dota worm
1,005
one worm family

From 1.4 million signals, only a few hundred lead to real access. Everything else is the internet talking to itself.

Events are not attacks. This distinction matters. Most of what security dashboards count as "attacks" is noise: passive scans, failed connections, background internet radiation. Only sessions with successful authentication and post-login commands represent real intrusions.

Two datasets, one story

This analysis combines two views: volumetric baselines (24-hour averages for scale) and a behavioral dataset (8 days of classified sessions for depth).

Methodology

Sessions with only minimal interaction (1–2 commands) may not contain enough signal for behavioral classification. This matters for the numbers below.

Dataset Construction

Short sessions (login followed by immediate disconnect or 1–2 trivial commands) were excluded from behavioral analysis due to insufficient signal. The 98% figure refers specifically to sessions with enough interaction to construct a behavioral fingerprint.

98% of classified intrusions - one worm

From the 8-day behavioral dataset:

MetricValue
Total sessions with commands1,021
Unique source IPs614
Countries69
Behavioral fingerprints17
Linked to one worm family1,005 (98%)

This isn't similar behavior or loose correlation. It's the same system. A self-propagating SSH worm operating across hundreds of compromised machines.

Meet the worm: Dota

Named after its payload archive: dota3.tar.gz. Across the dataset, 614 unique source IPs were observed, of which 605 were linked to the Dota worm family, spanning 69 countries. These are not independent attackers. They are compromised systems participating in propagation.

Prior research. Variants of the Dota/mdrfckr SSH worm have been documented in previous analyses, including reports by AhnLab and multiple honeypot operators. These studies describe the worm's propagation via SSH key injection and its use of automated deployment scripts.

What is new here: This investigation does not focus on payload analysis or infrastructure tracking. Instead, it introduces behavioral fingerprinting to cluster sessions, identify variant families, and quantify their dominance over a continuous observation window.

Every variant shares one invariant marker:

ssh-rsa AAAA...== mdrfckr

That SSH key appears across all variants. It acts as the worm's fingerprint.

Payload analysis is outside the scope of this behavioral study. This investigation focuses on observable command sequences and interaction patterns rather than post-deployment functionality.

A deterministic kill chain

Once inside, the worm doesn't improvise. It executes a fixed sequence, consistently observed across hundreds of sessions:

1
Remove SSH protections
chattr -ia .ssh; lockr -ia .ssh
2
Wipe and rebuild access
rm -rf .ssh && mkdir .ssh
3
Inject backdoor key
echo "ssh-rsa AAAA...== mdrfckr" >> authorized_keys
4
Lock access
chmod -R go= ~/.ssh
5
Profile the system
cat /proc/cpuinfo | grep name | wc -l
free -m | grep Mem
df -h | head -n 2
lscpu | grep Model
6
Prepare propagation
echo "root server" > /tmp/up.txt
7
Remove previous infections
rm -rf /var/tmp/dota*
8
Deploy payload
base64 --decode payload | bash
9
Start scanning internal networks
kthreadadd -t 150 -S 6 -p 22 /tmp/up.txt 192.168

All commands arrive within sub-second intervals. There are no pauses or typing delays. Execution is fully automated.

ATT&CK Mapping

StageTechniqueID
Initial AccessRemote Services: SSHT1021.004
PersistenceSSH Authorized KeysT1098.004
ExecutionUnix ShellT1059.004
DiscoverySystem Information DiscoveryT1082
PropagationRemote System DiscoveryT1018

Decisions after the breach

The worm doesn't evaluate targets before compromise. It breaks in first. Then it profiles the system: CPU cores, RAM, disk space, CPU model.

What we observe vs. what we infer. The profiling pattern strongly suggests resource classification, likely distinguishing between mining-capable systems and propagation-only nodes. This is an inference, not a directly observed decision. Due to honeypot constraints, we cannot observe the worm's internal decision logic after profiling.

The most dangerous part: internal propagation

After installation, the worm scans:

kthreadadd ... 192.168.x.x kthreadadd ... 172.16.x.x

This is not internet-wide scanning. This is propagation targeting private address space. One exposed SSH service can become an entry point into an entire internal network.

It knows if you're already infected

Before deploying, the worm checks:

cat /var/tmp/.systemcache436621

If the file exists, the system is already infected. Deployment is skipped. This is a built-in deduplication mechanism that reduces redundant infections, instability, and noise. This points to controlled propagation, not sloppy malware.

Behavioral DNA: tracking without IOCs

IP tracking fails here. The worm rotates across hundreds of compromised systems. Each infection becomes a new source. Tracking IPs means tracking victims, not the attacker.

Instead, we normalize behavior:

CommandNormalized Action
chattr -ia .sshpersist
rm -rf .sshcleanup
pkill -9 secure.shkill_process
cat /proc/cpuinforecon_system
echo creds > filewrite_file

Each session becomes a sequence - its Behavioral DNA:

It's not one worm - it's a family

Behavioral analysis revealed 17 fingerprints, 10 linked to the Dota family. Three variants dominate, each with a distinct DNA sequence:

Variant A - Standard dominant
813 sessions · 445 IPs · 67 countries
persist cleanup persist chmod recon
Variant B - Competitor Killer eliminates rivals
134 sessions · 115 IPs · 40 countries
persist cleanup persist chmod recon cleanup kill recon
Variant C - Credential Writer propagation
17 sessions · 16 IPs · 11 countries
persist cleanup persist chmod recon write cleanup write recon
Shared invariant across all 10 variants: ssh-rsa AAAA...== mdrfckr · 605 IPs · 69 countries

Unlike IOCs, behavioral DNA survives IP rotation, infrastructure changes, and payload variations. Behavioral patterns remain consistent regardless of infrastructure changes.

Infected systems are contested, not owned

The competitor-killer variant changes the picture. Before installing itself, it runs:

pkill -9 secure.sh pkill -9 auth.sh echo > /etc/hosts.deny pkill -9 sleep

It removes competing malware. An infected server is not simply "compromised" but rather contested infrastructure. Multiple malware families compete for persistence, CPU resources, and network position. The Dota worm actively eliminates rivals.

The passwords tell you where it came from

Observed credentials set by the worm:

345gs5662d34 3245gs5662d34

If these appear in your logs, the source is not a human attacker. It is another infected system. The worm leaves fingerprints across the internet.

Indicators

TypeValueDescription
SSH KeymdrfckrInjected authorized_keys marker
Marker File/var/tmp/.systemcache436621Reinfection check
Credentials345gs5662d34, 3245gs5662d34Worm-set passwords
Payloaddota3.tar.gzArchive name used during deployment

Sample size and generalization

This dataset comes from one honeypot, 8 days of observation, 1,021 sessions. Does this represent the entire internet? Not necessarily.

However: 69 countries, ~605 source systems, and consistent behavioral patterns across all sessions strongly indicate a globally distributed, coordinated campaign, not isolated activity.

Limitations.

The real insight: a monoculture

Within sessions that provided enough behavioral signal: ~98% belong to a single worm family.

This is not thousands of independent attackers. It's a monoculture. A self-replicating system moving across hundreds of machines, continuously reinfecting the internet.

If you track IPs, block regions, or count "attacks", you are measuring noise. The signal is in the behavior. The real threat is not individual attackers but autonomous systems that propagate, adapt, compete, and persist.

Defender takeaway. If you operate SSH sensors or review Cowrie logs, look for:

Fingerprint and subtract this activity. What remains is a much smaller set of sessions that warrant deeper investigation.

This is the first public investigation from NullRoute.
Future publications will cover behavioral clustering, credential reuse campaigns,
and attacker decision patterns observed across multiple sensors.

The 2% that is not Dota is where the interesting threats begin.

Erratum #1 - credential model correction (March 2026)

Update Brief - six more days, two nodes (March 23-29, 2026)

Two Bot Pools - coordinated timing, IP overlap (March 24-31, 2026)

Failed-Intent Analysis - what failed commands reveal across 81,000 sessions

RF-001 MDRFCKR - behavioral dossier and session replay

← all investigations