Nettstedet er hacket – begrens skaden og bygg opp rent

Hvis nettstedet videresender til svindel, viser fremmed innhold, sender spam eller har ukjente administratorer, må dere behandle det som en sikkerhetshendelse. Målet er ikke bare å få forsiden til å se normal ut. Dere skal stoppe skade, bevare nok spor til å forstå omfanget og hindre at angriperen kommer tilbake.

Ved utpressing, betydelige personopplysninger, betalingsdata, kritiske tjenester eller tegn på at flere systemer er berørt, bør virksomhetens sikkerhetsansvarlige, forsikring og kvalifisert hendelseshjelp involveres straks.

Første 15 minutter

1. Utpek én hendelsesleder og én loggfører.
2. Noter oppdagelsestidspunkt, tidssone, symptomer, URL-er og hvem som oppdaget dem.
3. Ta skjermbilder og lagre varsler, men ikke klikk på mistenkelige nedlastinger.
4. Finn hvilke brukere som er utsatt akkurat nå.
5. Kontakt hosting- eller plattformleverandør gjennom en kjent, ren kanal.
6. Stopp unødvendige publiseringer og automatiske deployer.
7. Bruk en kjent ren enhet til administrasjon.

WordPress anbefaler også dokumentasjon som første konkrete handling etter mistanke om kompromittering. Deres offisielle veiledning for et hacket WordPress-nettsted beskriver symptomer, miljødata og behovet for å forstå inngangsveien.

1. Begrens skaden uten å ødelegge spor

Containment avhenger av hvor angriperen har kontroll:

• La upstream-plattform, reverse proxy eller host vise en ren, statisk informasjonsside.
• Steng eller begrens kompromitterte administrasjons-, opplastings- og API-ruter.
• Deaktiver bekreftet kompromitterte nøkler og aktive sesjoner.
• Begrens origin eller server til hendelsesteamet hvis det kan gjøres trygt.
• Stopp utgående spam, skadelige redirects og nedlastinger.
• Behold en kontrollert snapshot eller kopi før omfattende endringer.

Ikke bruk det kompromitterte CMS-et til «vedlikeholdsmodus» hvis en angriper fortsatt har administrator- eller kodekjøring. En DNS-endring er heller ikke automatisk isolasjon: den kan bruke tid, påvirke e-post eller API-er og gjøre hendelsesforløpet vanskeligere å lese.

Hvis siden ikke aktivt skader brukere, kan et kort vindu for sikring av logger og snapshot være forsvarlig før nedstenging. Hvis den sprer skadevare eller phishing, veier brukerbeskyttelse tyngst.

2. Bevar data som kan forklare hendelsen

Sikre kopier av det som finnes, med begrenset tilgang:

• webserver-, applikasjons-, autentiserings- og WAF-logger
• kontrollpanel-, hosting-, DNS- og registrarlogger
• deployhistorikk, kildekode og endringslogg
• filsystem og database
• prosessliste, planlagte jobber, containere og serverkonfigurasjon
• ukjente brukere, SSH-nøkler, API-nøkler og webhooks
• varsler fra Search Console, nettlesere og sikkerhetsverktøy
• tidslinje over alle handlinger hendelsesteamet gjør

Eksporter logger før retensjon, rotasjon eller angriperen fjerner dem. Oppbevar kompromitterte data adskilt fra rene miljøer og dokumenter hvem som har håndtert dem. Ved mulig straffesak eller større hendelse må beviskrav avklares med fagpersoner.

NSM beskriver logger som viktige for hendelseshåndtering og understreker at de må beskyttes. Se NSMs grunnprinsipper for IKT-sikkerhet .

3. Kartlegg omfanget før dere erklærer siden ren

Undersøk kontrollkjeden rundt nettstedet:

Kontroller nabosider og andre tjenester som deler konto, nøkkel eller server. Et synlig defacement kan være den minst alvorlige delen av hendelsen.

Søk etter persistence, ikke bare den filen som viser symptomet. Angripere kan legge kode i uploads, database, mu-plugins, tema, .htaccess, planlagte jobber eller deploysystem.

4. Roter tilganger i riktig rekkefølge

Gjør dette fra en ren enhet og helst etter at aktiv tilgang er begrenset. Ellers kan angriperen lese de nye hemmelighetene eller opprette nye brukere.

1. Sikre e-post og identitetsleverandør som brukes til recovery.
2. Sikre registrar og DNS.
3. Sikre hosting, sky, kildekode og deploy.
4. Revoke aktive sesjoner, tokens, API-nøkler og SSH-nøkler.
5. Roter database-, CMS- og integrasjonshemmeligheter.
6. Tving nye, unike passord og MFA for privilegerte brukere.
7. Fjern ukjente kontoer og gjennomgå roller.

Hvis secrets kan ha ligget på den kompromitterte serveren, må de anses eksponert. Roter dem igjen etter ren gjenoppbygging dersom midlertidige nøkler ble brukt under hendelsen.

5. Finn inngangsveien og lukk den

Mulige veier inkluderer:

• sårbar eller forlatt plugin, tema eller CMS-versjon
• stjålet administrator-, hosting- eller e-postsesjon
• lekket deploy- eller API-nøkkel
• kompromittert lokal enhet
• for brede fil-, database- eller skytillatelser
• usikker opplasting eller kodekjøring
• angrep mot en annen side på samme konto
• leverandør- eller avhengighetskompromittering

Tidslinje, logger, filendringer og kjente sårbarheter må ses sammen. «Svak plugin» er ikke en rotårsak uten at dere kan vise hvilken komponent, versjon og vei som ble brukt.

Oppdatering etter kompromittering er nødvendig når en sårbar versjon var eksponert, men ikke kjør en blind oppdatering over det eneste bevismaterialet.

6. Bygg opp fra et kjent rent grunnlag

Den tryggeste løsningen er ofte å opprette et nytt miljø med vedlikeholdt programvare og hente kode fra en kjent, kontrollert kilde. Gjenopprett bare data og innhold dere har vurdert.

• Installer kjerne og avhengigheter fra offisielle eller verifiserte kilder.
• Ta bare med plugins og temaer virksomheten fortsatt trenger.
• Sammenlign egne filer mot versjonskontroll eller kjent ren release.
• Vurder databaseinnhold for nye brukere, skript, redirects og injeksjoner.
• Bruk nye secrets og nøkler.
• Legg til strammere rettigheter, MFA, logging og overvåking før åpning.
• Test i isolert miljø.

En backup er ikke ren bare fordi den er eldre enn oppdagelsen. Angriperen kan ha hatt tilgang lenge. En skanner som ikke finner kjent skadevare er heller ikke bevis på at miljøet er rent.

Hvis dere må rense i stedet for å bygge opp på nytt, bruk flere datakilder og la en kompetent person vurdere ukjent kode. Dokumenter det som ikke kunne verifiseres.

7. Verifiser før nettstedet åpnes

• Test som vanlig bruker, søkemotorbruker og mobilbruker; noen angrep viser bare innhold til bestemte referrere eller user agents.
• Kontroller adminbrukere, filer, planlagte jobber, database og redirects på nytt.
• Verifiser DNS, HTTPS, sikkerhetsheadere og eksterne integrasjoner.
• Test skjema, betaling, innlogging og passordreset.
• Kontroller at origin ikke kan omgå eventuelle beskyttelseslag.
• Kjør en restore-test og behold incident-snapshot adskilt.
• Aktiver skjerpet overvåking før full trafikk.

Hvis Google har vist en sikkerhetsadvarsel, bruk eksemplene i Search Console til kontroll. Når innholdet er ryddet og inngangsveien lukket, kan dere be om ny vurdering i Security Issues .

8. Vurder personvern, varsling og anmeldelse parallelt

Et brudd på personopplysningssikkerheten kan gjelde:

• konfidensialitet: uvedkommende har fått tilgang
• integritet: opplysninger er endret
• tilgjengelighet: opplysninger eller tjenesten er utilgjengelig eller slettet

Den behandlingsansvarlige skal som hovedregel melde et brudd til Datatilsynet uten ugrunnet opphold og når mulig innen 72 timer etter at virksomheten fikk kjennskap til det, med unntak når bruddet sannsynligvis ikke medfører risiko for fysiske personer. Databehandler varsler normalt den behandlingsansvarlige etter avtalen.

Ikke vent på komplett forensikk før fristen vurderes. Datatilsynet åpner for trinnvis melding når all informasjon ikke er klar innen 72 timer . Vurder også om berørte personer skal informeres, og om politi, NSM, sektorregelverk, forsikring eller avtalepart skal varsles.

Involver personvernombud eller juridisk kompetanse tidlig. Dokumenter vurderingen også når konklusjonen er at hendelsen ikke skal meldes.

9. Etter hendelsen

Hold et møte uten skyldfordeling og dokumenter:

• rotårsak og alle medvirkende kontrollsvikt
• faktisk tidslinje og hvor lenge angriperen kan ha hatt tilgang
• data, systemer og personer som ble berørt
• hva som oppdaget hendelsen, og hva som burde oppdaget den tidligere
• hvorfor skadebegrensning og gjenoppretting tok den tiden det tok
• konkrete tiltak, eier og frist
• nye tester eller varsler som skal hindre gjentakelse

Oppdater hendelsesplan, kontaktliste, backup, restore-test, tilgangsrutine og komponentinventar. Øv på en kortere versjon av scenarioet når tiltakene er innført.

Hvis siden hostes av Vymo

Hvis en enkel nettside Vymo setter opp og hoster viser ukjent innhold eller skadelig redirect, send straks hele URL-en, tidspunkt, skjermbilde og hva dere observerte . Ikke send passord, private nøkler eller kompromitterte filer i en vanlig e-post.

Vymo publiserer foreløpig ikke en garantert incident-responstid, automatisk backupfrekvens eller selvbetjent restore for standardtilbudet. Virksomheter med krav til hendelsesberedskap, loggretensjon, RPO eller RTO må avklare dette skriftlig før bestilling .