Деобфусцируем имена функций .NET вручную 🙌

ВПО на .NET обожает пакеры, обфускацию (имен, CFG и прочего) и многоэтапные рефлективные подгрузки образов. При этом открытые деобфускаторы всегда отстают от актуальных версий их противоположностей, если вообще поддерживаются. Рассмотрим один из таких случаев.

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

Откроем бинарь в dnSpy и увидим следующую картину (скриншот 1).

Вспомним, что существует de4dot и попробуем скормить ему бинарь. Взяв то, что похоже на наиболее актуальную версию среди кучи форков (или форков форков (или форков форков форков)), выполним команду:

>  de4dotex .\sample.bin -vv

Результат на скриншоте 2.

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

🐍Попробуем сделать это на питоне, используя связку dnfile и dncil, набросав код для сбора обфусцированных имен функций и полей (скриншот 3).

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

Перепишем то же самое на C#, позаимствовав dnlib.dll у de4dot, дабы не страдать с самостоятельной ее сборкой. А чтобы не путаться среди кучи меню Visual Studio, просто приведем .csproj к следующему виду (требуется .Net 4.8 и его SDK):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  <LangVersion>10.0</LangVersion>
    <Nullable>enable</Nullable>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="dnlib">
      <HintPath>dnlib.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

Заведем класс Utils, с двумя функциями — проверкой валидности имени и формированием нового имени (скриншот 4). Наконец, опишем основную логику по переименованию типов, методов, свойств, полей и событий классов (скриншот 5). Результат прогона программы представлен на скриншоте 6.

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

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

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

В альтернативном случае можно сразу обращаться к dnlib или инструментам на его основе.

Happy reversing!

#TI #reverse #malware #tip
@ptescalator

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