How cryptojacking works
Mining is a race to compute hashes, and the reward goes to whoever contributes computation. On your own hardware that costs electricity and machines; on someone else's server it costs the attacker nothing. MITRE ATT&CK classes this as resource hijacking, and its compute hijacking entry lists XMRig, which mines Monero, among the tools used by many of the groups it documents. Monero suits this because its mining algorithm is designed to run on ordinary CPUs rather than specialised hardware.
Once the attacker has a foothold, the sequence is usually the same: download a miner into a writable directory, start it pointed at a mining pool (the configuration often contains a stratum+tcp:// address), add a way to restart it, and sometimes disguise it under a name that looks like a kernel thread. MITRE also notes that some mining malware looks for competing miners and kills them.
How miners get in
- Weak or reused SSH passwords, found by brute force.
- Services that should not be public: a Docker API without authentication, Redis, a database, an admin panel.
- Vulnerable web applications and plugins, which give the attacker the web server's user and a writable temp directory.
- Leaked cloud access keys, used to start new instances for mining rather than to touch the existing server.
- A container image or dependency that arrived with the miner already inside.
What it costs
- Performance: the miner takes CPU your services need, so pages slow down and jobs run late. CISA lists degraded system performance, higher electricity costs and wear from heat among the effects.
- Money: on cloud instances billed by usage, with burstable CPU credits or autoscaling, someone else's mining becomes your bill. Leaked cloud keys can produce instances you never see from the server at all.
- Your provider's attention: a hosting provider that sees mining traffic may warn you, restrict the server or suspend it under its terms of service.
- The real cost: a miner means someone has run code on your server, with whatever access that gave them. The same access can read data, add keys or be sold on. Treat the miner as the symptom you happened to notice.
Signs on a Linux server
- Sustained high CPU, often on every core, that does not match traffic or scheduled work. Careful miners throttle themselves, so a modest but constant rise counts too.
- A process whose executable is in /tmp, /var/tmp or /dev/shm, often with the file already deleted from disk.
- A process named like a kernel thread, such as kworker, that has an executable file behind it. Real kernel threads do not.
- Long-lived outbound connections to unfamiliar addresses, often on unusual ports, from a process you did not start.
- Persistence: a new cron line, a systemd service or timer, or an extra authorized_keys entry that brings the miner back.
- Strings such as stratum+tcp://, xmrig or cryptonight in scripts, configuration files or a crontab.
The manual checks are in the guides below. Where the attacker may have root, ps, top and the logs can be made to lie; an /etc/ld.so.preload entry is one known way to hide a miner from them.
How to detect a cryptominer: the commandsInvestigate suspicious processesFind cron and systemd persistenceCheck outbound connections
Why killing the process is not the fix
Ending the miner makes the CPU graph look normal and changes nothing else. The persistence starts it again on its next scheduled run or at the next boot, the hole it came through is still open, and any key or account the attacker added still works. Killing it first also destroys evidence: the running process, its open connections and its memory are what tell you how it arrived.
Remediation means answering three questions: how did they get in, what else did they do, and can this server still be trusted? Preserve the evidence first (save the process details, connections and suspicious file paths to another machine, with timestamps), then find the entry point and the persistence. If the miner ran as root, if you find persistence you cannot fully explain, or if the server holds customer or regulated data, rebuild from a known-good image rather than cleaning in place, and consider professional incident response help; notification duties may apply.
Linux incident response checklistSigns a Linux server has been hacked
What cryptojacking is not
- Legitimate mining: the same software, run by the owner, on hardware they pay for. The difference is authorisation, not the program.
- Browser cryptojacking: a mining script injected into a website that uses visitors' CPUs. Your server may host the script, but the mining happens on other people's machines; it is a sign the site was modified.
- Malware in general: a miner is one payload among many. The same entry point can deliver a botnet client, a proxy that resells your bandwidth, or data theft. MITRE groups mining with bandwidth and cloud service hijacking under resource hijacking.
How SecAI connects
SecAI reports three of the signs above from the server itself. Any process whose executable resolves into /tmp, /var/tmp, /dev/shm or /run/shm is reported with its PID, path and command line, whether or not the file has been deleted; a deleted binary elsewhere is not flagged, because package upgrades cause that constantly. Miner markers (stratum+tcp://, xmrig, cryptonight) in PHP files and shell scripts under web roots, and a new cron line that runs a known miner, are reported with quarantine of the file proposed; quarantine waits for a person and is never pre-approved, and the file scanning runs on Pro plans and above. CPU, memory or outbound volume above the server's own baseline for five consecutive reports is an alert that closes itself after five calm ones.
SecAI never kills the process, does not clean the server and cannot prove it clean. It gives you dated evidence to start from; the investigation and the decision to rebuild stay with you.