What it is
Reptile is a rootkit, a tool that hides an attacker's presence, published openly as source code and used against Linux servers and virtual machines. It loads as a kernel module (an add-on that runs inside the core of the operating system) and can hide files, processes and network connections, and even take itself off the list of loaded kernel modules. It also gives the attacker a backdoor for running commands on the server from outside. Because it works from inside the core of the system, a server with Reptile can't be trusted to check itself.
How it gets in
In the cases researchers studied in Korea, how it got in was never found. In another case it was installed after attackers broke in through unpatched internet-facing devices and the software that manages virtual machines.
Close the door: Keep exposed and virtualisation-management software patched, restrict administrative interfaces, and monitor for new kernel module loads and unexpected edits to rc scripts, udev rules and systemd units. Where possible, enforce module signing or disable module loading after boot.
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 location | /reptile/ |
| File location | /etc/intel_audio/ |
| File location | /var/lib/fwupdd/<unique_keyword>_cmd |
| File location | /lib/modules/<kernel_version>/kernel/drivers/<unique_keyword>/<unique_keyword> |
| File location | /usr/bin/<unique_keyword> |
| File name | reptile_cmd |
| File name | reptile_shell |
| File name | intel_audio.ko |
| File name | intel_audio_start |
| File name | intel_audio_reverse |
| File name | gvfs-gdb-volume-monitor |
| File name | 99-bubba.rules |
| File name | bubba_loader |
| File name | bubba_icmp |
| File name | bubba_reverse |
| Startup entry | rc.local |
| Network port | 5214 |
These commands only look. They change nothing.
Look for the known file locations
sudo ls -la /etc/intel_audio/ /reptile/ 2>/dev/nullSearch for the known file names (slow on big disks)
sudo find / -xdev \( -name 'reptile_cmd' -o -name 'reptile_shell' -o -name 'intel_audio.ko' -o -name 'intel_audio_start' -o -name 'intel_audio_reverse' -o -name 'gvfs-gdb-volume-monitor' -o -name '99-bubba.rules' -o -name 'bubba_loader' \) 2>/dev/nullList 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 the known startup entries, wherever they are installed
systemctl list-unit-files --no-pager 2>/dev/null | grep -F -e 'rc.local'; sudo ls -la /etc/init.d/rc.local 2>/dev/nullCheck for programs using the known ports
sudo ss -tunap | grep -E ':(5214)\b'How sure these signs are: Reptile hides its files, processes, connections and itself, so a check run on the infected server can miss it, and finding nothing does not prove the server is clean. Because anyone can build it, attackers rename its folders and files: the default names reptile_cmd, reptile_shell and /reptile/ were changed in both reports, and intel_audio.ko and /etc/intel_audio/ are disguised names from particular cases. gvfs-gdb-volume-monitor copies the name of a desktop program, so judge it by its folder and fingerprint. rc.local is a normal file; only an added line that loads a kernel module is a sign. Port 5214 was seen in one case only, because each build chooses its own. No SHA-256 fingerprints have been published. These signs come from reports up to 2024.
How to deal with it
Removing it in place isn't safe. Here is what to do instead, in order:
- Don't try to clean it in place. Plan to rebuild the server from a fresh install.
- Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence from a rescue disk or a copy of the whole disk, because the running system hides things from you: install folders such as /etc/intel_audio/ and /var/lib/fwupdd/, startup scripts including rc.local, udev rules such as 99-bubba.rules, systemd services, and any kernel module files under /lib/modules you don't recognise, especially under kernel/drivers.
- Copy off your data: databases, website files and documents. Don't copy programs, kernel modules, startup scripts, udev rules or systemd services; any of those could bring it back.
- Reinstall from a fresh image, install all updates, then restore only the data you copied and checked.
- From a clean computer, change every password, key and TLS certificate that was on the server, and cancel the old ones. Check any other system that used the same passwords or keys.
- Before you reconnect, update internet-facing software and virtual machine management software, and limit who can reach admin pages. If your system supports it, allow only signed kernel modules, or block new ones from loading after start-up. Keep watching for new kernel modules and unexpected changes to startup scripts.
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 looks for this threat and reports it only when at least two signs agree. It never tries to remove it: it tells you to back up your data and rebuild.
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.
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.
- Reptile Malware Targeting Linux Systems, AhnLab ASEC (2023-07-21)
- Cloaked and Covert: Uncovering UNC3886 Espionage Operations, Mandiant (Google Cloud) (2024-06-18)
- SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)