Kort sagt: Om ni vill ta bort skadlig kod från er webbplats räcker det sällan att radera enskilda filer. Vi säkrar först fynden, hittar webshells, bakdörrar och dolda uppgifter, bygger upp på nytt från tillförlitliga källor och stänger ingångsvägen. Först då håller rensningen.
Hur ni känner igen skadlig kod på webbplatsen
Skadlig kod på webbplatser upptäcks ofta först indirekt. Typiskt är omdirigeringar till främmande sidor, spaminnehåll som bara syns för sökmotorer eller mobila enheter, en Google-varning i sökresultatet, klagomål från kunder eller en spärr från webbhotellet på grund av utskick av spam. På servern syns okända PHP-filer, nya adminkonton, ändrade .htaccess-filer eller oförklarliga cronjobb.
Efter PHP2Shell tillkommer en ytterligare oro: Via CVE-2026-109618 och CVE-2026-109619 kan angripare köra kod utan inloggning. Det finns inga publicerade, bekräftade Indicators of Compromise; upptäckten bygger på beteendeanalys. Hur webshells typiskt ser ut och var de ligger beskrivs i Känn igen och ta bort webshells.
Ta bort skadlig kod från webbplatsen: varför grundligt är viktigare än snabbt
Angripare lägger sällan bara ut en fil. Vanligt är flera bakdörrar på olika ställen: i uppladdningsmappar, i plugins eller teman, i must-use-plugins, i databasen, i cronjobb eller i extra användarkonton. Raderas bara den mest iögonfallande filen kommer den skadliga koden tillbaka.
Samtidigt är det angripna tillståndet ett bevismedel. Den som rensar förhastat förlorar möjligheten att fastställa om kunddata är berörda. Därför säkrar vi före varje ändring. Det kostar lite tid och håller alla vägar öppna för er, även en senare anmälan till tillsynsmyndighet eller försäkringsgivare.
En PHP-uppdatering eller en CMS-uppdatering tar inte bort skadlig programvara som redan ligger på servern. Och en rensad webbplats angrips på nytt så länge ingångsvägen är öppen.
Var skadlig kod typiskt gömmer sig
Följande ställen kontrollerar vi vid varje rensning, eftersom de i praktiken drabbas om och om igen:
| Plats | Typiskt fynd |
|---|---|
| Uppladdningsmappar | PHP-filer med harmlöst klingande namn eller förklädda till bilder |
| Plugins, teman, moduler | extra filer eller ändrade originalfiler |
| Konfiguration | insmugglade rader i .htaccess, .user.ini eller startfiler |
| Databas | främmande adminkonton, skript i innehåll eller alternativ |
| System | cronjobb, extra SSH-nycklar, processer utan synbart syfte |
| Cacher och temporära mappar | kopior av skadlig kod som dyker upp igen efter radering |
Viktigt är sammanhanget: Ett enskilt fynd förklarar sällan hela incidenten. Först helhetsbilden visar hur angriparen gick till väga och om inloggningsuppgifter har tagits med.
Hur hjälper PHP SOS konkret?
- Säkra: Vi skapar en kopia av filer, databas och loggar i det angripna tillståndet. Den bevaras för en senare analys.
- Söka: Vi jämför programfiler med tillverkarens original, kontrollerar uppladdningsmappar efter körbar kod och går igenom databas, cronjobb, användarkonton och serverkonfiguration. För WordPress-miljöer går vi tillväga som beskrivs i Hitta bakdörrar i WordPress.
- Rensa: Kärna, tillägg och teman installerar vi på nytt från tillförlitliga källor i stället för att laga misstänkta filer en och en. Eget innehåll och uppladdningar kontrollerar vi separat och för bara över det som är oproblematiskt.
- Stänga orsaken: Vi patchar PHP och applikationen, tar bort främmande konton och byter ut alla inloggningsuppgifter och nycklar som angriparen kan ha sett.
- Efterkontroll: Vi bevakar webbplatsen efter rensningen med avseende på nya förändringar och hjälper er att låta pröva en Google-varning via Search Console. Mer om det under Ta bort Google-varning.
För administratörer en ofarlig första blick på nyligen ändrade PHP-filer:
# PHP-filer i webbkatalogen som har ändrats under de senaste 10 dagarna
find /var/www -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
Resultatet är en indikation, inte ett bevis: Angripare kan ändra tidsstämplar.
Vad ni får och vad vi behöver
Ni får en rapport med de funna skadliga komponenterna och var de låg, rensningsåtgärderna, listan över utbytta inloggningsuppgifter och den sannolika ingångsvägen. Vi skiljer därvid tydligt på vad som är belagt, vad som är sannolikt och vad som är okänt.
Vi behöver från er:
- Åtkomst till server eller hostingpanel, CMS-backend och databas
- en kontaktperson som kan godkänna lösenordsbyten och avstängningar
- Information om byrå, utvecklare eller webbhotell och om egna anpassningar av systemet
- befintliga säkerhetskopior med datum, så att vi kan bedöma vilket skick som kan vara rent
- Åtkomst till Google Search Console, om en varning visas
Vad vi inte lovar
Vi lovar inte att varje bakdörr på varje system hittas med säkerhet om loggar saknas eller om angreppet ligger långt tillbaka. Vid oklart läge rekommenderar vi en nyuppbyggnad på en ny server dit bara kontrollerat innehåll förs över. Det är mer arbetskrävande men ofta den mer tillförlitliga vägen. Vi förutsäger inte heller när Google eller andra tjänster tar bort en varning; det avgör dessa leverantörer.
Om det ska klarläggas på ett sätt som håller i domstol vad som exakt hände och vilka data som är berörda tar vi med IT-forensik med specialiserade partner. Vid ett akut, fortfarande pågående angrepp börjar arbetet med akuthjälp vid hackad webbplats.
Vanliga frågor
Räcker ett plugin för malwareskanning för att rensa min webbplats?
En skanner hittar kända mönster men inte varje bakdörr. Webshells är ofta förvrängda, ligger i bilder, cacher eller databasen eller är förankrade som cronjobb. En skanner är ett hjälpmedel, inte en fullständig rensning.
Kan jag helt enkelt återställa en gammal säkerhetskopia?
Bara om det är säkert att säkerhetskopian skapades före intrånget och om ingångsvägen stängs efteråt. Annars är webbplatsen ren en kort stund och angrips på nytt på samma väg.
Varför dyker den skadliga koden upp igen efter radering?
Oftast finns det en andra bakdörr, ett cronjobb, ett manipulerat adminkonto, eller så är sårbarheten fortfarande öppen. Först när alla mekanismer för bestående åtkomst är funna och orsaken är åtgärdad håller rensningen.
Tar en PHP-uppdatering bort befintlig skadlig kod?
Nej. En patch stänger sårbarheten men tar inte bort skadlig programvara som redan förts in. Båda är skilda arbetssteg.