Kundens hjemmeside blev hacket: ansvarsfordeling i sporene

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

Når en kundes hjemmeside er kompromitteret, kommer spørgsmålet hurtigt: var det hostingudbyderens server, bureauets kode eller kundens egne adgange, der svigtede? Sporene kan ofte placere indgangsvejen i ét af de tre lag, men kun hvis logs, filer og database sikres, før nogen rydder op. Artiklen er skrevet til webbureauer, hostingudbydere og MSP’er, der står midt i sådan en sag og selv kan blive part i den.

Den ledelsesmæssige side, altså hvordan virksomheden reagerer, når kunden retter kritik mod leverandøren, er beskrevet på bevissikring-digitalt.dk. Her handler det om, hvad de tekniske spor kan sige om fordelingen.

Tre lag med hver sin ejer

En typisk opsætning har tre ansvarsområder, og hvert lag efterlader sine egne spor:

Infrastrukturen (server, operativsystem, webserver, PHP-version, kontrolpanel og netværk) hører normalt under hostingudbyderen. Spor: systemlogs, kontrolpanelets log, SFTP- og SSH-log og opdateringshistorik.
Applikationen (CMS, plugins, temaer, egen kode og deploy) hører ofte under bureauet efter aftale. Spor: filændringer, versionsstyring, deployhistorik og plugin-versioner.
Adgangene (administratorbrugere, adgangskoder, MFA og hvem der fik login) er tit kundens. Spor: CMS’ets brugertabel, loginforsøg i webserverloggen og nulstillinger af adgangskoder.

WordPress’ egen hardening-vejledning beskriver samme deling: værten svarer for server og netværk, mens den, der installerer applikationen, svarer for WordPress, plugins og temaer. I praksis er grænserne sjældent så skarpe. Managed hosting kan omfatte automatiske opdateringer, og bureauet kan have fået SSH-adgang til serveren. Kontrakten og driftsaftalen afgør, hvem der skulle have gjort hvad. Sporene viser, hvad der faktisk skete.

Sikring før nogen rydder op

Den største trussel mod en senere afklaring er den første reaktion: bureauet gendanner en backup, hostingudbyderen flytter kontoen til en ny server, og kunden skifter alle adgangskoder. Alle tre handlinger er rimelige, men de overskriver netop de spor, der skal fordele ansvaret.

Rækkefølgen bør være:

Fuld kopi af webroden med tidsstempler bevaret, helst som arkiv dannet på serveren. En FTP-klient kan give filerne nye ændringstider ved download.
Databasedump med hashværdi.
Webserverens adgangs- og fejllogs, inklusive roterede og komprimerede filer.
Kontrolpanelets log samt SFTP- og SSH-log, som kun hostingudbyderen kan levere.
Bureauets repository med fuld historik og deployhistorik.
Logs fra sikkerhedsplugins, WAF og CDN, hvis de findes.

Hvor længe udbyderen beholder logs, varierer, og roterede logs forsvinder ofte efter få dage eller uger. Hvad der kan bestilles, og hvordan, står i hostingleverandørens logs. Selve gennemgangen af filer, database og logs i et WordPress-site er beskrevet i kompromitteret WordPress.

Hver part sikrer helst sit eget lag, men efter en fælles protokol: aftal, hvem der tager hvad og hvornår, og at alle kopier hashes og deles. Ellers ender sagen med tre forskellige udgaver af den samme log.

Spor, der peger på infrastrukturen

Indgangsvejen ligger sandsynligvis hos hostingudbyderen, hvis kompromitteringen kan føres tilbage til noget, som kunde og bureau ikke kunne påvirke:

Ændrede filer i flere kunders webroder på samme server, med samme mønster og i samme tidsrum.
Filer ejet af en anden systembruger end webstedets egen, eller ændret af en proces, der ikke er webserveren.
Logins i kontrolpanelet eller via SFTP og SSH fra ukendte adresser, før de første ondsindede filer dukker op.
En forældet serverkomponent med kendt sårbarhed, som udbyderen efter aftalen skulle holde opdateret.

Delt hosting er et særtilfælde. Er en anden konto på samme server kompromitteret, og er isolationen mellem kontiene svag, kan webstedet blive ramt uden egen fejl. Det kan kun vises med data fra serveren, ikke fra kundens konto alene.

Spor, der peger på applikationen

Bureauets lag er i spil, når indgangen er en sårbarhed i kode eller komponenter:

Den første ondsindede forespørgsel rammer en kendt sårbar sti i et plugin eller tema, og den installerede version var sårbar på tidspunktet.
Sårbarheden var offentlig, og en rettet version var udgivet, før kompromitteringen skete. Afstanden mellem rettelse og udnyttelse vejer tungt i den senere diskussion.
Bureauets egen kode har uploadfunktioner uden validering eller hemmeligheder i offentligt tilgængelige filer.

Filintegritet kan tjekkes mod kendte versioner. For WordPress-kernen sammenligner wp core verify-checksums filerne med de checksummer, WordPress.org udgiver for den installerede version. Hvordan tidslinjen for et sårbart plugin stilles op mod alternative forklaringer, står i indgangsvejen i WordPress.

Spor, der peger på kundens adgange

Kundens lag er i spil, når indgangen var et gyldigt login:

Vellykket login som en eksisterende administrator, uden forudgående udnyttelse af en sårbarhed i loggen.
En ny administratorbruger, oprettet af en eksisterende konto.
Mange mislykkede loginforsøg mod wp-login.php eller xmlrpc.php, efterfulgt af et vellykket login.
Delte konti, adgangskoder sendt på mail eller tidligere medarbejdere med aktive brugere.

Webserverloggen viser IP-adresse, tidspunkt og forespørgsel, men ikke brugernavnet. Koblingen til en bestemt bruger kræver CMS’ets egen log eller et auditplugin, hvis et sådant var installeret før hændelsen.

Typiske fejl i fortolkningen

Første fund er ikke første hændelse. Det script, der blev opdaget, kan være lagt ind uger efter selve indgangen. Gå tilbage i tid, før konklusionen drages.
Ændringstider kan sættes. Den, der har skriveadgang, kan give en fil en vilkårlig ændringstid. Sammenhold med webserverloggen og filsystemets øvrige tider.
Backuppen kan være inficeret. En backup fra før opdagelsen, men efter indgangen, viderefører problemet og flytter fokus.
Proxy og CDN skjuler adresser. Står der kun CDN’ets adresser i loggen, skal den egentlige klientadresse findes i et headerfelt eller hos CDN-udbyderen; se webserverlogs.
Fravær af logs er ikke frifindelse. Mangler SSH-loggen for perioden, kan infrastrukturen hverken udelukkes eller udpeges.

Dokumentation, alle parter kan efterprøve

Rapporten bør angive, hvilket lag hver kilde stammer fra, hvem der leverede den, og hvordan den blev hentet. Notér for hver fil eller eksport tidspunkt, metode, hashværdi og serverens tidszone. Byg tidslinjen i UTC, og marker tydeligt, hvor der er huller, fx perioder uden logs eller filer, der er ændret efter opdagelsen. Gem en liste over alle handlinger, der er foretaget på serveren efter hændelsen, så egne spor kan skilles fra angriberens.

Hvad sporene kan og ikke kan afgøre

Sporene kan ofte vise, hvilket lag indgangen gik igennem, og hvornår. De kan ikke alene afgøre, om den part, der ejede laget, har handlet ansvarspådragende. Det afhænger af kontrakten, driftsaftalen og hvad der var aftalt om opdateringer og overvågning. Den tekniske rapport bør derfor holde sig til fakta og sikkerhedsgrader og lade vurderingen af ansvar ligge hos parterne og deres rådgivere.

Når både bureau og hostingudbyder kan blive part, er en uvildig sikring og gennemgang ofte den hurtigste vej til et fælles faktuelt grundlag. Nielco IT har erfaring med incident response og hackerangreb og påtager sig ikke opgaver for begge parter i samme tvist.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Er computeren hacket? Tekniske tegn og hvad der sikres først · Sessioner og tokens: når adgangen fortsætter efter skift af adgangskode

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For webbureauer og hosting · 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