Wie eine deutsche Unternehmens-Website gehackt wurde

Fallstudie: Wie eine deutsche Unternehmens-Website gehackt wurde

Einleitung

Cyberangriffe auf mittelständische deutsche Unternehmen passieren häufiger, als viele denken. Meist trifft es Firmen, die ihre Website zwar nutzen, aber selten aktiv pflegen. Genau so ein Fall landete bei mir: eine kompromittierte Unternehmensseite, versteckte Malware, ein angeschlagener Cloud-Server und ein Inhaber, der erst durch Google-Warnungen bemerkte, dass etwas nicht stimmte.
Im Folgenden präsentiere ich den gesamten Fall: Was genau passiert ist, wie der Angriff funktionierte, wie die kompromittierten Bereiche systematisch bereinigt wurden – und wie der Server am Ende so gehärtet wurde, dass der Kunde heute deutlich besser geschützt dasteht als zuvor.

 

Ausgangslage: Ein erfolgreicher Mittelständler – und ein vernachlässigter Server

Das Unternehmen betreibt seit Jahren eine dreisprachige WordPress-Website, hostet sie auf einem kleinen Cloud-Server (Ubuntu LTS) und betreibt dort auch ein internes Tool für die Mitarbeiter. Alles funktionierte jahrelang problemlos.
Wie so oft bestand das Problem nicht in Technikversagen, sondern im Nicht-Updaten:

— WordPress-Version nicht aktualisiert
— 2 Plugins mit Sicherheitslücken
— Theme seit 2021 ohne Patch
— PHP veraltet 7.4
— Admin-Login ohne 2FA und Login-Page publikum
— SFTP deaktiviert, stattdessen altes FTP offen
— Fail2ban nicht installiert
— Keine Malware-Scanner server-side
— Keine authentifizierten Cronjobs
— Cloud-Firewall nicht optimiert

Der Kunde bemerkte, dass die Seite Weiterleitungen auf dubiose Gewinnspiele und Glücksspielseiten enthielt. Kurz darauf stufte Google die Seite als „potenziell gefährlich“ ein. Der Traffic brach ein.

 

Die ersten Anzeichen des Hacks

Beim ersten Check waren die Symptome eindeutig:

— Zufällige Weiterleitungen nur auf mobilen Geräten
— Injected JavaScript am Ende von HTML-Ausgaben
— Unbekannte Dateien im Uploads-Verzeichnis
— Base64-verschlüsselte PHP-Dateien in den Plugin-Ordnern
— Zusätzliche Cronjobs
— „WP-Admin“ funktionierte, doch dort wurden verschleierte Nutzerkonten angelegt
— Undichte htaccess-Regeln, die nur bestimmte User-Agents betrafen

Das war kein simpler automatisierter Hack. Die Angreifer hatten sich:

— Zugriff verschafft
— Persistenz geschaffen
— Mehrere Backdoors platziert
— Unsichtbare Weiterleitungen nur für Googlebot-ähnliche User-Agents eingebaut
— Einen Remote-Command-Loader eingebunden

Die Kombination deutete auf eine typische SEO-Spam-Injection-Attacke hin, die oft über Plugin-Lücken oder gestohlene FTP-Zugangsdaten erfolgt.

 

Forensik: Woher kam der Angriff?

Bevor irgendetwas gelöscht wird, muss man die Quelle finden. Sonst kehrt der Hacker zurück.

 

Log-Analyse auf dem Cloud-Server

Die Apache- und Nginx-Logs zeigten verdächtige Requests:

— POST-Requests auf admin-ajax.php von russischen Proxy-Servern
— Zugriffe auf eine längst gelöschte Plugin-Datei
— Wiederholte XML-RPC-Anfragen
— Ein Login-Brute-Force-Angriff – aber mit Erfolg (schwaches Passwort)

Der Initialzugriff kam wahrscheinlich über ein Plugin (Revolution Slider – klassischer Einfallspunkt), bestätigt durch:

/wp-content/plugins/revslider/temp/update_extract/

Dort lag eine Datei, die der Kunde selbst nie kannte.

 

Manipulierte Dateien

Ich fand über 160 manipulierte Dateien, u.a.:

— functions.php des Themes
— wp-settings.php
— In Plugins mind. 1 versteckte Datei mit obfuskiertem Code
— Reihe von Dateien im Uploads-Verzeichnis, getarnt mit normalen Bildnamen (z. B. img_00923.php.jpg)

Das Ziel war klar: dauerhafte Kontrolle und Nutzung der Website für Weiterleitungs-Spam.

 

Sofortmaßnahmen: Eindämmen, bevor man säubert

Noch bevor die eigentliche Bereinigung beginnt, müssen zwei Dinge passieren:

 

1. Server dicht machen

— FTP sofort deaktiviert
— SSH-Port isoliert und Rate-Limits gesetzt
— Fail2ban richtig konfiguriert
— Cloud-Firewall auf „Default-Deny“ gestellt
— root-Login blockiert
— Neue SSH-Keys gesetzt
— Vorgeschaltete WAF aktiviert

2. Website offline nehmen

Das ersparte weiteren Schaden und verhindert, dass der Angreifer live weiterarbeiten konnte.

Gründliche Bereinigung

Hier beginnt die eigentliche Arbeit: Nicht blind Dateien löschen, sondern strukturiert alles aufrollen.

WordPress-Core ersetzt

Ich lade grundsätzlich eine frische WordPress-Version herunter, vergleiche via diff und ersetze alle kompromittierten Dateien. Denn sobald systemkritische Dateien manipuliert wurden, ist ein Austausch sicherer als jede manuelle Reparatur.

Theme komplett neu installiert

Da das Theme nicht mehr supported wurde, war der Code potenziell verwundbar. Ich exportierte Child-Theme-Anpassungen, löschte alles und spielte eine saubere Version ein.

Plugins radikal neu aufgesetzt

Alle Plugins wurden:

— vollständig gelöscht
— frisch aus dem offiziellen Repository geladen
— aktualisiert
— auf Sicherheitslücken geprüft
— Veraltete oder dubiose Plugins flogen komplett raus.

Die Uploads-Bibliothek bereinigt

Das ist der schlimmste Ort, weil Angreifer dort Backdoors gut tarnen.

Ich scannte jedes File:

— alles, was mit .php endet → sofort gelöscht
— Dateien > 1 MB mit komischem Hash → entfernt
— Doppelte Dateiendungen („.jpg.php“) → gelöscht

Datenbank bereinigt

SQL-Injection-Spuren waren vorhanden:

— 7 manipulierte wp_options-Einträge
— 3 gefälschte Admin-Konten
— Cronjobs mit eval-Code

Maßnamen:

— Malware-Optionen gelöscht
— Transients gesäubert
— Cron-Jobs resettet
— Tabellen indiziert
— defekte Einträge repariert

Wieder online – aber erst nach Härtung des Servers

Die Website war zu diesem Zeitpunkt wieder sauber, aber das reicht nicht. Ein sauberer WordPress-Ordner auf einem schlecht konfigurierten Server bedeutet nur, dass der Hacker irgendwann zurückkommt.

Deshalb folgte der Teil, der die meisten Dienstleister weglassen: den Server wirklich sicher zu machen.

 

Systematische Server-Härtung

Betriebssystem aktualisiert

Ich spielte alle Updates ein, inklusive Kernel-Patches. Veraltete Pakete wie PHP 7.4 wurden entfernt, stattdessen PHP 8.4 installiert.

SSH komplett abgesichert

— Login nur über SSH-Keys
— Passwort-Login deaktiviert
— root-User gesperrt
— Zugriff nur von definierten IP-Ranges
— Brute-Force-Limits verschärft
— Zeitsperren für Fehlversuche verlängert

Firewall restriktiv konfiguriert

Inbound erlaubt:

— 80
— 443
— 22 (aber nur mittels IP-Allowlist)

Outbound stark begrenzt, damit Malware im Ernstfall nicht „nach Hause telefonieren“ kann.

ModSecurity + OWASP-Ruleset aktiviert

Damit stoppt Exploits wie:

— SQL Injection
— XSS
— Directory Traversal
— RCE-Payloads
— automatisch blockieren.

PHP im Hardened Mode

-- disable_functions erweitert
-- open_basedir konfiguriert
-- allow_url_fopen deaktiviert
— Upload-Beschränkungen gesetzt
— Memory-Limits angepasst
— Mail-Versand auf authentifizierte Kanäle reduziert

Dateirechte neu gesetzt

Ein Klassiker: zu weite Rechte.
Ich habe alles nach dem Prinzip „so wenig wie nötig“ neu gesetzt:

— 640 für sensitive Dateien
— 750 für Verzeichnisse
— wp-config nach oben verschoben
— Ownership per user-separation

Fail2ban endlich richtig eingestellt

Bisher lief Fail2ban, aber blockte kaum. Jetzt:

— 12 Filter
— brute force für ssh, nginx, wp-login
— feste Ban-Times
— automatische Notification

Server-Monitoring aktiviert

Mit Alerting auf:

— unerwartete Dateiänderungen
— CPU-Spikes
— Cron-Manipulation
— ungewöhnlichen Ausgehend-Traffic
— Login-Versuche aus unbekannten Regionen

Zusätzliche WordPress-Security-Maßnahmen

Damit der Kunde auch langfristig Ruhe hat:

— 2FA für alle Admins
— Login-Rate-Limit
— Blockierung von XML-RPC
— REST-API-Härtung
— Script-Integrity-Check
— Malware-Scanner im Cron
— Plugin-Auto-Updates (nur Security-Updates)
— Backup-Rotation mit externem Storage

Der wichtigste Schritt: Die Wiederaufnahme durch Google

Nach der Bereinigung:

— Website in GSC neu gescannt
— „Schädliche Inhalte“ entfernt
— Neue Sitemap eingereicht
— 2-Tage später → Warnung verschwunden
— Rankings erholten sich schrittweise über 3–4 Wochen

 

Was der Angriff letztlich verursacht hat

— 40 % Traffic-Einbruch
— 3 verlorene Keywords auf Seite 1
— Abmahnungen durch Weiterleitungen auf Glücksspielseiten
— Downtime von zwei Tagen
— Mitarbeiter konnten internes Tool nicht nutzen
— Vertrauensverlust bei Kunden

Die gute Nachricht: Nach dem Cleanup und der Härtung läuft der Server heute schneller, stabiler und sicherer als je zuvor.

Lessons Learned – was die Firma heute besser macht

Der Kunde hält sich jetzt an ein paar einfache Regeln:

— Updates nicht ignorieren
— Kein FTP mehr
— Keine Admin-Accounts für Praktikanten
— Backups regelmäßig checken
— Server-Monitoring ernst nehmen
— Sensible Passwörter, nicht „Firma2020!“
— 2FA überall

Und – am wichtigsten – regelmäßige Security-Audits.

Fazit

Dieser Fall zeigt, was bei vielen Unternehmen Realität ist: Man nutzt eine Website als zentrales Marketing-Werkzeug, aber behandelt Security wie eine lästige Nebensache. Bis etwas passiert.
Der Angriff selbst war kein Meisterwerk – er war das Ergebnis monatelanger Sicherheitslücken. Doch die Bereinigung und vor allem die Server-Härtung haben das Unternehmen heute in eine Lage gebracht, in der es Angriffe deutlich besser abwehrt.

Es spricht sich niemand gerne öffentlich aus, wenn die eigene Firmenwebsite gehackt wurde. Aber intern hat dieser Fall die Prioritäten verändert: Sicherheit ist kein Luxus, sondern Grundvoraussetzung. Und wer sie ignoriert, bezahlt irgendwann dafür – mit Traffic, Umsatz oder Reputation.