Hackad WordPress: så sanerar du sajten utan att bli hackad igen
Sajten är hackad, och du vet förmodligen redan det. Kanske omdirigerar den till en okänd butik, kanske har Google flaggat den med en säkerhetsvarning, kanske ringde hostingbolaget och meddelade att kontot stängts av för utgående skräppost. Vad du gör de närmaste timmarna avgör om problemet försvinner för gott eller kommer tillbaka om en vecka.
Den här guiden går igenom saneringen i den ordning som faktiskt fungerar, från att säkra bevis till att sanera filer och databas till att rotera lösenord och nycklar i rätt turordning. Vi utgår från egen erfarenhet av att städa upp intrång på delade konton, där problemet sällan är en enda infekterad fil utan en hel kedja av misstag som gör att angriparen kommer tillbaka. Har du redan bestämt dig för att flytta sajten till ett webbhotell för WordPress med bättre isolering mellan sajter är det ett klokt beslut på sikt, men det löser inte dagens akuta problem. Just nu handlar det om att städa och stänga dörren, inte om att byta hus.
De två vanligaste felen vi ser är att sanera en sajt i taget på ett konto med flera domäner, och att rotera lösenord i fel ordning. Båda leder till samma resultat. Sajten blir hackad igen inom kort, och du står där och undrar varför lösenordsbytet inte hjälpte.
Innan detaljerna, här är åtgärderna i grova drag.
- Rör inte lösenorden ännu. Byter du dem för tidigt kan en angripare redan sitta kvar i en aktiv session eller ha planterat en ny väg in.
- Betrakta alla sajter och addon-domäner på kontot som misstänkta, inte bara den som visar tydliga symptom.
- Ta en smutsig kopia av filer och databas innan du rör något, som bevis och referens.
- Sätt sajten i underhållsläge så besökare inte möter skadligt innehåll medan du arbetar.
- Hitta ingången innan du sanerar, annars städar du bort symptomen men lämnar dörren öppen.
- Sanera samtliga sajter under kontot samtidigt, inte en i taget.
- Rotera lösenord och nycklar i rätt ordning när saneringen är klar.
- Uppdatera allt och verifiera, inklusive Search Console, efter att saneringen är klar.
Är sajten verkligen hackad?
Ibland är det uppenbart. Sajten omdirigerar besökare till andra webbplatser, startsidan har bytts ut mot spaminnehåll på ett främmande språk, Google Search Console visar en säkerhetsvarning, eller webbhotellet har stängt av kontot för utgående skräppost eller onormal serverbelastning. Det är de tydliga tecknen.
Andra gånger är tecknen svårare att upptäcka på egen hand.
- Ett administratörskonto i WordPress som du inte känner igen och inte skapat själv.
- Ovanligt hög CPU- eller minnesanvändning utan att sajten fått mer trafik.
- Egen e-post som plötsligt hamnar i mottagarens skräppost eller studsar helt.
- Schemalagda cron-jobb som kör okänd kod med jämna mellanrum.
En kraschad sajt är inte samma sak som en hackad sajt. En vit skärm, ett minnesfel eller ett 500-fel efter en misslyckad uppdatering är sällan tecken på intrång, det är oftast ett vanligt PHP-fel eller en konflikt mellan plugins. Blanda inte ihop felsökning av en trasig sajt med sanering av en hackad, det är två olika processer med olika lösningar.
Varför en infekterad sajt smittar de andra på kontot
Det här är den punkt som skiljer en riktig sanering från en som bara ser klar ut. På de flesta delade webbhotell körs PHP under samma systemanvändare för hela kontot, alltså för huvuddomänen och för varje addon-domän och subdomän du lagt till under åren. Ur operativsystemets perspektiv är det en och samma användare som äger alla filerna, oavsett hur många olika WordPress-installationer som ligger där.
Det betyder att en infekterad sajt normalt kan läsa och skriva filer i alla andra sajters mappar på samma konto. En bakdörr (backdoor) i huvuddomänen kan alltså plantera skadlig kod i en gammal testinstallation du glömt bort, eller i en subdomän du knappt använder längre, helt utan att röra sig utanför kontots egna behörigheter.
Symlink-tricket är en klassisk variant av samma problem. Angriparen skapar en symbolisk länk inifrån en webbmapp som pekar ut mot resten av filsystemet, i värsta fall mot en annan kunds hemkatalog om serverns behörigheter är slarvigt satta, i vart fall mot resten av det egna kontots mappar. Beroende på hur webbhotellet konfigurerat isoleringen kan tricket ge åtkomst långt utanför den sajt där intrånget faktiskt skedde.
Isoleringen på ett bra webbhotell finns mellan kunder, inte nödvändigtvis inom ditt eget konto. Varje kund kan ha en egen systemanvändare eller köra i en isolerad miljö som CageFS, vilket stoppar en hackad sajt från att nå grannens konto. Men har du själv flera WordPress-installationer på samma konto delar de som regel samma användare, samma filbehörigheter och samma PHP-process. Det är ditt ansvar att behandla dem som en enhet, inte webbhotellets.
| Nivå | Inom ditt konto (delad användare) | Mellan olika kunder hos webbhotellet |
|---|---|---|
| Filsystem | Delat, en infekterad sajt kan läsa och skriva övriga sajters filer | Isolerat via egen systemanvändare eller CageFS |
| PHP-processer | Körs oftast som samma användare för alla sajter | Separata användare per kund |
| Databaser | Egna databaser, men ofta med angränsande behörigheter beroende på konfiguration | Separerade databasinstanser hos de flesta seriösa hotell |
| Cron-jobb | Delad crontab-miljö, ett skadligt cron-jobb kan påverka hela kontot | Isolerat per kund |
Konsekvensen är enkel att formulera men lätt att missa i stressen. Sanerar du en sajt i taget, med de andra kvar orörda, är chansen stor att du blir återinfekterad inom kort, ibland samma dag. Gör istället en fullständig inventering av allt som ligger under kontot, huvuddomän, alla addon-domäner, alla subdomäner och särskilt gamla testinstallationer av WordPress som ingen längre kommer ihåg varför de finns kvar. De glöms ofta bort, körs på föråldrade pluginversioner och blir en perfekt ingång som sedan sprider sig vidare till de sajter du faktiskt bryr dig om.
Har du möjlighet att påverka serverkonfigurationen, till exempel via ett VPS eller en hanterad WordPress-lösning, finns officiell vägledning för hårdning av WordPress som går igenom filbehörigheter och processisolering mer i detalj.
Är det här första gången du inser att dina sajter delar användare på ett sätt du inte kände till, är det värt att läsa igenom vad du bör kräva av ett säkert webbhotell innan du väljer nästa leverantör.
Säkra bevis innan du rör något
Innan du raderar en enda fil, ta en fullständig kopia av sajten som den ser ut just nu, både filer och databas. Kalla den gärna en smutsig backup. Den innehåller skadlig kod med flit.
Den här kopian fyller två syften. Dels blir den din referens när du senare jämför vad som förändrats, dels är den ett underlag om det visar sig att personuppgifter exponerats och du behöver dokumentera vad som hänt. Lagra den utanför hostingkontot, inte i en mapp på samma server, av samma anledning som resten av kontot är misstänkt.
Den skiljer sig helt från den löpande backup du normalt bör ha på plats. Har du redan en fungerande 3-2-1-backup från innan intrånget skedde är det din snabbaste väg tillbaka, mer om det längre ner.
Hitta ingången innan du sanerar
Utan att veta hur angriparen kom in sanerar du i blindo. De vanligaste ingångarna är en föråldrad eller nulled plugin eller tema (en piratkopierad, olagligt distribuerad version med inbyggd skadlig kod), ett läckt eller återanvänt lösenord, eller en komprometterad dator hos den som administrerar sajten, där inloggningsuppgifter stulits lokalt.
Gå igenom listan över installerade plugins och teman och jämför mot senast uppdaterade versioner. Kontrollera om något är hämtat från en källa utanför wordpress.org, en nulled-variant av ett premiumplugin är en av de vanligaste ingångarna vi stöter på. Fråga också om lösenordet till WordPress eller FTP återanvänds någon annanstans, och om den dator som används för att administrera sajten nyligen visat tecken på egen infektion.
Det här steget är inte bara nyfikenhet. Roterar du lösenord utan att veta hur angriparen kom in riskerar du att låsa ut dig själv från en dörr som redan var stängd, medan den faktiska ingången, en sårbar plugin till exempel, står kvar öppen.
Sanera i rätt ordning
Här ligger kärnan i saneringen, och ordningen spelar större roll än de flesta inser. Gör du stegen i fel följd riskerar du att låsa en angripare inne i sajten snarare än ute, eller att öppna dörren igen precis efter att du stängt den.
Lås ute besökare medan du arbetar
Sätt sajten i underhållsläge eller stäng av den helt för publik trafik under saneringen. Det hindrar besökare från att exponeras för skadligt innehåll medan du jobbar, och det ger dig arbetsro utan att angriparens skript aktivt körs och skriver tillbaka ändringar samtidigt som du städar.
Sanera filerna
Jämför sajtens kärnfiler mot en ren nedladdning direkt från wordpress.org, samma version som sajten kör. wp-admin och wp-includes innehåller normalt aldrig anpassad kod, ersätt dem rakt av med de rena originalen. Skillnader där är nästan alltid ett tecken på manipulation.
Leta särskilt igenom uploads-mappen efter PHP-filer. Uppladdningsmappen ska bara innehålla bilder, dokument och media, aldrig körbar kod, så en enda .php-fil där är i sig värd att undersöka.
Granska mu-plugins-mappen (must-use plugins) noga. Filer där körs automatiskt av WordPress oavsett om de är aktiverade i adminpanelen eller inte, vilket gör mappen till ett klassiskt gömställe för bakdörrar som annars skulle synas i den vanliga plugin-listan.
WordPress.org har en genomgång av hur en hackad sajt saneras steg för steg som går igenom filstrukturen mer i detalj om du vill dubbelkolla mot något du är osäker på.
Sanera databasen
Skadlig kod gömmer sig lika ofta i databasen som i filsystemet. Sök igenom wp_posts och wp_options efter injicerad JavaScript- eller iframe-kod, ofta insmugen i widgettexter, temaalternativ eller gamla inlägg. Kontrollera wp_users efter administratörskonton du inte känner igen. Ett nytt konto med adminrättigheter som skapats utan din vetskap är ett av de tydligaste tecknen på ett aktivt intrång.
Granska schemalagda uppgifter
WordPress schemalägger egna bakgrundsuppgifter via wp-cron, och skadlig kod utnyttjar ofta samma mekanism för att återinstallera en bakdörr efter att du städat bort den. Ett cron-jobb som laddar ner en fil från en extern adress eller kör okänd kod med jämna mellanrum är precis det du vill fånga innan sajten öppnas igen. Missar du det inträffar det som förvånar många, sajten blir hackad igen trots att lösenorden bytts, helt enkelt för att ett schemalagt jobb tyst återskapade det som just städats bort.
När filerna och databasen är sanerade, och inte förrän då, är det dags att rotera lösenord och nycklar. Ordningen nedan är inte godtycklig, varje steg bygger på att föregående är avklarat.
| Steg | Vad du roterar | Varför just här i ordningen |
|---|---|---|
| a | Databaslösenord (DB_PASSWORD i wp-config.php) | Har angriparen läs- eller skrivåtkomst till databasen spelar det ingen roll vad du gör längre fram. Gäller även om bara filerna verkade drabbade, ett komprometterat filsystem ger ofta indirekt vägen in till databasuppgifterna ändå. |
| b | FTP/SFTP/SSH och hostingpanelens lösenord | Stänger den kanal angriparen använde för att ladda upp filer i första läget. Görs innan du arbetar vidare i WordPress, annars kan samma väg in utnyttjas igen medan du sanerar. |
| c | WordPress säkerhetsnycklar och salter (AUTH_KEY med flera) | Ogiltigförklarar alla aktiva sessioner omedelbart, inklusive en angripares inloggade session. Utan detta steg kan en angripare sitta kvar inloggad även efter att lösenordet bytts. |
| d | WordPress-användarlösenord | Görs efter salter, aldrig före. Byts lösenordet innan salter roterats kan angriparens gamla session fortsätta fungera trots det nya lösenordet, eftersom sessionen aldrig ogiltigförklarades. |
| e | Application passwords (REST API-nycklar) | Ofta helt bortglömda. Application passwords ger separat åtkomst till WordPress REST API för appar och integrationer, och kringgår vanligt lösenordsbyte helt. En angripare som skapat en egen kan behålla åtkomst länge efter att allt annat bytts. |
| f | Tredjeparts-API-nycklar (betalning, e-post, backup-tjänster) | Sista steget, men inte mindre viktigt om sajten hanterar betalningar eller skickar e-post via en extern tjänst. En läckt API-nyckel kan missbrukas långt efter att WordPress-sajten sanerats. |
Generera nya slumpade nycklar via WordPress officiella salt-generator och klistra in dem i wp-config.php. Känner du inte till application passwords sedan tidigare är det värt att läsa på om funktionen innan du går vidare, den är lätt att glömma bort helt i en stressad sanering.
De vanligaste felstegen är två. Nytt lösenord innan salter roterats gör att en redan inloggad angripare fortsätter vara inloggad oavsett hur starkt det nya lösenordet är. Nytt lösenord innan filerna sanerats gör att en kvarvarande bakdörr helt enkelt släpper in angriparen igen via en helt annan väg, lösenordet var aldrig den egentliga ingången.
När rotationen är klar, uppdatera WordPress, tema och samtliga plugins till senaste version innan du öppnar sajten för besökare igen. En sårbarhet som utnyttjats en gång fixas inte av sig själv bara för att lösenorden bytts.
Verifiera att sajten faktiskt är ren
En sanering känns sällan helt klar förrän du dubbelkollat med färska ögon. Kör en ny skanning med ett verktyg som letar efter skadlig kod för att fånga upp eventuella rester som missats i den manuella genomgången. Vill du förstå hur den typen av skanning faktiskt fungerar, och vad den kan respektive inte kan hitta, finns en genomgång i vår FAQ om malware-scanning.
Komplettera alltid den automatiska skanningen med en manuell omkoll. Gå igenom wp_users efter administratörskonton en gång till, kontrollera cron-listan igen, och öppna mu-plugins-mappen en sista gång. Skanningsverktyg är bra på kända signaturer men missar regelbundet obfuskerad eller specialskriven kod som inte matchar något tidigare känt mönster, vilket är precis den typ av kod en riktad attack ofta använder.
Är du osäker på om sajten verkligen är ren, testa den i en isolerad miljö innan du pekar om den riktiga domänen dit. Att sätta upp en testmiljö för att verifiera funktion och renhet innan produktionssajten öppnas igen är ett rimligt extra steg om du känner dig osäker på om något missats.
Efteråt: svartlistning, ansvar och nästa steg
Även efter en lyckad sanering kan spåren av intrånget synas ett tag till. Google indexerar om sajten i sin egen takt, och har den flaggats med en säkerhetsvarning behöver du gå in i Search Console och begära en granskning så snart du är säker på att sajten är ren. Görs det för tidigt, innan saneringen faktiskt är klar, riskerar du bara att förlänga tiden med varningen kvar.
Har intrånget exponerat personuppgifter, till exempel kunduppgifter i en webbutik eller ett medlemsregister, har du en informationsplikt enligt GDPR att ta ställning till. Vid allvarligare intrång, särskilt sådana som rör personuppgifter, kan CERT-SE vara en relevant kontakt för råd och stöd.
Känns hela processen övermäktig är det inget nederlag att ta hjälp. En sanering med flera sajter inblandade, en okänd ingång och osäkerhet kring vad som exponerats är ett läge där det ofta är värt att anlita någon med erfarenhet av just det här, särskilt om sajten hanterar betalningar eller känsliga uppgifter.
Finns en fungerande backup från innan intrånget skedde är en fullständig återställning ibland det snabbaste alternativet, förutsatt att du fortfarande hittar och stänger ingången innan sajten återpubliceras. Annars återkommer samma problem inom kort.
När sajten är sanerad, säkrad och verifierad är nästa steg att göra det svårare att hamna här igen. Vår FAQ om hur du skyddar din WordPress-sajt från hackning går igenom det förebyggande arbetet mer i detalj.