# Исследование электронных носителей информации при недоступности средств защиты информации

Юрий Павенский · независимый эксперт

MOSCOW FORENSICS DAY ’26 · День 2 — пятница, 4 сентября 2026 · По программе 13:10–13:40 · В записи 04:09:13–04:46:57 (запись обрывается на полуслове)

Саммари выступления · https://2026.moscow-forensics-day.workers.dev/summary/10-pavensky
Расшифровка: https://2026.moscow-forensics-day.workers.dev/transcript/10-pavensky · Слайды: https://2026.moscow-forensics-day.workers.dev/slides/09-unavailable-security-tools · Смотреть с 04:09:13: https://youtu.be/WuMIv5sFPRs?t=14953

---

## Кратко

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

## Главное

- Исходный тезис: даже полный арсенал защиты (SIEM, EDR, DLP, TI, WAF, NGFW, антивирусы, в том числе сертифицированные), регулярные пентесты, учения и проверки регуляторов «ни при каких условиях не гарантируют», что при серьёзной атаке у вас останется доступ к самим средствам защиты и их телеметрии.
- **Кейс, шаг 1**: в открытом доступе оказалась база интернет-магазина с персональными данными, почтами и паролями. Среди пострадавших — сотрудник разработчика известной IDM-системы, использовавший в качестве логина личный адрес почты.
- **Шаг 2**: по найденному паролю получен доступ к личной почте и облачному сервису этого сотрудника; по открытым источникам установлены его дополнительные адреса, корпоративная почта, должность и организация.
- **Шаг 3**: из содержимого почты и облака извлечены сведения об организациях-заказчиках, о привилегированных учётных записях AD, об используемых хостах и способах удалённого подключения.
- **Шаг 4**: злоумышленники продолжили переписку с одним из заказчиков и под предлогом дополнительных работ получили удалённый доступ к джамп-хосту. Первую неделю «себя вели, словно они действительно являются подрядчиком», затем начали собирать данные о доменной инфраструктуре, сетевой архитектуре, учётных записях и правах, критичных серверах и базах.
- **Шаг 5**: компрометация учётных записей AD, использование привилегированных и сервисных учёток, устойчивое присутствие в инфраструктуре; выгрузка баз с данными о финансах, работниках, клиентах и логистике.
- **Шаг 6**, отдельно показательный: на рабочем месте сотрудника ИТ-подразделения нашлась незашифрованная резервная копия его личного телефона. Из неё достали фотографии конфиденциальных документов, переписку с учётными данными, переданными подрядчику, схемы организации связи и учётные записи из заметок.
- **Шаг 7, деструктив**: уничтожены резервные копии серверов, удалены конфигурационные файлы коммутаторов уровня ядра и другого сетевого оборудования, изменены конфигурации коммутаторов ядра.
- Последствия: сеть потеряла связность, деградировала доменная среда, пропал штатный доступ к средствам защиты и появились централизованные ограничения телеметрии. Ключевая фраза: на этом этапе «оперативная реконструкция атаки штатными средствами уже не представлялась возможной».
- Параллельно сменены пароли к базам данных, после чего базы зашифрованы.
- **Вымогательство**: контакт с сотрудником ИТ через мессенджер, требование выкупа, угроза опубликовать захваченную резервную копию его личного телефона; для подтверждения серьёзности фрагмент данных действительно опубликован в открытом канале.
- Выводы по кейсу: компрометация одного личного аккаунта способна привести к инциденту такого масштаба; удалённый доступ подрядчиков без контроля — высокий риск; хранение конфиденциального на личных устройствах и в их резервных копиях бьёт и по компании, и по самому работнику.
- Главный вывод доклада: когда доступа к привычным средствам защиты нет, «единственным ключевым инструментом для восстановления полной картины инцидента является исключительно компьютерная криминалистика».
- Важная поправка к восприятию: всю цепочку видит только зритель презентации. У службы ИБ в момент выявления есть лишь неработающая сеть, сбои узлов и баз, сообщение от злоумышленника и опубликованный фрагмент данных.
- Процесс реагирования разбит на 10 взаимосвязанных этапов — от фиксации первичного сообщения и предварительной оценки масштаба до реконструкции атаки, восстановления инфраструктуры и закрытия инцидента. Подробный документ «Общий порядок реагирования» выложен по QR-коду, который висит на всех последующих слайдах.
- **Логика по узлам**: универсального правила нет — ни «немедленно изолировать все хосты», ни «снять всё со всех». Правила должны быть «гибкими и некатегоричными».
- Почему не изолировать всё: выжившая после инцидента система может сломаться именно из-за изоляции (особенно база данных, в которую в этот момент что-то писалось), и есть риск «бездумно потерять необходимые артефакты».
- Почему не снимать всё: при 2, 10 или 100 тысячах хостов «мы будем собирать информацию до тех пор, пока компания наша не закроется в связи с этим инцидентом».
- **Алгоритм принятия решения**: оценить связь узла с инцидентом → продолжается ли ущерб на хосте или через него, есть ли подозрительные сетевые соединения → сохранился ли сетевой доступ к живым системам (даже в мёртвой сети хост в одном VLAN с ними может сохранять связь) → учесть технические ограничения.
- Про технические ограничения отдельно: нестабильная машина может окончательно упасть от неаккуратного сбора, а у сетевого оборудования одного вендора на одной и той же ОС набор команд и их влияние на устройство различаются от модели к модели.
- **Случай 1**: узел связан с инцидентом, но ущерб не продолжается, подозрительных соединений нет и сетевого пути к ресурсам нет — изолировать не надо, «хост, по сути, и так уже изолирован». Снять волатильные данные и до получения постоянных данных не трогать вообще.
- **Случай 2**: идёт активное шифрование, изменение, удаление или копирование данных. Изоляция всё равно не автоматическое решение: на критичном узле обрыв соединения может оставить операцию незавершённой, и «сама база данных может отъехать», а восстановить её при уничтоженных резервных копиях уже проблематично. Если понятно, что две минуты ничего катастрофического не произойдёт, — сначала собрать волатильные данные, потому что при изоляции их потеря гарантирована.
- Вручную это не делается: на Linux речь о «порядка 67 и более команд», в две минуты не уложиться. Нужен автоматизированный скрипт — по QR-коду выложены и полные перечни команд для Windows, macOS и Linux, и готовые скрипты, которые за пару минут выгружают данные и формируют отчёт.
- **Случай 3**: узел не связан с инцидентом — не трогать вовсе. **Случай 4**: узел выключен — не включать и не загружать установленную ОС, иначе изменятся постоянные данные.
- **Виртуальные машины**: если есть техническая возможность и уверенность, что гипервизор не внесёт недопустимых изменений в данные гостевой системы, делается моментальный снимок с сохранением оперативной памяти — и до нажатия этой кнопки на машине не делать ничего.
- Как добраться до гипервизора в мёртвой сети: если серверы не на аутсорсе, взять недоменный ноутбук и подключиться к SAN-свитчу или напрямую к management-порту оборудования.
- **Очередность волатильного сбора.** Интересует не всё содержимое носителя, а то, что может измениться или исчезнуть из-за работы ОС, действий злоумышленника или самой изоляции. Сначала базовое об узле: имя хоста, текущая учётная запись, версия ОС или ядра, системные дата, время и часовой пояс, время от независимого источника с фиксацией расхождений, время непрерывной работы с момента загрузки.
- Затем пользовательская активность: активные пользователи и сеансы, кэшированные данные аутентификации текущих сеансов, выполняющиеся процессы и сервисы с параметрами запуска, открытые файлы.
- Затем локальные журналы с высоким риском перезаписи — да, они лежат в постоянной памяти, но пока идёт сбор, часть записей может затереться. Выгружать не всё: журналы бывают «вообще терабайтами», достаточно последних суток.
- Конкретные журналы: для Windows — System, Security, WinRM Operational, журналы терминальных служб, OpenSSH Operational и, «самое главное», оба журнала PowerShell; для Linux — syslog, audit, secure, kern, messages, daemon, журналы xrdp и auth; для macOS — syslog и Unified.
- Дальше — загруженные драйверы и модули ядра, активные средства межпроцессного взаимодействия и сетевое состояние узла: интерфейсы, установленные соединения, слушающие порты, таблица маршрутизации, соседние узлы по ARP и NDP.
- Жёсткое правило хранения: собранное «ни в коем случае» не сохраняется на постоянный носитель исследуемого узла — только на внешний носитель или в изолированное хранилище, независимое от корпоративной сети.
- **Сетевое оборудование.** Потеря связности сама по себе не означает компрометацию: это может быть технический сбой (случается часто), ошибки ИТ-специалистов при настройке — или действительно злоумышленник, как в разбираемом кейсе.
- Подключаться — с автономного недоменного ноутбука консольным кабелем. Перед установкой сессии обязательно включить запись терминальной сессии и зафиксировать время от независимого источника.
- Первая команда после входа — просмотр истории командной оболочки для всех пользователей: дальнейшие команды вытеснят старые записи. Затем — имя хоста, учётная запись, дата, время, часовой пояс и отклонение от независимого источника, время работы, версия ОС, локальные журналы, административные сеансы, сетевые маршруты и остатки в оперативных таблицах.
- Категорический запрет: никаких команд записи. Только заранее проверенные команды, у которых понятен и результат, и нагрузка на устройство. Любое подключение и даже команда просмотра отражается на истории оболочки, локальных журналах и системах AAA и может кратковременно поднять нагрузку. Сбор — тоже скриптом, одна-две минуты.
- **Постоянные данные**: задача — получить копию, происхождение и целостность которой можно проверить позже. Для этого фиксируются источник данных, способ извлечения, средство и его версия, место сохранения результата, время операции и рассчитываются контрольные суммы. На этой фразе запись обрывается.

## Инструменты, артефакты, технологии

- **Средства защиты, упомянутые как фон**: SIEM, EDR, DLP, TI, WAF, NGFW, антивирусное ПО.
- **Атака**: утёкшая база с логинами-почтами, доступ к личной почте и облаку, OSINT-обогащение, джамп-хост, привилегированные и сервисные учётные записи AD, незашифрованная резервная копия личного телефона на рабочем месте, уничтожение резервных копий и конфигураций коммутаторов ядра, шифрование баз, вымогательство через мессенджер и публикация фрагмента данных.
- **Волатильные данные хоста**: базовая информация об узле и времени, активные сеансы, кэш аутентификации, процессы и сервисы, открытые файлы, локальные журналы (**System**, **Security**, **WinRM Operational**, журналы терминальных служб, **OpenSSH Operational**, **Windows PowerShell** и **PowerShell Operational**; **syslog**, **audit**, **secure**, **kern**, **messages**, **daemon**, **xrdp**, **auth**; **syslog** и **Unified** в macOS), драйверы и модули ядра, межпроцессное взаимодействие, сетевое состояние (интерфейсы, соединения, порты, маршруты, **ARP**/**NDP**).
- **Сетевое оборудование**: консольный кабель и недоменный ноутбук, запись терминальной сессии, история командной оболочки, оперативные таблицы, системы **AAA**; замечание о различиях команд между моделями одного вендора.
- **Виртуализация**: моментальный снимок с памятью, доступ к гипервизору через SAN-свитч или management-порт.
- **Материалы автора** по QR-коду: документ «Общий порядок реагирования», перечни команд по операционным системам и автоматизированные скрипты сбора (в том числе PowerShell).

## Правовой и организационный контекст

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

## Вопросы из зала

Вопросов в записи нет: трансляция обрывается на полуслове в разделе о постоянных данных, поэтому финал доклада и возможное обсуждение в запись не попали.

## Позиция спикера

Методичный доклад практика, построенный не на инструментах, а на решениях: главный посыл — не действовать по шаблону «изолируй всё» или «сними всё», а каждый раз оценивать связь узла с инцидентом, продолжающийся ущерб и технические риски. Ограничения проговариваются последовательно: изоляция уничтожает волатильные данные, неаккуратный сбор роняет нестабильную машину, команда просмотра на коммутаторе всё равно меняет состояние устройства. Тон подчёркнуто осторожный, с оговорками «я бы не стал», «это философский вопрос». Практическая часть завязана на материалы по QR-коду — в самой записи ни скриптов, ни перечней команд полностью не показано.

## Цитаты

- «…какая бы ни была у вас на практике современная и сильная система информационной безопасности, она ни при каких условиях не гарантирует, что… у вас непременно сохранится доступ к привычным вам средствам защиты информации и их телеметрии».
- «…единственным ключевым инструментом для восстановления полной картины инцидента является исключительно компьютерная криминалистика».
- «Я боюсь, мы будем собирать информацию до тех пор, пока компания наша не закроется в связи с этим инцидентом».
- «…если мы осуществим с вами сетевую изоляцию, мы потеряем с вами огромное количество таких артефактов. Это 100%».
- «…в рамках сбора волатильных данных мы ни при каких обстоятельствах, ни в коем случае не используем команды записи».