Die beobachtete Angriffskette beginnt mit einem unscheinbaren Loader auf kompromittierten Websites. Dieser Stub lädt dynamisch ein Skript von einer URL nach, die wie eine legitime Shopify-CDN-Adresse aussieht. Das geladene Skript konstruiert anschließend mithilfe verschleierter Index-Arrays die eigentliche schädliche URL. Decodiert verweist diese auf //b4dfa5[.]xyz/favicon.ico.
An dieser Stelle wird die Technik interessant: Das Skript ruft das Favicon als Binärdaten ab, liest aus den EXIF-Metadaten eine schädliche Zeichenkette aus und führt sie über new Function() aus. Da der Payload im Bild-Metadatensatz steckt, bleibt er für jedes Werkzeug unsichtbar, das den Browser nicht zur Laufzeit beobachtet. Am Ende der Kette werden gestohlene Zahlungsdaten unbemerkt per POST an einen vom Angreifer kontrollierten Server gesendet.
Vier Eigenschaften der Kette sind für die Frage nach dem richtigen Werkzeug entscheidend: Der erste Loader wirkt wie eine harmlose Drittanbieter-Einbindung, der Payload liegt in binären Bild-Metadaten verborgen, die Exfiltration erfolgt direkt aus dem Browser des Kunden, und nichts davon erfordert einen Eingriff in den Quellcode des Händlers.
Claude Code Security ist darauf ausgelegt, Codebasen zu durchsuchen, Datenflüsse nachzuverfolgen und Korrekturen für Schwachstellen im selbst geschriebenen Code vorzuschlagen. Für die Absicherung eigener Anwendungen ist das nützlich, doch genau darin liegen auch die blinden Flecken gegenüber dieser Angriffsklasse. Das Werkzeug hat keine praktische Sicht auf Schadcode, der nur in Drittanbieter-, CDN- oder Tag-Manager-Skripten injiziert wird und nie im Repository landet. Es kann weder Payloads in binären Assets wie Favicons untersuchen, die nicht zum Quellbaum gehören, noch die Reputation von Angreifer-Domains bewerten, die erst zur Laufzeit auftauchen. Auch die Echtzeit-Erkennung auffälliger Netzwerkanfragen im Browser während des Bezahlvorgangs liegt außerhalb seines Bereichs. Beitragen könnte es allenfalls dort, wo der eigene Code selbst dynamische Skript-Injektionslogik enthält oder verdächtige Exfiltrations-Endpunkte fest verdrahtet – Muster, die eine Code-Analyse als riskant markieren kann.
Die Favicon-Steganografie ist nur eine Ausprägung eines breiteren Musters. Bei der Injektion bösartiger iframes überlagert ein kompromittiertes Drittanbieter-Widget ein echtes Checkout-Formular mit einem vom Angreifer kontrollierten iframe; der Nutzer sieht die reale Seite, seine Eingaben fließen jedoch zum Angreifer. Beim Missbrauch von Pixel-Trackern wird über externe CDNs geladener Analyse- oder Werbecode nach einer Kompromittierung zum Exfiltrationskanal, während der Händler-Code weiterhin denselben legitim wirkenden Endpunkt aufruft. Beim DOM-basierten Abgreifen von Zugangsdaten lauscht ein über einen Tag-Manager geladenes Skript auf Eingabeereignisse von Formularfeldern und erfasst die Daten vor dem Absenden.
Allen Vektoren ist gemeinsam: Die Bedrohung lebt außerhalb des Repositorys, läuft in einem für statische Analyse nicht beobachtbaren Kontext und zielt auf die Lücke zwischen dem ausgelieferten Code und dem, was tatsächlich im Browser der Nutzer ausgeführt wird. Die primäre Schutzschicht mit direkter Sicht auf einen solchen Angriff ist daher die kontinuierliche Überwachung dessen, was im Browser läuft. Clientseitige Laufzeit-Monitoring-Plattformen beantworten die Frage, welcher Code gerade im Browser der Nutzer ausgeführt wird und was er tut.
Laufzeitüberwachung ist dabei nur ein Teil des Bildes und funktioniert am besten als Element einer mehrschichtigen Verteidigung: Statische Analyse und Lieferketten-Governance verkleinern die Angriffsfläche, während die Laufzeitüberwachung abfängt, was durchrutscht. Ein Repository-zentriertes Werkzeug an einem Laufzeitangriff zu messen, ist ein Kategorienfehler, kein Produktmangel – vergleichbar mit der Erwartung, ein Rauchmelder solle ein Feuer löschen.