Kort sagt: Om ni installerar om en server efter ett hack eller saniterar den beror på hur säkert ni känner till intrångets omfattning. Kan angriparen ha haft root-rättigheter, är tidpunkten för intrånget oklar eller saknas loggar är en ombyggnad från pålitliga källor det säkrare valet. En sanering kommer bara i fråga vid snävt avgränsat, väl belagt angrepp. I båda fallen gäller: först säkra bevis och stänga luckan, sedan städa.
Varför frågan ställs särskilt ofta efter PHP2Shell
PHP2Shell tillåter enligt php.net körning av skadlig kod på distans utan inloggning. Den som har drivit en opatchad server måste därför fråga sig om något har hänt sedan 17.10.2026, det enligt medierapporter första observerade angreppsförsöket. Patchen besvarar inte den frågan, och det finns inga publicerade, bekräftade Indicators of Compromise.
Hittas sedan en misstänkt fil, en okänd process eller ett främmande cronjobb står beslutet för dörren. Impulsen är ofta att snabbt radera eller installera om direkt. Båda kan vara rätt, men inte som första steg.
Ordningsföljden före beslutet
Innan ni väljer mellan sanering och ominstallation ska tre saker vara gjorda. De gäller för båda vägarna.
- Avgränsa: Ta servern från nätet eller begränsa åtkomsten till det nödvändigaste, utan att stänga av den om arbetsminnet ännu ska säkras.
- Säkra bevis: Säkra loggar, filer, databas och helst en avbild av systemet, med datum och kontrollsumma. Varför det är nödvändigt före varje nyinstallation förklarar Säkra bevis innan ni installerar om.
- Involvera försäkringsgivare och dataskydd: Många cyberförsäkringar förväntar sig att väsentliga steg samordnas. Anvisningar står under Cyberförsäkring: vad som räknas vid skada. Om det finns en anmälningsplikt enligt GDPR bedömer dataskyddsombud eller advokat.
Först därefter lönar sig själva avvägningen.
Installera om servern efter hack eller sanera: kriterierna
| Kriterium | Sanera | Installera om |
|---|---|---|
| Intrångets omfattning | Snävt avgränsad, belagd, till exempel en fil i uppladdningsmappen utan andra spår | Oklar eller med tecken på systemåtkomst |
| Angriparens möjliga root-rättigheter | Uteslutna med goda belägg | Kan inte uteslutas |
| Tillgång till loggar | Fullständiga för den relevanta perioden | Ofullständiga, överskrivna eller manipulerbara |
| Arbetsinsats | Mindre, om fyndet är tydligt | Större, men bättre planerbar |
| Kvarstående osäkerhet | Högre, dolda bakdörrar är svåra att utesluta | Lägre, om det byggs upp rent från pålitliga källor |
| Avbrottstid | Oftast kortare | Oftast längre, går att styra väl med förberedelse |
| Lämplighet för äldre system | Problematiskt om systemet ändå är föråldrat | Bra tillfälle att byta till en PHP-version som stöds |
Som tumregel gäller: Ju mindre ni vet, desto mer talar för ombyggnad. Vid en lucka i PHP-tolken som kör kod i webbserveranvändarens sammanhang kan en angripare utnyttja ytterligare sårbarheter för att få fler rättigheter. Det går knappast att utesluta utan en grundlig undersökning.
Båda vägarna i praktiken
Vad ”installera om” egentligen innebär
Att installera om betyder inte att kopiera den gamla säkerhetskopian till en ny server. En ombyggnad börjar med ett rent operativsystem från officiell källa, aktuella paket och en patchad PHP-version. Applikationen installeras från tillverkarens original, tillägg och teman likaså.
Först därefter kommer de egna innehållen, och det kontrollerat. Uppladdade filer får inte innehålla körbara skript, databasen kan innehålla insmugglat innehåll, till exempel dolda administratörskonton eller skript i inlägg. Konfigurationsfiler skrivs om i stället för att kopieras. Alla inloggningsuppgifter förnyas: databas, CMS-administratörer, SSH-nycklar, API-nycklar, hostingpanel.
Säkerhetskopior spelar en viktig roll, men bara om deras tillstånd ligger före intrånget och de själva inte har ändrats. Flera generationer på åtskilda platser gör det kontrollerbart; mer om det under Säkerhetskopior enligt 3-2-1-regeln.
När sanering är försvarbar
En sanering kan vara rimlig om angreppet upptäcktes tidigt, fullständiga loggar finns och undersökningen inte ger något tecken på ytterligare åtkomster. Då tas de funna filerna bort efter säkringen, cronjobb, användarkonton och SSH-nycklar kontrolleras och kärnfiler jämförs med tillverkarens original.
Viktigt är en realistisk bedömning: Webshells är ofta oansenliga och gömda på flera ställen. Hur man hittar dem beskriver Känna igen och ta bort webshells. Efter en sanering bör servern övervakas noga så att en förbisedd bakdörr upptäcks.
Radera ingenting innan loggar och filer är säkrade, och stäng luckan innan servern kommer tillbaka på nätet. Annars förlorar ni spåren och bjuder in nästa intrång.
När ni inte behöver någon leverantör
Vid en enkel webbplats på delad hosting där hostingleverantören förvaltar systemet och bekräftar PHP-patchen ligger beslutet ofta inte alls hos er. Ni kan installera om applikationen från originalet, granska innehållet och förnya inloggningsuppgifter, med stöd av hostingleverantören. Även ett erfaret internt team kan klara en ombyggnad själva om säkring av bevis och dokumentation sitter.
Extern hjälp lönar sig om root-rättigheter inte kan uteslutas, personuppgifter kan vara berörda, försäkringen är inblandad eller flera system hänger ihop.
Hur hjälper PHP SOS konkret?
- Vi säkrar loggar, filer och databas på ett bevisbart sätt innan något ändras.
- Vi bedömer intrångets omfattning och rekommenderar sanering eller ombyggnad med motivering, uppdelat i belagt, sannolikt och okänt.
- Vi bygger vid behov om servern från pålitliga källor, med patchad PHP-version och förnyade åtkomster.
- Vi tar hand om skadeprogramsborttagning där en sanering är försvarbar och dokumenterar varje steg.
Slutsats
Frågan ”installera om eller sanera?” besvaras genom kunskapen om intrånget. Den som inte säkert känner till omfattningen bygger om. Den som kan avgränsa det väl belagt får sanera. I båda fallen gäller samma ordning: avgränsa, säkra, stänga luckan, sedan städa.
Vanliga frågor
Är det alltid bättre att installera om efter ett hack?
Inte alltid, men ofta. Om det är oklart hur långt angriparen kom är en ombyggnad från pålitliga källor oftast det säkrare valet. Vid ett snävt avgränsat, väl belagt angrepp kan en sanering räcka.
Kan jag bara återställa en gammal säkerhetskopia?
Bara om det är säkert att säkerhetskopian skapades före intrånget och inte innehåller någon bakdörr. Dessutom måste luckan vara stängd i förväg, annars är servern omedelbart sårbar igen. Nyare data måste kontrolleras separat.
Vad måste jag säkra före ominstallationen?
Loggar, en kopia av filerna och databasen samt, om möjligt, en avbild av systemet. Dessa bevis behöver ni för orsaksanalys, försäkring och en möjlig anmälan. Efter radering är de borta.
Räcker det att radera den hittade webshellen?
Sällan. Angripare lägger ofta flera bakdörrar, till exempel cronjobb, användarkonton eller SSH-nycklar. Den som bara raderar den synliga filen lämnar de andra åtkomsterna öppna.