Mistenkt innbrudd i WordPress? Dette gjør dere den første timen

En ukjent administrator dukker opp. Forsiden sender besøkende videre til et annet nettsted. Filer er endret utenfor arbeidstid, eller sikkerhetsverktøyet varsler om mistenkelig aktivitet. Da er det lett å handle raskt, men i feil rekkefølge.

Den første timen bør brukes til tre ting: begrense videre skade, bevare informasjon om hendelsen og etablere kontroll over tilganger. Målet er ikke nødvendigvis å få nettsiden opp igjen umiddelbart. Målet er å få den tilbake i en tilstand dere kan stole på.

Denne planen er laget for WordPress-baserte bedriftsnettsteder. Den bør tilpasses ansvar, leverandører og teknisk oppsett før en hendelse oppstår.

Først: Avklar om dere faktisk har en hendelse

Et avvik er ikke alltid et innbrudd. En omdirigering kan skyldes feil konfigurasjon, og en ny fil kan komme fra en legitim oppdatering. Samtidig bør tydelige faresignaler behandles som en mulig sikkerhetshendelse til dere vet mer.

Aktuelle faresignaler er blant annet:

• Ukjente administratorbrukere eller uventede endringer i brukerroller.
• Endringer i innhold, tema eller innstillinger som ingen kjenner til.
• Omdirigeringer, nye annonser eller fremmed innhold.
• Varsler om skadelige filer, uvanlige innlogginger eller endret programkode.
• Store utslag i trafikk, serverbelastning eller utsending av e-post.
• Kunder som melder om advarsler, falske skjemaer eller mistenkelige meldinger.

Registrer når avviket først ble observert, hvem som oppdaget det, og hva vedkommende så. Ta skjermbilder, men unngå å klikke rundt mer enn nødvendig. Ikke slett brukere, filer eller logger før noen har vurdert om de kan være viktige for undersøkelsen.

Minutt 0–10: Samle ansvar og begrens aktiviteten

Utpek én person som leder hendelsen. Denne personen skal holde oversikt over beslutninger, tidspunkt og involverte. Det reduserer faren for at flere gjør motstridende endringer samtidig.

Kontakt driftsleverandøren eller den tekniske partneren tidlig. De kan ha tilgang til serverlogger, sikkerhetskopier og tiltak som ikke er tilgjengelige i WordPress. Avklar også hvem som kan beslutte å ta nettsiden midlertidig ned.

Hvis nettstedet aktivt skader besøkende, samler inn opplysninger gjennom et falskt skjema eller sprer uønsket innhold, bør trafikken begrenses. Det kan bety vedlikeholdsmodus, blokkering av offentlig tilgang eller isolering av det berørte miljøet. En kort periode uten nettside er ofte bedre enn å holde en kompromittert løsning åpen.

Ikke bruk den mistenkte WordPress-installasjonen til intern kommunikasjon om hendelsen. Bruk etablerte kanaler utenfor nettstedet.

Minutt 10–20: Sikre logger og et øyeblikksbilde

Før oppryddingen starter, må dere bevare det som kan forklare hva som har skjedd. Be driftsleverandøren sikre relevante logger og ta et øyeblikksbilde av berørte filer og databasen. Dette er ikke en backup som skal brukes til gjenoppretting, men dokumentasjon av tilstanden på hendelsestidspunktet.

Noter også hvilke varsler dere har mottatt, og hvilke filer, brukere eller innstillinger som ser ut til å være endret. Tidspunkter er særlig nyttige når informasjon fra flere systemer senere skal sammenlignes.

Unngå å stole blindt på loggen i én WordPress-utvidelse. Hvis angriperen har hatt omfattende tilgang, kan data inne i installasjonen være endret eller slettet. Serverlogger, innloggingslogger og varsler fra eksterne overvåkingssystemer kan gi et bredere bilde.

Minutt 20–35: Steng tilganger i riktig rekkefølge

Passordbytte er viktig, men det må gjøres fra en enhet dere har grunn til å stole på. Hvis en administrators datamaskin eller e-postkonto er kompromittert, kan nye passord også bli fanget opp.

Start med kontoene som kontrollerer resten av miljøet:

1. Sikre e-postkontoene som brukes til gjenoppretting og administrasjon.
2. Bytt tilgang til webhotell, server, kontrollpanel og domenestyring.
3. Bytt passord for WordPress-administratorer og avslutt aktive økter.
4. Bytt databasepassord, deploy-nøkler og andre tekniske hemmeligheter ved behov.
5. Tilbakekall applikasjonspassord, integrasjonsnøkler og tilganger dere ikke kan bekrefte.

Slå på flerfaktorautentisering der det mangler. Kontroller samtidig at kontaktinformasjon og gjenopprettingsmetoder ikke er endret. Et nytt passord hjelper lite dersom en uvedkommende fortsatt kan nullstille det eller bruke en eksisterende økt.

Ikke la alle ansatte få administratorrettigheter for å hjelpe til. Hendelsen bør håndteres av færrest mulig, med navngitte kontoer og dokumenterte oppgaver.

Minutt 35–50: Finn omfanget før dere gjenoppretter

Nå må dere undersøke mer enn det første symptomet. En fjernet omdirigering betyr ikke at årsaken er borte. Angriperen kan ha opprettet flere brukere, lagt inn skjult kode eller skaffet seg tilgang gjennom en annen tjeneste.

Kontrollen bør minst omfatte:

• WordPress-kjernen, aktive og inaktive utvidelser samt temaer.
• Administratorbrukere, roller og nylige innlogginger.
• Planlagte oppgaver og uventede endringer i konfigurasjonen.
• Filer som nylig er opprettet eller endret.
• Integrasjoner mot skjemaer, nettbutikk, analyse, e-post og kundesystemer.
• Andre nettsteder eller testmiljøer på samme serverkonto.

Se etter kjente sårbarheter i komponentene som var installert da hendelsen oppsto. En tilgjengelig oppdatering kan lukke sikkerhetshullet, men den fjerner ikke nødvendigvis endringer som allerede er gjort. Derfor er bare «oppdater alt» ikke en fullgod opprydding.

Dersom dere ikke kan fastslå omfanget, bør installasjonen behandles som kompromittert. Da er gjenoppbygging fra en kjent, ren tilstand tryggere enn å reparere enkeltfiler på mistanke.

Minutt 50–60: Velg en trygg vei tilbake

Før nettstedet åpnes igjen, må dere velge mellom rensing, gjenoppretting eller full gjenoppbygging. Valget avhenger av hvor god oversikt dere har, hvor omfattende endringene er, og hvilke sikkerhetskopier som finnes.

En backup er bare aktuell dersom den er fra før kompromitteringen. Den må kontrolleres før bruk. En eldre sikkerhetskopi kan dessuten inneholde den samme sårbare utvidelsen som åpnet døren første gang.

En forsvarlig gjenoppretting innebærer derfor mer enn å trykke på en gjenopprettingsknapp:

1. Bygg eller gjenopprett i et isolert miljø.
2. Kontroller filer, database og brukere.
3. Fjern komponenter som ikke er nødvendige.
4. Oppdater WordPress, temaer og utvidelser fra pålitelige installasjonspakker.
5. Bytt relevante nøkler og påloggingsopplysninger.
6. Test skjemaer, betaling, innlogging og andre kritiske funksjoner.
7. Åpne nettstedet først når ansvarlig person har godkjent tilstanden.

Etter den første timen: Følg med på om problemet kommer tilbake

Et gjenåpnet nettsted bør overvåkes tettere enn normalt. Følg med på nye administratorer, mislykkede innlogginger, filendringer, uventede oppgaver, trafikkmønstre og utsending av e-post. Kontroller også at sikkerhetskopiering fungerer etter gjenopprettingen.

Vurder om hendelsen kan ha berørt personopplysninger, kundedata eller betalingsinformasjon. Dette må håndteres av virksomhetens ansvarlige for personvern, ledelse og eventuelle juridiske rådgivere. Ikke vent med denne vurderingen til den tekniske oppryddingen er ferdig.

Kommunikasjonen bør være presis. Skill mellom det dere vet, det dere undersøker, og tiltakene som er gjennomført. Unngå bastante påstander om at «ingen data er berørt» før det faktisk er avklart.

Gjør planen klar før dere trenger den

Den største tidsbesparelsen kommer fra forberedelser. Lag et kort hendelseskort med kontaktpersoner, telefonnumre, leverandører, beslutningsmyndighet og plassering av tilganger. Dokumentet må være tilgjengelig selv om WordPress, e-post eller en enkelt medarbeider ikke er det.

Avklar også på forhånd hvem som kan stenge nettstedet, hvem som kan bestille teknisk bistand, og hvem som godkjenner gjenåpning. Test at nødvendige administratorer har flerfaktorautentisering, og fjern kontoer som ikke lenger skal brukes.

Til slutt bør dere øve på et enkelt scenario. Still spørsmålet: Hvis en ukjent administrator oppdages i morgen tidlig, hvem gjør hva de neste 60 minuttene? Hvis svaret avhenger av én person, et gammelt passord eller en leverandør ingen vet hvordan de kontakter, har dere funnet et sikkerhetsproblem før det ble en krise.