Как сохранить метаданные подозрительного файла при анализе: практические методы и инструменты

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

Какие метаданные критичны и почему они меняются

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

• Хеш-суммы (MD5, SHA-1, SHA-256) — эталон целостности. Изменение хотя бы одного бита (в том числе атрибутов или альтернативных потоков данных) даст другой хеш.
• Таймстемпы файловой системы — Created, Modified, Accessed (MACE в NTFS; birth/time/ctime/mtime/atime в *nix). Простое копирование через Explorer или cp обновляет Accessed и часто Modified.
• Атрибуты и разрешения — Read-only, Hidden, System, ACL, extended attributes (xattr), альтернативные потоки данных (ADS в NTFS).
• Внутренние метаданные формата — заголовки PE (TimeDateStamp), EXIF в изображениях, свойства Office-документов, метаданные PDF. Они не меняются при копировании, но меняются при открытии редакторами.
• Zone.Identifier (Mark of the Web) — ADS, указывающий зону происхождения файла (Internet, Intranet, Local). Критичен для расследования вектора заражения. Удаляется при копировании на FAT/exFAT, архивации некоторыми архиваторами, отправкой через мессенджеры.

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

Базовая процедура: от изъятия к рабочей копии

Алгоритм действий одинаков для любого сценария — инцидент-респонс, маловэр-анализ, судебная экспертиза. Отклонения допустимы только при документированном обосновании.

1. Физический изъятие носителя (диск, флешка, телефон) с документированием: фото, серийные номера, пломбирование, протокол. Если носитель в работе — образ диска (dd/ewf) с write-blocker.
2. Расчёт эталонных хешей исходного файла на месте — до любых манипуляций. Используйте инструменты, не требующие монтирования ФС в режиме записи (см. раздел инструментов).
3. Создание форензической копии (bit-for-bit) — образа файла или всего раздела с сохранением разреженных областей, ADS, xattr, ACL.
4. Верификация копии — побайтовое сравнение и совпадение хешей.
5. Работа только с копией. Исходник упаковывается в антистатический пакет, пломбируется, хранится в сейфе.

Если файл уже скопирован «как попало» — считайте метаданные ФС потерянными. Внутренние метаданные формата и хеш контента могут быть целы — проверьте их.

Инструменты для безопасного доступа и копирования

Выбор инструмента зависит от ОС аналитика, ФС носителя и наличия аппаратного write-blocker’а.

Аппаратные write-blocker’ы (рекомендуется для судебных целей)

• Tableau, WiebeTech, CRU, Addonics — блокируют команды записи на уровне контроллера SATA/USB/NVMe. Работают прозрачно для ОС.
• Перед подключением носителя к рабочей станции — всегда через блокер. Проверяйте индикатор «Write Blocked».

Программные методы (если нет блокера или для быстрой триажи)

Задача	Windows	Linux / macOS
Расчёт хеша без изменения atime	certutil -hashfile SHA256 Get-FileHash -Algorithm SHA256 (PowerShell) HashCheck (Explorer extension, только чтение)	sha256sum openssl dgst -sha256 xxhsum (быстрее на больших файлах)
Копирование с сохранением всех атрибутов, ADS, xattr, ACL, sparse	robocopy /COPY:DATSOU /B /R:0 /W:0 src dst /B — backup mode (требует SeBackupPrivilege), сохраняет ADS, ACL, Owner, Audit FTK Imager (GUI/CLI) — создаёт E01/RAW образ файла или раздела	cp —preserve=all —sparse=always src dst rsync -aAXHS —sparse src dst dd if=src of=dst bs=64K conv=noerror,sync (для образов разделов) dcfldd / dc3dd — расширенные версии dd с хешированием на лету
Монтирование образа/раздела только для чтения	Arsenal Image Mounter (монтирует E01/RAW/dd как readonly) OSFMount (readonly флаг) diskpart → select volume → attributes volume set readonly	mount -o ro,loop,noexec,nodev,nosuid image.dd /mnt/analysis losetup -r /dev/loop0 image.dd
Просмотр внутренних метаданных без запуска файла	PE-bear, CFF Explorer, Detect It Easy (PE) ExifTool (универсальный) olevba, oledump (Office) pdfid, pdf-parser (PDF)	ExifTool (perl, кроссплатформенно) pefile (python), lief (C++/python) oletools (python) pdfid.py, pdf-parser.py

Важно: стандартные cp, copy, drag-and-drop в Explorer/Finder/Nautilus не сохраняют ADS, xattr, ACL, sparse-флаги, birth-time (в старых ФС). Используйте только флаги сохранения атрибутов или специализированные инструменты.

Сценарии работы по ОС: нюансы и ловушки

Windows (NTFS, ReFS, FAT32/exFAT)

• ADS (Zone.Identifier, скрытые данные) — копируются только robocopy /B, FTK Imager, raw-образ раздела. На FAT/exFAT ADS теряются безвозвратно — документируйте это.
• Timestamps — NTFS хранит 100-наносекундную точность с 1601 года. Explorer показывает локальное время, но в MFT — UTC. При копировании на другую ФС точность может усечься до секунд (FAT) или измениться часовой пояс.
• USN Journal / $LogFile — системные журналы изменений. Не копируются на уровне файла, нужны образ раздела.
• PowerShell Get-Item -Stream * — покажет все ADS. Get-Content -Path file -Stream Zone.Identifier — прочитает Mark of the Web без изменения atime.

Linux (ext4, xfs, btrfs, f2fs)

• birth time (crtime) — поддерживается ext4 (с kernel 4.11+), xfs, btrfs. statx() или stat -c ‘%w’ (coreutils 8.31+). Старые инструменты (stat, ls) показывают только ctime (изменение inode), а не создание.
• xattr — расширенные атрибуты (security.selinux, user.*, trusted.*). Копируются cp —preserve=xattr или rsync -X. tar по умолчанию не сохраняет xattr — нужен —xattrs.
• ACL — getfacl/setfacl. Сохраняются cp —preserve=mode,ownership + rsync -A.
• Sparse files — cp —sparse=always или fallocate -d для проверки дыр.

macOS (APFS, HFS+)

• Extended attributes (xattr) — ком.apple.quarantine (Gatekeeper), com.apple.metadata:kMDItemWhereFroms (URL источника), com.apple.lastuseddate. Критичны для расследования. Просмотр: xattr -l file. Копирование: cp -p (preserves xattr), rsync -X, ditto.
• Resource forks — устарело, но встречается в старых файлах. cp -p и ditto сохраняют.
• APFS clones/snapshots — копирование на той же ФС может создать clone (общие блоки). Для форензики нужна физическая копия — cp -c (copyfile) или образ через dd/asr.
• Timestamps — APFS наносекундная точность, birth time нативен. stat -f ‘%SB %Sm %Sa %Sc’.

Работа в изолированной среде: песочницы и ВМ

Запуск подозрительного файла — отдельная задача. Здесь метаданные хоста не должны «утекать» в гость, а действия гостя не должны менять исходник.

• Снимок (snapshot) ВМ до запуска — обязателен. Возврат к чистому состоянию за секунды.
• Shared folders / drag-and-drop / clipboard — отключены. Файл передаётся в гость только через изолированный канал: монтирование readonly ISO, сетевой share (SMB readonly), копирование внутри гостя из образа диска.
• Сетевая изоляция — хост-онли или полностью изолированная виртуальная сеть с имитацией интернета (INetSim, FakeNet-NG). Никакого доступа к корпоративной сети.
• Анти-эвазию — проверяйте, не детектирует ли малварь артефакты ВМ (MAC-адреса VMware/VirtualBox, CPUID, наличие инструментов гостя). Используйте скрипты скрытия (например, для VMware — настройки .vmx: monitor_control.restrict_backdoor = «TRUE», isolation.tools.getPtrLocation.disable = «TRUE» и т.д.).
• Логирование поведения — Procmon, Process Hacker, Sysmon (внутри гостя), strace/ltrace/bpftrace (Linux), DTrace (macOS), API-мониторы (API Monitor, Frida). Логи сохраняются на виртуальный диск, который потом извлекается как образ.

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

Верификация целостности: контрольные точки

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

1. H0 — хеш файла на исходном носителе (через write-blocker или read-only монтирование).
2. H1 — хеш созданного образа/копии (E01, raw, файл). Должен совпадать с H0.
3. H2 — хеш рабочей копии, переданной в песочницу/эксперту. Должен совпадать с H1.
4. H3 — хеш файла после извлечения из песочницы (если файл не должен меняться). Должен совпадать с H2.

Используйте один алгоритм (SHA-256 — стандарт де-факто) и один инструмент на всех этапах — разные реализации могут давать разные результаты для файлов с ошибками структуры (например, обрезанные PE).

Для больших объёмов: xxh128 или blake3 — в 10-50 раз быстрее SHA-256 на современных CPU, криптографически стойкие, поддерживаются современными инструментами (xxhsum, b3sum, hashcat). Документируйте алгоритм в протоколе.

Типичные ошибки и как их избежать

Ошибка	Что ломается	Правильная альтернатива
Копирование через Explorer / Finder / Nautilus drag-and-drop	atime, mtime, ADS, xattr, ACL, Zone.Identifier, sparse	robocopy /B /COPY:DATSOU / cp —preserve=all / rsync -aAXHS / FTK Imager
Открытие файла «посмотреть» в блокноте, Word, просмотрщике фото	atime, внутренние метаданные (LastPrinted, LastAuthor), возможное выполнение макросов/эксплойтов	Статический анализ: strings, ExifTool, PE-bear, olevba, pdfid — без запуска приложений
Архивация обычным zip/rar/7z без флагов	ADS, xattr, ACL, timestamps (зависят от архиватора), sparse	7z a -mx=0 -mtc=on -mta=on (хранит timestamps, attributes), но лучше — raw-образ (dd/E01) или tar —xattrs —acls
Копирование на FAT32/exFAT/NTFS без проверки поддержки атрибутов	Потеря ADS, xattr, точности таймстемпов, ACL	Целевая ФС должна поддерживать нужные атрибуты. Для переноса — только контейнеры (E01, zip с флагами, tar) или образ раздела
Расчёт хеша после копирования, а не до	Нет эталлона для сравнения — неизвестно, изменился ли файл при копировании	Хеш считается на источнике первой операцией. Протокол: «H0 = SHA256(source) = 0x…»
Использование монтирования в режиме RW для «быстрого просмотра»	ФС обновляет atime, журнал, может триггерить автозапуск/индексацию	Только readonly монтирование. В Windows: diskpart → attributes volume set readonly. В Linux: mount -o ro,noexec,nodev,nosuid
Передача файла коллеге через мессенджер/почту/облако	Стриппинг ADS, Zone.Identifier, сжатие, рекодинг, изменение таймстемпов	Передача только верифицированного контейнера (E01, password-protected 7z с сохранением атрибутов) через защищённый канал. Или физический носитель с цепочкой сохранности

Документирование и цепочка сохранности (Chain of Custody)

Для судебной применимости или внутреннего аудита каждое действие логируется:

• Кто, когда, где, с какого носителя изъял.
• Серийные номера оборудования (write-blocker, рабочая станция, носители).
• Команды с параметрами и их вывод (хеши, размеры, ошибки чтения).
• Хеши на каждой контрольной точке (H0–H3).
• Хранение исходника: пломба №, сейф, температурный режим (если актуально для SSD/HDD).
• Доступ к рабочей копии: кто, когда, для какой задачи.

Минимальный протокол — текстовый файл с подписью аналитика (PGP/GPG или ЭЦП). В корпоративном IR — в системе тикетов с неизменяемой историей.

Чек-лист перед началом анализа

• [ ] Наличие аппаратного write-blocker’а или подтверждённого readonly-монтирования.
• [ ] Расчёт и запись H0 (SHA-256) исходного файла на месте.
• [ ] Создание форензической копии (E01/raw/файл с сохранением всех атрибутов).
• [ ] Верификация копии: побайтовое сравнение + совпадение хеша (H1 == H0).
• [ ] Исходник пломбирован, убран в хранилище.
• [ ] Рабочая станция/ВМ изолирована от сети (или в выделенном сегменте IR).
• [ ] Снапшот чистой ВМ сделан до передачи файла.
• [ ] Файл передан в гость через readonly-канал (ISO, readonly share, образ диска).
• [ ] Инструменты статического анализа установлены и проверены (ExifTool, PE-bear, olevba, pdfid, strings).
• [ ] Протокол ведения цепочки сохранности открыт и ведётся параллельно.

Когда метаданные уже потеряны: что ещё можно спасти

Если файл пришёл уже «грязным» (пересылали через почту, копировали через Explorer, загружали в облако):

• Хеш контента — если тело файла не менялось, SHA-256 совпадёт с оригиналом. Проверьте по VirusTotal / внутренней базе IOC.
• Внутренние метаданные формата — PE TimeDateStamp, EXIF, Office core.xml/app.xml, PDF CreationDate/ModDate — часто выживают при копировании. Извлеките ExifTool / olevba / pdf-parser.
• Zone.Identifier — если файл скачивали через браузер и сразу архивировали 7z с флагами -mtc=on -mta=on — ADS может сохраниться внутри архива. Распакуйте 7z x -t7z archive.7z и проверьте Get-Content -Stream Zone.Identifier.
• Файловые системы с журналированием — иногда удалённые/изменённые файлы восстанавливаются через $MFT (NTFS), ext4 journal, APFS snapshots. Нужен образ раздела, не файла.

Документируйте: «Метаданные ФС недостоверны из-за предварительной обработки. Анализ основан на внутренних метаданных и хеше контента».

Практический следующий шаг

Начните с создания «чистого» рабочего места: выделенная станция (или ВМ) с установленным набором инструментов (FTK Imager, robocopy, ExifTool, PE-bear, 7z, xxhsum, Arsenal Image Mounter), отключённым автозапуском, индексацией, антивирусом (или в пассивном режиме). Прогоните процедуру на тестовом файле с известными ADS, xattr, sparse-областями — проверьте, что хеш и атрибуты проходят сквозь ваш пайплайн без изменений. Только после этого берите реальный подозрительный файл.

Главное правило: любое действие, которое вы не можете повторить и задокументировать с тем же результатом — недопустимо. Если сомневаетесь — сделайте образ раздела и работайте с образом.

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