Ein gehackter Onlineshop ist kein theoretisches Szenario mehr – er trifft Händler aller Größenordnungen, von kleinen WooCommerce-Shops bis hin zu mittelgroßen Shopware-Installationen. Wer die typischen Anzeichen kennt, Webshells gezielt aufspürt und danach alle Zugänge konsequent absichert, kann den Schaden begrenzen und einen erneuten Einbruch verhindern. Dieser Leitfaden zeigt, wie man nach einem Angriff systematisch vorgeht – von der ersten Schadensanalyse über die Bereinigung bis zur dauerhaften Härtung von Plesk, Shop-Admin und 2FA.
Typische Anzeichen: Wurde mein Shop gehackt?
Viele Angriffe bleiben wochenlang unentdeckt, weil der Shop auf den ersten Blick normal funktioniert. Erst wenn Google eine Sicherheitswarnung ausspielt, der Hoster den Account sperrt oder Kunden über Phishing-Mails berichten, wird das Ausmaß sichtbar. Folgende Symptome deuten auf einen Einbruch hin:
- Google Search Console meldet „Diese Website könnte gehackt sein“ oder „Schädliche Inhalte gefunden“
- Der Hoster sperrt FTP, SSH oder das gesamte Konto wegen Spam-Versands
- Unbekannte Dateien tauchen im Webroot oder in Plugin-Verzeichnissen auf
- Neue Admin-Nutzer erscheinen ohne eigenes Zutun im Backend
- Der Shop leitet Besucher auf externe Seiten um (Redirect-Hack)
- Pagespeed bricht ein, weil Crypto-Mining-Skripte Serverressourcen verbrauchen
- Kunden melden verdächtige E-Mails mit dem Absender der eigenen Domain
- Access-Logs zeigen massenhaft POST-Anfragen auf unbekannte PHP-Dateien
Tritt auch nur eines dieser Symptome auf, sollte man sofort handeln – und nicht erst auf die nächste Routine-Wartung warten.
Was ist eine Webshell – und warum ist sie so gefährlich?
Eine Webshell ist eine in PHP, Python oder Perl geschriebene Backdoor-Datei, die Angreifern über den Browser vollen Kommandozeilenzugang zum Server verschafft. Sie sieht von außen aus wie eine gewöhnliche PHP-Datei, führt aber beliebige Systembefehle aus. Bekannte Varianten tragen Namen wie c99.php, r57.php, wso.php oder tarnen sich als wp-config.php.bak in Upload-Verzeichnissen.
Das Gefährliche: Webshells überleben in vielen Fällen auch ein vollständiges Shop-Update, weil sie außerhalb der Kern-Dateien abgelegt werden – typischerweise in /wp-content/uploads/, in Plugin-Unterordnern oder sogar als Bild verkleidet (image.php). Wer nur das System aktualisiert, aber nicht nach Backdoors sucht, öffnet Angreifern dauerhaft die Tür.
Webshells finden: Vier bewährte Methoden
1. Nach PHP-Dateien in Upload-Verzeichnissen suchen
Legitime Uploads enthalten keine ausführbaren PHP-Dateien. Wer im Uploads-Verzeichnis auf PHP-Dateien stößt, hat fast sicher eine Backdoor gefunden. Über Plesk File Manager oder per SSH lässt sich das mit einem einfachen Find-Befehl prüfen:
Im Plesk-Terminal unter „Websites & Domains“ gibt es eine SSH-Konsole, über die man nach verdächtigen Dateien suchen kann. Alternativ prüft man das Verzeichnis über den Plesk File Manager direkt im Browser.
2. Kürzlich geänderte Dateien identifizieren
Angreifer hinterlassen Spuren im Dateisystem. Dateien, die kurz vor oder nach einem bekannten Angriffsversuch geändert wurden, sind verdächtig – besonders wenn man selbst keine Änderungen vorgenommen hat. Der Plesk File Manager zeigt Änderungsdaten direkt in der Dateiliste an. Über die Backup-Funktion lässt sich ein Vorher-Nachher-Vergleich ziehen.
3. Verdächtige Code-Muster erkennen
Webshells verwenden fast immer verschlüsselte Zeichenketten, um Erkennung zu umgehen. Typische Muster sind Base64-kodierter Code (erkennbar an langen kryptischen Zeichenfolgen), die Funktionen eval(), base64_decode(), gzinflate() oder str_rot13() in Kombination. Seriöser Shop-Code enthält diese Kombinationen nie.
4. Spezialisierte Malware-Scanner einsetzen
Für WooCommerce-Shops auf Basis von WordPress empfiehlt sich der kostenfreie Wordfence Security Scanner oder das Tool MalCare. Beide erkennen bekannte Webshell-Signaturen zuverlässig. Für Shopware und JTL gibt es dagegen keine allgemein etablierten Scanner – hier ist die manuelle Überprüfung unverzichtbar. Plesk bietet außerdem einen integrierten Imunify360-Scan an, der auf vielen Managed-Hosting-Paketen bereits vorinstalliert ist.
Schritt-für-Schritt-Bereinigung nach dem Hack
Die Bereinigung läuft in einer festen Reihenfolge ab. Wer Schritte überspringt, riskiert, dass Angreifer über eine übersehene Backdoor zurückkehren.
Schritt 1: Shop sofort in den Wartungsmodus
Solange der Shop gehackt ist, gefährdet er Kundendaten. Maintenance-Modus aktivieren und eine saubere Wartungsseite anzeigen – nicht die gehackte Seite, die womöglich noch aktive Malware enthält. In Plesk lässt sich der Shop über „Webseiten-Management“ temporär deaktivieren.
Schritt 2: Alle Passwörter und Tokens sofort sperren
Noch bevor man mit der Bereinigung beginnt: alle Zugangsdaten ändern. Dazu gehören FTP, SSH, Datenbank-Passwörter, Shop-Admin-Login, Hoster-Login (Plesk) und API-Keys für Zahlungsanbieter und Versanddienste. Passwörter, die auf dem infizierten System gespeichert waren, müssen als kompromittiert gelten.
Schritt 3: Sauberes Backup einspielen oder manuell bereinigen
Wer ein datiertes sauberes Backup besitzt, spielt es ein und aktualisiert danach sofort alle Komponenten. Ohne Backup bleibt nur die manuelle Bereinigung: Alle verdächtigen Dateien entfernen, den kompletten Kern des Shopsystems (WordPress, Shopware, JTL) neu aufspielen und jedes Plugin und Theme einzeln prüfen. Datenbank-Einträge, die Schadcode enthalten, müssen ebenfalls bereinigt werden – besonders in den Feldern wp_options (WordPress) oder vergleichbaren Konfigurations-Tabellen.
Schritt 4: Alle Plugins und Themes aktualisieren
Veraltete Plugins sind in über 60 Prozent der WordPress-Hacks der Einfallsweg. Nach der Bereinigung sofort alle Erweiterungen auf die jeweils neueste Version aktualisieren. Plugins, die nicht mehr gepflegt werden (letztes Update älter als 12 Monate), deinstallieren und durch aktiv gewartete Alternativen ersetzen.
Schritt 5: Alle unbekannten Admin-Nutzer löschen
Angreifer legen fast immer mindestens einen versteckten Admin-Nutzer an, um nach der Bereinigung wieder Zugang zu bekommen. Alle Nutzer im Backend prüfen und nicht erkannte Accounts sofort löschen.
Schritt 6: Server-Logs auswerten
Die Apache- oder Nginx-Access-Logs zeigen, welche Dateien wann aufgerufen wurden. Das hilft dabei, den initialen Angriffsvektor zu identifizieren – etwa ein anfälliges Plugin oder eine unsichere Datei-Upload-Funktion. Plesk stellt die Logs unter „Websites & Domains“ > Logs direkt im Interface bereit.
Plesk absichern: Die wichtigsten Einstellungen 2026
Plesk ist als zentrales Hosting-Control-Panel ein bevorzugtes Ziel für Angreifer. Wer Plesk richtig konfiguriert, schließt die häufigsten Einfallstore.
Plesk-Passwort und Zugangs-IP beschränken
Das Plesk-Admin-Passwort sollte mindestens 20 Zeichen lang sein und ausschließlich über eine zufällige Kombination aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen bestehen. Zusätzlich empfiehlt sich eine IP-Whitelist: Unter „Tools & Einstellungen“ > „Sicherheitsrichtlinie“ lässt sich der Zugang auf bestimmte IP-Adressen beschränken.
SSH-Zugang absichern
Root-Login per SSH sollte deaktiviert sein. Stattdessen: SSH nur mit Public-Key-Authentifizierung, kein Passwort-Login. Den SSH-Port von Standard-Port 22 auf einen nicht standardmäßigen Port legen – das reduziert automatisierte Brute-Force-Versuche drastisch. Fail2ban oder die in Plesk integrierte IP-Blocking-Funktion schützen zusätzlich gegen wiederholte fehlgeschlagene Login-Versuche.
ModSecurity Web Application Firewall aktivieren
Plesk unterstützt ModSecurity mit OWASP-Regeln direkt im Panel. Unter „Tools & Einstellungen“ > „Web Application Firewall“ lässt sich ModSecurity mit dem OWASP Core Rule Set aktivieren. Das filtert bekannte Angriffsmuster wie SQL-Injection und Remote-Code-Execution-Versuche, bevor sie den Shop überhaupt erreichen.
Dateiberechtigungen korrekt setzen
PHP-Dateien im Uploads-Verzeichnis sollten nie ausführbar sein. Die korrekte Konfiguration: Verzeichnisse mit 755, Dateien mit 644, wp-config.php mit 600. Plesk bietet unter dem Repair-Bereich die Möglichkeit, Berechtigungen für eine komplette Webseite zurückzusetzen.
Shop-Admin absichern: Best Practices für WooCommerce, Shopware und JTL
Das Backend des Shops ist der zweite kritische Angriffspunkt. Starke Passwörter allein reichen 2026 nicht mehr aus.
Admin-URL umbenennen (WooCommerce/WordPress)
Die Standard-URL /wp-admin/ ist bekannt und wird automatisiert angegriffen. Plugins wie WPS Hide Login ermöglichen es, die Login-URL auf einen individuellen Pfad zu legen, etwa /verwaltung-intern/. Automatisierte Angriffe auf /wp-admin/ laufen damit ins Leere.
Anmeldeversuche begrenzen
Ohne Begrenzung können Angreifer unbegrenzt viele Passwort-Kombinationen ausprobieren. Plugins wie Limit Login Attempts Reloaded oder Wordfence Security blockieren IP-Adressen nach mehreren fehlgeschlagenen Versuchen. Shopware 6 bietet diesen Schutz unter „Administrationsoberfläche“ in den Systemeinstellungen nativ an.
Benutzerrollen strikt vergeben
Nicht jeder Mitarbeiter braucht Administrator-Rechte. WooCommerce unterscheidet zwischen Subscriber, Customer, Shop Manager und Administrator. Wer nur Bestellungen bearbeitet, braucht keine Admin-Rechte und sollte keine haben. Nach dem Hack: alle Rollen überprüfen und auf das Minimum reduzieren.
2FA einrichten: Zweistufige Authentifizierung für Shop und Plesk
Zweistufige Authentifizierung (2FA) ist die wirksamste Einzelmaßnahme gegen kompromittierte Passwörter. Selbst wenn ein Angreifer das Passwort kennt, kommt er ohne den zweiten Faktor nicht ins System.
2FA für WordPress/WooCommerce
Mehrere Plugins ermöglichen 2FA für WordPress. Empfehlenswert sind WP 2FA (offiziell und gepflegt) sowie die in Wordfence Premium enthaltene 2FA-Funktion. Beide unterstützen TOTP-Apps wie Google Authenticator, Authy oder den in iOS und Android integrierten Passwort-Manager. Die Einrichtung dauert unter fünf Minuten und schützt alle Admin-Konten.
2FA für Plesk
Plesk unterstützt 2FA nativ. Unter „Mein Profil“ > „Zweistufige Authentifizierung“ lässt sich ein TOTP-Token mit einer Authenticator-App verbinden. Für den Hoster-Account selbst (bei Strato, IONOS, Hetzner oder Mittwald) bietet ebenfalls jeder seriöse Anbieter 2FA an – unbedingt aktivieren.
Backup-Codes sicher aufbewahren
Bei der 2FA-Einrichtung werden Backup-Codes generiert. Diese offline aufbewahren – nicht im selben E-Mail-Konto, das ebenfalls kompromittiert sein könnte. Ein Passwort-Manager mit lokalem Backup oder ein ausgedrucktes Exemplar an einem sicheren Ort sind sinnvoll.
Meldepflichten nach dem Hack: Was Händler rechtlich beachten müssen
Ein Hackerangriff auf einen Onlineshop ist in vielen Fällen auch ein Datenschutzvorfall nach DSGVO. Wurden Kundendaten abgegriffen – Adressen, E-Mails, Zahlungsdaten – besteht eine Meldepflicht gegenüber der zuständigen Datenschutzbehörde. Die Frist beträgt 72 Stunden nach Bekanntwerden des Vorfalls.
Darüber hinaus müssen in vielen Fällen auch die betroffenen Kunden informiert werden, wenn ein hohes Risiko für ihre persönlichen Daten besteht. Details zu den genauen Anforderungen und Schwellenwerten erklärt unser Artikel zum Thema Datenschutz im Onlineshop 2026. Wer die rechtlichen Grundlagen seines Shops umfassend überprüfen möchte, findet dazu auch unseren vollständigen Leitfaden zu den rechtlichen Anforderungen im Onlineshop.
Präventive Maßnahmen: So bleibt der Shop sicher
Wer nach einem Hack wirklich Konsequenzen zieht, verhindert den nächsten Angriff. Diese Maßnahmen sollten dauerhaft etabliert werden:
Automatische Updates aktivieren
Der häufigste Einfallsweg ist veraltete Software. WordPress bietet automatische Minor-Updates für den Kern sowie optionale Major-Update-Automatisierung. Plugins sollten wöchentlich auf Updates geprüft werden. Wer mit einem Managed-WordPress-Hoster arbeitet, erhält Updates oft automatisch ohne eigenes Zutun.
Regelmäßige Backups mit externer Lagerung
Backups, die auf demselben Server liegen, sind im Ernstfall wertlos – Angreifer löschen sie mit. Externe Backups auf einem separaten Storage-System (Hetzner StorageBox, Amazon S3, Backblaze B2) sind Pflicht. Täglich für Datenbankdumps, wöchentlich für vollständige Datei-Backups ist ein sinnvoller Rhythmus für aktive Shops.
Content Security Policy und Security-Header setzen
HTTP-Security-Header wie X-Frame-Options, X-Content-Type-Options und eine Content-Security-Policy schränken ein, welche Ressourcen der Browser laden darf. Das verhindert Cross-Site-Scripting-Angriffe und Clickjacking. Plesk erlaubt die Konfiguration dieser Header direkt in den Apache- oder Nginx-Einstellungen der jeweiligen Domain. Tools wie PageSpeed Insights zeigen übrigens auch, ob Security-relevante Header korrekt gesetzt sind.
Datei-Uploads auf erlaubte Typen beschränken
PHP-Dateien dürfen über Upload-Formulare nie auf den Server gelangen. WooCommerce erlaubt die Einschränkung auf bestimmte Dateitypen in den Medien-Einstellungen. Zusätzlich empfiehlt sich eine serverseitige Validierung in der .htaccess oder über Nginx-Konfiguration, die PHP-Ausführung im Uploads-Verzeichnis komplett deaktiviert.
Penetrationstest alle 12 Monate
Für Shops, die regelmäßig sensible Kundendaten verarbeiten, empfiehlt sich ein jährlicher Penetrationstest durch einen externen Sicherheitsdienstleister. Das kostet je nach Umfang zwischen 500 und 3.000 Euro – ist aber weitaus günstiger als ein echter Hack mit Reputationsschaden und behördlichen Bußgeldern.
Typische Anzeichen sind: Google-Warnmeldungen in der Search Console, Weiterleitungen auf fremde Seiten, unbekannte Admin-Nutzer im Backend, vom Hoster gesperrte Konten wegen Spam-Versands sowie unbekannte PHP-Dateien im Uploads-Verzeichnis. Auch massenhaft POST-Anfragen auf unbekannte Dateien in den Server-Logs sind ein sicheres Zeichen.
Eine Webshell ist eine Backdoor-Datei (meist PHP), die Angreifern über den Browser vollständigen Kommandozeilenzugang zum Server gibt. Webshells überleben Shop-Updates, weil sie außerhalb der Kern-Dateien abgelegt werden – zum Beispiel im Uploads-Verzeichnis. Sie sind extrem gefährlich, weil Angreifer damit dauerhaft Zugang behalten, auch nachdem das ursprüngliche Einfallstor geschlossen wurde.
Ja, wenn Kundendaten betroffen sind. Nach DSGVO besteht eine Meldepflicht gegenüber der zuständigen Datenschutzbehörde innerhalb von 72 Stunden nach Bekanntwerden des Vorfalls. Bei hohem Risiko für betroffene Personen müssen auch die Kunden selbst informiert werden. Zahlungsdaten-Lecks müssen zusätzlich dem Zahlungsdienstleister (Stripe, PayPal etc.) gemeldet werden.
Zweistufige Authentifizierung (2FA) schützt vor kompromittierten Passwörtern – selbst wenn ein Angreifer das Passwort kennt, kommt er ohne den zweiten Faktor (TOTP-Code aus einer Authenticator-App) nicht ins Backend. 2FA sollte für alle Admin-Konten im Shop sowie für den Plesk/Hoster-Login aktiviert werden. Die Einrichtung dauert unter fünf Minuten und ist die wirksamste Einzelmaßnahme gegen Brute-Force-Angriffe.
Nein. Ein Neuaufsetzen ohne Ursachenanalyse führt fast immer zu einem erneuten Hack. Zuerst muss der initiale Angriffsvektor identifiziert werden – meist ein veraltetes Plugin, eine anfällige Upload-Funktion oder ein schwaches Passwort. Erst wenn dieser Weg geschlossen ist und alle Backdoors entfernt wurden, ist ein Neuaufsetzen nachhaltig sinnvoll.
