Привет, Хабр! На связи команда UserGate uFactor, у нас новое исследование по кибербезопасности.
В этой статье рассмотрим подмену временных меток с помощью туннелирования NTFS и методы определения данного события с точки зрения компьютерной криминалистики.
Что же такое туннелирование файловой системы?
Туннелирование файловой системы — это встроенный механизм обратной совместимости, при котором операционная система сохраняет метаданные файла при его удалении или переименовании.
Основные компоненты:
Кэш туннелирования (tunnel cache)
Временное хранилище метаданных удаленных файлов
Хранится в памяти файловой системы
Время жизни записей: обычно 15 секунд в Windows
Ключевые сохраняемые метаданные:
Короткое имя (8.3 format)
Дата/время создания
Дата/время модификации
$OBJECT_ID
Некоторые атрибуты (сжатие, шифрование)
Условия активации:
Удаление или переименование файла
Создание файла (или обратное переименование) с тем же именем включая имя расширения в том же каталоге
Временной интервал между операциями времени жизни кэша
Мы провели эксперимент. У нас есть компьютерная системе на базе ОС Windows 10 Home (build 10240). Через проводник создали четыре файла, два с короткими именами и два с длинными (для записи в $MFT короткого имя (8.2 format). Далее записали в них текст «data». Рисунки 1 и 2.
Перезагрузили систему, далее скопировали файл $MFT.
Подождав некоторое время, выполнили манипуляцию, которая задействует туннелирование файловой системы. На рисунке 3 представлены используемые команды в bat файле. Два файлы мы переименовывали с перезаписью содержимого на «change_data». Другие два удалили и создали новые с такими же именами и новым содержимым (текст «change_data»).
Скопировали файл $MFT и $J (USN Journal). $LogFile копировать не стали по причине того, что в реальности сведений в нем мы не найдем.
Корректное объяснение:
USN Journal (Change Journal)
· Назначение - отслеживание изменений файлов/папок.
· Время хранения - длительное - недели/месяцы для низко нагруженных систем и несколько часов – 2 дня для высоко нагруженных.
· Размер - настраивается, но тоже ограничен.
$LogFile (Journal)
· Назначение - обеспечение целостности файловой системы.
· Время хранения - кратковременное - записи удаляются после commit транзакций.
· Размер - ограничен, циклическая перезапись.
Теперь давайте посмотрим, что у нас получилось. Сравним MFT Entry и Sequence Number и временные метки. Для извлечения данных и просмотра используем утилиты (Eric Zimmerman's tools) «MFTEcmd» и «TimelineExplorer». Временные метки представлены в UTC 0000.
Итак, на рисунке 5 и 7 мы видим, что в $MFT сохранились сведения об удаленных файлах (выделено красным), но нам это неинтересно. Обратите внимание (рис. 4 и 5) на Entry Number и Sequence Number файлов «del.txt» и «tunnel_del.txt» до и после. Как видим, Entry Number и Sequence Number изменились. А вот временные метки (рис. 6 и 7) файла $SI и $FN приняли старое значение. Напомню, в выводе «MFTEcmd», если в колонке нет временных меток для $FN, значит они соответствуют $SI. Отсюда следует вывод, что при исследовании файла $MFT или же образа диска, если вы примените фильтрацию по времени создания файла, опираясь на уверенные значения $FN, то вы пропустите подмененный файл. А вот если проводить исследование, опираясь на Entry Number, то подмену или же аномалию для времени создания файла можно увидеть. Также стоит учитывать время изменения и доступ, но вы столкнётесь с множеством ложных событий (легитимные операции).
Теперь перейдем к файлам, которые мы переименовывали: «ren.txt» и «tunnel_ren.txt». Вот тут уже интересно. Entry Number и Sequence Number не поменялись (рис. 4 и 5), даты (рис. 6 и 7) создания также сохранились. А вот Last Modified приняла странное значение «2025-10-30 12:09:03» по сравнению с Created «2025-10-30 15:47:42», что же это за время такое? А это время из $OBJECT ID, точнее из UUID Object Id. Мы рассмотрим его далее, когда будем смотреть сырые данные в $MFT. И вот Last Record Change нам показывает реальное время, когда содержимое было изменено. В этом случае уже нужно ориентироваться на $OBJECT ID (если оно есть), Last Record Change и USN Journal.
Теперь посмотрим сырые данные.
Зеленый цвет – временные метки $SI.
Красным цвет – временные метки $FN.
Желтый цвет – $OBJECT ID.
Серый цвет (для коротких имен 8.3 format) - временные метки для короткого имени.
Дополнительно бирюзовый цвет – имя файла «Мой документ файл.txt» (UTF-16LE) до переименования.
Перейдем к сырым данным.
Файл «del.txt» слева до справа после.
Напомню про временные метки:
Временные метки в $MFT хранятся в формате Windows FILETIME — это 64-битные значения в little-endian порядке. Little-endian означает, что читать нужно с конца.
Больше всего интересует $OBJECT ID, а точнее UUID Object Id:
· «47 BB 18 95 8B B5 F0 11 9C 69 D5 B5 BA CA 61 7F»
Это UUID ver.1 (RFC 4122)
Нам нужно не просто изменить направления (big-endian), а применить изменения для структуры UUID v 1
Разбиваем на компоненты:
Байты 0-3 (time_low): 47 BB 18 95 → 95 18 BB 47
Байты 4-5 (time_mid): 8B B5 → B5 8B
Байты 6-7 (time_high): F0 11 → 11 F0
Байты 8-9 (clock_seq): 9C 69 → 69 9C
Байты 10-15 (node): D5 B5 BA CA 61 7F → D5 B5 BA CA 61 7F
Из time_low, time_mid и time_high высчитывается временная метка.
Утилита «MFTExplorer» (Eric Zimmerman's tools) автоматически рассчитывает временную метку Object ID. Время Object Id Created On: 2025-10-30 12:25:55.4992967
То, что временная метка не соответствует дате создания, это нормально, Object ID - может создаваться раньше, при резервировании места в MFT или же может браться из системных часов на момент генерации UUID.
Не всегда можно встретить в MFT запись $OBJECT ID, например если файл создается через консоль (cmd).
Посмотрим теперь для файла «tunnel_del.txt»
Поскольку имя файла «tunnel_del.txt» более 8 символов, в MFT создается короткое имя. Формат 8.3 – 8 символов на имя и 3 – на расширение. Обратите внимание на временные метки для короткого имени (серый цвет), они соответствуют времени $FN, т.е. будут принимать значения $FN всегда.
Сравним оставшиеся файлы.
Также стоит отметить, что события, связанные с манипуляцией файлов, не повлияли на временные метки для индексных записей каталога (в котором содержались тестовые файлы) $I30 (см. рис. 12).
Creation Time - 2025-10-30 15:48:14.543130
Modification Time - 2025-10-30 15:48:14.543130
MFT Change Time - 2025-10-30 15:48:24.353188
Access Time - 2025-10-30 15:48:14.543130
Сделаем вывод, что при подмене временных меток через туннель NTFS представленным способом, мы можем понять, что с файлом проводились манипуляции. Особое внимание должно привлекать UUID Object Id и временная метка, скрытая в нем.
Теперь посмотрим USN Journal (Change Journal). Извлечь данные из файла $J можно также утилитой «MFTEcmd» (Eric Zimmerman's tools)
MFTECmd.exe -f <path\$J> -m <path\$MFT> --csv <out> --csvf file.csv
Фильтры для «Update Reasons» используем как на рисунке 13 (выделено красным)
На рисунке 13 зеленым цветом выделено время событий с файловыми операциями.
Конечно же, USN Journal (Change Journal) очень ценный и может дать полное понимание картины происходящего, но, к сожалению, зачастую глубина времени недостаточная для объективного и всестороннего анализа. Если глубины временных событий не хватило, используйте карвинг неразмеченной области дискового пространства, возможно, вам повезет и получится восстановить еще события.
А теперь о грустном.
В большей степени это касается компьютерно-судебной экспертизы.
Несложными манипуляциями (не требующими особых прав доступа) мы изменили содержимое файла. При этом все временные метки, Entry Number и Sequence Number сохранились от прежнего файла, файл не имел записи $Object ID в MFT.
А теперь представьте, что из-за давности события в USN Journal не сохранилась информация и карвинг тоже не дал результатов. Дополнительно настроенных журналов логирования нет. Метаданных файла нет, а может и есть, но злоумышленник тщательно подготовился и смастерил нужные метаданные. А подозреваемый не может доказать, что к компьютеру имел доступ кто-то посторонний.
На основании успешно получившегося эксперимента есть мнение. Если судебный эксперт не может доказать манипуляцию или обратное с временными метками файла, то он должен отразить в заключении эксперта следующее: «установить точное время создания и изменения файла, а также доступ к файлу не представляются возможным», даже если он видит их в MFT.
