Skadevare på nettstedet – slik undersøker du mistanken

En ukjent redirect eller advarsel i nettleseren kan være skadevare, men også en feilkonfigurert annonse, tredjepartsskript eller nettleserutvidelse. En treg side er enda svakere bevis. Målet med den første undersøkelsen er derfor ikke å «kjøre en skanner», men å svare på tre spørsmål:

1. Kan symptomet gjenskapes på en trygg og kontrollert måte?
2. Hvilken komponent eller konto er endret uten godkjenning?
3. Kan brukere, data eller andre systemer være utsatt nå?

Hvis nettstedet aktivt sender besøkende til svindel, leverer skadelige filer eller viser ukjente innloggingsskjemaer, skal brukerbeskyttelse og hendelseshåndtering starte med en gang. Følg hendelsesplanen for et hacket nettsted parallelt med undersøkelsen.

Skadevare, hacket innhold eller phishing?

Begrepene blandes ofte, men funnet bør beskrives presist:

De kan opptre sammen. Et nettsted kan også være kompromittert uten kjent skadevare, for eksempel når en angriper har stjålet kundedata eller endret betalingsmottaker.

Tegn som bør undersøkes

Sterke signaler

• en nettleser, Search Console eller host varsler om skadelig innhold
• ukjente administratorer, API-nøkler, SSH-nøkler eller aktive sesjoner
• filer, databaseinnhold eller DNS-poster er endret uten godkjent endring
• besøkende blir sendt til et annet domene eller får en ukjent nedlasting
• nye sider med gambling, legemidler, lån eller fremmed innhold er indeksert
• serveren sender spam eller gjør uventede utgående forespørsler

Svake signaler

• siden er treg eller ustabil
• trafikken faller
• en sikkerhetsplugin viser en generell advarsel
• en enkelt bruker ser en popup
• filnavn eller kode ser «uvanlig» ut

Svake signaler er gode startpunkter, men ikke bevis. Treghet kan skyldes database, trafikk eller tredjepartsskript. En popup kan komme fra brukerens enhet. Legitim programvare kan inneholde både kodet tekst og funksjoner som også misbrukes av angripere.

Før du åpner den mistenkelige siden

Ikke undersøk en mulig skadelig side fra en vanlig arbeidsmaskin med aktive innlogginger. Varsle den som eier hendelsen, noter klokkeslett og URL, og bruk en isolert testmaskin eller kvalifisert hendelseshjelp.

Ta vare på det opprinnelige varselet. Ikke slett filer eller kjør automatisk «repair» før dere har sikret relevante logger, snapshot og endringshistorikk. Slike handlinger kan fjerne både bevis og informasjonen som trengs for å finne inngangsveien.

Undersøk i flere lag

Ingen av kontrollene under kan alene friskmelde nettstedet. Sammen kan de bekrefte funn, avgrense omfang og avdekke hva en skanner ikke ser.

1. Kontroller varsler fra Google

I Search Console viser Sikkerhetsproblemer hvilke typer problemer Google har oppdaget og eksempler på berørte URL-er. Eksemplene er ikke nødvendigvis en komplett liste. Google påpeker også at skadelig innhold kan vises bare for bestemte brukere, henvisere eller user agents.

Bruk rapporten som utgangspunkt for undersøkelsen, og unngå å åpne en infisert eksempel-URL direkte i den vanlige nettleseren. Se Googles offisielle beskrivelse av rapporten .

Fravær av varsel betyr bare at Google ikke rapporterer et funn. Det beviser ikke at server, kontoer eller data er uberørt.

2. Sammenlign med kjent og kontrollert kilde

For kode som skal være identisk med en offisiell release eller en versjon i eget repository:

• sammenlign filhash, innhold, størrelse og tidspunkt
• finn nye filer og filer som mangler
• kontroller deployhistorikk mot godkjente endringer
• installer ikke en tilfeldig kopi «over» miljøet før avvikene er dokumentert

I WordPress kan kjernen og plugins fra det offisielle biblioteket sammenlignes mot de publiserte versjonene. Egen kode, premium-plugins, opplastinger og databaseinnhold krever egne referanser. WordPress beskriver både indikatorer og filkontroll i sin offisielle veiledning etter hacking .

3. Undersøk database og dynamisk innhold

En ren filkontroll finner ikke alt. Se etter:

• ukjente brukere, roller og endrede recovery-adresser
• skript, iframes, lenker og redirects i innhold eller innstillinger
• nye planlagte oppgaver og automatiseringer
• endret hjemadresse, betalingsinnstillinger eller e-postmottaker
• innhold som bare vises for enkelte språk, enheter eller innloggingsnivåer

Eksporter eller ta snapshot før omfattende endringer. Noter spørringer og verktøy som brukes, slik at funn kan gjentas.

4. Les logger og kontrollplan

Knytt fil- og databaseendringer til:

• administrator- og autentiseringslogger
• webserver-, applikasjons- og WAF-logger
• hosting-, sky- og kontrollpanellogger
• kildekode, CI/CD og deploy
• DNS, registrar og e-post

Se etter den første avvikende handlingen, ikke bare tidspunktet symptomet ble oppdaget. Logger kan være ufullstendige eller manipulert; sammenlign derfor flere kilder og tidssoner.

5. Bruk skannere med riktig forventning

Et grønt resultat betyr «ingen funn med denne metoden nå», ikke «rent nettsted». Et positivt resultat må også valideres: falske positiver finnes, og en filsti alene forteller ikke om angriperen fortsatt har tilgang.

Når er mistanken sterk nok til å eskalere?

Behandle saken som en sikkerhetshendelse når minst ett funn viser uautorisert endring, kodekjøring eller tilgang, eller når dere ikke kan utelukke aktiv skade mot brukere. Ikke vent på at alle skannere skal være enige.

Dokumenter:

• hva som ble observert, av hvem og når
• berørte URL-er, systemer og kontoer
• verktøy, versjon og innstillinger brukt i kontrollen
• hvilke data skanneren faktisk kunne se
• råfunn, logger, hashverdier og skjermbilder
• hva som er bekreftet, avkreftet og fortsatt ukjent

Derfra eier hendelsesguiden for et hacket nettsted isolering, tilgangsrotasjon, gjenoppbygging, verifisering og vurdering av varslingsplikt.

Friskmelding krever mer enn en ren skann

Før nettstedet åpnes fullt igjen, må dere kunne forklare:

1. hva som faktisk skjedde
2. hvordan angriperen eller den uautoriserte endringen kom inn
3. hvilke systemer, kontoer og data som kan være berørt
4. hvordan inngangsveien og eventuell vedvarende tilgang er fjernet
5. hvorfor grunnlaget som gjenopprettes eller bygges fra, er kjent rent
6. hvilke tester og skjerpede varsler som er aktive etter åpning

Hvis svaret bare er «skanneren er grønn», er undersøkelsen ikke ferdig. Test også gjenopprettingsløpet og bygg backup som tåler samme hendelse. Guidene om restore-test og 3-2-1-backup viser hvordan.

Hvis mistanken gjelder en side Vymo hoster

Send URL, tidspunkt, skjermbilde og en kort beskrivelse av symptomet . Ikke send passord, private nøkler eller en mistenkelig fil på vanlig e-post. Ved aktiv phishing, skadelig nedlasting eller redirect: opplys dette først i meldingen.