Webserverlogs na een aanval analyseren: het toegangslog goed lezen

Kort gezegd: Wie het toegangslog na een aanval wil analyseren, zet de logs eerst ongewijzigd veilig en werkt daarna alleen met kopieën. Gezocht wordt naar verzoeken met status 200 op onbekende PHP-bestanden, opvallende POST-verzoeken, toegang tot uploadmappen en tijdspatronen. Voor PHP2Shell zijn er geen gepubliceerde, bevestigde Indicators of Compromise; daarom telt het totaalbeeld uit meerdere logbronnen.

Eerst veiligstellen, dan analyseren

Logbestanden worden op de meeste servers automatisch geroteerd en na een vaste tijd verwijderd. Na een aanval is de eerste stap daarom de bestaande logs veilig te stellen voordat ze verdwijnen. Dat geldt ook als u nog niet zeker weet of er wel iets is gebeurd. Voor PHP2Shell adviseert de vakpers logs te bewaren vanaf 20-10-2026.

# Logs met tijdstempels kopiëren en controlesommen vastleggen
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"

Zet de back-up bovendien op een ander systeem neer. Een aanvaller met toegang tot de server zou logs anders achteraf kunnen wijzigen. De controlesommen tonen later dat de kopie ongewijzigd is. Is een gerechtelijk bruikbare back-up nodig, bijvoorbeeld voor een aangifte of de verzekering, dan moet een IT-forensica-onderzoek de back-up verzorgen.

Waar de logs staan en hoe een regel is opgebouwd

De opslagplaatsen hangen af van distributie en beheeromgeving. Typische paden:

In het gangbare combined-formaat bevat elke regel het clientadres, datum en tijd, methode en pad van het verzoek, de statuscode, de antwoordgrootte in bytes, de referer en de user-agent. Let op de tijdzone in de tijdstempel, vooral als u logs vergelijkt met meldingen in UTC. De PHP2Shell-patches werden bijvoorbeeld op 21-10-2026 om 14:00 UTC gepubliceerd, dus om 16:00 uur Duitse tijd.

Staat uw website achter een proxy, CDN of load balancer, dan staat in het log mogelijk alleen diens adres. Het echte bezoekersadres vindt u dan in een eigen veld of in de logs van de voorgeschakelde dienst.

Zonder opdrachtregel: logs in het paneel of bij de hoster

Niet elke exploitant heeft shelltoegang. Bij shared hosting of beheerde servers bieden beheeromgevingen meestal een logweergave en een download van de toegangs- en foutlogs. Download de bestanden voor de hele beschikbare periode en bewaar ze veilig. Vraag uw hoster schriftelijk hoe lang logs worden bewaard en of oudere standen kunnen worden veiliggesteld voordat ze verlopen.

Houd daarbij rekening met gegevensbescherming: logs bevatten IP-adressen en vaak verdere persoonsgegevens. Sla de kopieën met toegangsbeveiliging op, geef ze alleen door aan personen die ze voor de opheldering nodig hebben en bepaal wanneer ze na afsluiting van het incident worden gewist.

Toegangslog analyseren: de belangrijkste zoekopdrachten

De volgende opdrachten lezen alleen en zijn geschikt voor Nginx en Apache in combined-formaat. Geroteerde en gecomprimeerde bestanden doorzoekt u met zgrep of zcat.

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

# Geslaagde verzoeken op PHP-bestanden, naar frequentie
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-aanroepen in upload-, cache- of afbeeldingsmappen
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-verzoeken naar doel en adres
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Fouten 5xx per uur: opeenhopingen kunnen wijzen op crashende PHP-processen
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

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

Bij de eerste zoekopdracht zijn vooral bestandsnamen interessant die u niet kent of die niet bij de toepassing horen. Vergelijk verdachte bestanden met het bestandssysteem: wanneer zijn ze aangemaakt, van wie zijn ze, wat staat erin? Aanwijzingen daarvoor geeft de gids Webshells herkennen en verwijderen.

Bijzonderheden bij PHP2Shell

Bij PHP2Shell zitten de kwetsbaarheden in de verwerking van aanvragen door PHP zelf. Bij mod_php werd een exploit getoond voordat er zelfs maar toepassingscode draait. Dat betekent: een verzoek op een volkomen normale pagina kan volstaan. In het toegangslog ziet zo'n verzoek er mogelijk onopvallend uit, omdat de inhoud van de aanvraagbody daar niet in staat.

Er zijn geen gepubliceerde, bevestigde Indicators of Compromise. Let daarom op gedrag en samenhang, bijvoorbeeld vanaf 17-10-2026, de volgens mediaberichten eerste waargenomen aanvalspoging:

• Opeenhopingen van fouten 500 of afgebroken antwoorden op gewone pagina's.
• Meldingen over uitgeput geheugen of beëindigde workers in het fout- en PHP-FPM-log.
• Nieuwe PHP-bestanden of gewijzigde bestanden kort na zulke opeenhopingen.
• Nieuwe cronjobs, processen of uitgaande verbindingen onder de gebruiker van de webserver.

Geen van deze signalen is op zichzelf een bewijs. Samen met andere sporen vormen ze echter een beeld dat de vraag naar een compromittering beantwoordt of een diepgaander onderzoek rechtvaardigt. Een overzicht van de tekenen vindt u onder Ben ik al gecompromitteerd?.

Verdere bronnen: foutlog, PHP-FPM en systeemlogs

Het toegangslog toont maar een deel. Voor een compleet beeld betrekt u verdere bronnen:

# PHP-FPM en webserver in het journal vanaf een datum
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Aanmeldingen op de server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Geplande taken van alle gebruikers controleren
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Typische fouten bij de analyse zijn: alleen het actuele log doorzoeken in plaats van ook de geroteerde, de tijdzone over het hoofd zien en afzonderlijke treffers van geautomatiseerde scanners voor een geslaagde aanval aanzien. Even riskant is het omgekeerde: een onopvallend toegangslog als geruststelling beschouwen terwijl foutlog en bestandssysteem nog niet zijn gecontroleerd.

Noteer elke vondst met tijdstip, bron en waarneming in een tijdlijn. Die tijdlijn is later de basis voor beslissingen, voor meldingen aan autoriteiten of verzekeraars en voor het eindrapport.

Hoe helpt PHP SOS concreet?

• We stellen logs en relevante bestanden zo veilig dat ze voor latere controles traceerbaar blijven.
• We analyseren toegangs-, fout-, PHP- en systeemlogs gezamenlijk en maken een tijdlijn van het incident.
• Bij aanwijzingen voor een compromittering nemen we de incident response over met indamming en opruiming.
• We richten logrotatie en bewaartermijnen zo in dat bij het volgende incident de benodigde gegevens aanwezig zijn.

Veelgestelde vragen

Bronnen

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: beveiligingsmeldingen
• BSI IT-Grundschutz (basisbeveiliging van de Duitse federale dienst voor informatiebeveiliging)