Fremde Werbung und Redirects
Die Website öffnet mit fremden Bannern oder leitet Besucher auf Casinos, Online-Apotheken oder dubiose Seiten um, besonders von Smartphones und aus der Suche.
Joomla · Notfallhilfe · Sicherheit
Website-Wiederherstellung nach Hack: Ich entferne Backdoors und schließe das Leck, durch das sie hereinkamen
Ich bin Artem und habe mich auf Joomla spezialisiert. Wenn Ihre Website Besucher auf Casinos umleitet, in den Suchergebnissen fremde Seiten auftauchen und der Hoster eine Schadcode-Warnung geschickt hat, finde und entferne ich Web-Shells, bereinige Injektionen aus Dateien und Datenbank, lösche gefälschte Administratoren und schließe die Eintrittsstelle, damit der Hack nicht schon am nächsten Tag zurückkehrt. Ich beginne immer mit der Diagnose.
Ist die Website gerade offline oder infiziert? Dringende Fälle nehme ich vorrangig an.
Jetzt schreibenKommt Ihnen das bekannt vor?
So sieht ein Hack aus Sicht des Website-Betreibers aus. Wenn Sie auch nur einen Punkt wiedererkennen, ist die Website höchstwahrscheinlich infiziert, und Sie sollten schnell handeln, bevor die Verluste an Traffic und Reputation wachsen.
Spam in den Suchergebnissen
In Google und Yandex erscheinen statt Ihrer Seiten fremde: Schriftzeichen, Waren, Pillen. Das ist klassischer Suchmaschinen-Spam, über den Hack eingeschleust.
Warnung „Website wurde gehackt“
Suche oder Browser zeigt die Warnung „Diese Website wurde möglicherweise gehackt“ oder blockiert den Aufruf. Besucher springen ab, ohne die Website zu öffnen.
Sperrung durch den Hoster
Der Hoster hat das Konto wegen Spamversand oder gefundenem Schadcode gesperrt. Website und E-Mail funktionieren nicht, bis die Infektion beseitigt ist.
Fremde Administratoren
Im Backend sind unbekannte Super-Benutzer aufgetaucht, die Registrierung wurde aktiviert, Passwörter funktionieren nicht mehr.
Defacement der Startseite
Statt Ihrer Website eine Hacker-Seite oder fremde Banner. Im Sommer 2026 kursiert massenhaft ein Defacement mit der Signatur „Hacked by AntonKill“.
Anzeichen, dass die Website gehackt ist
Schnelle Checkliste. Prüfen Sie selbst: Je mehr Übereinstimmungen, desto höher die Wahrscheinlichkeit einer Infektion.
- Die Website leitet Besucher auf fremde Seiten um (Casino, Wetten, Pharma, Erwachseneninhalte), oft nur von Mobilgeräten oder nur beim Aufruf aus der Suche.
- Unter Ihrer Domain erscheinen in den Suchergebnissen fremde Seiten mit Spam-Keywords (Markenrepliken, Medikamente), nicht selten mit Schriftzeichen (japanischer Keyword-Hack) in Ordnern mit zufälligen Namen.
- Google markiert die Website als „This site may be hacked“, und im Browser erscheint die rote Warnung „Deceptive site ahead“ oder ein Hinweis auf Schadcode.
- In der Search Console traf eine Benachrichtigung ein, dass eine unbekannte Person die Website als Eigentümer bestätigt hat, oder im Bericht „Sicherheitsprobleme“ sind gehackte Seiten aufgetaucht.
- Die Startseite ist durch eine Hacker-Nachricht oder fremde Banner ersetzt (Defacement, zum Beispiel „Hacked by AntonKill“).
- In der Joomla-Benutzerliste sind Super-Administratoren aufgetaucht, die Sie nicht angelegt haben (glaubwürdige Namen, Adressen auf einer nicht existierenden Domain).
- Der organische Traffic ist durch Deindexierung oder Sperrung stark eingebrochen, die Besucherzahl fiel ohne erkennbaren Grund ab.
- Der Server versendet Spam ohne Ihr Wissen: Ausgehende Mails kommen zurück, und die IP des Mailservers landet auf schwarzen Listen (RBL/DNSBL).
- Der Hoster hat eine Nachricht über Schadcode oder übermäßige Last geschickt, manchmal mit Sperrung des Kontos.
- In den Ordnern media, images, tmp sind unbekannte PHP-Dateien aufgetaucht, Dateien mit doppelter Endung (.xml.php) oder ungewöhnlicher Groß-/Kleinschreibung (.pHp).
Warum Joomla gerade jetzt massenhaft gehackt wird
Der Sommer 2026 wurde für Joomla zur Zeit massenhafter automatisierter Angriffe, und die Ursache liegt überwiegend nicht im Kern, sondern in beliebten Erweiterungen. Eine nach der anderen wurden kritische Schwachstellen (CVSS bis 10.0) aufgedeckt, die einen nicht authentifizierten Upload und die Ausführung von PHP-Code erlauben, also die vollständige Übernahme der Website ohne Passwort: JCE / Joomla Content Editor (CVE-2026-48907, Fix in 2.9.99.5), SP Page Builder (CVE-2026-48908, Fix in 6.6.2), iCagenda (CVE-2026-48939, Fix in 4.0.8 und 3.9.15) und Page Builder CK (CVE-2026-56290, Fix in 3.6.0). Ein Teil wurde als 0-day ausgenutzt, noch vor dem Patch, und alle wurden von der CISA in den Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Die Exploits sind öffentlich, die Angriffe laufen per Bots über das gesamte Internet, deshalb schützen weder eine geschlossene Registrierung noch geringer Traffic vor einer Infektion.
Das Ausmaß zeigt sich auch auf Ebene der nationalen CERTs. Am 9. Juli 2026 warnte das Australische Zentrum für Cybersicherheit (ACSC) vor einer großen, andauernden globalen Kampagne: Angreifer scannen massenhaft CMS-Websites und installieren Web-Shells, und in der Liste der verwundbaren Software wird Joomla JCE ausdrücklich genannt. Das ACSC hält für möglich, dass die Kampagne durch KI beschleunigt wird, die die Zeit von der Offenlegung einer Schwachstelle bis zum Angriff verkürzt. Parallel läuft eine Welle von Startseiten-Defacements mit der Signatur „Hacked by AntonKill“: Joomla-Fachquellen bringen sie vor allem mit einer gesonderten Schwachstelle des Template-Frameworks Helix3 von JoomShaper (CVE-2026-49049) in Verbindung, über die Schadcode direkt in die Template-Parameter in der Datenbank eingeschleust wird. Die Schätzungen zur Zahl der infizierten Websites sind bislang ungefähr: Der Dienst mySites.guru etwa beobachtete Hunderte Auftritte, doch das ist die Schätzung einer einzigen Quelle, kein geprüftes Ergebnis.
Dabei geschehen die meisten realen Joomla-Hacks nach wie vor nicht über frische 0-days, sondern aus langweiligen Gründen: veralteter Kern und veraltete Erweiterungen, schwache oder wiederverwendete Administrator-Passwörter (die Zwei-Faktor-Authentifizierung gibt es in Joomla, ist aber standardmäßig deaktiviert), raubkopierte (nulled) Templates und Komponenten mit bereits eingebautem Backdoor sowie geleakte Zugänge zu Hosting, FTP und Datenbank. Nach Einschätzung von Sucuri entfällt der Großteil der CMS-Hacks gerade auf verwundbare Dritt-Erweiterungen und nicht auf den Kern selbst. Gesondert erwähnt sei die alte, aber immer noch aktiv gescannte Kern-Schwachstelle von Joomla 4.x, CVE-2023-23752, ein Leck von Datenbank-Login und -Passwort über die API, das bereits in 4.2.8 geschlossen wurde.
Ein Schlüsselpunkt, der oft unterschätzt wird: Die Installation eines Updates schließt den Eingang, entfernt aber NICHT, was der Angreifer bereits hinterlassen hat. Web-Shells, gefälschte Super-Administratoren, schädliche Einträge in .htaccess und Aufgaben in cron arbeiten auch nach dem Patch weiter. Deshalb muss eine Website, die im Juni oder Juli 2026 auch nur kurz eine verwundbare Version einer Erweiterung ausgeführt hat, nicht einfach aktualisiert, sondern vollständig bereinigt und auf Verankerung geprüft werden: Nach Beobachtungen von Google infiziert sich ein beträchtlicher Teil der gehackten Websites schon innerhalb eines Tages erneut, wenn das ursprüngliche Leck nicht geschlossen wird.
Erweiterungs-Schwachstellen, die Hauptursache 2026
Kritische Lecks (CVSS bis 10.0) mit nicht authentifiziertem PHP-Upload in JCE, SP Page Builder, iCagenda und Page Builder CK. Die Exploits sind öffentlich, die Angriffe laufen per Bots.
Veralteter Kern und veraltete Komponenten
Nach Einschätzung von Sucuri entfällt der Großteil der CMS-Hacks auf nicht aktualisierte Dritt-Erweiterungen. Dazu die immer noch gescannte alte Kern-Schwachstelle von Joomla 4.x, CVE-2023-23752.
Schwache und geleakte Zugänge
Einfache oder wiederverwendete Passwörter, fehlende 2FA, geleakte Zugänge zu Hosting, FTP und Datenbank. Ein klassischer Vektor, der keinerlei 0-day braucht.
Raubkopierte Templates und Erweiterungen
Nulled-Builds von Premium-Templates und -Komponenten aus unseriösen Quellen kommen oft mit bereits eingebautem Backdoor, das sich sofort nach der Installation aktiviert.
Automatisierung und Masse
Das ACSC warnte am 9. Juli 2026 vor einer globalen Kampagne mit massenhaftem CMS-Scanning und der Installation von Web-Shells, möglicherweise beschleunigt durch KI. Das Ziel wird per Durchprobieren gewählt, nicht von Hand.
Patch ist nicht gleich Bereinigung
Das Update schließt den Eingang, entfernt aber nicht die bereits hinterlassenen Web-Shells, gefälschten Admins, Änderungen in .htaccess und cron. Ohne die Verankerung zu schließen, wird die Website schnell erneut infiziert.
Betroffene Erweiterungen 2026 (prüfen und aktualisieren): JCE bis 2.9.99.5+, SP Page Builder bis 6.6.2+, iCagenda bis 4.0.8 / 3.9.15+, Page Builder CK bis 3.6.0+, Helix3 (JoomShaper) gemäß CVE-2026-49049. Daten laut NVD und CISA-KEV-Katalog. Ein Update ist zwingend, aber allein nicht ausreichend: Die Website muss zusätzlich auf bereits installierte Web-Shells und Backdoors geprüft werden.
Wie die Wiederherstellung abläuft
Transparente Reihenfolge der Arbeiten. Nicht einfach „bereinigt und weg“: Wichtig ist, nicht nur die Symptome, sondern auch die Ursache zu beseitigen, sonst wird die Website über dasselbe Leck erneut infiziert.
Diagnose und Sicherung
Ich prüfe die Website mit Remote-Scannern und auf dem Server, sehe mir Search Console, Safe Browsing und schwarze Listen an und bestimme den Infektionstyp. Ich erstelle eine Kopie des aktuellen Zustands und der Logs als Beweismittel. Die Logs kopiere ich zuerst.
Suche der Eintrittsstelle über die Logs
Ich untersuche die Zugriffsprotokolle: Ich suche POST-Anfragen an verwundbare Erweiterungs-Tasks, untypische Uploads und den Zeitpunkt des ersten Eindringens. So verstehe ich, worüber genau sie hereinkamen.
Abgleich mit sauberem Kern
Ich lade das offizielle saubere Joomla-Paket Ihrer Version herunter und vergleiche es mit der Live-Website, gesondert suche ich kürzlich geänderte Dateien. Das deckt Injektionen in Kern, Template und index.php auf.
Bereinigung von Dateien und Datenbank
Ich entferne eingeschleusten Code aus Dateien und DB-Tabellen: Ich suche eval, base64_decode, gzinflate, exec, Injektionen in index.php und Template-Parameter. Wenn möglich ersetze ich infizierte Dateien durch Originale, statt von Hand zu editieren.
Suche und Schließen aller Backdoors
Der Schlüsselschritt. Ich durchkämme media, images, tmp und untypische Ordner nach Web-Shells, prüfe .htaccess in allen Verzeichnissen und die Planer-Aufgaben auf sich selbst wiederherstellende Einträge. Ein einziger übersehener Backdoor bedeutet einen schnellen erneuten Hack.
Saubere Neuinstallation und Updates
Ich installiere den Joomla-Kern aus dem sauberen Paket neu, aktualisiere Erweiterungen und Templates aus offiziellen Quellen und entferne verwundbare, ungenutzte und unbekannte Komponenten anhand der Liste verwundbarer Joomla-Erweiterungen (VEL).
Zugänge wechseln und fremde Admins entfernen
Erst nach der Bereinigung entferne ich gefälschte Super-Administratoren, ändere alle Passwörter, Zugänge zu DB, FTP/SSH und Hosting, rotiere das Geheimnis in configuration.php und die API-Schlüssel. Die Reihenfolge ist wichtig: Solange Backdoors bestehen, ist ein Passwortwechsel nutzlos.
Prüfung und Aufheben der Warnungen
Ich scanne die Website erneut und stelle sicher, dass es keinen Schadcode und keine fremden ausgehenden Anfragen gibt. Ich beantrage eine erneute Überprüfung in der Google Search Console und im Yandex.Webmaster und bitte den Hoster, die Sperrung aufzuheben.
Was Sie erhalten
Das Ergebnis ist nicht einfach „die Website öffnet wieder“, sondern eine saubere, aktualisierte und geschützte Website plus das Verständnis, was passiert ist.
Saubere funktionierende Website
Ohne Web-Shells, Redirects, Spam-Seiten und Defacement, geprüft mit Remote- und Server-Scanner.
Geschlossene Eintrittsstelle
Aktualisierter Kern und aktualisierte Erweiterungen, beseitigte Schwachstelle, durch die sie hereinkamen, damit sich der Hack nicht auf demselben Weg wiederholt.
Sicherungskopie vor der Bereinigung
Vollständiger Snapshot des gehackten Zustands und der Logs, gesondert gespeichert für den Fall einer Klärung oder strittiger Punkte.
Infektionsbericht
Eine verständliche Beschreibung: was gefunden wurde (Dateien, Backdoors, fremde Admins), wo das Leck war, was entfernt und was geändert wurde.
Aktualisierte Zugänge
Wechsel der Passwörter von Administratoren, DB, FTP/SSH und Hosting, Rotation der Geheimnisse in configuration.php und der API-Schlüssel.
Anträge auf erneute Überprüfung
Anträge auf Aufhebung der Warnungen in der Google Search Console und im Yandex.Webmaster, bei Bedarf eine Anfrage an den Hoster zur Aufhebung der Sperrung.
Grundlegende Härtung des Schutzes
Aktivierte 2FA für Admins, eingeschränkter Zugang zum Panel, Verbot der PHP-Ausführung in Upload-Ordnern und weitere Maßnahmen nach der Bereinigung.
Empfehlungen für die Zukunft
Eine kurze Checkliste zu Updates, Sicherungskopien und Monitoring, um das Risiko einer erneuten Infektion zu senken.
Formate der Arbeiten und Fristen
Ich wähle das Format je nach Situation: von der dringenden Rückkehr der Website in den Betrieb bis zur vollständigen Wiederherstellung mit Schutz und Monitoring.
| Format | Wann sinnvoll | Was enthalten ist | Frist |
|---|---|---|---|
| Notfall-Bereinigung Website dringend zurückholen |
Die Website ist infiziert oder leitet um, sie muss schnell wieder in den Betriebszustand. | Suche und Entfernung des Schadcodes, Aufheben von Redirects und Spam, grundlegendes Schließen des Eingangs. | ab wenigen Stunden |
| Vollständige Wiederherstellung und Schutz Bereinigung + Vorbeugung |
Die Infektion beseitigen und einen erneuten Befall verhindern. | Alles aus dem Notfallpaket plus sauberer Kern, Updates, Zugangswechsel, Aufheben der Warnungen, Schutz und Backups. | 1-5 Tage |
| Wiederherstellung aus Backup oder Neuaufbau schwere Fälle |
Die Website ist stark beschädigt und eine Sicherungskopie fehlt oder ist ebenfalls infiziert. | Bereitstellung einer sauberen Kopie oder Neuaufbau auf sauberem Kern mit Übernahme der Inhalte. | nach Umfang |
| Monitoring und Schutz Abonnement |
Die Website nach der Bereinigung unter Beobachtung halten. | Monitoring, Updates, Backups, schnelle Reaktion auf Vorfälle. | monatlich |
* Den genauen Preis nenne ich nach der kostenlosen Diagnose: Er hängt vom Infektionstyp, der Größe der Website und dem Zustand der Sicherungskopien ab. Die Arbeiten beginne ich erst nach Abstimmung des Kostenvoranschlags.
Schutz nach der Bereinigung
Bereinigen allein reicht nicht: Wichtig ist, den Eingang zu schließen und das Risiko einer Wiederholung zu senken. Was ich im Rahmen der vollständigen Wiederherstellung einrichte.
- Ich aktiviere die Zwei-Faktor-Authentifizierung (2FA) für alle Super-Administratoren, in Joomla ist sie standardmäßig deaktiviert.
- Ich beschränke den Zugang zum Ordner /administrator per IP oder Passwort auf Ebene des Webservers.
- Ich deaktiviere die PHP-Ausführung in den Upload-Ordnern (media, images, tmp), damit eine hochgeladene Datei nicht zu einer funktionierenden Shell wird.
- Ich vergebe starke, eindeutige Passwörter für Admins, DB, FTP/SSH und Hosting und beende die Wiederverwendung.
- Ich schließe den nicht authentifizierten Zugriff auf den Konfigurations-API-Endpunkt auf Server- oder Cloudflare-Ebene.
- Ich entferne ungenutzte und unbekannte Erweiterungen und Templates, behalte nur das Nötige und aktualisiere aus offiziellen Kanälen.
- Ich verzichte auf raubkopierte (nulled) Templates und Komponenten und installiere nur aus geprüften Quellen.
- Ich richte regelmäßige Sicherungskopien außerhalb des Servers mit Wiederherstellungstest ein und bei Bedarf eine WAF vor der Website.
Häufige Fragen
Ihre Frage nicht dabei? Schreiben Sie in Telegram, ich antworte konkret zu Ihrem Fall.
Was kostet die Website-Wiederherstellung nach einem Hack?
Das hängt vom Umfang der Infektion ab: einen einzelnen Injekt in index.php zu bereinigen ist eine Sache, eine Website mit einem Dutzend Backdoors und gefälschten Administratoren auseinanderzunehmen eine ganz andere. Deshalb beginne ich mit der Diagnose: Ich prüfe das Ausmaß und nenne einen klaren Preis vor Arbeitsbeginn, ohne Überraschungen unterwegs.
Wie lange dauert die Wiederherstellung?
Einfache Fälle (ein Redirect oder Injekt) erledige ich oft in wenigen Stunden oder an einem Tag. Schwere Infektionen mit mehrfacher Verankerung und dem Aufheben von Google-Warnungen können mehrere Tage dauern. Nach der Diagnose gebe ich eine realistische Einschätzung für Ihre Website.
Kann ich Daten verlieren?
Als Erstes erstelle ich eine vollständige Sicherungskopie des aktuellen Zustands und arbeite damit, nicht blind an der laufenden Website. Inhalte und Einstellungen versuche ich vollständig zu erhalten. Ein Risiko besteht nur dort, wo der Schadcode Dateien physisch überschrieben hat, und darauf weise ich vorab hin.
Geben Sie eine Garantie, dass der Hack nicht zurückkommt?
Ehrlich: Niemand kann im Web eine 100%-Garantie geben. Aber ich schließe nicht nur die Symptome, sondern die Eintrittsstelle selbst und die gesamte Verankerung (Backdoors, .htaccess, cron), denn gerade wegen eines übersehenen Lecks infiziert sich ein Teil der Websites schon innerhalb eines Tages erneut. Zusätzlich verstärke ich den Schutz, damit der bisherige Weg nicht mehr funktioniert.
Brauchen Sie Zugänge zur Website?
Ja, für eine vollständige Bereinigung brauche ich Zugänge zum Hosting oder FTP/SSH und zum Joomla-Backend, manchmal zur Datenbank. Ein Remote-Scanner sieht nur das Frontend und übersieht serverseitige Backdoors, deshalb lässt sich ein Hack ohne Dateizugriff nicht sauber beheben. Alle Zugänge ändern Sie nach der Arbeit.
Reicht es, Joomla und die Erweiterungen einfach zu aktualisieren?
Nein. Das Update schließt den Eingang, entfernt aber nicht, was der Angreifer bereits hinterlassen hat: Web-Shells, fremde Administratoren, Änderungen in .htaccess und cron-Aufgaben arbeiten auch nach dem Patch weiter. Deshalb ist das Update ein Pflichtschritt, aber nicht der einzige.
Und wenn ich einfach ein Backup zurückspiele?
Vorsicht: Die offizielle Joomla-Dokumentation warnt ausdrücklich, dass ein Rollback oft einfach den Hack zurückbringt, weil die Infektion zusammen mit der Website in die Sicherungskopie gelangt sein kann. Zurückspielen sollte man nur eine Kopie, die nachweislich vor dem Hack erstellt und auf Sauberkeit geprüft wurde. In allen anderen Fällen ist eine saubere Neuinstallation zuverlässiger.
Arbeiten Sie mit WordPress und anderen CMS?
Meine Hauptspezialisierung ist Joomla, hier kenne ich die Feinheiten von Templates, Komponenten und typischen Verankerungsstellen. Die allgemeinen Prinzipien der Bereinigung (Suche nach Backdoors, Schließen des Lecks, Aufheben der Warnungen) gelten auch für WordPress, dort kann ich in einfachen Fällen helfen, am tiefsten arbeite ich aber mit Joomla.
Verwandte Leistungen
Ein Hack ist oft die Folge einer veralteten Website. Manchmal ist es günstiger und zuverlässiger, Altes nicht zu flicken, sondern auf sauberer Basis neu zu bauen.
Website gehackt? Beginnen wir mit einer kostenlosen Diagnose
Beschreiben Sie die Situation: Was passiert mit der Website, auf welchem CMS läuft sie und gibt es Zugänge? Ich schaue nach, bestimme den Infektionstyp und die Eintrittsstelle und sage Ihnen, was in welchen Fristen zu tun ist. Ohne Verpflichtung, weiter zu beauftragen.