Hvordan rense en hacket WordPress-side

“Nettstedet inneholder skadelige programmer.”

Denne setningen, vist på en knallrød skjerm (Google Safe Browsing) eller i en e-post fra hostingleverandøren, er ethvert nettstedseiers mareritt. En WordPress-infeksjon er ikke bare et omdømmeproblem. Den gir risiko for tyveri av kundedata, tap av Google-rangeringer (såkalt “Japanese Keyword Hack” eller viderekoblinger til spillsider) og potensielt sperring av hostingkontoen din.

En stor del av angrepene på WordPress er automatiserte: den offisielle veiledningen for herding av WordPress påpeker at mange angrep utføres selvstendig av roboter. Robotene angriper deg ikke personlig, de skanner nettet etter utdaterte programtillegg, svake passord eller hull i temaer.

I denne artikkelen vil jeg vise deg en profesjonell, teknisk prosess for rensing av en hacket WordPress-side. Glem “sikkerhetsprogramtillegg” som ofte bare maskerer problemet. Jeg skal vise deg hvordan du gjør det manuelt, effektivt og på servernivå ved bruk av SSH og WP-CLI.

Var det første tegnet japanske sider i Google og ikke noe synlig på selve nettstedet, ser du sannsynligvis på den skjulte varianten, som krever et annet første steg: se japansk nøkkelord-hack før du sletter noe.

#Tegn på at WordPress er hacket og hva du skal notere først

“Hacket” er et vagt begrep. Siden FAQ My site was hacked i den offisielle WordPress-dokumentasjonen kaller de konkrete symptomene indikatorer på kompromittering (IoC) og lister opp de tydeligste:

• nettstedet står på en svarteliste hos Google, Bing eller andre søkemotorer;
• hostingleverandøren har deaktivert nettstedet;
• nettstedet er flagget for å spre skadevare;
• besøkende melder at antivirusprogrammet deres blokkerer nettstedet;
• noen har tatt kontakt fordi nettstedet ditt brukes til å angripe andre nettsteder;
• det skjer ting ingen har godkjent, for eksempel nye brukere;
• endringen er synlig når du åpner nettstedet i nettleseren.

Det første praktiske steget er ifølge samme side dokumentasjon. Før du sletter noe, skriv ned hva du ser, når du oppdaget problemet (med tidssone) og hva som er endret nylig: et nytt programtillegg, en endring i temaet, en redigert widget. Legg til opplysninger om hostingmiljøet (PHP-versjon, servertype, hvem som har tilgang). Notatet er grunnlaget for en hendelsesrapport og sparer tid, enten du renser selv eller overlater jobben til noen andre.

To steg fra samme kilde blir ofte glemt. For det første: skann din egen datamaskin med et antivirusprogram. En lokal trojaner som fanger opp innloggingen til FTP eller /wp-admin gjør all rensing på serveren verdiløs. For det andre: snakk med hostingleverandøren. På delt hosting kan infeksjonen ha rammet mer enn nettstedet ditt, og et nettsted som sender spam kan få serverens IP-adresse på svartelister for e-post, noe som også rammer utgående e-post fra den serveren.

#Ta backup av hacket WordPress før rensing

Før du rører noe som helst, ta backup av nåværende tilstand. Hvorfor? Fordi du under rensing ved et uhell kan slette en kritisk fil (f.eks. en modifisert functions.php som inneholdt viktig funksjonalitet, ikke bare viruset). WordPress-dokumentasjonen anbefaler denne kopien selv om nettstedet er infisert: går rensingen galt, har du i det minste forrige tilstand å se på.

Hvis du har tilgang til SSH:

## Arkiver alle filer
tar -czf backup-infected-files_$(date +%F).tar.gz .

## Eksporter database
wp db export backup-infected-db_$(date +%F).sql --allow-root

#Finne malware i WordPress med grep

Før du begynner å kutte, må du vite hva du kjemper mot. Malware i WordPress skjuler seg ofte som maskert kode (obfuscated code) ved bruk av funksjoner som eval, base64_decode, eller gzinflate. Googles rapport om sikkerhetsproblemer viser et typisk eksempel, eval(base64_decode("...")), og anbefaler å søke etter eval, base64_decode og unescape.

Her er en liste over nyttige grep-kommandoer for å skanne filer etter mistenkelige strenger. Kjør dem i nettstedets rotkatalog.

#De vanligste malware-signaturene

1. Søk etter funksjonen eval (svært sjelden brukt legitimt i moderne kode):

   grep -rl --include=*.php 'eval(' .

2. Søk etter skjulte iframes og skript injisert i PHP-filer:

   grep -rl --include=*.php '<script' .
   grep -rl --include=*.php '<iframe' .

3. Søk etter kodede og komprimerte strenger (Base64, Rot13, gzinflate):

   grep -rl --include=*.php 'base64_decode' .
   grep -rl --include=*.php 'str_rot13' .
   grep -rl --include=*.php 'gzinflate' .

4. Søk etter unescape i JavaScript:

   grep -rl --include=*.js 'unescape(' .

Ikke bruk valget -w med disse mønstrene. Med -w krever grep at treffet slutter på et tegn som ikke er bokstav eller siffer, så eval( finner da ikke den vanligste formen, eval(base64_decode(.

#Hvordan skille falske treff fra ekte malware

Ikke hvert resultat er et virus.

• Programtillegg som Elementor eller Visual Composer kan ha base64_decode i koden sin.
• Vær oppmerksom på filer på merkelige steder, f.eks. wp-content/uploads/2024/03/avatar.php. Mappen uploads skal ikke inneholde PHP-filer.

For å finne alle PHP-filer i uploads-mappen:

find ./wp-content/uploads -name "*.php"

Det du finner her, skal du behandle som mistenkelig til det motsatte er bevist. Bare et svært spesielt programtillegg legger PHP i denne mappen, og det bør utvikleren av tillegget ha dokumentert.

#Se det hackede WordPress-nettstedet slik Google ser det

Mange angrep viser spammen bare til Googlebot eller til besøkende som kommer fra søk (cloaking). Eieren åpner nettstedet direkte og ser at alt er normalt. Googles rapport om sikkerhetsproblemer fraråder å åpne infiserte sider i nettleseren, fordi skadevare kan utnytte sårbarheter i selve nettleseren, og foreslår to alternativer.

Det første er verktøyet for URL-inspeksjon i Search Console, som viser siden slik Google mottar den. Det andre er curl (eller wget) med satt referer og user-agent, for å etterligne en besøkende fra Google-søk:

curl -sv --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://ditt-domene.no/ -o side.html
grep -iE 'eval|base64_decode|unescape|<iframe' side.html

Gjenta forespørselen uten referer og sammenlign svarene. En 301 eller 302 som bare dukker opp med Google som referer, peker mot regler i .htaccess eller i PHP-koden. Google nevner tre former for viderekobling som angripere bruker: regler i serverkonfigurasjonen (.htaccess, httpd.conf), JavaScript-viderekoblinger som avhenger av document.referrer, og skript som lastes fra et fremmed domene.

#Erstatte WordPress-kjernefiler med WP-CLI

Å manuelt fjerne virus fra WordPress-kjernefiler (wp-admin, wp-includes) er et sisyfosarbeid. Den raskeste og mest pålitelige metoden er å erstatte alle systemfiler med rene originaler.

Dette er en trygg prosess hvis du ikke manuelt har modifisert kjernefiler (noe du uansett ikke bør gjøre).

WordPress-dokumentasjonen ber deg installere samme versjon som nettstedet bruker: en eldre eller nyere versjon kan ta ned nettstedet. Uten --version laster wp core download ned nyeste versjon, så oppgi den gjeldende:

## Last ned samme WordPress-versjon (erstatter filer)
wp core download --version=$(wp core version --allow-root) --force --skip-content --allow-root

Flagget --skip-content er kritisk, det sørger for at WP-CLI ikke overskriver wp-content-mappen din, der bildene, temaene og programtilleggene dine ligger.

Det er en begrensning du bør kjenne til. Ifølge samme FAQ overskriver installasjonsprogrammer vanligvis bare eksisterende filer, mens angrep ofte legger til nye. En ekstra fil i wp-includes overlever --force. Kontrollsumsjekken i neste avsnitt viser den.

Hvis du ikke har WP-CLI:

1. Last ned WordPress-pakken i samme versjon fra wordpress.org.
2. Pakk den ut lokalt.
3. Slett mappen wp-content og filen wp-config-sample.php fra den.
4. Slett mappene wp-admin og wp-includes på serveren, last opp dem fra pakken via SFTP, og overskriv deretter filene i rotkatalogen.

WordPress-FAQ-en fraråder reinstallasjonsvalget i kontrollpanelet i denne situasjonen, av samme grunn: det overskriver bare.

#Sjekke kjerne og programtillegg med wp core verify-checksums

WP-CLI sammenligner de installerte filene med MD5-summene WordPress.org publiserer. Kommandoen wp core verify-checksums kjører på hooken before_wp_load, altså uten å laste WordPress. Det betyr noe når WordPress selv kan være kompromittert.

wp core verify-checksums --allow-root

Med en ren kjerne er resultatet:

Success: WordPress installation verifies against checksums.

Med en endret kjerne kommer det advarsler per fil og en feil til slutt:

Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File should not exist: wp-includes/ekstra-fil.php
Error: WordPress installation doesn't verify against checksums.

Etter et angrep er det advarselen “File should not exist” som teller. Kildekoden til kommandoen viser at den som standard ser etter ekstra filer i wp-admin, wp-includes og i wp-*.php-filene i rotkatalogen (unntatt wp-config.php). Med --include-root (fra versjon 2.8.0) sjekker den hele rotkatalogen, unntatt .htaccess, .maintenance, wp-config.php og wp-content. Bruker nettstedet en norsk språkpakke, legg til --locale=nb_NO, ellers melder kommandoen oversatte filer som endret. Navnet ekstra-fil.php i eksempelet er bare en plassholder: ved et ekte angrep har filen et navn som ser legitimt ut.

For programtillegg finnes motstykket wp plugin verify-checksums:

wp plugin verify-checksums --all --allow-root

Kommandoen sammenligner hvert programtillegg med summene fra WordPress.org og melder filer som er lagt til (“File was added”) og endret (“Checksum does not match”). For programtillegg utenfor WordPress.org-katalogen, som de fleste betalte, finnes det ingen summer: WP-CLI skriver en advarsel og hopper over tillegget. Slike tillegg må erstattes med en ren pakke fra leverandøren.

#Fjerne virus fra wp-content i WordPress

Det er vanligvis her problemet ligger.

#Programtillegg og temaer

Hvis mulig, slett og installer alle gratis programtillegg på nytt. Virus fester seg ofte til hver .js eller .php-fil på serveren.

## Reinstaller programtillegg fra depotet (f.eks. contact-form-7)
wp plugin install contact-form-7 --force --allow-root

For betalte programtillegg må du laste ned rene pakker fra leverandøren og erstatte filer via SFTP.

Sjekk temaet ditt. Hvis du bruker et dattertema (child theme), sjekk manuelt functions.php og header.php. Dette er favorittsteder for skadelig kode. WordPress-FAQ-en legger til index.php og footer.php, fordi en endring der påvirker hver sidevisning.

#Uploads-mappen

Som nevnt tidligere, skal mediemappen (wp-content/uploads) kun inneholde bilder, PDF-er og dokumenter. Radikal rensing (sletter alle PHP-skript fra uploads):

find ./wp-content/uploads -name "*.php" -delete

Advarsel: Sjekk listen på forhånd (uten -delete) for å sikre at du ikke sletter noe legitimt.

#Rense WordPress-databasen for spam og falske administratorer

Infeksjoner stopper ofte ikke ved filene. Virus injiserer spam-lenker i innleggsinnhold eller oppretter falske administratorer.

Logg inn i databasen (phpMyAdmin eller wp db cli) og sjekk:

1. Falske administratorer:

   SELECT * FROM wp_users;

   Se etter brukere du ikke kjenner igjen, ofte med .ru, .cn domener eller tilfeldige strenger. Slett dem umiddelbart.

2. Spam i innhold: “Japanese Keyword Hack”-virus injiserer tusenvis av sider med kinesiske/japanske tegn som reklamerer for forfalskninger. Sjekk tabellen wp_posts:

   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%eval(%';

Hvis nettstedet ditt plutselig har tusenvis av nye sider i Google-indeksen, må du rense disse oppføringene fra databasen og deretter sende et nettstedskart til Google Search Console for å øke hastigheten på fjerning av søppel fra indeksen.

#Liste WordPress-administratorer med wp user list

Spørringen SELECT * FROM wp_users viser alle brukere, men ikke rollene deres, som ligger i wp_usermeta. Kommandoen wp user list kobler sammen begge tabellene og filtrerer på rolle:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root

Sammenlign listen med personene som faktisk har tilgang. Kolonnen user_registered hjelper deg å koble en ukjent konto til tidspunktet for hendelsen som du noterte i starten. I en multisite-installasjon lister --network brukerne i hele nettverket (uten roller, fordi samme bruker kan ha ulik rolle på hvert nettsted), så sjekk også superadministratorene:

wp super-admin list --allow-root

Har angriperen tatt over administratorkontoen din og du kommer ikke inn, beskriver WordPress-FAQ-en veien ut: logg inn i databasen via phpMyAdmin eller Adminer, endre e-postadressen til kontoen din i tabellen wp_users til en adresse du kontrollerer, og bruk lenken for tilbakestilling av passord på innloggingssiden.

#Sjekke wp-config.php og .htaccess etter hacking

Malware modifiserer ofte disse to nøkkelfilene.

1. wp-config.php: Åpne den og sjekk for rare linjer. Referanser til midlertidige filer legges ofte til:

   include '\tmp\sess_dsf43...'; // MISTENKELIG!

   Sammenlign filen din med wp-config-sample.php. Den skal kun inneholde databaselegitimasjon og konstantdefinisjoner.

2. .htaccess: Virus legger ofte til regler her som omdirigerer søkemotortrafikk (f.eks. hvis User-Agent er Googlebot) til nettsteder med malware, mens du (ved direkte besøk) ser det normale nettstedet. Hvis du er usikker, generer standard WordPress .htaccess-fil:

   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   </IfModule>
   # END WordPress

WordPress-FAQ-en minner om at .htaccess ikke bare ligger i rotkatalogen: den kan også ligge i andre kataloger i samme installasjon. Finn alle:

find . -name ".htaccess"

#Sikre WordPress etter et hack

Renset nettstedet? Bra. Lås nå dørene slik at innbruddstyven ikke kommer tilbake.

1. Bytt passord:

   • Til alle administratorkontoer.
   • Til databasen.
   • Til FTP/SFTP og hostingpanelet.

   WordPress-FAQ-en legger vekt på én detalj: hvis du byttet passordene da du oppdaget angrepet, bytt dem en gang til etter at du har bekreftet at nettstedet er rent. Bytter du databasebruker eller databasepassord, oppdater wp-config.php med de nye verdiene.

2. Bytt salt-nøkler: Dette tvinger utlogging for alle brukere. Rediger wp-config.php og erstatt nøkkelseksjonen med nye generert her: https://api.wordpress.org/secret-key/1.1/salt/ Eller bruk WP-CLI:

   wp config shuffle-salts

3. Deaktiver filredigering fra dashbordet: Legg til i wp-config.php:

   define( 'DISALLOW_FILE_EDIT', true );

   Dette forhindrer at en hacker som får tak i et admin-passord kan redigere tema-/programtilleggsfiler direkte fra panelet. Herdingsveiledningen forklarer at konstanten tilsvarer å fjerne rettighetene edit_themes, edit_plugins og edit_files for alle brukere, og at redigeringsverktøyet i dashbordet ofte er det første en angriper bruker etter innlogging.

4. Deaktiver XML-RPC: Hvis du ikke bruker WordPress-mobilappen eller Jetpack, er XML-RPC bare et sikkerhetshull (brukt for DDoS og Brute Force-angrep). Legg til i .htaccess:

   <Files xmlrpc.php>
   order deny,allow
   deny from all
   </Files>

   Dette er syntaksen for Apache 2.2. På Apache 2.4 uten modulen mod_access_compat bruker du Require all denied inne i <Files>-blokken.

#Filrettigheter og databasebruker etter rensing

Herdingsveiledningen gir konkrete verdier. Kataloger med 755, filer med 644, skrivbare bare for brukerkontoen som eier nettstedet:

find /sti/til/wordpress/ -type d -exec chmod 755 {} \;
find /sti/til/wordpress/ -type f -exec chmod 644 {} \;

wp-config.php skal bare kunne leses av deg og webserveren, noe som vanligvis betyr 400 eller 440.

Samme veiledning påpeker at MySQL-brukeren til vanlig drift bare trenger SELECT, INSERT, UPDATE og DELETE. I samme avsnitt advarer den likevel om at det ikke anbefales å fjerne ALTER og lignende rettigheter uten en testet backupplan, fordi enkelte oppdateringer endrer databaseskjemaet. Etter et angrep er et annet steg mer nyttig: kjører flere nettsteder på samme server, bør hvert ha sin egen database og sin egen bruker, slik at et kompromittert nettsted ikke gir tilgang til de andre.

Til slutt loggene. Herdingsveiledningen beskriver dem som hovedkilden til å forstå hvordan angriperen kom inn: tilgangsloggene på serveren viser IP, tidspunkt og forespørsler, inkludert brute force-forsøk og forsøk på filinkludering. FAQ-en kaller denne fasen etterforskning, og målet er å stenge angrepsveien, ikke bare slette symptomene. Veiledningen anbefaler også jevnlige kopier av hele nettstedet på et pålitelig sted, fordi et angrep som oppdages dager senere bare kan sammenlignes med en kopi fra før det.

#Hvordan bekrefte at WordPress ikke lenger er infisert

En rensing er først ferdig når nettstedet består de samme kontrollene som avslørte problemet. Gjenta de neste dagene grep-kommandoene fra starten, find ./wp-content/uploads -name "*.php" og wp core verify-checksums. En tom liste i uploads er det forventede resultatet. En ny PHP-fil i den mappen betyr at inngangen fortsatt er åpen.

Gå også tilbake til databasen. Kjør wp user list --role=administrator på nytt for å bekrefte at ingen ukjent administrator har dukket opp igjen, og gjenta spørringene mot wp_posts etter <script og eval(. Sammenlign wp-config.php og .htaccess med de rene versjonene, fordi det er de to filene skadevare endrer oftest.

Var infeksjonen en Japanese Keyword Hack, følg med på indeksen i Google Search Console etter at du har sendt inn nettstedskartet, og bekreft at spamsidene forsvinner.

Feiler en kontroll, ikke bare gjenta rensingen. Finn først det utdaterte programtillegget, nulled-temaet eller det svake passordet som slapp angriperen inn, og rens deretter på nytt.

#Rapport om sikkerhetsproblemer og forespørsel om gjennomgang i Search Console

Har Google merket nettstedet, forsvinner advarselen først etter en gjennomgang. Rapporten om sikkerhetsproblemer i Search Console er ifølge Google den gjeldende kilden: Safe Browsing viser advarsler avhengig av nettleserkonteksten, så du klarer kanskje ikke å gjenskape advarselen i din egen nettleser. Rapporten deler problemene inn i tre kategorier: hacket innhold, skadevare og uønsket programvare, og sosial manipulering.

Hvert problem har eksempel-URL-er. Google understreker at det bare er et utvalg, og at et problem uten eksempler ikke betyr at ingen sider er berørt. Rett problemet på hele nettstedet: å rette bare noen sider gir ingen delvis retur til søkeresultatene. Lister rapporten flere problemer, rett alle.

Når alle er rettet, bruk valget Request Review (be om gjennomgang) i rapporten. Ifølge Google gjør en god forespørsel tre ting: den forklarer det nøyaktige problemet, beskriver stegene du tok for å rette det, og dokumenterer resultatet. Her fungerer hendelsesnotatet fra starten og utdataene fra kontrollkommandoene som dokumentasjon.

Gjennomgangen tar fra noen dager til noen uker, og Google varsler på e-post når forespørselen er mottatt og når den er ferdig. Ikke send forespørselen på nytt før du har fått en avgjørelse. En forespørsel sendt før problemet er rettet, kan forsinke den neste og til og med føre til at nettstedet merkes som gjentakende overtreder.

Har du nylig kjøpt et nettsted som allerede hadde disse problemene, ber Google deg nevne det i forespørselen, etter at du har rettet alt rapporten lister opp.

#Oppsummering

Kampen mot malware er et våpenkappløp. Den beste beskyttelsen er imidlertid ikke et “magisk sikkerhetsprogramtillegg”, men digital hygiene:

1. Umiddelbare oppdateringer av WordPress og programtillegg.
2. Ikke installere “nulled” (piratkopierte) programtillegg og temaer, en vanlig kilde til infeksjoner.
3. Ha en ekstern backup (f.eks. i skyen).

Hvis du føler at det tekniske aspektet er overveldende, er det bedre å leie inn profesjonelle. Dårlig utført rensing kan etterlate en bakdør (backdoor) åpen, som hackeren vil bruke for å komme tilbake etter noen dager, og du vil tape mer penger og tillit i Googles øyne.