VPS Compromise: 24-Hour Response Checklist (2026): Disconnect First or Preserve Evidence First?

For most VPS incidents, the safest order is:

• First cut off public network access
• But try to keep the system powered on and not rebooted

This means what you should do is more like:

• Temporarily tighten security groups / firewalls in the cloud provider console
• Block new inbound access
• Cut off suspicious outbound connections as much as possible
• If necessary, detach the instance from the public network

Rather than directly:

• reboot
• shutdown now

If you already see the following signals, isolating the network takes priority over everything:

• Continuously sending outbound packets, suspected of attacking others
• Large-scale data exfiltration in progress
• Scanning the internal network laterally
• Being used as a proxy, phishing, or spam node
• Obvious ongoing intrusion activity in the business

At this point, without isolation, the damage will only continue to expand.

If you're facing:

• A compliance investigation
• Customer data leakage
• A need to trace the attack path
• Suspicion of a persistent backdoor or advanced intrusion

Then you should be even more restrained about the urge to "reboot immediately."

Because once power is cut, a lot of volatile evidence is gone.

• Causing ongoing harm → isolate the network first
• Need to preserve forensic value → don't rush to shut down/reboot
• Both matter → isolate the network first, then preserve the scene

First write down:

• The time of the anomaly
• The source that triggered the alert
• Which service is abnormal
• Which accounts/ports/processes are suspicious

This step looks simple, but it's very important later for review, communication, and judging the timeline.

Prioritize using:

• Cloud provider firewall
• Security groups
• Console network rules

The goal is:

• Block the attacker from continuing to connect in
• Block suspicious outbound traffic
• Avoid damaging the scene as much as possible

You must be restrained at this step.

Don't immediately do these things out of panic:

• One-click antivirus
• Automatic repair scripts
• Clearing /tmp
• Deleting cron
• Directly apt upgrade

These can all contaminate the scene, making it impossible for you to trace the cause later or confirm the scope of impact.

If this VPS is running production business, you need to make a decision in the first 15 minutes:

• Must this machine go offline immediately?
• Is there a standby node or static degradation page?
• Do you need to switch traffic to a backup machine?

Don't leave "business continuity" until an hour later to remember.

If you already suspect that root, sudo users, deployment accounts, or panel accounts are compromised, pause using these accounts for further operations, to avoid expanding the contamination and to prevent the attacker from using your own operations to cover their tracks.

It's recommended to immediately open a separate incident record:

• Who did what and when
• Which rule was changed
• Which logs were exported
• What anomalies were seen

You'll be very grateful for this step later.

1. Current process list
2. Current network connections
3. Login sessions and user activity
4. Key system logs
5. Scheduled tasks, startup items, SSH keys, sudo configuration changes
6. Web service, database, panel, container logs

• Are there abnormal process names
• Are there suspicious parent-child process relationships
• Are there unfamiliar listening ports
• Are there outbound connections to unfamiliar IPs
• Are there newly created accounts / newly added SSH keys
• Are there modified scheduled tasks / systemd services

Because many key attacker behaviors only live in the "current running state":

• Callback connections
• Memory-resident malware / fileless malicious code
• Temporary tokens
• Shell sessions

Once you reboot, these may disappear directly.

If the attacker is still in the machine, or there's a persistent backdoor, then the new passwords, tokens, and keys you just changed may soon be obtained by the attacker again.

So the safer order is usually:

1. Isolate access first
2. Confirm the scope of impact
3. Invalidate sessions / tokens / keys first
4. Then rotate credentials in bulk

• root / sudo user passwords
• SSH keys
• Panel accounts
• Database accounts
• Deployment machine credentials
• API keys / Access Tokens
• Object storage keys
• CI/CD secrets

If this VPS has:

• .env
• Deployment scripts
• Automation tools
• GitHub Actions / GitLab Runner / webhook

Then what's leaked is often not just this server itself, but an entire chain of upstream and downstream credentials.

In the following situations, you should usually treat "rebuild" as the main path by default:

• root has been taken over
• The attack entry point and duration are uncertain
• There are obvious persistence traces
• Kernel-level / high-privilege backdoors are suspected
• The business allows recovery via backup
• It's impossible to confirm whether the system is still trustworthy

Why?

Because cleanup does not equal trustworthy recovery.

Deleting one mining program doesn't mean there's no second backdoor; fixing one cron doesn't mean there's no systemd persistence; restoring one file doesn't mean the attacker hasn't modified something else.

Only when the following conditions are relatively clear should you barely consider it:

• The scope of impact is very small
• The intrusion path is clear
• There's no high-privilege persistence
• You're confident enough that cleanup is complete
• The business can't be rebuilt in the short term

Even so, it's more advisable to migrate to a new instance as soon as possible.

If the vulnerability is still there, the ports are still open, and permissions haven't been tightened, the attacker only needs a few minutes to come back.

You restored the machine, but the old keys are still valid—that's not much different from not restoring at all.

Malicious files, backdoor scripts, and contaminated backups are sometimes not only on the host.

This is one of the most common persistence locations on Linux VPS.

If you don't strengthen monitoring within an hour after recovery, then you actually don't know whether the attacker has come back.

• Record the source of the anomaly
• Isolate the network at the control panel level
• Decide whether to switch traffic/degrade
• Don't reboot, don't clean the scene

• Export logs
• Check processes, ports, connections
• Record account, task schedule, service changes
• Keep copies of key evidence

• Judge the scope of impact
• Invalidate sessions and tokens
• Rotate high-risk credentials
• Judge whether to rebuild directly

• Restore from trustworthy backups to a new environment
• Harden patches, permissions, MFA, network policies
• Enable high-frequency monitoring
• Record root cause, timeline, and pending actions

Direct shutdown is usually not recommended. The safer default action is to isolate the network first to avoid further harm, while preserving volatile evidence such as memory, connections, and sessions as much as possible.

In most cases, disconnecting the network / isolating access takes priority. Because if the attacker is still online, the new password may also be leaked again soon.

If high privileges, persistence, or an unclear scope of impact are already involved, it's usually more advisable to rebuild a new instance rather than continue trusting the old system.

Then you should stick even more to the approach of "isolate first, preserve basic evidence, then rebuild." Don't panic-fix while destroying the entire scene.