{"id":103,"date":"2026-01-13T00:00:00","date_gmt":"2026-01-12T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/de\/wordpress-malware-googlebot-ip-verifiziertes-cloaking\/"},"modified":"2026-01-20T06:32:38","modified_gmt":"2026-01-20T05:32:38","slug":"wordpress-malware-googlebot-ip-verifiziertes-cloaking","status":"publish","type":"post","link":"https:\/\/helloblog.io\/de\/wordpress-malware-googlebot-ip-verifiziertes-cloaking\/","title":{"rendered":"WordPress-Malware, das Googlebot gezielt kapert: Warum IP-verifiziertes Cloaking so schwer zu entdecken ist"},"content":{"rendered":"\n

\u201eGoogle sieht etwas anderes als du\u201c ist kein neues Muster \u2013 aber die Umsetzung wird technisch zunehmend raffinierter. In einem aktuellen Incident wurde Schadcode direkt in der zentralen index.php<\/code> einer WordPress-Installation gefunden, der nur<\/strong> f\u00fcr legitime Google-Crawler (Googlebot & Co.) eine externe Payload nachl\u00e4dt. Normale Besucher:innen \u2013 inklusive Website-Betreiber \u2013 bekommen weiterhin die saubere Seite ausgeliefert. Genau diese Selektivit\u00e4t macht die Infektion so gef\u00e4hrlich: Sie schadet vor allem deiner Suchsichtbarkeit und bleibt gleichzeitig im Alltag unsichtbar.<\/p>\n\n\n\n

\"Schema:
. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

Worum geht\u2019s bei dieser Angriffstechnik?<\/h2>\n\n\n\n

Statt klassischer \u201ealle Besucher werden umgeleitet\u201c-Malware setzen Angreifer vermehrt auf selektive Content Injection<\/strong>: Der kompromittierte Entry-Point entscheidet zur Request-Zeit, welche Version der Seite ausgeliefert wird. Das Ziel ist typischerweise SEO-Manipulation<\/strong> (Cloaking): Suchmaschinen sollen Spam-\/Doorway-Inhalte sehen und indexieren, w\u00e4hrend echte Nutzer:innen das legitime Frontend sehen.<\/p>\n\n\n\n

Im untersuchten Fall sa\u00df der Schadcode in der WordPress-index.php<\/code> und agierte als eine Art Gatekeeper: Entweder startet er WordPress normal (saubere Ausgabe) \u2013 oder er holt fremden Content von au\u00dfen und gibt ihn direkt aus.<\/p>\n\n\n\n

\"Diagramm:
. \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

Was ist hier das Neue: IP- und ASN-verifiziertes Cloaking<\/h2>\n\n\n\n

Viele Cloaking-Skripte filtern billig \u00fcber den User-Agent<\/code> (also den Header, der Browser\/Client identifiziert). Das Problem f\u00fcr Angreifer: Den kann man trivially spoofen. Der hier beobachtete Code geht deutlich weiter und pr\u00fcft zus\u00e4tzlich, ob die anfragende IP tats\u00e4chlich zu Googles Infrastruktur geh\u00f6rt.<\/p>\n\n\n\n

Dazu war im Schadcode eine umfangreiche, hart kodierte Liste von Google-ASN-IP-Ranges<\/strong> im CIDR-Format<\/strong> enthalten.<\/p>\n\n\n\n

    \n\n
  • ASN (Autonomous System Number):<\/strong> eine Art \u201eNetz-Identit\u00e4t\u201c eines gro\u00dfen Providers\/Unternehmens. Wenn Traffic aus Googles ASN kommt, spricht das stark daf\u00fcr, dass er aus Googles echter Infrastruktur stammt (z. B. f\u00fcr Search-Crawler, Cloud, etc.).<\/li>\n\n\n
  • CIDR (Classless Inter-Domain Routing):<\/strong> kompakte Schreibweise f\u00fcr IP-Netzbl\u00f6cke, z. B. 192.168.1.0\/24<\/code> f\u00fcr 256 IPv4-Adressen. Das ist Standard, um IP-Ranges effizient zu beschreiben.<\/li>\n\n<\/ul>\n\n\n\n
    \"Beispielgrafik:
    . \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

    Warum das so schwer zu finden ist (auch f\u00fcr erfahrene Admins)<\/h2>\n\n\n\n

    Der Trick ist die Kombination aus mehrstufiger Bot-Erkennung<\/strong> und mathematisch exakter IP-Range-Pr\u00fcfung<\/strong>. Das bedeutet: Selbst wenn du mit \u201eGooglebot\u201c-User-Agent testest, bekommst du nicht automatisch die Spam-Ansicht \u2013 weil die IP nicht passt. Ergebnis: Manuelles Browsing, Staging-Checks oder \u201emal schnell curlen\u201c zeigen nichts Auff\u00e4lliges.<\/p>\n\n\n\n

    \"Screenshot:
    . \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

    Technischer Ablauf: So arbeitet der Schadcode in der index.php<\/h2>\n\n\n\n

    Auf hoher Ebene l\u00e4sst sich die Logik in f\u00fcnf Bausteine zerlegen \u2013 wichtig ist dabei weniger der genaue Code als das Muster: Eintrittspunkt kompromittiert, Identit\u00e4t gepr\u00fcft, Payload nachgeladen, Ausgabe manipuliert, Erfolg protokolliert.<\/p>\n\n\n\n

    1) Mehrschichtige Identit\u00e4tspr\u00fcfung (User-Agent + IP)<\/h3>\n\n\n\n

    Zuerst schaut das Skript auf HTTP_USER_AGENT<\/code> und sucht nach typischen Google-Strings. Weil dieser Header leicht f\u00e4lschbar ist, folgt dann eine IP-Verifikation gegen Google-IP-Ranges. Das ist das zentrale Qualit\u00e4tsmerkmal dieser Variante: Nur \u201eechte\u201c Google-Infrastruktur soll die Payload sehen.<\/p>\n\n\n\n

    \"Diagramm:
    . \u2014 Forr\u00e1s: Sucuri Blog<\/em><\/figcaption><\/figure>\n\n\n\n

    2) Bitweises IP-Range-Matching statt String-Vergleich<\/h3>\n\n\n\n

    F\u00fcr das IP-Matching wurde nicht einfach \u201eIP beginnt mit \u2026\u201c genutzt, sondern eine klassische Netzblock-Pr\u00fcfung per bitwise operations<\/strong> (Bitoperationen). F\u00fcr IPv4 ist das typische Prinzip:<\/p>\n\n\n\n

    <\/circle><\/circle><\/circle><\/g><\/svg><\/span>