Är jag redan komprometterad? Tecken efter PHP2Shell

Kort sagt: Om en server har hackats via PHP2Shell går inte att utläsa av ett enskilt kännetecken. Det finns inga publicerade, bekräftade Indicators of Compromise; upptäckten bygger på beteendeanalys. Typiska tecken är nya PHP-filer, okända cronjobb och ovanliga förbindelser. Säkra först loggarna från och med den 20 oktober innan ni ändrar något.

Finns det entydiga tecken på ett PHP2Shell-angrepp?

Nej, och det är det ärliga svaret. För många kända sårbarheter publicerar tillverkare eller säkerhetsföretag konkreta spår: filnamn, kontrollsummor, IP-adresser. För PHP2Shell finns sådana bekräftade Indicators of Compromise hittills inte.

Det som är känt: Enligt mediarapporter observerades ett första angreppsförsök den 17 oktober, fyra dagar före patcharna den 21 oktober. Cloudflare rapporterade ytterligare försök. Bekräftade lyckade angrepp i bredd var enligt BSI (Tysklands federala myndighet för informationssäkerhet) till en början inte kända. Den som mellan den 17 oktober och sin egen patch var nåbar utan skydd bör därför kontrollera i stället för att hoppas.

För bedömningen räknas framför allt tidsperioden. Mellan det första observerade angreppsförsöket den 17 oktober och patcharna den 21 oktober fanns ingen officiell uppdatering. Varje offentligt nåbar PHP-server var under den tiden potentiellt angripbar. Hur länge er server dessutom var öppen beror på när uppdateringen installerades och PHP startades om. Ju längre denna period och ju känsligare data, till exempel kundkonton, beställningar eller ansökningar, desto grundligare bör kontrollen vara.

Typiska tecken på att en server har hackats

Efter en lyckad kodkörning försöker angripare oftast få fäste och använda servern. Därav följer tecken som inte är specifika för PHP2Shell men som räknas vid varje intrångskontroll:

• Nya eller ändrade PHP-filer, särskilt i uppladdnings-, cache- eller bildkataloger där det annars inte ligger några PHP-filer.
• Okända cronjobb eller schemalagda uppgifter, till exempel för webbserveranvändaren.
• Ovanliga utgående förbindelser till okända adresser, hög nätverksbelastning eller e-postutskick som ingen har startat.
• Nya adminkonton i CMS eller butik, ändrade lösenord, okända SSH-nycklar.
• Avvikande belastning: ihållande hög CPU-användning av okända processer, ofta ett tecken på kryptomining.
• Synliga följder: omdirigeringar till främmande sidor, spamsidor i Googles index, varningar i webbläsaren eller i Search Console.

Inget av dessa tecken bevisar ett intrång i sig, och deras frånvaro bevisar inte motsatsen. Avgörande är helhetsbilden.

Första kontroller utan att förstöra spår

Innan ni raderar eller startar om något: Säkra loggarna. Facktidningarna rekommenderar att spara serverloggar från och med den 20 oktober. Kopiera webbserver-, PHP- och systemloggar till en säker plats utanför servern.

Därefter hjälper rent läsande kontroller. Sökvägar och användarnamn skiljer sig mellan system:

# PHP-filer som har ändrats sedan den 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls

# PHP-filer i uppladdningskataloger (exempel WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls

# cronjobb för webbserveranvändaren och systemomfattande
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null

# aktiva nätverksförbindelser med process
ss -tunp

# senaste inloggningar
last -n 30

Observera: Angripare kan förfalska filers tidsstämplar. Ett oansenligt resultat av find är därför ingen friskrivning. Hur ni analyserar loggar riktat beskriver Analysera webbserverloggar efter ett angrepp; hur ni hittar bakdörrar Känn igen och ta bort webshells.

Vad ni inte bör göra

• Bara patcha och gå vidare. En patch tar inte bort skadlig programvara som redan förts in.
• Genast radera misstänkta filer. Därmed försvinner belägg för vad som hände och vilka data som kan vara berörda.
• Installera om servern innan något är säkrat. Orsaken förblir oklar, och en bakdörr i databasen eller inloggningsuppgifterna överlever nyinstallationen.
• Återställa gamla säkerhetskopior okontrollerat. Även en säkerhetskopia kan redan innehålla bakdörren.
• Glömma inloggningsuppgifter. Efter en kodkörning kan databaslösenord, API-nycklar och andra inloggningsuppgifter ha läckt ur konfigurationsfiler. Förnya dem efter rensningen, inte före, så att en fortfarande aktiv angripare inte genast läser med de nya.

Om misstanken bekräftas

Då handlar det om mer än teknik. Pröva med ert dataskyddsombud om en anmälan enligt GDPR behövs; fristen är 72 timmar från kännedom, detaljer under anmälningsskyldighet enligt GDPR. Informera tidigt er cyberförsäkringsgivare, om ni har en, och klarlägg med en jurist om en polisanmälan ska göras. Vi ger allmänna anvisningar om det, ingen juridisk rådgivning.

Hur hjälper PHP SOS konkret?

Med vår incident response arbetar vi igenom en misstanke strukturerat:

• Säkra: Loggar från och med den 20 oktober och, där det behövs, en avbild av systemet innan något ändras.
• Undersöka: Beteendeanalys av filer, processer, förbindelser och konton; vid behov med bevisvärde i domstol genom IT-forensik.
• Rensa och stänga: Ta bort bakdörrar, uppdatera PHP, förnya inloggningsuppgifter, härda servern.
• Dokumentera, tills incidenten är avslutad och dokumenterad, som underlag för dataskydd, försäkring och ledning.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• BSI: Tysklands federala myndighet för informationssäkerhet
• GDPR art. 33: anmälan till tillsynsmyndigheten
• OWASP Cheat Sheets