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

Кратко

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

Главное

• Исходный тезис: даже полный арсенал защиты (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%».
• «…в рамках сбора волатильных данных мы ни при каких обстоятельствах, ни в коем случае не используем команды записи».