Server Hacked? What to Do First

Your stomach drops when your website starts redirecting somewhere strange, sending spam, or showing files you did not upload.

Short version: if your server was hacked, first contain it, then preserve evidence, then rebuild or restore from a known-good backup. Do not trust the compromised system to clean itself, and do not simply delete the suspicious file and move on. Your goal is to stop the damage, understand the doorway the attacker used, and come back online from a clean base.

What should you do first when your server is hacked?

If you are searching “server hacked what to do,” start with containment. Think of the server like a house with a broken lock and someone still inside. You do not begin by repainting the wall; you stop more people from walking through the door.

Take the server out of public use if you can. That might mean shutting down the affected app, blocking public traffic, or temporarily moving DNS away from it. If the server is sending spam, hosting phishing pages, attacking other machines, or leaking private data, speed matters more than keeping the site online.

Next, avoid making the crime scene worse. Do not randomly delete files, reinstall packages, or “try a few fixes” before you have saved what you need. If your provider offers a snapshot or rescue image, capture the current state. That gives you something to inspect later, even if you decide not to keep the machine.

Then change passwords and keys from a clean computer. If your laptop may also be infected, fix that first. Rotate SSH keys, admin passwords, database passwords, API tokens, and any credentials stored on the server. Assume anything readable by the compromised system may be known to the attacker.

How do you know how bad the compromise is?

You are looking for the entry point and the blast radius. In plain English: how did they get in, and what could they touch once they were there?

Common doors include weak SSH login settings, an outdated WordPress plugin, an exposed database, a leaked deployment key, a forgotten test app, or a Docker container that had more access than it needed. The attacker may have left a web shell, which is a small script that lets them control your site through the browser. They may also have added a new user, scheduled a task to come back later, or changed files that look normal at first glance.

Check the obvious symptoms: unfamiliar users, unknown processes, strange outgoing traffic, new files in web folders, changed SSH authorized keys, unexpected cron jobs, and modified application code. If you run nginx, PHP-FPM, MySQL, PostgreSQL, Docker, or WordPress, each has logs that can help show when the first odd request or login happened.

Also check what data lived there. A hacked static landing page is bad. A hacked customer database, password manager, or private file store is much more serious. If personal data may have been exposed, you may have legal or customer notification duties. That is not a hosting problem anymore; it is a trust problem.

Should you clean the server or rebuild it?

Most of the time, rebuilding is safer than cleaning. A compromised server is like a hotel room where someone may have copied the master key. You can tidy the room, but you cannot easily prove there is no hidden key under the mat.

Here is the practical choice:

For most small teams, the safer path is: create a new clean server, install only what you need, patch the vulnerable app or setting, restore clean data, rotate secrets, then point traffic back.

Backups matter here, but only if they restore cleanly. A backup that contains the attacker’s web shell is just a time machine back to the same problem. If this incident exposed gaps, use it as a reason to build backups you can actually restore, not just files you hope are useful later.

How do you stop the same hack from happening again?

After recovery, fix the doorway. Otherwise you are just putting the same broken lock on a new house.

Update the operating system, the app, plugins, themes, and containers. Remove software you do not use. Close public ports that do not need to be public. If only your web app should face the internet, your database should not be listening to the whole world.

Use key-based SSH login, disable password login where appropriate, and limit who can access admin panels. Put a basic firewall in front of services so the internet cannot poke at everything you run.

Separate projects when you can. One old test site should not be able to damage your main business site. This is the same reason shops put dangerous tools in separate drawers: if one thing spills, it does not ruin the whole workbench.

Finally, document what you rebuilt. Write down what runs on the server, which domains point to it, where backups live, and what secrets were rotated. Six months later, clear notes are security equipment.

The shortcut

Server Manager helps by keeping the shape of the setup visible: what is running, where traffic goes, which domains and certificates belong to which project, and what should not be exposed. That matters after a compromise because confusion is where mistakes hide: an old app left online, a forgotten admin panel, a wrong certificate, or one project breaking another during recovery.

It also helps your rebuilt setup stay understandable over time. When the map remains legible, you are less likely to forget why a port was opened, which service owns a domain, or whether a project was supposed to be public at all.

The real benefit is not avoiding every incident forever. It is recovering with fewer blind spots, then living with a server you can still understand months later.

FAQ

Can I just delete the suspicious file? Not safely. The file may be only the visible symptom. You still need to find how it got there and whether the attacker added another way back in.

Should I shut the server down immediately? If it is harming others, leaking data, or you cannot contain it another way, yes. If you can isolate it while preserving a snapshot, that gives you more to investigate.

Are backups always safe to restore? No. Restore only from a point before the compromise, and patch the original weakness before putting the site back online.

Do I need to tell users? If user data, private files, passwords, or payment-related information may have been exposed, get proper legal or security advice. Silence can make the damage worse.

What does a safe recovery look like?

A safe recovery is not just “the website loads again.” It means the attacker’s access is gone, the original doorway is fixed, secrets have been rotated, and the new setup is clear enough that you can maintain it.

You come out with a cleaner server, a better backup story, fewer exposed services, and notes that future-you can understand. That is the win: not panic, not guesswork, but a controlled return to normal.