Eine aktuelle Magecart-Kampagne zeigt eindrücklich, wie weitentwickelt Client-Side-Skimming inzwischen ist: Der eigentliche Schadcode wird nicht im Shop-Code selbst platziert, sondern in EXIF-Metadaten eines dynamisch geladenen Favicons versteckt und ausschließlich im Browser der Kundschaft ausgeführt. Herkömmliche Repository-Scanner und statische Codeanalyse bleiben dabei praktisch blind.
Neue Magecart-Technik: Skimming-Code im Favicon und in EXIF-Metadaten
Auf kompromittierten E‑Commerce-Websites fanden Forschende zunächst nur einen kurzen Loader-Skript. Dieser wirkt wie ein normaler Eintrag für einen externen Dienst, etwa ein Snippet von einem bekannten CDN oder Payment-Provider wie Shopify. Diese Tarnung reduziert die Chance, dass der Code bei einem manuellen Review oder oberflächlichem Security-Scan auffällt.
Der Loader lädt anschließend einen zweiten Script-Block nach, der über verschachtelte Array-Indizes und verschleierte Strings einen tatsächlich schädlichen URL konstruiert – etwa //b4dfa5[.]xyz/favicon.ico. Nach der Dekodierung fordert der Browser dieses Favicon an. Statt es wie üblich nur als Icon darzustellen, behandelt das Skript die Antwort als Binärdaten, liest gezielt die EXIF-Metadaten aus und extrahiert daraus eine versteckte Zeichenkette mit JavaScript.
Dieser versteckte JavaScript-Code wird anschließend über new Function() ausgeführt. Die gesamte Payload lebt somit im Metadaten-Bereich des Bildes und taucht an keiner Stelle als Klartext im HTML oder im für CI/CD-Tools sichtbaren Code auf. Abschließend werden abgegriffene Zahlungsdaten per POST-Anfrage direkt aus dem Browser an einen vom Angreifer kontrollierten Server gesendet – ohne Änderungen am Store-Template oder Backend.
Charakteristisch für diese Kette sind vier Eigenschaften: Der Loader tarnt sich als legitimer Third-Party-Script; die Payload ist im binären Favicon versteckt; die Exfiltration erfolgt direkt aus der Kundensession; und der eigentliche Shop-Code im Repository bleibt unverändert.
Warum statische Codeanalyse Web-Supply-Chain-Angriffe kaum erfassen kann
Statische Codeanalyse – ob in Form von SAST-Tools, Repository-Scannern oder CI-Integrationen – arbeitet ausschließlich auf den Artefakten, die im eigenen Projekt vorhanden sind: Quellcode, Konfigurationsdateien, Infrastruktur-Definitionen. In diesem Bereich identifiziert sie zuverlässig klassische Schwachstellen wie XSS, SQL-Injections, fehlerhafte Authentifizierung oder unsichere Datenverarbeitung.
Magecart-Angriffe sind jedoch typische Web-Supply-Chain-Bedrohungen. Der bösartige JavaScript-Code gelangt über kompromittierte Drittanbieter-Komponenten auf die Seite: Payment-Widgets, Tag-Manager, Analytics-Skripte, CDN-Ressourcen oder dynamisch geladene Bilder. Dieser Code liegt meist weder im eigenen Git-Repository noch durchläuft er das interne Code-Review. Aus Sicht eines Repository-Scanners existiert er schlicht nicht.
Daraus ergeben sich klare Grenzen: Statische Analyse kann keine Payload interpretieren, die in einem binären Favicon versteckt ist, sieht keine Domains, die erst zur Laufzeit im Browser auftauchen, und erkennt keine ungewöhnlichen clientseitigen Netzwerkaufrufe. Das ist kein Produktfehler, sondern ein Mismatch zwischen Werkzeugklasse und Angriffstyp.
Dennoch bleibt statische Analyse ein wichtiger Schutzlayer. Sie kann riskante Muster im eigenen Code markieren – etwa dynamische Einbindung externer Skripte, übermäßige Nutzung von eval oder new Function sowie fest verdrahtete Endpunkte für Datentransfers. Damit verkleinert sie systematisch die Angriffsfläche, ersetzt aber nicht die Überwachung dessen, was tatsächlich im Browser geschieht.
Typische Muster von Web-Supply-Chain- und Client-Side-Skimming-Angriffen
Unsichtbare iframes über Zahlungsformularen
Ein verbreitetes Muster bei Magecart-ähnlichen Angriffen ist ein nicht sichtbarer iframe, der direkt über dem legitimen Zahlungsformular liegt. Ein kompromittiertes Widget blendet diesen Overlay ein, zeichnet jede Tastatureingabe mit und sendet Kartendaten an die Angreifer. Das sichtbare HTML des Shops bleibt formal unverändert; im Repository findet sich kein Hinweis auf den Skimmer.
Missbrauch von Tracking-Pixeln und Analytics-Skripten
Nahezu jeder E‑Commerce-Shop nutzt Tracking-Pixel und Analyseskripte aus externen CDNs. Werden diese Anbieter oder deren Lieferkette kompromittiert, kann derselbe Pixel plötzlich als Kanal für Datenabfluss dienen. Für die Anwendung wirkt der Aufruf weiterhin wie ein seit Jahren bekannter, legitimer Endpoint, während die schädliche Logik vollständig bei der Drittpartei liegt.
DOM-basierte Datendiebstähle über Tag-Manager
Ein weiterer Angriffsvektor sind Skripte, die über Tag-Manager verteilt werden. Sie registrieren sich dynamisch auf Eingabe-Events in Login- oder Zahlungsfeldern und sammeln die Daten bereits vor dem Absenden der Formulare. Die dafür verantwortlichen Event-Handler entstehen erst zur Laufzeit im Browser und entziehen sich dadurch der statischen Analyse im Repository.
Aktuelle Angreifer kombinieren diese Techniken mit KI-generiertem, polymorphem JavaScript, dessen Struktur sich ständig ändert, um signaturbasierte Erkennung zu umgehen. Dadurch steigt der Wert von Lösungen, die das tatsächliche Verhalten von Code beobachten, anstatt nur seinen Text zu prüfen.
Defense-in-Depth: Clientseitiges Runtime-Monitoring als fehlende Verteidigungsschicht
Für Bedrohungen wie Magecart ist clientseitiges Runtime-Monitoring im Browser ein zentrales Kontrollinstrument. Entsprechende Plattformen protokollieren, welche Skripte in einer Session tatsächlich ausgeführt werden, welche DOM-Änderungen sie vornehmen und wohin sensible Daten gesendet werden. Praktisch beantworten sie die Fragen: „Welcher Code läuft gerade im Browser meiner Kundschaft?“ und „Versucht dieser Code, Zahlungs- oder Kontodaten an unbekannte Domains zu übertragen?“
Branchenempfehlungen – etwa von OWASP oder der EU-Agentur ENISA – betonen einen Defense-in-Depth-Ansatz für Web-Supply-Chain-Risiken. Statische Analyse und konsequentes Dependency-Management reduzieren Schwachstellen im eigenen Code. Sicherheitsrichtlinien wie Content Security Policy (CSP), Subresource Integrity (SRI) und strenge Allowlists für Drittanbieter-Skripte begrenzen die Möglichkeiten von Angreifern. Clientseitiges Runtime-Monitoring schließt schließlich die Lücke, indem es Angriffe sichtbar macht, die sich ausschließlich im Browser abspielen und den Codebestand des Unternehmens nie berühren.
Unternehmen – insbesondere im E‑Commerce – sollten ihre Sicherheitsstrategie daher um drei Bausteine ergänzen: robuste statische Codeanalyse, striktes Management der Web-Supply-Chain und kontinuierliches Browser-Runtime-Monitoring. Wer diese Ebenen kombiniert, reduziert die Gefahr unbemerkter Magecart-Skimmer deutlich und schützt Zahlungsdaten dort, wo sie heute am häufigsten angegriffen werden: direkt im Browser der Kundinnen und Kunden.
