Suspect Your VPS Was Hacked? A Calm First-Response Checklist

Separate a symptom from a conclusion

A CPU spike, unfamiliar process or outbound-mail alert deserves investigation, but none proves a compromise by itself. Scheduled backups, security scanning and legitimate imports can also consume resources. Write down what changed, when it began and which customer-facing functions are affected. This November 2026 operational guide uses the incident-response approach in NIST SP 800-61 Revision 3, published in 2025; it is not a claim about a new zero-day.

Choose one incident owner and a trusted workspace

Use a known-clean device and the hosting provider’s verified control panel. Assign a person to coordinate technical decisions and a separate contact for customer updates when possible. Record times in a consistent timezone. If the server may be compromised, do not treat tools and reports from that machine as independent proof of safety. Provider logs, external monitoring and previously collected application logs can help establish a second view.

Contain active harm without improvising a cleanup

If data is being destroyed or traffic is attacking other systems, prioritize limiting the damage. A provider-level network control or isolation feature may be safer than experimenting inside the affected operating system. Preserve console access and identify dependencies before changing network rules. Containment can interrupt service; choose it deliberately according to the impact, rather than promising an incident can always be handled without downtime.

Before deleting files, killing processes or rebooting, decide what evidence the investigation needs. Volatile information can be lost, while an uncontrolled cleanup can hide the entry point. An authorized responder may collect process, connection and log information, plus snapshots where appropriate. A snapshot is neither a complete memory capture nor a clean recovery image. Keep evidence restricted because it may include secrets or customer information.

Build a timeline and check the blast radius

• Correlate administrative sign-ins, application requests and deployment changes around the first known symptom.
• Check affected users, scheduled tasks, service definitions, new credentials and unexpected application files.
• Identify which API keys, database users, mail accounts and backup credentials the affected process could read.
• Compare files with a trusted release artifact, not only timestamps. A quiet process list does not establish that persistence is gone.

Recover from a known source

For a confirmed compromise, rebuilding a replacement instance from trusted images and reviewed application artifacts often provides a clearer recovery boundary than editing suspicious files in place. Determine and fix the entry point before routing traffic back. Validate backups in isolation, review restored data and rotate affected credentials from a clean device in a planned order. Otherwise a recovered application may retain the access that enabled the intrusion.

Define the conditions for returning to service

Confirm access controls, the patched entry point, restored data, monitoring and a tested rollback path. Watch external requests and outbound activity after cutover. Record what remains uncertain and assign follow-up checks. NIST’s guidance integrates preparation, detection, response and recovery into ongoing risk management; the operating checklist here is our practical application of that approach.

Prepare in advance with useful security-log retention and a separate restore drill. Use the Linux VPS security checklist to review the replacement server before reopening access.