The session
One telnet login, root / password, from an ISP in Venezuela. What followed took about twenty seconds:
- Type the words that drop various routers' management consoles to a Linux shell:
enable,system,shell,sh,linuxshell, andping ;sh. - Print a marker,
__SRDY__, so the controller knows a shell is answering. - Find BusyBox in one of five usual places and use it for everything after.
- Rename the device:
hostname PBOC. - Test 24 directories, from
/tmpto/userdata, by writing an empty file in each and running it, to learn where it can both write and execute. Two of the paths are missing a slash (/media.b,/userdata.b), so those two tests check the wrong place. - Write a script,
.k, in seven chunks of hex withecho -ne, and run it ten times in a row.
Nothing else. No download, no bot. Writing files with echo instead of downloading them is how loaders reach devices that have no wget, curl or tftp; here it delivered a cleaner rather than a bot.
The script
#!/bin/sh
for proc_dir in /proc/*; do
pid=${proc_dir##*/}
result=$(ls -l "/proc/$pid/exe" 2> /dev/null)
if [ "$result" != "${result%(deleted)}" ]; then
kill -9 "$pid"
fi
done
For every process, look at /proc/PID/exe, the link to the program file the process is running. If the link's description ends in (deleted), kill the process with no chance to clean up.
Why that finds rivals
Linux keeps a running program alive after its file is deleted, and marks the exe link (deleted). Mirai and many of its descendants delete their own executable right after starting, so there is no file left on disk to find. The same habit that hides them from a search of the filesystem makes them stand out here. The script does not need to know any rival's name. It kills the category.
Running it ten times in a row is probably meant to catch anything that respawns between passes. That is a guess; the session does not say.
Why that would hurt a real server
Malware is not the only thing that runs from a deleted file. When a package upgrade replaces a program, the new file takes the old one's place and a service that is still running keeps the old, now deleted copy until it is restarted. Its exe link reads … (deleted) too. Tools that tell an administrator which services need a restart after an upgrade look for exactly this condition, among others.
On a server that was patched but not yet restarted, this script would kill -9 those services: the SSH daemon, the web server, the database, whichever were waiting. On the routers and cameras these toolkits are written for, upgrades that work this way are rare, so the damage would mostly fall on rival bots. On a general-purpose Linux machine, it would not.
Check your own machines. As root, ls -l /proc/*/exe 2>/dev/null | grep '(deleted)' lists every process running from a deleted file. Each one is either a service that needs a restart after an upgrade, or something that deleted itself after starting. Both are worth knowing about.
The same toolkit, two hours earlier
At 20:18 UTC the same evening, a session from an address on a Chinese backbone network ran the identical opening, step for step, through hostname PBOC and the first directory test, and then stopped. Two addresses on two continents running one script suggests a toolkit spreading through devices it has already taken, rather than one operator typing.
What PBOC means, I do not know. It changes the device's name, so it shows up in the device's prompt and anywhere the name is reported, which makes it a convenient mark for whoever comes looking later.
What the blocklist does with it
Both addresses are on the blocklist's loader tier. Neither is named here. One session each is not sustained activity, and both are most likely someone else's compromised device.
What I can and cannot say
| Claim | Confidence |
|---|---|
| What the script does | High. Seven lines, read directly. |
| It is meant to remove rival malware | Likely. It is the common reason for this pattern; the script carries no comment saying so. |
| It would kill services awaiting a restart on a patched server | High, on general-purpose Linux. That is how the exe link behaves after a file is replaced. |
| The two sessions share a toolkit | High. Identical sequences, including the hostname. |
| What the toolkit installs next | Unknown. Neither session got that far. |
Remaining gaps
The next step. A cleaner usually runs before a bot is installed. Neither session installed one, so the family behind PBOC is unknown.
The marker. __SRDY__ and PBOC are distinctive, but I have not searched for them outside these logs.
Indicators
.k (assembled) 0c99433c7d433d65ab890dcee20b330f262379d532bc76f91e18f09ecfa5fb54, 202 bytes Hostname PBOC Marker __SRDY__ Test files .b in up to 24 directories, then .k in the last one