He may not, as unvalued persons do, Carve for himself (W. Shakespeare)

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

В таких случаях извлечь данные MFT, логи ОС или юзерские артефакты в состоянии, пригодном для обработки классическими инструментами, возможно далеко не всегда. Это порождает необходимость применения карвинга — восстановления или реконструкции поврежденных файлов. В ряде случаев доступные коммерческие инструменты, реализующие данную технику, дают неплохие результаты, но в целом имеют достаточно ограниченную область применения.

В случае карвинга событий журналов ОС Windows хорошо зарекомендовала себя техника «забудь про BinXML»: для полноценного декодирования содержимого полей единичного события необходимы шаблоны, хранящиеся в заголовке чанка, который по понятным причинам может просто отсутствовать. Не пытаясь даже искать такие шаблоны, можно составить текстовое описание единичного события, где однозначно выделяются даты, хранимые в стандартных расположениях, коды событий и несколько других служебных полей, а также декодируемые «как текст» (с вырезанием служебных последовательностей BinXML) байтовые последовательности, содержащие данные для подстановки в шаблоны.

В итоге подобная техника позволяет получить существенно больше данных, нежели при попытке восстановления чанков EVTX: имея дату, код события EventID и тип журнала, хранимый в виде текста, можно понять, о чем идет речь (скриншот 1).

Схожий подход может применяться и для «живых» систем, где атакующие предприняли попытку удаления данных с целью сокрытия следов своих перемещений.

🔎 Для поиска остаточных данных таблицы MFT, помимо восстановления единичных записей стандартного формата, в ряде случаев хорошо работает техника поиска единичных атрибутов: как правило, ценность представляют атрибуты типа 0x30, то есть $FILE_NAME, содержащие четыре метки времени, имя файла и его размер (скриншот 2). В отдельных случаях такие единичные атрибуты даже для «живой» системы позволяют обнаружить, например, в файле подкачки (pagefile.sys) следы присутствия вредоносных файлов, отсутствующие в других артефактах. Подобные результаты также возможно получить с помощью поиска USN-записей, содержащих одну метку времени и имя файла, с которым производились какие-либо операции ФС (скриншот 3).

💽 Для поиска исполняемых файлов в образе диска хорошо работает тактика поиска заголовка PE с последующей оценкой размера файла по совокупному размеру секций. При небольшом усложнении алгоритма возможно реализовать более точный подход: определение энтропии конечных фрагментов файла с последовательным уменьшением размера фрагмента до момента перехода эмпирически определенного порогового значения «снизу вверх» при соблюдении паддинга в ряде случаев позволяет получить исполняемые файлы с совпадением по хешу. Однако даже «вырубленные топором» исполняемые файлы ВПО или их фрагменты прекрасно детектируются с помощью YARA-правил (скриншоты 4, 5).

📁 Для восстановления файлов реестра возможно использование поиска по заголовку с определением размера файла по полю HiveBinsDataSize: данное приближение в ряде случаев позволяет получить набор файлов, пригодных для обработки классическими инструментами. Характерной особенностью в данном случае является наличие в заголовке даты модификации и типа файла (primary/log), а также имени файла в UTF-16 размером 64 байта. Несмотря на то что для некоторых потенциально интересных с точки зрения форензики файлов (UsrClass.dat) структура пути не позволяет определить с достаточной точностью исходное размещение файла, для большинства случаев имеющейся информации вполне достаточно.

Наконец, прекрасно зарекомендовала себя техника поиска в образе диска читаемых текстовых фрагментов, ассоциируемых с выявленным инструментарием атакующих: в ряде случаев она позволяет восстановить командлайны и логи использованных инструментов, включая пароли, имена УЗ и подобные «приятные мелочи» (скриншот 6).

#yara #dfir #ir #windows
@ptescalator