Kort sagt: Om er webbplats har hackats hjälper den här checklistan er att inte glömma något: först begränsa och säkra bevis, sedan hitta orsaken och sanera, därefter förnya alla åtkomster, kontrollera skyldigheter och avsluta incidenten dokumenterat. Ordningen är viktig, för den som raderar först förlorar spår, och den som bara sanerar utan att stänga sårbarheten angrips på nytt.
Vad den här checklistan gäller när webbplatsen har hackats
Checklistan vänder sig till ledning, ägare och it-ansvariga efter ett bekräftat eller sannolikt angrepp mot en webbplats, en butik eller en PHP-webbserver. Den passar även efter PHP2Shell, om en server var nåbar före uppdateringen och det finns tecken på att den komprometterats.
Inte varje punkt passar i varje miljö. Gå ändå igenom listan fullständigt och anteckna för varje punkt om den är klar, inte tillämplig eller öppen. Det protokollet är senare värdefullt för försäkring, dataskydd och intern uppföljning.
För in datum, klockslag, ansvarig person och resultat för varje steg. Om flera personer är inblandade, utse en person som för listan och dokumenterar beslut.
Fas 1: begränsa och säkra direkt
- Begränsa skadan: Sätt webbplatsen i underhållsläge eller ta den offline om besökare är utsatta eller data kan läcka ut. BSI (Tysklands federala myndighet för informationssäkerhet) rekommenderar vid PHP2Shell att tillfälligt ta ej patchade webbservrar offline om en uppdatering inte kan göras direkt.
- Radera ingenting: Ta inte bort några filer, installera inte om servern och töm inga loggar innan spåren är säkrade.
- Säkra loggar: Kopiera åtkomst-, fel-, PHP-FPM- och systemloggar till ett annat system och notera kontrollsummor. För PHP2Shell rekommenderar fackpressen att spara loggar från och med den 20 oktober 2026.
- Säkra en avbild: Skapa en kopia av filer och databas, vid virtuella servrar en ögonblicksbild, som bevisläge och ändra den inte.
- Informera ansvariga: Koppla tidigt in ledning, dataskyddsombud, webbhotell och, om sådan finns, cyberförsäkring. Många försäkringar har anmälningsskyldigheter.
Fas 2: hitta orsaken och sanera
- Fastställ ingångsvägen: Analysera loggar, filändringar och versioner. Kontrollera PHP självt, CMS, teman, tillägg, inloggningsuppgifter och servertjänster. Utan känd orsak kvarstår risken för ett nytt angrepp.
- Stäng sårbarheten: Uppgradera PHP till en åtgärdad version (8.5.12, 8.4.27, 8.3.36 eller 8.2.35 respektive leverantörens bekräftade backport), uppdatera CMS och tillägg, starta om alla PHP-workers.
- Avgränsa tidsperioden: Fastställ den tidigaste tidpunkten för misstänkt aktivitet. Den avgör vilka säkerhetskopior som kan vara rena och vilka data som kan vara berörda.
- Ta bort bakdörrar: Granska och ta bort webshells, främmande PHP-filer i uppladdnings- och cachemappar, ändrade kärnfiler, cronjobb, SSH-nycklar och systemtjänster. Ersätt kärnfiler från en ren källa.
- Rensa databasen: Ta bort okända adminkonton, insmugglade skript i innehåll och inställningar samt skräpinnehåll.
- Överväg ominstallation: Vid djupgående komprometterad server är en ominstallation på ett nytt, patchat system med granskade data ofta den säkrare vägen än en sanering i det löpande systemet.
Fas 3: förnya åtkomster och härda
- Byt lösenord: För CMS, hostingkonto, panel, databas, FTP, SFTP, SSH och e-post, och det från en ren enhet.
- Byt nycklar och tokens: Skapa nya API-nycklar, gränssnitt mot betal- och fraktjänster, CMS:ets applikationsnycklar, SSH-nycklar och certifikat som låg på servern.
- Avsluta sessioner: Logga ut alla aktiva inloggningar i CMS och hos tjänster och kontrollera registrerade tvåfaktorsenheter.
- Aktivera tvåfaktorsinloggning: För alla adminåtkomster, inklusive hosting, domän och DNS.
- Härda servern: Kontrollera och dokumentera PHP-inställningar, filrättigheter, körningsspärrar i uppladdningsmappar, brandvägg och säkerhetsheaders.
Fas 4: skyldigheter, kommunikation och avslut
- Kontrollera anmälningsskyldigheter: Kan personuppgifter ha påverkats kan en anmälan inom 72 timmar enligt GDPR art. 33 vara nödvändig. Bedömningen hör hemma hos dataskyddsombud eller advokat. Branschskyldigheter, till exempel enligt NIS2, kontrolleras separat.
- Överväg anmälan: Polisens Zentrale Ansprechstellen Cybercrime (ZAC, centrala kontaktpunkter för it-brottslighet) tar emot anmälningar från företag. De säkrade loggarna är ett viktigt underlag för det.
- Informera kunder och Google: Informera berörda sakligt och samordnat. Visar Google en varning, begär granskning efter saneringen, som beskrivs under Ta bort Googles varning.
- Dokumentera avslutet och övervaka: Anteckna orsak, tidsperiod, åtgärder och öppna punkter i en rapport, dra lärdomar för nödlägesplanen och övervaka systemen förstärkt under de följande veckorna.
Vanliga fel i uppföljningen
Många incidenter drar ut på tiden eftersom man i första hettan sparar på fel ställe eller agerar för snabbt. De här felen bör ni undvika:
- Bara ta bort det synliga: En raderad skräpsida eller en borttagen omdirigering är inget bevis för en ren webbplats. Bakdörrar förblir ofta obemärkta.
- Byta lösenord från det berörda systemet: Körs fortfarande skadlig programvara på datorn eller servern kan nya inloggningsuppgifter läcka ut direkt igen.
- Blint återställa en säkerhetskopia: Utan stängd sårbarhet och utan granskning av säkerhetskopian står angriparen snart i dörren igen.
- Tolka patchen som avvisning av faran: En uppdatering till en åtgärdad PHP-version bevisar inte att inget hände dessförinnan och tar inte bort insmugglad skadlig programvara.
- Kontrollera skyldigheter för sent: Frister börjar löpa när incidenten blir känd, inte när saneringen är klar.
- Ingen dokumentation: Utan protokoll går frågor från försäkring, myndigheter eller kunder senare knappast att besvara.
Den här checklistan ersätter ingen juridisk rådgivning. Vid frågor om anmälningsskyldigheter, ansvar eller försäkring, vänd er till ert dataskyddsombud, en advokat eller er försäkringsgivare.
Hur hjälper PHP SOS konkret?
- Vi tar över den strukturerade incidenthanteringen och går igenom checklistan tillsammans med er, punkt för punkt med protokoll.
- Vi säkrar loggar och systemnivåer så att de förblir användbara för försäkring, myndigheter och en möjlig IT-forensik.
- Vi stänger sårbarheten, saneras eller bygger upp på nytt och förnyar åtkomster i rätt ordning.
- Vi levererar en slutrapport med orsak, åtgärder och rekommendationer och övervakar systemen därefter vidare på begäran.
Vanliga frågor
Vad är det första jag bör göra om min webbplats har hackats?
Behåll lugnet, radera ingenting och begränsa skadan. Ta vid behov webbplatsen offline eller i underhållsläge och säkra loggar och filer innan ni sanerar. Därefter följer orsakssökning och sanering.
Räcker det att återställa webbplatsen från en säkerhetskopia?
Oftast inte. Säkerhetskopian kan redan innehålla skadlig kod, och sårbarheten som angriparen kom in genom är efter återställningen fortfarande öppen. Stäng först orsaken, återställ sedan en granskad, ren nivå på ett uppdaterat system.
Måste jag anmäla en hackning till dataskyddsmyndigheten?
Om personuppgifter kan ha påverkats föreskriver art. 33 GDPR i princip en anmälan inom 72 timmar efter att ni fått kännedom, om en risk för de registrerade inte är osannolik. Bedömningen hör hemma hos ert dataskyddsombud eller en advokat.
När är en incident verkligen avslutad?
När orsaken är stängd, alla kända bakdörrar borttagna, åtkomster förnyade, skyldigheter uppfyllda och åtgärderna dokumenterade. En tid av förstärkt övervakning därefter hör dit, för att upptäcka förbisedda spår.