Finding a malicious file on a Linux server does not reveal the full extent of an incident.
The attacker may have changed only one vulnerable application. They may also have gained shell access, stolen credentials, created new accounts, or installed another way back into the system.
The key question is not whether you can remove the visible malware.
It is whether you can still trust the server afterwards.
Cleaning may be reasonable when the incident has a narrow and clearly understood scope. Once an attacker gains privileged access, or you cannot determine what they changed, rebuilding from a clean source usually provides a safer path.
The real problem is trust
A compromised server can appear to work normally.
Websites load, services start, and resource usage looks ordinary. A malware scan may also stop finding suspicious files.
None of that proves the system is trustworthy.
An attacker with enough access can add SSH keys, create users, modify startup services, schedule tasks, replace files, or interfere with local logs.
Removing the first malicious file only removes what you found.
A proper recovery must return the system to a known state. Current NIST guidance treats response and recovery as connected parts of cybersecurity risk management, not simply as the removal of visible malware.
When cleaning may be reasonable
Not every incident requires a complete rebuild.
Cleaning can make sense when you can show that the compromise remained inside one application and never reached the underlying operating system.
For example, an attacker may have modified files inside a vulnerable website without gaining shell access or elevated privileges.
In that situation, you may be able to:
- replace the application with a clean copy;
- patch the original vulnerability;
- remove malicious files;
- rotate the credentials that the application could access;
- inspect other services for related activity.
That decision still needs evidence.
You should understand how the attacker entered, which permissions the affected process had, and what data or secrets it could reach.
Without those answers, cleaning becomes an assumption rather than a verified recovery.
When rebuilding is safer
A rebuild becomes the stronger choice when the attacker gains root or another privileged account.
At that level, they can change almost every part of the system. Local commands, package checks, logs, and monitoring tools may no longer provide a complete picture.
I would also favour rebuilding when:
- the original entry point remains unknown;
- unfamiliar users, SSH keys, cron jobs, or services appear;
- system files change unexpectedly;
- logs are missing or incomplete;
- credentials stored on the server may have leaked;
- the attacker retained access for an unknown period;
- malicious files return after removal;
- a rootkit or another deep persistence mechanism may exist.
CISA’s incident-response playbook recommends reimaging affected systems from clean sources and rebuilding when rootkits are involved.
At that point, trying to prove that every malicious change has disappeared may take longer and provide less certainty than building a clean replacement.
Preserve evidence before deleting anything
Rebuilding should not begin by immediately destroying the compromised VPS.
The existing machine may contain the only useful evidence of what happened.
Where possible, isolate it from public traffic and other systems. Preserve relevant logs, provider activity, suspicious files, active connections, process information, and a disk or volume snapshot.
That snapshot is not a production backup.
It is a record of the compromised state that may help identify the entry point, affected data, and persistence methods.
For a personal server, a complete forensic investigation may not be realistic. Even so, deleting the machine before collecting basic evidence can remove the information needed to prevent the same incident from happening again.
Assume exposed credentials may no longer be safe
A compromised server can expose more than the files stored on disk.
The attacker may reach:
- SSH keys;
- database passwords;
- API tokens;
- SMTP credentials;
- backup accounts;
- control-panel access;
- secrets inside configuration or environment files.
Changing only the root password is rarely enough.
Rotate every credential the attacker could have accessed, and make those changes from a separate trusted device.
Replace exposed keys and tokens instead of simply copying them to the new server.
Also check where the same credentials work. A stolen key may open another VPS, while a cloud or backup token may provide access far beyond the original machine.
Rebuilding removes the compromised host. Credential rotation helps remove the attacker’s remaining access.
Restore data carefully
Start the replacement server from a trusted operating-system image, apply current updates, and review the services you actually need.
Do not restore the entire old filesystem.
Doing so may return malicious files, unsafe permissions, or persistence mechanisms to the new system.
Recover only the necessary data, such as databases, mailboxes, application uploads, and verified website content.
Treat configuration files with more caution.
Review SSH keys, cron jobs, systemd units, startup scripts, plugins, container definitions, and Docker Compose files before bringing them across.
The latest backup may not be the cleanest one either. If the compromise began before that backup, restoring it could recreate the same problem.
Fix the original weakness
A clean rebuild achieves little when the replacement exposes the same vulnerability.
Before returning the service to production, identify and remove the most likely entry point.
That may mean:
- updating a vulnerable application;
- removing an abandoned plugin;
- correcting permissions;
- restricting a public administration panel;
- replacing reused credentials;
- changing how the service reaches the internet.
Review related systems as well. An attacker may have reused stolen credentials or moved beyond the first server.
Recovery does not end when the website starts loading again. The new environment must also close the path that allowed the compromise.
Rebuilding is controlled recovery
Rebuilding can feel excessive, especially when the server still appears to work.
In many cases, however, it provides the clearest route back to a trusted system.
You know where the operating system came from. You can introduce new credentials, review each service, remove obsolete components, and avoid carrying unknown changes into production.
Cleaning remains valid when the incident has a limited and well-understood scope.
Once privileged access or unknown persistence enters the picture, certainty matters more than preserving the existing installation.
Need help recovering a compromised server?
I can review a compromised Linux server, help determine whether cleaning is still reasonable, and plan a controlled rebuild when the existing system can no longer be trusted.