Turf Wars at Scale: Botnets Fighting for the Same Servers

Tracking a competitive cryptomining botnet through its own eviction script.

Observation window: 2026-04-30 → 2026-05-02

Primary signal: 42 post-auth sessions from 13 IPs running the same eviction + miner-deploy playbook

Core finding: the botnet removes rival miners before deploying its own payload

Defensive value: high-signal eviction patterns, source infrastructure, hashes, and SSH command telemetry

A botnet that exposes its competitors through its eviction logic.

During a 58-hour observation window, we watched a cryptomining botnet compromise internet-exposed servers already occupied by rival miners, remove rival implants, kill competing miners, and deploy its own loader/payload pair.

The interesting part is not just the miner. It is the eviction script: a compact map of the malware ecosystem already present on internet-exposed servers - Opera, xmrig, cnrig, java, /tmp/.diicot, /var/tmp/.update-logs/, and /dev/shm/rete*.

This is what commodity botnets look like when the target is not greenfield territory, but contested infrastructure.

Context: a documented family, still very much active

The eviction pattern, naming conventions, and toolset described here are consistent with publicly documented Diicot behavior, a Romanian-origin threat actor documented by Wiz Research (December 2024) , Darktrace , and The Hacker News / Kaspersky (April 2025) under the overlapping name Outlaw. We use “Diicot/Outlaw” throughout to refer to a behavioral cluster, not a specific operator identity - multiple operators may share this toolchain.

The binaries we captured (/tmp/cache, SHA256 640c817...) were first submitted to VirusTotal in August 2025 and currently score 31/75 engines. They are not a new discovery. The third binary in the loader/payload pair (3069a28...) has not been indexed in any public malware database as of this writing - it may represent a variant or an updated loader that has not yet been submitted elsewhere.

This article’s contribution is not attribution (that work was done in 2024–2025) but current infrastructure mapping and behavioral measurement: refreshed netblocks, updated eviction logic, brute-force conversion ratios, and confirmation that the campaign remains operational at meaningful volume 18 months after initial public documentation.

What we observed

Over 58 hours (2026-04-30T00:36Z → 2026-05-02T11:16Z), our sensors recorded 42 successful post-auth intrusion sessions from 13 coordinated IPs. Every successful deployment followed the same shape: authenticate, upload /tmp/cache, remove competing malware, drop a loader/payload pair into /var/tmp/, daemonize, clear shell history, disconnect.

There was no interactive exploration and no manual troubleshooting. The sessions were short, deterministic, and repeatable. This was not an operator looking around. It was a dispatcher executing a playbook against infrastructure it expected to be contested.

Brute-force conversion

The same 13 IPs generated 19,742 password attempts against the honeypot during this window, of which 189 succeeded - a 0.96% conversion rate. The credential pairs cycled match the standard top-100 SSH brute-force wordlists circulated in commodity-bot ecosystems (no targeting indicators observed; the same lists hit our other tenants identically).

All 189 logins authenticated successfully - The 78% gap is not in authentication, but in follow-on payload deployment. Of the 189 sessions, only 42 went on to run the kill chain described below; the other 147 logged in, did nothing observable, and disconnected. Candidate explanations: credential-validation passes feeding a separate dispatch queue, sessions handed off to another worker, or - most interesting from a defender’s perspective - silent honeypot fingerprinting before deployment. If the dispatcher checks for honeypot indicators (virt-what, dmidecode strings, sysctl footprints, network egress filters) before committing the loader, the 78% gap is exactly what we’d expect to see from a flagged target. We don’t have direct evidence either way; we note the anomaly because it would materially change how we assess the operator’s capabilities.

Conversion rates cluster tightly between 0.5% and 1.3% across all 13 nodes - consistent with a shared credential list and a shared dispatcher.

Infrastructure

The 13 IPs cluster into four infrastructure groups. Eleven of them sit on AS51396, registered to Pfcloud UG (haftungsbeschränkt) in Germany, with sub-allocations advertised under two RIPE org-names: VMHeaven.io (NL) and Storm Industries (PFCLOUD-NET). Two outliers are hosted outside this AS51396-heavy footprint.

Pfcloud UG / VMHeaven.io is the operator’s dominant infrastructure here - eleven nodes across four /24 blocks, three countries (NL, DE, BG), one legal entity. The ASN is the same; the inetnum brand differs (VMHeaven.io vs. Storm Industries) but the upstream is identical.

This footprint differs from the original Diicot infrastructure (arhivehaceru[.]com, 45.88.67.94) documented in 2024. The operator has rotated hosting while keeping the same toolchain - a strong signal that public attribution succeeded only in burning IPs, not in disrupting operations.

The Alibaba HKG and Viettel VN nodes are the interesting outliers. An Alibaba Cloud IP may evade blocklists tuned specifically for bulletproof hosting providers; Viettel is a mainstream Vietnamese telco. Both are likely abused customer accounts rather than directly rented operator nodes - a redundancy hedge against the bulk of the fleet getting taken down on AS51396.

The kill chain

Each successful session runs the same five-stage sequence. Numbered chronologically below:

Stage 1 - SSH brute force

Continuous credential attempts in 3–5/second bursts, cycling common pairs from a shared wordlist. Successful auth triggers an immediate follow-on session.

Stage 2 - Payload delivery (SCP)

scp -qt "/tmp/cache"

The -q flag suppresses progress output, -t is the server-side mode triggered by the remote SCP. Binary properties: ~1 MB static ELF x86-64, no section header, UPX-packed (per VirusTotal tagging), with a debug-environment detection flag.

Three binaries, three different ages, one shared distribution channel. The 31/75 detection on /tmp/cache is consistent with a sample that has circulated long enough for AV vendors to triage but not long enough to draw a coordinated signature push. The 6/75 on the loader is recent enough that most engines still miss it. The third payload is worth submitting to AV vendors, since it does not appear in public malware databases.

Stage 3 - Competitor eviction (the part that maps the contested host)

The eviction script is the article’s map: every path it deletes and every process it kills points to another operator’s current or previous foothold on the same host.

Each session runs the same ;-separated one-liner. Grouped thematically (the script does not include comments - these labels are ours):

# unlock — strip immutable + append-only set by prior installs
chattr -iae ~/.ssh/authorized_keys
chattr -iae /var/tmp/Documents/.diicot
chattr -iae /var/tmp/.update-logs/{History,Update}

# wipe — competitor + prior-install paths
rm -rf /dev/shm/.x /dev/shm/rete*
rm -rf /var/tmp/payload /tmp/.diicot /tmp/kuak
rm -rf /var/tmp/.update-logs /var/tmp/Documents
rm -rf xmrig xmrig.1 .diicot .black Opera

# kill — competing miner processes
pkill Opera; pkill cnrig; pkill java; pkill xmrig
killall java; killall cnrig; killall xmrig

# clear cron, reset Documents/, then proceed to install (next phase)
crontab -r
mkdir /var/tmp/Documents

Each target maps to a known family:

The most interesting target is Opera. Reading the Diicot 2024 documentation, Opera is the disguised name Diicot uses for its own miner binary. The fact that this script kills Opera before deploying suggests either (a) the operator overrides their previous self-deploys, or (b) we are watching a competing fork of the same toolchain that wants to evict the original. Both readings line up with a busy ecosystem of operators borrowing each other’s code.

The chattr -iae calls before each delete handle the immutable/append-only attributes Diicot and others set to defend their own installations - the script is engineered for hostile takeover, not greenfield deploy.

Stage 4 - Loader + payload daemonization

cd /var/tmp && chmod 777 <PAYLOAD> && chmod 777 <LOADER> && \
  ./<LOADER> <PAYLOAD> >/dev/null 2>&1 & disown

Both filenames are random 8-character alphanumeric strings, regenerated every session. Examples we captured:

./EkeDZmvO SijjVEiT
./TsFmXshK SOeQvJRs
./qGyKUjmR SGrFfyeg
./VJSAvnbA reIOrvsr
./XrobaiCl oztaUAfB

The pattern (./LOADER PAYLOAD, daemonized, disown-ed from the SSH session) is consistent across all 42 captures.

Stage 5 - Anti-forensics

history -c; rm -rf .bash_history ~/.bash_history

Standard hygiene, common across the SSH brute-force botnet ecosystem. Nothing sophisticated - just enough to defeat a casual history check.

Density and timing

42 sessions over 58 hours = ~0.72 sessions/hour mean, peak 3 sessions/hour (multiple times across both days). No circadian pattern - the operator runs at uniform intensity around the clock. Multiple IPs occasionally hit the same victim within minutes, consistent with either a shared job queue or two nodes racing each other to the same credential batch.

Session duration from auth to disconnect varies more than we expected. Median 154 seconds, mean 230 seconds (≈3.8 minutes), with a long tail: p90 sits at 285s, p95 at 877s. The longest session ran for ~39 minutes and is almost certainly an outlier where a process kill or a filesystem operation hung; the shortest, 9 seconds, is an eviction shortcut where the script bails early on a host already free of competitor binaries. Most sessions complete in 2–3 minutes.

What’s new vs. prior public reporting

The big update is scale and conversion: ~20k brute-force attempts → ~190 logins → ~40 monetized sessions across 13 nodes in 58 hours. Bulletproof VPS rental on AS51396 costs roughly 5–10 EUR per node per month, so 13 nodes is a ~100 EUR monthly infrastructure budget. We do not have direct yield data (see “Scope” below), but the conversion ratio is high enough to make the hosting economics plausible even at low miner yield.

Scope of this analysis (what is not covered)

This article is a behavioral characterization of the SSH-layer kill chain we observed. Three things we deliberately do not cover:

• C2 / phone-home destinations of the loader (the random 8-char binary in /var/tmp/). Static analysis of the loader is ongoing; C2 details will follow in a separate post if and when we have them. The SSH-layer eviction script captured here does not embed C2 endpoints.
• Monero wallet / pool used by the deployed miner. Without dynamic analysis of the running payload, we cannot extract wallet addresses or mining-pool URLs. Reporting wallets without verification is a common source of false attribution in cryptomining threat intelligence.
• Operator identity beyond family signature. We treat “Diicot/Outlaw” as a behavioral cluster, not as a specific operator. See the disclaimer in the Context section.

Indicators of compromise

Defensive notes

• Watch for chattr -iae followed by rm -rf on /var/tmp/.update-logs/ or /var/tmp/Documents/: this is the eviction prologue, and no legitimate workload runs it. Auditd watch on these paths gives near-zero false-positive detection.
• Block AS51396 outright if your environment has no NL/DE/BG/LU hosting requirements: 11 of 13 attacker IPs sit there. The false-positive impact of a targeted ASN block is usually easier to contain; the cost of a successful Diicot install (CPU theft + hosting denylist + cleanup) is not.
• Alert on scp -qt "/tmp/cache" in SSH exec logs: this is the file-name signature, near-zero FP on real workloads.
• Watch the loader-launch shape: cd /var/tmp && chmod 777 <8-alnum> && chmod 777 <8-alnum> && ./[8-alnum] [8-alnum] >/dev/null 2>&1 & disown. Legitimate software does not normally produce two random 8-character executables in /var/tmp and execute them as ./X Y.
• Rate-limit SSH brute force per source IP: at ~3,000 attempts in 58 hours per node, even modest per-IP throttling collapses conversion economics below the operator’s break-even.

References

• Wiz Research, Diicot: An Emerging Romanian Threat Actor, December 2024 - https://www.wiz.io/blog/diicot-threat-group-malware-campaign
• Darktrace, Tracking Diicot: An Emerging Romanian Threat Actor - https://www.darktrace.com/blog/tracking-diicot-an-emerging-romanian-threat-actor
• The Hacker News, Outlaw Group Uses SSH Brute-Force to Deploy Cryptojacking Malware, April 2025 (citing Kaspersky GReAT research) - https://thehackernews.com/2025/04/outlaw-group-uses-ssh-brute-force-to.html
• Hackread, Diicot Hackers Target SSH Servers with Brute-Force Malware, 2024 - https://hackread.com/diicot-hackers-ssh-servers-brute-force-malware/
• MITRE ATT&CK T1098.004: Account Manipulation - https://attack.mitre.org/techniques/T1098/004/
• MITRE ATT&CK T1496: Resource Hijacking - https://attack.mitre.org/techniques/T1496/

OHIIHO Research - sensors powered by HIIH.