# Verborgen cronjobs als achterdeur herkennen

> Cronjob-achterdeur herkennen: alle plekken voor geplande taken onder Linux controleren, verdachte vermeldingen duiden en vondsten veiligstellen vóór het wissen.

Bron: https://phpsos.de/nl/blog/cronjobs-als-hintertuer/  
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 verborgen cronjob is een van de meest voorkomende achterdeuren op Linux-servers: hij laadt regelmatig schadelijke code na of start processen opnieuw, ook na een PHP-update. Controleer alle plekken voor geplande taken, niet alleen `crontab -l`: crontabs van alle gebruikers, `/etc/crontab`, `/etc/cron.d`, de cron-mappen, systemd-timers en at-opdrachten. Stel vondsten veilig voordat u ze verwijdert.

## Waarom cronjobs als achterdeur zo geliefd zijn

Na een geslaagde inbraak heeft een aanvaller een probleem: zijn toegang is breekbaar. Een update dicht het lek, een beheerder wist de webshell, een herstart beëindigt het proces. Een cronjob lost dit probleem op. Hij start opdrachten op vaste tijden, zonder dat iemand ingrijpt, en herstelt zo verloren toegangen.

Voor PHP2Shell bestaan geen bevestigde Indicators of Compromise. Nieuwe cronjobs behoren volgens de ons beschikbare berichten echter tot de algemene waarschuwingssignalen na inbraken via webtoepassingen. Wie al naar webshells heeft gezocht, moet de geplande taken meteen meecontroleren. De overige stappen van een nazorg noemt de [checklist na een hack](https://phpsos.de/nl/ratgeber/checkliste-nach-dem-hack/).

## Waar geplande taken zich kunnen verbergen

Linux kent meerdere mechanismen voor geplande taken. Veel controles mislukken doordat er maar één van wordt bekeken.

| Plek | Debian/Ubuntu | RHEL-familie | Wie mag schrijven |
|---|---|---|---|
| Crontab per gebruiker | `/var/spool/cron/crontabs/` | `/var/spool/cron/` | de betreffende gebruiker |
| Systeembrede crontab | `/etc/crontab` | `/etc/crontab` | root |
| Afzonderlijke bestanden | `/etc/cron.d/` | `/etc/cron.d/` | root |
| Periodieke mappen | `/etc/cron.hourly` tot `/etc/cron.monthly` | idem | root |
| systemd-timers | `/etc/systemd/system/`, gebruikersunits | idem | root, deels gebruiker |
| at-opdrachten | wachtrij van `atd` | idem | gebruiker, indien toegestaan |

Belangrijk voor webservers: de webservergebruiker kan in de regel zijn eigen crontab aanmaken, zonder rootrechten. Een aanvaller met de rechten van `www-data` heeft daarvoor dus geen verder lek nodig. Vermeldingen in `/etc/cron.d` of systemd-units wijzen daarentegen erop dat hij rootrechten heeft verkregen.

Hostingpanelen zoals Plesk of cPanel bieden een eigen interface voor geplande taken. Daarachter staan in de regel eveneens crontabs van de betreffende systeemgebruikers. Wie alleen in de interface kijkt, herkent daarom niet elke vermelding die rechtstreeks op de server is aangemaakt. Controleer in geval van twijfel beide.

## Zo controleert u alle plekken volledig

De volgende opdrachten lezen alleen. Voer ze uit als root en bewaar de uitvoer met datum.

```bash
# Crontabs van alle gebruikers uitvoeren
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Systeembrede vermeldingen en wijzigingstijden
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# systemd-timers en at-opdrachten
systemctl list-timers --all
atq 2>/dev/null

# Typische patronen in alle cron-bestanden zoeken
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
```

Twee trucs verdienen bijzondere aandacht. Sommige vermeldingen verbergen opdrachten achter veel spaties, zodat ze in de editor rechts uit beeld lopen. Andere gebruiken stuurtekens die bij weergave tekst overschrijven. Met `cat -A` worden zulke tekens zichtbaar:

```bash
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
```

Een tweede invalshoek zijn de logs van de cron-service. Op veel systemen noteert cron elke uitvoering met gebruiker en opdracht. Zo ziet u ook vermeldingen die een aanvaller inmiddels weer heeft verwijderd, en herkent u sinds wanneer een verdachte opdracht draait:

```bash
# Uitgevoerde cron-opdrachten van de webservergebruiker (Debian/Ubuntu resp. systemd-journal)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100
```

## Waaraan u een cronjob-achterdeur herkent

1. **Nalaadacties van internet:** Een download waarvan het resultaat direct aan een shell wordt doorgegeven.
2. **Gecodeerde inhoud:** Lange tekenreeksen die pas tijdens de uitvoering worden gedecodeerd.
3. **Ongewone paden:** Programma's in `/tmp`, `/dev/shm`, verborgen mappen of uploadmappen.
4. **Verkeerde gebruiker:** Taken onder de webservergebruiker terwijl de toepassing er geen nodig heeft.
5. **Opvallende frequentie:** Uitvoering elke minuut of bij elke herstart via `@reboot`.
6. **Onpassende tijdstempels:** Bestand gewijzigd in een periode waarin niemand aan de server werkte, bijvoorbeeld na 17 oktober.

Niet vergeten: ook toepassingen hebben eigen schema's. WordPress beheert geplande taken bijvoorbeeld in de database. Hoe u daar controleert, beschrijft [Achterdeuren in WordPress vinden](https://phpsos.de/nl/ratgeber/backdoor-wordpress-finden/).

> **Belangrijk:**
> Een cronjob komt zelden alleen. Wie een geplande taak heeft aangemaakt, heeft vaak ook SSH-sleutels geplaatst of bestanden verborgen. Controleer bovendien de sleutels, zoals beschreven in het artikel [Onbekende SSH-sleutels vinden](https://phpsos.de/nl/blog/ssh-schluessel-pruefen/).

## Vondst veiligstellen, begrijpen, dan verwijderen

Een kwaadaardige cronjob is een waardevol bewijsstuk. Hij toont het naladresse, het tijdstip van aanmaak en vaak de gebruiker via wie de aanvaller binnenkwam. Stel het bestand met controlesom en tijdstempels veilig voordat u het verwijdert. De tijdstempel helpt later het verloop te reconstrueren; hoe dat gaat, toont [De tijdlijn van een incident opstellen](https://phpsos.de/nl/blog/zeitleiste-eines-vorfalls/). Ook voor een mogelijke melding aan de toezichthouder voor gegevensbescherming of voor de verzekeraar is de vondst een belangrijk bewijs van sinds wanneer een aanvaller toegang had.

Alleen verwijderen volstaat niet. Draait er nog een proces dat de vermelding opnieuw schrijft, dan is ze na de volgende minuut terug. En zolang het oorspronkelijke lek open is, kan de aanvaller op elk moment opnieuw beginnen. De volgorde luidt daarom: veiligstellen, oorzaak dichten, alle onderdelen verwijderen, toegangen wijzigen, bewaken.

## Cronjobs preventief beveiligen

Opdat een cronjob-achterdeur er niet eens kan ontstaan of snel opvalt, helpen drie maatregelen. Ten eerste kan worden vastgelegd welke gebruikers überhaupt een crontab mogen aanmaken. Bestaat het bestand `/etc/cron.allow`, dan mogen alleen de daar genoemde gebruikers `crontab` gebruiken. Heeft uw toepassing geen cronjob onder de webservergebruiker nodig, dan hoort die gebruiker niet op de lijst. Controleer vooraf welke taken de toepassing werkelijk nodig heeft, en leg die bewust vast onder een eigen gebruiker.

Ten tweede loont bewaking van de bestanden. Een hulpmiddel voor integriteitscontrole meldt zodra een bestand in de cron-mappen of onder `/var/spool/cron` wijzigt. Ten derde horen geplande taken in de documentatie van de server: wie weet welke vermeldingen er horen te zijn, herkent een vreemde meteen.

## Hoe helpt PHP SOS concreet?

- **Volledig controleren:** Wij onderzoeken alle mechanismen voor geplande taken, ook systemd-timers, at-opdrachten en schema's van toepassingen.
- **Vondsten plaatsen:** Wij analyseren verdachte vermeldingen zonder ze uit te voeren en leiden verdere sporen af.
- **Netjes opschonen:** Met de [malwareverwijdering](https://phpsos.de/nl/leistungen/malware-entfernung/) verwijderen wij alle onderdelen en dichten wij de oorzaak.
- **Terugkeer herkennen:** Wij richten een bewaking in die nieuwe of gewijzigde geplande taken meldt.


## Veelgestelde vragen

**Waarom gebruiken aanvallers cronjobs?**  
Een cronjob start opdrachten regelmatig en zonder verdere handeling. Aanvallers laden daarmee schadelijke code na, maken gewiste bestanden opnieuw aan of starten processen opnieuw. Zo overleeft hun toegang een update en vaak ook een oppervlakkige opschoning.

**Volstaat crontab -l voor de controle?**  
Nee. crontab -l toont alleen de crontab van de huidige gebruiker. Geplande taken staan bovendien in de crontabs van andere gebruikers, in /etc/crontab, /etc/cron.d, de cron.daily-mappen, in systemd-timers en in at-opdrachten.

**Hoe herken ik een kwaadaardige cronjob?**  
Typisch zijn downloads van internet met directe uitvoering, opdrachten met gecodeerde tekenreeksen, programma's in tijdelijke mappen, taken onder de webservergebruiker en vermeldingen die elke minuut draaien. Een afzonderlijk kenmerk is een aanwijzing, meerdere samen een ernstige verdenking.

**Kan ik verdachte cronjobs gewoon wissen?**  
Eerst veiligstellen, dan verwijderen. De vermelding verraadt vaak herkomst, naladresse en verdere onderdelen. Zonder op te helderen hoe ze is ontstaan, maakt de aanvaller haar vaak opnieuw aan.

## Bronnen

- [BSI: Duitse federale dienst voor informatiebeveiliging](https://www.bsi.bund.de/)
- [BSI IT-Grundschutz (Duitse IT-basisbeveiliging)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)