PHP-bestanden in de uploadmap: vindplaatsen juist duiden

Kort gezegd: Een PHP-bestand in de uploadmap is een ernstig waarschuwingssignaal, want daar horen alleen afbeeldingen en documenten te staan. Open het bestand nooit in de browser, maar lees het als tekst, controleer tijdstempel en eigenaar en zoek de bestandsnaam in de toegangslogs. Onschuldig zijn meestal alleen lege plaatshouders zoals een index.php zonder inhoud; al het andere behandelt u als mogelijke inbraak.

Waarom PHP in de uploadmap niets te zoeken heeft

Uploadmappen zijn bedoeld voor inhoud die bezoekers of redacteuren uploaden: afbeeldingen, pdf's, video's. De webservergebruiker mag daar schrijven, anders werken uploads niet. Juist dat maakt deze mappen aantrekkelijk voor aanvallers. Wie via een lek bestanden kan schrijven, plaatst ze waar schrijven is toegestaan.

Nieuwe PHP-bestanden in upload- of cachemappen behoren volgens de ons beschikbare berichten tot de algemene waarschuwingssignalen na een inbraak. Voor PHP2Shell bestaan geen bevestigde Indicators of Compromise; een vondst zegt dus niets over via welk lek het bestand kwam. Hoe uploadfuncties veilig worden gebouwd, beschrijft Bestandsuploads in PHP veilig implementeren.

Of zo'n bestand schade kan aanrichten, bepaalt de configuratie van de webserver. Voert hij PHP-bestanden in de uploadmap uit, dan wordt elk daar geplaatst bestand een mogelijke afstandsbediening. Is de uitvoering daar geblokkeerd, dan blijft het bestand een vreemd element, maar aanvankelijk zonder werking. Veel installaties hebben deze blokkade nooit ingesteld.

Hoe komt een PHP-bestand in de uploadmap?

Voor de beoordeling helpt het de mogelijke wegen te kennen. Elke leidt tot andere vervolgvragen.

Meerdere wegen kunnen samenkomen. Een aanvaller die via een lek code uitvoert, plaatst het bestand misschien alleen om later gemakkelijker terug te keren.

Vindplaatsen systematisch opsommen

Voordat u een afzonderlijk bestand beoordeelt, verschaft u zich een overzicht. De opdrachten lezen alleen. Paden zijn voorbeelden voor WordPress; bij andere systemen past u het uploadpad aan.

# PHP-achtige bestanden in de uploadmap met grootte, eigenaar, mtime en ctime
find /var/www/html/wp-content/uploads -type f \
  \( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
  -printf '%s Bytes  %u  m:%T+  c:%C+  %p\n'

# Bestandstype bepalen op basis van inhoud in plaats van extensie (afbeeldingen met PHP-inhoud vallen op)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"

Andere systemen gebruiken andere schrijfmappen, zoals fileadmin bij TYPO3, images bij Joomla of de mediamap onder public bij Shopware 6. Daarbij komen cache- en temp-mappen van de toepassing. Bij multisite-installaties en meerdere websites op één server zijn er overeenkomstig veel uploadmappen; elk daarvan hoort in de zoekopdracht.

Ook .htaccess- en .user.ini-bestanden in de uploadmap zijn verdacht. Daarmee kan de uitvoering van PHP in deze map weer worden ingeschakeld of de configuratie worden gewijzigd.

PHP-bestand in de uploadmap: de vondst juist duiden

Niet elke treffer is even ernstig. De volgende indeling helpt bij de eerste beoordeling. Ze vervangt geen nauwkeurig onderzoek.

Lees verdachte bestanden alleen als tekst, bijvoorbeeld met head -c 2000 datei.php of less. Opvallend zijn zeer lange regels, gecodeerde tekenreeksen en functienamen zoals eval of base64_decode. Waaraan u versluierde code herkent, toont Versluierde PHP-code herkennen.

Is het bestand aangeroepen? Een blik in het log

De belangrijkste vraag na de vondst luidt: heeft iemand het bestand gebruikt? Het antwoord staat in de toegangslogs van de webserver. Zoek op de bestandsnaam, ook in gearchiveerde logs.

# Aanroepen van het verdachte bestand in actuele en ingepakte logs (naam als voorbeeld)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null

# Alleen geslaagde aanroepen met IP-adres en tijdstip
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'

Veel geslaagde POST-verzoeken van enkele adressen wijzen op actief gebruik als webshell. Geen treffers betekent niet automatisch ontwarring, want logs kunnen geroteerd, gewist of onvolledig zijn. Draait de website achter een CDN of proxy, dan staan daar verdere logs; bij shared hosting stelt de hoster de toegangslogs meestal beschikbaar in het klantenpaneel. Let bovendien op verzoeken naar andere nieuwe bestanden vanaf dezelfde adressen, want die leiden vaak naar verdere onderdelen. Bewaar logs vanaf 20 oktober. Hoe u logs grondig analyseert, staat in de gids Webserverlogs na een aanval analyseren.

Na de beoordeling: de juiste volgorde

1. Veiligstellen: Bestand met controlesom en tijdstempels kopiëren, logs veiligstellen.
2. Herkomst vaststellen: Uploadformulieren, plug-ins en de periode vóór de vondst controleren.
3. Verdere onderdelen zoeken: extra bestanden, cronjobs, nieuwe beheerdersaccounts.
4. Uitvoering blokkeren: PHP in de uploadmap op webserverniveau verbieden, zoals beschreven in het artikel PHP-uitvoering in uploadmappen verbieden.
5. Opschonen en toegangen wijzigen: pas dan het bestand verwijderen en alle wachtwoorden vernieuwen.

Hoe helpt PHP SOS concreet?

• Vondst beoordelen: Wij controleren het bestand zonder het uit te voeren en plaatsen het.
• Gebruik vaststellen: Wij analyseren de logs en reconstrueren wie het bestand wanneer heeft aangeroepen.
• Volledig opschonen: Met de malwareverwijdering zoeken wij alle onderdelen, dichten wij de oorzaak en wijzigen wij de toegangen.
• Herhaling voorkomen: Wij blokkeren de PHP-uitvoering in schrijfmappen en bewaken nieuwe bestanden.

Veelgestelde vragen

Bronnen

• OWASP Cheat Sheet Series (o.a. File Upload)
• OWASP Top 10
• php.net: beveiligingsmeldingen