Anatomy of an Outlaw: 28 Minutes Inside a Cryptomining Botnet Intrusion

Published: July 25, 2026
Threat Family: Outlaw / Dota (Shellbot) cryptomining botnet
Confidence: High

Summary

On the evening of July 25, 2026, one of our SSH honeypot sensors recorded a complete, end to end intrusion by the Outlaw botnet (also tracked as Dota or Shellbot), a long running, Perl/shell based cryptomining operation that has been compromising Linux servers via SSH brute force since at least 2018.

In just under 29 minutes, a single attacking host ran a slow and low credential guessing campaign, landed a successful login, planted its signature SSH backdoor key, profiled the victim’s hardware, changed the account password to lock out competitors, and pulled down its malware payload; then went right back to brute-forcing, hunting for the next foothold.

Every stage was automated. No human ever touched a keyboard. This post walks through the full kill chain as our sensor captured it, because this exact playbook is hitting internet facing SSH services everywhere, right now.

The Attacker

The libssh_0.9.6 client banner is a strong tell. Legitimate administrators connect with OpenSSH; libssh is a programming library, and this specific version string is a well documented fingerprint of Outlaw’s brute force tooling. Combined with the source IP’s pre-existing “known attacker” reputation, the sensor knew what it was dealing with before the first password was ever guessed.

The source is almost certainly not the operator’s own machine; Outlaw propagates worm like, so this host in Benin is most likely a previously compromised victim now being used to attack others. That’s the business model: every victim becomes an attacker.

The Timeline

The entire engagement spanned 19:21:53 to 19:50:14 UTC: 28 minutes and 21 seconds, across 14 SSH sessions.

Phase 1: Slow and Low Brute Force (19:21 – 19:31)

The first four sessions arrived at a deliberately lazy cadence of roughly one attempt every 2.5 – 3 minutes:

Two things stand out. First, the pacing, one guess per connection, minutes apart, is engineered to stay under the trip-wire of fail2ban-style lockout tools and rate based detection. Second, the wordlist: these are not root/password123 sprays. They’re username as password pairs and service account patterns harvested from previously breached hosts, which is how Outlaw’s distributed brute force network keeps finding accounts that generic wordlists miss.

At 19:31:23, hima:hima worked. The honeypot let it in.

Phase 2: Backdoor in Under Two Seconds (19:31:23 – 19:31:24)

The moment authentication succeeded, the bot fired its implant sequence:

cd ~; chattr -ia .ssh; lockr -ia .ssh

First it strips the immutable and append-only attributes from the .ssh directory; a countermeasure against defenders (and rival botnets) who “lock” authorized_keys with chattr +i. The lockr variant is a fallback for systems where a renamed chattr binary exists; here it failed with command not found, which the bot ignored.

Then, the signature move:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2E... mdrfckr" >> .ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

It deletes the entire .ssh directory, wiping out any legitimate keys and any keys planted by competing botnets; recreates it, and installs a single RSA public key with the comment string mdrfckr. That comment is Outlaw’s calling card, documented in threat reporting going back years and unchanged to this day. It then locks the directory permissions down so only the owner can read it.

Total elapsed time from login to persistent backdoor: under two seconds.

Phase 3: The Honeypot Check (19:31:25 – 19:31:28)

Two rapid follow-up sessions attempted logins with the credentials 345gs5662d34 and 3245gs5662d34. These strings appear across Outlaw activity worldwide and function as a canary check — a deliberately nonsensical credential pair the botnet uses to sanity-test the target. A real server rejects garbage credentials; a poorly configured honeypot that accepts anything exposes itself. Our sensor correctly failed both attempts, passing the test.

Phase 4 — Hands-Off Recon and Victim Lockout (19:31:29–19:31:43)

Satisfied, the bot reconnected with its stolen hima credentials and ran a rapid fire profiling script: 18 commands in 14 seconds, all machine paced:

cat /proc/cpuinfo | grep name | wc -l
echo -e "hima\nOZ8YSnsixDkm\nOZ8YSnsixDkm"|passwd|bash
free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'
ls -lh $(which ls)
crontab -l
w
uname -a
lscpu | grep Model
df -h | head -n 2 | awk 'FNR == 2 {print $2;}'

Two objectives here:

1. Mining feasibility assessment. CPU core count, model, RAM, and disk, Outlaw is a cryptomining operation, and this inventory decides whether the victim is worth deploying a Monero miner on and how to tune it.
2. Lock out the competition — and the owner. The passwd pipe changes the hima account password to the randomly generated string OZ8YSnsixDkm. The legitimate user is now locked out of their own account, and so is every other botnet brute-forcing the same weak credential. The attacker doesn’t care; they retain access through the mdrfckr SSH key.

The w and crontab -l checks look for logged-in admins and existing scheduled jobs (i.e., signs of a defender, or of a rival miner already resident).

Phase 5: Payload Delivery (19:31:44)

A final authenticated session fetched the malware payload. The sensor captured the file:

SHA-256: a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2

This hash is extremely well known in public malware repositories: it is Outlaw’s dota3 toolkit archive, a tarball that unpacks into the group’s standard three components, an XMRig based Monero miner, an IRC controlled Shellbot backdoor written in Perl, and the SSH brute force/scanner module that turns the victim into the next attacking node.

On a real host, this is the moment the machine stops being a victim and starts being infrastructure.

Phase 6: Back to Work (19:33 – 19:50)

With the implant delivered, the bot resumed exactly where it left off, the same ~2.5 minute brute force cadence, working down its credential list against the same target:

root:1q2w3e!q@w#e → dante:dante → joerg:joerg → omnix:omnix → root:asterix → xian:xian → root:A123456 — all failed, and the capture window closed at 19:50:14 UTC.

The persistence of the loop after a successful compromise is telling: the operation is fully autonomous and greedy. One valid account is never enough; the bot keeps grinding for additional credentials it can feed back into the collective wordlist.

Why This Matters

Outlaw is not sophisticated. There’s no zero-day here, no clever exploit, just weak passwords, patience, and total automation. That’s exactly what makes it effective at scale. Recent industry reporting continues to track active Outlaw infections worldwide, overwhelmingly on Linux servers whose only sin was an SSH service exposed to the internet with a guessable credential.

The economics are brutal in the attacker’s favor: compromised victims supply the compute (for mining) and the bandwidth (for spreading). The campaign runs itself.

Detection & Hunting Guidance

Indicators of Compromise

Hunt queries for your environment:

• Grep every user’s ~/.ssh/authorized_keys for the string mdrfckr. Any hit is a confirmed compromise.
• Alert on chattr -ia targeting .ssh paths, and on rm -rf .ssh — legitimate automation almost never does this.
• Flag SSH authentication from clients presenting libssh banners; interactive admins essentially never use them.
• Watch for passwd invoked via echo | passwd pipes in shell history or auditd — the lockout pattern is a strong post-compromise signal.
• Hunt for unexplained dota3.tar.gz archives, hidden directories (commonly .configrc-style paths), and XMRig process artifacts.

Mitigations (the boring ones, because they work):

1. Disable SSH password authentication entirely; require keys.
2. If passwords must exist, enforce length/complexity and deploy fail2ban with a low threshold and long ban, note this actor’s cadence was tuned to evade default thresholds, so consider aggregating failures over 30+ minute windows.
3. Don’t expose SSH to the whole internet. VPN, bastion, or at minimum IP allowlisting.
4. Monitor authorized_keys files for changes with file-integrity monitoring.

MITRE ATT&CK Mapping

This report is based on telemetry from a research honeypot network. Destination addresses and sensor identifiers have been redacted. The attacking IP address is published in good faith as an indicator of compromise; the host is likely itself a compromised victim, and the geolocation should not be read as attribution of the operators.