Die neu entdeckte Magecart-Malware demonstriert eine Technik, die klassische Sicherheitsscans komplett ausbremst. Die Angreifer nutzen eine dreistufige Loader-Kette: Ein scheinbar harmloser Third-Party-Code lädt ein Skript von einer gefälschten Shopify-CDN-URL herunter. Dieses Skript konstruiert dann eine obfuskierte URL zu einem externen Server (b4dfa5.xyz/favicon.ico). Dort liegt die eigentliche Malware – nicht als JavaScript-Datei, sondern versteckt in den EXIF-Metadaten eines Favicon-Bildes. Der Browser führt diese extrahierte Payload via new Function() aus und leitet gestohlene Zahlungsdaten direkt an Server des Angreifers weiter.
Woher kommt die Blindheit der Scanner? Statische Code-Analyse-Tools wie Claude Code Security arbeiten ausschließlich mit Quellcode aus Repositories. Sie können Datenflüsse nachverfolgen, problematische Code-Muster erkennen und Fixes vorschlagen. Aber bei Magecart-Angriffen findet die malware Aktivität komplett außerhalb des Repository statt – sie lebt in kompromittierten Third-Party-Assets, die zur Runtime geladen werden. Das Tool hat keine Sichtbarkeit auf: dynamisch geladene Fremskripte von CDNs oder Tag-Managern; Payloads, die in Binärdateien wie Bilder versteckt sind; Reputationsprobleme von Angreifer-kontrollierten Domains; oder anomale Netzwerkanfragen im Browser während des Checkouts.
Ähnliche Angriffsvektoren zeigen das gleiche Muster. Bei Malicious-iframe-Injection überlagert ein kompromittiertes Third-Party-Widget das echte Checkout-Formular mit einer Angreifer-kontrollierten Version – der Nutzer sieht die richtige Seite, aber Tastenanschläge gehen an die Angreifer. Im Repository ändert sich nichts. Bei Pixel-Tracker-Abuse werden Analysepixel von externen CDNs geladen; wenn diese CDNs brechen, wird der legitim aussehende Tracking-Code zur Exfiltrations-Pipeline. Bei DOM-basierten Credential-Harvesting registriert ein Tag-Manager-Script Event-Handler auf Login- oder Zahlungsseiten – der ganze Angriff lebt in der Runtime, nicht im statischen Code.
Das bedeutet nicht, dass Claude Code Security ein schlechtes Produkt ist. Es ist ein Kategorien-Fehler, es gegen Runtime-Angriffe zu testen – wie wenn man einen Rauchmelder beurteilt, weil er Feuer nicht löscht. Das Tool war für etwas anderes designt und leistet dort hervorragende Dienste. Für wirkliche Web-Supply-Chain-Sicherheit braucht es eine Defense-in-Depth-Strategie: Statische Analyse reduziert die Angriffsfläche durch Governance und sicheren Code, Runtime-Monitoring beobachtet, was tatsächlich im Browser passiert und fängt Angriffe auf, die den statischen Scanner passieren. Deutsche Unternehmen sollten beide Tools im Stack haben – und das Runtime-Monitoring als primäre Kontrollschicht gegen Magecart behandeln.