Hackad webbplats vad göra: den kompletta guiden till att ta tillbaka kontrollen
Googles dokumentation konstaterar att kriminella komprometterar tusentals webbplatser varje dag. Den här guiden går igenom hela återställningen — från de första tecknen på ett intrång till skyddet mot nästa angrepp.
Googles dokumentation konstaterar att kriminella komprometterar tusentals webbplatser varje dag. Den här guiden går igenom hela återställningen — från de första tecknen på ett intrång till skyddet mot nästa angrepp.
Föreställ dig situationen — du öppnar din egen webbplats, och i stället för den välbekanta startsidan möts du av en varning om skadlig programvara, en omdirigering till en tvivelaktig sida eller helt enkelt en tom skärm med obegriplig kod. Scenariot är inget teoretiskt hot: Googles dokumentation om hackade webbplatser inleds med konstaterandet att kriminella komprometterar tusentals webbplatser varje dag. Oavsett om din webbplats är en liten personlig blogg, en lokal företagswebbplats eller en omfattande webbutik finns risken för intrång hela tiden där, och att återställa en hackad webbplats börjar betydligt tidigare än de flesta ägare tror — hur snabbt och hur välavvägt du agerar vid en sådan incident avgör om din närvaro på nätet är tillbaka inom några dagar, eller om du förlorar ett anseende som byggts under månader, kundernas förtroende och dina placeringar i sökresultaten.
Här går vi igenom hela återställningsprocessen i detalj — från de första tecknen på att något har komprometterats till den långsiktiga säkerhetsstrategi som håller nästa angrepp borta. Vi tar upp både de tekniska delarna och de praktiska stegen som vilken webbplatsägare som helst klarar av, också utan djupa programmeringskunskaper.
Så märker du att din webbplats har hackats
En av de största svårigheterna för webbplatsägare är att ett intrång inte alltid är uppenbart — många angrepp är medvetet byggda för att förbli oupptäckta så länge som möjligt, eftersom det lönar sig bättre för angriparen att i lugn och ro utnyttja dina serverresurser, sprida skadlig programvara via din webbplats eller lägga in dolda länkar och skräpinnehåll som lyfter angriparens egna webbplatser i sökresultaten. Ändå finns det en rad tecken som du bör reagera på omedelbart, eftersom de ofta betyder att din webbplats har blivit komprometterad.
Det första och mest synliga tecknet är varningar från webbläsaren eller sökmotorn — visar Google Chrome eller en annan webbläsare en röd helskärmsvarning i stället för din webbplats, en varning som helt enkelt inte släpper igenom besökaren, betyder det nästan alltid att Google Safe Browsing har hittat skadligt innehåll på din sida. Den exakta ordalydelsen beror på vilket språk webbläsaren körs på, så att jaga en enda bestämd formulering är inte värt besväret. En sådan varning skrämmer bort besökarna omedelbart — en helskärmsspärr ställer sig mellan dem och ditt innehåll — och den räknas därför till de allvarligaste följderna av ett intrång. På samma sätt kan texten ”Denna webbplats kan ha blivit hackad” dyka upp under din adress i Googles sökresultat, vilket märkbart påverkar både antalet klick och användarnas förtroende.
Det andra vanliga tecknet är oväntade omdirigeringar — skickas besökarna på din webbplats automatiskt vidare till andra sidor, särskilt till tvivelaktiga webbplatser med annonser, läkemedel eller innehåll för vuxna, är det en tydlig signal om att skadlig kod har lagts in på din webbplats och utför omdirigeringarna. Ofta är sådana omdirigeringar inställda att slå till bara för vissa användare, till exempel bara i mobilen eller bara för besökare som kommer från en sökmotor, vilket gör problemet ännu svårare att upptäcka, eftersom administratören som öppnar sidan direkt kanske inte ser någon skillnad alls.
Det tredje tecknet, som ofta förbises, är oväntade förändringar i innehållet — dyker det plötsligt upp saker på din webbplats som du inte har skapat, till exempel länkar till främmande webbplatser, nya användarkonton i adminpanelen, okända filer i serverns mappar eller ändringar i befintliga filer, pekar allt det på obehörig åtkomst. Särskilt farligt är det när angripare bygger dolda sidor på din webbplats, optimerade för sökmotorer och fyllda med skräpinnehåll — den taktiken, som branschen kallar SEO-spam och Google beskriver som hacket med maskerade nyckelord, kan under lång tid skada din webbplats anseende i sökmotorernas ögon, även om du själv aldrig ser sidorna, eftersom de bara visas för sökmotorernas robotar.
Det fjärde tecknet är prestandaproblem på servern — blir din webbplats plötsligt märkbart långsammare, slutar servern med jämna mellanrum att svara eller får du meddelanden från webbhotellet om onormalt hög resursförbrukning, kan det betyda att angripare använder din server för sina egna ändamål, till exempel för att utvinna kryptovaluta, skicka skräppost eller angripa andra webbplatser. I sådana lägen kan webbhotellet till och med stänga av ditt konto, vilket gör din webbplats fullständigt oåtkomlig.
Vanliga typer av intrång och sårbarheter
För att kunna återställa en hackad webbplats och samtidigt hindra nya angrepp behöver du förstå hur angriparna över huvud taget tar sig in i systemet, för utan den förståelsen riskerar du att åtgärda följderna i stället för orsaken, och webbplatsen kan vara hackad igen inom några dagar eller veckor efter saneringen. Statistiken över IT-säkerhet visar att de flesta intrång inte är avancerade, riktade angrepp utan automatiserade processer, där robotar skannar miljontals webbplatser efter kända sårbarheter och utnyttjar dem så snart de hittas.
SQL-injektion är fortfarande en av de vanligaste och farligaste angreppsmetoderna, och den låter angriparen manipulera din webbplats databas genom att mata in skadliga SQL-frågor via inmatningsfält, till exempel inloggningsformulär, sökrutor eller parametrar i adressen. Släpper din webbplats kod in användarens indata direkt i SQL-frågor utan ordentlig validering och parametrisering, kan angriparen gå förbi autentiseringen och läsa, ändra eller radera känsliga uppgifter i databasen, inklusive användarnas lösenord, personuppgifter och finansiella data. SQL-injektioner är särskilt farliga eftersom de kan ge angriparen fullständig kontroll över databasen, och i vissa fall över hela servern, om databasanvändaren har alltför vida behörigheter.
Cross-site scripting (XSS) är ytterligare en utbredd sårbarhet, som till skillnad från SQL-injektion inte riktar sig mot servern utan mot webbplatsens användare — angriparen lägger in skadlig JavaScript-kod på din webbplats, koden körs i besökarnas webbläsare och gör det möjligt att stjäla sessionskakor, skicka användare vidare till bedrägerisidor eller utföra handlingar i användarens namn utan att användaren märker något. XSS-angrepp kan vara beständiga (den skadliga koden sparas i databasen och visas för alla besökare), reflekterade (koden ligger i en parameter i adressen och fungerar bara när användaren klickar på en särskilt preparerad länk) eller DOM-baserade (sårbarheten finns helt och hållet i koden på klientsidan). Ett effektivt skydd mot XSS bygger på kodning av utdata, sanering av indata och en Content Security Policy (CSP), som begränsar vilka källor skript får laddas från.
Föråldrad programvara är ytterligare en ytterst vanlig orsak till intrång, och den är särskilt aktuell i ekosystemet kring WordPress: i Patchstacks rapport för 2025 satt 91 % av de 11 334 nyupptäckta sårbarheterna i tillägg (plugin) och 9 % i teman, medan det i WordPress-kärnan rapporterades sex fel med låg prioritet. När utvecklaren av ett tillägg eller ett tema upptäcker och rättar en sårbarhet släpps en uppdatering, men samtidigt blir uppgifterna om sårbarheten offentliga, och angriparna börjar omedelbart leta efter webbplatser som ännu inte har uppdaterats — tidsfönstret mellan offentliggörandet och den installerade uppdateringen är en av de mest kritiska perioderna för din webbplats säkerhet. Just därför är regelbundna uppdateringar inte bara god sed utan en absolut nödvändighet.
Svaga eller läckta lösenord är fortfarande ett av de enklaste sätten för angripare att komma in, eftersom många administratörer använder lösenord som är lätta att gissa, återanvänder samma lösenord i flera tjänster eller avstår från flerfaktorsautentisering, vilket gör brute force-attacker och credential stuffing (automatiserad användning av stulna inloggningsuppgifter) utomordentligt effektiva. Läget förvärras av att många använder samma e-postadress och lösenord både hos webbhotellet, i FTP-åtkomsten och i webbplatsens adminpanel, vilket betyder att ett enda läckt lösenord kan ge angriparen tillgång till hela infrastrukturen.
Steg för steg: så gör du för att återställa en hackad webbplats
När du väl har konstaterat att din webbplats har blivit hackad är det ytterst viktigt att arbeta metodiskt och i rätt ordning, i stället för att i panik börja radera filer eller installera om allt från grunden, eftersom ett kaotiskt agerande kan förstöra de spår som behövs för att identifiera angreppets källa och till och med förvärra läget om alla bakdörrar angriparen lämnat inte stängs. Nedan följer en strukturerad återställningsprocess, byggd på branschens beprövade praxis och rekommenderad av både webbhotell och säkerhetsspecialister.
Första fasen: omedelbar isolering och att frysa läget
Det allra första steget, som ska tas omedelbart efter att intrånget har upptäckts, är att isolera webbplatsen från omvärlden för att förhindra ytterligare skada, både på dina besökare och på ditt anseende. Enklast gör du det genom att slå på underhållsläget (maintenance mode), som visar besökarna ett informativt meddelande om att webbplatsen tillfälligt är otillgänglig och samtidigt blockerar åtkomsten till allt annat innehåll. Kommer du inte åt webbplatsens adminpanel kan du använda filen .htaccess för att skicka all trafik till en enkel HTML-sida med ett meddelande, eller be webbhotellet att tillfälligt stänga av kontot.
Samtidigt med isoleringen är det avgörande att ta en fullständig kopia av den komprometterade webbplatsen — både alla filer och databasen. Den kopian fyller två syften: dels bevarar den spåren som kan behövas för att fastställa angreppets källa och metod, dels är den ett skyddsnät om återställningen misslyckas och du behöver gå tillbaka till utgångsläget för att pröva ett annat tillvägagångssätt. Under inga omständigheter får saneringen börja innan kopian finns, eftersom du annars riskerar att förlora både de infekterade filerna (som kan behövas för analysen) och potentiellt rena filer, om något går snett under saneringen.
Det tredje viktiga steget i den här fasen är att kontakta webbhotellet, eftersom de har tillgång till serverns loggfiler, som kan ge värdefull information om när och hur angreppet skedde, vilka filer som ändrades och från vilka IP-adresser den obehöriga åtkomsten kom. Ligger ditt konto dessutom på en delad server måste webbhotellet kontrollera om angreppet också har drabbat andra konton på samma server och vidta åtgärder för att isolera problemet.
Andra fasen: att hitta och ta bort den skadliga koden
När webbplatsen är isolerad och kopian är tagen börjar den mest kritiska delen av återställningen — att hitta och ta bort den skadliga koden. Arbetet kräver noggrannhet och ett systematiskt arbetssätt, eftersom angripare ofta lämnar flera bakdörrar i olika delar av webbplatsen, och en enda förbisedd bakdörr betyder att angriparen kan komma tillbaka när som helst.
Första steget är en automatisk skanning med pålitliga säkerhetsverktyg, till exempel Wordfence, Sucuri eller MalCare, som går igenom alla filer och hela databasen på jakt efter kända mönster av skadlig kod, misstänkta funktioner och obehöriga ändringar. Verktygen hittar merparten av de vanliga infektionerna, men de är inte ofelbara, och därför ska den automatiska skanningen alltid följas av en manuell genomgång. Vid den manuella genomgången ägnas särskild uppmärksamhet åt de kritiska filerna, till exempel .htaccess, wp-config.php (i WordPress), functions.php, header.php och footer.php, eftersom de är de vanligaste måltavlorna och koden som injiceras i dem kan vara maskerad med tekniker som base64-kodning, anrop till eval() eller gzinflate(), vilket gör den svår att känna igen med blotta ögat.
Att sanera databasen är precis lika viktigt som att sanera filerna, eftersom angripare ofta lägger in skadligt innehåll direkt i databastabellerna — i WordPress drabbas oftast tabellerna wp_posts och wp_options, där det kan hamna skräpinnehåll, dolda länkar eller till och med PHP-kod som körs när webbplatsen laddar de aktuella posterna. För att gå igenom databasen kan du använda phpMyAdmin eller ett liknande verktyg och leta efter misstänkta poster, obehöriga administratörskonton och ovanliga ändringar i tabellen med inställningar.
När den skadliga koden är identifierad är den beprövade metoden inte att försöka laga de infekterade filerna, utan att ersätta dem med rena originalkopior — alltså att ladda ned systemets kärna och varje tillägg, tema eller modul från utvecklarens officiella källa och skriva över mapparna i sin helhet i stället för att ge sig på enskilda filer en och en. Har du egen anpassad kod i ett tema eller en modul måste den jämföras rad för rad mot en ren version, så att bara de skadliga ändringarna tas bort och dina legitima ändringar blir kvar.
Särskilt viktigt är det att gå igenom de mappar där det normalt inte ska ligga körbara filer — mapparna för uppladdningar och media — eftersom en PHP-fil som hamnat där nästan aldrig har kommit dit av en slump, med tanke på att sådana mappar bara är avsedda för bilder, video och dokument. Likaså ska webbplatsens rotkatalog gås igenom efter okända filer som kan vara bakdörrar eller verktyg som angriparen lämnat kvar. Exakt vilka mappar, filer och databastabeller som ska kontrolleras i en WordPress-installation har vi beskrivit steg för steg i guiden om en hackad WordPress-webbplats.
Tredje fasen: nya inloggningsuppgifter och härdning av systemet
När den skadliga koden är borta måste alla lösenord och åtkomstnycklar som hör till webbplatsen bytas, eftersom sannolikheten är stor att angriparen kom över dem under intrånget, och byts de inte kan angriparen helt enkelt logga in igen och kompromettera webbplatsen på nytt. Lösenordsbytet måste omfatta alla nivåer: webbplatsens administratörskonton (och alla andra konton med utökade behörigheter), lösenordet till webbhotellets kontrollpanel, uppgifterna för FTP och SFTP, databasens lösenord samt lösenorden till de e-postkonton som hör till webbplatsen.
På WordPress-webbplatser ska dessutom autentiseringsnycklarna och saltet i filen wp-config.php bytas: de krypterar ingenting, men de signerar autentiseringskakorna med HMAC-SHA256, så efter ett byte avvisar servern varenda kaka som delats ut fram till dess och avslutar alla aktiva sessioner, inklusive dem angriparen skulle kunna använda. Lösenorden ändras inte av den åtgärden — de ligger som hashvärden beräknade med bcrypt och måste bytas separat. Nya nycklar genererar du med den officiella nyckelgeneratorn på WordPress.org och klistrar helt enkelt in dem i wp-config.php i stället för de gamla värdena.
Härdningen av systemet innebär också att alla programvarukomponenter uppdateras till sina senaste versioner — det gäller CMS-kärnan, alla tillägg, alla teman och programvaran på serversidan, till exempel PHP-versionen. Allt oanvänt och övergivet ska raderas helt och inte bara avaktiveras, eftersom även ett avaktiverat tillägg med en sårbarhet kan användas för ett angrepp så länge filerna ligger kvar på servern. Särskilt farliga är de så kallade nulled-versionerna, alltså piratkopierade teman och tillägg, som ofta innehåller skadlig kod redan från början och hör till de vanligaste orsakerna till intrång.
Utöver nya lösenord och uppdaterad programvara ska också proaktiva säkerhetsåtgärder införas, sådana som märkbart sänker risken för nya angrepp. En webbapplikationsbrandvägg (WAF) är ett av de mest effektiva skydden, eftersom den filtrerar den inkommande trafiken och blockerar misstänkta förfrågningar innan de når din webbplats, vilket ger skydd mot SQL-injektioner, XSS-angrepp, brute force-attacker och många andra hot. Flerfaktorsautentisering (MFA eller 2FA) är ytterligare ett avgörande säkerhetslager, som betyder att angriparen inte kan logga in ens med ditt lösenord i handen, så länge den andra faktorn saknas, till exempel en kod ur en mobilapp eller ett sms.
På WordPress-webbplatser är det dessutom klokt att stänga av filredigeringen i adminpanelen genom att lägga till raden define('DISALLOW_FILE_EDIT', true) i wp-config.php, vilket hindrar en angripare som kommit över ett administratörskonto från att redigera tema- och tilläggsfiler direkt i gränssnittet i WordPress. Likaså är det klokt att begränsa antalet inloggningsförsök, byta det förvalda administratörsnamnet och begränsa åtkomsten till katalogen wp-admin efter IP-adress, där det är praktiskt möjligt.
Fjärde fasen: att få tillbaka anseendet i sökmotorerna
Har din webbplats hamnat bakom en säkerhetsvarning från Google, eller dyker det upp varningar om intrång i sökresultaten, är återställningen inte klar förrän varningarna är borta, eftersom de fortsätter att skrämma bort besökare och skada dina placeringar i sökresultaten även när webbplatsen redan är sanerad och härdad. Google Search Console är det centrala verktyget i den här fasen, och har du ännu inte verifierat din webbplats där är det nu hög tid att göra det.
I Google Search Console ligger rapporten ”Säkerhetsproblem” (Security Issues) i gruppen för säkerhet och manuella åtgärder, och den visar vilka konkreta problem Google har hittat på din webbplats, vilka sidor som är drabbade och vilken typ av hot som identifierats. När du har gått igenom alla saneringar och härdningar som beskrivits ovan kan du klicka på knappen ”Begär granskning” (Request Review), som talar om för Google att problemet är åtgärdat och att du ber om att få varningarna borttagna. I begäran ska det stå utförligt vad problemet bestod i, vilka konkreta steg du har tagit för att lösa det och vad de stegen resulterade i — ju mer detaljerad och konkret beskrivningen är, desto större är chansen att granskningen går snabbt och slutar väl.
Någon bestämd tidsram lovar Google inte: dokumentationen anger dels ”allt från ett par dagar till ett par veckor”, dels att en granskning vid skräppostrelaterade intrång kan ta flera veckor, eftersom den innefattar en manuell bedömning eller en ny behandling av samtliga drabbade sidor. De hackade sidorna med skräpinnehåll får inte omdirigeras till startsidan eller till andra delar av webbplatsen — i stället ska de svara med statuskoden 404 (hittades inte), så att Google efter hand plockar bort dem ur sitt index. En omdirigering kan i det läget tolkas som ett försök att dölja problemet snarare än att lösa det.
Utöver Google Search Console är det värt att kontrollera andra blockeringslistor också, till exempel Norton Safe Web och McAfee SiteAdvisor, eftersom vissa webbläsare och säkerhetsprogram använder de listorna vid sidan av Googles, och står din webbplats med i någon av dem måste du lämna in en egen begäran hos varje tjänst.
Strategi för säkerhetskopior: ditt skyddsnät
Regelbundna och pålitliga säkerhetskopior hör till de viktigaste förebyggande åtgärderna en webbplatsägare kan vidta, eftersom du även i det värsta läget — när webbplatsen är så illa komprometterad att en sanering varken är praktiskt genomförbar eller ekonomiskt försvarbar — kan återställa den från en ren kopia och bara förlorar det innehåll som tillkommit sedan kopian togs. Strategin måste däremot vara genomtänkt, för dåligt organiserade kopior kan visa sig värdelösa i precis det ögonblick då de behövs som mest.
För det första ska kopiorna omfatta både alla webbplatsens filer och databasen, eftersom en webbplats utan databas eller en databas utan filer är meningslös — båda delarna behövs för att webbplatsen ska fungera igen fullt ut. För det andra ska kopiorna förvaras utanför samma server som webbplatsen ligger på, för komprometteras servern kan angriparen radera eller infektera även de kopior som finns där. Helst förvaras kopiorna på minst två olika ställen, till exempel i molnet (Google Drive, Amazon S3, Dropbox) och på ett lokalt lagringsmedium.
För det tredje är det viktigt att spara flera versioner och inte bara den senaste, eftersom den senaste kopian redan kan vara infekterad om intrånget upptäcks sent, och då behöver du en äldre och ren version. Beprövad praxis är att spara minst 30 dagars historik, vilket gör att du kan gå tillräckligt långt tillbaka för att hitta en ren version även när intrånget upptäcks flera veckor efter att det började.
För det fjärde ska kopieringen automatiseras, eftersom manuella säkerhetskopior är opålitliga — människor glömmer, skjuter upp eller slutar helt enkelt efter en tid. De flesta webbhotell erbjuder automatiska kopior, och det finns även specialiserade tjänster och moduler som sköter uppgiften. Lika viktigt är att med jämna mellanrum kontrollera att kopiorna verkligen fungerar, genom att försöka återställa webbplatsen från dem i en testmiljö, för ingenting är värre än att i en krissituation upptäcka att kopiorna är trasiga eller ofullständiga.
Vad data, inte prognoser, säger om hackade webbplatser
Den statistik om IT-säkerhet som cirkulerar i offentligheten handlar nästan alltid om globala kostnader för IT-brottslighet i biljoner, eller om dataintrång hos stora koncerner där genomsnittskostnaden mäts i miljoner, och för ett litet eller medelstort företag med en webbplats finns det ingen praktisk nytta i det — det är siffror från en helt annan värld. Nyttiga är de data som samlats in direkt från hackade webbplatser, och dem publicerar samma företag som sanerar de webbplatserna varje dag, eftersom deras urval består av webbplatser precis som din.
I säkerhetsföretaget Sucuris rapport för 2023, som bygger på de webbplatser deras team faktiskt sanerade under året, var 39,1 % av innehållshanteringssystemen föråldrade vid infektionstillfället (Sucuri, ”2023 Hacked Website & Malware Threat Report”). I nästan två fall av fem behövde angriparen alltså inte leta efter något mer avancerat än en offentligt känd sårbarhet i ett system som ägaren inte hade uppdaterat — och just därför är ett uppdateringsschema den billigaste säkerhetsinvestering som över huvud taget finns på det här området.
Ännu mer säger det som data visar om angriparens avsikt, för det förklarar varför ett intrång så sällan ser ut som ett intrång. I samma rapport innehöll 20,30 % av de infekterade webbplatserna SEO-spam, och bland de komprometterade databaserna nådde andelen 38,3 %, medan 1,34 % av webbplatserna bar kod som stjäl kortuppgifter. Ingen av de tre sakerna är till för att förstöra webbplatsen — de är alla till för att webbplatsen ska fortsätta fungera som vanligt och under tiden tjäna pengar åt någon annan.
Och ytterligare en siffra förklarar varför en filsanering ensam aldrig räcker: på 55,2 % av de webbplatser där skadlig kod hade nått databasen fanns minst en administratörsanvändare som angriparen själv hade skapat. Ett sådant konto förblir fullständigt legitimt efter en filsanering — det har ett lösenord, det har alla behörigheter, och med det kan angriparen helt enkelt logga in på nytt och lägga tillbaka koden. Just därför är genomgången av databasen och granskningen av användarlistan ett eget steg i vår återställningsprocess, inte ett tillbehör till filsaneringen.
Långsiktig säkerhetsstrategi: ett proaktivt arbetssätt
Att återställa en hackad webbplats är bara halva historien — lika viktigt, om inte viktigare, är att bygga en långsiktig säkerhetsstrategi som märkbart sänker risken för nya intrång och håller webbplatsen så väl skyddad som möjligt mot hot som hela tiden förändras. Den strategin är ingen engångsinsats utan ett löpande arbete som kräver återkommande uppmärksamhet och egna resurser.
Regelbunden skanning efter sårbarheter och penetrationstest hör till de viktigaste delarna av det proaktiva arbetet, eftersom de gör det möjligt att hitta och täppa till säkerhetsbrister innan angriparna hinner utnyttja dem. Sårbarhetsskanningen sköts av automatiserade verktyg som med jämna mellanrum går igenom din webbplats och rapporterar det de hittar, medan ett penetrationstest är en djupare övning där en säkerhetsspecialist försöker ta sig in med samma metoder som en riktig angripare skulle använda, för att hitta de sårbarheter automatiken missar.
Åtkomstkontroll och behörighetshantering är ytterligare en avgörande del som ofta förbises — varje användare på din webbplats bör bara ha de minsta behörigheter som uppgiften kräver, och ingen bör använda administratörskontot för vardagliga sysslor som att publicera innehåll eller moderera kommentarer. Den principen, som kallas principen om lägsta behörighet, minskar skadan avsevärt om något av kontona skulle komprometteras.
Säkerhetsövervakning och analys av loggfiler är ett löpande arbete som gör det möjligt att upptäcka misstänkt aktivitet tidigt och agera innan den växer till ett fullbordat intrång. Det innefattar återkommande genomgångar av serverns åtkomstloggar, bevakning av misslyckade inloggningsförsök, kontroll av filernas integritet (som varnar när en fil ändras utan att du vet om det) och analys av nätverkstrafiken efter ovanliga mönster som kan tyda på ett angrepp eller ett dataintrång.
Att ta fram en incidenthanteringsplan är ytterligare ett viktigt steg som många ägare av små och medelstora företag hoppar över i tron att det bara behövs i stora koncerner, men i själva verket bör varje organisation som är beroende av sin närvaro på nätet ha en dokumenterad plan som beskriver vad som ska göras vid ett intrång, vem som ansvarar för varje steg, hur kunder och partner ska informeras och hur den normala driften ska komma igång igen så snabbt som möjligt. En sådan plan kortar reaktionstiden avsevärt och förhindrar kaotiska beslut i en krissituation. En del av de valen görs redan när webbplatsen beställs — om vilka misstag som kostar mest i just det skedet har vi skrivit i en egen artikel om att beställa en webbplats.
Professionell hjälp: när det är dags att ta in specialister
Många av stegen i en återställning klarar webbplatsägaren själv, men det finns lägen där professionell hjälp inte bara är att rekommendera utan nödvändig för att återställningen ska bli fullständig och säker. Har intrånget varit ovanligt komplicerat, hackas webbplatsen om efter saneringen, finns det misstanke om ett dataintrång som rör kundernas personuppgifter, eller saknar du helt enkelt tekniska kunskaper och tid för att gå igenom alla stegen, är det värt att överväga att ta in specialister på IT-säkerhet eller en specialiserad tjänst för webbplatssäkerhet.
Professionella säkerhetstjänster som Sucuri, Wordfence eller MalCare erbjuder både automatiska saneringsverktyg och manuell experthjälp, och många av dem tillhandahåller dessutom löpande övervakning och skydd efter återställningen. Kostnaden för sådana tjänster är oftast mycket lägre än de förluster ett utdraget intrång leder till — förlorad trafik, minskat förtroende hos kunderna, möjliga rättsliga följder vid ett dataintrång och den tid som går åt när du försöker lösa problemet själv utan tillräckliga kunskaper.
Behandlas personuppgifter på din webbplats och har det inträffat en personuppgiftsincident, kan du dessutom vara skyldig att underrätta tillsynsmyndigheten och de drabbade personerna enligt dataskyddsförordningen (GDPR) eller annan tillämplig lagstiftning, och i det läget är det särskilt viktigt att dokumentera hela återställningen och spara underlaget för de åtgärder som vidtagits.
De vanligaste frågorna.
Hur lång tid tar det att återställa en hackad hemsida?
I vår erfarenhet tar hela processen från förfrågan till överlämning 8–72 timmar, och arbetet inleder vi normalt inom några timmar efter att förfrågan kommit in. Skillnaden mellan åtta och sjuttiotvå timmar avgörs nästan alltid av hur djupt angriparen hann rota sig, hur brett filerna och databasen är infekterade och hur gammal den senaste rena kopian är. Att få bort Googles varning är ett eget steg som ligger utanför vår kontroll: någon bestämd tidsram lovar Google inte, och dokumentationen nämner både några dagar och några veckor.
Bör jag betala lösensumman som utpressningsprogrammet kräver?
Nästan alltid nej. Både säkerhetsexperter och brottsbekämpande myndigheter avråder från att betala, och det finns tre skäl till det: det finns ingen som helst garanti för att angriparna verkligen dekrypterar dina data när betalningen kommit in; betalningen finansierar fortsatt brottslighet; och organisationer som betalar blir ofta måltavlor på nytt, eftersom angriparna nu vet att de är beredda att betala. Fokusera i stället på att återställa data från säkerhetskopior och på att härda systemet.
Hur kontrollerar jag om min webbplats är svartlistad?
Enklast gör du det i Google Search Console, där avsnittet ”Säkerhetsproblem” visar allt Google har hittat på webbplatsen. Utöver det kan du använda kostnadsfria verktyg på nätet, till exempel Googles diagnossida för Safe Browsing (transparencyreport.google.com), Sucuri SiteCheck eller VirusTotal, som kontrollerar din adress mot flera listor samtidigt. Kom ihåg att kontrollera både med och utan www och, om webbplatsen har flera domäner, var och en för sig.
Är gratis säkerhetstillägg tillräckligt effektiva?
Gratis säkerhetstillägg som Wordfence eller gratisversionen av Sucuri ger ett grundskydd som är avsevärt bättre än inget skydd alls, och de räcker gott för mindre personliga webbplatser och bloggar. För företagswebbplatser och webbutiker, där följderna av ett intrång kan bli kännbara i kronor, är det däremot klokt att investera i betalda säkerhetslösningar med funktioner som brandvägg i realtid, automatisk borttagning av skadlig kod, återkommande skanning och prioriterad support vid en incident.
Hur skyddar jag min webbplats mot att bli hackad igen?
Inte med ett enda verktyg, utan med flera lager som täcker varandras luckor. En säkerhetsstrategi i flera lager omfattar regelbundna uppdateringar, starka och unika lösenord tillsammans med flerfaktorsautentisering, en webbapplikationsbrandvägg, säkerhetskopior som tas regelbundet och förvaras utanför servern, begränsade behörigheter enligt principen om lägsta behörighet, återkommande säkerhetsskanning och övervakning, samt utbildning av personalen i grunderna för IT-säkerhet och i att känna igen nätfiske. Att återställa en hackad webbplats en gång är arbete; att slippa göra om det är rutin.
Hackad WordPress- eller Laravel-webbplats? Behöver webbplatsen återställas efter intrånget? Vi återställer, sanerar och härdar den — vanligtvis på 8–72 timmar, med orsaken hittad och Googles varning borttagen.