.NET Reactor: эволюция защиты с 6.7 до 7.0 и методы снятия обфускации 🔄

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

Но, как это обычно бывает, применяется он не только в благих целях: экспертам антивирусной лаборатории PT ESC часто попадаются вредоносные файлы, защищенные от анализа именно .Net Reactor.

🔓 Как защищен?

.NET Reactor использует несколько уровней защиты для предотвращения декомпиляции и анализа кода:

• NecroBit IL Code Protection: заменяет CIL-код методов на зашифрованный, делая невозможной декомпиляцию и восстановление исходного кода.

• Виртуализация кода: преобразует исходный код в набор инструкций отличный от .NET IL, которые интерпретируются во время выполнения виртуальной машиной, что затрудняет анализ и восстановление оригинального кода.

• Обфускация потока управления (Control Flow Obfuscation): преобразует код методов в запутанную структуру, усложняя понимание логики программы и затрудняя работу декомпиляторов (пример — на скриншоте 1).

• Шифрование строк (String Encryption): шифрует строки в коде, предотвращая их чтение и анализ, что усложняет понимание функциональности приложения, как показано на скриншоте 2.

• Антиотладочные механизмы (Anti Debug): внедряет проверки на наличие отладчиков, завершая процесс при их обнаружении, что препятствует динамическому анализу приложения.

🆕 Что нового?

• Поддержка .NET 6.0: обеспечивает защиту для новейших приложений на этой платформе.

• Улучшения в виртуализации кода и Control Flow Obfuscation обеспечивают дальнейшее повышение надежности и сложности обфускации.

• Скрытие содержимого объединенных приложений .NET Core, 5.0, 6.0 предотвращает просмотр содержимого с помощью инструментов, таких как ILSpy / dnSpy.

🧐 Как анализировать?

Несмотря на сложность защиты, существуют инструменты, которые облегчают жизнь реверсерам.
NETReactorSlayer — мощный инструмент для реверса приложений, обфусцированных с помощью .NET Reactor. Его главные фишки:

• дешифровка NecroBit — восстанавливает CIL-код из зашифрованных методов;

• удаление прокси и оберток — очищает код от мусора, добавленного обфускатором (смотрите на скриншоте 3);

• декодирование строк и ресурсов — возвращает читаемые строки, зашифрованные в приложении;

• обход антиотладки и защиты от изменения кода.

Однако начиная с версии 6.9 изначальная версия Net Reactor Slayer перестала справляться с деобфускацией защиты даже с базовыми параметрами. Благодаря открытому исходному коду и довольно большому комьюнити, в pull requests можно найти исправленный код, который прекрасно отрабатывает даже на самой свежей версии обфускатора.

Но вот с виртуализированным кодом не все так гладко: Net Reactor Slayer с ним не справляется. Если вам повезло и файл был защищен версией 6.9.0.0, то можно не тратить время на ручной анализ виртуальной машины, а применить VMAttack — инструмент для девиртуализации приложений .NET, в котором есть поддержка этой версии .NET Reactor. А если не повезло — проще всего проанализировать файл по его поведению, например с помощью PT Sandbox.

☝️ Вывод

.NET Reactor остается одним из самых популярных обфускаторов для .NET. С каждой версией защита усложняется, особенно за счет виртуализации. Если собираетесь его анализировать — запасайтесь терпением и хорошими инструментами.

#avlab #sandboxteam #dotnet #obfuscation
@ptescalator

1C_shell для «1С» 🦞

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

Самым терпеливым и любопытным может помочь связка инструментов для работы с кэшем RDP (который, как известно, хранится в Windows по адресу C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache), состоящая из парсера кэша bmc-tools и инструмента для «склеивания» фрагментов изображения RdpCacheStitcher.

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

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

🔎 Итак, что же любопытного можно обнаружить внутри подобного кэша?

1. Следы внезапно проснувшегося интереса пользователя к разного рода сомнительным инструментам (скриншоты 1, 2);

2. Следы запуска подозрительных файлов с еще более подозрительными параметрами (скриншот 3);

3. Выполнение до боли знакомых команд, которые, казалось бы, простой бухгалтер выполнять не должен (скриншот 4);

4. Нечто крайне подозрительное, интересное (скриншот 5).

При обнаружении такого рода данных следует внимательно изучить соседние фрагменты — там, как правило, можно обнаружить какое-то развитие наметившейся идеи (скриншоты 6, 7, 8).

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

Несмотря на то, что механизмы работы подобных «внешних обработок» системы «1С» были уже давно описаны в материале «Взломать за 60 секунд!» и докладе «„1С“ глазами пентестера», а все соответствующие рекомендации сформулированы, схема продолжает работать и по сей день.

#ir #dfir #malware
@ptescalator

Используете ли вы криптографию правильно? 🔓

Группе исследования сложных угроз департамента Threat Intelligence часто приходится решать интересные задачи в процессе реверса ВПО. Этот раз не стал исключением. Существует такая техника, как Execution Guardrails: Environmental Keying, — она нужна для ограничения выполнения ВПО только в конкретной целевой среде. Например, ее использует группировка Decoy Dog в своих операциях.

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

☠️ Выяснилось, что ВПО «падает» при попытке вызова функции LoadLibraryA с переданным именем библиотеки в качестве неотображаемых байтов. Этот набор байтов должен представлять собой имя библиотеки, которая расшифровывается в цикле; при каждой итерации берется символ от имени компьютера, с помощью логических операций приводится в необратимый вид, а после уже гаммируется с зашифрованным текстом и его однобайтовой константой.

Чтобы вычислить промежуточный ключ (который формируется в результате логических операций), мы прибегнули к атаке на основе открытого текста. Возвращаясь к функции LoadLibraryA: мы знаем, что имя библиотеки будет составлять 13 байт в кодировке ASCII + '\x00'; так мы смогли восстановить треть ключа, а далее по аналогии уже с другими строками восстановили оставшуюся часть ключа.

Дешифрование строки:
F(sym_comp_name) ^ sym_enc ^ cnst_enc = sym_dec
F(sym_comp_name) — логические операции

Получение промежуточного ключа:
sym_dll_name ^ sym_enc ^ cnst_enc = irr_sym_key
irr_sym_key — промежуточный байт ключа, необратимый

Группа исследования сложных угроз рекомендует одну из платформ для изучения криптоанализа — cryptohack.org.

#tips #reverse #malware #cryptography #TI
@ptescalator