Что было. На сервере нашли майнер, замаскированный под системную утилиту в каталоге root (/root/system-check/systemx86), с подключением к пулу через порт 443. Процесс убили, файлы удалили. Через сутки заражение повторилось, причём загрузчик поменялся (сначала curl, потом wget с публичного хостинга кода). Отдельно нашли пустой файл в cron с атрибутом «неизменяемый», который после удаления появлялся снова.
Что это означает. У вредоносного ПО было как минимум два механизма закрепления: явный (майнер и его запуск) и скрытый «охранник», который следит за наличием первого и восстанавливает его. Пустой cron-файл с chattr +i это типичный след такого охранника: он резервирует место и защищает его от удаления. Пока охранник жив, чистка бесполезна. Автор публикации разбирал, откуда мог прийти запуск от root: подозрение пало на долгоживущую сессию инструмента автоматизации с правами root без журнала выполненных команд.
Как искать охранника.
lsattr -R /etc/cron* /var/spool/cron /etc/systemd/system /root /tmp 2>/dev/null | grep -- '-i-'
systemctl list-units --type=service --state=running | grep -viE 'ssh|cron|rsyslog|systemd|dbus|network'
systemctl list-timers --all
ls -la /etc/ld.so.preload /etc/rc.local /etc/init.d 2>/dev/null
ps -eo pid,ppid,user,etime,cmd --sort=etime | head -40 # старые процессы с непонятными именами
ss -ntup | grep -v ':22 ' # исходящие соединения
find / -xdev -newer /etc/hostname -type f -perm -u+x 2>/dev/null | grep -vE '^/(usr|proc|sys)' # свежие исполняемые
chattr -i перед удалением; проверить /etc/ld.so.preload (подмена библиотек скрывает процессы от ps).
Как искать точку входа. Журналы входов: last -a, journalctl _COMM=sshd | grep Accepted (какие ключи и откуда), ~/.ssh/authorized_keys у всех пользователей (лишние ключи), история команд (~/.bash_history, journalctl от сервисов), веб-логи на подозрительные POST, открытые наружу службы (ss -ltnp). В обсуждаемом случае вход был не через взлом службы, а через уже имеющиеся права: сессия с root, в которой команды выполнялись без контроля. Отсюда правило: любой инструмент, который выполняет команды от root (агенты автоматизации, панели, ИИ-помощники в терминале), должен работать под ограниченной учётной записью с sudo на конкретные команды и с журналом.
Что делать после находки. Как и в остальных разборах о заражениях: образ диска для разбора, вынос данных, переустановка из чистого образа, ротация всех ключей и паролей, которые были на машине, закрытие точки входа, и только потом возвращение в работу. Чистка «на месте» уместна лишь когда точно известны и точка входа, и все механизмы закрепления, что бывает редко.
Атрибуты файлов описаны в документации Ubuntu.