# Webshell herkennen en verwijderen

> Webshell herkennen na PHP2Shell: verdachte PHP-bestanden, processen en verbindingen vinden, sporen veiligstellen en achterdeurtjes laten verwijderen.

Bron: https://phpsos.de/nl/ratgeber/webshell-erkennen/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een webshell herkent u aan nieuwe of gewijzigde PHP-bestanden op ongebruikelijke plekken, aan vreemde processen van de webservergebruiker en aan ongewone verbindingen. Zet sporen veilig voordat u iets verwijdert, en herstel de code vanuit een schone bron. Een patch alleen verwijdert geen achterdeur.

## Waarom webshells na PHP2Shell een onderwerp zijn

De kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 in PHP zelf maken het mogelijk om op afstand en zonder aanmelding schadelijke code uit te voeren. Een voor de hand liggend doel na een geslaagde aanval is een permanente achterdeur, dus een webshell. Die blijft bestaan, ook als PHP inmiddels is bijgewerkt.

Volgens mediaberichten werd al op 17-10-2026 een eerste aanvalspoging waargenomen; de patches volgden op 21-10. Wie in die periode kwetsbaar was, moet gericht gaan kijken. Bevestigde Indicators of Compromise zijn tot nu toe niet gepubliceerd. De zoektocht steunt daarom op opvallend gedrag, niet op een kant-en-klare lijst.

> **Direct handelen:**
> Vindt u op een server met klantgegevens een webshell: verwijder niets overhaast. Zet eerst bewijs veilig, isoleer dan de server en plan de verdere afhandeling.

## Hoe u een webshell herkent: bestanden controleren

De meeste webshells zijn PHP-bestanden in de webmap. Opvallend zijn bestanden die na 17-10. zijn ontstaan of gewijzigd, PHP-bestanden in upload- en cachemappen en bestanden met versluierde code. De volgende opdrachten veranderen niets, ze maken alleen een lijst:

```bash
# PHP-bestanden die sinds 17-10-2026 zijn gewijzigd
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls

# PHP-bestanden in upload-, cache- of tmp-mappen
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls

# Typische versluiering: eval in combinatie met decodering
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"

# Ongewoon lange regels wijzen vaak op ingepakte code
grep -rlE ".{3000,}" /var/www --include="*.php"
```

Treffers zijn aanwijzingen, geen bewijzen. Sommige plug-ins gebruiken legitiem gecodeerde code. Vergelijk verdachte bestanden met het originele pakket van de fabrikant. Het betrouwbaarst is een vergelijking met controlesommen of een versiebeheersysteem zoals Git:

```bash
# Afwijkingen ten opzichte van de laatst bekende stand in de Git-repository
git -C /var/www/projekt status --porcelain
```

Een tijdstempel kan vervalst zijn. Vertrouw daarom niet alleen op de wijzigingsdatum van een bestand.

### Welke kenmerken een bestand verdacht maken

| Kenmerk | Waarom het opvalt |
|---|---|
| PHP-bestand in een upload- of afbeeldingenmap | Daar horen alleen media te staan |
| Dubbele extensie zoals `.jpg.php` of `.php.png` | Vermomming als onschuldig bestand |
| Zeer lange regels zonder regeleinde | Typisch voor ingepakte of versleutelde code |
| Bestandsnaam lijkt op een kernbestand, maar zit niet in het originele pakket | Vermomming in een bekende omgeving |
| Eigenaar of rechten wijken af van naastliggende bestanden | Bestand is op een andere manier aangemaakt |

Hoe meer kenmerken samenkomen, hoe groter de kans op een vondst. Open verdachte bestanden alleen als tekst, nooit via de browser, want een aanroep via de website zou de code uitvoeren.

## Processen, verbindingen en cronjobs controleren

Een actieve webshell laat vaak sporen na buiten het bestandssysteem. De webservergebruiker, bijvoorbeeld `www-data`, `apache` of `nginx`, start normaal geen shells, netwerkprogramma's of compilers.

```bash
# Processen van de gebruikelijke webservergebruikers
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"

# Open netwerkverbindingen met bijbehorend proces
sudo ss -tunap | grep -E "php|www-data|apache|nginx"

# Geplande taken van de webservergebruiker
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
```

Opvallend zijn duurzame uitgaande verbindingen naar onbekende bestemmingen, processen met cryptische namen en cronjobs die bestanden van internet nalaadt. Controleer bovendien de toegangslogs op verzoeken aan bestanden die er eerder niet waren. Hoe dat gaat, beschrijft de gids [Webserverlogs na een aanval analyseren](https://phpsos.de/nl/ratgeber/logfiles-auswerten/).

## Sporen veiligstellen voordat u verwijdert

Wie eerst verwijdert, verliest het antwoord op de belangrijkste vragen: hoe kwam de aanvaller binnen, wat heeft hij gezien, welke gegevens zijn getroffen? Die antwoorden hebt u nodig voor een mogelijke melding op grond van de AVG, voor verzekeraars en voor de beslissing of andere systemen gevaar lopen.

Zinvolle volgorde:

1. De toestand documenteren: procesoverzicht, netwerkverbindingen, aangemelde gebruikers.
2. Verdachte bestanden en logs met controlesom kopiëren, zonder ze te openen of uit te voeren.
3. Indien mogelijk een image van het systeem of een snapshot van de virtuele machine maken.
4. De server van het netwerk halen of de toegang sterk beperken.

Bij systemen met gevoelige gegevens of een mogelijk geschil moet het veiligstellen forensisch zuiver gebeuren. Achtergronden daarover vindt u onder [IT-forensica na een aanval op een webserver](https://phpsos.de/nl/leistungen/it-forensik/).

## Webshells correct verwijderen

Het verwijderen van één bestand is zelden het einde. Aanvallers richten vaak meerdere toegangen in: extra bestanden op verborgen plekken, vermeldingen in configuratiebestanden zoals `.htaccess` of `.user.ini`, nieuwe beheerdersaccounts in de toepassing of cronjobs. Een betrouwbare schoonmaak volgt deze stappen:

- PHP naar een verholpen stand brengen (8.5.12, 8.4.27, 8.3.36, 8.2.35 of bevestigde backport) en alle PHP-processen herstarten.
- De toepassingscode opnieuw opzetten vanuit een schone bron, in plaats van afzonderlijke bestanden te repareren.
- Alleen gecontroleerde inhoud zoals uploads en database overnemen en daarin gericht zoeken naar binnengebrachte code.
- Alle toegangsgegevens wijzigen: database, SSH, FTP, beheerdersaccounts, API-sleutels.
- Schrijfrechten van de webserver tot het hoogstnodige beperken en PHP-uitvoering in uploadmappen verhinderen.

Voor WordPress zijn er eigen typische schuilplaatsen, die de gids [Achterdeurtjes in WordPress vinden](https://phpsos.de/nl/ratgeber/backdoor-wordpress-finden/) beschrijft. Daarna moet de website een tijd lang nauwer worden bewaakt om nieuwe toegang vroeg op te merken.

## Hoe helpt PHP SOS concreet?

- We stellen logs, bestanden en systeemstatus controleerbaar veilig voordat er iets wordt gewijzigd.
- We zoeken achterdeurtjes in bestanden, database, cronjobs en configuratie en beoordelen de vondsten.
- We zetten de toepassing opnieuw op vanuit een schone bron, wijzigen toegangen en verharden de server.
- We documenteren het incident tot het is afgesloten, als basis voor meldingen en verzekeraars.

Het verloop van een schoonmaak beschrijft de dienst [Malware en webshells laten verwijderen](https://phpsos.de/nl/leistungen/malware-entfernung/).


## Veelgestelde vragen

**Wat is een webshell?**  
Een webshell is een binnengebracht bestand, meestal PHP, waarmee aanvallers de server op afstand kunnen besturen. Ze vermomt zich vaak als onschuldig bestand met een onopvallende naam en blijft ook na een update actief.

**Vindt een virusscanner elke webshell?**  
Nee. Scanners herkennen bekende patronen; nieuwe of sterk versluierde varianten glippen erdoor. Voor PHP2Shell zijn bovendien geen gepubliceerde, bevestigde Indicators of Compromise beschikbaar, daarom is gedragsanalyse belangrijker dan een signatuurlijst.

**Volstaat het om het gevonden bestand te verwijderen?**  
Meestal niet. Aanvallers richten vaak meerdere toegangen in, zoals extra bestanden, cronjobs of nieuwe beheerdersaccounts. Zonder oorzaakanalyse en wijziging van alle toegangsgegevens is nieuwe toegang waarschijnlijk.

**Moet ik na het vinden van een webshell iets melden?**  
Als persoonsgegevens getroffen kunnen zijn, kan er een meldplicht volgens de AVG bestaan, in de regel binnen 72 uur. Stem dit af met uw functionaris voor gegevensbescherming of een advocaat; dit is geen juridisch advies.

## Bronnen

- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik (Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/)
- [AVG art. 33: melding aan de toezichthouder](https://dsgvo-gesetz.de/art-33-dsgvo/)