Kort sagt: Berörs ni? Ring oss. Vi hjälper er. Om ni misstänker att er server har hackats är en sak viktigast först: bevara spåren. Från första meddelandet tar vi hand om lägesbilden, säkringen, begränsningen, rensningen och dokumentationen på distans, tills incidenten är avslutad.
Radera ingenting och installera inte om något nu. Återställ inte heller någon säkerhetskopia innan allt har säkrats. Den som städar förstör just de spår som visar hur angriparen tog sig in. Anmäl nödläge, så går vi tillväga tillsammans.
Berörs ni? Tecken på att en server har hackats
En misstanke räcker för att höra av sig. Ni behöver inte bevisa angreppet. Typiska ledtrådar är:
- Webbservern eller PHP-FPM startar processer som
shellerbash. Det är en stark varningssignal, som vi förklarar på sidan Webbservern startar ett skal. - I uppladdnings-, cache- eller temp-mappar ligger nya eller okända PHP-filer.
- Det finns cronjobb som ingen har skapat, eller SSH-nycklar som ingen kan koppla till någon.
- Belastningen är hög utan synlig orsak, eller servern upprättar ovanliga utgående förbindelser.
- E-post från er server hamnar i skräpposten eller avvisas.
- Webbhotellet, en kund eller en varning i webbläsaren meddelar skadlig kod.
- I CMS:et dyker det upp administratörskonton som ingen har skapat.
Fler tecken finns under Är jag redan komprometterad?. Om flera punkter stämmer, behandla servern som hackad tills motsatsen är belagd.
Server hackad: det här gör ni direkt
- Behåll lugnet och ändra ingenting. Radera inga filer, gör inga ”snabba reparationer”, ingen nyinstallation över det gamla läget.
- Anteckna tidpunkten. Notera vad ni har observerat och när, och vem som senast gjorde ändringar i systemet.
- Bevara loggarna. Åtkomst-, fel- och systemloggar får inte roteras eller skrivas över. Vid PHP2Shell rekommenderar fackpressen att serverloggar sparas från och med den 20 oktober 2026.
- Minska angreppsytan. Ta servern från det offentliga nätet eller spärra den med brandväggen om data kan läcka ut. Stäng inte bara av den.
- Samla åtkomsterna. Vem har SSH-, panel-, FTP-, CMS- och databasåtkomst? Byt lösenord först efter överenskommelse och bara från en ren enhet.
- Utse en kontaktperson. En person med beslutsbefogenhet bör vara nåbar, även för avstängning och omstarter.
- Hör av er nu. Ring eller skriv via WhatsApp. Allt annat klarlägger vi med er steg för steg.
Ta bort från nätet eller låta det löpa?
Det är den vanligaste frågan de första minuterna, och den har inget generellt svar. Körs en webbutik med betalningar eller en portal med kunduppgifter väger skyddet av data oftast tyngst. Då är en tillfällig avskärmning rätt, till exempel via en underhållssida eller en brandväggsregel som bara släpper in era administratörer.
En hård avstängning är däremot sällan det bästa första steget, eftersom det finns spår i arbetsminnet som en omstart raderar. Bättre är en avbild av systemet, till exempel en snapshot hos webbhotellet, innan något ändras. I PHP2Shell-läget rekommenderar BSI att webbservrar tillfälligt tas offline om en uppdatering inte är möjlig direkt. Det betyder inte att varje avstängd server har hackats.
Om ni i ert fall ska skärma av, strypa eller låta det löpa avgör vi tillsammans med er utifrån det som finns på systemet.
Installera om eller rensa?
Många vill helst bygga upp servern på nytt direkt. Det är inte fel, men först efter säkringen. Annars förblir det oklart hur angriparen tog sig in, och samma väg står öppen även för det nya systemet. Avvägningen beskrivs på sidan Installera om servern eller rensa den?, och säkringen inför en ny uppbyggnad på sidan Säkra bevis innan ni installerar om.
Viktigt: En PHP-uppdatering ensam löser inte problemet. Den stänger sårbarheten men tar inte bort skadlig programvara som redan förts in. Hur spår kan hittas i loggarna står under Analysera webbserverloggar efter ett angrepp. Och utgå från att inloggningsuppgifter ur konfigurationsfiler har lästs med: åtkomster till databas, e-post och API hör hemma på listan över hemligheter som ska förnyas.
Hur hjälper PHP SOS konkret?
- Kartlägga läget: Vi klarlägger med er vad som har observerats, vilka system som kan vara berörda och vilka uppgifter som finns där.
- Säkra och stänga: Vi säkrar filer, databas och loggar innan något ändras. Därefter begränsar vi angreppet och stänger ingången, vid PHP2Shell med patch och omstart av alla PHP-processer.
- Granska och rensa: Vi söker efter webshells, bakdörrar, cronjobb och främmande åtkomster och tar bort dem. Detaljer finns under Ta bort skadlig kod och webshells.
- Härda och rapportera: Ni får en dokumentation med tidslinje, fynd och rekommendationer. Når incidenten utanför en server går vi över till strukturerad incidenthantering.
Det här bör ni inte göra
I stressen uppstår fel som går att undvika. Radera inga ”misstänkta” filer på misstanke utan att först ha säkrat dem. Kör inga kommandon från forum som ni inte förstår. Och installera inga säkerhetsplugin på en server som kanske redan är komprometterad: Skadlig kod kan lura skannrar, och resultatet vaggar er in i falsk trygghet. Var också försiktiga med tips om att blockera alla förfrågningar med ett visst sessions-ID; fackskribenter avvisar uttryckligen sådana råd om PHP2Shell. Er egen version kan ni kontrollera på ett säkert sätt med php -v och en titt i er distributions paketchangelog, eftersom backports ofta låter versionsnumret vara oförändrat.
Det här bör ni skicka till oss
- en kort beskrivning: vad har uppmärksammats, sedan när, vad ändrades senast
- typen av system: egen server, vServer, managed server eller webbhotellspaket
- åtkomst via SSH eller panel eller tillstånd att tala med ert webbhotell
- uppgifter om befintliga säkerhetskopior och hur gamla de är
- varningsmeddelanden från webbhotell, webbläsare eller kunder i ordagrann lydelse
Saknas något av detta, hör av er ändå. Luckorna stänger vi i samtalet.
Varför PHP SOS
Vi arbetar Made in Germany och är sedan över 25 år, tillsammans med vårt partnernätverk av cyberproffs, specialiserade på IT-säkerhet. Ni har en kontaktperson, och vi arbetar på distans, utan resor, i hela Europa. Varje steg dokumenteras, och vi skiljer öppet mellan belagt, sannolikt och okänt. Löften som ingen kan hålla ger vi inte. En översikt över efterarbetet finns i checklistan efter en hackning, hela nödhjälpen under Webbplats hackad? Nödhjälp på distans. Om anmälningsskyldighet vid personuppgiftsincidenter, läs 72-timmarsregeln; den juridiska bedömningen ligger kvar hos dataskyddsombud och jurister.
Berörs ni? Ring oss. Vi hjälper er.
Vänta inte tills misstanken blir en större skada. Vi tar över från första meddelandet och är med tills incidenten är avslutad och dokumenterad. Anmäl nödläge nu.
Vanliga frågor
Server hackad: ska jag stänga av den direkt?
Inte förhastat. En avstängning kan förstöra flyktiga spår i arbetsminnet. Bättre är att koppla bort servern från nätet eller skärma av den med brandväggen och säkra den först. Är ni osäkra, hör av er till oss innan dess.
Hur tar jag reda på om min server verkligen har hackats?
Ledtrådar ges av processer som webbservern startar, nya PHP-filer i uppladdnings- eller cachemappar, okända cronjobb och SSH-nycklar samt ovanliga utgående förbindelser. Säkerhet får ni först genom en analys av loggar och filer. Det finns inga bekräftade PHP2Shell-indikatorer; upptäckten bygger på beteendeanalys.
Räcker en PHP-uppdatering om servern redan har hackats?
Nej. En patch stänger ingången men tar inte bort skadlig programvara som redan förts in, och den bevisar inte att inget hände tidigare. Efter uppdateringen måste dessutom alla PHP-processer startas om.
Måste jag anmäla en hackad server?
Om personuppgifter kan ha påverkats kan en anmälan till tillsynsmyndigheten inom 72 timmar vara nödvändig. Bedömningen gör ert dataskyddsombud eller er jurist; vi levererar de tekniska fakta till det.
Kan jag rensa den hackade servern själv?
På små system är det möjligt men riskabelt: Den som bara tar bort synliga filer missar ofta bakdörrar, cronjobb eller åtkomster. Vi bedömer om en rensning räcker eller om en ny uppbyggnad från rena källor är mer ändamålsenlig.