Website hacked

What this means

A hacked website is not only a changed homepage. The attacker may have created an administrator, web shell, scheduled task, forwarding rule, malicious dependency, database user, cloud key, or CI/CD credential that survives a superficial cleanup.

If payment data, passwords, private customer data, or regulated information may have been exposed, preserve evidence and contact qualified security and legal help immediately. Do not promise customers that no data was taken until the scope is established.

Warning signs

• Unexpected pages, redirects, ads, downloads, administrator accounts, files, or database changes.
• Browser, search engine, hosting, WAF, antivirus, or customer malware warnings.
• Unexplained deployments, processes, scheduled jobs, outbound traffic, resource usage, or bills.
• Password resets, API calls, orders, refunds, or emails that nobody authorized.
• Logs are missing, disabled, cleared, or show access from unfamiliar locations.

Recover now

First 15 minutes

1. Start an incident log on a clean system. Record the discovery time, reporter, symptoms, URLs, screenshots, alerts, recent changes, and every response action in UTC.
2. Contain the site without destroying evidence. Use the hosting provider, load balancer, CDN, or WAF to enable maintenance mode, restrict traffic, or isolate the affected instance. Avoid editing or deleting suspicious files in place.
3. Preserve short-lived evidence. Save hosting, application, access, authentication, firewall, CDN, database, deployment, and cloud audit logs. Snapshot affected disks or instances when the provider supports it. A snapshot of a compromised system is evidence, not a safe backup.
4. Secure the control plane from a trusted device. Protect the primary email, identity provider, hosting, cloud, DNS, source control, CI/CD, and password manager. Revoke unknown sessions and use targeted credential rotation where the compromised path is known.
5. Escalate when impact is serious. Contact the hosting provider and insurer if applicable. Bring in an incident responder when customer data, payment systems, production secrets, multiple systems, or an unknown persistent attacker may be involved.

Today

1. Determine the likely entry point and time window. Review recent deployments, vulnerable plugins or dependencies, administrator logins, uploaded files, cloud changes, CI/CD activity, and DNS changes.
2. Create a clean recovery environment. Prefer rebuilding from trusted source, infrastructure configuration, and a known-good data backup over “cleaning” the compromised server. Patch the exploited software or configuration before exposing the replacement.
3. Restore only trusted data. Select a backup from before the earliest evidence of compromise. Scan uploads and user-controlled files. Do not restore executable files, plugins, themes, or server configuration blindly from the affected system.
4. Remove every persistence path. Review administrators, service accounts, SSH keys, API tokens, application secrets, database users, scheduled tasks, startup scripts, webhooks, OAuth apps, CI/CD variables, DNS, CDN rules, and email forwarding.
5. Rotate affected credentials at their issuer. Replace application, database, cloud, hosting, source-control, email, payment, and signing credentials that the attacker could access. Invalidate sessions and password-reset tokens when the application permits it.
6. Test the clean environment before cutover. Verify application behavior, permissions, outbound connections, dependencies, logging, backups, and security controls. Keep the compromised system isolated.
7. Return traffic gradually and monitor. Watch authentication, application, database, WAF, DNS, CDN, and cloud logs for the original indicators and new anomalies.
8. Handle notifications based on evidence and law. Record what information was exposed, whose data was involved, and for how long. Get legal advice for customer, regulator, payment-provider, insurer, or law-enforcement notifications.

Verify recovery

• The production system was rebuilt from a known-good source or independently verified clean; it was not merely returned to its earlier appearance.
• The exploited vulnerability or control gap is identified and fixed.
• All unauthorized accounts, keys, sessions, tasks, files, apps, routes, DNS entries, and forwarding rules are removed.
• Old credentials and sessions fail, while newly issued credentials work.
• Logs, alerts, backups, and restore procedures work in the recovered environment.
• External checks show the intended certificate, DNS, content, redirects, and response headers.
• Monitoring shows no recurrence during a defined observation period.

After recovery

Write a timeline covering initial access, persistence, affected data, containment, eradication, restoration, notifications, and cost. Schedule follow-up work with owners and dates. Keep forensic copies and the report outside the recovered production environment.

Prepare now

Access

• Hosting, cloud, DNS, source control, CI/CD, email, and administrator accounts use unique credentials and strong 2FA.
• Production access is named, least-privilege, and removable; no shared root or administrator login is used for routine work.
• Plugins, dependencies, runtimes, and operating systems have an owner and an update schedule.
• Unused accounts, plugins, endpoints, keys, and services are removed.

Backups and evidence

• Application data, user uploads, source, infrastructure configuration, and required secrets can be restored independently.
• At least one backup copy is isolated from normal production credentials and deletion.
• A restore test has produced a working site within the last three months.
• Security, access, deployment, DNS, and cloud audit logs are retained outside the affected server long enough to investigate.

Contacts and ownership

• Hosting, cloud, DNS, CDN/WAF, payment, insurer, legal, and security-response contacts are recorded outside production.
• Someone is explicitly allowed to take the site offline and communicate with customers.
• The team knows which customer-data and breach-notification rules apply to the business.

Practice

• A clean environment can be deployed from trusted source, restored with test data, given replacement secrets, and verified without using the current production server.

Common mistakes

• Deleting the visible malware and reopening. Attackers commonly leave other accounts, keys, tasks, or web shells.
• Restoring an unverified recent backup. The backup may already contain the intrusion or vulnerable code.
• Using the compromised server to coordinate recovery. The attacker may observe credentials and response plans.
• Rotating credentials before securing email and identity. An attacker controlling recovery channels can take them again.
• Keeping the site online to avoid downtime. Continued service can mean continued theft or infection; make an explicit risk decision.
• Declaring that no data was stolen because none is visible. Data theft often leaves no changed file or page.

Sources

• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• CISA: StopRansomware Guide—response and recovery practices
• CISA: Technical approaches to uncovering malicious activity
• UK NCSC: Hacked accounts