Site Hacked? Do These Things First

Your site's homepage has turned into a black page with English text, or Google has written "This site may be hacked" under the search results, or a customer has called saying their bank card was charged from your checkout page. Any of these means the site has been hacked and you need to make a decision right now. The first decision is this: don't touch the files. If you start deleting suspicious files right now, there's a high chance you'll destroy the attacker's trail forever, and two weeks later the same thing will happen again.

The correct order has four stages: containment, preserving evidence, cleanup, restoration. Most site administrators skip the first and second stages and go straight to the third. That's where things go wrong.

Stage One: Cut off the attacker's access, don't delete files

The goal of this stage is just one thing: the attacker can no longer get in. Don't delete any files yet.

First of all, change the passwords for the hosting control panel and the domain panel, from another device, not from the same system that might be infected. Then check the SSH keys:

cat ~/.ssh/authorized_keys

Delete any key you don't recognize. If your server has SSH on port 22 and password authentication is enabled, this was probably the door the attacker came through. The guide SSH security; from changing the port to fail2ban and public keys covers exactly this scenario.

Then it's the users' turn. In MySQL or MariaDB:

SELECT user, host FROM mysql.user;
SELECT user, host, command, time, state FROM information_schema.processlist;

A user that shouldn't exist, or a user connecting from the wrong host, means a database backdoor. Change the passwords of all application users and update wp-config.php or the equivalent configuration file.

If the site runs on WordPress, check the admin users. The attacker usually creates a user with a meaningless name and the administrator role:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Now, and only now, if necessary, take the site offline from public access. A simple 503 page is enough; you don't need to shut down the whole server, because shutting down the server means losing the live logs too.

Stage Two: Preserve evidence before cleanup

This is the stage almost everyone skips and then regrets. If you later want to file a complaint with FATA police, report to an insurance company, or even just understand where the attacker came from, you'll need these files.

First of all, take a snapshot of the current state. If you're on a VPS or cloud server, take a full snapshot from the panel and name it with the date. If a snapshot isn't available, at least copy these:

tar czf /root/evidence-$(date +%F).tar.gz \
  /var/log/nginx /var/log/apache2 /var/log/auth.log \
  /var/www/html/wp-content/uploads 2>/dev/null

Look at the web server logs and search for strange patterns. A POST request to a PHP file that shouldn't accept input, or an unusual volume of traffic from one IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

If the number next to one IP is four or five digits and the rest are two digits, take that IP seriously. But be careful: if the attack is distributed, this command won't show anything useful and you'll need to move on to analyzing time windows. For this type of attack, the DDoS protection layer acts before traffic reaches the web server.

Find the modified files along with their timestamps. If you have the last healthy backup, comparison is the simplest way:

find /var/www/html -type f -newermt "2024-01-01" -printf "%T+ %p\n" | sort

In WordPress, checking the core checksum is the fastest way to find a tampered file:

wp core verify-checksums
wp plugin verify-checksums --all

The output of these two commands usually gives a short list of files. Set those aside and keep them; they'll be useful for analysis later.

This is where they make a mistake

A common mistake I've seen many times: the site administrator immediately deletes the infected files, the site comes back up, everyone is happy, and three weeks later exactly the same black page returns. Why? Because the attacker didn't just leave one file. A cron job in /etc/cron.d/, an extra function in the theme's functions.php, or a row in the wp_options table remains that recreates the infected file every night. The sign is this: you delete the file, and a few hours later it comes back with the same content and a new timestamp. Until you find the source of regeneration, deleting the file is useless.

Stage Three: Clean up from a clean point

Cleaning an infected site in place is a risky job. If you have a healthy backup, prefer that. If you don't, follow this order:

1. Reinstall the core and all plugins and themes from the official source, not from the current files on the server.
2. Delete any PHP file with a random name in uploads or cache. No executable file should be in the uploads folder.
3. Search the database for suspicious strings: eval(, base64_decode, <script src= with an unknown domain.
4. Review the admin users and change everyone's password.
5. Revoke and reissue API keys, payment tokens, and passwords for external services.

A point that's rarely mentioned: if the attacker had access to the database, they may have copied customer data. This is no longer a technical issue, it's a legal issue. The guide Data privacy; a practical guide for Iranian sites explains when and how you should notify.

Stage Four: Restore and close the entry hole

Once you've brought the site back up, the job isn't done. If the same hole that allowed entry stays open, all this work will be repeated. Definitely do three things:

• Bring the PHP version, WordPress, and all plugins up to the latest stable version. Delete abandoned plugins, don't just deactivate them.
• Enable two-factor authentication for all administrative accounts.
• Restrict access to the admin panel, either by IP or with an extra authentication layer.

And one thing most teams don't do: enable audit logs and keep them somewhere the attacker can't delete. If you don't know where to start, What are audit logs and how do we keep them intact? is a good starting point. Without logs, next time you won't know where you got hit either.

If you have a team and you exchange passwords in chat, that's one of the root causes right there. Read Password management in teams; why is sharing in chat forbidden? and set up a real password manager.

When you should get outside help

If your site is an online store and you have customer data, or if after two rounds of cleanup the infected file still comes back, don't continue on your own. Malware analysis and deep cleanup is specialized work, and its cost is usually less than the cost of a data leak or several days of downtime. For critical sites, ServerNet's server security services cover exactly this layer.

Let me honestly state one limitation too: no automatic cleanup tool replaces manual investigation. Scanners find known files, but custom backdoors that the attacker wrote specifically for your site usually go undetected. If the scanner says "clean" and the site still behaves strangely, don't trust the scanner.

Frequently asked questions

What's the first thing I should do after my site is hacked?

Change the passwords for the hosting panel, domain panel, and database from another device, and delete unknown SSH keys. Don't delete files at this stage, because you'll destroy the evidence needed to understand the entry method.

Should I take the site offline immediately?

If the site is serving malicious content to visitors or bank card information is being transferred, yes. A 503 page is enough and there's no need to shut down the whole server, because shutting down the server means losing the live logs.

How do I figure out where the attacker entered from?

Compare the web server log, the authentication log, and the list of modified files together. In WordPress, the wp core verify-checksums command is the fastest way to find tampered files. If audit logging wasn't enabled beforehand, reconstructing the entry path is harder but not impossible.

After cleanup, how do I make sure it won't be hacked again?

There's no absolute guarantee, but the combination of updating all components, two-factor authentication, removing abandoned plugins, and having audit logging enabled drastically reduces the chance of recurrence. If the infected file comes back on its own after deletion, it means a source of regeneration such as a cron job or hidden code in the theme has been left behind.