- First, stop the bleeding: isolate the site to prevent further damage and protect your visitors.
- Recovery means finding out what happened, rebuilding from a clean base and closing the door the attackers came through.
- Documenting everything during the incident is essential, both for recovery and for your legal obligations.
The call came in at 9:30 in the morning: “My website is redirecting to a page that downloads malware”. Our client had found out because one of their own customers had complained. According to the logs, the site had been like that for at least 18 hours. Nobody had noticed.
That’s the typical scenario: you discover the hack late, once it has already done damage. What you do in the first few hours determines how serious the incident ends up being. This is the protocol we follow, in order of priority (and here’s a full case from start to finish).
Phase 1: immediate containment (first 30 minutes)
The goal is to prevent further damage. Don’t think about fixing yet; think about stopping the bleeding.
1. Put the site into maintenance mode or take it offline.
If you can get into the WordPress dashboard or your hosting control panel, turn on maintenance mode; if not, ask your host to suspend the account temporarily. This protects visitors and stops the attacker from continuing to use your server.
Another option is to point your DNS to a static maintenance page on another server, leaving the compromised one isolated.
2. Keep a copy of the compromised site.
Before deleting or restoring anything, download the files, database and logs, and store them separately. They’re the evidence of what happened: you’ll need them to find the point of entry and to justify what you did. Many hosts delete logs after just a few days.
3. Change every password.
WordPress admin, hosting, FTP, database and any email linked to the domain. Assume they’re all compromised. Do it from a computer you know is clean and use random passwords of 20 characters or more, generated with a password manager. If your team is shaky on this, go over the basics of passwords, 2FA and password managers.
4. End active sessions.
In WordPress, log out sessions from each user’s profile and regenerate the security keys (salts) in wp-config.php, which forces everyone to log in again. This kicks out any attacker who is still inside.
5. Notify the key people.
Management, your data protection officer or legal lead (if personal data is at stake) and, where relevant, key clients who were exposed. Communicating early, even incompletely, beats silence.
Phase 2: damage assessment (first 4 hours)
With the site isolated, it’s time to work out what happened and how far the problem goes.
Analyze the access logs.
Look for suspicious requests: POSTs to files that shouldn’t accept uploads, wp-admin logins from unusual IPs, requests with SQL injection or XSS patterns. Look especially for:
- PHP files uploaded to the uploads folder.
- Requests to files that didn’t exist before (backdoors with random names).
- Successful wp-admin logins from places your team can’t possibly be.
Identify the attack vector.
How did they get in? The most common routes are:
- An outdated plugin or theme with a known vulnerability.
- A weak password, or one reused and leaked from another service.
- Compromised FTP credentials.
- SQL injection through a vulnerable form.
- A supply chain attack: a legitimate plugin compromised at the source.
Identifying the vector is critical, because it determines what needs fixing to avoid reinfection, and tells you how long you’ve been compromised, which is key to choosing which backup to restore.
Assess what data was exposed.
Did they access the customer database? Did they export it? Did they install something to capture what people type into forms? Did they modify core files? The answers determine whether you have notification obligations under the GDPR and what you need to tell those affected. Also review connected services (CRM, email, payment gateway) and where your customers’ data is really stored.
Phase 3: cleanup and recovery (days 1 to 3)
Don’t try to “clean” the compromised site and keep using it. Attackers usually leave several backdoors, and it’s very hard to be sure you’ve found them all.
The golden rule: rebuild, don’t clean.
1. Start from a clean backup.
Restore a backup from before the intrusion (not before the detection: the attacker may have been inside for weeks) and fix the vulnerability before putting it live. If you have no clean backup at all, the problem is bigger, but you can rebuild by hand:
- A clean install of WordPress (or whichever CMS you use).
- Plugins freshly downloaded from the official repositories, never copied from the compromised server.
- The same goes for themes.
- The database reviewed table by table before importing it.
2. Audit the database.
In WordPress, look for:
- Users with the administrator role you don’t recognize.
- Rows in the wp_options table with suspicious names or base64-encoded values.
- Drafts or private posts containing code (scripts, iframes).
- Extra tables that don’t belong to the core or to known plugins.
3. Verify the files.
Compare the core files with the originals from wordpress.org: any difference is suspicious. With WP-CLI, the “wp core verify-checksums” command does it in seconds, and security plugins such as Wordfence or Sucuri also do it automatically.
4. Keep the site offline until everything is verified.
Don’t reopen it to the public until you’re sure it’s clean. A site that gets hit again the moment it goes live is worse than a few more hours offline.
Phase 4: close the door (days 3 to 7)
The site is clean. Now it’s time to stop it happening again.
1. Update everything.
Core, plugins and themes. Remove any plugins you don’t need: every plugin is potential attack surface.
2. Harden access.
- Mandatory 2-step verification for every administrator.
- Limited login attempts (with plugins such as Limit Login Attempts Reloaded).
- Changing the wp-admin login URL: it’s security through obscurity, but it cuts down bot noise.
- Restricting admin access to specific IPs if your team is small and works from fixed locations.
3. Firewall and monitoring.
Set up a WAF (web application firewall) such as Cloudflare, Sucuri or Wordfence. And turn on alerts that warn you if core files change.
4. Automated, off-site backups.
Schedule daily backups off the server (Google Drive, Dropbox, Amazon S3) and test restoring them from time to time: a corrupt backup is as useless as no backup at all.
5. Review and document.
Write an incident report: what happened, how they got in, how it was detected, how long the response took and what lessons you’ve learned. It helps prevent future incidents and is part of what the GDPR requires you to document.
Legal and notification implications
If the incident involves personal data of customers or visitors:
GDPR. The breach must be reported to the supervisory authority (in Spain, the AEPD) without undue delay and, where feasible, within 72 hours of becoming aware of it (if you report later, you must justify the delay), unless it’s unlikely to pose a risk to the people affected. If the risk is high, you must also inform them. And even if you conclude that you don’t need to notify, you have to record the breach and the reason for that decision.
Corporate clients. If yours is a B2B website, tell clients who may have been exposed: early transparency protects the relationship more than hiding it.
Advice and support. For serious incidents, get specialized legal advice. In Spain, INCIBE also offers free cybersecurity help on 017, and if there is extortion or data theft, consider reporting it to the police.
Frequently asked questions
How do I know if my website has been hacked?
Common signs: redirects to strange sites, content you didn’t create, extreme slowness, unknown files, Google Safe Browsing warnings or alerts from your host. To catch it early, check the Security Issues report in Search Console and run a malware scanner.
Should I pay if they demand a ransom?
Generally, no. There’s no guarantee you’ll get the key to recover your data, and paying can mark you as a target for future attacks. Restore from a backup. If you don’t have one, that’s the lesson for next time.
How long does it take to recover from a hack?
With a clean backup, from a few hours to a day. Without one, days to weeks rebuilding by hand, plus the time to check that everything is clean. Prevention is far, far cheaper.
Is my hosting provider responsible?
Usually not, unless the vulnerability was in their infrastructure. Most hacks are the site owner’s responsibility (outdated plugins, weak passwords). Check your contract and, if you’re about to sign one, include these technical clauses.
Conclusion
A hack is stressful, but it doesn’t have to be catastrophic. The difference between a minor incident and a disaster is preparation: backups that work, a response plan and speed of reaction.
The time to think about security is before the hack. But if you’re already in the middle of one, this protocol helps you act methodically rather than in a panic.
If your website has been compromised and you need urgent help to recover it, at Baqueiro we can help. One thing, though: once it’s back, let’s spend some time making sure it doesn’t happen again. A hack can be bad luck; a repeat usually points to a lack of prevention. Get in touch and we’ll look at it as soon as possible.