Закрепление и его обнаружение

Доступ, который теряется после перезагрузки, бесполезен для атакующего — поэтому он стремится «прописаться» в системе.

Закрепление (persistence) — обеспечение того, чтобы доступ атакующего сохранялся после перезагрузки, выхода пользователя или смены пароля; обычно через встраивание в механизмы автозапуска системы.

Получить доступ — половина дела; удержать его — вторая. Если контроль исчезает при первом ребуте, вся операция рассыпается. Поэтому атакующий ищет место, откуда система сама будет регулярно запускать его код: при загрузке, по расписанию, при входе пользователя. Хорошая новость для защитника: таких мест конечное число, они задокументированы, и почти все они должны меняться редко и предсказуемо. Значит, любое неожиданное изменение там — отличный сигнал тревоги.

Зачем это знать защитнику

Blue Team не обязана угадывать конкретный «зловред». Достаточно знать каталог легитимных точек автозапуска и следить за их изменениями. Это переводит защиту от персистенции из охоты за иголкой в стоге сена в управляемую задачу: знаешь норму — видишь отклонение.

Где обычно закрепляются — карта для проверки

Концептуально это любые механизмы «запусти это автоматически». На что Blue Team смотрит в первую очередь:

Важно: все эти механизмы — штатные и нужные, ими ежедневно пользуются админы. Подозрительной запись делает не сам факт автозапуска, а то, что она появилась вне процесса изменений и ссылается на что-то странное.

Как это проверяет защитник в лаборатории

Аудит автозапуска — это чтение тех самых списков и сравнение с эталоном. В учебной Linux-ВМ:

crontab -l                 # задачи текущего пользователя
ls -la /etc/cron.* /etc/cron.d/   # системные расписания
systemctl list-unit-files --type=service   # службы
ls -la ~/.ssh/authorized_keys     # ключи доступа — не добавлен ли лишний

Те же действия в Windows делают штатные средства аудита и инструменты разбора автозапуска (например, Autoruns из Sysinternals для ручного анализа). Принцип везде один: собрать полный список точек автозапуска и сверить с бейзлайном.

Почему персистенция — это окно возможностей для защиты

Между проникновением и достижением цели атакующий нередко находится в сети неделями — это время называют dwell time. Закрепление как раз и нужно ему, чтобы пережить этот период, и именно оно оставляет долгоживущие артефакты: новую службу, лишнюю задачу, добавленный ключ. Для защитника это шанс: даже если первичное проникновение прошло незамеченным, закладка остаётся в системе и её можно найти при следующей сверке с бейзлайном. Чем короче ваш цикл аудита автозапуска, тем меньше у атакующего dwell time.

Тот же приём «эталон против текущего»

Обнаружение закрепления — это ровно тот же приём сравнения множеств, что и в уроке про привилегии, только применённый к списку служб или задач:

baseline_services = {"sshd", "cron", "systemd-logind"}
current_services  = {"sshd", "cron", "systemd-logind", "update-helper"}
novel = current_services - baseline_services
for name in sorted(novel):
    print("Новая служба, проверить вручную:", name)

Вывод:

Новая служба, проверить вручную: update-helper

Безобидное на вид имя update-helper — отличная иллюстрация: вредонос маскируется под штатное, и единственная защита здесь — знать, что в эталоне такой службы не было. Сравнение не доказывает злой умысел, но даёт точную точку для ручной проверки.

Как это работает под капотом

Любое закрепление эксплуатирует доверие ОС к собственным механизмам запуска: система не спрашивает «а законна ли эта задача?», она просто исполняет то, что записано в положенном месте. Атакующий ничего не «взламывает» — он добавляет валидную с точки зрения ОС запись. Поэтому защита строится не на запрете автозапуска (он необходим), а на контроле целостности и изменений: фиксируем эталонное состояние и ловим всякое отклонение от него.

Как защититься

• Бейзлайны. Зафиксируйте эталон «чистой» системы: какие службы, задачи, автозагрузки и аккаунты должны быть. Без эталона невозможно отличить норму от закладки.
• Аудит автозапуска. Регулярно (а лучше автоматически) сверяйте текущее состояние точек автозапуска с бейзлайном. Включите аудит создания служб, задач планировщика и изменений ключей реестра.
• EDR. Endpoint Detection and Response отслеживает поведение на хостах в реальном времени: создание служб, модификацию автозагрузки, появление новых аккаунтов, подозрительные родительско-дочерние цепочки процессов — и поднимает тревогу.
• Контроль изменений. Любое легитимное изменение служб и задач проходит через процесс (заявка, IaC, журнал). Тогда всё, что появилось вне процесса, по определению подозрительно.
• Контроль целостности и гигиена аккаунтов. Мониторьте изменения системных файлов (FIM), регулярно ревизуйте список пользователей и ключи доступа, удаляйте лишнее.
• Threat hunting. Периодически проактивно ищите аномалии в автозапуске, не дожидаясь срабатывания правил, — особенно редкие и «одиночные» записи на отдельных хостах.

Юридическое напоминание: создавать и исследовать механизмы закрепления допустимо только на своих системах и в учебных лабораториях. Установка вредоносного ПО и скрытных закладок в чужие системы наказуема (УК РФ ст. 273).

Итоги

• Закрепление сохраняет доступ после перезагрузки через штатные механизмы автозапуска.
• Таких точек конечное число и они задокументированы — это превращает защиту в проверяемый чек-лист.
• Подозрительно не наличие автозапуска, а его изменение вне процесса; основа детекта — бейзлайн и сравнение с ним.
• Инструменты Blue Team: бейзлайны, аудит автозапуска, EDR, контроль изменений и целостности, проактивный threat hunting.