# Разпознаване на скрити cron задачи като задна вратичка

> Разпознаване на задна вратичка през cron: проверете всички места за планирани задачи под Linux, тълкувайте подозрителните записи и запазете находките, преди да изтриете.

Източник: https://phpsos.de/bg/blog/cronjobs-als-hintertuer/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Скритата cron задача е една от най-честите задни вратички на Linux сървъри: тя зарежда редовно злонамерен код или стартира наново процеси, и след актуализация на PHP. Проверете всички места за планирани задачи, не само `crontab -l`: crontab файловете на всички потребители, `/etc/crontab`, `/etc/cron.d`, cron директориите, таймерите на systemd и задачите at. Запазете находките, преди да ги премахнете.

## Защо cron задачите са толкова любими като задна вратичка

След успешно проникване нападателят има един проблем: достъпът му е крехък. Актуализация затваря уязвимостта, администратор изтрива уеб шела, рестарт прекратява процеса. Cron задачата решава този проблем. Тя стартира команди в определени часове, без някой да се намесва, и така възстановява загубените достъпи.

За PHP2Shell няма потвърдени Indicators of Compromise. Новите cron задачи спадат обаче според наличните ни съобщения към общите предупредителни сигнали след проникване през уеб приложения. Който вече е търсил уеб шелове, трябва да провери веднага и планираните задачи. Останалите стъпки на последваща обработка изброява [Контролният списък след хакване](https://phpsos.de/bg/ratgeber/checkliste-nach-dem-hack/).

## Къде могат да се крият планираните задачи

Linux познава няколко механизма за планирани задачи. Много проверки се провалят, защото се разглежда само един от тях.

| Място | Debian/Ubuntu | RHEL семейство | Кой може да пише |
|---|---|---|---|
| Crontab за всеки потребител | `/var/spool/cron/crontabs/` | `/var/spool/cron/` | съответният потребител |
| Общосистемен crontab | `/etc/crontab` | `/etc/crontab` | root |
| Отделни файлове | `/etc/cron.d/` | `/etc/cron.d/` | root |
| Периодични директории | `/etc/cron.hourly` до `/etc/cron.monthly` | същото | root |
| Таймери на systemd | `/etc/systemd/system/`, потребителски unit-и | същото | root, отчасти потребители |
| Задачи at | Опашка на `atd` | същото | потребители, ако е разрешено |

Важно за уеб сървърите: Потребителят на уеб сървъра по правило може да създаде собствен crontab без права на root. Нападател с правата на `www-data` затова не се нуждае от друга уязвимост за това. Записи в `/etc/cron.d` или unit-и на systemd, напротив, сочат, че е получил права на root.

Хостинг панели като Plesk или cPanel предлагат собствен интерфейс за планирани задачи. Зад него по правило също стоят crontab файловете на съответните системни потребители. Който поглежда само в интерфейса, затова не разпознава всеки запис, създаден директно на сървъра. При съмнение проверете и двете.

## Така проверявате всички места изцяло

Следните команди само четат. Изпълнете ги като root и запазете изходите с дата.

```bash
# Извеждане на crontab файловете на всички потребители
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

# Общосистемни записи и времена на промяна
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 и задачи at
systemctl list-timers --all
atq 2>/dev/null

# Търсене на типични шаблони във всички cron файлове
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
```

Два трика заслужават особено внимание. Някои записи крият команди зад много интервали, така че в редактора излизат вдясно от екрана. Други ползват управляващи знаци, които при показването презаписват текст. С `cat -A` такива знаци стават видими:

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

Втора гледна точка са протоколите на cron услугата. В много системи cron отбелязва всяко изпълнение с потребител и команда. Така виждате и записи, които нападателят междувременно е премахнал, и разпознавате от кога работи подозрителна команда:

```bash
# Изпълнени cron команди на потребителя на уеб сървъра (Debian/Ubuntu респ. журнал на 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
```

## По какво разпознавате задна вратичка през cron

1. **Зареждане от интернет:** Изтегляне, чийто резултат се предава директно на shell.
2. **Кодирано съдържание:** Дълги низове, които се декодират едва по време на изпълнение.
3. **Необичайни пътища:** Програми в `/tmp`, `/dev/shm`, скрити директории или директории за качване.
4. **Грешен потребител:** Задачи под потребителя на уеб сървъра, макар приложението да не се нуждае от такива.
5. **Странен такт:** Изпълнение всяка минута или при всеки рестарт чрез `@reboot`.
6. **Неподходящи времеви печати:** Файл, променен в период, в който никой не е работил по сървъра, например след 17 октомври.

Да не забравяме: и приложенията имат собствени графици. WordPress например управлява планираните задачи в базата данни. Как да проверите там, описва [Намиране на задни вратички в WordPress](https://phpsos.de/bg/ratgeber/backdoor-wordpress-finden/).

> **Важно:**
> Една cron задача рядко идва сама. Който е създал планирана задача, често е оставил и SSH ключове или е скрил файлове. Проверете допълнително ключовете, както е описано в статията [Намиране на непознати SSH ключове](https://phpsos.de/bg/blog/ssh-schluessel-pruefen/).

## Запазване на находката, разбиране, после премахване

Злонамерената cron задача е ценно веществено доказателство. Тя показва адреса за зареждане, момента на създаването си и често потребителя, през когото е дошъл нападателят. Запазете файла с контролна сума и времеви печати, преди да го премахнете. Времевият печат по-късно помага да се възстанови ходът; как се прави това, показва [Съставяне на времева линия на инцидент](https://phpsos.de/bg/blog/zeitleiste-eines-vorfalls/). И за евентуално уведомяване на надзорния орган по защита на данните или за застрахователя находката е важно доказателство от кога нападателят е имал достъп.

Само премахването не стига. Ако още работи процес, който пише записа наново, той се връща след следващата минута. А докато първоначалната уязвимост е отворена, нападателят може по всяко време да започне наново. Редът затова е: запазване, затваряне на причината, премахване на всички съставни части, смяна на достъпите, наблюдение.

## Предварителна защита на cron задачите

За да не може изобщо да възникне задна вратичка през cron или за да бие бързо на очи, помагат три мерки. Първо, може да се определи кои потребители изобщо могат да създават crontab. Ако съществува файлът `/etc/cron.allow`, само посочените там потребители могат да ползват `crontab`. Ако Вашето приложение не се нуждае от cron задача под потребителя на уеб сървъра, този потребител не принадлежи в списъка. Проверете предварително какви задачи приложението наистина изисква, и ги създайте съзнателно под собствен потребител.

Второ, наблюдението на файловете си заслужава. Инструмент за проверка на целостта съобщава, щом някой файл в cron директориите или под `/var/spool/cron` се промени. Трето, планираните задачи принадлежат в документацията на сървъра: който знае какви записи трябва да има, разпознава чужд веднага.

## Как помага PHP SOS конкретно?

- **Пълна проверка:** Изследваме всички механизми за планирани задачи, и таймерите на systemd, задачите at и графиците на приложенията.
- **Класифициране на находките:** Оценяваме подозрителните записи, без да ги изпълняваме, и извеждаме други следи.
- **Чисто почистване:** С [премахване на зловреден софтуер](https://phpsos.de/bg/leistungen/malware-entfernung/) отстраняваме всички съставни части и затваряме причината.
- **Разпознаване на връщане:** Настройваме наблюдение, което съобщава за нови или променени планирани задачи.


## Често задавани въпроси

**Защо нападателите ползват cron задачи?**  
Cron задачата стартира команди редовно и без допълнителна намеса. Нападателите зареждат с нея злонамерен код, създават наново изтрити файлове или стартират отново процеси. Така достъпът им преживява актуализация и често дори повърхностно почистване.

**Стига ли crontab -l за проверката?**  
Не. crontab -l показва само crontab на текущия потребител. Планираните задачи стоят освен това в crontab файловете на други потребители, в /etc/crontab, /etc/cron.d, директориите cron.daily, в таймерите на systemd и в задачите at.

**Как да разпозная злонамерена cron задача?**  
Типични са изтегляния от интернет с директно изпълнение, команди с кодирани низове, програми във временни директории, задачи под потребителя на уеб сървъра и записи, които работят всяка минута. Отделният признак е указание, няколко заедно - сериозно подозрение.

**Мога ли просто да изтрия подозрителните cron задачи?**  
Първо запазете, после премахнете. Записът често издава произхода, адреса за зареждане и други съставни части. Без изясняване как е възникнал нападателят често го създава наново.

## Източници

- [BSI: Федерална служба за информационна сигурност на Германия](https://www.bsi.bund.de/)
- [BSI IT-Grundschutz](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/)