Zorg voor het juiste dreigingsmodel

Wanneer een Magecart-payload zich verbergt in de EXIF-gegevens van een dynamisch geladen favicon van derden, zal geen enkele repositoryscanner deze opvangen – omdat de kwaadaardige code nooit daadwerkelijk in uw repository terechtkomt. Nu teams Claude Code Security gebruiken voor statische analyse, is dit precies de technische grens waar het scannen van AI-codes stopt en de runtime-uitvoering aan de clientzijde begint.

Een gedetailleerde analyse van waar Claude Code Security ophoudt – en wat runtime-monitoring omvat – is hier beschikbaar.

Een Magecart-skimmer die onlangs in het wild werd gevonden, gebruikte een drietraps laadketen om zijn lading te verbergen in de EXIF-metagegevens van een favicon. Daarbij raakte hij nooit de broncode van de verkoper aan, verscheen hij nooit in een repository en werd hij bij het afrekenen volledig in de browser van de klant uitgevoerd. De aanval roept een vraag op die de moeite waard is om nauwkeuriger te zijn: welke categorie tools zou dit eigenlijk moeten opvangen?

Magecart leeft buiten uw codebasis

Aanvallen in Magecart-stijl gaan zelden over klassieke kwetsbaarheden in uw eigen broncode. Het zijn infiltraties in de toeleveringsketen. Het kwaadaardige JavaScript komt doorgaans binnen via gecompromitteerde middelen van derden: tagmanagers, betalings-/afrekenwidgets, analysetools, door CDN gehoste scripts en afbeeldingen die tijdens runtime in de browser worden geladen. De slachtofferorganisatie heeft die code niet geschreven, beoordeelt deze niet in PR’s, en deze bestaat vaak helemaal niet in hun repository.

Dat betekent dat een op repository’s gebaseerd hulpmiddel voor statische analyse, zoals Claude Code Security, in dit scenario daarom qua ontwerp beperkt is, omdat het alleen kan analyseren wat zich in de repository bevindt of wat u er expliciet aan toevoegt. Elke skimmer die uitsluitend leeft in gewijzigde bronnen van derden of dynamisch geladen binaire bestanden in productie, komt nooit in zijn gezichtsveld. Dat is geen bug in het product; het is een scope-mismatch.

De aanvalsstroom: hoe de skimmer zich verbergt

Hier is de eerste lader die te zien is op gecompromitteerde websites:

Deze stub laadt dynamisch een script van wat een legitieme Shopify CDN-URL lijkt te zijn. Het geladen script construeert vervolgens de daadwerkelijke kwaadaardige URL met behulp van versluierde indexarrays:

Eenmaal gedecodeerd verwijst dit naar //b4dfa5(.)xyz/favicon.ico. Wat er vervolgens gebeurt, is waar de techniek interessant wordt: het script haalt de favicon op als binaire gegevens, parseert de EXIF-metagegevens om een kwaadaardige tekenreeks te extraheren en voert deze uit via de nieuwe Function() – de payload bevindt zich in de metagegevens van afbeeldingen, dus is onzichtbaar voor alles dat de browser tijdens runtime niet in de gaten houdt.

De laatste exfiltratie-oproep POST gestolen betalingsgegevens stil naar een door de aanvaller bestuurde server:

De keten heeft vier eigenschappen die van belang zijn voor de gereedschapsdiscussie die volgt: de initiële lader ziet eruit als een goedaardige externe partij; de payload is verborgen in de metadata van binaire afbeeldingen; exfiltratie gebeurt rechtstreeks vanuit de browser van de klant; en niets ervan vereist dat de eigen broncode van de handelaar wordt aangeraakt.

Wat Claude Code Security wel en niet kan zien

Claude Code Security is ontworpen om codebases te scannen, gegevensstromen te traceren en oplossingen voor kwetsbaarheden in de code voor te stellen die u of uw teams schrijven. Dat maakt het nuttig voor het beveiligen van first-party applicaties, maar het definieert ook de blinde vlekken voor deze aanvalsklasse.

In dit scenario heeft het geen praktisch inzicht in kwaadaardige code die alleen wordt geïnjecteerd in door derden, CDN of door Tag Manager gehoste scripts die nooit in uw opslagplaatsen worden opgeslagen. Het kan ook geen payloads ondervragen die verborgen zijn in binaire assets zoals favicons of afbeeldingen die geen deel uitmaken van uw bronstructuur. Het kan het risico of de live reputatie van door aanvallers gecontroleerde domeinen die alleen tijdens runtime verschijnen niet inschatten, en realtime detectie van afwijkende netwerkverzoeken aan de browserzijde tijdens het afrekenen valt ook buiten het bereik ervan.

Waar het een bijdrage zou kunnen leveren (hoewel niet als de primaire controle) zou zijn in gevallen waarin uw eigen code dynamische script-injectielogica bevat, een patroon dat een code-analysetool als riskant kan markeren. En als code van eigen hand verdachte exfiltratie-eindpunten hardcodeert of onveilige logica voor gegevensverzameling gebruikt, kan statische analyse deze stromen ter beoordeling aan het licht brengen.

De bovenste vier rijen zijn het belangrijkst in een Magecart-scenario, en Claude Code Security heeft in geen enkele runtime inzicht.

De onderste twee vertegenwoordigen een fundamenteel andere bedreiging: een ontwikkelaar schrijft per ongeluk kwaadaardig ogende code in zijn eigen repository.

Magecart is één vector, niet het hele aanvalsoppervlak

De bovenstaande favicon-steganografietechniek is geavanceerd, maar is een voorbeeld van een breder patroon. Aanvallen op de supply chain van het web komen via verschillende mechanismen, elk met hetzelfde bepalende kenmerk: de kwaadaardige activiteit vindt plaats tijdens runtime, in de browser, via middelen die de verkoper niet heeft gemaakt. Ontdek hoe AI-gegenereerd, polymorf JavaScript de inzet verhoogt →

Nog een paar die het vermelden waard zijn:

Schadelijke iframe-injectie. Een gecompromitteerde widget van een derde partij overlapt stilletjes een legitiem afrekenformulier met een door de aanvaller bestuurd iframe. De gebruiker ziet de echte pagina, maar zijn toetsaanslagen worden naar de aanvaller gestuurd. Er verandert niets in de repository van de handelaar.

Misbruik van pixeltrackers. Analytics- en advertentiepixels – bijna universeel op e-commercesites – worden geladen vanaf externe CDN’s. Wanneer deze CDN’s worden gecompromitteerd of de pixelprovider zelf wordt geschonden, wordt de trackingcode die op elke pagina wordt uitgevoerd een exfiltratiekanaal. De code van de verkoper roept nog steeds hetzelfde legitiem ogende eindpunt aan als altijd.

Op DOM gebaseerde inloggegevens verzamelen. Een script dat via een tagmanager wordt geladen, luistert stil naar formulierveldgebeurtenissen op inlog- of betalingspagina’s en legt gegevens vast voordat deze ooit worden verzonden. De aanval vindt volledig plaats in de gebeurtenishandler die tijdens runtime is geregistreerd, en niet in iets dat een statische scanner ooit zou zien.

Elk van deze volgt dezelfde logica als de Magecart-zaak: de dreiging leeft buiten de repository, wordt uitgevoerd in een context die statische analyse niet kan waarnemen, en richt zich op de kloof tussen wat u heeft verzonden en wat daadwerkelijk in de browsers van uw gebruikers draait. U kunt het volledige overzicht vinden van hoe elke vector in verband staat met de dekking van de gereedschappen – en hoe een diepgaand verdedigingsprogramma er in al deze vectoren uitziet – in de onderstaande gids.

Waarom runtimemonitoring van cruciaal belang is (maar niet de enige controle)

Voor bedreigingen in de webtoeleveringsketen zoals deze Magecart-campagne is continue monitoring van wat er daadwerkelijk in de browsers van gebruikers wordt uitgevoerd de primaire laag met direct inzicht in de aanval op het moment dat deze plaatsvindt. Runtime-monitoringplatforms aan de clientzijde beantwoorden een aantal vragen die statische tools niet kunnen: “Welke code wordt momenteel uitgevoerd in de browsers van mijn gebruikers, en wat doet deze?”

Tegelijkertijd is runtime-monitoring slechts een deel van het plaatje. Het werkt het beste als onderdeel van een diepgaande verdedigingsstrategie. Statische analyse en supply chain-beheer verkleinen het aanvalsoppervlak, terwijl runtime-monitoring opmerkt wat er doorheen glipt en wat volledig buiten uw repository’s leeft.

De ‘test’ opnieuw formuleren: categorie, niet capaciteit

Het evalueren van een repo-centrisch hulpmiddel als Claude Code Security tegen een runtime-aanval is een categoriefout, geen productfout. Het is alsof je verwacht dat een rookmelder branden zal blussen. Het is het verkeerde gereedschap voor die klus, maar wel het ideale gereedschap voor waarvoor het is ontworpen. Voor een brandveilig gebouw heb je rookmelders en brandblussers nodig, en voor een veilige website heb je Claude Code Security en runtime monitoring in je stack nodig. Voor Magecart en soortgelijke skimming-aanvallen aan de clientzijde hebt u dat runtime-venster in de browser nodig. Statisch scannen van repository’s kan op zichzelf eenvoudigweg niet zien waar deze aanvallen zich werkelijk bevinden.

Als u tooling koppelt aan bedreigingsklassen op CISO-niveau, hebben we een korte handleiding samengesteld over hoe codebeveiliging en runtimemonitoring in elkaar passen binnen het volledige scala van vectoren van de webtoeleveringsketen – en waar elk ervan niet meer nuttig is.