Joomla-Hack: Beweise sichern, bereinigen, melden – was wir aus unseren Bereinigungen gelernt haben

Seit dem 21. Oktober 2026 haben wir eine zweistellige Zahl von Joomla-Websites auf einen Hack untersucht. Fast alle waren kompromittiert. Jede Seite haben wir in einer abgeschotteten Kopie ohne Internetzugang nachgebaut, mit den Originalpaketen verglichen und, wo es sie gab, die Zugriffsprotokolle des Servers ausgewertet. Hier steht, was wir gefunden haben und in welcher Reihenfolge Betreiber nach einem Hack vorgehen sollten: abschalten, Beweise sichern, Ursache finden, bereinigen, melden. Namen von Kunden nennen wir nicht.

Was wir auf den gehackten Seiten gefunden haben

Die Angreifer sind schnell und arbeiten automatisiert

Am Morgen des 21. Oktober traf es mehrere Seiten innerhalb einer Stunde, einige davon in derselben Viertelstunde. Zwischen dem ersten Angriffsaufruf und der ersten Antwort der abgelegten Hintertür lagen nur Sekunden – Stunden bevor das Update des Herstellers am Nachmittag erschien. Danach wurde der Zugang offenbar geteilt oder verkauft: Auf einer Seite nutzten innerhalb weniger Tage über zwanzig verschiedene Adressen dieselbe Hintertür, auf einer anderen fragten Scanner noch eine Woche später gezielt nach ihr.

Nach dem Update nach Hintertüren suchen

Ein Update schließt die Lücke, aber keine Hintertür, die vorher schon abgelegt wurde. Wurde eine Lücke ausgenutzt, bevor das Update erschien, gehört deshalb zu jedem Sicherheitsupdate eine Prüfung: Welche Dateien sind seit dem Tag der Lücke neu oder geändert? Liegt PHP in Bilder-, Medien-, Cache- oder Temp-Ordnern? Gibt es neue Benutzer oder neue Profile von Erweiterungen? Spuren stecken nicht immer in Dateien. Bei einer Lücke in einem Editor waren es fremde Profile in der Datenbank, die das Hochladen von Programmdateien erlaubten – das Update des Editors entfernt solche Profile nicht. In unserer Wartung gehört diese Suche zu jedem Sicherheitsupdate für eine Lücke, die bereits angegriffen wurde.

Was Angreifer hinterlassen

• Hintertüren, die wie Bilder aussehen, in images oder media, teils mit Namen wie Joomla-Dateien und mit zurückgesetztem Datum.
• Eigene .htaccess-Dateien, die eine vorhandene PHP-Sperre für einzelne Ordner wieder aufheben.
• Spam nur für Suchmaschinen: Bots bekommen Glücksspiel-Seiten, Besucher die echte Seite. Auf einer Seite holten Suchmaschinen so in einer Woche Zehntausende Spam-Seiten ab. Auf einer anderen legten die Angreifer die Bestätigungsdatei der Google Search Console ab und konnten die Domain damit in ihrem eigenen Google-Konto verwalten.
• Schad-JavaScript im Template, das Besucher auf fremde Seiten leitet – auch im Template des Administrators.
• Einen Hintergrundprozess, der gelöschte Hintertüren jede Sekunde wiederherstellte.
• Kaputte Seiten: Auf einer Seite leerte ein fehlgeschlagener Versuch Dutzende Dateien auf einmal, seitdem zeigte sie nur noch den Fehler 500. Oft ist so ein Fehler das erste, was der Betreiber bemerkt.

Was erreichbar war

Wer auf dem Server PHP ausführen kann, liest die configuration.php und damit die ganze Datenbank. Auf mehreren Seiten lagen dort jeweils Hunderte bis fast zweitausend Formulareinsendungen mit Namen, E-Mail-Adressen und teils Telefonnummern, auf einer weiteren die Konten aller Mitglieder. Mehrfach stand das Passwort eines Postfachs in der Konfiguration, auf mehr als der Hälfte der Seiten lagen ganze Sicherungen mit Datenbank im Webspace. Weil alle Websites eines Hosting-Pakets unter demselben Benutzer laufen, waren oft auch andere Websites und alte Ordner im selben Paket erreichbar; in einem Fall legten die Angreifer auch dort Dateien ab.

Die ersten Stunden: in dieser Reihenfolge

1. Abschalten, nicht löschen. Nehmen Sie die Seite beim Hoster vom Netz: Ordner umbenennen, Zugriff sperren oder eine Wartungsseite mit Status 503 zeigen. Joomlas Offline-Modus genügt nicht, denn Hintertüren sind eigene Dateien und laufen an Joomla vorbei. Löschen Sie noch nichts, jede Datei ist ein Beweisstück.
2. Beweise sichern. Eine vollständige Sicherung des jetzigen Zustands mit Dateien und Datenbank, dazu die Zugriffs-, FTP- und Fehlerprotokolle des Servers. Notieren Sie Prüfsummen und Uhrzeit. Viele Hoster bewahren Protokolle nur Tage oder wenige Wochen auf; in einigen unserer Fälle fehlten genau die Tage des Einbruchs.
3. Den Zeitpunkt der Kenntnis festhalten. Ab dann laufen die 72 Stunden für eine mögliche Meldung. Schreiben Sie auf, wer wann was bemerkt hat, etwa durch die Warnmail des Hosters oder eines Überwachungsdienstes.
4. Zugänge außerhalb der Website sofort ändern: Kundenkonto beim Hoster, FTP, SFTP und SSH, dazu das Postfach, dessen Passwort in der Konfiguration stand. Datenbank-Passwort und Joomlas Secret ändern Sie bei der Bereinigung – solange eine Hintertür aktiv ist, lesen die Angreifer neue Werte in der configuration.php sofort mit.
5. Den Hoster einbeziehen. Fragen Sie nach den Protokollen, nach gesperrten Dateien und danach, ob auf dem Webspace Prozesse laufen. Die Virenscanner der Hoster haben in unseren Fällen gesperrt, was sie kannten; auf einer Seite übersahen sie einzelne Hintertüren.

Forensik: Was passiert ist, steht in den Protokollen

Wir untersuchen nie auf dem Live-Server, sondern in einer Kopie ohne Internetzugang. So ruft kein Schadcode nach außen, und es geht keine Mail an Kunden der Seite. Geprüft wird:

• Der Joomla-Kern gegen das Originalpaket derselben Version: jede geänderte, fehlende oder fremde Datei. Wo Kerndateien verändert waren, war es jeweils genau eine, die bei jedem Aufruf als Erstes geladen wird.
• Die Erweiterungen gegen ihre Originalpakete, soweit es sie gibt.
• Alle Dateien nach Mustern, auch Bilder: Programmcode in Bilddateien, PHP in Upload-, Cache- und Temp-Ordnern, fremde .htaccess, php.ini und .user.ini.
• Die Datenbank: alle Textspalten nach Skripten, iFrames und fremden Links, dazu Benutzer, Zwei-Faktor-Anmeldung, API-Tokens, geplante Aufgaben und die Profile von Erweiterungen.
• Die Zeitleiste aus den Zugriffsprotokollen. Datei-Zeitstempel lassen sich fälschen, und mehrere Angreifer haben das getan. Belastbar sind die Protokolle des Servers: welcher Aufruf, welche Antwort, wie groß.
• Der ganze Webspace, nicht nur der Joomla-Ordner.

Joomlas Aktionsprotokoll hilft dabei selten. In Sicherungen fehlt es oft, weil Backup-Erweiterungen den Log-Ordner auslassen, und mehrfach hatten die Angreifer die Einträge gelöscht. Die Größe der Antworten in den Zugriffsprotokollen hilft dagegen beim Eingrenzen: Auf einer Seite erhielten alle Anfragen der Angreifer zusammen nur wenige hundert Kilobyte. Ein Abzug der Datenbank über die Website war damit ausgeschlossen, andere Wege nicht. Meist bleibt es bei „erreichbar, Abfluss weder belegt noch ausgeschlossen“ – und genau das muss in die Meldung.

Bereinigen: neu aufsetzen statt flicken

• Ein sauberer Ausgangsstand. Am sichersten ist eine Sicherung von vor dem Einbruch, aber prüfen Sie auch sie. Gibt es keine, entfernen Sie die Funde einzeln, spielen alle Joomla-Kerndateien aus dem Originalpaket neu ein und ersetzen die Erweiterungen durch frische Pakete.
• Erst aktualisieren, dann online. Joomla und alle Erweiterungen auf den neuesten Stand, bevor die Seite wieder erreichbar ist. Was niemand nutzt, kommt weg: alte Erweiterungen, Testordner, frühere Installationen, info.php, configuration.bak.php.
• Alle Zugangsdaten neu: Datenbank-Passwort, Joomlas Secret (meldet alle ab und macht API-Tokens ungültig), die Passwörter aller Konten mit Wechsel bei der nächsten Anmeldung, Zwei-Faktor-Anmeldung für Administratoren, die Schlüssel des Cloud-Speichers für Sicherungen (im Google- oder Dropbox-Konto widerrufen und neu verbinden) und die Verbindungen von Wartungsdiensten.
• Sicherungen vom Server. Alte Komplettsicherungen gehören nicht auf den Webspace.
• Härten. PHP in images, media, tmp und cache per .htaccess sperren. Auf einer Seite wies diese Sperre Dutzende abgelegte Hintertüren ab. Spam-Adressen, die Google schon kennt, antworten mit dem Status 410, damit sie aus dem Index fallen.
• Nach dem Einspielen prüfen: Bekommt Googlebot dieselbe Seite wie Besucher? In der Search Console fremde Inhaber entfernen, den Bericht „Sicherheitsprobleme“ ansehen und nach der Bereinigung eine Überprüfung beantragen.

Eine Seite auf Joomla 3 oder einem PHP ohne Sicherheitsupdates bleibt nach einem Hack offline, bis die migrierte Fassung fertig ist. Bereinigen lässt sie sich, aber die Lücken, die Angreifer gefunden haben, schließt niemand mehr. Welche Versionen noch Updates bekommen, steht in Joomla-Versionen und ihr Supportende.

Melden: wer, wem, bis wann

In allen Fällen waren personenbezogene Daten für die Angreifer lesbar. Ob sie wirklich abgeflossen sind, ließ sich meist weder belegen noch ausschließen. Für die DSGVO ist das unerheblich: Eine Datenpanne ist schon der unbefugte Zugang zu den Daten, nicht erst ihr nachgewiesener Abfluss.

• Datenschutz-Aufsichtsbehörde
  Der Betreiber der Website (Firma, Verein, Schule) meldet die Panne als Verantwortlicher, außer sie führt voraussichtlich zu keinem Risiko für die Betroffenen. Frist: unverzüglich, möglichst binnen 72 Stunden ab Kenntnis; fehlende Angaben dürfen nachgereicht werden (Art. 33 DSGVO).
• Betroffene
  Der Betreiber benachrichtigt sie unverzüglich, wenn ein hohes Risiko besteht, etwa bei Passwörtern, Bank- oder Gesundheitsdaten (Art. 34 DSGVO).
• Eigene Akte
  Jede Panne wird dokumentiert, auch wenn keine Meldung nötig ist (Art. 33 Abs. 5 DSGVO).
• Betreiber
  Agentur, Hoster und Wartungsdienst informieren ihn als Auftragsverarbeiter unverzüglich, sobald sie den Hack bemerken (Art. 33 Abs. 2 DSGVO).
• Polizei
  Unternehmen, Verbände und Bildungseinrichtungen zeigen den Angriff bei der Zentralen Ansprechstelle Cybercrime ihres Landes an, Privatleute bei der Onlinewache – früh und mit den gesicherten Protokollen.
• Google
  Im Bericht „Sicherheitsprobleme“ der Search Console nach der Bereinigung eine Überprüfung beantragen.

Warten Sie mit der Meldung nicht auf die fertige Analyse; die DSGVO erlaubt ausdrücklich, Angaben schrittweise nachzureichen. Wer Kartendaten gespeichert hat, informiert außerdem seinen Zahlungsdienstleister. Das ist keine Rechtsberatung: Ob gemeldet wird, entscheidet der Betreiber, am besten mit seinem Datenschutzbeauftragten. Unsere Befundberichte enthalten die Angaben, die eine Meldung braucht – was erreichbar war, seit wann, welche Daten und was getan wurde.

Vorbeugen: was in diesen Fällen geholfen hätte

1. Sicherheitsupdates am Tag ihres Erscheinens und danach die Suche nach Hintertüren, wenn die Lücke schon angegriffen wurde. Fast alle Einbrüche liefen über bekannte Lücken in Erweiterungen. Welche Lücken gerade ausgenutzt werden, führen wir in der Liste Sicherheitslücken in Joomla-Erweiterungen 2026.
2. Was nicht da ist, kann nicht angegriffen werden: ungenutzte Erweiterungen, alte Installationen und Testordner im selben Paket, info.php, configuration.bak.php.
3. Keine Sicherungen auf dem Webspace. Sicherungen gehören außer Haus, verschlüsselt, mit eigenem Speicherort und eigenem Schlüssel je Website. Werkzeuge dafür im Test: Backup-Erweiterungen für Joomla 6.
4. PHP dort sperren, wo nur Dateien liegen: images, media, tmp, cache.
5. Protokolle einschalten und wegsichern. Zugriffsprotokolle beim Hoster aktivieren und regelmäßig außerhalb des Servers ablegen.
6. Weniger speichern. Formulareinsendungen, die ohnehin per Mail ankommen, nach einigen Tagen löschen. Eine Seite hatte Kontaktanfragen aus vielen Jahren in der Datenbank.
7. Zwei-Faktor-Anmeldung und weniger Konten. Keiner der Einbrüche lief über das Backend, aber die Angreifer konnten Passwort-Hashes und Joomlas Secret lesen. Auf mehr als der Hälfte der Seiten hatte kein Administrator eine Zwei-Faktor-Anmeldung. Nicht genutzte Konten und API-Tokens abschalten.
8. Überwachen. Kerndateien und neue Dateien regelmäßig prüfen lassen und die Google Search Console verbinden. Mehrere dieser Hacks fielen zuerst einem Wartungsdienst oder dem Hoster auf. Was die Dienste prüfen: Joomla-Wartungsdienste im Vergleich.
9. Einen Notfallplan haben: Wer entscheidet über das Abschalten, wer hat Zugang zum Hoster, wo liegen Protokolle und Sicherungen, wer ist Datenschutzbeauftragter?

So sind wir vorgegangen

Grundlage ist eine zweistellige Zahl von Untersuchungen vom 21. Oktober bis 9. November 2026, Joomla 3.10 bis 6.2, bei mehreren Hostern. Jede Untersuchung begann mit einer Sicherung des befallenen Stands, die wir in Docker ohne Internetzugang wiederhergestellt haben. Darauf folgten der Vergleich mit den Originalpaketen von Joomla und den Erweiterungen, eine Musterprüfung aller Dateien und aller Textspalten der Datenbank und, wo es sie gab, die Auswertung der Zugriffsprotokolle. Kundennamen, Dateinamen und Adressen der Angreifer nennen wir bewusst nicht.

Quellen: Art. 33 DSGVO · Art. 34 DSGVO · Zentrale Ansprechstellen Cybercrime (Polizei) · Google Search Console: Bericht „Sicherheitsprobleme“