Google Ads mit Claude-Links verbreiten potenzielle Malware
Stellen Sie sich vor, Sie suchen nach einem beliebten Open-Source-Paketmanager für macOS und geben bei Google etwas wie „brew macOS“ ein. Ganz oben in den Suchergebnissen erscheint ein gesponserter Link, der angeblich von Google verifiziert wurde. Die Domain sieht vertrauenswürdig aus — sie gehört einem bekannten KI-Unternehmen, zum Beispiel Anthropic, dessen Tools Sie möglicherweise bereits in Ihrer täglichen Arbeit verwenden. Alles scheint in Ordnung. Es gibt keine auffälligen Tippfehler, keine verdächtige URL — alles wirkt seriös.
Sie klicken darauf.
Die Seite erklärt, wie Sie Homebrew installieren können, einen beliebten Paketmanager. Die Formulierung ist technisch, aber auch selbstbewusst und vertraut. Sie folgt sogar der tatsächlichen Installationsmethode: ein einzelner Terminal-Befehl, der ein Setup-Skript herunterlädt und ausführt. Der Befehl sieht fast genauso aus wie der offizielle Befehl auf der Website von Homebrew brew.sh:
Er ruft
bashaufEr lädt ein entferntes Skript herunter
Er führt es sofort aus
Wenn Sie schon einmal Entwickler-Tools installiert haben, scheint das ganz normal zu sein — fast schon erwartet. Sie kopieren den Befehl ins Terminal und drücken Enter. Das Skript wird ausgeführt. Aber es ist nicht Homebrew.
Statt den offiziellen Installer von GitHub herunterzuladen, zieht das Skript heimlich eine schadhafte Payload von einem Server des Angreifers und führt sie aus. Zunächst passiert nichts Auffälliges, aber im Hintergrund ist Ihr Gerät nun kompromittiert.
Wenn Sie regelmäßig Homebrew verwenden, gehören Sie wahrscheinlich zu einer der folgenden Gruppen:
- Entwickler
- DevOps-Ingenieur
- Forscher jeder Art
- Power-User von macOS, der mit Code oder Infrastruktur arbeitet
Das bedeutet, dass Ihr Laptop nicht nur ein gewöhnliches persönliches Gerät ist — er könnte sensible Zugangsdaten enthalten, die als Einstiegspunkte für andere Systeme, Repositories oder Infrastrukturen dienen. Wenn Ihr Gerät SSH-Schlüssel, GitHub-Zugangstoken, Cloud-Zugangsdaten, VPN-Konfigurationen, API-Schlüssel, CI/CD-Geheimnisse oder Lese- und Schreibzugriff auf Repositories und Produktionsumgebungen speichert, hört eine Malware-Infektion nicht bei Ihrem Laptop auf. Ihr Gerät wird zu einem kompromittierten Einstiegspunkt — einer vergifteten Verbindung in einer viel größeren Kette.
Diese Malware kann möglicherweise Konfigurationsdateien auslesen, Authentifizierungstoken extrahieren und an einen entfernten Command-and-Control-Server übertragen. Mit den gestohlenen Zugangsdaten können Angreifer enormen Schaden anrichten. Das Ausmaß dessen ist nahezu unvorstellbar, und die Folgen können so verheerend sein, wie Sie sich vorstellen können.
Hier sind nur einige Szenarien, die keineswegs unrealistisch sind. Sobald Angreifer Ihre Zugangsdaten haben, könnten sie schadhafter Code in ein öffentliches oder privates Repository einschleusen. Wird dieser Code in einem gemeinsamen Projekt oder einer Bibliothek verwendet, könnte ein eigentlich harmloses Update zu einer verborgenen Bedrohung werden, die sich weiter verbreitet und irgendwann andere Projekte oder Personen erreicht.
Angreifer könnten sogar den Build-Prozess oder Release-Dateien manipulieren, sodass Software, die offiziell aussieht, heimlich kompromittiert wird. Sie könnten Versionen weit verbreiteter Pakete mit Backdoors veröffentlichen und Malware weit über das ursprüngliche Ziel hinaus verbreiten. Und wenn Angreifer Zugang zu Firmennetzwerken haben, könnten sie sich unbemerkt durch interne Systeme bewegen und sensible Datenbanken, private Server oder Produktionsumgebungen erreichen — alles begann mit diesem einen infizierten Laptop.
Wie Google Ads, die zu Claude-Links führen, giftig geworden sind
Sie haben wahrscheinlich schon erraten, dass das oben Beschriebene kein Produkt unserer Fantasie ist — kein Fiebertraum, auch wenn wir uns wünschen würden, es wäre so. Das ist tatsächlich passiert und hat potenziell Tausende von Menschen betroffen. Ab dem 11. Februar, als wir mit der Überwachung der Kampagne begannen, hatte eine der Seiten, die durch diese Anzeigen beworben wurden, bereits etwa 10.000 Klicks erhalten. Bis heute haben die beiden Seiten, die wir identifiziert haben, insgesamt etwa 25.000 Klicks (etwas über 20.000 auf der einen und 4.300 auf der anderen) laut ihren eigenen eingebauten Zählern. Die Anzahl der Anzeigenimpressionen war wahrscheinlich jedoch viel höher.
Der Angriff beeindruckt durch seine Einfachheit und das Ausmaß. So lief es in der Praxis, Schritt für Schritt:
Ein Angreifer erstellt ein öffentliches, benutzergeneriertes Artefakt auf
claude.aimit Anweisungen zur Installation von Homebrew.Die Seite folgt dem gleichen Installationsmuster wie die offiziellen Anweisungen, aber der Befehl wird durch einen base64-codierten ersetzt, der eine Payload von einem vom Angreifer kontrollierten Server herunterlädt und ausführt.
Der Angreifer kauft dann Google-Suchanzeigen, die auf Anfragen wie „brew macos“ oder „brew install“ abzielen.
Da der Anzeigenausschnitt die vertrauenswürdige
claude.ai-Domain anzeigt, ist es wahrscheinlicher, dass man dem Link vertraut und darauf klickt.Der Nutzer landet auf einer Seite, die wie eine offizielle Claude-Seite aussieht, aber tatsächlich benutzergenerierte Inhalte enthält, die vom Angreifer kontrolliert werden.
Der base64-codierte Befehl (wir haben festgestellt, dass er eine Botnet-bezogene URL enthält) lädt und führt sofort Remote-Code aus — eine klassische Malware-Bereitstellungstechnik. Alles geschieht unbemerkt vom Nutzer.
Es gab mehrere Seiten wie diese, die über Google Ads von verschiedenen Fake-Entitäten beworben wurden, mit einer kumulierten View-Zahl von etwa 25.000. Es ist unmöglich zu wissen, wie viele dieser Aufrufe tatsächlich zur Ausführung des Befehls führten, aber selbst ein kleiner Bruchteil davon wäre ausreichend, um erheblichen Schaden zu verursachen, angesichts des Zugriffs und der Berechtigungen, die typischerweise auf Entwicklermaschinen vorhanden sind.
Wichtig ist, dass diese Seiten nicht vom Claude-Team erstellt wurden. Sie waren benutzergenerierte Inhalte (UGC), die auf der Domain claude.ai gehostet wurden. Dennoch ist die Art und Weise, wie dieses UGC gehostet und präsentiert wird, ein Teil des Problems.
Das Platzieren benutzergenerierter Inhalte auf der Haupt-Second-Level-Domain (claude.ai) mag aus geschäftlicher oder SEO-Perspektive gerechtfertigt sein, aber es führt zwangsläufig zu einem unrechtfertig hohen Vertrauen in diesen Inhalt aus Sicht des Nutzers. Für die meisten sieht eine Seite, die auf claude.ai liegt, nicht anders aus als eine offizielle Claude-Seite, was Verwirrung nicht nur möglich, sondern wahrscheinlich macht. Der Hinweis, dass der Inhalt benutzergeneriert ist, befindet sich oben auf der Seite in kleiner, kaum leserlicher Schrift, was es weniger neugierigen Menschen leicht macht, ihn zu übersehen. Außerdem ist der Hinweis auf einem Handy überhaupt nicht sichtbar.
In diesem Sinne liegt die Verantwortung für den daraus resultierenden Vertrauensmissbrauch nicht nur bei den Angreifern oder Google, die die Anzeige zugelassen haben: Die Wahl der Domain und des Designs hat die Wachsamkeit der Nutzer gesenkt und die Effektivität der Kampagne verstärkt.
Wenn Zeit entscheidend ist
Es ist wichtig zu betonen, dass wir diesen Vorfall sofort nach seiner Entdeckung gemeldet haben. Der Zeitplan sah wie folgt aus:
- Februar, 15:00 UTC — Ein Bericht wurde bei Google Ads eingereicht
- Februar, 16:00 UTC — Eine öffentliche Offenlegung wurde auf X gepostet
- Februar, 20:00 UTC — Ein Bericht wurde an Claude gesendet
Trotzdem blieben die schadhafte Seiten stundenlang zugänglich. Die Moderation von benutzergenerierten Inhalten (UGC) auf Claude.ai erwies sich als langsam: Die spezifische Seite, die wir gemeldet hatten, wurde erst 16 Stunden später entfernt. In der Zeit, in der wir die Seite verfolgt haben, hatte sie etwa 21.000 Besuche angesammelt.
Noch besorgniserregender ist, dass andere schadhafte Artefakte auch danach weiterhin zugänglich waren. Mindestens eine ähnliche Seite ist immer noch aktiv und hat bis zum Zeitpunkt des Schreibens etwa 4.300 Klicks gesammelt. Mit anderen Worten, obwohl der anfängliche Bericht schließlich bearbeitet wurde, ermöglichte die Verzögerung in der Gesamtreaktion der Kampagne, dass weiterhin neue Opfer gewonnen wurden — lange nachdem das Problem gemeldet worden war.
Was diese Malware-Kampagne so geschickt macht
Aus unserer Sicht hat dieser Angriff das Potenzial, besonders effektiv zu sein, weil er Vertrauen in jeder Phase mit extrem präzisem Targeting kombiniert.
Auf hoher Ebene wird eine gefährliche Vertrauenskette geschaffen:
Anzeige von einem Google-verifizierten Publisher → Offizielle Claude.ai-Domain → Ausführung von verstecktem Code
Diese Kette erhöht dramatisch die Wahrscheinlichkeit, dass der Befehl ausgeführt wird, ohne ihn genau zu überprüfen.
Konkret gesagt:
Vertrauen wird in jedem Schritt vorausgesetzt
Die Anzeige zeigt eine echte, anerkannte Domain (claude.ai), keine gefälschte oder Tippfehler-Domain (und viele achten nicht besonders auf das „Gesponsert“-Label).
Das Klicken auf die Anzeige führt zu einer echten Claude-Seite, nicht zu einer Phishing-Kopie.
Der Text ist in einem überzeugenden, technischen Stil geschrieben und sieht genau so aus, wie Entwickler es erwarten.
Der Installationsprozess spiegelt den legitimen Homebrew-Prozess wider, einschließlich eines einzeiligen Shell-Befehls (der, um fair zu sein, auch in der offiziellen Version schon etwas beängstigend aussieht).
Hier eine kurze Erklärung. Die legitime Seite ist https://brew.sh/, und der legitime Installationsbefehl lautet:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Dieser Befehl sieht in gewisser Weise schon so aus, wie es Sicherheitsforscher warnen: Er lädt ein Skript aus dem Internet herunter und führt es sofort mit bash aus. Dieses Muster wird genau so von realer Malware verwendet. Natürlich ist der Befehl in diesem Fall legitim und verweist auf ein bekanntes GitHub-Repository, das vom Homebrew-Projekt gepflegt wird. Aber rein mechanisch gesehen ist der Ablauf identisch: Sie vertrauen einem entfernten Server, der Ihnen Code liefert, und führen diesen Code aus, ohne ihn vorher zu überprüfen.
Aber das ist nur ein Teil, der zum Erfolg der Angreifer beigetragen hat. Der andere ist eine perfekt abgestimmte Zielgruppe.
Die Zielgruppe besteht aus Menschen, die aktiv Homebrew installieren möchten (brew); andernfalls würden sie überhaupt nicht danach suchen.
Die Zielgruppe führt wahrscheinlich technische Arbeiten aus und hat Zugang zu Unternehmenssystemen, SSH-Schlüsseln, GitHub-Tokens und anderen Anmeldeinformationen.
Die Zielgruppe erwartet, einen Befehl im Terminal auszuführen, und ist damit überhaupt nicht überrascht. Mit anderen Worten, die schadhafte Aktion ist perfekt in einen normalen, erwarteten Arbeitsablauf eingebaut.
Da die Anzeigen für Anfragen wie „brew macos“ oder „brew install“ angezeigt werden, sehen Windows-Nutzer oder diejenigen, die nicht an Homebrew interessiert sind, diese nicht. Das macht den Traffic besonders relevant.
Ein weiterer Faktor ist, wie billig und einfach dieser Angriff skalierbar ist. Es ist keine Notwendigkeit für gefälschte Domains und keine Notwendigkeit für Social Engineering in direkten Nachrichten oder E-Mails. Der Angreifer erstellt einfach eine Seite auf einer vertrauenswürdigen Domain, kauft Anzeigen und lässt den eigenen Google-Traffic den Rest erledigen. Aus der Sicht des Angreifers ist der operative Aufwand minimal. Es gibt keine komplexe Infrastruktur aufzubauen und keine langwierige Interaktion mit den Opfern. Man erstellt die Seite, startet die Anzeigen, und die Verteilung passiert automatisch. Sobald die Anzeigen live sind, ist die Reichweite nur durch das Anzeigenbudget und den Traffic begrenzt, wodurch ein kleines Setup zu einem effizienten und potenziell großen Infektionskanal wird.
Aus unserer Sicht hat dies zusammen genommen etwas nahe an einem perfekten Sturm geschaffen: ein vertrautes und weithin akzeptiertes Installationsmuster, ein hoch vertrauenswürdiger Verteilungskanal und eine Zielgruppe mit dem Potenzial, erheblichen Schaden zu verursachen — genau zur richtigen Zeit und mit der richtigen Intention. Auch wenn wir die Handlungen der Angreifer in keiner Weise billigen, ist es schwer, nicht eine gewisse düstere „Eleganz“ darin zu erkennen, wie effizient all diese Teile zusammengefügt wurden.
Was lässt sich daraus schließen?
Dieser Angriff zeigt, wie schnell vertrauenswürdige Domains und Plattformen missbraucht werden können. Nutzer klicken auf einen Link zu einer legitimen Domain, folgen scheinbar normalen Anweisungen und führen unwissentlich Befehle aus, die ihren Computer gefährden. Ein einziger Klick kann den Laptop eines Entwicklers in ein Tor für gestohlene Anmeldeinformationen, eingeschleuste Malware in Repositories oder manipulierte Builds verwandeln — und das sind nur einige der möglichen Folgen.
Die Schlussfolgerung ist klar: Google Ads + eine bekannte, vertrauenswürdige Plattform + technische Nutzer mit weitreichenden Folgen = ein gefährlicher Malware-Verteilungsvektor. Schon ein einziges infiziertes Gerät kann eine Kettenreaktion auslösen, die Tausende von Nutzern betrifft, weit über das ursprüngliche Ziel hinaus.
Noch wichtiger ist, dass dieser Vorfall auch zeigt, warum das überhaupt passieren konnte.
Zuerst gibt es das langjährige Problem der unzureichenden Anzeigekontrolle bei Google. Das ist nichts Neues. Auch wenn die schiere Menge an Anzeigen, die Google bearbeiten muss, das Problem vielleicht erklärt, ändert es nichts an der Tatsache: Schadkampagnen schlüpfen weiterhin durch und erreichen viele Menschen. Ähnliche Fälle wurden auch schon dokumentiert, zum Beispiel in der Analyse der Bumblebee-Malware-Kampagne, die Google Ads missbraucht hat.
Dann kommt das Verzögern bei der Moderation von benutzergenerierten Inhalten bei Claude, zusammen mit fragwürdigen Designentscheidungen für das Produkt und die Domain. Wenn potenziell gefährliche UGC auf der Hauptdomain (claude.ai) gehostet wird, erbt dieser Inhalt das Vertrauen der Marke.
Zusammengefasst war das nicht nur ein cleverer Angriff — es war ein systematisches Versagen auf mehreren Ebenen: Werbeprüfung, Plattformmoderation und Vertrauenssignale.
Trotzdem hoffen wir, dass dieser Vorfall eine Warnung für alle Unternehmen ist und dazu führt, dass schnell Lösungen gefunden werden. Angesichts der Schwere des Problems könnten bereits Tausende im Visier sein oder Gefahr laufen, Opfer zu werden. Es liegt im Interesse von Google, Anthropic (die das Claude-Projekt besitzen) und vor allem der Nutzer, dass diese Probleme so schnell wie möglich gelöst werden.
Update (13. Februar)
Wir haben beobachtet, dass die Angreifer die gleiche Taktik erneut angewendet haben, jedoch mit einer bemerkenswerten Änderung. Anstatt die vergifteten Anweisungen auf claude.ai zu hosten, wurde die schadhafte Seite nun auf share.evernote.com veröffentlicht, einer dritten Domain, die für benutzergenerierte Inhalte auf Evernote verwendet wird. Die Mechanik des Angriffs blieb dieselbe: Eine scheinbar legitime UGC-Seite auf einer vertrauenswürdigen Plattform wurde genutzt, um einen schädlichen Befehl auszuliefern. Dies zeigt, dass dieser Ansatz nicht an einen einzelnen Dienst wie Anthropics Claude gebunden ist, sondern auf verschiedenen beliebten Plattformen, die benutzergenerierte Inhalte hosten, repliziert werden kann.
