Website Hacked: What to Do in the Next 6 Hours

Discovering your website has been hacked is stressful. The most important thing is to act quickly and systematically. This guide gives you a prioritised response plan for the first six hours. If you want a fast external check of what visitors and Google currently see, run a free scan before you start cleanup.

How to Know You've Been Hacked

Signs that something is wrong:

• Your website shows content you did not put there (spam, ads, redirects to other sites)
• Google Search Console shows a security alert
• Google is flagging your site as dangerous in search results ("This site may harm your computer")
• Visitors receive malware warnings from their browsers
• Your hosting provider suspended your account and cited malware
• You notice unusual admin accounts in your CMS
• You received an email from a security researcher reporting an issue
• Your website traffic dropped sharply without explanation (Google may have de-indexed it)
• A customer reports being redirected to a suspicious website

Step 1: Contain the Damage (Hour 0-1)

Take the website offline or into maintenance mode

This stops the attacker from continuing to use your website and prevents visitors from being exposed to malware or redirected to malicious sites.

WordPress: Add to your wp-config.php:

define('WP_MAINTENANCE_MODE', true);

Or use your hosting control panel to show a maintenance page.

Alternative: Put .htaccess rules in place to show a static maintenance page and block all other requests.

Why this matters: Every minute your hacked website remains online, it can be serving malware to your visitors and further damaging your search rankings.

Change all access credentials

Change these immediately, before attempting cleanup:

• CMS admin password (WordPress, Joomla, etc.)
• Hosting control panel password (cPanel, Plesk, etc.)
• FTP/SFTP passwords
• Database passwords (and update the CMS config file to use the new password)
• Email account passwords for any accounts linked to your domain

If you reuse passwords across services, the attacker may have obtained credentials from another breach and used them to access your website. Changing only the website password is not enough.

Revoke active sessions

After changing CMS passwords, invalidate all active sessions. In WordPress: add a new authentication key to wp-config.php (get new keys from wordpress.org/secret-key/1.1/salt/). This logs out all currently logged-in users.

Step 2: Assess the Damage (Hour 1-2)

What was accessed?

Determine what data the attacker may have reached:

• Website files: Check file modification dates. On Linux: find /var/www -name "*.php" -newer /tmp/reference -ls
• Database: Was customer data, order history or personal information in the database?
• Email: Did the attacker access email accounts hosted on the same server?
• Admin panel activity: Check your CMS audit logs for unusual logins or changes

Does this trigger a GDPR breach notification?

Use the 72-hour breach reporting decision tree:

• If customer data, personal information or passwords were accessible: very likely yes
• If the attacker only defaced the public site and no personal data was accessible: likely no, but document your assessment

The 72-hour clock starts when you become aware of the breach. If you discovered the hack now, the deadline for AP notification is 72 hours from this moment.

Report to the AP at: datalekken.autoriteitpersoonsgegevens.nl

Step 3: Clean Up (Hour 2-4)

You have two options: restore from a clean backup or manually clean the infected files.

Option A: Restore from a clean backup (recommended)

If you have a backup from before the attack:

1. Confirm the backup date predates the breach (check file modification times to estimate when the attack occurred)
2. Restore the backup to a staging environment first
3. Confirm the restored site is clean by scanning it
4. If clean, restore to production
5. Apply all pending updates before going back online. The vulnerability that was exploited must be patched first

Important: Do not simply restore and go live without patching. The attacker used a specific vulnerability. If you restore without fixing it, you will be hacked again within hours.

Option B: Manual cleanup

If no clean backup exists:

1. Download your current files via FTP/SFTP for offline analysis
2. Scan for malware:
   • Sucuri SiteCheck, remote scan
   • Maldet / Linux Malware Detect, server-side scan
   • Wordfence, WordPress malware scanner
3. Look for injected PHP code, especially in unexpected places: image directories, theme files, wp-includes, .htaccess
4. Check for new/modified user accounts in your CMS database
5. Remove malicious code. This requires technical knowledge. If you are not confident, hire a professional

Signs of common attack patterns:

• PHP eval() statements with base64-encoded strings in unexpected files
• New admin users created you did not create
• Added <script> tags in theme header or footer files
• .htaccess modified to redirect certain visitors (Googlebot, mobile users) elsewhere

After cleanup, before going back online

• All CMS and plugin updates applied
• All old/unused plugins removed
• All old/unused themes removed (except the active one)
• Admin accounts verified, remove any you did not create
• New authentication keys set (WordPress)
• Security scan shows clean

Step 4: Harden and Go Back Online (Hour 4-6)

After cleanup, implement measures to prevent recurrence:

Immediate hardening

• Enable automatic updates for WordPress core and plugins
• Install a security plugin (Wordfence, Sucuri) for ongoing monitoring
• Enable two-factor authentication for all admin accounts
• Limit login attempts (Wordfence, Login LockDown plugin)
• Change database prefix from wp_ to something random (if WordPress)

Remove Google's malware flag

If Google flagged your site:

1. Go to Google Search Console → Security Issues
2. Confirm the issues are resolved
3. Click "Request Review" Google typically reviews within 1-3 days.

Notify your customers (if needed)

If customer data was potentially accessed, you must notify affected individuals under GDPR Article 34. The notification should:

• Explain what happened
• Describe what data was potentially accessed
• Provide actionable advice ("change your password on any other accounts where you used the same password as on our site")
• Include your contact details for questions

Step 5: Document Everything

Document your incident response for:

• GDPR Article 33(5) internal breach record (required even if you don't notify the AP)
• Your own records for insurance claims or legal proceedings
• Future security improvements

Record:

• Date and time you discovered the attack
• How you discovered it
• What data was or may have been accessed
• Actions taken and timeline
• Outcome of AP notification assessment (whether you notified and why/why not)

Preventing Recurrence

After the immediate crisis is resolved:

• Review our secure website checklist and implement all 12 points
• Set up uptime monitoring that also monitors for content changes or malware
• Schedule quarterly security reviews
• Ensure backup automation is working and backups are off-site

---

This article is technical analysis, not legal advice. Consult a lawyer for advice specific to your situation.