Joomla gehackt: System bereinigen, absichern und Meldepflichten einhalten

Woran Sie erkennen, dass Ihr Joomla gehackt wurde

Ein Joomla gilt als kompromittiert, sobald fremder Code im Dateisystem oder in der Datenbank ausgeführt wird, auch wenn die Website nach außen völlig normal aussieht. Genau das ist der Regelfall: Angreifer verdienen an Spam-Links, Weiterleitungen und Zugangsdaten, nicht an Aufmerksamkeit. Ein sichtbares Defacement ist die Ausnahme, kein Indikator.

Die typische Meldekette beginnt außerhalb Ihrer Organisation. Der Hoster sperrt das Postfach, weil aus Ihrem Webspace Mails verschickt wurden. Die Search Console zeigt Hunderte neue indexierte URLs mit Begriffen aus Bereichen, mit denen Ihr Unternehmen nichts zu tun hat. Ein Browser blockiert die Domain. In jedem dieser Fälle liegt der eigentliche Einbruch oft Wochen zurück.

Symptome, die Sie sofort prüfen sollten

• Neue Benutzer in der Gruppe Super Users, die niemand angelegt hat. Prüfen Sie Benutzer nach Registrierungsdatum sortiert.
• PHP-Dateien in Verzeichnissen, die nur Medien enthalten dürfen, also unter images/, media/ oder tmp/.
• Dateien mit Änderungsdatum, das zu keinem Ihrer Deployments oder Updates passt.
• Unbekannte Editor-Profile, Module oder Plugins, die aktiv sind, aber in keiner Dokumentation auftauchen.
• Eine .htaccess mit Weiterleitungsregeln, die nach User-Agent oder Referrer unterscheiden.
• Ausgehende Verbindungen des Webservers zu Hosts, die Sie nicht kennen.
• Suchergebnisse zu Ihrer Domain, die Sie mit einer site-Abfrage bei Google finden und die nicht aus Ihrem Redaktionssystem stammen.
• Erhöhte Last ohne Kampagne oder Traffic-Anlass, oft durch Spam-Versand oder Krypto-Mining.

Was Bereinigungsstatistiken über Befunde sagen

Sucuri veröffentlicht jährlich Zahlen aus der eigenen Incident Response. Die Verteilung der Befunde erklärt gut, warum eine oberflächliche Bereinigung fast immer scheitert.

Der Anteil der Backdoors ist die wichtigste Zahl in dieser Tabelle. Wer die ausgenutzte Lücke schließt, aber die hinterlassene Hintertür übersieht, hat die Website nicht bereinigt, sondern nur den Angreifer gebeten, den Nebeneingang zu benutzen.

Eine Backdoor ist kein Nebenprodukt des Angriffs, sondern sein Zweck. Sie sichert den Zugang für den Tag, an dem Sie die eigentliche Lücke endlich schließen.

Die ersten Schritte nach dem Fund

Sichern Sie zuerst Beweise und sperren Sie danach den Zugang, denn wer sofort löscht, verliert die Information darüber, wie der Angreifer hereinkam. Ohne diese Information wiederholt sich der Vorfall.

Konkret heißt das: Ziehen Sie eine vollständige Kopie des Webspace und einen Datenbank-Dump, bevor Sie eine einzige Datei anfassen. Legen Sie diese Kopie außerhalb des Webservers ab und markieren Sie sie eindeutig als infiziert. Sichern Sie außerdem die Access- und Error-Logs des Webservers sowie Mail-Logs. Bei vielen Hostern rotieren Logs nach wenigen Tagen, danach lässt sich der Einbruchsweg nicht mehr rekonstruieren.

Nehmen Sie die Website anschließend offline. Joomla bietet dafür den Offline-Modus, der aber nur die Anwendung betrifft und untergeschobene PHP-Dateien weiterhin ausführbar lässt. Sperren Sie deshalb auf Serverebene, per .htaccess mit einer IP-Freigabe für Ihr Team oder über eine Wartungsseite im Reverse Proxy. Wenn Sie einen Verdacht auf laufenden Datenabfluss haben, ziehen Sie die Website ganz vom Netz.

Rotieren Sie parallel alle Zugangsdaten, die im Webspace stehen oder auf ihn zeigen: Datenbankpasswort in der configuration.php, FTP- und SSH-Zugänge, Hoster-Panel, SMTP-Zugangsdaten, API-Schlüssel von Zahlungsdienstleistern und Versanddienstleistern. Der secret-Wert in der configuration.php gehört ebenfalls ersetzt, weil er in die Session- und Token-Bildung eingeht.

Joomla bereinigen: der Ablauf im Detail

Joomla bereinigen bedeutet, alle austauschbaren Bestandteile durch Originaldateien zu ersetzen und nur die Teile manuell zu prüfen, die nicht ersetzbar sind: eigene Uploads, die Datenbank und individuell entwickelter Code. Das Suchen und Löschen einzelner Schadcode-Zeilen ist der langsamere und unsicherere Weg.

Schritt 1: Kern durch Originaldateien ersetzen

Laden Sie das offizielle Full-Package Ihrer Joomla-Version von joomla.org und ersetzen Sie damit alle Kerndateien und Kernverzeichnisse. Behalten Sie nur configuration.php, Ihre eigenen Uploads unter images/ und Ihre individuellen Templates oder Overrides. Wenn Sie eine veraltete Version einsetzen, nutzen Sie das jeweils passende Full-Package und planen das Update direkt anschließend ein, statt es zu überspringen.

Ein Detail, das oft übersehen wird: Ein Full-Package überschreibt vorhandene Dateien, entfernt aber keine untergeschobenen. Eine Datei namens media/vendor/jquery/js/cache.php bleibt liegen. Vergleichen Sie deshalb die Dateiliste Ihrer Installation mit der Dateiliste des Pakets und löschen Sie alles, was im Original nicht vorkommt. Auf der Kommandozeile erledigt das ein diff über zwei sortierte find-Ausgaben in wenigen Sekunden.

Schritt 2: Erweiterungen einzeln bewerten

Gehen Sie die Liste unter System und Verwalten und Erweiterungen durch und treffen Sie für jeden Eintrag eine Entscheidung. Erweiterungen, die Sie noch brauchen, installieren Sie neu aus der Originalquelle des Herstellers, nicht aus einem Backup. Erweiterungen, die niemand mehr nutzt, deinstallieren Sie vollständig, statt sie nur zu deaktivieren, denn deaktivierte Komponenten liegen weiter im Dateisystem und ihre Dateien bleiben über direkte URLs erreichbar.

Achten Sie besonders auf Erweiterungen ohne aktuelle Update-Quelle. Wenn ein Hersteller sein Produkt eingestellt hat oder die letzte Version Jahre alt ist, gibt es keinen Weg, dieses Risiko sauber zu betreiben. Suchen Sie einen Ersatz oder lösen Sie die Funktion anders.

Schritt 3: Uploads und Medienordner durchsuchen

In images/, media/ und tmp/ darf keine ausführbare Datei liegen. Suchen Sie dort nach den Endungen php, php3, php5, phtml, phar und inc sowie nach doppelten Endungen wie .xml.php oder .gif.php. Prüfen Sie außerdem Dateien, deren Inhalt nicht zur Endung passt: Ein PHP-Tag in einer .gif ist ein eindeutiger Befund. Auf der Kommandozeile liefert grep über die Muster eval(, base64_decode, gzinflate, str_rot13, assert(, preg_replace mit e-Modifikator, system(, shell_exec und passthru die meisten Treffer.

Bewerten Sie Treffer aber immer im Kontext. base64_decode kommt auch in legitimen Bibliotheken vor. Entscheidend ist die Kombination aus Fundort, Obfuskierung und Eingabequelle: Ein kurzes Skript, das Daten aus $_POST oder $_COOKIE durch eval schickt, ist eine Backdoor, egal wie es heißt.

Schritt 4: Datenbank prüfen

Angreifer nisten sich zunehmend in der Datenbank ein, weil dort niemand nach ihnen sucht. Prüfen Sie die Benutzertabelle auf unbekannte Konten und auf Zuordnungen zur Gruppe Super Users. Prüfen Sie die Modultabelle auf Custom-HTML-Module mit script-Tags. Durchsuchen Sie Beiträge und Custom Fields nach eingebetteten iframes, nach display:none und nach Links auf fremde Domains. Sehen Sie sich die Tabelle der geplanten Aufgaben an, denn der Joomla-Scheduler eignet sich hervorragend als Persistenzmechanismus.

Kontrollieren Sie auch die Konfiguration selbst. Ein aktivierter Debug-Modus, ein auf 0 gesetztes Session-Handling oder eine geänderte Mail-Konfiguration sind Spuren, die zum Angreifer gehören können.

Schritt 5: Serverumgebung mitnehmen

Der Webspace ist nicht die ganze Umgebung. Prüfen Sie die Cronjobs des Benutzers, denn ein wiederkehrender wget-Aufruf holt eine gelöschte Backdoor nach Minuten zurück. Prüfen Sie .htaccess-Dateien in allen Unterverzeichnissen, nicht nur im Root. Prüfen Sie Mail-Weiterleitungen und Autoresponder im Hosting-Panel. Prüfen Sie schließlich, ob im selben Webspace weitere Anwendungen liegen, denn eine veraltete WordPress-Installation in einem Unterordner erklärt viele Joomla-Infektionen, ohne dass Joomla selbst die Lücke hatte.

Schritt 6: Arbeitsplätze und Passwörter

Setzen Sie alle Benutzerpasswörter zurück und erzwingen Sie eine Neuanmeldung. Aktivieren Sie die Mehrfaktor-Authentifizierung für alle Konten mit Backend-Zugang. Lassen Sie außerdem die Rechner prüfen, von denen aus jemand FTP- oder Backend-Zugang hatte. Ein Infostealer auf einem Redaktionsrechner reproduziert jeden Einbruch, den Sie serverseitig gerade behoben haben.

Angriffswege in Joomla und ihre Erkennungsmerkmale

Die meisten Joomla-Kompromittierungen 2026 gehen nicht auf den Kern zurück, sondern auf ungepatchte Drittanbieter-Erweiterungen mit Datei-Upload-Funktion. Der Kern erhält regelmäßig Sicherheitsupdates und wird von vielen Augen gelesen. Eine Baukasten-Erweiterung mit einem Upload-Endpunkt ohne Rechteprüfung öffnet dagegen den direkten Weg zur Codeausführung.

Zwei Fälle aus dem Juni 2026 zeigen das Muster deutlich. Beim Joomla Content Editor erlaubte CVE-2026-48907 unauthentifizierten Angreifern, über die Profil-Import-Funktion eine PHP-Datei hochzuladen und im tmp-Verzeichnis auszuführen. Der Fehler betraf alle Versionen bis einschließlich 2.9.99.4, die Korrektur erschien am 3. Juni 2026 in 2.9.99.5, eine Nachhärtung folgte in 2.9.99.6. CISA nahm die Lücke am 16. Juni 2026 in den Katalog der bekannt ausgenutzten Schwachstellen auf. Kurz danach traf es SP Page Builder mit CVE-2026-48908 im Task asset.uploadCustomIcon, behoben in Version 6.6.2, sowie Page Builder CK mit CVE-2026-56290, behoben in 3.6.0. Die Cyber Security Agency of Singapore stufte beide mit CVSS 9.8 ein und meldete aktive Ausnutzung.

Im Kern dominiert 2026 eine andere Fehlerklasse: fehlerhafte Zugriffsprüfungen in den Webservice-Endpunkten. Am 7. Juli 2026 behob Joomla mit 5.4.7 und 6.1.2 drei solche Fälle, darunter CVE-2026-48958 zum Anlegen von Custom Fields ohne Berechtigung und CVE-2026-48957 zum Auslesen von com_privacy-Datensätzen. Beide betrafen die Zweige 4.0.0 bis 5.4.6 und 6.0.0 bis 6.1.1. Am 26. Mai 2026 hatten die Versionen 5.4.6 und 6.1.1 bereits zehn Probleme geschlossen, unter anderem zwei Umgehungen der Mehrfaktor-Authentifizierung und eine Privilegien-Eskalation in den Batch-Aktionen von com_users. Wer sich fragt, ob diese Klasse tatsächlich ausgenutzt wird: CVE-2023-23752, ebenfalls eine fehlerhafte Zugriffsprüfung an Webservice-Endpunkten, steht seit dem 8. Januar 2024 im CISA-Katalog.

Joomla 3 End of Life und der Support-Status der Versionen

Joomla 3 erhält seit dem 17. August 2023 keine Sicherheitsupdates mehr, Joomla 4 seit dem 14. Oktober 2025, sodass 2026 nur noch die Zweige 5.x und 6.x überhaupt gepatcht werden. Jede Installation auf 3.x oder 4.x ist damit unabhängig von konkreten Symptomen ein offener Posten, weil neue Lücken dort niemals geschlossen werden.

Beachten Sie die Zeile zu Joomla 5: Der Bugfix-Support endet am 13. Oktober 2026. Danach fließen dort nur noch Sicherheitskorrekturen, bis am 12. Oktober 2027 auch die enden. Wer heute von 3.x oder 4.x migriert, sollte deshalb prüfen, ob der Sprung direkt auf 6.x sinnvoll ist. Joomla 6 verlangt allerdings mindestens PHP 8.3.0 sowie MySQL 8.0.13 oder MariaDB 10.4, was bei manchen Hostings zuerst einen Wechsel des PHP-Handlers oder des Tarifs nötig macht.

Der Marktanteil erklärt, warum Joomla-Installationen so oft veralten. W3Techs weist Joomla am 3. August 2026 mit 1,7 Prozent Anteil unter den erkannten Content-Management-Systemen und 1,2 Prozent aller Websites aus. Viele dieser Installationen laufen seit Jahren ohne Betreuungsvertrag, weil der ursprüngliche Dienstleister nicht mehr existiert oder das Projekt nach dem Launch aus dem Budget fiel.

Joomla Migration: von 3.x auf 5.x oder 6.x

Es gibt keinen direkten Upgrade-Pfad von Joomla 3 auf Joomla 5 oder 6, Sie migrieren zwingend über 3.10.x und 4.4.x. Der Sprung von 3 auf 4 ist dabei die eigentliche Arbeit, weil sich Ordnerstruktur, Namensräume und Template-Konventionen geändert haben. Der Weg von 4 auf 5 und weiter auf 6 verhält sich danach wie ein normales Update.

Beginnen Sie mit einer Inventur der Erweiterungen, bevor Sie eine Zeile Code anfassen. Joomla 3.10 bringt dafür den Pre-Update-Check mit, der jede installierte Erweiterung gegen die Kompatibilitätsangaben der Hersteller prüft. Für jede Erweiterung gibt es dann genau vier Optionen: aktualisieren, ersetzen, Funktion neu bauen oder Funktion streichen. Klären Sie das vollständig, denn eine Migration, die an einer inkompatiblen Komponente hängen bleibt, blockiert das gesamte Update.

Führen Sie die Migration immer auf einer Kopie durch, nie am produktiven System. Ziehen Sie Dateien und Datenbank auf eine Staging-Umgebung mit derselben PHP-Version wie das Ziel, arbeiten Sie dort die Schritte durch und dokumentieren Sie jeden Handgriff. Der zweite Durchlauf auf dem Produktivsystem folgt dann einem geprüften Ablaufplan statt einem Versuch.

Wenn Sie eine Migration nach einem Sicherheitsvorfall planen, drehen Sie die Reihenfolge nicht: Erst bereinigen, dann migrieren. Wer eine infizierte Installation migriert, überträgt Backdoors in Datenbank und Uploads in die neue Umgebung und verliert die Möglichkeit, Änderungen später sauber zuzuordnen.

Template und individueller Code

Alte Joomla-3-Templates auf Basis von Bootstrap 3 laufen unter Joomla 5 oder 6 nicht ohne Anpassung. Rechnen Sie hier mit dem größten Aufwandsblock, besonders wenn Overrides für Kernkomponenten existieren. Prüfen Sie zuerst, ob der Template-Hersteller eine aktuelle Version anbietet. Existiert die Vorlage nicht mehr, ist ein Neuaufbau des Templates auf aktueller Basis meist günstiger als das Nachziehen jahrealter Overrides.

Joomla Sicherheitsupdate: Prozess statt Einzelaktion

Ein Joomla Sicherheitsupdate schützt nur dann, wenn es innerhalb von Tagen nach Veröffentlichung eingespielt wird, denn öffentliche Proof-of-Concept-Exploits erscheinen inzwischen regelmäßig binnen einer Woche. Bei CVE-2026-48907 lag zwischen Patch am 3. Juni 2026 und veröffentlichtem Exploit auf GitHub weniger als eine Woche.

Legen Sie deshalb einen festen Rhythmus fest und benennen Sie eine verantwortliche Person. Ein tragfähiges Minimum sieht so aus:

• Abonnieren Sie die Joomla Security Announcements unter developer.joomla.org/security-centre als Feed, nicht als gelegentlichen Website-Besuch.
• Abonnieren Sie zusätzlich die Update-Kanäle der Hersteller aller eingesetzten Erweiterungen, insbesondere von Editoren und Seiten-Baukästen.
• Prüfen Sie wöchentlich den Update-Bereich im Joomla-Backend und spielen Sie Kernupdates innerhalb von sieben Tagen ein.
• Behandeln Sie Meldungen aus dem CISA-Katalog der bekannt ausgenutzten Schwachstellen als Notfall und patchen Sie innerhalb von 24 Stunden.
• Testen Sie jedes Update zuerst auf Staging, halten Sie aber ein Rollback bereit, statt den Test zum Grund für Verzögerung zu machen.
• Halten Sie ein Backup-Konzept vor, das versionierte Kopien außerhalb des Webservers speichert und dessen Wiederherstellung Sie mindestens einmal jährlich testen.
• Aktivieren Sie das Aktionsprotokoll in Joomla, damit Sie nach einem Vorfall nachvollziehen können, wer wann was geändert hat.
• Erzwingen Sie Mehrfaktor-Authentifizierung für jeden Backend-Zugang und entfernen Sie Konten ausgeschiedener Mitarbeitender sofort.

Ergänzend hilft eine Serverkonfiguration, die die Folgen eines Uploads begrenzt. Nehmen Sie die Verzeichnisse images/, media/ und tmp/ vom PHP-Handler aus, setzen Sie open_basedir, deaktivieren Sie nicht benötigte Funktionen wie exec und passthru und geben Sie dem Webserver keinen Schreibzugriff auf Verzeichnisse, in denen keine Uploads landen müssen. Diese Maßnahmen verhindern keinen Einbruch, aber sie machen aus einer Codeausführung häufig einen wirkungslosen Upload.

Meldepflichten nach DSGVO Art. 33 und Art. 34

Sobald bei einem Hack personenbezogene Daten betroffen sein können, müssen Sie den Vorfall nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden nach Kenntnis der zuständigen Aufsichtsbehörde melden. Die Frist beginnt mit der Kenntnis der Verletzung, nicht mit dem Abschluss der Analyse. Eine unvollständige Meldung mit Nachlieferung ist zulässig, eine verspätete Meldung ohne Begründung nicht.

Für ein gehacktes Joomla ist die Schwelle schnell erreicht. Ein Webshell mit Dateisystemzugriff erreicht die Datenbank und damit die Benutzertabelle mit Namen, E-Mail-Adressen und Passwort-Hashes. Kontaktformular-Einträge, Newsletter-Listen und Bestelldaten liegen ebenfalls dort. Sie müssen nicht beweisen, dass Daten abgeflossen sind. Es genügt, dass ein Zugriff möglich war und Sie das nicht ausschließen können.

Was Sie für die Meldung brauchen

Die Aufsichtsbehörden stellen Online-Formulare bereit, die inhaltlich Art. 33 Abs. 3 DSGVO folgen. Halten Sie die Angaben bereit, bevor Sie mit der Bereinigung fertig sind: Art der Verletzung, betroffene Kategorien personenbezogener Daten, ungefähre Zahl betroffener Personen und Datensätze, wahrscheinliche Folgen, ergriffene und geplante Gegenmaßnahmen sowie die Kontaktdaten des Datenschutzbeauftragten oder einer anderen Auskunftsstelle. Genau deshalb steht die Beweissicherung am Anfang der Bereinigung und nicht am Ende.

Die Benachrichtigung der Betroffenen nach Art. 34 DSGVO greift erst bei voraussichtlich hohem Risiko. Bei ausschließlich starken, korrekt gesalzenen Passwort-Hashes und ohne Zahlungsdaten kann diese Pflicht entfallen. Bei Klartextdaten, Gesundheitsdaten oder Zahlungsinformationen entfällt sie nicht. Dokumentieren Sie in beiden Fällen die Begründung Ihrer Einschätzung, denn die Nachweispflicht liegt bei Ihnen.

Ein Verstoß gegen die Meldepflicht aus Art. 33 DSGVO kann nach Art. 83 Abs. 4 DSGVO mit Geldbußen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes des Vorjahres geahndet werden, je nachdem, welcher Betrag höher ist. Klären Sie außerdem vertragliche Meldewege: Wenn Sie Daten im Auftrag verarbeiten, verpflichtet Art. 33 Abs. 2 DSGVO Sie zur unverzüglichen Meldung an Ihren Auftraggeber, unabhängig von Ihrer eigenen Analyse.

Wann ein Neuaufbau günstiger ist als die Bereinigung

Ein Neuaufbau ist der wirtschaftlichere Weg, sobald die Bereinigung mehr Aufwand kostet als eine frische Installation mit importierten Inhalten, und das ist bei alten Installationen mit vielen Erweiterungen häufig der Fall. Die Entscheidung fällt nicht nach Gefühl, sondern nach wenigen prüfbaren Kriterien.

• Die Installation läuft auf Joomla 3.x oder 4.x, also ohne Sicherheitsupdates. Dann steht die Migration ohnehin an.
• Mehrere eingesetzte Erweiterungen haben keinen aktiven Hersteller mehr. Ohne Updates lässt sich der Betrieb nicht verantworten.
• Es existiert kein Backup aus der Zeit vor dem Einbruch, das Sie als sauberen Referenzstand nutzen könnten.
• Sie finden mehrere unabhängige Backdoors, was auf mehrere Angreifer oder monatelange Präsenz hindeutet.
• Die Website wurde nach einer Bereinigung erneut infiziert. Dann fehlt entweder ein Zugang oder eine Persistenz.
• Individueller Code liegt ohne Versionskontrolle vor, sodass Sie legitime von untergeschobenen Änderungen nicht unterscheiden können.

Beim Neuaufbau übernehmen Sie ausschließlich Daten, keine Dateien und keinen Code: Beiträge, Kategorien, Medien nach Prüfung und Benutzer ohne Passwörter mit erzwungenem Reset. Die Struktur bauen Sie neu, die URLs halten Sie über Weiterleitungen stabil, damit die Suchmaschinen-Sichtbarkeit erhalten bleibt.

CMS gehackt, was tun: Checkliste für die ersten 48 Stunden

Die kurze Antwort auf die Frage, was bei einem gehackten CMS zu tun ist: Beweise sichern, Zugang sperren, Meldefrist prüfen, ersetzen statt reparieren, Zugangsdaten rotieren, Ursache belegen. Die folgende Reihenfolge hat sich für Joomla bewährt und lässt sich auf andere Systeme übertragen.

• Stunde 0: Vollständige Kopie von Dateien und Datenbank ziehen, Access-, Error- und Mail-Logs sichern, alles als infiziert kennzeichnen.
• Stunde 0: Website serverseitig sperren oder vom Netz nehmen, Offline-Modus allein genügt nicht.
• Stunde 1: Feststellen, ob personenbezogene Daten betroffen sein können, und die 72-Stunden-Frist nach Art. 33 DSGVO im Kalender vermerken.
• Stunde 1: Alle Zugangsdaten rotieren, inklusive Datenbankpasswort und secret-Wert in der configuration.php.
• Stunde 2 bis 8: Logs auswerten und den Einbruchsweg belegen, bevor Sie löschen. Ohne Ursache keine abgeschlossene Bereinigung.
• Stunde 4 bis 24: Kern per Full-Package ersetzen, Erweiterungen neu aus Originalquellen installieren, überzählige Dateien löschen.
• Stunde 8 bis 24: Uploads und Datenbank auf Backdoors, fremde Konten, manipulierte Module und geplante Aufgaben prüfen.
• Stunde 24 bis 48: Serverkonfiguration härten, PHP-Ausführung in Upload-Pfaden abschalten, MFA erzwingen, Aktionsprotokoll aktivieren.
• Stunde 24 bis 48: Meldung an die Aufsichtsbehörde absetzen, falls erforderlich, und den Vorfall nach Art. 33 Abs. 5 DSGVO dokumentieren.
• Nach dem Wiederanlauf: Über zwei Wochen täglich auf Wiederinfektion prüfen, Suchmaschinen-Index kontrollieren, Blocklisten-Einträge aufheben lassen.

Halten Sie den letzten Punkt ein. Eine Wiederinfektion innerhalb weniger Tage ist das häufigste Signal dafür, dass ein Zugang offen geblieben ist, und sie liefert Ihnen bei früher Erkennung genau die Logeinträge, die Sie beim ersten Durchgang vermisst haben.

Wenn Sie eine Joomla-Installation betreiben, die seit Jahren ohne Updates läuft, warten Sie nicht auf den Vorfall. Die Bereinigung nach einem Einbruch kostet regelmäßig ein Vielfaches der Migration, die Sie vorher hätten planen können, und sie kommt zu einem Zeitpunkt, den nicht Sie bestimmen.