Analysér weblogs efter et angreb: læs access-loggen rigtigt

Kort sagt: Den, der vil analysere access-loggen efter et angreb, sikrer logs først uændret og arbejder derefter kun med kopier. Der søges efter forespørgsler med status 200 til ukendte PHP-filer, påfaldende POST-forespørgsler, adgange til upload-mapper og tidsmæssige mønstre. Til PHP2Shell findes der ingen offentliggjorte, bekræftede Indicators of Compromise, derfor tæller det samlede billede fra flere logkilder.

Først sikre, derefter analysere

Logfiler roteres på de fleste servere automatisk og slettes efter en fast tid. Efter et angreb er det første skridt derfor at sikre de eksisterende logs, før de forsvinder. Det gælder også, hvis I endnu ikke er sikre på, om der overhovedet er sket noget. Til PHP2Shell anbefaler fagpressen at gemme logs fra den 20.10.2026.

# Kopiér logs med tidsstempler, og notér kontrolsummer
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Læg desuden sikkerhedskopien på et andet system. En angriber med adgang til serveren kunne ellers ændre logs bagefter. Kontrolsummerne viser senere, at kopien er uændret. Er en retssikker sikring nødvendig, f.eks. til en anmeldelse eller forsikringen, bør en IT-forensik overtage sikringen.

Hvor logs ligger, og hvordan en linje er opbygget

Lagringsstederne afhænger af distribution og administrationsflade. Typiske stier:

I det udbredte Combined-format indeholder hver linje klientadressen, dato og klokkeslæt, forespørgslens metode og sti, statuskoden, svarstørrelsen i bytes, referer og user agent. Vær opmærksom på tidszonen i tidsstemplet, især hvis I sammenholder logs med meddelelser i UTC. PHP2Shell-rettelserne blev f.eks. offentliggjort den 21.10.2026 kl. 14:00 UTC, altså kl. 16 tysk tid.

Ligger jeres website bag en proxy, CDN eller load balancer, står der i loggen måske kun dennes adresse. Den rigtige besøgsadresse findes så i et eget felt eller i logs fra den foranliggende tjeneste.

Uden kommandolinje: logs i panelet eller hos hosteren

Ikke enhver driftsansvarlig har shell-adgang. Ved shared hosting eller administrerede servere tilbyder administrationsfladerne som regel en logvisning og en download af access- og error-logs. Hent filerne ned for hele det tilgængelige tidsrum, og opbevar dem sikkert. Spørg skriftligt jeres hoster, hvor længe logs opbevares, og om ældre status kan sikres, før de udløber.

Vær her opmærksom på databeskyttelsen: Logs indeholder IP-adresser og ofte yderligere personoplysninger. Gem kopierne adgangsbeskyttet, giv dem kun videre til personer, der har brug for dem til opklaringen, og fastlæg, hvornår de slettes efter afslutningen af hændelsen.

Analysér access-loggen: de vigtigste forespørgsler

De følgende kommandoer læser kun og egner sig til Nginx og Apache i Combined-format. Roterede og komprimerede filer gennemsøger I med zgrep eller zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Vellykkede forespørgsler til PHP-filer, efter hyppighed
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-kald i upload-, cache- eller billedmapper
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-forespørgsler efter mål og adresse
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Fejl 5xx pr. time: ophobninger kan pege på PHP-processer, der styrter ned
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Medtag roterede logs
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Ved den første forespørgsel interesserer især filnavne, som I ikke kender, eller som ikke hører til applikationen. Sammenhold mistænkelige filer med filsystemet: Hvornår blev de oprettet, hvem ejer dem, hvad står der i dem? Henvisninger giver vejledningen Opdag og fjern webshells.

Særligheder ved PHP2Shell

Ved PHP2Shell ligger sårbarhederne i PHP's egen behandling af forespørgsler. Ved mod_php blev en exploit vist, før der overhovedet kører applikationskode. Det vil sige: En forespørgsel til en helt almindelig side kan være nok. I access-loggen ser sådan en forespørgsel måske upåfaldende ud, fordi forespørgselslegemets indhold ikke står der.

Der findes ingen offentliggjorte, bekræftede Indicators of Compromise. Vær derfor opmærksom på adfærd og sammenhænge, f.eks. fra og med 17.10.2026, det ifølge medierapporter første observerede angrebsforsøg:

• Ophobninger af 500-fejl eller afbrudte svar på almindelige sider.
• Meddelelser om opbrugt hukommelse eller afsluttede workere i error- og PHP-FPM-loggen.
• Nye PHP-filer eller ændrede filer kort efter sådanne ophobninger.
• Nye cronjobs, processer eller udgående forbindelser under webserverens bruger.

Intet af disse signaler er alene et bevis. Sammen med andre spor giver de dog et billede, der besvarer spørgsmålet om en kompromittering eller begrunder en dybere undersøgelse. Et overblik over tegnene finder I under Er jeg allerede kompromitteret?.

Yderligere kilder: error-log, PHP-FPM og systemlogs

Access-loggen viser kun en del. Til et fuldstændigt billede inddrager I flere kilder:

# PHP-FPM og webserver i journalen fra en dato
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Logins på serveren
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Kontrollér planlagte opgaver for alle brugere
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Typiske fejl ved analysen er kun at gennemsøge den aktuelle i stedet for også de roterede logs, at overse tidszonen og at tage enkelte fund fra automatiserede scannere for et vellykket angreb. Lige så risikabelt er det modsatte: at vurdere en upåfaldende access-log som afblæsning, selv om error-log og filsystem endnu ikke er kontrolleret.

Notér hvert fund med klokkeslæt, kilde og observation i en tidslinje. Denne tidslinje er senere grundlaget for beslutninger, for meddelelser til myndigheder eller forsikringsselskaber og for slutrapporten.

Hvordan hjælper PHP SOS konkret?

• Vi sikrer logs og relevante filer, så de forbliver sporbare ved senere kontroller.
• Vi analyserer access-, error-, PHP- og systemlogs samlet og opretter en tidslinje over hændelsen.
• Ved tegn på en kompromittering overtager vi Incident Response med inddæmning og oprydning.
• Vi indretter logrotation og opbevaring, så de nødvendige data er til stede ved næste hændelse.

Ofte stillede spørgsmål

Kilder

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: Sikkerhedsmeddelelser
• BSI IT-Grundschutz (det tyske forbundskontors grundbeskyttelse for IT)