WordPress-Sicherheitsvorfall im Handwerksbetrieb: Was in den ersten 60 Minuten zählt

Veröffentlicht: 26. September 2026 · Lesezeit: ca. 16 Minuten

Ein Handwerksbetrieb mit acht Mitarbeitern verliert seinen WordPress-Webauftritt für zwei Arbeitstage: Kontaktformular offline, keine neuen Auftragsanfragen, das eingebettete Aufmaß-Tool für Kunden nicht erreichbar. Zwei Tage Stillstand auf der digitalen Front kosten bei einem Stundensatz von 65 Euro und realistisch zwei entgangenen Angeboten schon 800 bis 1.500 Euro Umsatzausfall – dazu kommen Personalstunden für die Schadensbehebung und im schlimmsten Fall eine DSGVO-Meldung, die Anwaltskosten nach sich zieht. Automatisierte Angriffsskripte unterscheiden dabei nicht zwischen großen Konzernen und dem Elektrobetrieb um die Ecke: Sie scannen das gesamte Netz auf bekannte WordPress-Schwachstellen und schlagen zu, sobald ein Update fehlt. Wer in diesem Moment weiß, was zu tun ist, begrenzt den Schaden erheblich.

Ein Incident Response WordPress Angriff ist für viele Handwerksbetriebe Neuland – dabei sind die ersten Schritte nach einem Sicherheitsvorfall entscheidend dafür, wie groß der Schaden am Ende wirklich wird. Wer falsch reagiert, riskiert nicht nur eine längere Ausfallzeit, sondern auch den Verlust von Beweismitteln und – sofern Kundendaten betroffen sind – eine versäumte Meldepflicht nach DSGVO.

WordPress ist das weltweit meistgenutzte Content-Management-System und damit auch das meistangegriffene. Aktuell wurde eine kritische WordPress-Sicherheitslücke bereits Stunden nach Veröffentlichung des Patches aktiv ausgenutzt – wie heise Security berichtet. Für Betriebe, die ihre Website nicht aktiv überwachen, kann das zu einem ernsthaften Problem werden, bevor überhaupt jemand von der Lücke weiß.

Diese Checkliste richtet sich an Handwerksbetriebe, die WordPress für ihren Webauftritt nutzen – ob für Kontaktformulare, Referenzprojekte oder die Einbindung von Auftragsanfragen. Sie führt Sie Schritt für Schritt durch die ersten 60 Minuten nach einem Vorfall, erklärt die wichtigsten technischen und rechtlichen Pflichten und zeigt, wie Sie Ihr System dauerhaft besser absichern.

Kennzahl	Wert	Quelle
Täglich neu entdeckte Software-Schwachstellen (Ø)	78 pro Tag – Anstieg von 14 % gegenüber dem Vorjahr	BSI Lagebericht 2024
Anteil der Cyberangriffe gegen KMU	80 % aller angezeigten Fälle – überwiegend automatisierte Massenangriffe	BSI Lagebericht 2024
Registrierte Cybercrime-Fälle in Deutschland	136.865 – bei hoher Dunkelziffer liegt die tatsächliche Zahl deutlich höher	BKA Bundeslagebild Cybercrime 2023
DSGVO-Meldefrist bei Datenpanne mit personenbezogenen Daten	72 Stunden ab Kenntnisnahme (Art. 33 DSGVO)	Art. 33 DSGVO – gesetze-im-internet.de

Was bei einem WordPress-Vorfall wirklich auf dem Spiel steht

Viele Handwerksbetriebe unterschätzen, was ihre WordPress-Website tatsächlich alles transportiert: Kontaktformulare mit Namen und Telefonnummern von Interessenten, eingebettete Anfrage-Tools für Aufmaße, verlinkte Auftragsportale für Auftraggeber der öffentlichen Hand. Ein Incident Response WordPress Angriff betrifft damit nicht nur die Sichtbarkeit im Netz – er berührt im schlimmsten Fall personenbezogene Daten, GoBD-relevante Belege und laufende Kundenbeziehungen.

Der BSI Lagebericht Cybersicherheit zeigt: 80 % aller angezeigten Cyberangriffe richten sich gegen kleine und mittelständische Unternehmen – und zwar nicht durch gezielte Hacker-Arbeit, sondern durch automatisierte Skripte, die rund um die Uhr bekannte Schwachstellen scannen. Wer WordPress betreibt und Updates nicht zeitnah einspielt, steht früher oder später in dieser Schusslinie.

Für Handwerksbetriebe kommt ein branchenspezifisches Risiko hinzu: Monteure nutzen häufig private Smartphones oder Tablets, um auf der Baustelle Zeiten zu erfassen oder Aufmaße digital abzuschließen. Sind diese Geräte mit dem WordPress-Backend verbunden oder speichern sie Login-Daten, kann ein kompromittiertes WordPress-Konto schnell zum Einfallstor in das gesamte Betriebsnetz werden.

Als ISO/IEC 27001 zertifiziertes IT-Systemhaus sieht die TTG GmbH in der Praxis regelmäßig, dass die ersten 60 Minuten nach einem Sicherheitsvorfall über Ausmaß und Dauer des Schadens entscheiden. Diese Checkliste gibt Ihnen die Struktur, um in diesem Zeitfenster richtig zu handeln – auch wenn Sie gerade auf der Baustelle sind oder Ihr IT-Verantwortlicher nicht sofort erreichbar ist.

Klären Sie vorab, wer in Ihrem Betrieb im Notfall die Zugangsdaten für Hosting-Panel und FTP kennt.
Legen Sie fest, wer bei einem Sicherheitsvorfall die erste Ansprechperson ist – intern oder extern.
Stellen Sie sicher, dass aktuelle Backups Ihrer WordPress-Installation existieren und außerhalb des Webservers gespeichert sind.
Notieren Sie die Kontaktdaten Ihres Hosting-Anbieters und des IT-Dienstleisters – nicht nur im WordPress-Backend.

Prüfpunkte 1 & 2: Sofort isolieren und den Ist-Zustand sichern

Der häufigste Fehler beim Incident Response WordPress Angriff: Der Betriebsinhaber oder ein Mitarbeiter loggt sich ins wp-admin ein, um zu prüfen, was passiert ist. Damit werden unter Umständen Spuren verwischt, Schadcode wird ausgeführt, und der Angreifer bemerkt möglicherweise, dass er entdeckt wurde. Die Regel lautet: Erst isolieren, dann untersuchen.

Prüfpunkt 1: Website sofort in den Offline-Modus versetzen

Versetzen Sie die Website umgehend in den Wartungsmodus – nicht über das WordPress-Backend, sondern über das Hosting-Panel Ihres Anbieters oder direkt über die .htaccess-Datei. Viele Hosting-Anbieter bieten im Panel eine Ein-Klick-Funktion zum Sperren des Webverzeichnisses. Alternativ kann ein einfacher Eintrag in der .htaccess alle Zugriffsversuche auf eine statische Wartungsseite umleiten. Solange die infizierte Website erreichbar ist, können Besucher auf Schadsoftware stoßen oder weiterhin Daten abgegriffen werden.

Rufen Sie das Hosting-Panel auf (z. B. Plesk, IONOS, cPanel) und sperren Sie das Webverzeichnis.
Alternativ: Fügen Sie in der .htaccess eine Deny from all-Regel ein, um den Zugriff zu blockieren.
Informieren Sie Ihr Team sofort: Niemand soll sich in der Zwischenzeit in das wp-admin einloggen.

Prüfpunkt 2: Forensischen Snapshot anlegen – vor jeder Veränderung

Bevor irgendetwas bereinigt, gelöscht oder überschrieben wird, brauchen Sie eine vollständige Sicherung des infizierten Zustands – Dateisystem und Datenbank. Kennzeichnen Sie diesen Snapshot explizit als „INFECTED“ und speichern Sie ihn getrennt von Ihren regulären Backups. Dieser Stand ist Ihr Beweismittel: Er ermöglicht später die Analyse des Angriffsvektors und dient als Vergleichsbasis für die Bereinigung. Ohne diesen Schritt wissen Sie nach der Reinigung nicht, über welchen Weg der Angreifer hereingekommen ist – und können denselben Weg nicht zuverlässig schließen.

Erstellen Sie über das Hosting-Panel oder per SFTP eine vollständige Kopie des Webverzeichnisses.
Exportieren Sie die Datenbank über phpMyAdmin oder ein Hosting-Tool als SQL-Datei.
Speichern Sie beides außerhalb des Webservers – auf einem lokalen Rechner oder einem separaten Cloud-Speicher.
Benennen Sie die Dateien klar: backup_INFECTED_[Datum].

Für weitere Unterstützung bei der technischen Absicherung stehen Ihnen die IT-Sicherheitslösungen der TTG GmbH zur Verfügung.

Prüfpunkte 3 & 4: Zugangsdaten rotieren und den Angriffsvektor identifizieren

Zwei Fehler passieren beim Incident Response WordPress Angriff besonders häufig: Entweder werden Passwörter zu früh geändert – bevor Backdoors entfernt wurden – oder sie werden gar nicht vollständig rotiert. Beides ist problematisch. Wer die Zugangsdaten ändert, bevor alle Schadcode-Komponenten beseitigt sind, gibt dem Angreifer lediglich einen neuen Hinweis, ohne ihn wirklich auszusperren.

Prüfpunkt 3: Alle Zugangsdaten vollständig rotieren – in der richtigen Reihenfolge

Die korrekte Reihenfolge: erst Backdoors identifizieren und entfernen, dann alle Zugangsdaten wechseln. Das betrifft nicht nur das WordPress-Admin-Passwort, sondern zwingend auch FTP/SFTP-Zugänge, Datenbankpasswörter, das Hosting-Panel-Konto und – oft vergessen – E-Mail-Konten, die mit der Domain verknüpft sind. Bei Handwerksbetrieben, in denen Mitarbeiter mobile Zeiterfassungs-Apps oder Aufmaß-Anwendungen über dieselben Zugangsdaten nutzen, müssen auch diese Systeme geprüft werden.

Ändern Sie das WordPress-Admin-Passwort über die Datenbank (phpMyAdmin), nicht über das Backend.
Setzen Sie neue SFTP/FTP-Zugangsdaten im Hosting-Panel.
Ändern Sie das Datenbankpasswort in der wp-config.php und im Hosting-Panel synchron.
Prüfen Sie, ob Monteure oder externe Mitarbeiter eigene WordPress-Nutzerkonten haben – und löschen Sie nicht benötigte Konten.

Prüfpunkt 4: Angriffsvektor vor der Bereinigung klären

Eine Bereinigung ohne Ursachenanalyse ist wie das Schließen eines Fensters, während die Tür noch offen steht. Prüfen Sie systematisch: Welches Plugin oder Theme war veraltet? Gibt es Nutzerkonten mit schwachen Passwörtern? Zeigen die Server-Logs auffällige POST-Requests auf /wp-login.php oder /xmlrpc.php? Tools wie Wordfence oder das Plugin WP Cerber Security können dabei helfen, den Einstiegspunkt zu rekonstruieren – allerdings nur, wenn Logging vorab aktiviert war.

Prüfen Sie die Server-Zugriffslogs auf auffällige Muster rund um den mutmaßlichen Angriffszeitpunkt.
Vergleichen Sie die Datei-Zeitstempel im Webverzeichnis mit dem Zeitpunkt des letzten regulären Backups.
Prüfen Sie alle installierten Plugins auf veraltete Versionen – nutzen Sie dafür WPScan oder die Wordfence-Scan-Funktion.
Dokumentieren Sie den gefundenen Angriffsvektor schriftlich – dieser Nachweis ist später für DSGVO-Dokumentationspflichten relevant.

Für die technische Infrastruktur rund um Ihre WordPress-Installation empfiehlt sich ein Blick auf die sichere IT-Infrastruktur für KMU, die die TTG GmbH anbietet.

Prüfpunkte 5 & 6: DSGVO-Prüfung und rechtliche Pflichten

Dieser Punkt fehlt in nahezu allen deutschen Ratgeberartikeln zum Incident Response WordPress Angriff – dabei ist er für Handwerksbetriebe besonders relevant: Sobald personenbezogene Daten betroffen sind, läuft eine gesetzliche Uhr. Wer sie verpasst, riskiert erhebliche Bußgelder.

Prüfpunkt 5: DSGVO-Prüfung sofort einleiten

Stellen Sie unmittelbar fest, welche Daten auf dem betroffenen System gespeichert waren oder verarbeitet wurden. Für Handwerksbetriebe sind das typischerweise: Kontaktformular-Einträge mit Namen, Telefonnummern und Adressen von Interessenten, Kundendaten aus Auftragsformularen, E-Mail-Adressen aus Newsletter-Anmeldungen und – bei integrierten Auftragsportalen für öffentliche Auftraggeber – möglicherweise auch Angebots- und Vergabedaten. Sobald personenbezogene Daten betroffen oder potenziell abgeflossen sind, gilt Art. 33 DSGVO: Die Meldung an die zuständige Datenschutzaufsichtsbehörde muss binnen 72 Stunden nach Kenntnisnahme erfolgen.

Dokumentieren Sie den genauen Zeitpunkt, zu dem Sie von dem Vorfall erfahren haben – dieser Moment startet die 72-Stunden-Frist.
Listen Sie alle Datenarten auf, die auf der WordPress-Installation verarbeitet wurden.
Prüfen Sie, ob Kontaktformular-Plugins (z. B. Contact Form 7, Gravity Forms) Einträge in der Datenbank speichern.
Ziehen Sie bei Unsicherheit über die Meldepflicht einen Datenschutzbeauftragten hinzu – bevor die Frist abläuft.

Prüfpunkt 6: Dokumentation für Nachweis- und Aufbewahrungspflichten

Handwerksbetriebe unterliegen GoBD-konformen Aufbewahrungspflichten für geschäftsrelevante Unterlagen. Wenn Ihre WordPress-Website in die digitale Belegablage eingebunden ist – etwa über automatisch generierte Auftragsbestätigungen per E-Mail oder eingebettete Formulare, die Daten an Ihre Handwerkersoftware wie pds oder Streit übermitteln – dann ist der Incident auch aus steuerrechtlicher Sicht zu dokumentieren. Halten Sie fest: wann der Vorfall bemerkt wurde, welche Systeme betroffen waren, welche Maßnahmen wann ergriffen wurden und wer informiert wurde.

Legen Sie ein Incident-Protokoll an – ein einfaches Word-Dokument mit Zeitstempeln reicht für den Anfang.
Notieren Sie alle getroffenen Maßnahmen mit Uhrzeit und ausführender Person.
Bewahren Sie den forensischen Snapshot (aus Prüfpunkt 2) mindestens bis zum Abschluss der DSGVO-Prüfung auf.
Prüfen Sie, ob Ihr Datenschutzbeauftragter informiert werden muss – bei Betrieben ab 20 Mitarbeitern oft Pflicht.

Die IT-Dienstleistungen der TTG GmbH unterstützen Sie dabei, diese Dokumentationspflichten strukturiert umzusetzen.

Prüfpunkte 7 & 8: Technische Bereinigung und dauerhafte Absicherung

Nach Isolierung, Snapshot und DSGVO-Prüfung folgen die technisch anspruchsvollsten Schritte eines Incident Response WordPress Angriff: die eigentliche Bereinigung und die Härtung des Systems, damit der gleiche Angriffsweg nicht ein zweites Mal funktioniert.

Prüfpunkt 7: WordPress sauber bereinigen – oder sauber neu aufsetzen

Wer eine infizierte WordPress-Installation vollständig bereinigen möchte, muss alle Dateien gegen saubere Referenzversionen prüfen. Das klingt aufwändig, ist mit den richtigen Tools aber handhabbar. Wordfence Premium bietet eine Dateiintegritätsprüfung, die modifizierte Core-Dateien identifiziert. Für Plugins und Themes gilt: Deinstallieren, dann neu installieren aus dem offiziellen WordPress-Repository – nicht einfach überschreiben, da Backdoors oft in Ordnern liegen, die bei einem Update nicht überschrieben werden.

Unserer Erfahrung nach ist bei stark infizierten Installationen ein Neuaufsetzen auf Basis eines sauberen Backups schneller und zuverlässiger als eine manuelle Bereinigung. Wichtig: Das saubere Backup muss von vor dem Angriffszeitpunkt stammen – prüfen Sie daher die Zeitstempel Ihrer Backups gegen die Logs.

Scannen Sie alle Dateien mit Wordfence oder Sucuri Security auf bekannte Schadcode-Signaturen.
Ersetzen Sie WordPress Core-Dateien durch frische Downloads von wordpress.org – behalten Sie nur wp-config.php und wp-content.
Deinstallieren Sie alle Plugins vollständig, installieren Sie nur noch aktiv gepflegte Plugins neu.
Prüfen Sie die Datenbank auf verdächtige Einträge in den Tabellen wp_options und wp_users.

Prüfpunkt 8: Härtung und Monitoring einrichten

Nach der Bereinigung muss die Installation so konfiguriert werden, dass der nächste Incident Response WordPress Angriff entweder verhindert oder deutlich früher erkannt wird. Zwei-Faktor-Authentifizierung (2FA) für alle Admin-Konten, automatische Updates für WordPress Core und alle Plugins sowie ein externes Monitoring-Tool mit Dateiintegritätsprüfung sind dabei keine optionalen Extras, sondern Mindeststandard.

Aktivieren Sie 2FA für alle Nutzerkonten mit Editor-Rolle oder höher – z. B. über das Plugin WP 2FA.
Schalten Sie automatische Updates für WordPress Core und alle Plugins ein (wp-config.php: define('WP_AUTO_UPDATE_CORE', true);).
Richten Sie ein externes Monitoring ein, das Dateiänderungen im Webverzeichnis meldet – z. B. über Wordfence oder das Hosting-Panel.
Deaktivieren Sie die XML-RPC-Schnittstelle, sofern Sie diese nicht aktiv nutzen.

Mehr zu den strukturellen Voraussetzungen finden Sie bei der TTG GmbH – Ihrem regionalen IT-Partner.

Was tun, wenn Sie einen oder mehrere Punkte nicht erfüllen?

Nicht jeder Handwerksbetrieb hat einen IT-Verantwortlichen, der um 7 Uhr morgens erreichbar ist, geschweige denn einen forensischen Snapshot anlegen kann, während auf der Baustelle der erste Monteur schon wartet. Wenn Sie beim Durcharbeiten dieser Checkliste feststellen, dass mehrere Punkte nicht erfüllt sind, hilft eine klare Priorisierung nach Risiko weiter.

Typisch ist folgende Konstellation: Ein Sanitärbetrieb betreibt seine WordPress-Website über einen günstigen Shared-Hosting-Tarif. Die Kontaktformular-Einträge werden in der Datenbank gespeichert und zusätzlich an die pds-Handwerkersoftware weitergeleitet. Backups laufen automatisch – aber auf denselben Server, auf dem auch die Website liegt. Ein Angreifer, der Zugriff auf das Webverzeichnis erlangt, hat damit auch Zugriff auf die Backup-Dateien. Nach einem Incident Response WordPress Angriff stellt sich heraus: Das letzte externe Backup liegt drei Monate zurück, weil niemand geprüft hat, ob die automatische Sicherung tatsächlich funktioniert. Genau diese Lücke – Backup vorhanden, aber ungetestet – sehen wir regelmäßig auch bei anderen Betrieben dieser Größe.

Die Priorisierung nach Risiko sieht so aus:

Situation	Empfehlung	Warum
Kein externes Backup vorhanden	Sofort einrichten – noch heute	Ohne Backup kein Wiederanlauf nach einem Angriff
Kein 2FA für WordPress-Admin	Innerhalb einer Woche aktivieren	Häufigster Einstiegsweg für Angreifer
Kein Monitoring/Dateiintegritätsprüfung	Innerhalb von 30 Tagen einrichten	Ohne Monitoring bemerken Sie einen Angriff zu spät
DSGVO-Meldeprozess unklar	Datenschutzbeauftragten konsultieren	72-Stunden-Frist läuft ab Kenntnisnahme

Weiterführende Orientierung bietet das BSI – IT-Grundschutz für Unternehmen, das speziell für kleine Betriebe niedrigschwellige Maßnahmen beschreibt.

Betriebe in Nordhausen und Umgebung, die externe Unterstützung bei der Umsetzung suchen, können die TTG GmbH direkt ansprechen. Als IT-Systemhaus mit über 25 Jahren Erfahrung unterstützt die TTG GmbH Handwerksbetriebe dabei, diese Maßnahmen strukturiert und ohne übermäßigen Aufwand umzusetzen. Jetzt unverbindlich Kontakt aufnehmen.

Was sofort gilt, was in 30 Tagen und was dauerhaft

Nach einem Incident Response WordPress Angriff – oder nach dem Durcharbeiten dieser Checkliste als Vorsorgemaßnahme – stellt sich die Frage: Was muss wirklich sofort passieren, und was kann geordnet nachgezogen werden? Eine realistische Zeitleiste hilft dabei, Prioritäten zu setzen, ohne den laufenden Betrieb zu überfordern.

Sofort (innerhalb der ersten 60 Minuten nach einem Vorfall):

Website isolieren – Hosting-Panel oder .htaccess, nicht das WordPress-Backend.
Forensischen Snapshot anlegen – Dateisystem und Datenbank, als „INFECTED“ kennzeichnen.
Zeitpunkt der Kenntnisnahme dokumentieren – die 72-Stunden-DSGVO-Frist läuft ab diesem Moment.
IT-Dienstleister oder -Verantwortlichen informieren.

Innerhalb von 24–72 Stunden:

Angriffsvektor identifizieren, Backdoors entfernen, dann alle Zugangsdaten rotieren.
DSGVO-Prüfung abschließen: Sind personenbezogene Daten betroffen? Wenn ja, Meldung an die Aufsichtsbehörde vorbereiten.
WordPress sauber bereinigen oder auf Basis eines verifizierten Backups neu aufsetzen.
Website wieder in Betrieb nehmen – erst nach vollständiger Bereinigung.

Innerhalb von 30 Tagen:

Zwei-Faktor-Authentifizierung für alle Admin-Konten aktivieren.
Automatische Updates für Core und Plugins einschalten und testen.
Externes Backup-System einrichten und den ersten Restore-Test durchführen.
Monitoring mit Dateiintegritätsprüfung konfigurieren.

Dauerhaft:

Regelmäßige Überprüfung der installierten Plugins auf aktiv gepflegte Versionen – mindestens vierteljährlich.
Jährliche Überprüfung der Nutzerkonten: Wer hat noch Admin-Zugriff? Aushilfen mit erhöhter Fluktuation regelmäßig aus dem System entfernen.
Incident-Response-Plan schriftlich festhalten – wer macht was, wer ist erreichbar, welche Backups existieren wo.

Der Incident Response WordPress Angriff ist kein Einmal-Thema. Angriffsskripte entwickeln sich weiter, neue Schwachstellen kommen hinzu – täglich durchschnittlich 78 neue, wie das BSI für das vergangene Jahr dokumentiert hat. Wer die Nachsorge als dauerhaften Prozess versteht, ist deutlich besser aufgestellt als jemand, der nach einem Vorfall wieder zur Tagesordnung übergeht.

Häufige Stolperfallen – und wie Sie sie von Anfang an vermeiden

Beim Incident Response WordPress Angriff wiederholen sich dieselben Fehler immer wieder – unabhängig von der Betriebsgröße. Wer sie kennt, kann sie gezielt umgehen.

Stolperfalle 1: Das Backup liegt auf demselben Server wie die Website. Ein Backup, das bei einem Angriff mit kompromittiert wird, ist kein Backup. Externe Backups – auf einem separaten SFTP-Server, einem verschlüsselten Cloud-Speicher oder einem lokalen NAS im Büro – sind Pflicht. Viele Hosting-Angebote liefern serverseitige Snapshots mit, die bei einem vollständigen Server-Kompromiss ebenfalls verloren gehen können.

Stolperfalle 2: Zugangsdaten werden vor der Backdoor-Entfernung geändert. Wenn ein Angreifer eine Backdoor hinterlegt hat – zum Beispiel eine versteckte PHP-Datei in einem Upload-Ordner oder ein manipuliertes Plugin –, nützt das neue Passwort nichts. Die Backdoor bleibt aktiv und ermöglicht den erneuten Zugriff, ganz ohne Login-Daten.

Stolperfalle 3: Nur das WordPress-Admin-Passwort wird geändert. SFTP-Zugänge, Datenbank-Passwörter und Hosting-Panel-Konten werden vergessen. Bei Handwerksbetrieben, die Aufmaß-Apps oder digitale Bautagebücher über denselben Hosting-Account betreiben, kann ein nicht geänderter SFTP-Zugang den gesamten Bereinigungsaufwand zunichte machen.

Stolperfalle 4: Der Angriffsvektor wird nicht dokumentiert. Nach dem Stress des Vorfalls will man schnell wieder online sein – verständlich. Wer aber nicht festhält, über welches Plugin oder welchen Account der Angriff erfolgte, kann die gleiche Lücke nicht zuverlässig schließen. Eine Reinfektion innerhalb weniger Wochen ist dann wahrscheinlich.

Stolperfalle 5: Die DSGVO-Meldepflicht wird übersehen. Viele Betriebe wissen nicht, dass ein WordPress-Hack mit Kundendaten eine meldepflichtige Datenpanne darstellen kann. Die 72-Stunden-Frist nach Art. 33 DSGVO läuft ab dem Moment der Kenntnisnahme – nicht ab dem Zeitpunkt, zu dem die Analyse abgeschlossen ist. Wer zu spät meldet, riskiert ein Bußgeld, das den eigentlichen Schaden durch den Incident Response WordPress Angriff übersteigen kann.

Richten Sie externe Backups ein und testen Sie den Restore-Prozess mindestens einmal jährlich.
Entfernen Sie Backdoors vor dem Passwort-Wechsel – in dieser Reihenfolge, nicht umgekehrt.
Rotieren Sie alle Zugangsdaten vollständig: WordPress, SFTP, Datenbank, Hosting-Panel, verknüpfte E-Mail-Konten.
Dokumentieren Sie den Angriffsvektor schriftlich – auch wenn der Druck groß ist, schnell wieder online zu gehen.
Notieren Sie den Zeitpunkt der Kenntnisnahme sofort und prüfen Sie die DSGVO-Meldepflicht innerhalb der ersten Stunde.

Ihre Checkliste: So starten Sie jetzt

Versetzen Sie Ihre WordPress-Website sofort in den Offline-Modus – über das Hosting-Panel oder die .htaccess, nicht über das wp-admin-Backend.
Legen Sie einen forensischen Snapshot an: vollständiges Backup von Dateisystem und Datenbank im infizierten Zustand, gekennzeichnet als „INFECTED“, außerhalb des Webservers gespeichert.
Dokumentieren Sie den genauen Zeitpunkt der Kenntnisnahme – die 72-Stunden-DSGVO-Frist nach Art. 33 DSGVO beginnt in diesem Moment.
Prüfen Sie, welche personenbezogenen Daten auf der Installation gespeichert waren (Kontaktformulare, Kundendaten, Auftragsformulare) und entscheiden Sie über die Meldepflicht.
Identifizieren Sie den Angriffsvektor (veraltetes Plugin, schwaches Passwort, kompromittierter Nutzeraccount) – erst dann bereinigen.
Rotieren Sie nach der Backdoor-Entfernung alle Zugangsdaten vollständig: WordPress-Admin, SFTP/FTP, Datenbank, Hosting-Panel, verknüpfte E-Mail-Konten.
Aktivieren Sie nach der Bereinigung Zwei-Faktor-Authentifizierung für alle Admin-Konten und schalten Sie automatische Updates für WordPress Core und alle Plugins ein.
Richten Sie ein externes Backup-System und ein Monitoring mit Dateiintegritätsprüfung ein – und testen Sie den Restore-Prozess, bevor Sie ihn wirklich brauchen.

Häufig gestellte Fragen

Muss ich einen WordPress-Hack wirklich der Datenschutzbehörde melden?

Das hängt davon ab, ob personenbezogene Daten betroffen sind. Sobald auf Ihrer WordPress-Installation Kontaktformular-Einträge, Kundendaten oder Bestellinformationen gespeichert waren und ein Zugriff durch Dritte nicht ausgeschlossen werden kann, gilt Art. 33 DSGVO: Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden. Die Frist beginnt ab dem Moment, in dem Sie von dem Vorfall erfahren – nicht erst nach abgeschlossener Analyse. Im Zweifel lieber melden als die Frist versäumen.

Kann ich meine WordPress-Website nach einem Angriff einfach neu aufsetzen?

Ja – und in vielen Fällen ist das der schnellere und zuverlässigere Weg als eine manuelle Bereinigung. Voraussetzung ist ein sauberes Backup, das nachweislich von vor dem Angriffszeitpunkt stammt. Prüfen Sie die Zeitstempel Ihrer Backups gegen die Server-Logs, bevor Sie das Backup einspielen. Wer kein verlässliches externes Backup hat, muss entweder manuell bereinigen oder einen Teil der Inhalte neu aufbauen.

Unser Betrieb nutzt pds für die Auftragsverwaltung – ist das System auch betroffen?

Direkt in der Regel nicht, wenn pds lokal oder in einer eigenen Cloud-Umgebung betrieben wird. Kritisch wird es, wenn WordPress-Formulare Daten direkt an pds oder eine verknüpfte E-Mail-Adresse übermitteln und diese Schnittstellen kompromittiert wurden. Prüfen Sie im Rahmen des Incident Response WordPress Angriff ausdrücklich alle Schnittstellen und API-Verbindungen, die von der Website ausgehen.

Wie verhindere ich, dass Aushilfen oder ehemalige Mitarbeiter noch WordPress-Zugang haben?

Indem Sie Nutzerkonten in WordPress aktiv verwalten – mindestens einmal pro Quartal prüfen, wer noch aktiven Zugang hat. Für Handwerksbetriebe mit saisonal wechselnden Aushilfen ist das besonders relevant: Ein nicht gelöschtes Editor-Konto mit schwachem Passwort ist einer der häufigsten Einstiegswege bei automatisierten Angriffen. Richten Sie außerdem für jeden Nutzer ein individuelles Konto ein – keine geteilten Zugangsdaten.

Was kostet professionelle Hilfe bei einem WordPress-Sicherheitsvorfall?

Das hängt stark vom Ausmaß des Schadens ab. Eine einfache Bereinigung mit anschließender Härtung liegt bei spezialisierten Dienstleistern typischerweise zwischen 500 und 2.000 Euro – je nachdem, ob ein Neuaufsetzen nötig ist und wie komplex die Installation ist. Zum Vergleich: Zwei Tage Ausfallzeit, eine DSGVO-Meldung und anwaltliche Beratung können schnell mehr kosten. Die TTG GmbH bietet eine erste Einschätzung im Rahmen eines unverbindlichen Gesprächs an.

Lesetipps – weitere Ratgeber der TTG GmbH

Über den Autor
Martin Trappe ist Geschäftsführer der TTG Daten- und Bürosysteme GmbH in Dingelstädt. Mit über 25 Jahren Erfahrung im IT-Mittelstand betreut er kleine und mittelständische Unternehmen in Nordthüringen, Eichsfeld und Südniedersachsen. Die TTG GmbH ist ISO/IEC 27001 zertifiziert – dem höchsten Standard für Informationssicherheit.

Kontakt aufnehmen · Über TTG GmbH

Wissen Sie gerade, wer in Ihrem Betrieb im Ernstfall die Zugangsdaten für Hosting-Panel und Datenbank kennt – und ob Ihr letztes Backup wirklich wiederherstellbar ist?

Ihre IT-Sicherheit jetzt stärken

Schützen Sie Ihr Unternehmen vor Cyberangriffen und Datenverlust. Die TTG GmbH berät KMU in Nordthüringen und Eichsfeld – ISO/IEC 27001 zertifiziert, persönlich vor Ort.