Kort sagt: Et skjult cronjob er en af de hyppigste bagdøre på Linux-servere: Det henter regelmæssigt skadelig kode eller genstarter processer, også efter en PHP-opdatering. Kontrollér alle steder for planlagte opgaver, ikke kun crontab -l: alle brugeres crontabs, /etc/crontab, /etc/cron.d, cron-mapperne, systemd-timere og at-opgaver. Sikr fund, før I fjerner dem.
Hvorfor cronjobs er så populære som bagdør
Efter et vellykket indbrud har en angriber et problem: Hans adgang er skrøbelig. En opdatering lukker sårbarheden, en administrator sletter webshellen, en genstart afslutter processen. Et cronjob løser dette problem. Det starter kommandoer på faste tidspunkter, uden at nogen griber ind, og genopretter dermed tabte adgange.
For PHP2Shell findes der ingen bekræftede indicators of compromise. Nye cronjobs hører dog ifølge de rapporter, vi har foran os, til de generelle advarselstegn efter indbrud via webapplikationer. Den, der allerede har søgt efter webshells, bør kontrollere de planlagte opgaver med det samme. De øvrige skridt i en efterbehandling opregner Tjekliste efter et hackerangreb.
Hvor planlagte opgaver kan skjule sig
Linux kender flere mekanismer til planlagte opgaver. Mange kontroller slår fejl, fordi kun én af dem ses efter.
| Sted | Debian/Ubuntu | RHEL-familien | Hvem må skrive |
|---|---|---|---|
| Crontab pr. bruger | /var/spool/cron/crontabs/ |
/var/spool/cron/ |
den pågældende bruger |
| Systemdækkende crontab | /etc/crontab |
/etc/crontab |
root |
| Enkeltfiler | /etc/cron.d/ |
/etc/cron.d/ |
root |
| Periodiske mapper | /etc/cron.hourly til /etc/cron.monthly |
tilsvarende | root |
| systemd-timere | /etc/systemd/system/, bruger-units |
tilsvarende | root, delvist bruger |
| at-opgaver | kø hos atd |
tilsvarende | bruger, hvis tilladt |
Vigtigt for webservere: Webserverbrugeren kan som regel oprette sin egen crontab uden root-rettigheder. En angriber med rettighederne for www-data behøver altså ingen yderligere sårbarhed hertil. Poster i /etc/cron.d eller systemd-units peger derimod på, at han har fået root-rettigheder.
Hostingpaneler som Plesk eller cPanel tilbyder en egen grænseflade til planlagte opgaver. Bagved står som regel ligeledes crontabs for de pågældende systembrugere. Den, der kun kigger i grænsefladen, genkender derfor ikke hver post, der er oprettet direkte på serveren. Kontrollér i tvivlstilfælde begge dele.
Sådan kontrollerer I alle steder fuldstændigt
Følgende kommandoer læser kun. Kør dem som root, og sikr output med dato.
# Udlæs alle brugeres crontabs
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
# Systemdækkende poster og ændringstidspunkter
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-timere og at-opgaver
systemctl list-timers --all
atq 2>/dev/null
# Søg typiske mønstre i alle cron-filer
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
To tricks fortjener særlig opmærksomhed. Nogle poster skjuler kommandoer bag mange mellemrum, så de løber ud af billedet til højre i editoren. Andre bruger styretegn, der overskriver tekst ved visningen. Med cat -A bliver sådanne tegn synlige:
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
En anden synsvinkel er cron-tjenestens logs. På mange systemer noterer cron hver udførelse med bruger og kommando. Så ser I også poster, som en angriber siden har fjernet igen, og genkender, siden hvornår en mistænkelig kommando har kørt:
# Udførte cron-kommandoer for webserverbrugeren (Debian/Ubuntu henholdsvis 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
Sådan genkender I en cronjob-bagdør
- Genhentning fra internettet: Et download, hvis resultat afleveres direkte til en shell.
- Kodet indhold: Lange tegnstrenge, der først afkodes under kørslen.
- Usædvanlige stier: Programmer i
/tmp,/dev/shm, skjulte mapper eller upload-mapper. - Forkert bruger: Opgaver under webserverbrugeren, selv om applikationen ikke har brug for nogen.
- Påfaldende takt: Udførelse hvert minut eller ved hver genstart via
@reboot. - Upassende tidsstempler: Fil ændret i en periode, hvor ingen arbejdede på serveren, f.eks. efter den 17. oktober.
Glem ikke: Også applikationer har egne tidsplaner. WordPress administrerer f.eks. planlagte opgaver i databasen. Hvordan I kontrollerer dem dér, beskriver Find bagdøre i WordPress.
Et cronjob kommer sjældent alene. Den, der har oprettet en planlagt opgave, har ofte også lagt SSH-nøgler ind eller skjult filer. Kontrollér desuden nøglerne, som beskrevet i indlægget Find ukendte SSH-nøgler.
Sikr fundet, forstå det, fjern det derefter
Et ondsindet cronjob er et værdifuldt bevismiddel. Det viser hentningsadressen, tidspunktet for dets oprettelse og ofte den bruger, via hvem angriberen kom ind. Sikr filen med kontrolsum og tidsstempler, før I fjerner den. Tidsstemplet hjælper senere med at rekonstruere forløbet; hvordan det gøres, viser Opret tidslinjen for en hændelse. Også til en mulig anmeldelse til databeskyttelsestilsynet eller til forsikringsselskabet er fundet et vigtigt bevis for, siden hvornår en angriber havde adgang.
At fjerne det alene er ikke nok. Kører der stadig en proces, der skriver posten på ny, er den tilbage efter næste minut. Og så længe den oprindelige sårbarhed er åben, kan angriberen når som helst sætte an igen. Rækkefølgen er derfor: sikre, lukke årsagen, fjerne alle bestanddele, skifte adgange, overvåge.
Sikr cronjobs forebyggende
For at en cronjob-bagdør slet ikke kan opstå eller hurtigt falder i øjnene, hjælper tre foranstaltninger. For det første kan det fastlægges, hvilke brugere der overhovedet må oprette en crontab. Findes filen /etc/cron.allow, må kun de dér nævnte brugere bruge crontab. Har jeres applikation ikke brug for et cronjob under webserverbrugeren, hører denne bruger ikke på listen. Kontrollér først, hvilke opgaver applikationen faktisk har brug for, og opret dem bevidst under en egen bruger.
For det andet er en overvågning af filerne umagen værd. Et værktøj til integritetskontrol melder, så snart en fil i cron-mapperne eller under /var/spool/cron ændrer sig. For det tredje hører planlagte opgaver med i serverens dokumentation: Den, der ved, hvilke poster der skal være, genkender en fremmed med det samme.
Hvordan hjælper PHP SOS konkret?
- Kontrollér fuldstændigt: Vi undersøger alle mekanismer for planlagte opgaver, også systemd-timere, at-opgaver og applikationers tidsplaner.
- Vurdér fund: Vi analyserer mistænkelige poster uden at udføre dem og udleder yderligere spor.
- Ryd rent op: Med malwarefjernelsen fjerner vi alle bestanddele og lukker årsagen.
- Opdag tilbagevenden: Vi sætter en overvågning op, der melder nye eller ændrede planlagte opgaver.
Ofte stillede spørgsmål
Hvorfor bruger angribere cronjobs?
Et cronjob starter kommandoer regelmæssigt og uden videre indgriben. Angribere henter dermed skadelig kode igen, genopretter slettede filer eller starter processer på ny. Sådan overlever deres adgang en opdatering og ofte også en overfladisk oprydning.
Er crontab -l nok til kontrollen?
Nej. crontab -l viser kun den aktuelle brugers crontab. Planlagte opgaver står desuden i andre brugeres crontabs, i /etc/crontab, /etc/cron.d, cron.daily-mapperne, i systemd-timere og i at-opgaver.
Hvordan genkender jeg et ondsindet cronjob?
Typisk er downloads fra internettet med direkte udførelse, kommandoer med kodede tegnstrenge, programmer i midlertidige mapper, opgaver under webserverbrugeren og poster, der kører hvert minut. Et enkelt kendetegn er et fingerpeg, flere en alvorlig mistanke.
Kan jeg bare slette mistænkelige cronjobs?
Først sikre, så fjerne. Posten afslører ofte oprindelse, hentningsadresse og yderligere bestanddele. Uden en afklaring af, hvordan den er opstået, opretter angriberen den ofte på ny.