Наверняка каждый из вас сталкивался с похожей ситуацией: ищешь вещь, уверен, что она лежит где-то рядом, а находишь совсем в другом месте. Как будто обронили винтик под ноги, а он взял и перекатился через всю комнату. В этом блоге я — Андрей Кравцов, специалист по реагированию на инциденты и цифровой криминалистике компании F6, — хочу рассказать о похожем опыте — поиске временных меток в файле с расширением DOCX. И поделюсь своим способом решения подобной задачи на примере воссозданной ситуации в виртуальной машине.
Итак, представьте: в процессе ревизии финансово-экономической деятельности одной российской компании проверяющий обнаружил несоответствие в документации сотрудника. Были представлены две версии его должностной инструкции, одна из которых содержала положения, противоречащие действующему законодательству России. Это обстоятельство потребовало установить дату и время последней модификации электронного файла и дату его последнего вывода на печать.
В результате внутреннего расследования был установлен персональный компьютер, на котором были созданы, редактировались, а затем и печатались найденные документы. Так ко мне на исследование попал системный блок, в котором был установлен один накопитель информации на жестких магнитных дисках (далее – НЖМД). После создания криминалистической копии НЖМД я приступил к предварительному анализу хранящейся в его памяти информации.
Пользователь с правами
Предварительный анализ показал, что на рабочем месте использовались операционная система «Microsoft Windows 10», офисный пакет «Microsoft Office», а также был зарегистрирован один локальный пользователь с правами администратора. Эти данные позволили мне определиться с тактикой исследования.
Установленные даты и время инсталляции операционной системы и офисного пакета предшествовали дате подписания должностных инструкций. Это обстоятельство позволяло предположить, что значимые для исследования данные в операционной и файловой системах не были удалены.
В начале было решено проанализировать файловую систему «NTFS», которая является основной для последних версий Windows. Согласно её спецификации, метаданные файлов хранятся в файле с именем "$MFT", среди которых есть важные временные метки. Для его анализа применялась утилита "MFTExplorer".
Анализ файловой системы показал, что атрибуты файла «$STANDARD INFORMATION» и «$FILE_NAME» идентичны и не вызывают каких-либо подозрений
(см. Иллюстрации 1, 2). Дополнительно был проанализирован USN Journal, который регистрирует изменения в томах NTFS и ReFS. Этот журнал содержал множественные изменения, связанные с файлом, которые не выходили за рамки временных меток, указанных в метаданных файла, но их количество вызвало у меня подозрения (см. Иллюстрации 3).
Должностные инструкции были сохранены в документе с расширением «DOCX». Как известно, это расширение связано с форматом файла, разработанным компанией Microsoft для текстовых документов, используемых в приложении Microsoft Word, которое было представлено 2007 году с выходом Microsoft Office 2007 на основе стандарта Office Open XML.
Одним из свойств документов, основанных на стандарте Office Open XML, является возможность хранения расширенных метаданных, которые образуются в результате работы с документом. В данном случае меня интересовал файл «core.xml», содержащий метаданные, указанные в таблице №1.
Таблица №1. Сведения о метаданных в файле «core.xml»
№ | Свойство | Описание |
1 | category | Категоризация содержимого этого |
2 | contentStatus | Статус контента |
3 | created | Дата создания содержимого |
4 | creator | Автор, содержимого |
5 | description | Объяснение содержания ресурса |
6 | identifier | Однозначная ссылка на ресурс в данном контексте |
7 | keywords | Ключевые слова для поиска и индексации. |
8 | language | Язык интеллектуального содержания ресурса |
9 | lastModifiedBy | Пользователь, выполнивший последнюю модификацию |
10 | lastPrinted | Дата и время последней печати |
11 | modified | Дата изменения содержимого |
12 | revision | Номер ревизии |
13 | subject | Тематика содержания ресурса |
14 | title | Имя, данное ресурсу |
15 | version | Номер версии |
Как видно из таблицы, в файле «core.xml» есть теги «created», «modified», «lastPrinted», которые содержат интересующие сведения. Эти сведения просматриваются штатными средствами проводника через меню «Свойства-> Подробно» (см. Иллюстрацию 4.)
Просмотрев эти метаданные, я насторожился: поле «Авторы» было пустым, так как при создании документа это поле заполняется автоматически значением расположенным в «\Software\Microsoft\Office\Common\UserInfo» из куста реестра «NTUSER.DAT». Дальше воспользовавшись утилитой «RegistryExplorer», я увидел, что поле «UserName» заполнено (см. Иллюстрацию 5).
Ответы на поверхности
Обнаруженные сведения подвели меня к мысли, что метаданные файла редактировались не известным мне способом. Эта мысль не давала покоя и заставляла неоднократно изучать спецификацию стандарта Office Open XML в надежде найти какие-либо зацепки, которые позволили бы определить способ редактирования метаданных.
Но как обычно бывает, все ответы оказались на поверхности, просто надо было посмотреть под другим углом. Я пытался найти следы в файлах, из которых состоит документ, а надо было копнуть немного глубже. В той же спецификации указывалось, что документ, основанный на стандарте Office Open XML, является обычным ZIP-архивом.
ZIP - это формат сжатия и архивирования данных, который широко используется для упаковки файлов и папок в один архив с возможностью сжатия для экономии пространства. В спецификации ZIP-архива указано, что этот файл состоит из нескольких основных блоков: заголовок локального файла (Local File Header), данные файла (File Data), центральный заголовок файла (Central Directory File Header), конец центрального заголовка (End of Central Directory Record) (см. Иллюстрацию 6). Также в спецификации указано, что блок Local File Header для каждого файла в архиве, содержит время и дату последнего изменения файла. Стоит отметить, что по умолчанию датой и временем последнего изменения файла в ZIP-архиве всегда указывается 01.01.1980 00:00:00.
Написав небольшой скрипт на Python, я получил список всех файлов и их метаданных, которые хранились в исследуемом файле. Результат работы был неожиданным, так как один из файлов, а именно файл «core.xml» имел дату, отличную от даты по умолчанию. Обнаруженные сведения указывали на то, что метаданные о датах и времени создания содержимого, последней печати и изменения содержимого редактировались в самом файле «core.xml» (см. Иллюстрацию 7). Кстати, после написания скрипта я понял, что это можно было сделать с помощью «7zip», но с поправкой на часовые пояса.
После всех найденных следов оставалось установить реальную дату изменения метаданных. Проверив журнал регистрации событий «System.evtx», я обнаружил событие (event id = 1) о смене системного времени (см. Иллюстрацию 8).
Таким образом, исходя из собранных сведений, был сделан вывод о том, что должностные инструкции редактировались незадолго до начала ревизии финансово-экономической деятельности для сокрытия незаконных действий и ухода от ответственности.
Изменения были выполнены в следующей последовательности: первоначально была изменена системная дата компьютера, затем скорректировано содержимое документа и обновлены метаданные в файле «core.xml», а для того, чтобы изменить дату создания в файловой системе, файл копировали в новую директорию, что отразилось в множественных записях USN Journal, связанных с этим файлом.
Надеюсь, что описанный выше способ поможет выявить документы, которые были отредактированы задним числом.
