Research Blog

Honeypot observations

How SSH bots try to replace authorized_keys

15 October 2026 · Jorge Aquino · Revision 2

Internet-facing SSH services receive automated login attempts. This post examines a command sequence recorded by a decoy after a login: it attempts to remove existing SSH keys and install a new one. The sensor recorded commands, not a successful takeover of a real account.

Volume

Counts from one 24-hour window, 14 October 01:00 to 15 October 01:00 UTC:

One 24-hour window.
What I countedCount
SSH sessions7,602
Distinct source addresses161
Login attempts7,405
Commands typed7,556
File transfers151

That averages about 47 sessions per source address. The volume is consistent with automated activity, but a source address does not identify an individual bot or operator.

Recurring command patterns

Over the seven days from 8 to 15 October, two multi-step patterns came up again and again, almost the same number of times:

cd ~ ; chattr -ia .ssh ; [EXECUTABLE] -ia .ssh

Seen 150 times in seven days.

cd ~ && rm -rf .ssh && mkdir .ssh && echo [SSH_KEY] >> .ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

Seen 146 times in seven days.

My publishing filter replaces anything that might be sensitive or unrecognized with a placeholder like [SSH_KEY], which is why you see those brackets. Other operators have reported the two patterns in sequence. The aggregate counts from this sensor do not show how often they occurred in the same session.

Observed commands and evidence to check on a host
Observed patternWhat it establishesWhat to verify on a host
Attribute changes · 150 observationsThe sensor recorded commands attempting to clear directory flags.Check process or audit logs for attribute changes on SSH directories.
Directory and key replacement · 146 observationsThe sensor recorded commands attempting to replace the SSH directory and add a key.Compare authorized keys and file changes with the account’s approved configuration.

What each step does

  1. chattr -ia .ssh removes the immutable and append-only flags from the SSH folder. Admins, and rival bots, sometimes set those flags so the folder can't be changed. This step undoes that.
  2. [EXECUTABLE] -ia .ssh repeats the same flags with a program my filter didn't recognize, so it was replaced with a placeholder. Other honeypot operators record a program called lockr in this position, which their fake shells answer with "command not found." It looks like a backup in case chattr was renamed or removed.
  3. rm -rf .ssh attempts to delete the folder and any existing authorized keys. On a real host, a successful deletion could lock out the owner and competing actors.
  4. mkdir .ssh and echo [SSH_KEY] >> .ssh/authorized_keys recreate the folder with a single key: the attacker's.
  5. chmod -R go= ~/.ssh removes group and other permission bits. That can satisfy part of the server’s permission checks. Acceptance also depends on ownership, the effective SSH configuration, and the key itself.

If this sequence succeeds on a real host, a guessed password can become key access that survives a password change. Rotating the password alone would not remove the planted key. MITRE ATT&CK lists this as T1098.004, SSH Authorized Keys.

Corroborating reports

Other honeypot operators have recorded this same chain, step for step, for years. In public write-ups the planted key ends with the comment mdrfckr, which is how the campaign got its name (port22, 2023; DEV Community, 2026). Some researchers link it to the Outlaw (also called Dota) cryptomining group. Others say the bot is separate from that group. I'm not attributing it to anyone.

One limitation is self-imposed. Keys are redacted before publishing, so the public data on this page cannot show whether this sensor received that exact key. The claim here is limited to the commands matching the published reports.

Detection and hardening

  • Review the configured authorized-key sources, including those for privileged accounts, against approved keys. A matching key comment is a clue. Preserve evidence and confirm unexpected changes before removing keys.
  • Where key-only access is intended, check the effective SSH configuration for password and keyboard-interactive authentication, and verify key access before changing login policy. The observed sequence requires sufficient access to modify the account’s files.
  • Get an alert when any authorized_keys file changes, for example with an auditd watch or file-integrity monitoring.
  • Limit or block repeated failed logins with tools like fail2ban or a cloud firewall rule.

How this data was collected

The Threat Observatory publishes delayed sensor data. The snapshot used in this article omits source addresses, typed passwords, and key material. A command pattern is only published if every word is on a fixed list of known commands, flags and paths. Anything else is either replaced by a placeholder or dropped. The figures on this page come from one Observatory snapshot, published 15 October 2026 at 02:00 UTC.

Limits: this is one sensor, one protocol and one week. It doesn't measure how common these attacks are across the internet. A login to a honeypot is not access to a real machine, and a command I recorded is an attempt, not proof it would have worked. Revision 2 clarifies the evidence and hardening guidance. Corrections are welcome at contact@vardrsec.com.

Sources