Kort sagt: Ett dolt cronjobb är en av de vanligaste bakdörrarna på Linux-servrar: det laddar regelbundet ned skadlig kod eller startar om processer, också efter en PHP-uppdatering. Kontrollera alla platser för schemalagda uppgifter, inte bara crontab -l: alla användares crontabs, /etc/crontab, /etc/cron.d, cron-mapparna, systemd-timers och at-jobb. Säkra fynd innan ni tar bort dem.
Varför cronjobb är så omtyckta som bakdörr
Efter ett lyckat intrång har en angripare ett problem: hans åtkomst är bräcklig. En uppdatering stänger sårbarheten, en administratör raderar webbshellen, en omstart avslutar processen. Ett cronjobb löser det problemet. Det startar kommandon vid fasta tider utan att någon ingriper, och återställer på så vis förlorade åtkomster.
För PHP2Shell finns inga bekräftade Indicators of Compromise. Nya cronjobb hör dock enligt de rapporter vi har tillgång till till de allmänna varningssignalerna efter intrång via webbapplikationer. Den som redan har sökt efter webbshells bör kontrollera de schemalagda uppgifterna samtidigt. De övriga stegen i en efterbehandling anger Checklista efter ett intrång.
Var schemalagda uppgifter kan gömma sig
Linux har flera mekanismer för schemalagda uppgifter. Många kontroller misslyckas eftersom bara en av dem granskas.
| Plats | Debian/Ubuntu | RHEL-familjen | Vem får skriva |
|---|---|---|---|
| Crontab per användare | /var/spool/cron/crontabs/ |
/var/spool/cron/ |
respektive användare |
| Systemomfattande crontab | /etc/crontab |
/etc/crontab |
root |
| Enskilda filer | /etc/cron.d/ |
/etc/cron.d/ |
root |
| Periodiska mappar | /etc/cron.hourly till /etc/cron.monthly |
likaså | root |
| systemd-timers | /etc/systemd/system/, användar-units |
likaså | root, delvis användare |
| at-jobb | atd:s kö |
likaså | användare, om tillåtet |
Viktigt för webbservrar: webbserveranvändaren kan som regel skapa sin egen crontab utan root-rättigheter. En angripare med www-data:s rättigheter behöver alltså ingen ytterligare sårbarhet för det. Poster i /etc/cron.d eller systemd-units tyder däremot på att han har fått root-rättigheter.
Hostingpaneler som Plesk eller cPanel erbjuder ett eget gränssnitt för schemalagda uppgifter. Bakom det står i regel också crontabs för respektive systemanvändare. Den som bara tittar i gränssnittet upptäcker därför inte varje post som skapats direkt på servern. Kontrollera vid tvivel båda.
Så kontrollerar ni alla platser fullständigt
Kommandona nedan läser bara. Kör dem som root och säkra utskrifterna med datum.
# Skriv ut alla användares 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
# Systemomfattande poster och ändringstider
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 och at-jobb
systemctl list-timers --all
atq 2>/dev/null
# Sök typiska mönster i alla cron-filer
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
Två knep förtjänar särskild uppmärksamhet. Vissa poster gömmer kommandon bakom många blanksteg, så att de löper ut ur bild åt höger i redigeraren. Andra använder styrtecken som skriver över text vid visningen. Med cat -A blir sådana tecken synliga:
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
En andra synvinkel är cron-tjänstens loggar. På många system noterar cron varje körning med användare och kommando. Då ser ni också poster som en angripare i mellantiden har tagit bort igen, och ser sedan när ett misstänkt kommando har körts:
# Körda cron-kommandon för webbserveranvändaren (Debian/Ubuntu respektive 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å känner ni igen en cronjobb-bakdörr
- Nedladdning från internet: En nedladdning vars resultat lämnas direkt till ett skal.
- Kodat innehåll: Långa teckensträngar som först avkodas under körning.
- Ovanliga sökvägar: Program i
/tmp,/dev/shm, dolda mappar eller uppladdningskataloger. - Fel användare: Uppgifter under webbserveranvändaren fast applikationen inte behöver några.
- Uppseendeväckande takt: Körning varje minut eller vid varje omstart via
@reboot. - Opassande tidsstämplar: Fil ändrad under en period då ingen arbetade på servern, till exempel efter den 17 oktober.
Glöm inte: även applikationer har egna scheman. WordPress hanterar till exempel schemalagda uppgifter i databasen. Hur ni kontrollerar där beskrivs i Hitta bakdörrar i WordPress.
Ett cronjobb kommer sällan ensamt. Den som har skapat en schemalagd uppgift har ofta också lagt in SSH-nycklar eller gömt filer. Kontrollera dessutom nycklarna, som beskrivs i inlägget Hitta okända SSH-nycklar.
Säkra fyndet, förstå det, ta sedan bort det
Ett illasinnat cronjobb är ett värdefullt bevisföremål. Det visar nedladdningsadressen, tidpunkten för skapandet och ofta den användare via vilken angriparen kom in. Säkra filen med kontrollsumma och tidsstämplar innan ni tar bort den. Tidsstämpeln hjälper senare att rekonstruera förloppet; hur det går till visar Ta fram tidslinjen för en incident. Även för en möjlig anmälan till dataskyddsmyndigheten eller för försäkringsbolaget är fyndet ett viktigt belägg för sedan när en angripare hade åtkomst.
Att bara ta bort räcker inte. Körs fortfarande en process som skriver om posten är den tillbaka efter nästa minut. Och så länge den ursprungliga sårbarheten är öppen kan angriparen när som helst börja om. Ordningen är därför: säkra, stäng orsaken, ta bort alla delar, byt åtkomster, övervaka.
Säkra cronjobb förebyggande
För att en cronjobb-bakdörr inte ens ska kunna uppstå eller snabbt ska synas hjälper tre åtgärder. För det första går det att bestämma vilka användare som överhuvudtaget får skapa en crontab. Finns filen /etc/cron.allow får bara de användare som nämns där använda crontab. Behöver er applikation inget cronjobb under webbserveranvändaren hör den användaren inte hemma på listan. Kontrollera i förväg vilka uppgifter applikationen faktiskt behöver och skapa dem medvetet under en egen användare.
För det andra lönar sig en övervakning av filerna. Ett verktyg för integritetskontroll meddelar så snart en fil i cron-katalogerna eller under /var/spool/cron ändras. För det tredje hör schemalagda uppgifter hemma i serverns dokumentation: den som vet vilka poster som ska finnas känner direkt igen en främmande.
Hur hjälper PHP SOS konkret?
- Kontrollera fullständigt: Vi undersöker alla mekanismer för schemalagda uppgifter, även systemd-timers, at-jobb och applikationsscheman.
- Placera fynd: Vi utvärderar misstänkta poster utan att köra dem och härleder fler spår.
- Sanera rent: Med skadeprogramborttagningen tar vi bort alla delar och stänger orsaken.
- Upptäcka återkomst: Vi sätter upp en övervakning som meddelar nya eller ändrade schemalagda uppgifter.
Vanliga frågor
Varför använder angripare cronjobb?
Ett cronjobb startar kommandon regelbundet och utan vidare åtgärd. Angripare laddar med det ned skadlig kod, återskapar raderade filer eller startar om processer. Så överlever deras åtkomst en uppdatering och ofta också en ytlig sanering.
Räcker crontab -l för kontrollen?
Nej. crontab -l visar bara den aktuella användarens crontab. Schemalagda uppgifter finns dessutom i andra användares crontabs, i /etc/crontab, /etc/cron.d, mapparna cron.daily, i systemd-timers och i at-jobb.
Hur känner jag igen ett illasinnat cronjobb?
Typiskt är nedladdningar från internet med direkt körning, kommandon med kodade teckensträngar, program i temporära mappar, uppgifter under webbserveranvändaren och poster som körs varje minut. Ett enskilt kännetecken är en fingervisning, flera en allvarlig misstanke.
Kan jag helt enkelt radera misstänkta cronjobb?
Säkra först, ta sedan bort. Posten avslöjar ofta ursprung, nedladdningsadress och fler delar. Utan att ha klarlagt hur den uppstod skapar angriparen den ofta på nytt.