Your website was hacked: what to do in the first 24 hours

If you have opened this page, chances are you do not have much time to read. Below is the order of play: what to do right now, what to do in an hour, and what can wait until tomorrow. The classic mistake of the first few minutes is to start deleting things. Let us look at why that usually does more harm than good, and what to do instead.

First, make sure it really is a hack

Not every site failure is a hack. But some signs almost always mean exactly that:

• A browser or a search engine flags the site as dangerous. The red Chrome screen, a warning in Yandex search results, a “this site may harm your security” label.
• Your hosting provider has emailed you — or has already taken the site offline. Hosts spot spam mailings and malicious files before the owner does.
• Pages you never created have appeared on the site. Usually articles about loans, betting or pharmacies, or duplicates in Latin script. Often they are visible only to the search crawler, while you see the usual homepage.
• A redirect to an unrelated resource. Especially if it does not fire every time: only on mobile, only when arriving from search, only for first-time visitors.
• Spam is going out from your domain. The tell-tale sign is a stream of “message undeliverable” bounces landing in a mailbox you sent nothing from.
• A sudden spike in load. The server has slowed down without any growth in traffic — the site is being used as someone else’s resource: for mailings, mining or attacks on other sites.
• Administrators you do not recognise in the admin panel. An account you never created is the single most unambiguous sign of them all.

Any one sign can have another explanation: a drop in rankings can come from an algorithm change, a 500 error from a botched plugin update. But two or more signs together mean a hack — so work through the steps below in order.

The first hours, step by step

Step 1. Take a copy — before you start cleaning

The strongest urge in the first hour is to wipe everything suspicious and restore from a backup. That is exactly what most often leads to a second hack a week later. Along with the malicious files you destroy the only evidence of how the attacker got in. You will not close the hole, and he will come back the same way.

So the first thing is an archive: the site files, a database dump and, most important of all, the web server logs (these are text files where the server records every request to the site — usually access.log and error.log). Logs are rotated on a schedule, often within days, and there is no way to recover them afterwards. Download the archive to your own computer instead of leaving it on the same server.

Step 2. Close the site to visitors

While the site is infected, every visitor is at risk and search engines keep recording new malicious pages. Turn on maintenance mode or serve a stub page with a 503 status code — that way search engines understand this is temporary and will not drop your pages from the index. There is no need to delete the site entirely or to change DNS.

Step 3. Cut off access first, change passwords second

The order here is critical, and it is almost always broken. If you simply change the administrator password, the attacker will not even notice: he stopped using the login form long ago. He has a web shell on your server — a small file that lets him run commands straight from a browser, with no password at all. Or an active session in the admin panel. Or a server access key you never thought of as a password.

So the sequence is:

1. End all active sessions. Most CMSs and hosting panels have a “log out on all devices” button. Without it, changing the password does not throw out someone who is already inside.
2. Revoke access keys: SSH keys on the server, FTP and SFTP credentials, API tokens, integration and payment service keys, passwords for mailboxes on the domain.
3. Change the passwords — the hosting panel, every CMS administrator, the database, mail, the domain registrar. Every password new and unique: if the same password was in use in three places, all three are compromised.
4. Change the passwords from a clean computer. If the leak came from an infected machine, the new passwords will travel to the same place the same minute.

Step 4. Audit the accounts

Open the CMS user list and delete everyone you do not recognise — especially anyone with administrator rights. While you are there, check the things people usually forget: forwarding rules on the domain’s mailboxes (a popular way to quietly receive password reset emails), the list of SSH keys on the server, connected third-party apps and webhooks, and the access you granted to contractors.

Step 5. Look at when the files were modified

This is the fastest way to gauge the scale. Sort the site files by modification date — in the file manager of your hosting panel that takes a single click. The files changed on the suspicious day are your map of the infection. As a bonus you get an approximate time of the break-in, and with it the stretch of the logs you need.

Pay attention to .php files in directories where they have no business being: in the uploads folder, among the images, in the cache. A legitimate site does not execute code from the folder with the product photos.

How to find the entry point

Until you know how they got in, cleaning is pointless. There are four places worth looking.

The web server logs. Take the day your modified files are dated and find the requests to them. The typical picture: several dozen requests from one address within a minute (that is brute forcing), then a single successful POST request to the login page or to a file you are hearing about for the first time. If you are not ready to read the log yourself, this is exactly the fragment to hand to a specialist.

An outdated CMS, plugins and themes. The most common cause. Vulnerabilities in popular plugins are published constantly, and ready-made exploitation tools appear alongside them; automated scripts sweep the internet and try them one after another, without picking a victim. Look at what has gone longest without an update, and especially at what was disabled but not deleted: a disabled plugin still sits on disk, and its files are reachable by direct URL.

A stolen password. There may have been no break-in of the site at all: the FTP or panel password was lifted from a developer’s computer. Many FTP clients store saved passwords in near-plaintext, and malware grabs them first thing. The tell-tale sign is that the login succeeded straight away, with no brute forcing at all, from an ordinary end-user address. In that case run an antivirus scan on every machine used to access the site, including the computers of your contractors.

Neighbours on the hosting account. On cheap shared hosting, sites are sometimes laid out in such a way that an infection crawls from one to another. If you have several sites on one account, check them all at once.

If you still cannot find the entry point, there is a workable fallback: deploy the CMS from scratch, move over only the content (texts, images, the product and order database) and install the plugins you need by hand from official sources. You must not carry the old theme and plugin files over wholesale — the shell usually moves with them.

What to do before you put the site back online

The moment when everything looks cured is the most dangerous one. The site works, the panic has passed, and it feels as though you can take the stub page down. Before you do, close whatever let the hack happen.

• Update everything: the CMS core, plugins, themes, the PHP version. Updating after the cleanup is how you close the hole, not hygiene “for the future”.
• Delete what you do not use. Plugins kept “for later”, old themes, a test copy of the site in a subfolder, a forgotten info.php. The best protection belongs to what is not on the server at all.
• Rotate the CMS secret keys. In WordPress those are the salts and keys in wp-config.php; other systems have equivalent settings. Changing them invalidates every session issued earlier, including the ones you do not know about.
• Change the database password and check that the database is not reachable from outside.
• Turn on two-factor authentication for the CMS login and for the hosting panel. It is the one measure that keeps working even when the password has already been stolen.
• Set up backups that are stored somewhere other than the same server. A copy sitting next to the site gets encrypted and deleted along with it.
• Check the site from the outside — the same way an attacker looks at it: which component versions are visible, which service files are reachable, where panels have been left open. What a check like that finds, and what it fundamentally cannot see, we covered in a separate article.

How to clear the “dangerous site” warning

The warning in the browser and in search results will not disappear on its own — you have to ask for a review. Do it after the cleanup: if the check finds malicious code again, you will wait longer for the next review.

• Yandex.Webmaster — the Russian search engine’s equivalent of Google Search Console. The “Security and violations” section shows the type of threat detected and a button to request a re-check. It is worth reading the threat type before you start cleaning: it hints at what exactly was found.
• Google Search Console. The “Security issues” section — a description of what was found and a button to request a review. It usually lists the specific infected addresses as well.
• Your hosting provider. If the site has been suspended, write to support and say exactly what you have done. Many hosts lift the block after running their own check.
• Mail reputation. If spam was going out from the domain, your emails may fail to arrive even after the cleanup — the domain has landed on blocklists. Check your SPF, DKIM and DMARC settings (the records that confirm mail sent in your name really came from you) and, if necessary, file a delisting request.

A review is not instant — allow several days. While it is running, keep the site working and clean: malicious code reappearing during the review throws you back to the start.

If customer data may have been affected

This is the part small business owners skip most often — and it comes with legal consequences. If the site has enquiry forms, customer accounts, order checkout or a subscriber list, you process personal data and by law you are a data operator (Russia’s Federal Law No. 152-FZ “On Personal Data”).

In an incident where personal data may have been copied or altered by outsiders, the law requires you to notify Roskomnadzor — the Russian regulator that oversees personal data. The deadlines are short: the first notification comes almost immediately after discovery, the second, based on your internal investigation, a few days later. The wording currently in force puts them at roughly 24 and 72 hours, but before you file, be sure to check the current wording of the law and the notification form on the Roskomnadzor website — the requirements have changed and are still being refined. If you are unsure whether the incident counts as a breach, that is a question to put to a lawyer the same day, not a week later.

Separately from the formal obligation there is the human side. If passwords that customers might also use in other services passed through your site, it is more honest to tell them yourself and suggest they change the password. Customers forgive a hack far more easily than they forgive silence about it.

What not to do

• Pay the extortionists. If the site has been encrypted and a ransom is demanded, paying gives you nothing except confirmation that money can be extracted from you. They still have access to the server, and the demand comes back. Restore from a copy and close the way in.
• Delete the one file you found and consider yourself done. Shells almost never come alone: usually there are several, scattered across different directories, disguised as system files, and one of them is often written into the database or into a scheduler job so it can restore the rest.
• Hope that “it is just a virus, the antivirus will clean it up”. Your host’s antivirus removes known malicious code from disk, but it does not fix the vulnerability that let that code onto the server, and it does not revoke stolen credentials. The infection comes back after the cleanup — that is not a sign of a bad antivirus, it is a sign of a door left open.
• Put off dealing with the logs. They are rotated on a schedule. If you do not save them on day one, there will be nothing left to investigate with.
• Bring the site back with the same passwords and the same CMS version. That is not recovery, it is a pause before the next hack.

In short

1. Take a copy of the files, the database and the logs — before any cleaning.
2. Close the site behind a stub page with a 503 status code.
3. Kill the sessions and the keys, then change the passwords — from a clean computer.
4. Review the administrators, the mail forwarding rules and the access granted to contractors.
5. Find the entry point using the logs and the file modification dates.
6. Update, delete what you do not need, turn on two-factor authentication, set up off-server backups.
7. Request a review in Yandex.Webmaster and in Search Console.
8. If personal data may have been affected, check the procedure and the deadlines for notification.