Zum Inhalt springen
Proactive security updates
Wartung

Emergency Plan: What to Do When Your Website Is Hacked

Emergency plan for a hacked website: detection, containment, forensics, cleanup, hardening and communication -- step by step.

15 min read NotfallGehacktIncident ResponseForensikPrävention

A hacked website is every shop operator's nightmare -- and it happens more often than many think. In 2025, 4.3 million websites were compromised through vulnerabilities (Patchstack, 2025). When it happens, every minute counts: the faster the attack is detected and contained, the less damage is done. This emergency plan describes the structured process from detection through forensics to complete cleanup -- and shows how professional prevention minimizes the risk.

Emergency Plan: Website Hacked -- Immediate ActionsIncident Response: Detect - Contain - Clean - Harden1. DetectionMonitoring alertMalware scanBehavior analysisCustomer report2. ContainmentIsolate websiteLock accessPreserve evidenceMaintenance page3. ForensicsFind entry pointDetermine scopeBuild timelineSearch backdoors4. CleanupRemove malwareClean installChange passwordsVerify data5. Post-Incident HardeningPatch vulnerabilityConfigure WAFStrengthen monitoringEnable 2FA6. CommunicationGDPR notificationInform customersIncident reportSearch ConsoleTime-Critical Actions (Golden Hour)0-60 min: Containment1-4 hrs: Forensics4-24 hrs: CleanupResult: Containment in 60 Min | Forensics Report | Full Cleanup | HardeningIncident Response | Malware Removal | GDPR Reporting | Backup Recovery | Post-Incident Review

Detecting an Attack: Signs of Compromise

Detecting a hack is the most critical step -- the earlier, the better. Professional monitoring detects compromises in real-time. Without monitoring, shop operators often notice the hack only through secondary symptoms: Google marks the website as unsafe, customers report suspicious redirects, search rankings collapse or the hosting provider suspends the account for spam sending.

Typical signs of compromise include: unknown files in the filesystem (especially PHP files in the upload directory), modified core files (checksums no longer match), new administrator accounts nobody created, suspicious database entries (injected JavaScript in page content or metadata), increased outbound traffic (spam sending or DDoS participation) and redirects to external websites.

According to IBM (2025), it takes an average of 197 days to detect a compromise -- and another 69 days to contain it. During this time, attackers can steal customer data, distribute malware and abuse the website for further attacks. Professional security monitoring reduces detection time to minutes instead of months.

Immediate Containment

Isolate website, lock access, activate maintenance page. Completed within 60 minutes of detection.

Forensic Analysis

Identify entry point, determine damage scope, reconstruct timeline and find hidden backdoors.

Complete Cleanup

Remove malware, clean install of software, change all passwords and verify data integrity.

Post-Incident Hardening

Patch vulnerability, configure WAF, strengthen monitoring and tighten access controls.

Communication

GDPR notification, customer information, Search Console cleanup and incident report for review.

Post-Incident Review

Document lessons learned, adjust processes and implement preventive measures for the future.

Phase 1: Containment in the Golden Hour

Once a hack is detected, the golden hour begins: the first 60 minutes where containment is the top priority. The goal is not cleanup (that comes later) but limiting damage. The website is taken offline or put into maintenance mode delivering no dynamic content. All admin access is locked, SSH keys rotated and database passwords changed.

Simultaneously, evidence is preserved: a complete image of the compromised system (filesystem and database) is created before any changes are made. Server logs, access logs and error logs are secured. This evidence is essential for subsequent forensics -- and potentially for legal proceedings. Premature cleanup without evidence preservation makes it impossible to identify the entry point and close the vulnerability.

Containment also includes checking adjacent systems: if the compromised server hosts additional websites, these may also be affected. Shared hosting environments are particularly vulnerable to lateral spread. All systems with network access to the compromised server must be checked.

Checklist: The First 60 Minutes After Detection

  • Put website into maintenance mode or take offline
  • Change all admin passwords immediately (CMS, database, FTP, SSH)
  • Rotate SSH keys and invalidate API tokens
  • Create complete image of the compromised system (filesystem + database)
  • Secure server logs, access logs and error logs from the last 30 days
  • Inform hosting provider about the incident
  • Check whether other websites on the same server are affected
  • Notify GDPR responsible person in the company (72-hour deadline begins)

These immediate measures must be completed within the first 60 minutes of detection. A prepared emergency plan with documented credentials and contact persons significantly reduces response time. Without preparation, simply searching for SSH credentials and hosting provider contact details will cost valuable minutes. Professional emergency support ensures trained technicians execute the process immediately and systematically.

Phase 2: Forensic Analysis

Forensic analysis answers three questions: How did the attacker gain entry? When did the compromise begin? And what did the attacker do? Analysis of access logs, file modification timestamps and database manipulations reconstructs a timeline of the attack. Typical entry points are: unpatched plugin vulnerabilities, stolen credentials, brute-force attacks on the admin area and file upload vulnerabilities.

Particularly important is the search for backdoors: experienced attackers place multiple backdoors in the system to regain access after cleanup. Typical backdoor types are web shells (PHP files enabling command execution), cron jobs that reload malicious code, modified core files and hidden admin accounts. An incomplete cleanup that misses a single backdoor leads to re-compromise -- often within hours.

Forensics also determines the damage scope: Was customer data accessed or exfiltrated? Was the database manipulated (e.g., payment redirects injected)? Were files encrypted (ransomware)? Was the server abused for further attacks (spam sending, cryptomining)? The damage scope determines necessary communication measures and potential GDPR notification requirements.

Phase 3: Cleanup and Recovery

Cleanup is not performed by selectively removing malicious code but ideally through a clean install: fresh installation of the software (WordPress, Shopware) from trusted sources, fresh installation of all plugins in current versions and data restoration from a backup created before the compromise. This approach is more effort than selective cleanup but ensures no backdoors are overlooked.

After the clean install, all credentials are changed: database passwords, admin accounts, FTP/SSH access, API keys and authentication keys/salts. All existing sessions are invalidated so any active attacker sessions end immediately. Additionally, two-factor authentication is activated for all admin access if not already in place.

Data restoration requires particular care: the backup must be from a point before the compromise. Since the attack may have started weeks before discovery (IBM, 2025: average 197 days), standard backups may not suffice. The forensic timeline helps determine the earliest safe backup point. Order and customer data between compromise and cleanup must be manually reviewed and transferred from the compromised system as needed.

Phase 4: Hardening and Prevention

After cleanup, the vulnerability that led to the breach must be closed. Forensic analysis identified the entry point -- now it is patched. Beyond that, additional security measures are implemented: a Web Application Firewall (WAF) with rules against the specific attack vector, enhanced monitoring focused on compromised areas and tightened access controls.

Hardening also includes reviewing all remaining plugins and themes for known vulnerabilities, updating all components to the latest version and implementing a regular maintenance routine ensuring security updates are applied promptly. A hack based on an unpatched vulnerability is a symptom of missing maintenance -- the root cause must be addressed long-term.

Supply Chain Attacks: When Trusted Sources Are Compromised

Not every hack begins with a vulnerability in your own system. Supply chain attacks compromise trusted third-party components -- an infected plugin update, a manipulated CDN script or a compromised dependency in the supply chain. These attacks are particularly dangerous because they bypass standard security measures: the update comes through the official channel, the script from the trusted domain. Detection requires additional measures like Subresource Integrity (SRI) for external scripts and hash comparisons for plugin updates.

The emergency plan must address the supply chain attack scenario separately. The immediate action is not cleaning the own system but isolating the compromised source: disable the external script, revert the plugin update, replace the CDN integration with a local copy. Only then follows the analysis of whether the malicious code was already active and which data may be affected. Professional maintenance continuously monitors plugin sources and CDN integrity to detect supply chain attacks early.

Prevention of supply chain attacks begins with dependency selection: every plugin, external library and embedded script increases the attack surface. A regular audit of external dependencies -- combined with the principle of only including what is absolutely necessary -- significantly reduces risk. For critical online shops, Content Security Policies that only allow explicitly approved sources are additionally recommended, along with monitoring that detects changes to embedded resources.

Post-Incident Review: Learning from the Incident

After cleanup and hardening comes the post-incident review: a structured meeting where the entire incident is analyzed. The questions are: what was the root cause? How long did detection take? How long did containment take? Which measures were effective, which were not? What must change to prevent a similar incident in the future? Results are documented in an incident report and feed into updated processes, monitoring rules and security policies.

The post-incident review is not about assigning blame but a systematic improvement process. In our experience, organizations with regular post-incident reviews significantly reduce the frequency of repeated incidents (project experience). The review should take place within 5 business days of the incident while memories are fresh. Documented lessons learned become part of the continuous improvement process and strengthen the resilience of the entire infrastructure.

Cost of a Hack: Direct and Indirect Damages

The financial impact of a hack extends far beyond direct cleanup costs. Direct costs include forensic analysis and cleanup (5,000 to 25,000 euros, project experience), revenue loss during downtime (averaging 5,600 euros per hour, Gartner, 2025) and potential GDPR fines. Indirect costs -- often underestimated -- include customer trust erosion, SEO ranking loss from the Google warning (recovery can take weeks), increased customer service costs and internal time spent on crisis communication and documentation.

The total cost of a data breach regularly exceeds pure cleanup costs many times over once fines, lost revenue and follow-up effort are factored in (project experience). For online shops with customer data and payment information, this amount is particularly high. Investment in professional prevention and maintenance costs a fraction of this sum and drastically reduces the risk of compromise.

Long-term costs are frequently underestimated: after a publicly known security incident, customer trust measurably declines. Existing customers question data security, potential new customers choose alternative providers. This loss of trust can be measured in lost revenue over months -- an effect that can exceed immediate cleanup costs by multiples. Investment in preventive security measures is therefore the better strategy not just technically but also from a business perspective.

GDPR Notification and Communication

When personal data is affected by a hack -- customer names, email addresses, order data, payment information -- Article 33 GDPR requires notification to the supervisory authority within 72 hours of becoming aware. When there is high risk to affected individuals (Article 34 GDPR), those individuals must also be informed directly. Failure to notify can result in fines of up to 10 million euros or 2 percent of annual revenue.

Communication to customers should be transparent and factual: what happened, which data is affected, what measures were taken and what customers should do (e.g., change passwords). Open communication builds trust -- cover-up attempts that are later exposed destroy it permanently. Additionally, the Google Search Console must be cleaned if Google has marked the website as "hacked".

The best emergency plan is one that never needs to be used. Professional prevention -- regular updates, hardened configuration, WAF, monitoring and tested backups -- drastically reduces the risk of compromise. But since absolute security does not exist, a prepared, tested emergency plan is the insurance that makes the difference between a manageable incident and an existential crisis. Investment in professional emergency support ensures that experienced experts respond within minutes when the worst happens.

Sources and Studies

This article is based on data from: Patchstack State of WordPress Security (2025), IBM Cost of a Data Breach Report (2025), GDPR Articles 33/34 on notification requirements. Figures cited may vary depending on industry and attack scenario.