Офисные документы с вредоносным кодом - как обезвредить ловушку и рассмотреть ее поближе

Нас часто спрашивают: «Где можно взять вредоносное ПО для анализа?» В разделе «О нас», на сайте, мы говорим вам что-то вроде «в онлайн-песочницах, ханипотах и у таких же читателей, как вы!». Итак, сегодняшний образец вредоноса прислал один из подписчиков, который хотел увидеть наш подход к анализу вредоносного документа с поддержкой VBA. Что ж, мы рады помочь!

Первоначальный анализ

Начнем с просмотра .DOC файла в шестнадцатеричном редакторе. Как можно заметить, заголовок начинается с PK, это указывает на то, что этот файл является ZIP-файлом. Все современные документы Microsoft Word представляют собой ZIP-архивы, в этом легко убедиться, - если вы переименуете аналогичный документ из .DOC в .ZIP, вы сможете распаковать его содержимое. Однако, чтобы продолжить анализ, мы собираемся сделать нечто другое.

Мы скармливаем наш документ утилите под названием OfficeMalScanner, которая осуществляет поиск встроенных элементов, таких как сценарии Visual Basic. В этом документе нашелся один такой сценарий, OfficeMalScanner извлек его как VBAPROJECT.BIN в каталог %temp%.

Если уже извлеченный двоичный файл VBAPROJECT.BIN просканировать с помощью OfficeMalScanner, утилита выведет реальный VBA-сценарий, чтобы мы могли проверить его содержимое.

Теперь, когда у нас есть читабельный VBA, можно заметить, что его код плохо отформатирован (скорее всего, специально); поэтому нам нужно будет немного его очистить, заменив избыточные символы новой строки («\n»), табуляции («\t») и пробелы («\s»). Это не обязательно делать, если бы нам нужно было бы только запустить такой сценарий, однако, если мы собираемся отлаживать его в Microsoft Word Developer Tools, нам понадобится многострочный код для размещения точек останова.

После небольшой очистки кода у нас остается что-то вроде этого:

Открытие ящика Пандоры

Теперь, когда мы видим, с каким кодом мы будем иметь дело, давайте откроем вредоносный документ в Microsoft Word.

Причина, по которой нам нужно открывать документ в Microsoft Word, а не просто запустить VBA сценарий отдельно, заключается в том, что этот сценарий использует скрытые переменные, расположенные в документе. Эти две переменные можно увидеть в «ActiveDocument.Variables (...). Value».

Вам может быть интересно, как можно найти такие переменные, поскольку на них не так-то просто наткнуться в коде, на них ничего не указывает явно ни в содержимом документа, ни в его свойствах, ни в настройках. Мы начинаем с открытия инструментов разработчика в Microsoft Word, затем вставляем наш отформатированный сценарий в окно VBA (заменяя плохо отформатированный). Затем мы помещаем точку останова в функцию «Sub Document_Open ()». Эта функция, как вы уже догадались, запускается при открытии документа. Затем мы запускаем сценарий, который остановится на нашей точке останова.

Две вышеназванные переменные можно найти, развернув «[+] ME» в окне локальных переменных, в нижней части редактора.

Эти две переменные будут считаны и декодированы. Здесь скрыта вся функциональность данного скрипта. Первая переменная декодируется в WMI Object "winmgmts:\\.\root\cimv2:Win32_Process", который отвечает за запуск содержимого второй переменной.

Вторая переменная декодируется в ... вы можете догадаться ... ага ... наш старый друг Powershell.

Если мы продолжим выполнение сценария, он в конечном итоге запустит Powershell терминал с декодированным сценарием из второй переменной. Мы можем увидеть содержимое этого скрипта при запуске Powershell, посмотрев на него в ProcessHacker.

Продолжаем деобуфскацию

Теперь, когда у нас есть извлеченный Powershell скрипт, мы можем еще раз немного очистить код и разделить его на соответствующие строки, заменив "; \ n" на ";" и исправив межстрочный интервал.

Мы делаем это для того, чтобы отладить код в Powershells IDE / Debugger, который поставляется вместе с Windows. Вы можете найти его, зайдя в меню ПУСК и набрав «ISE». «Windows Powershell ISE» - вот он. Для запуска кода вам нужно ввести команду в окне консоли: «Set-ExecutionPolicy unrestricted».

Powershell сценарий довольно прост. В чистом коде можно увидеть одну функцию деобфускации сверху, которая будет отвечать за декодирование большого количества текста в промежуточной переменной. Можно также увидеть строку «Add-Type» внизу скрипта, которая, в свою очередь, вызывает функцию «c193b ()». Это чаще всего используется для встраивания скрипта на языке программирования, отличном от Powershell. В данном случае мы видим, что скрипт декодировал C# код.

С#?

Мы зашли довольно далеко. Запустили документ Microsoft Office Word с поддержкой макросов, позволили ему декодировать скрытые переменные в обфусцированный сценарий Powershell, запускаемый через WMI Object, а затем декодировали сам этот сценарий, чтобы найти встроенный C# код. Мы почти закончили. Можно еще раз немного почистить деобфусцированный код, чтобы можно было загрузить его в подходящую IDE и отладить. В данном случае у нас на руках C# код, поэтому мы можем создать новый проект C# в Visual Studio и вставить код после функции «Hello World», как показано на изображении ниже. Нужно поместить операторы «using» вверху и вставить деобфусцированный код public class под основной функцией.

Из Powershell сценария мы увидели, что он вызывает класс yba2983 в функции c193b (). Поэтому нам нужно поместить ее в «Main», чтобы она имитировала передачу от Powershell. Обязательно установите точку останова в функции «c193b». Мы сейчас в конце, верно? Наконец-то мы можем увидеть, что этот лоадер пытался поставить в нашу систему. Ну, почти. Прежде чем мы дойдем до конца, нужно отметить еще один важный момент.

Обход AMSI

Anti-Malware Scanning Interface (AMSI) - это система защиты, которая поставляется с более поздними версиями Microsoft Windows и помогает защитить систему от различных атак.

Проще говоря, «amsi.dll» запускается в вашей системе и заставляет все запущенные скрипты взаимодействовать с API AmsiScanBuffer. Таким образом, весь обнаруженный нами деобфусцированный код будет проверяться в интерфейсе AmsiScanBuffer на предмет подозрительных / вредоносных действий. Если он их обнаружит, AMSI запретит выполнение скрипта. Там, где есть защита, есть обходы, и это именно то, что мы находим в начале C# кода.

Конкретно этот обход пытается вызвать "loadlibrary" с "amsi.dll" в качестве цели. Если это удастся, то он узнает, что AMSI существует в системе. Затем код вызовет «GetProcAddress» для интерфейса AmsiScanBuffer, снимет защиту с его области памяти, вызвав «VirtualProtect», а затем пропатчит «amsi.dll» с помощью вызова «RtlMoveMemory». Патча "amsi.dll", он удалит все защитные проверки, которые могут помешать запуску сценария.

Финишная черта

Если мы продолжим отладку C# кода, мы в конечном итоге деобфускируем последнюю переменную и наткнемся на URL-адрес предполагаемой загрузки.

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

Но почему...?

Зачем мы прошли через все это? Ведь можно было просто запустить этот образец в контролируемой среде и отслеживать весь сетевой трафик, чтобы увидеть загружаемый исполняемый файл. Вы правы. Это был бы очень эффективный способ получить индикатор компрометации (IOC) в течение нескольких секунд.

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

Что, если бы мы попытались запустить документ Microsoft Word, но ничего бы не случилось? Знаете ли вы, как проверить документ - .docx формата он или .rtf? Что, если вы не знаете, как отлаживать VBA, и он содержит встроенную защиту от отладки / анализа, которая препятствует запуску? Что, если бы Powershell распаковал альтернативный сценарий на основе даты и времени? Что, если C# обнаружит среду анализа и изменит окончательную строку загрузки на что-то безопасное или несуществующее? Вы бы не знали, потому что все, что у вас было бы, это последний IOC или документ, который отказался запускаться.

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

Прежде всего, самый ценный инструмент в нашей профессии - это любопытство. Оставайтесь любопытными.

Прочитать оригинал этого материала на английском можно здесь.

Cybred - канал об информационной безопасности и конкурентной разведке, вдохновленный идеями олдскульных андеграундных интернет-сообществ о свободе распространения информации в сети и всеобщей взаимопомощи.