๐งฌ TI-2026-025F โ The Evolution: Eight Years of Adaptation and the Fingerprint That Never Dies
Chapter 1 โ The Long Arc: 2018โ2026
Most malware has a shelf life measured in months. A campaign launches, defenders document it, signatures get written, and the operators pivot to something new. The mdrfckr botnet doesn't follow this model. It has been continuously operational for eight years โ not through technical sophistication, but through a strategy of minimal adaptation. It changes exactly what it needs to change to survive, and nothing more.
What follows is the documented evolutionary history of a botnet that has outlasted hundreds of security vendors' reports, multiple generations of defensive tooling, and at least three complete cycles of the cybersecurity industry's attention span.
Trend Micro publishes the first report: "Perl-Based Shellbot Looks to Target Organizations via C&C." The group is named Outlaw โ a direct translation of the Romanian word haiduc, their primary hacking tool. C2 domain: luci.madweb.ro. IRC operators: lucian, dragos, mazy, hydra. CVE-2017-1000117 (git command injection) is the initial exploitation vector. The botnet is small, regional, focused.
A second Trend Micro report documents the scale: 180,000+ compromised hosts, 20,000 newly compromised. The haiduc SSH brute-forcer is deployed at industrial scale. RDP and cPanel modules are added. The botnet has gone from a research curiosity to an infrastructure threat in under a month.
New C2 infrastructure: 146.185.171.227:443, 5.255.86.129:3333. Package evolves from dota.tar.gz to dota2.tar.gz. Android targeting module appears. Trend Micro notes: "We noted how quickly it went from the testing and development phase to compromising more than 200,000 hosts."
C2 shifts from Romanian domains to FranTech-hosted infrastructure. The IRC server moves to 45.9.148.99:443 (channel #007, admins polly/molly). By the end of 2020, the operation has settled on 198.98.56.205 โ a BuyVM/FranTech IP that will remain the C2 anchor for over 5 years. The domain bullshit-irc.net is the human-readable alias.
No major vendor publications. The botnet doesn't stop โ it simply drops below the attention threshold. CounterCraft's internal classification CC0631 tracks continued activity. The operators refine XMRig configurations, incrementing from version 6.x through 6.19. The package name evolves to dota3.tar.gz. Persistence directories shift from .configrc5 to .configrc6.
CounterCraft's North Dakota honeypot documents: 5,873 successful authentications in 62 days from 2,464 unique attacker IPs across 94 countries. The scale is staggering โ this is one honeypot seeing thousands of infected machines performing automated spread operations. The botnet never stopped; it grew.
Elastic Security Labs and Kaspersky/Securelist both publish deep analyses within weeks of each other. Elastic captures a live operator performing a manual "quality check" from 212.234.225.29 โ including typos and Ctrl+C. The human behind the automation is documented in real-time. XMRig is now at version 6.22.1.
LSN Cowrie honeypot goes operational. Within hours, the first f555226df1963d1d3c09daf865abdc9a HASSH sessions appear. We're seeing what the NINGI researchers will later classify as Wave 1 โ the quiet reconnaissance phase using older libssh 0.9.6 toolkit. 20 sessions, 1 unique IP. The parasite is probing.
HASSH af8223ac9914f509afdadfaf5f7ee94e (libssh 0.12.0) appears with overwhelming force. 4,926 sessions from 200 unique IPs in a single week. Static password y6ekwUbyoOkk set on all victims. This is the industrialized deployment phase โ the upgraded toolkit attacks at scale.
The day everything flips. Wave 2 (libssh 0.12.0) drops from 269 sessions to 89. Wave 3 (libssh 0.9.6) surges from 0 to 809. The per-session random password rotation deploys. The operator has read the analyses and responded within days. By May 21, Wave 2 traffic hits zero. The old fingerprint is abandoned.
Only f555226df1963d1d3c09daf865abdc9a remains active. ~184 sessions/week from ~92 IPs. The botnet has adapted, survived, and continues. It is now older than some of the security analysts tracking it.
Chapter 2 โ The Three Waves of 2026
Our honeypot captured the most detailed view of a botnet toolkit transition ever documented from a single observation point. Three distinct campaign waves, each with measurable differences in tooling, operational security, and tactical behavior.
Wave 1: The Scout
- Period: Mar 29 โ Apr 19
- HASSH: f555226d...
- libssh: 0.9.6
- Sessions: ~229
- IPs: 3โ10
- Password: Not changed
- Purpose: Reconnaissance
Wave 2: The Hammer
- Period: Apr 21 โ May 20
- HASSH: af8223ac...
- libssh: 0.12.0
- Sessions: 18,169
- IPs: 616
- Password: Static
- Purpose: Mass deployment
Wave 3: The Ghost
- Period: May 7 โ present
- HASSH: f555226d...
- libssh: 0.9.6
- Sessions: 12,044+
- IPs: 1,312+
- Password: Per-session random
- Purpose: Stealth persistence
The Crossover Event: May 13, 2026
The most significant moment in our dataset isn't a spike โ it's a crossover. On May 13, 2026, Wave 2 traffic (libssh 0.12.0, HASSH af8223ac...) dropped below Wave 3 traffic (libssh 0.9.6, HASSH f555226d...) and never recovered.
Wave 2 (libssh 0.12.0) Wave 3 (libssh 0.9.6)
The crossover on May 13 was not gradual โ it was a switch. This is not organic botnet decay. This is a coordinated toolkit replacement executed across 1,000+ infected hosts within 72 hours. Someone pushed an update to the entire fleet. The operator has a command-and-control capability that reaches every active node simultaneously.
Chapter 3 โ What Changed and What Didn't
The evolutionary strategy of mdrfckr is best understood through what the operator chose to change โ and what they deliberately left unchanged. Each modification has a purpose. Each invariant is a structural dependency.
The Mutable Shell
| Attribute | Wave 2 | Wave 3 | Why It Changed |
|---|---|---|---|
| HASSH Fingerprint | af8223ac... |
f555226d... |
HASSH-based blocking made the old fingerprint a liability. Reverting to older libssh produces different key exchange algorithms. |
| SSH Client Version | SSH-2.0-libssh_0.12.0 |
SSH-2.0-libssh_0.9.6 |
Downgrade to older version โ counterintuitive but effective. Older version blends better with legacy infrastructure. |
| Root Password | Static (y6ekwUbyoOkk) |
Per-session random 12-char | NINGI-015: "The per-session password rotation is a targeted improvement... removing the most obvious forensic correlator." |
| Persistence Directory | ~/.configrc6 |
Unknown (modified) | Elastic's publication of .configrc6 made it a signature. Expected to have changed. |
| Node Count | 616 unique IPs | 1,312+ unique IPs | Wave 3 doubled the fleet size โ the adaptation included expansion, not just evasion. |
The Immutable Core
| Attribute | Value | Unchanged Since | Why It Can't Change |
|---|---|---|---|
| SSH Key Comment | mdrfckr |
2018 | Embedded in the RSA public key. Changing it would require re-keying every infected host simultaneously โ an operation that risks losing control of the fleet. |
| RSA Public Key | SHA256: a8460f44... |
2018 | The backdoor key grants persistent access. Rotating it means a window where old-key hosts are accessible but new-key hosts aren't โ a fleet-split risk. |
lockr -ia .ssh |
Dead command in script | Unknown (pre-2024) | Present in every wave, always fails. Either technical debt the operator won't touch, or a canary for an internal tool. |
| Credential Probe | 345gs5662d34:345gs5662d34 |
Wave 1 | The re-entry credential identifies already-compromised hosts. Changing it would orphan the entire existing fleet. |
| C2 Server | 198.98.56.205 |
~2020 | FranTech's bulletproof hosting absorbs all abuse complaints. No reason to move. |
| Kill Chain Logic | chattr โ inject key โ kill competitors โ fingerprint โ deploy | 2019 | The sequence is functionally optimal. Each step depends on the previous. Reordering breaks the chain. |
The mdrfckr botnet follows what biologists call phylogenetic constraint: certain structures are so deeply integrated into the organism that changing them would require redesigning the entire system. The RSA key, the lockr command, the credential probe, the kill chain order โ these are the botnet's skeleton. The HASSH, password, and persistence directory are its skin. You can change your skin. You cannot change your skeleton.
Chapter 4 โ The Operator Reads Our Research
The most disturbing finding of this investigation is not the botnet's persistence โ it's the operator's awareness. We have direct evidence that the mdrfckr operator monitors published security research and adapts in response.
Evidence Chain
NINGI-WRITEUP-004 (March 2026) documents a credential in the brute-force list that exists for no technical purpose:
This credential cannot succeed on any real system. Its sole purpose is to appear in honeypot logs. The operator knows they are being watched, and they are communicating that knowledge directly through the data channel.
- April 1, 2025: Elastic publishes detailed analysis of HASSH
af8223ac...and.configrc6 - April 25, 2025: Kaspersky publishes
.configrc5directory and XMRig 6.19 analysis - March 2026: NINGI-004 documents Wave 1 behavior, including the taunt credential
- May 5, 2026: NINGI-011 documents Wave 2 with static password
y6ekwUbyoOkk - May 13, 2026: 8 days after NINGI-011: Wave 3 deploys with per-session random passwords
The correlation between publication dates and operational changes is too tight to be coincidental. The operator reads the writeups and responds within days.
Wave 3 uses libssh_0.9.6 instead of Wave 2's libssh_0.12.0. Software normally evolves forward. A deliberate downgrade is an evasion tactic: defenders had fingerprinted the newer version and written detection rules. The older version:
- Produces a different HASSH, bypassing fingerprint-based blocking
- Blends with older infrastructure (many production servers still run libssh 0.9.x)
- Is unexpected โ defenders look for newer versions, not regressions
The mdrfckr operator has integrated published security research into their operational feedback loop. The cycle time from publication to adaptation is less than 2 weeks. This is faster than most organizations' patch cycles. The botnet evolves faster than the defenders.
How does a supposedly unsophisticated Romanian operator maintain a real-time intelligence feed on global security publications? The reading list implied by the operational changes includes: Elastic Security Labs, Kaspersky/Securelist, SANS ISC, multiple independent honeypot researcher GitHub repositories (NINGI, pagzlol, SamJones56), and likely this very publication series.
Two interpretations:
Interpretation A (Occam): The operator has Google Alerts set for "outlaw botnet," "mdrfckr," and "dota3" and reads the results. Simple, effective, requires no special capability.
Interpretation B (Structural): The speed and precision of adaptation suggests either a small team with dedicated intelligence capability, or access to threat intelligence platforms that aggregate security publications. This level of operational awareness costs money โ either through subscriptions, or through access provided by someone with a different interest in the botnet's survival.
The evidence supports Interpretation A for the basic awareness. But the speed of fleet-wide deployment โ 1,000+ nodes updated within 72 hours โ requires infrastructure that exceeds what a solo operator with Google Alerts can maintain.
Chapter 5 โ The lockr Mystery
In every wave, in every variant, in every sample documented by every researcher over 8 years, one command appears that serves no visible purpose:
lockr is not a standard Linux utility. It fails with "command not found" on every host in every wave. It has never been observed to succeed. Yet it has never been removed from the script template.
Hypotheses
The simplest explanation: lockr was once a custom tool on the operator's development machine, was included in the template by accident or convenience, and has never been worth removing. Since it fails silently and doesn't break the chain, there's no pressure to clean it up. Eight years of technical debt in a shell script.
lockr may be a real tool deployed on the operator's own infrastructure โ a custom binary that performs the same function as chattr (managing file immutability) but with additional features like logging or remote control. When the script runs on the operator's machines, it succeeds. On victim machines, it fails harmlessly. The command is a fingerprint of the operator's own environment leaking into the deployment script.
What if lockr is not dead code but a detection mechanism? If the operator plants lockr on select compromised hosts โ perhaps high-value targets or infrastructure nodes โ then its success or failure on a given host tells the C2 server something about the host's classification. A honeypot will never have lockr installed. A previously-compromised host in the operator's own infrastructure might. The command is a membership test disguised as technical debt.
This would explain why it's never been removed despite 8 years of active modification to every other aspect of the script. It's not debt โ it's intelligence.
The lockr command is the single most stable fingerprint of the mdrfckr toolset. It has survived every evolutionary change across 8 years and multiple campaign waves. Whether dead code or deliberate signal, it is the one invariant that connects the 2018 Trend Micro sample to the June 2026 Wave 3 variant with certainty.
Chapter 6 โ The Credential as DNA
Beyond the RSA key, the credential 345gs5662d34:345gs5662d34 serves as the botnet's immune system โ a self-recognition mechanism that distinguishes "self" (already-compromised hosts) from "other" (new targets).
The Re-entry Protocol
When a mdrfckr node connects to a target, it first tries 345gs5662d34:345gs5662d34 as both username and password. This credential only succeeds on hosts where a previous wave set this as the root password (Wave 2 and earlier). If it succeeds:
- The target is already part of the fleet โ refresh the payload, update the miner config
- No need for brute-force โ saves time and avoids generating defensive alerts
- Confirms the fleet's geographic spread without a dedicated C2 check-in mechanism
If it fails, the node falls back to conventional brute-force with common credentials (root:password, root:12345, ubuntu:ubuntu). The credential is a handshake, not an attack.
Wave 3 introduced per-session random passwords, which means new victims can no longer be re-identified by their root password alone. But the RSA key in authorized_keys serves as the persistent marker. The credential probe 345gs5662d34 now functions as a backward compatibility check โ identifying nodes from Waves 1 and 2 that haven't been re-compromised with Wave 3 tooling.
The operator faces a classical distributed systems problem: how do you maintain a fleet of 1,000+ compromised machines without a persistent connection to each one? The answer is biological: mark them. The RSA key is the permanent tattoo. The credential probe is the verbal passphrase. The lockr command is the secret handshake. Together they form a multi-factor authentication system โ not for security, but for fleet management.
This is convergent evolution with legitimate infrastructure management tools. The botnet independently reinvented service mesh identity management, authentication chains, and fleet orchestration โ using shell scripts and IRC instead of Kubernetes and mTLS, but solving the same fundamental problem.
Chapter 7 โ The Survival Theorem
Why has this botnet survived when hundreds of more sophisticated operations have been disrupted? The answer is not technical โ it's architectural. The mdrfckr botnet is optimized for a specific environmental niche, and that niche is expanding.
The Niche
- Linux hosts with SSH exposed to the internet โ the attack surface grows every year as cloud adoption accelerates
- Weak or default credentials โ still common on IoT, dev servers, educational infrastructure, small ISPs
- Low-value individual targets โ each node mines perhaps $0.50โ$2.00/day in Monero, making individual remediation economically irrational for most organizations
- No inter-node dependency โ each infected host operates independently. Taking down 10% of the fleet doesn't affect the other 90%
- Bulletproof C2 hosting โ FranTech/BuyVM at 198.98.56.205 has absorbed abuse reports for 5+ years without acting
This is not a design for maximum impact. This is a design for maximum persistence. The botnet occupies an ecological niche that no defender has sufficient incentive to eradicate:
"The most dangerous organism is not the apex predator โ it's the parasite that causes just enough damage to survive but not enough to kill its host."
โ Ecological principle, applied to information systemsChapter 8 โ The Version History: An Evolutionary Record
Like geological strata, each component version change tells us something about what the operator prioritized at each evolutionary stage.
| Component | 2018 | 2019 | 2024โ2025 | Wave 2 (2026) | Wave 3 (2026) |
|---|---|---|---|---|---|
| Package Name | dota.tar.gz | dota2.tar.gz | dota3.tar.gz | dota3.tar.gz | dota3.tar.gz |
| XMRig Version | N/A (Perl miner) | Early XMRig | 6.19.x | 6.22.1 | 6.22.1+ |
| Persistence Dir | Unknown | ~/.configrc3? | .configrc5 | .configrc6 | Modified |
| Brute-force Tool | haiduc | haiduc v2 | BLITZ (kthreadadd) | BLITZ | BLITZ |
| IRC Backdoor | Perl Shellbot | Perl Shellbot v2 | Stealth Shellbot | Stealth Shellbot | Stealth Shellbot |
| C2 Domain | luci.madweb.ro | Various IPs | bullshit-irc.net | bullshit-irc.net | bullshit-irc.net |
| SSH Library | Unknown | Unknown | libssh 0.9.6 | libssh 0.12.0 | libssh 0.9.6 โ |
| Password Strategy | No change | No change | Pre-set credentials | Static per-wave | Per-session random |
The only component that has continuously evolved is the operational security layer (passwords, SSH fingerprints, persistence locations). The core functionality โ RSA key injection, XMRig mining, BLITZ brute-force, IRC C2 โ has changed minimally. The botnet evolves its camouflage, not its biology.
Chapter 9 โ The HASSH Migration: A Case Study in Botnet Fleet Management
The transition from HASSH af8223ac... to f555226d... is not just a version change โ it's a logistics operation comparable to a firmware update across a distributed IoT deployment. Understanding how it happened reveals the operator's command-and-control capabilities.
Day-by-Day Migration Data
| Date | Wave 2 (af8223ac) | Wave 3 (f555226d) | % Wave 3 |
|---|---|---|---|
| May 5 | 755 | 0 | 0% |
| May 6 | 1,185 | 0 | 0% |
| May 7 | 687 | 60 | 8% |
| May 10 | 620 | 30 | 5% |
| May 12 | 1,506 | 0 | 0% |
| May 13 | 269 | 809 | 75% |
| May 14 | 89 | 990 | 92% |
| May 15 | 19 | 680 | 97% |
| May 17 | 17 | 635 | 97% |
| May 19 | 126 | 2,007 | 94% |
| May 21 | 0 | 563 | 100% |
The transition completed in 8 days (May 13โ21). By May 15, 97% of traffic was Wave 3. The residual Wave 2 traffic through May 19 likely represents infected hosts that hadn't yet checked in with C2 to receive the update. By May 21, the old fingerprint was extinct in our data.
For context: many enterprise organizations cannot deploy a critical security patch across their own infrastructure in 8 days. The mdrfckr operator executed a complete toolkit replacement across a botnet spanning 29 countries in the same timeframe.
How does the operator push updates to 1,000+ nodes? Two possible mechanisms:
A. IRC-based push: All active nodes maintain an IRC connection to 198.98.56.205. A single IRC command in channel #007 can instruct every connected bot to download and execute a new toolkit version. This explains the sudden switchover โ it's a broadcast.
B. Cron-based pull: The persistence cron entries (5 6 * * 0, 0 0 */3 * *) periodically re-download the payload from C2. If the operator replaces the payload on the C2 server, every node that checks in will get the new version. This explains the 8-day tail โ nodes on weekly cron schedules take up to 7 days to update.
The data supports a hybrid model: IRC-connected nodes received an immediate push on May 13 (explaining the sudden 75% switchover), while cron-dependent nodes trickled in over the following week. This dual-channel update mechanism provides both speed and reliability โ exactly the properties a legitimate deployment system would optimize for.
Chapter 10 โ The Arms Race We're Losing
The mdrfckr botnet's evolutionary trajectory reveals an uncomfortable truth: the botnet is winning the arms race. Not through superior technology โ through superior adaptation speed.
The Adaptation Asymmetry
| Defender Action | Defender Timeline | Operator Response | Operator Timeline |
|---|---|---|---|
| Elastic publishes HASSH fingerprint | Months of research + review | Switches to different HASSH | ~2 weeks |
| Kaspersky documents .configrc5 | Months of analysis | Migrates to .configrc6 | Days |
| NINGI-011 documents static password | Active honeypot monitoring | Deploys per-session random | 8 days |
| AbuseIPDB reaches 100% score on IPs | Ongoing abuse reports | 1,312 new IPs recruited | Continuous |
| Our dossier series published | Weeks of investigation | ? | Expected: <2 weeks |
The defender's research cycle (weeks to months) is longer than the operator's adaptation cycle (days). By the time a detailed analysis is published, the specific indicators it documents are already obsolete. The publications serve primarily as a to-do list for the operator: a checklist of what to change next.
"We publish our research to help defenders. But the first reader of every security report is the attacker it describes. Our papers are their patch notes."
โ Implicit lesson of the mdrfckr adaptation timelineWhat Still Works
Despite the operator's adaptation speed, the immutable core provides permanent detection opportunities:
lockr -ia .sshโ appears in every variant since at least 2024. Universal detection rule.ssh-rsa AAAAB3...oRw== mdrfckrโ the RSA key. Checkauthorized_keyson any Linux host.345gs5662d34:345gs5662d34โ the handshake credential. Will always be present.dota3.tar.gzโ the payload package name. Has incremented only twice in 8 years.kswapd0โ XMRig binary disguised as kernel thread. Name unchanged for years.- Competitor displacement:
rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh
Chapter 11 โ What Comes Next
If the operator follows their established pattern, publishing this dossier series will trigger specific responses. Based on 8 years of observed behavior, we can predict:
Expected Adaptations (High Confidence)
- New HASSH fingerprint: A third SSH library variant within 2โ4 weeks of this publication
- Persistence directory change:
.configrc7or an entirely new naming convention - XMRig update: Version increment to 6.23.x or newer, possibly with new disguise name
- New credential taunt: Expect a credential referencing "shuffle-on" or "LSN" in the next wave
Possible Adaptations (Medium Confidence)
- IRC C2 migration: If we've brought sufficient attention to
198.98.56.205, the operator may establish a backup C2 on a different BPH provider - Package name change:
dota3.tar.gzโdota4.tar.gzor something less distinctive - Competitor displacement update: New target filenames as the rival malware ecosystem evolves
Things That Won't Change (High Confidence)
- The RSA key โ changing it risks fleet fragmentation
- The
345gs5662d34credential โ the fleet's self-recognition mechanism - The kill chain order โ functionally optimized, no room for improvement
- Monero mining โ the only viable cryptocurrency for this operation model
- The operator's language โ Romanian cultural markers will persist in any new code
By publishing this prediction, we create a decision tree for the operator. If they change what we predicted, they confirm they read our work. If they don't change it, they either didn't read it or decided the predicted changes are unnecessary. Either outcome provides intelligence. The act of publishing predictions about a reactive adversary turns every future observation into a data point about the operator's capabilities, priorities, and information sources.
This is not a bug in the process โ it's the only way to study an adversary that reads your publications. You make predictions. You watch what happens. The deviation between prediction and reality is where the real intelligence lives.
Chapter 12 โ The Botnet as Organism: A Final Analysis
Over six dossiers, we have dissected the mdrfckr/Outlaw botnet from every angle: its kill chain, its infrastructure, its operator, its economics, its victims, and now its evolution. The picture that emerges is not of a sophisticated cybercrime operation โ it's of an organism.
- Reproduction: BLITZ brute-forcer scans and compromises new hosts โ asexual reproduction through infection
- Metabolism: XMRig converts stolen CPU cycles into Monero โ energy conversion
- Immune system: Competitor displacement kills rival malware โ interspecific competition
- Self-recognition:
345gs5662d34credential identifies fellow organisms โ immune self/non-self distinction - Adaptation: HASSH rotation, password randomization โ mutation under selection pressure
- Phylogenetic constraint: RSA key,
lockr, kill chain order โ conserved core genome - Ecological niche: Weak SSH credentials on internet-facing Linux โ habitat specialization
- Persistence strategy: Cron jobs, IRC backdoor โ dormancy and reactivation mechanisms
The mdrfckr botnet is not a tool that someone runs. It is an entity that lives on the internet. Its operator is less a programmer and more a rancher โ tending a herd of compromised machines, updating their toolkit when predators (security researchers) get too close, moving them to new pastures (new HASSH fingerprints) when the old ones are grazed bare.
"Eight years, zero arrests, and growing. Every published report becomes a checklist for the next adaptation. Every defensive measure becomes a selection pressure that makes the next variant stronger. The mdrfckr botnet has achieved what every organism strives for: it has become endemic. It is not an infection to be cured โ it is a permanent feature of the internet's ecosystem."
โ Conclusion of the SSH Parasite investigationIn eight years, no law enforcement agency has made a public arrest related to the Outlaw/mdrfckr botnet. Not Interpol. Not the FBI. Not Romania's DIICOT. Not Europol's EC3. This despite:
- Multiple published attribution paths pointing to Romania
- A fixed C2 server on US soil (198.98.56.205, Las Vegas, NV) for 5+ years
- Romanian-language artifacts in the code dating to 2018
- IRC operator nicknames that are common Romanian first names
- A known hosting provider (FranTech) with a documented history of abuse tolerance
- At least 200,000 documented victim hosts worldwide
The question is not "who is mdrfckr?" โ the attribution evidence is overwhelming. The question is: "why has no one acted on the attribution?"
Possible answers, in decreasing order of charity:
- Crypto mining botnets fall below law enforcement priority thresholds (probable)
- Cross-border prosecution between Romania and the US is procedurally complex (true but insufficient)
- The individual damage per victim is too small to pursue (systemic issue)
- The operator has information or relationships that make prosecution inconvenient (unverified)
- Someone with authority benefits from the botnet's continued operation as an intelligence collection platform (paranoid but not impossible โ compromised government telcos in PK, VE, KZ are useful for signals intelligence)
The most boring explanation is usually the right one: nobody cares enough to stop it. And that is the most damning indictment of all.
Series Conclusion โ The SSH Parasite
This six-part investigation has traced a single SSH key comment โ mdrfckr โ from its first appearance in a 2018 Trend Micro report to its continued presence in our honeypot logs today. Along the way, we documented:
- 025A โ The Anatomy: The kill chain that makes infection autonomous
- 025B โ The Infrastructure: 81 confirmed botnet nodes across 29 countries
- 025C โ The Operator: Romanian attribution, IRC C2 on FranTech's bulletproof hosting
- 025D โ The Economics: $0.50โ$2.00/day per node ร 1,000+ nodes = quiet income
- 025E โ The Victims: Education networks, cloud instances, state telcos โ the geography of neglect
- 025F โ The Evolution: Eight years of adaptation and the fingerprint that never dies
The mdrfckr botnet is not the most dangerous threat on the internet. It is not the most sophisticated. It is not the most profitable. But it may be the most durable. And in that durability lies its lesson: the internet's security model is optimized for dramatic incidents, not chronic infections. A ransomware attack on a hospital makes headlines and triggers law enforcement. A botnet that silently steals CPU cycles from 1,000+ servers across 29 countries for 8 years generates reports that nobody with enforcement authority reads.
The parasite thrives not because it is strong, but because the host โ the global internet infrastructure โ is structured so that no one is responsible for removing it.