Krótko: Ukryte zadanie cron to jedna z najczęstszych tylnych furtek na serwerach Linux: regularnie doładowuje złośliwy kod lub ponownie uruchamia procesy, także po aktualizacji PHP. Proszę sprawdzić wszystkie miejsca zaplanowanych zadań, a nie tylko crontab -l: crontaby wszystkich użytkowników, /etc/crontab, /etc/cron.d, katalogi cron, timery systemd i zlecenia at. Znaleziska proszę zabezpieczyć, zanim zostaną usunięte.
Dlaczego zadania cron są tak lubianą tylną furtką
Po udanym włamaniu atakujący ma problem: jego dostęp jest kruchy. Aktualizacja zamyka lukę, administrator usuwa webshell, restart kończy proces. Zadanie cron rozwiązuje ten problem. Uruchamia polecenia w ustalonych porach bez niczyjej interwencji i w ten sposób odtwarza utracone dostępy.
Dla PHP2Shell nie ma potwierdzonych wskaźników kompromitacji (Indicators of Compromise). Nowe zadania cron należą jednak według znanych nam doniesień do ogólnych sygnałów ostrzegawczych po włamaniach przez aplikacje webowe. Kto już szukał webshelli, powinien od razu sprawdzić także zaplanowane zadania. Pozostałe kroki późniejszej obróbki wymienia Lista kontrolna po włamaniu.
Gdzie mogą ukrywać się zaplanowane zadania
Linux zna kilka mechanizmów zaplanowanych zadań. Wiele kontroli zawodzi, ponieważ sprawdzany jest tylko jeden z nich.
| Miejsce | Debian/Ubuntu | Rodzina RHEL | Kto może zapisywać |
|---|---|---|---|
| Crontab każdego użytkownika | /var/spool/cron/crontabs/ |
/var/spool/cron/ |
dany użytkownik |
| Crontab systemowy | /etc/crontab |
/etc/crontab |
root |
| Pojedyncze pliki | /etc/cron.d/ |
/etc/cron.d/ |
root |
| Katalogi okresowe | /etc/cron.hourly do /etc/cron.monthly |
tak samo | root |
| Timery systemd | /etc/systemd/system/, unity użytkowników |
tak samo | root, częściowo użytkownik |
| Zlecenia at | kolejka atd |
tak samo | użytkownik, jeśli dozwolone |
Ważne dla serwerów WWW: użytkownik serwera WWW może zwykle założyć własny crontab bez uprawnień roota. Atakujący z uprawnieniami www-data nie potrzebuje więc do tego kolejnej luki. Wpisy w /etc/cron.d lub unity systemd wskazują natomiast, że zdobył uprawnienia roota.
Panele hostingowe, takie jak Plesk czy cPanel, oferują własny interfejs zaplanowanych zadań. Za nim stoją zwykle również crontaby poszczególnych użytkowników systemowych. Kto zagląda tylko do interfejsu, nie rozpozna więc każdego wpisu założonego bezpośrednio na serwerze. W razie wątpliwości proszę sprawdzić oba miejsca.
Jak sprawdzić wszystkie miejsca w pełni
Poniższe polecenia tylko odczytują dane. Proszę je wykonać jako root i zabezpieczyć wyniki z datą.
# Wypisać crontaby wszystkich użytkowników
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
# Wpisy systemowe i czasy modyfikacji
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
# Timery systemd i zlecenia at
systemctl list-timers --all
atq 2>/dev/null
# Szukać typowych wzorców we wszystkich plikach cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
Dwie sztuczki zasługują na szczególną uwagę. Niektóre wpisy ukrywają polecenia za wieloma spacjami, tak że w edytorze wypadają z ekranu po prawej stronie. Inne używają znaków sterujących, które przy wyświetlaniu nadpisują tekst. Poleceniem cat -A takie znaki stają się widoczne:
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
Drugą perspektywą są protokoły usługi cron. W wielu systemach cron zapisuje każde wykonanie z użytkownikiem i poleceniem. Dzięki temu widać także wpisy, które atakujący w międzyczasie usunął, i można rozpoznać, od kiedy działa podejrzane polecenie:
# Wykonane polecenia cron użytkownika serwera WWW (Debian/Ubuntu lub dziennik systemd)
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
Po czym poznać tylną furtkę w cron
- Doładowanie z internetu: Pobranie, którego wynik jest przekazywany bezpośrednio do powłoki.
- Zakodowane treści: Długie ciągi znaków, które są dekodowane dopiero w czasie działania.
- Nietypowe ścieżki: Programy w
/tmp,/dev/shm, ukrytych folderach lub katalogach uploadu. - Zły użytkownik: Zadania pod użytkownikiem serwera WWW, choć aplikacja żadnych nie potrzebuje.
- Rzucający się w oczy takt: Wykonanie co minutę lub przy każdym restarcie przez
@reboot. - Niepasujące znaczniki czasu: Plik zmieniony w okresie, w którym nikt nie pracował na serwerze, na przykład po 17 października.
Nie zapominać: aplikacje mają też własne harmonogramy. WordPress na przykład zarządza zaplanowanymi zadaniami w bazie danych. Jak je tam sprawdzić, opisuje Znajdowanie backdoorów w WordPress.
Zadanie cron rzadko występuje samo. Kto założył zaplanowane zadanie, często zapisał też klucze SSH lub ukrył pliki. Proszę dodatkowo sprawdzić klucze, jak opisano w artykule Znajdowanie nieznanych kluczy SSH.
Znalezisko zabezpieczyć, zrozumieć, potem usunąć
Złośliwe zadanie cron to cenny dowód. Pokazuje adres doładowania, moment utworzenia i często użytkownika, przez którego wszedł atakujący. Plik proszę zabezpieczyć z sumą kontrolną i znacznikami czasu, zanim zostanie usunięty. Znacznik czasu pomaga później odtworzyć przebieg; jak to zrobić, pokazuje Tworzenie osi czasu incydentu. Także dla ewentualnego zgłoszenia do organu nadzorczego ochrony danych lub dla ubezpieczyciela znalezisko jest ważnym dowodem, od kiedy atakujący miał dostęp.
Samo usunięcie nie wystarcza. Jeśli nadal działa proces, który zapisuje wpis na nowo, wraca po następnej minucie. A dopóki pierwotna luka jest otwarta, atakujący może w każdej chwili zacząć od nowa. Kolejność brzmi więc: zabezpieczyć, zamknąć przyczynę, usunąć wszystkie składniki, zmienić dostępy, monitorować.
Zabezpieczanie zadań cron prewencyjnie
Aby tylna furtka w cron w ogóle nie mogła powstać lub szybko się ujawniła, pomagają trzy środki. Po pierwsze, można ustalić, którzy użytkownicy w ogóle mogą zakładać crontab. Jeśli istnieje plik /etc/cron.allow, tylko wymienieni tam użytkownicy mogą używać crontab. Jeśli Państwa aplikacja nie potrzebuje zadania cron pod użytkownikiem serwera WWW, ten użytkownik nie należy na listę. Proszę wcześniej sprawdzić, jakich zadań aplikacja faktycznie potrzebuje, i założyć je świadomie pod osobnym użytkownikiem.
Po drugie, opłaca się monitorowanie plików. Narzędzie do kontroli integralności zgłasza, gdy plik w katalogach cron lub pod /var/spool/cron się zmieni. Po trzecie, zaplanowane zadania należą do dokumentacji serwera: kto wie, jakie wpisy powinny istnieć, od razu rozpozna obcy.
Jak konkretnie pomaga PHP SOS?
- Sprawdzić w pełni: Badamy wszystkie mechanizmy zaplanowanych zadań, także timery systemd, zlecenia at i harmonogramy aplikacji.
- Ocenić znaleziska: Analizujemy podejrzane wpisy bez ich wykonywania i wyprowadzamy dalsze ślady.
- Oczyścić czysto: W ramach usuwania złośliwego oprogramowania usuwamy wszystkie składniki i zamykamy przyczynę.
- Rozpoznać powrót: Konfigurujemy monitoring, który zgłasza nowe lub zmienione zaplanowane zadania.
Częste pytania
Dlaczego atakujący używają zadań cron?
Zadanie cron uruchamia polecenia regularnie i bez dalszej interwencji. Atakujący doładowują tak złośliwy kod, tworzą na nowo usunięte pliki lub ponownie uruchamiają procesy. Dzięki temu ich dostęp przetrwa aktualizację, a często i powierzchowne oczyszczenie.
Czy do kontroli wystarczy crontab -l?
Nie. crontab -l pokazuje tylko crontab bieżącego użytkownika. Zaplanowane zadania stoją ponadto w crontabach innych użytkowników, w /etc/crontab, /etc/cron.d, w katalogach cron.daily, w timerach systemd i w zleceniach at.
Jak rozpoznać złośliwe zadanie cron?
Typowe są pobrania z internetu z bezpośrednim wykonaniem, polecenia z zakodowanymi ciągami znaków, programy w katalogach tymczasowych, zadania pod użytkownikiem serwera WWW i wpisy uruchamiane co minutę. Pojedyncza cecha jest wskazówką, kilka to poważne podejrzenie.
Czy mogę po prostu usunąć podejrzane zadania cron?
Najpierw zabezpieczyć, potem usunąć. Wpis często zdradza pochodzenie, adres doładowania i dalsze składniki. Bez wyjaśnienia, jak powstał, atakujący często zakłada go ponownie.