Guides · Website · Hacking
Hacked Website: What to Do in the First 72 Hours
Preserve the evidence, cut off public access, reset the compromised credentials and check whether personal data was affected. Here are the actions to take, in order.
The short answer
If your website has been hacked, start by noting the time and the signs you observed. Keep every file as it is. Before deleting anything or restoring a backup, have a copy made of the site, the database and the technical logs.
Next, cut off public access to the site or put it behind a maintenance page, without destroying the compromised environment. From a clean device, reset the credentials for your hosting, the site’s admin area, the domain name, the database and any connected services. Revoke every session that is still open.
In the first hours, ask your provider to identify the data and accounts the attacker may have reached. If personal data is involved, you may have 72 hours to notify the CNIL (France’s data protection authority). If cyber insurance may cover the incident, other deadlines apply for filing a police report and reporting the loss to the insurer.
Put a rebuilt installation back online, built from trusted sources, once you have closed the entry point. Restoring a backup without knowing when the site was hacked can bring the attack back.
Confirm the hack without changing the site
A hacked website does not always show a ransom page. The most visible signs are a redirect to another site, a browser or Search Console warning, a new administrator account, emails sent from your domain, or files changed without any planned work.
Take a screenshot of what appears, and note the page address, the date, the time and who spotted the problem. Check from another device without logging back in to the admin area. At this stage, record what you see and keep every file intact.
Cut off public access, preserve the evidence
Before deleting anything, have the site files, its database and any available logs copied. The copy must keep the compromised state exactly as it was found. It will be used to find the entry point and to date the attacker’s actions.
Then put the site behind a maintenance page or block public access. From a device that was not used to administer the site during the incident, reset the main credentials first: hosting, site admin and domain name. Revoke active sessions, then continue with the database, file transfer access, API keys and email.
What not to do
- Reinstalling or cleaning the site before keeping a copy of it
- Restoring a backup without knowing the likely date of the intrusion
- Changing passwords from a device that may be compromised
- Announcing the origin or extent of the attack publicly before confirming them
See the technical detail: preserve, clean and rebuild
What to preserve, depending on your hosting
Preserve the data before running an antivirus scan, updating a plugin or restoring a backup. Then work on a copy.
| Environment | Preserve first | Persistence points to check |
|---|---|---|
| WordPress or another CMS on shared hosting | Files, full database export, access and error logs, list of administrator accounts, history available in the customer area | Must-use plugins or unfamiliar plugins, active theme, scheduled tasks, redirect rules, configuration files, recently created accounts |
| Virtual or dedicated server | Disk image or snapshot, system and web logs, SSH connections, processes and scheduled tasks, firewall rules | Authorized SSH keys, added services, system tasks, users, web proxy, temporary files and startup mechanisms |
| Cloud infrastructure | Volume snapshots, history of admin actions, logs from the load balancer, web application firewall and storage, network rules, identities and roles | New keys, new roles, functions or scheduled tasks, modified secrets, widened network rules, disabled logs |
| Domain, DNS and CDN | History of DNS changes, accounts and sessions, redirect rules, cache and firewall events | Modified name servers, added subdomains, redirects, rules that bypass the origin server |
Reset credentials in the right order
- From a clean device, reset the main hosting or cloud account and turn on two-factor authentication.
- Revoke existing sessions, tokens and keys before creating new ones.
- Reset access to the domain name and check the name servers.
- Reset the admin accounts for the site, the database, file transfer and outgoing email.
- Replace the secrets the site uses: API keys, database passwords, signing keys and backup access.
- Document what was not reset, and why.
Validate before reopening
- The known entry point is closed or covered by a documented measure
- No unknown administrator account, key or scheduled task remains active
- Executable files come from a trusted source
- Any content carried over has been checked
- Sessions have been revoked and secrets reset
- Logging and monitoring work
- A post-rebuild backup has been created outside the compromised environment
Alert your host and check your obligations
Notify your host as soon as the initial copy is safe. Ask them to preserve their own logs, confirm the actions already taken and flag any unusual access to the customer area or the server.
If personal data may have been lost, altered or viewed, start right away on the assessment needed to notify the CNIL. The deadline may be 72 hours from the moment you become aware of the breach. Also check your cyber insurance policy: the police report and the report of the loss each follow their own deadlines.
Identify and close the entry point
Start with the common causes: a plugin or theme that was not updated, an administrator account protected by a reused password, hosting or file transfer credentials picked up from another device, or a technical key left active.
Cross-check the server logs against file modification dates, admin logins and account changes. Check older files too: some intrusions alter file dates. If the entry point remains unknown, say so plainly and step up monitoring before anything goes back online.
Rebuild, then go back online
Start from a clean installation. Reinstall the content management system, plugins and theme from their official sources. Carry over from the old site only content and data you have checked. An earlier backup is usable only if its date precedes the intrusion and its restoration has been verified.
Before reopening the site, delete unknown accounts, reset keys and passwords, revoke all sessions, turn on two-factor authentication for admin accounts and check redirects, scheduled tasks and DNS settings. Then watch for new files, logins and errors.
Fix what allowed the intrusion
Write a short report: confirmed or probable entry point, data affected, credentials reset, components rebuilt and actions still to complete. Then fix the cause: updates, removal of unneeded accounts, two-factor authentication, separation of access rights and error monitoring.
Finally, check that a backup kept independently of your host can really be restored. How often to test depends on how fast the site changes and on the maximum data loss the business can accept; it is not one number for everyone.
What to ask your provider
Did you keep a copy of the files, the database and the logs before deleting anything?
A date, a scope, a location and confirmation that the copy preserves the compromised state.
What is the confirmed or probable entry point, and what technical evidence supports that conclusion?
A named cause, a time period and the logs or files that make it plausible. “We don’t know yet” beats a certainty with no proof.
Which accounts, sessions, passwords and keys have been revoked or reset?
A complete list covering admin, hosting, domain, database, file transfer, email and connected services.
What personal data may have been lost, altered or viewed, and what uncertainties remain?
One answer per database, form, account or storage space, with the estimated period of exposure.
Was the site that went back online rebuilt from trusted sources, or just cleaned?
The list of what was reinstalled, what was carried over and what was checked before reopening.
Which clean backup do we have, and has a full restore been tested?
The backup’s date, proof that it predates the intrusion, and the result of a restore test.
Sources
- CNIL — Notifier une violation de données personnelles (Reporting a personal data breach)
The 72-hour deadline, its starting point, and the internal breach register.
- CNIL — RGPD, chapitre 4, articles 32 à 34 (GDPR, Chapter 4, Articles 32–34)
The text of the security and notification obligation, in its current version.
- ANSSI — Guide d’hygiène informatique (IT hygiene guide)
The baseline measures expected of an organization, including logging and backups.
- ANSSI — Authentification multifacteur et mots de passe (Multi-factor authentication and passwords)
The up-to-date document on what to turn on for an admin account.
- Cybermalveillance.gouv.fr — Rapport TPE/PME 2025 (Small-business report 2025)
The state of the threats that actually hit companies with fewer than 50 employees.