Kort sagt: Om er webbplats har hackats är den viktigaste frågan ”vad gör vi utan att förstöra spår?”. Vi tar på distans hand om begränsningen, säkrar loggar och filer, tar bort skadlig kod, stänger ingångsvägen och dokumenterar allt. Ni behåller besluten, vi levererar de tekniska fakta.
Webbplatsen hackad: vad göra den första timmen?
De första stegen avgör om incidenten senare går att klarlägga rent. Lugn är viktigare än fart till varje pris. Dessa punkter kan ni själva göra genast:
- Radera ingenting: inga filer tas bort, ingen nyinstallation över det gamla läget, ingen återställning av en säkerhetskopia innan något har säkrats.
- Avskärma: sätt webbplatsen i underhållsläge eller ta den tillfälligt från nätet om besökare är utsatta eller data kan läcka ut.
- Spara loggar: be ert webbhotell att inte skriva över åtkomst- och felloggar. Vid PHP2Shell rekommenderar facktidningarna att spara serverloggar från och med den 20 oktober 2026.
- Anteckna åtkomster: Vem har admin-, FTP-, SSH- och panelåtkomst? Byt lösenord först efter överenskommelse, och då från en ren enhet.
- Informera berörda: ledning, dataskyddsombud och, om en försäkring finns, försäkringsgivaren.
Utgå från att en angripare med åtkomst till webbservern även kunde läsa inloggningsuppgifter ur konfigurationsfiler. Databas-, e-post- och API-åtkomster hör därför till listan över hemligheter som ska bytas.
Vilka tecken som tyder på ett intrång beskriver sidan Är jag redan komprometterad?.
Hur hjälper PHP SOS konkret?
- Lägesbild: Vi klarlägger med er vad som har observerats, vilka system som kan vara berörda och vilka data som finns där. Därav följer en kort bedömning med nästa steg.
- Säkra och begränsa: Vi säkrar filer, databas och loggar innan något ändras. Därefter begränsar vi angreppet, till exempel genom att spärra misstänkta åtkomster, stänga av angripna funktioner eller tillfälligt avskärma.
- Hitta och stänga ingångsvägen: Vi kontrollerar PHP-version och patchstatus, CMS, tillägg och åtkomster. Ligger intrånget via PHP2Shell nära patchar vi och startar om alla PHP-processer.
- Rensa och återställa: Webshells, bakdörrar och manipulerade filer tas bort, eller så byggs läget upp på nytt från tillförlitliga källor. Detaljer finns under Ta bort skadlig kod och webshells.
- Avslut och rapport: Ni får en dokumentation av incidenten och rekommendationer för härdning. Behövs en utredning som håller i domstol tar vi in specialiserade partner för forensik.
Vad ni får från oss
- en tidslinje över incidenten, så långt den går att belägga ur spåren
- en lista över funna och borttagna skadliga komponenter
- beskrivningen av den sannolika ingångsvägen, tydligt uppdelad i belagt, sannolikt och okänt
- en lista över alla ändrade åtkomster och hemligheter
- rekommendationer om vad som bör säkras varaktigt
Rapporten hjälper vid samtal med dataskyddsombud, försäkringsgivare och i förekommande fall polis. För den rättsliga bedömningen, till exempel anmälningsskyldigheten enligt GDPR inom 72 timmar, ersätter den ingen rådgivning av experter.
Vad vi behöver från er
- Åtkomster: till servern (SSH eller panel), till CMS-backend och till databasen, alternativt tillstånd att tala direkt med ert webbhotell
- Kontaktperson: en nåbar person med beslutsbefogenhet för avstängning, omstarter och lösenordsbyten
- Information: sedan när problemet märks, vilka ändringar som nyligen gjordes, vem som hade åtkomst
- Säkerhetskopior: var säkerhetskopior finns och hur gamla de är
- Kontakt med leverantörer: byrå, utvecklare eller webbhotell som känner systemet
Vad vi inte lovar
Vi kan inte lova att varje angrepp går att rekonstruera fullständigt. Om loggar saknas eller redan har skrivits över kvarstår luckor, och dem pekar vi öppet ut. Vi lovar inte heller att en rensad webbplats förblir säker för alltid. Vi arbetar med incidenten tills den är avslutad och dokumenterad och talar om vad som återstår därefter.
Juridisk rådgivning ger vi inte. Frågor om anmälningsskyldighet, ansvar eller försäkringsskydd hör hemma hos dataskyddsombud, jurist och försäkringsgivare. För ett strukturerat arbete efter incidenten hjälper vår checklista efter ett hack.
När en större incidenthantering behövs
Vissa incidenter sträcker sig bortom en enskild webbplats: flera servrar, läckta kunddata, utpressning eller en angripare som rör sig vidare i nätet. Då går vi över till en strukturerad incident response med fasta roller, lägesmöten och avstämd kommunikation. Övergången går vi igenom med er så snart det börjar visa sig.
Även efter en mindre incident lönar det sig att blicka framåt. En rensad webbplats utan härdning, uppdateringar och övervakning förblir ett givet mål, eftersom angripare ofta kontrollerar kända offer på nytt. Det är därför meningsfullt att efter avslutet fastställa vem som framöver ansvarar för uppdateringar, säkerhetskopior och kontroll. Ofta visar incidenten just där en lucka: Ingen kände sig ansvarig, eller så låg åtkomsterna hos en leverantör som inte längre gick att nå. Dessa frågor klarlägger vi med er i det avslutande samtalet så att incidenten blir till en bättre drift.
Vanliga frågor
Ska jag genast radera den hackade webbplatsen och sätta upp den på nytt?
Gör det inte förhastat. Den som raderar allt förstör de spår som visar hur angriparen kom in och om data har läckt ut. Bättre är att ta sidan från nätet eller avskärma den och först säkra.
Hur ser jag att min webbplats har hackats?
Typiska tecken är främmande omdirigeringar, spamsidor i Googles index, okända adminkonton, nya PHP-filer eller varningar från webbläsare, webbhotell eller Google. Även kraftigt ökad serverbelastning eller avvikande utgående datatrafik kan vara tecken.
Måste jag anmäla ett hackerangrepp?
Om personuppgifter kan vara berörda kan en anmälningsskyldighet till tillsynsmyndigheten inom 72 timmar föreligga. Om det gäller er klarar ni ut med ert dataskyddsombud eller en jurist.
Hjälper akuthjälpen även om servern ligger hos ett webbhotell?
Ja. Vi arbetar med den åtkomst ni har och samråder vid behov med ert webbhotell. Vad vi kan kontrollera beror på de rättigheter ni kan ge oss.