Symptome und erste Diagnose: Ist Ihre Website gehackt?
Nicht jeder Hack ist auf den ersten Blick erkennbar. Angreifer haben ein Interesse daran, moeglichst lange unentdeckt zu bleiben - um Spam-Mails zu versenden, Besucher auf Phishing-Seiten umzuleiten oder Ihre Serverressourcen fuer andere Angriffe zu missbrauchen. Die folgenden Symptome sind typische Indikatoren fuer eine kompromittierte Website.
Typische Anzeichen einer infizierten Website
- Rote Warnseite im Browser oder in der Google-Suche (Google Safe Browsing: 'Diese Website koennte Ihren Computer schaedigen')
- Unbekannte Weiterleitungen zu Spam-, Pharma- oder Phishing-Domains
- Neue, unbekannte PHP-Dateien im Webspace (typische Namen: wp-tmp.php, c99.php, r57.php, WSO.php)
- Neue unautorisierte Administrator-Accounts im CMS-Backend
- Massiver Spam-Mailversand vom eigenen Server
- Deutlich verlangsamte Ladezeiten durch versteckte, zusaetzliche Prozesse
- Sicherheitswarnung in der Google Search Console unter 'Sicherheitsprobleme'
- Veraenderte Seiteninhalte, Fremdwerbung oder eingebetteter Schadcode im Quelltext
Kostenlose Schnellpruefung: Diese Tools liefern erste Hinweise
- Google Safe Browsing Transparency Report (transparencyreport.google.com/safe-browsing/search): zeigt, ob Google Ihre Domain als schaedlich eingestuft hat
- Sucuri SiteCheck (sitecheck.sucuri.net): scannt das Frontend auf bekannte Malware-Signaturen und Blacklist-Eintraege
- VirusTotal: prueft die Domain gegen ueber 70 Sicherheitsanbieter
- Google Search Console - Bereich 'Sicherheits- und manuelle Massnahmen': zeigt Google-seitig erkannte Probleme
- Website im Inkognito-Modus aufrufen: schliesst gecachte Warnungen aus und zeigt den aktuellen Zustand
Wichtige Einschraenkung
Remote-Scanner wie Sucuri SiteCheck scannen ausschliesslich den oeffentlich erreichbaren Teil Ihrer Website. Backdoors, Webshells und versteckte Schadcode-Dateien auf Serverebene bleiben dabei unentdeckt. Eine serverseitige Analyse ist zwingend erforderlich und kann nur mit Serverzugang durchgefuehrt werden.
Sofortmassnahmen in den ersten 60 Minuten
Die ersten Massnahmen nach einem Hack sind entscheidend fuer die Schadensbegrenzung. Ziel ist es, weitere Besucher nicht mit Malware in Kontakt zu bringen, die Angriffsvektoren zu unterbrechen und Beweise zu sichern - bevor Sie mit der eigentlichen Bereinigung beginnen oder uns beauftragen.
- 1
Website in Wartungsmodus versetzen
Versetzen Sie die Website sofort in den Wartungsmodus oder benennen Sie die index.php um. Kein Besucher sollte in diesem Zustand mit der infizierten Seite interagieren. Informieren Sie bei Bedarf Ihre Kunden kurz ueber eine geplante Wartung.
- 2
Alle Zugangsdaten aendern - von einem sauberen Geraet
Aendern Sie saemtliche Passwoerter: CMS-Administrator, FTP/SFTP, Datenbank, Hosting-Panel (cPanel/Plesk), SSH und E-Mail. Tun Sie dies ausschliesslich von einem Geraet aus, das selbst nicht kompromittiert ist. Verwenden Sie eindeutige Passwoerter mit mindestens 16 Zeichen je Konto.
- 3
Hoster informieren und Logs anfordern
Informieren Sie Ihren Hosting-Anbieter. Fordern Sie Zugang zu den Server-Logs an (access.log, error.log) - diese sind fuer die forensische Analyse des Einfallstors unverzichtbar.
- 4
Beweise sichern
Erstellen Sie Screenshots der Fehlermeldungen und sichern Sie die Log-Dateien. Legen Sie ein Archiv des aktuellen Webspace-Zustands an und beschriften Sie es als 'infiziertes Backup'. Dieses Archiv darf spaeter nicht als Wiederherstellungspunkt verwendet werden.
- 5
Sauberes Backup identifizieren
Versuchen Sie, den Zeitpunkt vor der Kompromittierung zu bestimmen. Pruefen Sie, welches Backup aus diesem Zeitraum verfuegbar ist - und scannen Sie es vor dem Einspielen auf Malware, um eine Reinfektion durch ein bereits infiziertes Backup auszuschliessen.
DSGVO-Hinweis: 72-Stunden-Frist beginnt sofort
Sobald Sie Kenntnis von einem Hack erhalten, startet gemaess Art. 33 DSGVO die 72-Stunden-Frist zur Meldung bei der zustaendigen Datenschutzbehoerde Ihres Bundeslandes - auch an Wochenenden und Feiertagen. Die Meldung entfaellt nur, wenn nachweislich kein Risiko fuer betroffene Personen besteht. Dieser Punkt wird weiter unten ausfuehrlich behandelt.
Unser Bereinigungsprozess: Drei Phasen fuer vollstaendige Malware-Entfernung
Eine professionelle Hack-Bereinigung laesst sich nicht auf das Loeschen einzelner schaedlicher Dateien reduzieren. Unser Prozess folgt einem strukturierten Drei-Phasen-Ansatz, der sicherstellt, dass weder Malware noch Backdoors noch die urspruengliche Angriffsluecke zurueckbleiben.
Phase 1: Forensische Diagnose und Schadensanalyse
Wir beginnen mit einem kombinierten Scan: Remote-Scanner fuer eine erste Uebersicht des oeffentlich erreichbaren Schadcodes, gefolgt von einer serverseitigen Dateianalyse. Dabei pruefen wir den Webspace auf bekannte Malware-Signaturen: obfuskierten PHP-Code (eval mit base64_decode, str_rot13, gzinflate, preg_replace mit /e-Modifier), unbekannte Dateien in Upload-Verzeichnissen, manipulierte .htaccess-Regeln sowie verdaechtige Eintraege in der Datenbank. Die Server-Logs werden nach dem Infektionszeitpunkt und dem Einfallstor ausgewertet.
Phase 2: Vollstaendige Entfernung - Dateisystem und Datenbank
Alle schadhaften Dateien werden identifiziert und entfernt. Dazu gehoeren PHP-Webshells (C99, R57, WSO, B374K), eingebettete Code-Snippets in CMS-Kerndateien, manipulierte Konfigurationsdateien sowie unautorisierte Datenbank-Eintraege und Cron-Jobs. Die Datenbank wird separat bereinigt: Content-Tabellen werden auf eingeschleuste Script-Tags und Iframes geprueft, Benutzertabellen auf unautorisierte Admin-Accounts, CMS-Optionen auf manipulierte Site-URLs und andere Konfigurationswerte.
Warum ein einzelner Scanner nicht ausreicht
Sicherheitsforscher haben dokumentiert, wie Malware das Sicherheits-Plugin, das sie aufspueren soll, selbst modifiziert: Warnungen werden aus der Datenbank geloescht, legitime Scan-Funktionen aus dem Quellcode entfernt und Plugin-Updates blockiert. Versteckte Backdoors bleiben dabei vollstaendig unentdeckt. Fazit: Kein einzelner Scanner ist allein zuverlaessig - die Kombination aus mehreren Werkzeugen und manueller Analyse ist Pflicht.
Phase 3: Angriffsvektor schliessen und Haertung
Eine Bereinigung ohne Schliessen der Angriffsluecke fuehrt innerhalb von Stunden zur Neuinfektion. Wir identifizieren das Einfallstor (veraltetes Plugin, schwaches Passwort, Serverkonfigurationsfehler, gestohlene FTP-Credentials), schliessen es und haerten die gesamte Umgebung nach Best Practices - inklusive Berechtigungen, 2FA-Aktivierung und WAF-Konfiguration.
Backdoors und Webshells: Die unsichtbare Gefahr nach dem Hack
Der Begriff 'Backdoor' bezeichnet Code oder Konfigurationen, die Angreifern nach dem initialen Einbruch dauerhaften Zugang zur Website sichern - auch wenn das urspruengliche Einfallstor geschlossen wird. Wer nur die offensichtliche Malware entfernt, aber die Backdoor uebersieht, erlebt die naechste Infektion innerhalb kurzer Zeit.
Die haeufigsten Backdoor-Typen
- PHP-Webshells (C99, R57, WSO, B374K): Grosse, eigenstaendige PHP-Dateien, die Angreifern eine vollstaendige Server-Benutzeroberflaeche per Browser bieten. Durch bekannte Signaturen oft erkennbar.
- Eingebettete Code-Snippets in legitimen Dateien: Wenige Zeilen obfuskierter PHP-Code, eingeschleust in wp-config.php, functions.php, index.php oder Theme-Dateien. Schwieriger zu finden, da die Wirtsdatei legitim wirkt.
- Manipulierte .htaccess-Dateien: Eingeschleuste Redirect-Regeln, die Besucher oder Suchmaschinen-Bots auf Schadseiten umleiten, waehrend direkte Aufrufe durch den Administrator normal erscheinen.
- Unautorisierte Cron-Jobs auf Serverebene: Regelmaessig ausgefuehrte Skripte, die Malware erneut einschleusen oder Spam versenden - selbst wenn die infizierten Dateien im Webspace entfernt wurden.
- Unautorisierte Datenbank-Eintraege: Eingebetteter JavaScript-Code in Content-Tabellen oder manipulierte Plugin-Konfigurationen, die bei jedem Seitenaufruf ausgefuehrt werden.
Besonders gefaehrdete Verzeichnisse je CMS
- WordPress: /wp-content/uploads/, /wp-content/plugins/, /wp-content/themes/ - insbesondere deaktivierte, aber nicht geloeschte Themes
- Joomla: /tmp/, /cache/, /images/ - da diese Verzeichnisse schreibbar sein muessen
- TYPO3: fileadmin/, Extensions-Ordner - besonders bei veralteten Extensions mit bekannten Schwachstellen
- Alle CMS: Root-Verzeichnis und alle Ordner mit 777-Berechtigungen
Vergleich mit sauberer Installation
Eine bewaehrte Methode zur Backdoor-Erkennung ist der Dateivergleich mit einer frischen CMS-Installation. Jede Abweichung in Core-Dateien ist ein Warnsignal. Fuer WordPress-Instanzen laesst sich dieser Vergleich mit dem nativen Plugin-Integritaetscheck sowie mit spezialisierten Tools wie Wordfence (serverseitiger Scan) und Sucuri (zwei Scan-Schichten: Remote und serverseitig) durchfuehren.
Google Blacklist entfernen: Schritt fuer Schritt zurueck in die Suchergebnisse
Wenn Google Ihre Website als schaedlich eingestuft hat, zeigt der Browser eine rote Warnseite - und Ihre Seite wird aus den Suchergebnissen entfernt oder stark abgewertet. Das betrifft nicht nur Google: Auch Norton Safe Web, McAfee WebAdvisor, Avast und Bing fuehren eigene Sicherheitslisten. Der Removal-Antrag kann erst nach vollstaendiger Bereinigung gestellt werden.
- 1
Malware vollstaendig identifizieren
Google Search Console aufrufen - Bereich 'Sicherheitsprobleme'. Google nennt dort die Art des erkannten Problems und zeigt betroffene URLs. Diese Informationen sind die Grundlage fuer die Bereinigung.
- 2
Vollstaendige Bereinigung durchfuehren
Saemtliche Malware, Backdoors, eingeschleuste Inhalte und Cloaking-Umleitungen werden entfernt. Erst wenn keine schadhaften Inhalte mehr vorhanden sind, hat ein Review-Antrag Aussicht auf Erfolg. Ein zu frueh gestellter Antrag verlaengert die Sperrzeit, weil Google dann erneut einen negativen Befund erheben kann.
- 3
Sicherheit haerten
CMS, Plugins und PHP auf aktuelle Versionen aktualisieren. Starke, eindeutige Passwoerter setzen. 2FA fuer alle Admin-Zugaenge aktivieren. Datei-Berechtigungen korrekt setzen: Verzeichnisse 755, Dateien 644, Konfigurationsdateien wie wp-config.php 440 oder 400.
- 4
SEO-Schaden beheben
Durch den Hack entstandene Probleme im Suchmaschinenkontext beheben: Spam-Seiten und Doorway-Pages entfernen, eingeschleuste Keyword-Texte loeschen, Cloaking-Weiterleitungen vollstaendig deaktivieren. Google unterscheidet zwischen dem Sicherheitsproblem und eventuellen manuellen Abstrafungen.
- 5
Review-Antrag stellen
In der Google Search Console unter 'Sicherheitsprobleme' den Button 'Review beantragen' aufrufen. Dort muessen die ergriffenen Massnahmen konkret beschrieben werden. Googles automatisierte Systeme pruefen die Seite typischerweise innerhalb von 1-3 Tagen. Anschliessend kann derselbe Antrag fuer weitere Blacklists gestellt werden: Bing Webmaster Tools, Norton Safe Web und McAfee WebAdvisor haben eigene Removal-Prozesse.
Bearbeitungszeit und Rankingverlust
Die Google-Pruefung dauert typischerweise 1-3 Werktage. Wenn Ihre Website bereits deindexiert war, kann die Wiederherstellung des Rankings mehrere Wochen in Anspruch nehmen - je nach Dauer und Schwere der Infektion. Fruehzeitige Bereinigung begrenzt den SEO-Schaden erheblich.
DSGVO und Rechtliches: Was bei einem Hack zu melden ist
Ein Website-Hack ist in vielen Faellen eine meldepflichtige Datenpanne im Sinne der Datenschutz-Grundverordnung. Viele Unternehmen sind sich dieser Pflicht nicht bewusst - oder unterschaetzen die Konsequenzen einer verspaeteten oder unterlassenen Meldung.
Art. 33 DSGVO: Meldepflicht gegenueber der Datenschutzbehoerde
Wenn durch den Hack personenbezogene Daten betroffen sind (zum Beispiel Kundendaten, E-Mail-Adressen, Bestelldaten, Zahlungsinformationen), beginnt mit dem Zeitpunkt der Kenntniserlangung eine 72-Stunden-Frist zur Meldung bei der zustaendigen Datenschutzbehoerde Ihres Bundeslandes - auch an Wochenenden und Feiertagen. Die Meldung entfaellt nur, wenn nachweislich kein Risiko fuer betroffene Personen besteht.
Art. 34 DSGVO: Benachrichtigungspflicht gegenueber Betroffenen
Wenn die Datenpanne voraussichtlich ein hohes Risiko fuer die Rechte und Freiheiten natuerlicher Personen zur Folge hat - etwa bei Kompromittierung von Zahlungsdaten oder Gesundheitsinformationen - muessen die betroffenen Personen unverzueglich informiert werden. Die Pflicht entfaellt, wenn die betroffenen Daten nachtraeglich verschluesselt wurden.
Bussgelder bei Verletzung der Meldepflicht
Gemaess Art. 83 Abs. 4 DSGVO koennen Verstoesse gegen die Meldepflicht mit Bussgeldern bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes geahndet werden. Datenschutzbehoerden bewerten eine verspaetete oder unterlassene Meldung haeufig schwerer als die Datenpanne selbst. Technische Schutzmassnahmen gemaess BSI-Empfehlungen gelten als Erfuellung des Gebots aus Art. 32 DSGVO ('Stand der Technik').
Wiederinbetriebnahme und Haertung: Nachhaltig sicher
Nach der Bereinigung folgt die Wiederinbetriebnahme - aber nicht ohne Haertungsmassnahmen. Ohne diese bleibt die Website ein leichtes Ziel fuer denselben oder aehnliche Angriffe. Die folgende Checkliste beschreibt, was vor dem Wiederonlinegehen zwingend umgesetzt sein muss.
BSI-Grundschutz APP.3.2 als Orientierung
Das BSI-Grundschutz-Kompendium APP.3.2 (Webserver) definiert verbindliche Massnahmen fuer sicher betriebene Webserver: Schwachstellen- und Patchmanagement, SQL-Injection-Schutz, Verschluesselung vertraulicher Datenbankinhalte, WAF-Konzeption sowie Backup- und Disaster-Recovery-Plaene. Wer diese Anforderungen erfuellt, erfuellt gleichzeitig die technischen Anforderungen aus Art. 32 DSGVO ('Stand der Technik').
Fuer weitergehende Praevention - etwa regelmaessige Sicherheitsaudits, Penetrationstests und kontinuierliches Monitoring - empfehlen wir unsere uebergeordnete Sicherheitsleistung auf /leistungen/website-sicherheit/. Dort finden Sie auch Informationen zu verwandten Unterleistungen wie SSL/TLS-Konfiguration, Sicherheitsaudit und Performance-Optimierung.
Die haeufigsten Fehler bei der Selbstbereinigung
Viele Websitebetreiber versuchen zuerst, den Hack selbst zu beheben - was grundsaetzlich moeglich ist, aber typischerweise in eine Reihe vermeidbarer Fehler fuehrt, die den Schaden vergroessern oder die Bereinigung unwirksam machen.
- Remote-Scanner allein verwenden: Tools wie Sucuri SiteCheck scannen nur das Frontend. Backdoors und Webshells im Dateisystem bleiben unentdeckt - die Website gilt als sauber, obwohl Angreifer weiterhin Zugang haben.
- Backup einspielen ohne Angriffsvektor zu schliessen: Das haeufigste Problem. Das Backup stellt den Stand vor dem Hack wieder her - aber die Sicherheitsluecke ist noch offen. Innerhalb von Stunden wird die Seite erneut infiziert.
- Infiziertes Backup einspielen: Wenn das Backup aus dem Zeitraum nach der Erstinfektion stammt, bringt es die Malware mit. Das Backup muss vor dem Einspielen gescannt werden.
- Nur das CMS-Passwort aendern: Angreifer, die Zugang hatten, haben in der Regel auch FTP/SFTP- oder Hosting-Credentials extrahiert. Nur das CMS-Passwort zu aendern reicht nicht.
- Einem einzigen kompromittierten Scanner vertrauen: Angreifer koennen den Scanner selbst deaktivieren. Mehrere unabhaengige Werkzeuge sind Pflicht.
- Zu lange warten: Malware, die innerhalb von Stunden entdeckt wird, fuehrt selten zu dauerhaftem Blacklisting und grossem SEO-Schaden. Wer Wochen wartet, riskiert Deindexierung, verlorene Rankings und umfassende DSGVO-Konsequenzen.
Empfehlung fuer unsichere Faelle
Wenn Sie nicht sicher sind, ob Ihre Bereinigung vollstaendig war, koennen Sie einen nachtraeglichen Verifikations-Scan beauftragen. Wir pruefen auf Serverebene, ob noch Malware oder Backdoors vorhanden sind - ohne dass Sie die gesamte Bereinigung neu starten muessen.