Kompromitteret WordPress: webserverlogs, filændringer og databasen

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

En kompromitteret WordPress-side undersøges i tre lag, der skal sikres samlet: filerne på serveren, som viser, hvad der er tilføjet eller ændret; databasen, som viser brugere, indstillinger og indhold; og logs fra webserver, hosting og eventuel WAF eller CDN, som viser, hvilke forespørgsler der førte til ændringerne. Filerne og databasen viser tilstanden, logsene viser forløbet. Den hyppigste fejl er at gendanne fra backup eller køre et oprydningsplugin, før de tre lag er sikret, fordi det overskriver netop de spor, der kan datere og forklare angrebet.

Haster det? Webserverens adgangs- og fejllogs roteres ofte efter få dage eller uger hos hostingudbyderen, og databasen ændrer sig, så længe siden kører. Se akut forensisk sikring; hastesager koster ekstra.

Grundlæggende bevissikring af en WordPress-side er beskrevet på digitalbevissikring.dk, og virksomhedens handleplan på Hjemmesiden eller webshoppen er hacket. Her er den tekniske undersøgelse. Når ansvaret er til diskussion, bruges sporene til at teste forklaringerne på, hvordan angriberen kom ind; den konklusion står i Indgangsvejen i WordPress.

Sikring af de tre lag

Filer

Tag en komplet kopi af webroden og eventuelle mapper uden for den, fx konfiguration og logs. Brug en metode, der bevarer filernes tidsstempler og rettigheder, fx et arkiv lavet på serveren med de rette indstillinger, eller et snapshot af hele serveren eller containeren, hvis hostingen tillader det. En kopi hentet over FTP kan sætte nye tidsstempler på alle filer. Notér metode, kommando og tidspunkt, og beregn hashværdi af arkivet og gerne en liste over hashværdier for hver fil.

Database

Tag et konsistent dump af hele databasen, ikke kun WordPress-tabellerne, fordi der kan være oprettet nye tabeller. Notér databaseversion, tegnsæt og de indstillinger, der er brugt. → Konsistent sikring af en database

Logs

Webserverens adgangs- og fejllogs ligger ofte hos hostingudbyderen og roteres efter få dage eller uger. Bed om alle tilgængelige logs i rå form: adgangslog, fejllog, PHP-fejllog, logs for FTP, SFTP og SSH, kontrolpanelets log og eventuelle logs fra WAF eller CDN. Bed samtidig om bevarelse af de logs, der endnu ikke er roteret ud. → Hostingleverandørens logs

Rækkefølge og forbehold

Sikr i rækkefølgen logs, database, filer, fordi logs roterer hurtigst, og fordi databasen ændrer sig, så længe siden kører. Skal siden tages ned eller sættes i vedligeholdelsestilstand undervejs, så notér tidspunktet: En vedligeholdelsestilstand skriver typisk til database eller filsystem og ændrer dermed det, der undersøges. Har hostingudbyderen allerede ryddet op eller gendannet, så bed om udbyderens egne snapshots og en beskrivelse af, hvad der er gjort hvornår.

Arbejd på en kopi

Analysen foregår på kopierne, ikke på den kørende server. Det er ofte nyttigt at genskabe siden i et isoleret testmiljø uden adgang til internettet, så indstillinger og indhold kan undersøges i WordPress’ egen brugerflade uden at påvirke den rigtige side. Testmiljøet må ikke kunne sende mail eller kontakte eksterne adresser, fordi indsat kode kan forsøge netop det.

Filerne: hvad er ændret?

Sammenlign med kendte versioner

WordPress-kernen kan sammenlignes med de officielle kontrolsummer for den installerede version, og plugins og temaer fra det officielle katalog kan sammenlignes med den udgivne version. Alt, der afviger eller ikke findes i den officielle pakke, er kandidater til nærmere undersøgelse. Premium-plugins og egenudviklede temaer har ingen offentlig reference; her må der sammenlignes med leverandørens pakke eller en ældre backup.

Typiske fund

PHP-filer i mapper, hvor de ikke hører hjemme, særligt uploadmappen,
ændrede kernefiler eller konfigurationsfilen,
nye eller ændrede regler i serverens omskrivningsfil, der sender besøgende videre,
ukendte plugins, ofte med neutrale navne, som kan være skjult fra pluginlisten,
filer med tilsløret kode.

Fund dokumenteres med sti, hashværdi, tidsstempler, ejer og rettigheder samt en beskrivelse af funktionen. Den ejer, filen er skrevet af, kan vise, om den er skabt gennem webserverens proces eller via en FTP- eller SSH-konto, og det peger på forskellige indgangsveje. Selve koden gengives ikke i rapporten ud over det, der er nødvendigt for at forklare fundet.

Tidsstempler

Filernes ændringstidspunkt kan sættes af den, der har skriveadgang, og bruges ofte til at få nye filer til at ligne gamle. På Linux kan inode-ændringstiden (ctime) ikke sættes på samme måde fra almindelige programmer og er derfor nyttig som kontrol. Er en fil med en gammel ændringstid oprettet for nylig ifølge ctime, er det et tydeligt tegn. Bevares ctime ikke i kopien, skal den registreres på serveren før kopieringen. → Linux-servere: journald, auth-log og shellhistorik

Databasen: brugere, indstillinger og indhold

Gennemgå mindst:

Brugertabellen: nye administratorer, registreringstidspunkter og ændrede e-mailadresser. Rettigheder ligger i brugermetadata og skal læses derfra.
Indstillingstabellen: sidens adresse, aktive plugins, planlagte opgaver og ukendte indstillinger, der indeholder kode eller adresser.
Indhold: indsat JavaScript eller skjulte links i indlæg, sider og widgets. Revisioner kan vise, hvornår indholdet blev ændret, og af hvilken bruger.

Databasen indeholder sjældent pålidelige tidsstempler for ændringer af indstillinger. Tidspunktet må ofte findes i adgangsloggen ved at koble ændringen til den forespørgsel, der skabte den.

Logs: hvordan og hvornår?

Adgangsloggen er den vigtigste kilde til forløbet. Søg efter:

forespørgsler til de filer, der er fundet, især første forespørgsel til en mistænkelig PHP-fil. Det giver ofte det tidligste tidspunkt for kompromitteringen,
POST-forespørgsler til usædvanlige filer,
login-forsøg mod loginsiden og XML-RPC, og vellykkede logins efterfulgt af administrative handlinger,
forespørgsler til sårbare plugins, som kan pege på indgangsvejen,
IP-adresser og brugeragenter, der går igen på tværs af hændelserne.

Står siden bag en CDN eller en reverse proxy, viser webserverens log måske kun proxyens adresser. Den rigtige klientadresse står i et særskilt felt eller i proxyens egne logs. Feltbetydninger og tidszoner er beskrevet i Webserverlogs (IIS, Apache, Nginx).

Persondata og kundedata

Er siden en webshop eller har den brugerkonti, bliver spørgsmålet, om persondata er hentet. Databasen viser, hvilke data der fandtes. Adgangsloggen kan vise forespørgsler, der returnerede usædvanligt store svar, adgang til eksportfunktioner eller databaseværktøjer, og kald til filer, der kunne læse databasen direkte. Mængden af sendte bytes pr. forespørgsel er her et vigtigt felt. Fravær af sådanne spor udelukker ikke udtræk, hvis angriberen havde adgang til databasen ad andre veje.

Fejlkilder

Sikkerhedsplugins og backupplugins ændrer filer og database løbende og kan forveksles med angriberens ændringer.
Automatiske opdateringer ændrer kernefiler og plugins på bestemte tidspunkter.
Delt hosting kan betyde, at andre sider på samme server er kilden.
Kort logopbevaring hos hosting kan betyde, at den første kompromittering ligger før det tidligste logtidspunkt.
Tidszoner: Webserverlogs, databasen og WordPress’ egne indstillinger kan bruge hver sin tidszone.

Hvad undersøgelsen kan og ikke kan vise

Undersøgelsen kan typisk vise, hvad der er ændret, hvornår ændringerne blev aktive, og ofte hvordan adgangen blev opnået, hvis logs dækker perioden. Den kan sjældent identificere, hvem der stod bag. Spørgsmålet om indgangsvejen og ansvaret mellem webbureau og kunde er behandlet i Indgangsvejen i WordPress: sårbart plugin eller svag adgang?

Dokumentation

Rapporten bør angive sikringsmetode for filer, database og logs, hashværdier, WordPress-, plugin- og temaversioner, en liste over fundne ændringer med tidsstempler og kilde, og en tidslinje, der kobler logforespørgsler til ændringerne.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: QR-koder og delte dokumenter som phishing: særlige spor · Indgangsvejen i WordPress: sårbart plugin eller svag adgang?

→ 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