Skimming på betalingssiden: spor efter injiceret JavaScript

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Ved skimming på en webshop er der indsat JavaScript, som opsamler det, kunderne taster på betalingssiden, og sender det til en fremmed server. Undersøgelsen skal besvare tre spørgsmål: hvor koden ligger, hvornår den blev aktiv, og hvornår den blev fjernet. De to tidspunkter afgrænser det vindue, hvor ordrer kan være berørt, og dermed hvilke kunder der skal underrettes. Fordi koden kører i kundens browser, ses selve opsamlingen ikke i webshoppens serverlogs. Dateringen må derfor bygges op af andre kilder: filer, database, tag manager, adgangslogs og infrastrukturen bag den fremmede server.

Haster det? Webshoppens adgangslogs roteres ofte efter dage eller uger, og koden fjernes typisk ved den første oprydning, så starttidspunktet kan gå tabt. Se akut forensisk sikring; hastesager koster ekstra.

Virksomhedens handleplan, når webshoppen er hacket, står på bevissikring-digitalt.dk. Den generelle undersøgelse af en kompromitteret WordPress-side, som mange webshops bygger på, er beskrevet i Kompromitteret WordPress.

Hvor koden kan ligge

Koden kan være indsat mange steder, og det er sjældent det mest oplagte:

i temaets eller platformens filer, fx skabelonen for betalingssiden eller en fælles JavaScript-fil,
i databasen, fx i indstillinger for sidefod, brugerdefinerede scripts eller indholdsblokke,
i en tag manager-container, hvor scripts kan tilføjes uden at ændre webshoppen,
hos en tredjepart, hvis et eksternt script, som siden indlæser, er ændret ved kilden,
i et plugin eller modul, der kun indsætter koden på bestemte sider.

Koden er ofte betinget: Den aktiveres kun på betalingssiden, kun for besøgende, der ikke er logget ind som administrator, kun fra bestemte lande eller kun én gang pr. besøgende. En administrator, der kigger på siden, ser derfor måske intet.

Sikring af siden, som kunden ser den

Besøg betalingssiden som almindelig kunde fra et isoleret miljø, ikke logget ind som administrator, og optag al netværkstrafik, herunder alle scripts, der indlæses, og alle forespørgsler, siden sender. → Webarkivering i forensisk kvalitet
Gennemfør flowet frem til betalingsfelterne uden at indtaste rigtige kortoplysninger. Mange skimmere aktiveres først, når der skrives i felterne. Brug kun testdata og notér, hvad der er indtastet.
Gem hvert script med adresse og hashværdi. Sammenlign med de forventede versioner af platformens og tredjeparters scripts.
Dokumentér forespørgsler til ukendte domæner, især dem, der sendes, når felterne udfyldes.

Gentag besøget med forskellige browsere og fra forskellige netværk, hvis koden er betinget. Notér tidspunkt, udgående IP-adresse og brugeragent for hvert besøg.

Sikring på serveren

Tag kopi af filer og database som ved enhver kompromittering, og eksportér tag manager-containerens versionshistorik, hvis en sådan bruges. Bed hostingudbyderen om adgangslogs, logs for administrative logins og logs fra eventuel WAF eller CDN. Bed betalingsudbyderen om at bevare transaktionsdata for perioden.

Datering: hvornår blev koden aktiv?

Tidspunktet findes typisk ved at kombinere flere kilder:

Filens tidsstempler, især inode-ændringstid på Linux · Hvornår filen sidst blev skrevet
Databasens revisioner eller ændringslog · Hvornår indholdet eller indstillingen blev ændret
Tag managerens versionshistorik · Hvornår en version med scriptet blev udgivet, og af hvilken konto
Adgangsloggen · Den administrative forespørgsel, der indsatte koden
Registrering og certifikater for det fremmede domæne · Den tidligste dato, hvor domænet kunne modtage data
Webarkiver og egne backups · Om koden var til stede på bestemte datoer

Det fremmede domænes registreringsdato og første TLS-certifikat giver en nedre grænse: Koden kan ikke have sendt data til domænet, før det fandtes. → Lookalike-domæner: registreringsdata og certifikatlogs

Backups er ofte den stærkeste kilde: Findes koden i én backup, men ikke i den forrige, er den indsat mellem de to. Notér backuppernes tidspunkter og hvordan de er gendannet til analyse.

Browserrapporter

Har webshoppen en indholdssikkerhedspolitik (Content Security Policy) med rapportering, sender kundernes browsere en rapport, når siden forsøger at indlæse eller sende data til et domæne, der ikke er tilladt. Rapporterne lander hos den modtagende tjeneste, webshoppen har valgt, og kan give en direkte datering af, hvornår browsere første gang mødte det fremmede domæne, og fra hvilke sider. Tilsvarende kan integritetskontrol af eksterne scripts give fejl, der er logget, hvis et tredjepartsscript er ændret. Findes sådanne rapporter, er de blandt de stærkeste kilder, fordi de kommer fra kundernes side af forbindelsen.

Datering: hvornår blev koden fjernet?

Fjernelsen er lige så vigtig som indsættelsen. Notér præcist, hvornår koden blev fjernet, af hvem og hvordan. Kontrollér bagefter med et nyt besøg som kunde, at den faktisk er væk, og at den ikke ligger i en cache hos CDN eller i browsercache. Er koden fjernet flere gange og kommet igen, er der en fastholdelse, der ikke er fundet.

Afgrænsning af berørte ordrer

Når vinduet er fastlagt, kan de berørte ordrer findes i webshoppens ordredatabase og i betalingsudbyderens transaktionsliste. Afgrænsningen afhænger af betalingsløsningen:

Betalingsfelter på webshoppens egen side: alle ordrer med kortbetaling i vinduet kan være berørt.
Betalingsvindue hos udbyderen, indlejret eller via omdirigering: Selve kortfelterne ligger hos udbyderen. Skimmeren kan dog indsætte en falsk betalingsformular før omdirigeringen, og så er alle kunder, der nåede betalingssiden, potentielt berørt.
Påbegyndte, men ikke gennemførte køb kan også være berørt, fordi data sendes, mens der tastes. De ses ikke i ordredatabasen, men kan ses som besøg på betalingssiden i adgangsloggen.

Adgangsloggen kan altså give et tal for, hvor mange sessioner der nåede betalingssiden i vinduet, og ordredatabasen et tal for gennemførte køb. Begge bør fremgå. Den generelle metode til at afgrænse berørte persondata er beskrevet i Hvilke persondata blev berørt?

Betalingsudbyder og kortindløser

Ofte er det betalingsudbyderen eller kortindløseren, der først opdager skimmingen, fordi mange kort med svindel har webshoppen som fælles købssted. Deres henvendelse kan indeholde en periode og et antal kort, som kan sammenholdes med det tekniske vindue. Kortindløsere kan stille særlige krav til, hvem der må lave undersøgelsen, og til rapportens form. Kortordningerne kan via indløseren kræve, at undersøgelsen udføres af en PCI Forensic Investigator (PFI), dvs. en virksomhed, der er godkendt til formålet af PCI Security Standards Council. Om kravet stilles, afhænger af ordningernes regler og den konkrete sag. Afklar det tidligt, så sikringen kan bruges af alle parter.

Fejlkilder

Administratorvisning: Koden vises ikke for administratorer.
Cache: En fjernet kode kan stadig leveres fra cache i timer eller dage.
Legitime tredjepartsscripts til analyse, chat og markedsføring sender også data til eksterne domæner. Det er indholdet og tidspunktet for forespørgslen, der adskiller dem.
Tidszoner i ordredatabase, adgangslog og tag manager.
Ufuldstændige backups, der ikke indeholder databasen eller tag manager-indstillingerne.

Hvad sporene kan og ikke kan bevise

Sporene kan vise, at skimmingkode var til stede, hvor den lå, i hvilket tidsrum den var aktiv, og hvilke ordrer og sessioner der faldt i vinduet. De kan ikke vise, hvilke kunders data der faktisk blev modtaget af den fremmede server, eller hvem der står bag. Vinduet bør angives med den usikkerhed, kilderne giver, og med den forsigtige afgrænsning som udgangspunkt.

Dokumentation

Rapporten bør indeholde sikringen af betalingssiden med netværkstrafik, koden med hashværdi og placering, kilderne til datering af indsættelse og fjernelse, den fastlagte periode med usikkerhed og den metode, der er brugt til at finde de berørte ordrer.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Indgangsvejen i WordPress: sårbart plugin eller svag adgang? · Lækkede API-nøgler og tokens: dokumentation af misbrug

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For MSP’er · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik