With this checklist, I guide you through the first 24 hours after an attack. I explain how to preserve information and handle the notification deadline with your data protection officer or lawyer.
Your website displays content you didn’t put there or redirects visitors to another page. Perhaps your hosting provider contacts you, or a client does. This is unsettling, but you don’t have to solve everything at once. I’d start by limiting the damage and preserving the information needed to understand what happened.
During these 24 hours, I’d follow the steps below and involve your technical contact early. If you need help right away, the Website hacked page shows you how to reach us. From now on, record every observation and change with a timestamp, because this helps with recovery and with establishing which data might be affected.
Take warning signs seriously
An attack can be clearly visible through unfamiliar text or changed images. Sometimes, however, a redirect only affects visitors arriving through Google. Spam emails sent from your website can also be a sign. I’d also check any warning from your hosting provider or Google straight away.
Log in to your provider only through the web address you type in yourself. Because a warning can itself be an attempt to deceive you, don’t follow a login link from a suspicious email. Ask your hosting provider to confirm what they observed and preserve existing logs.
Replace all credentials
From a clean device, immediately change the passwords for hosting, domain management and email. Start with accounts that can reset access to other accounts, and use a different password for each login.
- Replace credentials for the CMS, file transfers and database.
- Revoke old API keys and create replacement keys.
- End active sessions and enable two-factor authentication.
Also check users and recovery addresses in your hosting account. Document and block unfamiliar accounts. Check redirects and changes to the domain configuration. After the cleanup, change the CMS and database passwords and API keys again.
Stop access and preserve the current state
Block public access through your hosting provider or have an independent maintenance page displayed. Maintenance mode inside the compromised CMS alone won’t reliably stop an attacker, so agree with your provider on how to isolate the affected system. Visitors should no longer receive harmful content.
Before any cleanup, I’d have a copy of the compromised state made. This includes files, the database and existing access logs. Keep the copy separate and protected from unauthorized access. Label it as compromised so that nobody accidentally restores it later. This copy documents the incident and isn’t a clean backup for publishing the site again.
Don’t delete suspicious files yourself. Take screenshots of changed pages and note when the website last appeared normal.
Find the entry point
Common entry points include an outdated CMS or plugins that haven’t been updated. Weak passwords and exposed credentials are also possibilities. Have someone check which software versions were running and what the logs show, because one suspicious filename doesn’t by itself explain how access became possible.
I’d also check other websites in the same hosting account, because the visible damage may be somewhere other than the original entry point. Have someone look for additional user accounts and hidden ways to regain access. While the cause remains unresolved, the attacker can get into a newly published website again.
Clean up or restore safely
A backup from before the attack can make recovery easier if it’s known to be clean. I wouldn’t automatically use the latest backup for this without checking its date and contents. Close the exploited vulnerability before the restored website becomes publicly accessible.
Without a clean backup, someone experienced needs to investigate and clean the affected system or rebuild the website. Cleanup involves more than removing the visible change. Check forms and redirects before reopening the site too. If your site runs on WordPress, the WordPress guidance on hacked websites explains further steps.
Personal data and the notification deadline
If personal data might be affected, speak to your data protection officer or lawyer immediately, even if the technical work is still underway. Such data can include messages from contact forms. Establish together whether a personal data breach has occurred and what risks it poses to the people affected.
For such a breach, Article 33 GDPR requires notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Notification is only unnecessary if the breach is unlikely to result in a risk to the rights and freedoms of those affected. Review the notification requirement with your data protection officer or lawyer. Document the incident and the decision even if no notification is made.
Prevent a repeat
Assign responsibility for updates and security alerts. I also recommend using two-factor authentication and testing recovery from backups. A web application firewall can filter harmful requests and so complements website maintenance. You still need to fix security vulnerabilities.
I’d also consider whether a static website meets your needs. Without a publicly running CMS, certain ways of attacking the site disappear, while accounts and connected services still need protection.
Checklist for the first 24 hours
- Record every observation and change with a timestamp.
- Check warnings and log in to your provider only through the web address you type in yourself.
- From a clean device, change the passwords for hosting, domain management and email.
- Block public access through your hosting provider and have the compromised state preserved.
- If personal data might be affected, involve your data protection officer or lawyer right away and clarify the notification deadline.
- Have someone find the entry point and close the vulnerability before the website goes public again.
- Restore the website from a backup that’s known to be clean, or have it cleaned up.
If you need help with containment and recovery, the Website hacked page explains how we work. The website security services page explains how we protect access and applications before an incident.