Server-side malware has changed shape
The "antivirus on a server" model is obsolete. Production server malware in 2026 looks like: a compromised dependency, a webshell, a cryptominer, a backdoored CI runner, a credential-stealer running as a sidecar.Prevention
- Patching cadence — most malware exploits known CVEs
- Reduced attack surface — only run services that need to run
- Hardened SSH — keys only, no root, fail2ban for brute force
- WAF — for the L7 attack vectors
- Outbound restrictions — production servers shouldn't make arbitrary outbound connections
- Dependency hygiene — image scanning, dependency scanning
Detection
- File integrity monitoring (AIDE, Tripwire, Wazuh) — alerts on changes to critical paths
- Process anomaly detection (Falco, Tetragon) — alerts on processes that shouldn't be running
- Network anomaly detection — unexpected outbound, DNS to suspicious domains
- Resource anomaly detection — CPU spike at 3 AM = cryptominer
- Authentication anomaly detection — login from unexpected IPs / geos
Webshells specifically
The most common server-side malware in compromised LAMP stacks. Detection:- File integrity monitoring on web roots — any new .php / .jsp / .aspx file is suspicious
- Pattern matching for known webshell signatures (yara)
- Behavioural detection — webshells often spawn unexpected child processes
- Server-side request log review — webshells receive POST requests with unusual patterns
Cryptominers
- Sustained high CPU on a server that shouldn't be CPU-bound
- Outbound connections to known mining pool domains
- Unusual processes (xmrig, named to look innocuous)
Outbound restrictions are the most effective single mitigation.
Credential stealers
Programs that read environment variables, AWS metadata, /etc/shadow, SSH keys. Mitigations:- No long-lived credentials on hosts; OIDC federation
- Strict IAM scoped per service
- Shadow keys / sentinel data — if anything reads them, you have an intruder
- Audit logging on sensitive file access
Persistence mechanisms — where to look
- New systemd services
- Cron jobs (/etc/crontab, /etc/cron.d, user crontabs)
- SSH authorized_keys for any user
- LD_PRELOAD-style hooks
- Modified init scripts
- Modified package binaries
- Container persistence (modified images, sidecar containers)
Response
- Contain — isolate the affected host. Snapshot for forensics. Don't shut down (loses memory state)
- Investigate — vector, scope, exfiltration, timeline
- Eradicate — rebuild from a known-clean state. Not "clean up" — rebuild
- Recover — bring services back, with new credentials (assume everything on the compromised host is leaked)
- Lessons learned
The "we cleaned the malware" approach is unreliable. Persistence mechanisms are easy to hide; rebuilding is the only certainty.
EDR / XDR
Commercial endpoint detection (CrowdStrike, SentinelOne, Microsoft Defender for Servers) centralise the detection-response pipeline. For cost-conscious teams, Falco / Wazuh / OSSEC get most of the value.One pattern we'd warn about
Running antivirus on Linux servers and considering it sufficient. Modern threats are not signature-detected. Behavioural monitoring is what works.One pattern that always pays off
A tested incident response runbook. Who's called, what's snapshotted, where logs are pulled.What's the strangest server-side malware you've encountered?
