My website was hacked: how to recover it step by step

The first hour

The first hour is not for cleaning. It is for stopping the damage and not losing information. In this order:

1. See what is happening from the outside. Open the site on your phone over mobile data, in a private window, coming in from Google. Write down what you see: a redirect, a Chrome warning, a defaced page, a strange payment form. Take dated screenshots.
2. If it is a store, check the payment step first. If the checkout shows a card form that should not be there, turn that payment method off. Every order placed with an active skimmer is a stolen card. I explain it in card skimming on your online store.
3. Consider putting the site in maintenance mode. If it is redirecting to scams or spreading malware, a maintenance page protects your visitors while you work. Do it from the hosting panel or with a server rule, not from a plugin inside the infected site itself.
4. Tell your hosting provider. Not so they "clean it" with a scanner, but to find out whether they have seen anything (mass email, odd processes) and so they do not suspend your account without warning. Ask them for the access logs of the last few days.
5. Write down the dates: when you noticed, when the complaints started, whether anything changed recently (a new plugin, an update, a contractor with access).

Do not restore yet

Restoring yesterday's backup looks like the fastest fix, but it has three problems:

• You do not know whether the backup is clean. Many infections sit inside for weeks before they show. Yesterday's backup may already contain the backdoor.
• The hole is still open. If they got in through a vulnerable plugin or module, the backup brings back the same vulnerable plugin. They will get in the same way again, often automatically.
• You wipe the evidence. The infected files, their dates and the logs tell you how they got in and what they took. If customer data is involved, you are going to need to explain it.

Before touching anything, make a full copy of the current state, infection included: every file, the database and the server logs. Store it off the server. Over SSH, something like this:

# Files (from the folder above the website)
tar -czf hacked-site-$(date +%F).tar.gz public_html/

# Database
mysqldump -u USER -p DB_NAME > hacked-db-$(date +%F).sql

Without SSH, the hosting panel usually has a full-backup option, or lets you download the database with phpMyAdmin. That copy is never restored as it is: it is your evidence and your safety net.

Get the passwords in order

You need to change every credential that gives access to the site, from a computer you know is clean (if yours has a trojan, the attacker will see the new passwords too):

• The hosting control panel and the domain registrar account.
• FTP and SFTP, and any SSH keys you do not recognize in ~/.ssh/authorized_keys.
• The database user (and update it in the site's configuration: wp-config.php in WordPress, app/config/parameters.php in PrestaShop 1.7 and later).
• Every admin user of the site, and delete the ones you do not recognize.
• In WordPress, the keys and salts in wp-config.php, to log out every open session.
• Connected accounts: payment gateway, Google Search Console, domain email.

Turn on two-factor authentication wherever you can, starting with the hosting and the registrar: with those, an attacker can take the whole domain.

Clean without losing the evidence

A good cleanup is not about deleting whatever looks strange. It is about replacing what is known with its original and reviewing by hand whatever has no original. This is how I work:

1. Core: I compare every file with the original of the same version. In WordPress, wp core verify-checksums; in PrestaShop, against the official package of that exact version. Whatever does not match gets replaced.
2. Plugins, modules and themes: the ones with a public version are reinstalled from the official source. Purchased or custom ones are reviewed file by file.
3. Files that should not exist: PHP inside upload or image folders, randomly named files in the root, extra .htaccess files in subfolders.
4. Database: scripts injected into options, content and settings; new admin users; scheduled tasks.
5. Server: cron jobs of the hosting user (crontab -l), which sometimes reinstall the infection every hour.
6. The way in: with all of the above and the logs, I look for how they got in. If it cannot be found, every candidate gets closed (update everything, remove whatever is not used).

Everything you remove, move it to a folder outside the website instead of deleting it, and note where it came from. If it later turns out personal data was affected, that list is the basis of the report. To find what to look at, there are guides for hacked WordPress, hacked PrestaShop and the general one on how to tell if your website is hacked.

If you have backups, and if you don't

If you have backups

A backup helps a lot, but as a source of clean files, not as an undo button. Look for the most recent backup that is older than the infection (the dates of the infected files and the logs give you a hint) and use it to recover what has no public original: the custom theme, the images, the database from before the attack. If you restore an old database on a store, you lose every order and customer since then: in that case it is better to clean the current database.

After restoring, update or remove whatever was vulnerable before you open the site again. Otherwise the cycle repeats.

If you have no backups

It can still be recovered, just with more manual work: the core and the public plugins or modules are reinstalled from their source, and your own parts (theme, content, database) are cleaned by hand. That is the most common situation in the cases I get. When you are done, set up daily backups off the server: a backup that lives on the same hosting goes down with it.

Ask Google for a review

If Google shows "This site may be hacked" or Chrome shows the red screen, the warning does not go away on its own. Once the site is clean:

1. Verify the site in Google Search Console if it was not already, and check there are no owners you do not know.
2. Open Security & Manual Actions → Security issues and check the sample URLs: they should return 404 or show your own content.
3. Click Request Review and explain what you found, what you did and how you closed the way in.

I go through it in detail, including the timelines Google publishes, in how to remove the dangerous site warning.

Personal data: don't leave it for last

If the site stores customer data (a store, a members area, forms) and the attacker may have seen it, the GDPR gives you 72 hours from the moment you become aware to notify your supervisory authority (in Spain, the AEPD, Spain's data protection authority), unless it is unlikely to put people at risk. That clock keeps running while you clean. It is step by step in data breach on your online store.

When to get help (price)

You can do it yourself if you have SSH access, you know your way around the database and you have the time. I recommend getting help if any of these apply:

• It is a store and you suspect card or customer data theft.
• You (or your hosting provider) already cleaned it and it came back.
• You do not know how they got in.
• The site brings in revenue and every day with the Google warning costs you money.

My prices, published, no surprises:

• WordPress (WordPress malware removal): €219 excluding VAT. With priority over other work: +€80.
• PrestaShop or WooCommerce (hacked PrestaShop repair): €349 excluding VAT, including a review of the payment step and customer data. With priority: +€100.
• Other CMSs or custom PHP: from €390, with a fixed quote before I start.

Every cleanup includes the Google Search Console review, closing the way in, a report of what was there and what I did, and a 90-day guarantee: if it gets reinfected within that period, I clean it again at no cost. All of it is on hacked website repair. If you are not sure it is infected, start with the free scan.

Sources

• web.dev: Clean and maintain your site (copy the infected site before cleaning, restore only a backup from before the hack and change every password).
• web.dev: Identify the vulnerability (weak passwords, outdated software and infected admin computers as ways in).
• WordPress: FAQ "My site was hacked" (document dates, check your local computer, change FTP, panel and MySQL access and renew the wp-config.php keys to end sessions).
• WP-CLI: wp core verify-checksums (compares the core with the WordPress.org checksums).
• EDPB: Guidelines 9/2022 on personal data breach notification under GDPR and AEPD: personal data breach notification (in Spanish) (Article 33 GDPR, 72-hour deadline).