How a miner gets there
- A web shell or a vulnerable application, which gives the attacker the web server's user and a writable temp directory.
- Stolen or guessed SSH credentials.
- An exposed service: a Docker API, a Redis or database port, an admin panel.
- A dependency or image that arrived with the miner already inside.
Signal one: where it runs from
Malware that lands as an unprivileged user has to run from somewhere that user can write, so it runs from /tmp, /var/tmp or /dev/shm, and it usually deletes its own file once it is in memory. The agent walks /proc and reports any process whose executable resolves into a world-writable temp directory, deleted or not, with the PID, the path and the command line. It deliberately does not report every process with a deleted executable: a routine package upgrade leaves long-running daemons pointing at a deleted file all the time, and a detector that cannot tell a miner from an apt upgrade does not survive its first week.
Signal two: the numbers, against this server's normal
A fixed CPU threshold is wrong for every server: too low for a build box, too high for a database. SecAI compares each server with its own baseline and opens a finding when CPU, memory or outbound data volume stays above it for five consecutive reports, which is five minutes, and closes the finding by itself after five calm reports. A miner throttled to a third of the CPU still moves a quiet server's baseline; on a busy one, the other four signals carry it.
Signals three and four: the dropper and the schedule
The files that install a miner say so: a pool address beginning stratum+tcp://, an xmrig configuration, a cryptonight algorithm flag. The agent looks for those markers in PHP files and shell scripts under web roots. And because a miner that does not restart is a miner that lasts until the next reboot, the change to the schedule is watched too: when a cron file or crontab changes, the text before and after travels with the finding, and the platform rates the new line, routine, review or suspicious, where suspicious includes a download piped into a shell, code run from /tmp or /dev/shm, an encoded command, and a known miner.
Signal five: who it talks to
A miner has to reach its pool. The agent reads the kernel's connection tables, never the packets, and reports an outbound connection to a destination the server has not used before, with the remote address, the port and the process that owns the socket. On a server whose outbound traffic is a handful of known destinations, a new long-lived connection from a process in /dev/shm is not a subtle finding.
What SecAI does about it, and what it does not
Each signal is a finding with its evidence, rated by one policy, in the dashboard, in the alert email if it is critical and in the daily summary otherwise. SecAI does not kill a process, on any setting: a wrong kill on a production server is worse than the miner. If the miner drives the machine into genuine exhaustion and you have set that server to Protect, the agent may cap, throttle or freeze the one process group responsible and undo it when the episode ends; every server starts at record only. Removing the miner, and the way it got in, is yours: the persistence findings tell you where it will come back from.
After you find one
- Do not reboot first. The process in memory and its open connections are the evidence of how it arrived.
- Note the executable path, the command line and the owning user from the finding; the user tells you which door was used.
- Look for the restart mechanism: cron, a systemd unit or timer, an authorised key, an extra account. SecAI reports changes to all four.
- Close the door: the vulnerable application, the exposed port, the reused password. A miner that is removed without that returns within days.