Etter et innbrudd på et WordPress-nettsted går den første timen til dokumentasjon, ikke til opprydding. Først sikrer jeg bevis, så finner jeg angrepsveien, og først da fjerner jeg skadevaren, på en kopi av nettstedet og borte fra produksjon. Filer som slettes i blinde, visker ut sporene etter angrepsveien, og en gammel kopi som gjenopprettes uten å sjekke når infeksjonen startet, kan ta med seg den skadelige koden tilbake.
Denne siden beskriver tegnene på innbrudd, rekkefølgen jeg jobber i etter en hendelse, innbrudd i WooCommerce-butikker og i løsninger på andre systemer, og pliktene etter personopplysningsloven som starter i det øyeblikket innbruddet blir oppdaget. Vil du gå gjennom oppryddingen selv, ligger hele fremgangsmåten med kommandoer i guiden til opprydding på et hacket WordPress-nettsted.
WordPress hacket: tegn på innbrudd
Tegn som som regel betyr innbrudd, og det første jeg gjør da.
- Hva du ser: Google viser en advarsel ved nettstedet ditt, eller Search Console melder om et sikkerhetsproblem
- Hva jeg gjørJeg sjekker rapporten om sikkerhetsproblemer i Search Console og listen over adresser som er meldt. Det er utgangspunktet for diagnosen og for forespørselen om ny vurdering senere.
- Hva du ser: Search Console har en eier du ikke har lagt til
- Hva jeg gjørJeg noterer eieren som bevis og fjerner tilgangen. Kontroll av eiere i Search Console hører til de første stegene etter et oppdaget innbrudd.
- Hva du ser: Brukerlisten har en ukjent administratorkonto
- Hva jeg gjørJeg går gjennom alle administratorkontoer og cron-jobber. Kontoer som ingen har opprettet, sletter jeg etter at dataene deres er lagret som bevis.
- Hva du ser: Kjernefilene stemmer ikke med originalen
- Hva jeg gjørJeg kjører wp core verify-checksums og sammenligner filene i utvidelser og temaer med versjonene fra de offisielle kildene.
- Hva du ser: Nettstedet sender besøkende videre til fremmede adresser eller sprer skadelig kode
- Hva jeg gjørJeg slår på vedlikeholdsmodus, slik at nettstedet ikke infiserer besøkende, og tar en kopi av filer og database som bevis.
- Hva du ser: Kunder i nettbutikken melder om rar oppførsel i kassen eller ved Vipps-betalingen
- Hva jeg gjørJeg behandler det som et mulig brudd på personopplysningssikkerheten. Jeg sikrer bevis, noterer tidspunktet for meldingen og varsler deg, fordi fristene etter GDPR løper fra nå.
- Hva du ser: Infeksjonen kommer tilbake noen dager etter oppryddingen
- Hva jeg gjørJeg leter etter angrepsveien som ikke ble stengt: en bakdør i databasen, en cron-jobb, en gammel konto. Opprydding uten stengt angrepsvei holder ikke.
Den første timen etter et innbrudd: hva du kan gjøre selv
Før du skriver til meg eller noen andre, gjør fem ting. Ikke slett noen filer. Ta en kopi av filer og database, selv om den er infisert, fordi den er bevis. Skriv ned dato og klokkeslett for når du oppdaget innbruddet. Sjekk i Search Console om det står noen ukjente på listen over eiere. Hvis nettstedet sprer skadevare eller sender besøkende videre, slå på vedlikeholdsmodus.
Bytt deretter passord til WordPress-panelet, SFTP og databasen. Ikke gjenopprett en gammel sikkerhetskopi før du vet når infeksjonen startet. En kopi fra forrige uke hjelper ikke hvis den skadelige koden har ligget på nettstedet i en måned.
Oppryddingen går raskere når jeg med en gang får tilgang til kontrollpanelet hos webhotellet, serverloggene, SFTP, databasen og Search Console. Er tilgangene spredt på flere personer eller firmaer, samle dem på ett sted før vi starter.
Fjerne skadevare fra WordPress: rekkefølgen
Hvert steg ender med noe som kan kontrolleres: en kopi, en rapport, en liste over endringer.
Databehandleravtale før tilgang
Før jeg får tilgang til nettstedet, signerer vi en databehandleravtale (GDPR artikkel 28). På et infisert nettsted ligger opplysninger om kundene dine.
Første time: sikring av bevis
Kopi av filer og database som bevis, notert tidspunkt for oppdagelsen, vedlikeholdsmodus hvis nettstedet sprer skadevare, og kontroll av eiere i Search Console. Fra oppdagelsen løper fristene etter GDPR.
Diagnose som eget trinn
Diagnosen har egen pris og avgrenset omfang. Resultatet er årsaken, omfanget av reparasjonen og kostnaden, skriftlig. Oppryddingen starter når du har bekreftet omfanget.
Angrepsveien på en kopi av nettstedet
Jeg jobber på en kopi, ikke i produksjon. Angrepsveien finner jeg i serverloggene, med wp core verify-checksums og ved å sammenligne filene i utvidelser og temaer med rene versjoner.
Opprydding i filer og database
Jeg fjerner skadevare og bakdører fra filer og database, sjekker administratorkontoer og cron-jobber, og henter kjerne og utvidelser fra rene kilder.
Nye passord og tilganger
Jeg bytter passord til WordPress-panelet, SFTP og databasen. De gamle innloggingsdataene regner jeg som kjent for angriperen.
Én publisering som kan reverseres
Den rensede versjonen publiserer jeg i ett steg som kan rulles tilbake. Jeg legger inn sikring mot den angrepsveien som ble funnet, og beskriver årsaken og forebyggingen skriftlig.
Ny vurdering hos Google
Når nettstedet er rent, sender jeg forespørsel om ny vurdering i rapporten om sikkerhetsproblemer i Search Console.
Det siste steget har jeg ikke kontroll over. Ifølge Googles hjelpesider tar vurderingen fra noen dager til noen uker, og Google sender en e-post når den er ferdig. Derfor lover jeg ingen dato for når advarselen forsvinner fra søkeresultatene.
Hva koster det å fjerne skadevare fra WordPress
Prisen på oppryddingen gir jeg ikke på forhånd, fordi den avhenger av hva diagnosen finner: om infeksjonen gjelder noen få filer eller også databasen og kontoene, om sikkerhetskopiene er eldre enn infeksjonen, og om angrepsveien er en utvidelse som bare kan oppdateres. Diagnosen er et eget, avgrenset trinn med egen pris. Resultatet er årsaken, omfanget av reparasjonen og kostnaden, skriftlig. Oppryddingen starter når du har bekreftet omfanget.
Et nettsted uten vedlikeholdsavtale går via WordPress-reparasjon, der prisen kommer etter at du har beskrevet hendelsen. Hva fast vedlikehold med skanning etter skadevare og daglige kopier koster, står på siden vedlikehold av WordPress, pris.
Hacket WooCommerce-butikk
Et innbrudd i en nettbutikk skiller seg fra et innbrudd på et bedriftsnettsted ved at det nesten alltid gjelder personopplysninger. I butikkens database ligger kundekontoer, leveringsadresser, telefonnumre og bestillingshistorikk. Derfor går jeg i en butikk fra første time ut fra at det kan dreie seg om et brudd på personopplysningssikkerheten, og noterer med en gang tidspunktet for oppdagelsen, som jeg gir videre til deg som behandlingsansvarlig.
Rekkefølgen er den samme som for et bedriftsnettsted, men kontrollen går bredere. I tillegg til filer, database, kontoer og cron-jobber sjekker jeg betalingsutvidelser som Vipps MobilePay, fraktutvidelser og koblinger mot andre systemer, fordi hver av dem har sine egne API-nøkler. Nøkler som kan ha lekket, må byttes også hos betalingsløsningen, i ERP-systemet og i fakturatjenesten som sender EHF via Peppol, ikke bare i WordPress. Byttet krever tilgang til panelene for disse tjenestene, så det gjør vi vanligvis sammen.
Etter oppryddingen tester jeg hele kjøpet, fra handlekurv via kundedata og frakt til betaling, uten å legge inn en ekte bestilling, før butikken begynner å selge igjen. En butikk der denne testen skal gå hele tiden, drifter jeg på Store Reliability Plan. Når handlekurven eller betalingen ikke virker etter innbruddet og salget må i gang igjen, er WooCommerce rescue sprint riktig tjeneste.
Typisk situasjon: butikk med kundekontoer og en utdatert utvidelse
Et typisk tilfelle som butikkeiere kommer med, ser slik ut: butikken har vært i drift i noen år, har kundekontoer og et dusin utvidelser, og flere av dem er ikke oppdatert på måneder. Noen legger merke til en ukjent administratorkonto eller rar oppførsel i kassen. I en slik butikk sikrer jeg først bevis og noterer tidspunktet for oppdagelsen, og sjekker deretter om og hvilke kundeopplysninger som kan ha blitt lest. Den beskrivelsen gir jeg til deg, fordi det er du som avgjør om og når bruddet skal meldes til Datatilsynet. Viser det seg at angrepsveien er egen kode, for eksempel et REST-endepunkt uten rettighetssjekk, fortsetter arbeidet som et oppdrag for en WordPress-spesialist.
Typisk situasjon: bedriftsnettstedet sender mobilbrukere videre
En annen typisk situasjon: eieren av et bedriftsnettsted får høre fra en kunde at nettstedet åpnet på mobil sender videre til et fremmed nettsted, mens det ser normalt ut på PC. Et slikt symptom betyr som regel skadelig kode i filene eller i databasen som bare slår til for utvalgte besøkende. Også her starter jeg med en kopi som bevis og vedlikeholdsmodus, og angrepsveien leter jeg etter i serverloggene og ved å sammenligne filene med rene versjoner. Har nettstedet et kontaktskjema, sjekker jeg også om den skadelige koden hadde tilgang til innsendte skjemaer, fordi det er personopplysninger.
Innbrudd på nettsted i Drupal, TYPO3, Laravel eller Symfony
Den samme rekkefølgen (bevis, angrepsvei, opprydding på en kopi, nye tilganger, én publisering som kan reverseres) gjelder i systemer utenfor WordPress. Det som skiller, er verktøyene: i Drupal og TYPO3 henter jeg kjerne og moduler fra rene kilder via Composer, og i en applikasjon i Laravel eller Symfony sammenligner jeg koden på serveren med kodelageret.
En versjon uten sikkerhetsstøtte får ikke rettinger for nye sårbarheter. Drupal 7 har vært uten sikkerhetsstøtte siden 5. januar 2025, og Drupal 10 mister den 9. desember 2026. Den gratis støtten for TYPO3 12.4 tok slutt 30. april 2026. Etter opprydding på et nettsted med en slik versjon holder det ikke å fjerne den skadelige koden; det trengs en plan for oppdatering eller migrering til WordPress. For Drupal 10 beskriver jeg alternativene i artikkelen om Drupal 10 og slutt på støtte.
Innbrudd og personvern: Datatilsynet, 72 timer og NSM
Hvis noen gjennom innbruddet kan ha fått tilgang til personopplysninger (kundekontoer, bestillinger, innsendte skjemaer), begynner fristene i personvernforordningen å løpe. GDPR gjelder i Norge gjennom personopplysningsloven og EØS-avtalen. Artikkel 33 nr. 1 sier at den behandlingsansvarlige melder bruddet til tilsynsmyndigheten uten ugrunnet opphold og om mulig senest 72 timer etter å ha fått kjennskap til det, med mindre bruddet sannsynligvis ikke medfører en risiko for de registrertes rettigheter og friheter. Kommer meldingen senere, må den begrunne forsinkelsen. Er risikoen høy, krever artikkel 34 nr. 1 i tillegg at de registrerte varsles uten ugrunnet opphold.
I Norge er det Datatilsynet som tar imot meldingen. Datatilsynet skriver på sin side om avvik at et avvik som hovedregel skal meldes så snart som mulig, og meldingen sendes via skjemaet meld avvik til Datatilsynet. Selve sikkerhetshendelsen kan du melde til Nasjonalt cybersikkerhetssenter (NCSC) i Nasjonal sikkerhetsmyndighet, på [email protected]. Fremgangsmåten står på NSM sin side om digital hendelseshåndtering.
Hvem som har ansvar for hva ved brudd på personopplysningssikkerheten
Rollefordelingen følger av GDPR og av databehandleravtalen vi signerer før jeg får tilgang til nettstedet.
Du, som behandlingsansvarlig
- Du avgjør om bruddet skal meldes til Datatilsynet (GDPR artikkel 33)
- Du avgjør om de registrerte skal varsles (GDPR artikkel 34)
- Du sender meldingen til Datatilsynet og holder styr på 72-timersfristen fra du fikk kjennskap til bruddet
- Du har kontakten med kundene hvis opplysninger kan ha lekket
Jeg, som databehandler
- Jeg varsler deg uten ugrunnet opphold når jeg får kjennskap til bruddet (GDPR artikkel 33 nr. 2)
- Jeg gir deg faktaene du trenger til meldingen: tidspunkt for oppdagelsen, omfanget av filer og data, angrepsveien som ble funnet
- Jeg melder ikke avviket til Datatilsynet på dine vegne, med mindre avtalen sier det
- Jeg fjerner følgene av innbruddet og stenger angrepsveien innenfor omfanget i avtalen
Ansvaret mellom partene, også for følgene av et innbrudd, står i avtalen. Derfor signerer vi databehandleravtalen før første tilgang til nettstedet. Til meldingen har du nytte av det som kommer ut av de første stegene i arbeidet mitt: tidspunktet for oppdagelsen, hvilke filer og tabeller infeksjonen gjaldt, og angrepsveien som ble funnet. Hele rapporten med årsaken får du skriftlig.
Krav til hendelsesrapportering i sektorregelverk som NIS2 og DORA kan gå lenger enn GDPR. Om de gjelder for virksomheten din, og hva det betyr for WordPress-infrastrukturen, går vi gjennom i en vurdering av NIS2 og DORA.
Rydde opp, gjenopprette eller bytte ut
Valget avhenger av når infeksjonen startet og hva som er kilden.
Du har en sikkerhetskopi som sikkert er eldre enn infeksjonen, og angrepsveien er kjent.
Jeg gjenoppretter den kopien på en arbeidskopi, stenger angrepsveien og publiserer først da. Innhold og bestillinger som er lagt til etter datoen for kopien, må flyttes over separat.
Du vet ikke når infeksjonen startet, eller alle kopiene er nyere enn den.
Jeg rydder opp på en kopi av nettstedet: filer, database, kontoer, cron-jobber, kjerne og utvidelser fra rene kilder.
Kilden er et tema eller en utvidelse som ingen lenger videreutvikler.
Jeg fjerner den eller foreslår en erstatning. Krever byttet ny kode, får det et eget tilbud.
Løsningen går på en CMS-versjon uten sikkerhetsstøtte.
Etter oppryddingen trengs en plan for oppdatering eller migrering. Uten den står angrepsveien åpen.
Nettstedet er nede etter innbruddet, og du har ingen vedlikeholdsavtale.
Ingenting tyder på innbrudd, men du vil vite om nettstedet er rent.
Sikkerhetsrevisjon: rapport innen 5 virkedager, sortert etter prioritet.
Slik oppdager du et innbrudd før Google gjør det
En advarsel i Googles søkeresultater er et sent symptom. Før det setter innbruddet spor i filene og i databasen. I vedlikeholdet sammenligner jeg filene i kjerne, utvidelser og temaer med sjekksummene fra de offisielle kildene (wp checksum core, wp checksum plugin --all), så en endret fil blir synlig i løpet av et døgn. Skanningen etter skadevare ser etter kjente mønstre av skadelig kode, og den månedlige gjennomgangen av administratorkontoer fanger opp kontoer som ingen har opprettet.
Den andre kilden er sårbarhetsdatabaser, blant annet Patchstack og WPScan. Når en sårbarhet dukker opp i en utvidelse du har på nettstedet, oppdaterer jeg den utenom den ukentlige syklusen. Det stenger angrepsveien før noen rekker å bruke den.
Retting av kode etter et innbrudd
Når angrepsveien var nettstedets egen kode, for eksempel et skjema i en utvidelse skrevet for bedriften eller en funksjon i temaet som ikke kontrollerte inndata, retter jeg den som del av sikringen mot angrepsveien. Rettingen går inn i versjonskontroll, og koden sjekker jeg med PHP_CodeSniffer og reglene i WordPress Coding Standards, som også har sikkerhetsregler, og med statisk analyse i PHPStan. I løsninger utenfor WordPress følger jeg standarden PSR-12. Før publisering går jeg gjennom endringen en gang til, adskilt fra skrivingen. Krever rettingen at en større del av koden bygges om, beskriver jeg det og gir et eget tilbud.
Hva du får etter oppryddingen
Etter oppryddingen får du en skriftlig beskrivelse: hvordan innbruddet skjedde, hva som ble endret i filene og i databasen, hvilke tilganger som ble byttet, og hvilken sikring jeg la inn mot angrepsveien. Beskrivelsen er nyttig når du melder avviket til Datatilsynet, hvis du gjør det, og i dialogen med webhotellet. Den rensede versjonen er publisert i ett steg som kan rulles tilbake, og en kopi av den infiserte versjonen blir liggende som bevis.
Vil du at noen skal følge med på nettstedet fast etter oppryddingen, går det over i vanlig månedlig vedlikehold.
Hva jeg ikke lover etter et innbrudd
Jeg gir ingen garanti for at nettstedet aldri blir hacket igjen. Oppryddingen fjerner den skadelige koden og stenger angrepsveien som ble funnet, men nye sårbarheter i utvidelser dukker stadig opp. Jeg garanterer heller ikke reparasjonstid: den avhenger av hvor omfattende infeksjonen er, av tilgangen til webhotellet og av om sikkerhetskopiene er eldre enn infeksjonen. Jeg lover ingen dato for når Google fjerner advarselen, fordi det er Google som gjør vurderingen.
Du får rekkefølgen beskrevet over, et skriftlig diagnoseresultat før oppryddingen og en rapport med årsak og forebygging etterpå.
Slik reduserer vedlikeholdet risikoen for et nytt innbrudd
I vedlikeholdet av WordPress-nettsider tar jeg sikkerhetskopier daglig og oppbevarer dem i minst 30 dager, skanner filene etter skadevare og kontrollerer filintegriteten, og en gang i måneden går jeg gjennom administratorkontoene. Overvåkingen sjekker at nettstedet svarer hvert 1. til 5. minutt og sender meg et varsel når det slutter å svare. Finner skanningen noe, isolerer jeg de infiserte delene, gjenoppretter en ren versjon fra kopien, legger inn sikring mot angrepsveien og beskriver hendelsen i den månedlige rapporten.
Tretti dager med kopier betyr mye ved innbrudd som blir oppdaget sent. Er infeksjonen to uker gammel, finnes det fortsatt en versjon fra før den i historikken. Jeg sjekker likevel når infeksjonen startet, før jeg gjenoppretter noe.
En utdatert utvidelse med en publisert sårbarhet er en åpen angrepsvei. Mot den beskytter en fast oppdateringssyklus, som jeg beskriver på siden om WordPress-oppdateringer. Hva vedlikehold med skanning og kopier koster, finner du på siden vedlikehold av WordPress, pris.
Neste steg hvis nettstedet er infisert nå: ikke slett noe, ta en kopi av filer og database, skriv ned klokkeslettet du oppdaget det, og skriv til meg med adressen til nettstedet og en beskrivelse av symptomene.
