Kort sagt: Om en server er blevet hacket via PHP2Shell, kan ikke aflæses af ét enkelt kendetegn. Der findes ingen offentliggjorte, bekræftede Indicators of Compromise; opdagelsen bygger på adfærdsanalyse. Typiske tegn er nye PHP-filer, ukendte cronjobs og usædvanlige forbindelser. Sikr først logs fra og med 20. oktober, før I ændrer noget.
Findes der entydige tegn på et PHP2Shell-angreb?
Nej, og det er det ærlige svar. Til mange kendte sårbarheder offentliggør producenter eller sikkerhedsfirmaer konkrete spor: filnavne, kontrolsummer, IP-adresser. Til PHP2Shell findes sådanne bekræftede Indicators of Compromise endnu ikke.
Hvad der er kendt: Ifølge mediernes rapporter blev et første angrebsforsøg observeret den 17. oktober, fire dage før rettelserne fra 21. oktober. Cloudflare meldte om yderligere forsøg. Bekræftede vellykkede angreb i bredden var ifølge BSI først ikke kendt. Den, der mellem 17. oktober og sin egen rettelse var tilgængelig uden beskyttelse, bør derfor kontrollere i stedet for at håbe.
For vurderingen tæller frem for alt tidsrummet. Mellem det første observerede angrebsforsøg den 17. oktober og rettelserne den 21. oktober fandtes der ingen officiel opdatering. Hver offentligt tilgængelig PHP-server var i denne tid potentielt angribelig. Hvor længe jeres server derudover var åben, afhænger af, hvornår opdateringen blev indspillet og PHP genstartet. Jo længere dette tidsrum og jo mere følsomme dataene er, f.eks. kundekonti, bestillinger eller ansøgninger, desto grundigere bør kontrollen være.
Typiske tegn på, at en server er blevet hacket
Efter en vellykket kodeudførelse forsøger angribere som regel at fæstne sig og bruge serveren. Heraf opstår tegn, der ikke er specifikke for PHP2Shell, men tæller ved enhver indbrudskontrol:
- Nye eller ændrede PHP-filer, især i upload-, cache- eller billedmapper, hvor der ellers ikke ligger PHP-filer.
- Ukendte cronjobs eller planlagte opgaver, f.eks. for webserverbrugeren.
- Usædvanlige udgående forbindelser til ukendte adresser, høj netværksbelastning eller mailudsendelse, som ingen har sat i gang.
- Nye administratorkonti i CMS eller webshop, ændrede adgangskoder, ukendte SSH-nøgler.
- Påfaldende belastning: vedvarende høj CPU-udnyttelse fra ukendte processer, ofte et tegn på kryptomining.
- Synlige følger: omdirigeringer til fremmede sider, spamsider i Googles indeks, advarsler i browseren eller i Search Console.
Ingen af disse tegn beviser i sig selv et indbrud, og deres fravær beviser ikke det modsatte. Afgørende er helhedsbilledet.
Første kontroller uden at ødelægge spor
Før I sletter eller genstarter noget: Sikr logs. Fagpressen anbefaler at gemme serverlogs fra og med 20. oktober. Kopiér webserver-, PHP- og systemlogs til et sikkert sted uden for serveren.
Derefter hjælper rent læsende kontroller. Stier og brugernavne afviger fra system til system:
# PHP-filer, som er ændret siden 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP-filer i upload-mapper (eksempel WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cronjobs for webserverbrugeren og systemomfattende
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktive netværksforbindelser med proces
ss -tunp
# seneste logins
last -n 30
Bemærk: Angribere kan forfalske filers tidsstempler. Et upåfaldende resultat af find er derfor ingen frikendelse. Hvordan I analyserer logs målrettet, beskriver Analysér webserverlogs efter et angreb; hvordan I finder bagdøre, Genkend og fjern webshells.
Finder I konkrete holdepunkter, f.eks. en ukendt PHP-fil i upload-mappen: Slet ikke, sæt ikke op påny, og »reparér« ikke applikationen hurtigt. Adskil eller isolér serveren fra nettet, sikr logs og systemaftryk, og begynd en struktureret hændelseshåndtering.
Hvad I ikke bør gøre
- Kun rette og køre videre. En rettelse fjerner ikke skadelig software, der allerede er indsmuglet.
- Straks slette mistænkelige filer. Dermed forsvinder beviserne for, hvad der er sket, og hvilke data der kan være berørt.
- Sætte serveren op påny, før der er sikret. Årsagen forbliver uklar, og en bagdør i databasen eller i adgangsdata overlever nyinstallationen.
- Indspille gamle backups uden kontrol. Også en backup kan allerede indeholde bagdøren.
- Glemme adgangsdata. Efter en kodeudførelse kan databaseadgangskoder, API-nøgler og andre adgangsdata være sluppet ud fra konfigurationsfiler. Forny dem efter oprydningen, ikke før, så en stadig aktiv angriber ikke straks læser de nye med.
Hvis mistanken bekræftes
Så handler det om mere end teknik. Undersøg sammen med jeres databeskyttelsesrådgiver, om en anmeldelse efter GDPR er nødvendig; fristen er 72 timer fra kendskab, detaljer under GDPR-anmeldelsespligt. Underret tidligt jeres cyberforsikringsselskab, hvis I har et, og afklar med en advokat, om der skal indgives politianmeldelse. Vi giver hertil almindelige henvisninger, ikke juridisk rådgivning.
Hvordan hjælper PHP SOS konkret?
Med vores incident response afvikler vi en mistanke struktureret:
- Sikre: logs fra og med 20. oktober og, hvor nødvendigt, et aftryk af systemet, før noget ændres.
- Undersøge: adfærdsanalyse af filer, processer, forbindelser og konti; om nødvendigt bevismæssigt holdbart med it-forensik.
- Rense og lukke: fjerne bagdøre, opdatere PHP, forny adgangsdata, hærde serveren.
- Dokumentere, indtil hændelsen er afsluttet og dokumenteret, som grundlag for databeskyttelse, forsikring og direktion.
Ofte stillede spørgsmål
Beviser PHP-opdateringen, at min server er ren?
Nej. En rettelse lukker sårbarheden for fremtiden, men fjerner ikke skadelig software, der allerede er indsmuglet. Den siger heller intet om, hvorvidt nogen var trængt ind før rettelsen.
Findes der en scanner, der sikkert opdager PHP2Shell-angreb?
Hidtil ikke. Der findes ingen offentliggjorte, bekræftede Indicators of Compromise, som en scanner målrettet kunne lede efter. Malware-scannere finder kendte webshells, men vurderingen af en server bygger på adfærdsanalyse.
Skal jeg anmelde en mistanke til databeskyttelsesmyndigheden?
Det afhænger af, om personoplysninger kan være berørt. GDPR fastsætter for anmeldelsespligtige brud på datasikkerheden en frist på 72 timer fra kendskab. Afklar det tidligt med jeres databeskyttelsesrådgiver eller en advokat; vi giver ingen juridisk rådgivning herom.
Skal jeg bare sætte den hackede server op påny?
Ikke som første skridt. Sikr først logs og, hvis muligt, et aftryk af systemet. Den, der straks sætter op påny, mister de spor, der viser, hvad der er sket, og hvilke data der kan være berørt.