Malware
Rootkit
Rootkit is malware built to hide itself and other malware from the person running the system. It tampers with what tools report, so the machine tells you it is clean.
How it is measured
You look from outside the lie. Compare views: a process list or file listing from the running system against one taken from a trusted live disk or a memory dump. Mismatches, hidden processes, and open ports not shown by netstat are signs.
On a web host, common clues are a shared library preloaded through /etc/ld.so.preload, a kernel module you did not load, or ps and ls binaries that differ from the distribution package hashes. Package verification such as rpm -V or debsums checks the second.
Worked example
A VPS runs at 90 percent CPU, but top shows only nginx and php-fpm at 3 percent. Network graphs show a steady 8 Mbps to port 3333 on a foreign IP. cat /etc/ld.so.preload names /usr/lib/libsystem.so, a file that ls will not display in its own directory.
Booting from a rescue image reveals the library and a miner binary. The admin does not clean in place. Because the rootkit sat below the tools, the only safe move is to rebuild the server from a clean image and restore data only.
How it differs
A backdoor is a way back in. A rootkit is a way to stay unseen, and it often protects a backdoor. A backdoor can be a plain file anyone could spot; a rootkit makes the operator's own commands lie.
Common errors
Running the scanner inside the compromised system and trusting the output. Deleting the miner binary and leaving the preload entry. Assuming rootkits are only a Windows problem. Rebooting and thinking that cleared it. Restoring a full-system backup taken after the intrusion.
In practice
If you suspect one, stop trusting the host: take a snapshot for analysis, compare it offline, then rebuild from a known-good image and restore only data. Keep package verification and file-integrity baselines on servers so differences show up before a rootkit settles in.