What it is
Mirai is a family of botnet programs. Each copy takes over a device or Linux machine and waits for orders, mostly to flood a website or network with traffic until it falls over (a DDoS attack). Its source code was published in 2016, so many different groups run their own versions. The version our own sensor caught in October 2026 hides a copy of itself in /var/tmp on a Linux server and sets up three separate ways to start again after a restart.
How it gets in
Mostly through default or weak passwords, and through software on internet-facing devices and servers that hasn't been updated.
Close the door: Change all default passwords to strong unique ones, patch device firmware as updates appear, disable UPnP on routers unless needed, and keep IoT devices on a separate network from systems critical to daily operations.
How to tell if you have it
Signs published for this threat. One sign alone proves little: names get reused, and newer versions change them. Look for several together.
| Kind | Sign |
|---|---|
| File name | /var/tmp/.sys_recovery.sh |
| File name | /etc/cron.d/netupd |
| Process name | configd |
| Process name | httpd |
| Scheduled task line | @reboot root /bin/sh /var/tmp/.sys_recovery.sh & |
| Startup entry | /etc/systemd/system/netd.service |
| Startup entry | /etc/init.d/sys_daemon |
These commands only look. They change nothing.
Look for the known file locations
sudo ls -la /etc/cron.d/netupd /etc/init.d/sys_daemon /etc/systemd/system/netd.service /var/tmp/.sys_recovery.sh 2>/dev/nullLook for the known process names, and where each one runs from
for p in $(pgrep -f 'configd|httpd'); do echo "$p $(sudo readlink /proc/$p/exe)"; doneList running programs that live in a temporary folder (real software almost never does)
sudo ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/(tmp|var/tmp|dev/shm)/'Check every scheduled task for the known lines
sudo grep -rnF -e '@reboot root /bin/sh /var/tmp/.sys_recovery.sh &' /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/nullFingerprint a suspect file and compare it with the list below
sudo sha256sum /path/to/suspect-fileKnown file fingerprints (SHA-256). A match identifies that exact file; newer builds differ.
How sure these signs are: Versions differ, so a file name or fingerprint from one version tells you nothing about another. The files and startup entries listed here come from the one sample we caught: one sensor, one day. The process names configd and httpd come from a different version, and normal software uses the same names, so neither proves anything on its own. A restart does not remove the version we caught, because it has three ways to start itself again.
How to remove it by hand
Work through these in order. Don't skip the first two.
- Save evidence before you change anything: run the checks above and keep their output, and copy each suspect file somewhere safe along with its SHA-256 fingerprint.
- Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. That stops it being used in attacks while you work.
- Remove all three ways it restarts itself, first. Delete /etc/cron.d/netupd if it only holds the @reboot line shown above. Run sudo systemctl disable --now netd.service, delete /etc/systemd/system/netd.service, then run sudo systemctl daemon-reload. Delete /etc/init.d/sys_daemon (on Debian or Ubuntu, also run sudo update-rc.d -f sys_daemon remove). If you remove only one or two, it comes back.
- Stop the restart script before the bot, or it starts the bot again: find processes running /var/tmp/.sys_recovery.sh and stop them with sudo kill -9 followed by the process number. Then stop every process whose program lives in /var/tmp; the process check above shows where each one runs from.
- Delete /var/tmp/.sys_recovery.sh and the bot's own copy in /var/tmp. The copy is a hidden file with a random name, so find it by its fingerprint, not its name.
- Run the checks above again. Then restart the server and check once more. Nothing should come back.
- Before you reconnect: change every password on the server, switch SSH to key logins, and install all updates.
- If you find anything you can't account for, or the attacker had full control (root), rebuild from a fresh install instead of trusting the cleanup.
These steps are provided as-is, without warranty. Run them at your own risk, and back up first. If you're unsure, rebuild from a known-good install.
What Minaki Scan does about it
Minaki Scan finds this threat by the fingerprints of its files and processes and removes it, but only after you type yes. It backs up what it changes and logs every change on your server.
Minaki Scan checks your server for this and every other threat in this wiki, explains each finding in plain English, and never changes anything without your OK. $1 per server a month. Downloads open soon.
Caught by our sensors
Our honeypot sensor in US West (San Jose) caught a sample on 14 Oct 2026, 13:16 UTC. We label it Mirai-lineage: it shares markers with this family, so treat the name as our best reading, not a certainty.
On a sealed test machine it planted: /var/tmp/.MGdneGj7, /var/tmp/.sys_recovery.sh, /etc/cron.d/netupd, /etc/systemd/system/netd.service, /etc/init.d/sys_daemon. Our cure removed every one, and a restart test (setting off each way it had set itself up to start again) brought nothing back.
Sources
This page is written by MinakiLabs in our own words. The facts above come from this published research; credit and thanks to its authors.
- SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
- IoT Under Siege: The Anatomy of the Latest Mirai Campaign Leveraging Multiple IoT Exploits, Palo Alto Networks Unit 42 (2023-06-22)
- Analysis of Mirai Botnet Variant Aquabot, Antiy Labs (2023-12-25)
- Heightened DDoS Threat Posed by Mirai and Other Botnets, CISA (US-CERT) (2016-10-14)
- New Mirai Variant Uses Multiple Exploits, Trend Micro (2019-05-23)