WordPress gehackt: Shell-Angriff trotz Firewall, Updates und Schutzmaßnahmen

WordPress gehackt trotz Firewall und Updates: Was wir bei einem Shell-Angriff erlebt haben

Aus der Praxis: Dieser Beitrag basiert auf einem realen Sicherheitsvorfall bei mehreren von dailyseven betreuten WordPress-Websites.

Mitte Juli wurden mehrere von uns betreute WordPress-Websites angegriffen – obwohl Updates eingespielt waren und Sicherheitsmaßnahmen wie Firewalls aktiv waren. Was zunächst wie ein klassischer WordPress-Hack aussah, ging deutlich weiter: fremde Administratoren, Shell-Zugriffe, manipulierte Dateien und sogar Eingriffe in die Google Search Console. Für uns war das eine wichtige Erinnerung daran, dass WordPress-Sicherheit und Website-Betreuung heute weit über regelmäßige Updates hinausgehen.

Der Moment, in dem klar wurde: Das ist kein normaler WordPress-Hack

Mitte Juli hatten wir plötzlich mehrere WordPress-Websites auf dem Tisch, bei denen etwas nicht stimmte.

Es waren keine uralten Installationen, bei denen seit Jahren niemand mehr ein Update durchgeführt hatte. Die Systeme wurden betreut, Updates waren vorhanden und Sicherheitsmechanismen liefen.

Trotzdem zeigten sich bei mehreren Kunden ähnliche Auffälligkeiten.

• Unbekannte Dateien tauchten innerhalb der Website auf.
• Neue Administrator-Benutzer waren angelegt worden.
• Es gab Hinweise auf Shell- beziehungsweise Backdoor-Zugriffe.
• Änderungen ließen sich nicht allein durch einen normalen WordPress-Login erklären.
• Bei einzelnen Projekten mussten wir zusätzlich die Google Search Console und die Google-Sichtbarkeit überprüfen.

Spätestens an diesem Punkt war klar: Einfach eine verdächtige Datei löschen, Passwörter ändern und weitermachen wäre zu wenig gewesen.

Wenn ein Angreifer einmal die Möglichkeit besitzt, Dateien auf dem Server anzulegen oder auszuführen, muss man davon ausgehen, dass sich weitere Hintertüren im System befinden können.

Genau das macht einen solchen WordPress Hackerangriff so unangenehm.

WordPress gehackt trotz Firewall und Updates – wie kann das passieren?

Eine der ersten Fragen unserer Kunden war verständlicherweise:

„Wie kann unsere WordPress-Website gehackt werden, wenn doch alles aktuell ist und eine Firewall läuft?“

Die Antwort ist unangenehm, aber wichtig: Updates und Firewall reduzieren das Risiko erheblich. Sie können es aber nicht vollständig beseitigen.

Eine WordPress-Website besteht heute nicht nur aus WordPress selbst.

Dazu gehören unter anderem:

• WordPress Core
• Plugins
• Themes
• Hosting und Webserver
• PHP und Datenbank
• FTP- oder SFTP-Zugänge
• Hosting-Control-Panel
• E-Mail-Konten
• Administrator-Zugänge
• externe Dienste und APIs

Eine Firewall innerhalb von WordPress sieht deshalb nicht zwangsläufig jeden möglichen Zugriffsweg.

Wird beispielsweise ein Hosting-Zugang kompromittiert, eine Schwachstelle außerhalb der eigentlichen WordPress-Installation ausgenutzt oder ein anderer Dienst auf dem Server übernommen, kann der Angriff an der WordPress-Firewall vorbeilaufen.

Auch eine bisher unbekannte Sicherheitslücke kann ein Zeitfenster schaffen, in dem eine eigentlich gepflegte Website angreifbar ist.

Deshalb ist die Aussage

„WordPress ist aktuell, also kann nichts passieren“

leider falsch.

Sicherheit funktioniert nur in mehreren Ebenen.

Was ein Webshell- oder Shell-Angriff bedeutet

Der Begriff „Shell“ klingt zunächst sehr technisch.

Vereinfacht gesagt geht es darum, dass ein Angreifer auf dem Server eine Möglichkeit schafft, weitere Befehle auszuführen.

Eine solche Webshell kann beispielsweise als unscheinbare PHP-Datei abgelegt werden. Von außen lässt sie sich anschließend ansprechen und als Hintertür verwenden.

Damit bekommt ein Angreifer – abhängig von den Rechten des betroffenen Serverprozesses – erheblich mehr Möglichkeiten als mit einem normalen WordPress-Benutzerkonto.

Er kann beispielsweise:

• Dateien verändern oder neu anlegen,
• Schadcode nachladen,
• weitere Backdoors hinterlegen,
• WordPress-Dateien manipulieren,
• neue Benutzer anlegen,
• Weiterleitungen oder Spam integrieren
• und eine bereits bereinigte Website erneut infizieren.

Genau der letzte Punkt ist entscheidend.

Wenn eine WordPress-Website nach einer Bereinigung kurze Zeit später wieder kompromittiert ist, liegt häufig irgendwo noch ein persistenter Zugang.

Dann ist die sichtbare Malware nur das Symptom.

Die eigentliche Ursache liegt tiefer.

Als plötzlich auch die Google Search Console betroffen war

Bei diesem Angriff gab es einen Punkt, der selbst für uns ungewöhnlich war.

Auf dem Server fanden wir eine zusätzliche Datei zur Google-Site-Verifizierung.

Solche Dateien sind grundsätzlich nichts Verdächtiges. Google bietet den Upload einer speziellen HTML-Datei ganz offiziell als Möglichkeit an, die Inhaberschaft einer Website für die Google Search Console zu bestätigen.

Problematisch wird es, wenn diese Datei nicht vom eigentlichen Website-Betreiber stammt.

Wer Schreibzugriff auf das Stammverzeichnis einer Website besitzt, kann dort eine solche Bestätigungsdatei hinterlegen und damit versuchen, sich gegenüber Google als Inhaber einer URL-Präfix-Property zu verifizieren.

Bei den betroffenen Projekten mussten wir deshalb nicht nur WordPress kontrollieren, sondern auch:

• die Inhaber und Benutzer der Google Search Console,
• hinterlegte Verifizierungsmethoden,
• unbekannte Google-Bestätigungsdateien,
• mögliche ungenutzte Eigentümer-Tokens,
• Entfernungsanträge,
• Indexierungszustände,
• Sitemaps
• und technische SEO-Einstellungen.

Das war für mich einer der interessantesten Aspekte dieses Angriffs.

Der Angriff endete nicht bei WordPress.

Er zielte auf die gesamte digitale Kontrolle über die Website.

Warum ein WordPress-Hack auch zum SEO-Problem werden kann

Viele denken bei einem gehackten WordPress zuerst an eine kaputte Website oder an Malware-Warnungen.

Für Unternehmen kann der Schaden aber noch an einer anderen Stelle entstehen:

bei Google.

Ein Angreifer mit ausreichend Zugriff kann beispielsweise technische Einstellungen der Website verändern, Spam-Seiten anlegen oder den Googlebot mit anderen Inhalten versorgen als normale Besucher.

Auch Änderungen an folgenden Bereichen können SEO-Folgen haben:

• robots.txt
• Meta-Robots-Angaben wie „noindex“
• Sitemaps
• Canonical-Tags
• Weiterleitungen
• interne Links
• Seitentitel und Inhalte
• Google Search Console

Wichtig ist dabei eine Unterscheidung:

Eine Property aus der eigenen Search Console zu entfernen bedeutet nicht automatisch, dass eine Website aus Google verschwindet.

In der Search Console existieren aber separate Funktionen, mit denen verifizierte Inhaber URLs vorübergehend aus den Suchergebnissen entfernen lassen können.

Außerdem kann ein Angreifer mit Serverzugriff direkt auf der Website Änderungen vornehmen, die Crawling oder Indexierung beeinflussen.

Nach einem WordPress-Hack reicht es deshalb nicht, nur zu prüfen, ob die Startseite wieder funktioniert.

Bei Websites, die über Google Kunden gewinnen, gehört immer auch eine SEO-Kontrolle dazu.

Bei größeren oder unklaren Fällen verbinden wir diese Prüfung deshalb mit einer technischen
SEO-Analyse der Website.

Wie wir die betroffenen Websites untersucht und bereinigt haben

Bei einem solchen Angriff ist die Versuchung groß, schnell die sichtbare Malware zu löschen und die Website wieder online zu stellen.

Genau das kann aber dazu führen, dass die eigentliche Hintertür bestehen bleibt.

Wir sind deshalb systematisch vorgegangen.

Zunächst musste geklärt werden, welche Dateien verändert wurden und welche Zugänge möglicherweise kompromittiert waren.

Danach wurden unter anderem folgende Bereiche überprüft:

• WordPress Core-Dateien
• Plugins und Themes
• wp-config.php
• .htaccess
• Upload-Verzeichnisse
• Must-Use-Plugins
• unbekannte PHP-Dateien
• WordPress-Benutzer und Administratoren
• Datenbank-Inhalte
• Cronjobs und geplante Aufgaben
• Hosting- und Serverzugänge
• Google-Verifizierungsdateien
• Search-Console-Berechtigungen

Wo es möglich und sinnvoll war, wurden originale WordPress-, Theme- und Plugin-Dateien nicht nur „bereinigt“, sondern durch vertrauenswürdige Originalversionen ersetzt.

Das ist ein wichtiger Unterschied.

Bei einer kompromittierten Installation kann man nicht davon ausgehen, dass nur die offensichtlich verdächtige Datei verändert wurde.

Außerdem wurden Passwörter und Zugangsdaten erneuert.

Nicht nur für WordPress.

Auch Hosting, Datenbank, FTP beziehungsweise SFTP und andere relevante Zugangspunkte müssen nach einem ernsthaften Sicherheitsvorfall berücksichtigt werden.

WordPress gehackt – was jetzt unbedingt geprüft werden sollte

Wer gerade über Google nach „WordPress gehackt – was tun?“ sucht, sollte nicht planlos einzelne Dateien löschen.

Die folgende Reihenfolge ist in der Praxis deutlich sinnvoller.

1. Zustand sichern

Bevor umfangreiche Änderungen vorgenommen werden, sollte eine vollständige Kopie der kompromittierten Website gesichert werden.

Das klingt zunächst widersprüchlich – schließlich ist diese Kopie infiziert.

Für eine spätere Analyse kann sie aber entscheidend sein.

2. Website und Zugänge absichern

Je nach Situation sollte die Website vorübergehend geschützt oder vom normalen Betrieb getrennt werden.

Danach gehören alle relevanten Zugänge auf den Prüfstand:

• WordPress-Administratoren
• Hosting
• SFTP / FTP
• Datenbank
• E-Mail-Konten
• Google-Konten

3. Unbekannte Administratoren entfernen

Unter WordPress sollte kontrolliert werden, ob Benutzer mit Administratorrechten existieren, die dort nicht hingehören.

Auch Anwendungspasswörter und andere Authentifizierungsmöglichkeiten sollten überprüft werden.

4. Dateien nicht nur innerhalb von WordPress prüfen

Das ist eine der wichtigsten Erkenntnisse aus solchen Vorfällen.

Liegt die eigentliche Backdoor außerhalb des normalen WordPress-Verzeichnisses, kann eine reine WordPress-Prüfung sauber aussehen, obwohl der Server weiterhin kompromittiert ist.

Bei wiederkehrenden Infektionen muss deshalb gegebenenfalls auf Hosting- oder Serverebene weitergesucht werden.

5. Google Search Console kontrollieren

Unter

Einstellungen → Nutzer und Berechtigungen

sollten unbekannte Benutzer oder Inhaber auffallen.

Besonders wichtig sind unbekannte Verifizierungsmethoden.

Eine fremde Bestätigungsdatei darf nicht einfach nur über die Search Console entfernt werden. Der dazugehörige Verifizierungs-Token muss ebenfalls von der Website entfernt werden, sonst kann die Verifizierung erneut greifen.

6. Google-Indexierung prüfen

Nach der technischen Bereinigung sollte überprüft werden:

• Ist die Website noch indexierbar?
• Gibt es ungewöhnliche URL-Entfernungen?
• Sind unbekannte Seiten im Google-Index aufgetaucht?
• Ist die Sitemap korrekt?
• Wurde die robots.txt verändert?
• Existieren unerwartete noindex-Angaben?

7. Erst nach der Bereinigung alle Zugangsdaten erneut ändern

Wurde ein Passwort bereits zu Beginn des Vorfalls geändert, kann es sinnvoll sein, es nach einer vollständigen Bereinigung erneut zu ändern.

Solange noch ein kompromittierter Prozess oder eine Backdoor aktiv ist, besteht sonst das Risiko, dass neue Zugangsdaten erneut abgegriffen werden.

Warum Firewall, Backups und Updates allein nicht reichen

Nach diesem Vorfall würde ich nicht sagen:

„Firewalls bringen nichts.“

Das wäre falsch.

Genauso falsch wäre aber die Aussage:

„Wir haben eine Firewall, deshalb kann unsere Website nicht gehackt werden.“

Sicherheit funktioniert am besten als Zusammenspiel mehrerer Ebenen.

Dazu gehören für uns heute:

• regelmäßige WordPress-, Plugin- und Theme-Updates,
• starke und einzigartige Passwörter,
• Zwei-Faktor-Authentifizierung für wichtige Zugänge,
• Web Application Firewall,
• Malware- und Dateiüberwachung,
• regelmäßige externe Backups,
• Überwachung von Administrator-Konten,
• saubere Datei- und Benutzerrechte,
• Kontrolle des Hostings und der Serverumgebung,
• und eine Überwachung der Google Search Console.

Vor allem Backups werden häufig falsch verstanden.

Ein Backup verhindert keinen Angriff.

Es gibt Ihnen aber die Möglichkeit, auf einen bekannten, sauberen Zustand zurückzugehen – vorausgesetzt, das Backup stammt tatsächlich aus einer Zeit vor der Kompromittierung und der ursprüngliche Angriffsweg wurde anschließend geschlossen.

Sonst wird auch die wiederhergestellte Website erneut gehackt.

Was wir aus dem WordPress-Hackerangriff mitgenommen haben

Mitte Juli war für uns wieder einer dieser Momente, in denen Theorie und Praxis deutlich auseinandergehen.

Auf dem Papier waren wichtige Sicherheitsmaßnahmen vorhanden.

In der Realität hatten Angreifer trotzdem einen Weg gefunden.

Besonders bemerkenswert war für uns, wie weit der Zugriff ging. Die Manipulation endete nicht bei einer einzelnen WordPress-Datei oder einem fremden Administrator.

Mit der zusätzlichen Google-Verifizierung wurde deutlich, dass moderne Angriffe nicht zwangsläufig nur die Website selbst betreffen.

Hosting, WordPress, Benutzerkonten und Suchmaschinen-Sichtbarkeit hängen heute eng zusammen.

Genau deshalb sehen wir professionelle WordPress-Betreuung inzwischen nicht mehr nur als „Updates installieren“.

Es geht auch darum, ungewöhnliche Veränderungen zu erkennen, Backups zu kontrollieren, Zugänge abzusichern und bei einem Sicherheitsvorfall nicht nur das sichtbare Symptom zu entfernen.

Wenn eine Website einmal kompromittiert wurde, lautet die wichtigste Frage deshalb nicht:

„Wo ist die Malware-Datei?“

Sondern:

„Wie kam der Angreifer hinein – und besitzt er noch irgendwo einen Zugang?“

Erst wenn diese Frage beantwortet ist, ist eine gehackte WordPress-Website wirklich bereinigt.