Gehackter Inhalt: was wirklich passiert, wenn die Plattform selbst kompromittiert wird, nicht ein Inserent
Das erste Anzeichen kommt selten von offizieller Stelle. Es sind ein paar merkwuerdige URLs in der Search Console, an deren Erstellung sich niemand im Team erinnert, oder organischer Traffic, der ohne erkennbaren Grund in den ueblichen Dashboards einbricht, oder ein Inserent, der schreibt und fragt, warum seine Anzeigenseite auf etwas weiterleitet, das nichts mit der Seite zu tun hat. Manchmal meldet ein Besucher, dass der Browser sich geweigert hat, die Seite zu oeffnen. Nichts davon sieht nach Betrug durch einen Inserenten aus, und nichts aehnelt dem Fall einer boeswilligen Anzeige, der eine Seite markieren laesst, ohne dass ihr eigener Code irgendetwas damit zu tun hat.
Das ist der andere Fall, und es ist ein anderes Problem mit einer anderen Loesung. Hier wurde tatsaechlich etwas zu den Dateien oder der Datenbank der Seite hinzugefuegt, ohne dass jemand im Team es dort platziert hat. Ein Verzeichnis dieser Kategorie kann es sich nicht leisten, auch nur eine Woche lang unzuverlaessig zu wirken: nicht gegenueber Google, nicht gegenueber einem Zahlungsdienstleister, der die Branche ohnehin schon als risikoreicher als den Durchschnitt behandelt, nicht gegenueber einem Hoster, der moeglicherweise nur eine Beschwerde von der Kontosperrung entfernt ist. Genau zu wissen, was passiert ist, was Google tatsaechlich prueft und in welcher Reihenfolge die Loesung wirklich funktioniert, ist hier mehr wert als beim Blog eines gewoehnlichen Kleinunternehmens, weil die Kosten einer falschen Reihenfolge hoeher sind.
Wie ein Angreifer tatsaechlich eindringt, und das ist selten spektakulaer
Auf dieser Ebene zielt fast niemand gezielt auf ein Erwachsenen-Kleinanzeigenverzeichnis. Das uebliche Muster ist ein Bot, der das offene Web nach jeder Seite durchsucht, die eine bestimmte Software mit einer bekannten, ungepatchten Schwachstelle einsetzt, genauso wie er Restaurantseiten oder Anwaltskanzlei-Blogs durchsucht. Die Seite wird getroffen, weil sie zufaellig dasselbe CMS, dasselbe Plugin oder dieselbe veraltete Bibliothek wie eine Million anderer Seiten nutzt, nicht weil jemand sie beobachtet und entschieden hat, dass sie den Aufwand wert ist.
Veraltete Software ist ein realer und haeufiger Faktor, aber sie ist nicht die ganze Geschichte, und sie als die ganze Geschichte zu behandeln, laesst die Haelfte der tatsaechlichen Einfallstore ungeschuetzt. Der Hacked-Website-Report von Sucuri, der Seiten betrifft, die 2023 bereinigt wurden, fand heraus, dass 39,1% der kompromittierten CMS-Installationen zum Zeitpunkt der Infektion veraltete Software liefen, ein Rueckgang gegenueber 50,58% im Vorjahr. Derselbe Bericht fand, dass nur etwa 14% dieser Seiten noch ein identifizierbares verwundbares Plugin oder Theme hatten, sobald Sucuri die Bereinigung genauer untersuchte. Mit anderen Worten: Die meisten der bereinigten Seiten wurden nicht tatsaechlich ueber die Softwareluecke gehackt, die ein Betreiber erwarten wuerde zuerst beheben zu muessen.
Die andere Haelfte des Bildes sind Zugangsdaten. Der Data Breach Investigations Report 2025 von Verizon, der alle verfolgten Branchen betrachtet und nicht nur Websites, fand gestohlene oder erratene Zugangsdaten knapp vor ausgenutzten Softwareschwachstellen als die Methode, mit der Angreifer ihren ersten Zugriff erlangen: 22% der Verstoesse gegenueber 20%. Es ist keine Zahl, die ausschliesslich aus Kleinanzeigenseiten gebildet wurde, aber sie deckt sich mit dem, was Sucuri bei Bereinigungen speziell auf CMS-Plattformen sieht. Ein Admin-Passwort, das von einem privaten E-Mail-Konto wiederverwendet wird, das Jahre zuvor bei einem unabhaengigen Vorfall geleakt wurde, ist in der Praxis etwa genauso wahrscheinlich der Weg hinein wie ein ungepatchtes Plugin.
Die praktische Konsequenz ist, dass die Absicherung einer Seite zwei etwa gleich gewichtete Aufgaben sind, nicht eine. Ein Patch-Zeitplan schliesst die Haelfte der Softwareluecken. Eine getrennte Disziplin dazu, wer einen Zugang hat, wie dessen Passwort tatsaechlich lautet und ob es anderswo wiederverwendet wird, schliesst die andere Haelfte. Ein Betreiber, der nur Plugins aktuell haelt, hat die Haelfte der Arbeit erledigt und merkt es vielleicht nie, weil der Warnbildschirm identisch aussieht, unabhaengig davon, welche Haelfte uebersprungen wurde.
Wie Google das tatsaechlich nennt, und warum es ein anderes Problem als eine boeswillige Anzeige ist
Eine andere Art von Chrome-Warnung wurde hier bereits behandelt: jene, bei der ein beauftragtes Werbenetzwerk ueber die eigenen Werbeplaetze der Seite ein taeuschendes oder boeswilliges Creative ausspielt und Google die Seite fuer Inhalte markiert, die sie nie beruehrt hat. Das ist nicht dieser Fall. Hier wurde etwas zu den Seiten oder der Datenbank der Website hinzugefuegt, ohne dass der Betreiber davon wusste, und genau das definieren Googles Spam-Richtlinien als gehackten Inhalt: Inhalt, der ohne Erlaubnis des Eigentuemers auf einer Seite platziert wird, aufgrund einer Schwachstelle in der eigenen Sicherheit der Seite.
Googles Dokumentation unterscheidet drei konkrete Muster. Code-Injection ist boeswilliger Code, meist JavaScript, der direkt in bereits bestehende Seiten oder iFrames eingefuegt wird. Page-Injection sind neue, zuvor nicht vorhandene Seiten, die auf der Website hinzugefuegt werden, um das Suchranking zu manipulieren oder einen Phishing-Versuch zu starten, waehrend die Seiten, die ein Besucher bereits kannte, oft keine sichtbaren Anzeichen dafuer zeigen, dass etwas nicht stimmt. Content-Injection ist noch subtiler: versteckter Text oder versteckte Links, die ueber CSS- oder HTML-Tricks zu bestehenden Seiten hinzugefuegt werden, sichtbar fuer den Crawler einer Suchmaschine, aber nicht fuer eine Person, die dieselbe Seite im Browser betrachtet.
Page-Injection ist normalerweise das Muster, das Betreiber zuletzt entdecken, und es lohnt sich zu verstehen, warum ein Angreifer sich diese Muehe macht, statt einfach eine eigene Wegwerf-Seite zu bauen. Eine Domain, die bereits eine Historie, bestehende Backlinks und eine etablierte Position in den Suchergebnissen hat, waescht Spam-Inhalte weit schneller ins Ranking als es eine brandneue Domain tun wuerde, weshalb Angreifer lieber die Reputation einer bestehenden Seite ausleihen als ihre eigene von Grund auf aufzubauen. Das ist ein anderer Mechanismus als der an anderer Stelle behandelte externe Linkangriff: dort richtet der Angriff Links von anderen Seiten von aussen auf das Ziel; hier sind die Spam-Seiten so gebaut, dass sie auf der eigenen Domain des Ziels existieren, innerhalb seiner eigenen Dateistruktur.
Sobald dieser Inhalt auf der Seite existiert, haeufen sich die Folgen. Der Sicherheitsprobleme-Bericht der Search Console markiert die Property direkt, manche Seiten koennen aus den Ergebnissen entfernt oder in der Auflistung durch eine Warnung ersetzt werden, und Googles Safe Browsing kann Besuchern dieselbe rote Zwischenseite anzeigen, die bereits fuer den Fall des Werbenetzwerks beschrieben wurde, diesmal ausgeloest, weil die Seite tatsaechlich boeswilligen oder taeuschenden Inhalt hostet, nicht durch ein fehlerhaftes Creative, das sie durchlaeuft.
Die Warnung entfernen lassen: die Reihenfolge, die wirklich funktioniert
Googles eigene Anleitung ist bei der Reihenfolge konkret, und der groesste Teil der in der Praxis verlorenen Zeit entsteht dadurch, diese Schritte in falscher Reihenfolge auszufuehren. Die erste Aufgabe ist, jede Instanz des eingeschleusten Inhalts zu finden und zu entfernen, nicht nur die Beispielseite, die die Search Console als Beispiel fuer das Problem genannt hat. Diese URL ist ein Stichprobenbeispiel, kein Inventar, und eine Bereinigung, die nach deren Behebung endet, laesst meist den Grossteil der eigentlichen Injektion bestehen.
Die zweite Aufgabe ist herauszufinden, wie der Angreifer eingedrungen ist, und genau dieses Loch zu schliessen, sei es ein ungepatchtes Plugin, eine geleakte Zugangsdatei oder eine falsch konfigurierte Berechtigung, denn das Loeschen der Spam-Seiten ohne Behebung des Einstiegspunkts setzt die Uhr lediglich zurueck, bis derselbe Angreifer oder derselbe automatisierte Scan durch dieselbe Tuer zurueckkehrt. Googles Dokumentation ist eindeutig, dass die Korrektur die gesamte Seite abdecken muss, nicht nur die Startseite oder die Seite, die ein Besucher gemeldet hat, und ein verwandter Teil derselben Anleitung empfiehlt, jedes Passwort zu aendern, das mit einem Konto mit Administratorzugriff verbunden ist: den CMS-Login, das Hosting-Kontrollpanel, FTP oder SFTP und die Datenbank, genau weil der Einstiegspunkt oft eines davon ist und nicht die Seite, auf der das Symptom sichtbar wurde.
Der Teil, den Betreiber am haeufigsten vertauschen, ist der Zeitpunkt, zu dem Google um eine erneute Pruefung gebeten wird. Eine Ueberpruefung anzufordern, bevor die oben beschriebene Bereinigung tatsaechlich abgeschlossen ist, beschleunigt nichts; Google sagt klar, dass eine Ueberpruefung anzufordern, waehrend das Problem noch besteht, die Zeit, in der die Seite markiert bleibt, nur verlaengert. Die Pruefungsdauer variiert je nach Kategorie: eine Pruefung fuer einfache Malware dauert meist wenige Tage, eine Phishing-Pruefung etwa einen Tag, aber eine Pruefung von gehacktem Inhalt mit eingeschleusten Spam-Seiten kann bis zu mehreren Wochen dauern, weil Google diese Kategorie als eine behandelt, die eine tatsaechlich manuelle Durchsicht statt einer automatisierten Nachpruefung erfordern kann.
Eine zweite Runde derselben Warnung, nachdem eine Pruefung bereits bestanden wurde, ist meist ein Zeichen dafuer, dass der Einstiegspunkt beim ersten Mal nie wirklich geschlossen wurde, nur das Symptom. Das Loeschen der sichtbaren Spam-Seiten fuehlt sich wie erledigte Arbeit an, aber wenn das verwundbare Plugin noch da ist oder das geleakte Passwort noch funktioniert, wird dasselbe Loch wieder benutzt, manchmal innerhalb weniger Tage nach Aufhebung der Warnung.
Was das wirklich verhindert, mit einem Budget, das dieses Geschaeft tragen kann
Nichts davon erfordert die Einstellung eines dedizierten Sicherheitsteams, und Betreiber, die die Grundlagen ueberspringen, tun das meist, weil die Liste laenger klingt, als sie tatsaechlich ist. Das CMS, sein Theme und jedes installierte Plugin brauchen einen festen Update-Zeitplan, woechentlich geprueft statt "wenn Zeit ist", und alles, was einmal installiert und nicht mehr genutzt wird, sollte komplett entfernt statt ruhend gelassen werden, denn ein inaktives Plugin bleibt eine nie verschlossene Tuer.
Die Zugangsdaten-Disziplin wiegt genauso schwer wie Patches, angesichts dessen, was die oben genannten Sucuri- und Verizon-Zahlen tatsaechlich zeigen. Das bedeutet ein eindeutiges Passwort fuer jedes Konto, das die Seite beruehren kann, generiert und in einem Passwort-Manager gespeichert statt im Gedaechtnis, Zwei-Faktor-Authentifizierung aktiviert bei jedem Login, der sie anbietet, und keine geteilten Logins, die zwischen Mitarbeitenden oder Moderatoren herumgereicht werden, da ein geteilter Login auch ein Zugang ist, den niemand auf eine bestimmte Person zurueckfuehren kann, wenn etwas schiefgeht.
Backups sind genauso wichtig wie Vorbeugung, denn sie sind es, was eine Seite in Stunden statt nach wochenlangem Warten auf eine Google-Pruefung wieder online bringt. Ein Backup, das auf demselben Hosting-Konto liegt wie die Seite, die es schuetzen soll, ist kein besonders gutes Backup, da ein Angreifer mit Admin-Zugang in der Regel auch darauf zugreifen kann; eine Kopie, die anderswo gespeichert und tatsaechlich durch mindestens eine Wiederherstellung getestet wird, statt unverifiziert zu laufen, ist der Unterschied zwischen einer schlechten Woche und einem schlechten Monat.
Das letzte Element ist einfach, es frueh zu erfahren. Die E-Mail-Benachrichtigungen der Search Console bringen den Sicherheitsprobleme-Bericht in ein Postfach, das jemand tatsaechlich liest, statt dass der Betreiber das Problem durch die Beschwerde eines Besuchers oder einen langsamen Rueckgang des organischen Traffics Tage oder Wochen spaeter entdeckt. Keiner dieser Schritte kostet mehr als Zeit, und alle sind guenstiger, jetzt erledigt, als nachdem der Warnbildschirm bereits eine Woche Traffic gekostet hat, waehrend die Bereinigung sortiert wird.
Die Reihenfolge, wenn die Warnung bereits erschienen ist: zuerst alles bereinigen, das konkrete Loch schliessen, das sie ermoeglicht hat, und erst dann Google um eine erneute Pruefung bitten, nie umgekehrt. Die Reihenfolge, wenn noch nichts passiert ist: trotzdem dieselben vier Dinge diese Woche auf einem Kalender erledigen: patchen, was installiert ist, jedes Passwort mit Administratorzugriff aendern, Zwei-Faktor-Authentifizierung ueberall aktivieren, wo sie angeboten wird, und eine echte Wiederherstellung aus dem Backup testen. So oder so ging es bei der Loesung nie um die Jurisdiktion des Zertifikats oder die Groesse der beauftragten Anwaltskanzlei: Es geht darum, wer sich einloggen kann, wie aktuell die Software ist, und ob es jemand rechtzeitig bemerken wuerde.
