Joomla gehackt? „Hacked by“ richtig beheben

1Joomla gehackt und „Hacked by“ auf der Startseite

Plötzlich steht da nur noch „Hacked by …“. Manchmal schlicht eine umgeschriebene Startseite, manchmal Varianten wie „Hacked by AntonKil“ oder „Hacked by trenggalek6etar“. Ob das echte Gruppenbezeichnungen, Copycats oder bloß austauschbare Defacement-Tags sind, ist für deine erste Reaktion ehrlich gesagt zweitrangig.

Wichtig ist etwas anderes: Deine Website ist kompromittiert. Nicht optisch. Technisch.

Gerade bei älteren Joomla-Seiten im Raum Aachen, Würselen, Stolberg oder Eschweiler sehe ich dasselbe Muster immer wieder: Die Seite lief jahrelang „noch irgendwie“, Updates wurden vertagt, eine alte Erweiterung blieb liegen, Zugangsdaten wurden weitergereicht. Dann reicht eine bekannte Lücke – und plötzlich wirbt jemand auf deiner Startseite für seinen Ego-Trip.

Die gute Nachricht: Du kannst das sauber beheben.

Die schlechte: Einfach die Startseite zurückkopieren ist meistens Pfusch. Backdoors sitzen oft tiefer – in index.php, in /components, /modules, /templates oder in komplett unauffälligen Dateien, die auf den ersten Blick legitim wirken.

21. Was eine „Hacked by“-Meldung wirklich bedeutet

Eine sichtbare Defacement-Seite ist nur die Spitze des Problems . Dahinter stecken oft manipulierte Core-Dateien, zusätzliche Admin-Konten, SEO-Spam, Redirects auf Fremdseiten oder nachgeladene Schadskripte.

In meiner Arbeit mit Unternehmen aus der Städteregion Aachen ist genau das der häufigste Denkfehler: Die Startseite wird schnell ersetzt, die Seite ist wieder erreichbar, alle atmen auf. Zwei Wochen später tauchen Casino-Unterseiten im Google-Index auf oder Kontaktformulare leiten auf dubiose Domains weiter. Das ist dann nicht Pech, sondern eine halbe Bereinigung.

1. 1
   Seite isolieren

   Wartungsmodus einschalten oder die Website beim Hoster temporär sperren, damit Besucher keinen Schadcode sehen und Angreifer nichts nachladen.
2. 2
   Forensisches Backup ziehen

   Komplette Webdateien, Datenbank, configuration.php sowie Access- und Error-Logs sichern.
3. 3
   Zeitfenster eingrenzen

   Prüfen, wann verdächtige Dateien zuletzt geändert wurden und wie weit die Host-Logs zurückreichen.
4. 4
   Erst dann bereinigen

   Keine Blindaktion mit Restore oder Dateilöschung, bevor Ursache und Umfang grob klar sind.

Wenn Google bereits eine Warnung anzeigt, geh direkt in den Bericht „Sicherheitsprobleme“. Die offizielle Search Console-Hilfe beschreibt den Ablauf sauber.

32. Joomla-Lifecycle: Welche Versionen heute ein echtes Risiko sind

Hier muss man klar sein. Bei Joomla ist der Lifecycle kein Detail, sondern ein Sicherheitsfaktor.

Joomla 3 ist seit August 2023 End of Life. Dafür gibt es keinen regulären Sicherheits-Support mehr. Wer das noch produktiv betreibt, nimmt bekannte und künftige Lücken ohne Airbag in Kauf.

Joomla 4 ist ebenfalls keine langfristig sichere Ziellinie mehr. Nach dem offiziellen Joomla-Release-Zyklus endete der Security-Support für Joomla 4 im Oktober 2025. Maßgeblich sind die Angaben im Joomla Security Centre sowie die offiziellen Release- und Support-Informationen auf joomla.org.

Für produktive Websites heißt das praktisch:

• Joomla 3.x: EOL seit August 2023
• Joomla 4.x: Security-Support ausgelaufen seit Oktober 2025
• Joomla 5.x: die aktuell sinnvolle, unterstützte Ziellinie

Dazu kommt die Plattform darunter. Die offiziellen technischen Anforderungen auf downloads.joomla.org/technical-requirements zeigen klar, welche PHP-Versionen zu aktuellen Joomla-Versionen passen. Alte PHP-Stände sind nicht nur langsamer, sondern häufig selbst außerhalb des Supports.

43. Konkrete Schwachstellen: Diese CVEs waren kein Theoriekram

„Veraltete Erweiterungen“ stimmt zwar. Aber wenn du verstehen willst, warum Updates nicht optional sind, helfen konkrete Fälle mehr als Allgemeinplätze.

Hier drei reale Joomla-Schwachstellen aus offiziellen Advisories:

Genau solche Fälle meine ich, wenn ich sage: Ein ungepatchtes Joomla 4 war nie automatisch „schon modern genug“. Modern ist nur, was auch wirklich gepflegt wird.

Und nein, der Joomla-Core ist nicht pauschal unsicher. Das eigentliche Problem ist fast immer die Kombination aus offenen bekannten Lücken, verspäteten Updates und liegengebliebenen Drittanbieter-Erweiterungen.

Zusätzliche typische Einfallstore sind:

1. Ungepatchter Core
2. Verlassene Komponenten, Module oder Plugins
3. Templates mit eingebautem Alt-Code
4. Geteilte Admin-Zugänge ohne 2FA
5. FTP statt SFTP/SSH
6. Zu offene Dateirechte
7. Zugangsdaten in alten Mails oder lokalen Tools

Wenn du bei so einer Altinstallation einmal grundsätzlich aufräumen musst, ist das meist mehr als „mal eben eine Website retten“. Genau da greift oft saubere IT-Beratung, weil die Betriebsbasis mit saniert werden muss.

54. Backdoors finden: typische Pfade, Marker und konkrete Prüf-Workflows

Laut Sucuri verstecken sich Backdoors bei Joomla gern in legitimen Dateinamen an falschen Orten oder direkt in Dateien wie index.php sowie in /components, /modules und /templates.

Typische verdächtige PHP-Funktionen sind:

• base64_decode
• eval
• assert
• exec
• system
• gzinflate
• gzuncompress
• create_function
• preg_replace mit /e/
• move_uploaded_file
• curl_exec
• file_get_contents

Typische String- und JavaScript-Indikatoren:

• location.href
• sehr lange verschleierte Zeichenketten
• mehrfach geschachtelte Decoder
• merkwürdige str_rot13- oder strrev-Konstrukte

Stattdessen gehst du operativ vor. Zum Beispiel so:

Verdächtige PHP-Dateien in Upload-, Cache- und Temp-Pfaden suchen

find images/ cache/ tmp/ -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" \)

In vielen sauberen Joomla-Installationen gehören dort keine ausführbaren PHP-Dateien hinein. Jeder Treffer ist prüfenswert.

Frische Änderungen der letzten Tage finden

find . -type f -mtime -7 | sort

Wenn du den ungefähren Angriffszeitraum kennst, ist das Gold wert. Noch zielgenauer wird es mit Datum:

find . -type f -newermt "2026-01-10" ! -newermt "2026-01-15"

Nach typischen Obfuscation-Markern suchen

grep -RInE "base64_decode|gzinflate|gzuncompress|eval\(|assert\(|str_rot13|preg_replace.*\/e|shell_exec|system\(|exec\(|passthru\(" .

### Core-Dateien gegen sauberes Joomla-Paket vergleichen

Lade das exakt passende offizielle Joomla-Paket herunter und vergleiche die Dateien lokal:

```bash

diff -ruN clean-joomla/ public_html/

Oder pragmatischer per Hash-Vergleich:

find clean-joomla -type f -exec sha256sum {} \; | sort > clean.sha find public_html -type f -exec sha256sum {} \; | sort > live.sha diff clean.sha live.sha

Ungewöhnliche Administratoren und Cron-/Shell-Reste prüfen

• Joomla-Benutzerliste im Backend und in der Datenbank gegen bekannte Accounts abgleichen
• Geplante Jobs beim Hoster kontrollieren
• .htaccess, index.php, configuration.php und Template-Overrides gezielt prüfen

65. Joomla bereinigen: die Reihenfolge, die in der Praxis funktioniert

Jetzt kommt der Teil, bei dem viele hektisch werden. Verständlich. Aber genau hier macht Struktur den Unterschied.

Schritt 1: Forensisches Backup und Log-Sicherung

Sichere komplette Dateien, Datenbank-Dump, configuration.php, Access-Logs, Error-Logs und – falls vorhanden – WAF- oder CDN-Logs.

Schritt 2: Zeitfenster und Einstiegspunkt eingrenzen

Suche nach verdächtigen POST-Requests, Uploads, Admin-Logins, Aufrufen unbekannter PHP-Dateien und Dateischreibaktionen im fraglichen Zeitraum. Wenn kurz vor dem Defacement eine alte Komponente angesprochen wurde, hast du oft schon einen belastbaren Verdacht.

Schritt 3: Core aus offizieller Quelle sauber neu einspielen

Spiele den Joomla-Core aus einem offiziellen Paket neu ein. Nicht aus irgendeinem Alt-Backup eines früheren Dienstleisters, nicht aus einem Download-Ordner auf dem Laptop.

Der Fokus liegt zuerst auf Core-Pfaden wie:

• /administrator
• /includes
• /libraries
• Root-Dateien wie index.php

Schritt 4: Erweiterungen und Templates kompromisslos auditieren

Für jede Komponente, jedes Modul, Plugin und Template gilt:

• Wird es noch gepflegt?
• Ist die Version aktuell?
• Brauchst du es wirklich?
• Kommt es aus vertrauenswürdiger Quelle?

Alles, was unklar, veraltet oder verlassen ist, fliegt raus. Da bin ich ziemlich eindeutig. Eine hübsche Slideshow von 2018 ist kein Grund, heute eine offene Flanke mitzuschleppen.

Schritt 5: Datenbank, Inhalte und Benutzer prüfen

Kontrolliere:

• neue oder unbekannte Admin-Konten
• geänderte Mailadressen von Admins
• fremde Module oder Menüpunkte
• Spam-Inhalte in Artikeln
• verdächtige Redirects
• Script-Injections in benutzerdefinierten Feldern oder Modulen

Schritt 6: Alle Zugangsdaten rotieren

Nach dem Hack gelten alte Zugangsdaten als verbrannt. Wechsle mindestens:

• Joomla-Administrator-Zugänge
• Hoster-Panel
• SFTP/SSH
• Datenbank-Zugangsdaten
• Mailpostfächer
• API-Keys
• CDN/WAF-Logins

Schritt 7: Nachkontrolle und Monitoring

Beobachte die Website nach der Bereinigung engmaschig. Wenn binnen Stunden wieder verdächtige Dateien auftauchen, ist die Lücke noch offen oder eine Backdoor blieb liegen.

76. Backup-Restore oder manuelle Bereinigung?

Die Frage kommt immer. Und die ehrliche Antwort ist: Ein Restore ist nicht automatisch die saubere Lösung.

Ein Backup hilft nur dann wirklich, wenn du belegen kannst, dass es vor dem Angriff erstellt wurde und die eigentliche Eintrittsstelle danach geschlossen wird. Sonst spielst du dir die nächste Runde nur selbst wieder ein.

Gerade bei kleineren Firmenwebsites in der Region sehe ich oft das gleiche Bild: Niemand weiß mehr genau, welche Erweiterung wofür installiert wurde. In so einem Zustand ist „Restore und hoffen“ keine Strategie, sondern Glückspiel.

87. Google-Warnung entfernen und SEO-Schaden begrenzen

Wenn Google deine Website als kompromittiert oder gefährlich einstuft, ist das mehr als ein Technikproblem. Dann verlierst du Vertrauen, Klicks und oft auch Anfragen .

Die offizielle Search Console-Hilfe nennt den Ablauf klar:

1. Problem bestätigen
2. Problem bewerten
3. Website bereinigen
4. Korrekturen bestätigen
5. Überprüfung anfordern

Laut web.dev dauert die Malware-Überprüfung oft einige Tage. In komplizierteren Fällen auch länger. Deshalb solltest du den Antrag erst stellen, wenn du wirklich fertig bist.

Vor dem Review prüfst du mindestens:

• Beispiel-URLs aus dem Bericht „Sicherheitsprobleme“
• URL-Prüfung für betroffene Seiten
• indexierte Spam-Unterseiten
• manipulierte Meta-Titel und Descriptions
• fremde Sitemaps
• externe Redirects
• schädliche Downloads
• versteckte JavaScript- oder PHP-Injections

98. Schutz danach: Was für den Mittelstand wirklich praktikabel ist

Nach dem Hack kommt fast immer die Frage nach dem richtigen Schutz-Setup. Meine Meinung: Nicht blind drei Security-Plugins stapeln, sondern Schutzebenen kombinieren .

Sinnvoll sind meist diese drei Ebenen:

1. Network/CDN-WAF – zum Beispiel Cloudflare, Sucuri WAF oder hostingseitige Schutzschichten
2. Joomla-nahe Application-WAF – etwa Admin Tools, RSFirewall oder Securitycheck Pro
3. File-Integrity- und Malware-Monitoring – damit Änderungen früh auffallen

Im Joomla Extension Directory zu Securitycheck Pro wird genau diese Kombination aus WAF, Malware-Scanner und File-Integrity-Monitoring beschrieben. Das ist nützlich. Aber es ersetzt keine Updates, keine Härtung und keine saubere Bereinigung.

Für KMU-praktischen Betrieb gehören aus meiner Sicht zusätzlich diese Basics dazu:

• SSL/TLS sauber erzwingen: Backend, Login, Formulare und gesamte Website nur über HTTPS betreiben
• 2FA für Admins aktivieren
• Restore-Tests fest einplanen: mindestens quartalsweise prüfen, ob Backups wirklich einspielbar sind
• Log-Aufbewahrung klären: beim Hoster nachfragen, wie lange Access- und Error-Logs verfügbar bleiben
• Verantwortlichkeit festziehen: monatlich Updates prüfen, quartalsweise Erweiterungsinventur und Restore-Test dokumentieren

Ehrlich gesagt wird genau dieser organisatorische Teil ständig unterschätzt. Die gehackte Website ist oft nur das Symptom davon, dass technisch niemand verantwortlich war.

109. Präventions-Checkliste für den laufenden Betrieb

Die beste Bereinigung ist die, die du nie brauchst. Klingt banal. Ist aber die Wahrheit.

Meine pragmatische Checkliste für den Alltag:

1. Nur unterstützte Joomla-Hauptversionen betreiben
2. Joomla 5 zeitnah patchen
3. PHP-Version im aktiven Support halten
4. Unnötige Erweiterungen entfernen
5. Templates regelmäßig mitprüfen
6. Admin-Zugänge mit starken Passwörtern und 2FA absichern
7. SFTP/SSH statt FTP nutzen
8. HTTPS/SSL/TLS konsequent erzwingen
9. Dateirechte und Serverhärtung prüfen
10. Backups täglich oder passend zum Änderungsrhythmus erstellen
11. Restore-Test mindestens quartalsweise durchführen
12. Hoster-Log-Aufbewahrung dokumentieren
13. Monatliche Update-Verantwortung fest zuweisen
14. Quartalsweise Erweiterungs- und Benutzer-Audit machen
15. Monitoring auf Dateiänderungen aktivieren

11Meine Einschätzung

Ein Joomla-Defacement ist fast nie nur ein optischer Schaden. Es ist ein technisches Warnsignal dafür, dass über längere Zeit etwas offen stand – im Code, im Hosting oder in der Organisation.

Mein klarer Rat: Nicht kosmetisch flicken. Erst sichern, dann Ursache eingrenzen, dann aus offiziellen Paketen bereinigen, danach härten und Verantwortlichkeiten sauber festlegen.

Vor allem bei älteren Firmenwebsites sehe ich selten den einen spektakulären Super-Exploit. Meist ist es eher die Summe kleiner Nachlässigkeiten: EOL-Versionen, verwaiste Erweiterungen, schwache Prozesse, fehlende Zuständigkeit. Das ist unbequem. Aber genau deshalb ist es lösbar.

12Häufige Fragen

Joomla gehackt: Was tun bei „Hacked by“ auf der Startseite?

Nimm die Website zuerst vom Netz oder in den Wartungsmodus, sichere Dateien, Datenbank und Logs und prüfe dann Core, Erweiterungen, Benutzer und verdächtige Dateien. Nur die Startseite zurückzusetzen reicht fast nie, weil Backdoors und der eigentliche Einstiegspunkt meist weiter vorhanden sind.

Wie entferne ich eine Google-Warnung nach einem Joomla-Hack?

Du musst die Website vollständig bereinigen, schädliche Downloads, Spam-URLs, Redirects und Injections entfernen und die Korrekturen in der Search Console prüfen. Erst danach lohnt sich der Review-Antrag. Wenn Reste auf der Website bleiben, lehnt Google die Überprüfung in der Praxis oft schnell wieder ab.

Backup zurückspielen oder Joomla manuell bereinigen – was ist besser?

Ein Restore ist gut, wenn dein Backup sicher vor dem Angriff erstellt wurde und die Lücke danach geschlossen ist. Ist der Hack-Zeitpunkt unklar, gibt es SEO-Spam, Reinfektionen oder veraltete Extensions, ist eine manuelle Bereinigung oder gleich die Migration auf Joomla 5 meist die solidere Lösung.