Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

Opdag og fjern webshell

Sådan opsporer I bagdøre på PHP-webservere uden at ødelægge spor, og hvorfor sletning alene sjældent er nok.

Status 5 min. læsetidVejledninger

Kort sagt: En webshell opdager I på nye eller ændrede PHP-filer på utypiske steder, på fremmede processer under webserverens bruger og på usædvanlige forbindelser. Sikr spor, før I sletter noget, og gendan koden fra en ren kilde. En patch alene fjerner ikke en bagdør.

Hvorfor webshells er et emne efter PHP2Shell

Sårbarhederne CVE-2026-109618 og CVE-2026-109619 i selve PHP muliggør kørsel af skadelig kode på afstand uden login. Et nærliggende mål efter et vellykket angreb er en varig bagdør, altså en webshell. Den består, selv om PHP i mellemtiden er opdateret.

Ifølge medierapporter blev et første angrebsforsøg observeret allerede den 17.10.2026, rettelserne fulgte den 21.10. Den, der var sårbar i dette tidsrum, bør se målrettet efter. Bekræftede Indicators of Compromise er hidtil ikke offentliggjort. Søgningen bygger derfor på påfaldende adfærd, ikke på en færdig liste.

Handl med det samme

Hvis I finder en webshell på en server med kundedata: slet ikke noget i forhastelse. Sikr først beviser, isolér derefter serveren og planlæg den videre behandling.

Sådan opdager I en webshell: kontrollér filer

De fleste webshells er PHP-filer i webmappen. Påfaldende er filer, der er opstået eller ændret efter 17.10., PHP-filer i upload- og cachemapper samt filer med tilsløret kode. De følgende kommandoer ændrer intet, de lister kun op:

# PHP-filer, der er ændret siden 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls

# PHP-filer i upload-, cache- eller tmp-mapper
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls

# Typisk tilsløring: eval i kombination med afkodning
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"

# Usædvanligt lange linjer tyder ofte på pakket kode
grep -rlE ".{3000,}" /var/www --include="*.php"

Fund er indikationer, ikke beviser. Nogle plugins bruger legitimt kodet kode. Sammenlign mistænkelige filer med producentens originalpakke. Mest pålideligt er en sammenligning med kontrolsummer eller et versionsstyringssystem som Git:

# Afvigelser fra den sidst kendte status i Git-repositoriet
git -C /var/www/projekt status --porcelain

Et tidsstempel kan være forfalsket. Stol derfor ikke alene på en fils ændringsdato.

Hvilke kendetegn gør en fil mistænkelig

Kendetegn Hvorfor det er påfaldende
PHP-fil i en upload- eller billedmappe Dér bør kun ligge medier
Dobbelt endelse som .jpg.php eller .php.png Camouflage som harmløs fil
Meget lange linjer uden linjeskift Typisk for pakket eller krypteret kode
Filnavn, der ligner en kernefil, men ikke findes i originalpakken Camouflage i det kendte miljø
Ejer eller rettigheder afviger fra nabofilerne Filen er oprettet ad anden vej

Jo flere kendetegn der kommer sammen, desto større er sandsynligheden for et fund. Åbn mistænkelige filer kun som tekst, aldrig via browseren, for et kald via websitet ville køre koden.

Kontrollér processer, forbindelser og cronjobs

En aktiv webshell efterlader ofte spor uden for filsystemet. Webserverens bruger, f.eks. www-data, apache eller nginx, starter normalt ikke shells, netværksværktøjer eller kompilatorer.

# Processer under de typiske webserver-brugere
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"

# Åbne netværksforbindelser med tilhørende proces
sudo ss -tunap | grep -E "php|www-data|apache|nginx"

# Planlagte opgaver for webserverens bruger
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null

Påfaldende er vedvarende udgående forbindelser til ukendte mål, processer med kryptiske navne og cronjobs, der henter filer fra internettet. Kontrollér desuden adgangslogs for forespørgsler til filer, der ikke fandtes før. Hvordan det gøres, beskriver vejledningen Analysér weblogs efter et angreb.

Sikr spor, før I fjerner

Den, der sletter først, mister svaret på de vigtigste spørgsmål: Hvordan kom angriberen ind, hvad har vedkommende set, hvilke data er berørt? Disse svar har I brug for til en mulig GDPR-anmeldelse, til forsikringsselskaber og til afgørelsen af, om flere systemer er truet.

Fornuftig rækkefølge:

  1. Dokumentér tilstanden: procesliste, netværksforbindelser, tilmeldte brugere.
  2. Kopiér mistænkelige filer og logs med kontrolsum, uden at åbne eller køre dem.
  3. Opret om muligt et aftryk af systemet eller et snapshot af den virtuelle maskine.
  4. Tag serveren af nettet, eller begræns adgangen kraftigt.

Ved systemer med følsomme data eller mulig retstvist bør sikringen ske forensisk korrekt. Baggrund finder I under IT-forensik efter et webserverangreb.

Fjern webshells korrekt

Sletning af en enkelt fil er sjældent enden. Angribere opretter ofte flere adgange: flere filer på skjulte steder, poster i konfigurationsfiler som .htaccess eller .user.ini, nye admin-konti i applikationen eller cronjobs. En pålidelig oprydning følger disse trin:

  • Bring PHP til en rettet status (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller bekræftet backport), og genstart alle PHP-processer.
  • Opsæt applikationskoden på ny fra en ren kilde i stedet for at reparere enkelte filer.
  • Overtag kun kontrolleret indhold som uploads og database, og søg dér målrettet efter indsmuglet kode.
  • Skift alle adgangsdata: database, SSH, FTP, admin-konti, API-nøgler.
  • Begræns webserverens skriverettigheder til det nødvendige, og forhindr PHP-kørsel i upload-mapper.

For WordPress findes der egne typiske skjulesteder, som vejledningen Find bagdøre i WordPress beskriver. Derefter bør websitet overvåges tættere et stykke tid for tidligt at opdage en fornyet adgang.

Hvordan hjælper PHP SOS konkret?

  • Vi sikrer logs, filer og systemtilstand sporbart, før noget ændres.
  • Vi søger efter bagdøre i filer, database, cronjobs og konfiguration og vurderer fundene.
  • Vi opsætter applikationen på ny fra ren kilde, skifter adgange og hærder serveren.
  • Vi dokumenterer hændelsen, indtil den er afsluttet, som grundlag for anmeldelser og forsikringsselskaber.

Forløbet af en oprydning beskriver ydelsen Lad malware og webshells fjerne.

Ofte stillede spørgsmål

Hvad er en webshell?

En webshell er en indsmuglet fil, oftest PHP, hvormed angribere kan styre serveren på afstand. Den camouflerer sig ofte som en harmløs fil med et upåfaldende navn og forbliver aktiv, selv efter en opdatering.

Finder en virusscanner enhver webshell?

Nej. Scannere genkender kendte mønstre, nye eller stærkt tilslørede varianter slipper igennem. Til PHP2Shell findes der desuden ingen offentliggjorte, bekræftede Indicators of Compromise, derfor er adfærdsanalyse vigtigere end en signaturliste.

Er det nok at slette den fundne fil?

Som regel ikke. Angribere opretter ofte flere adgange, f.eks. flere filer, cronjobs eller nye admin-konti. Uden årsagsanalyse og skift af alle adgangsdata er en fornyet adgang sandsynlig.

Skal jeg indberette noget, hvis jeg finder en webshell?

Hvis personoplysninger kan være berørt, kan der bestå en anmeldelsespligt efter GDPR, som regel inden for 72 timer. Afklar det med jeres databeskyttelsesansvarlige eller en advokat; dette er ikke juridisk rådgivning.

Kilder

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp