Signs your server has been compromised

Ask what a compromised server is worth to the person who took it, and the quiet behaviour makes sense. It can mine cryptocurrency with spare CPU. It can relay spam from an IP address with no history of it. It can host phishing pages under your domain's reputation. It can inject links into your pages that only appear when the visitor arrives from a search engine, so you never see them. It can sit still and wait for the credentials that pass through it.

None of those want your attention. A defaced homepage ends the access within hours, so the intrusions that last are the ones that change nothing you would notice. Uptime, response time and a correct-looking homepage are all compatible with a server that has been someone else's for a month.

That is why the useful question is not "is anything broken" but "is this server doing anything it has no reason to do".

**Outbound connections.** Start here, because it is the highest-signal check on the box. List established connections and ask which process owns each one and why your web server needs to talk to that address. A web server that initiates connections to hosts nobody can explain is the single most reliable indicator you will find.

**Unexpected processes.** Look for processes running as the web user that are not part of your stack, processes whose binary has been deleted from disk while still running, and anything with a name chosen to look plausible at a glance. Compare against how the machine looked when you last knew it was clean — which is an argument for recording that once, in writing, while it is true.

**Scheduled work.** Cron entries, systemd timers and per-user crontabs are the most common persistence mechanism, because they survive a reboot and nobody audits them. Check the web user's crontab specifically, not just root's.

**Files in the web root.** New PHP or executable files inside an uploads or cache directory, files whose modification time is inconsistent with your last deploy, and files with timestamps deliberately set to match their neighbours. A file integrity baseline turns this from an afternoon of guessing into a diff.

**Accounts and keys.** New users, existing users with a changed shell, additions to `authorized_keys`, and sudo rules added outside a change window.

**Listening ports.** Anything accepting connections that you did not put there, and any administrative service reachable from outside the network.

Authentication logs are worth reading properly rather than skimming: a long run of failures from one range followed by a single success is a brute force that landed, and it is easy to miss because the success line looks ordinary.

A missing period is itself evidence. Attackers truncate logs, and a rotation that happened at an hour it does not normally happen is not a coincidence. So is a log source that simply stopped producing entries — silencing the recorder is what a careful intruder arranges before doing anything worth recording.

This is also the argument for shipping logs somewhere the server cannot reach. Logs stored only on the compromised machine are logs the attacker can edit. Once they are being written to a separate destination, tampering becomes a visible gap rather than a clean absence.

An outdated CMS plugin or theme, by a wide margin. The core is usually patched and the plugin that was installed once for a landing page in 2023 is not.

An exposed `.env`, `config.php` backup or `.git` directory served as a static file, handing over database credentials and API keys without any exploitation at all.

Administrative interfaces reachable from the whole internet — phpMyAdmin, cPanel, a database port, a Redis or MongoDB instance left on its default with no authentication.

Shared hosting cross-contamination, where the neighbour's site is the way in and your files are simply reachable from it.

Credential reuse: an FTP or SSH password that also appears in a public breach corpus, tried automatically against every host that answers.

**Do not reboot.** Running processes, open connections and anything held only in memory disappear with the uptime, and those are frequently the only evidence of what was happening.

**Do not delete the file you found.** It is your best lead on how the intrusion arrived and what else it touched. Quarantine a copy first.

**Do not restore a backup over the top yet.** If you do not know the entry point, you will restore the vulnerability along with the content, and you will overwrite the evidence that would have told you what it was.

**Do not change every password immediately** if you have not yet checked for persistence. An attacker with a cron job and an SSH key does not care about your new password, and the rotation tells them you have noticed.

**Do not keep it to yourself.** If payment data or personal data sat on that machine, the reporting clock is already running and the decision is not a technical one.

Take a snapshot of the disk if your provider supports it, and copy the logs off the machine before touching anything. That is fifteen minutes that decides whether the rest of the investigation is possible.

Contain next: restrict inbound access to your own address, block the outbound destinations you identified, and suspend the affected credentials. Containment is reversible and cheap; cleaning is neither.

Only then clean, and clean by restoring known-good files rather than by removing the bad ones you managed to find. The set of files you found is never the whole set. Finish by identifying and closing the entry vector — an infection that recurs is almost always one where this step was skipped because the site was working again.

Escalate beyond your own team when payment data or identity documents were on the machine, when there is a ransom note or encrypted files, when you have lost administrative access, when the hosting provider has suspended the account, or when you cannot establish how long the access lasted.

That last one matters more than it sounds. "We do not know when it started" changes the scope of everything downstream — which customers to notify, which credentials to treat as public, and whether backups from the past six months can be trusted at all.