Advanced Malicious Document Techniques pt.1

Существуют мощные методы создания вредоносных документов, которые эффективно обходят антивирусные средства обнаружения. Техника, которую мы сегодня рассмотрим называется VBA stomping и подразумевает собой замену сжатого исходного кода VBA. Код VBA хранится в потоках модулей, состоящих из PerformanceCache (P-код - скомпилированный код VBA) и CompressedSourceCode (исходный код VBA, сжатый с помощью проприетарного алгоритма).В этом сценарии обнаружение вредоносных программ, основанное только на исходном коде VBA, не удается. В этой статье мы продемонстрируем подробные примеры этого метода, а также представим некоторые дополнительные техники.

Сначала мы продемонстрируем работу VBA на простом, не вредоносном макросе. Этот документ просто отображает окно сообщения с текстом "ABC" при открытии документа. Исходный код VBA и результирующее окно сообщения показаны ниже.

Теперь нас интересует модификация исходного кода VBA, показанного выше, при этом промежуточный p-код останется неизменным. В рамках этой статьи мы сосредоточимся на текущем формате .docx/.xlsx/.docm/.xlsm (Office 2007+). Однако рассмотренные здесь приемы можно легко применить и к более старому формату .doc/.xls. В файлах Office 2007+ исходный код VBA и p-код обычно располагаются в файле под названием vbaProject.bin. Обратите внимание, что это имя файла по умолчанию, но его можно переименовать. Чтобы вручную изменить этот файл, нужно сначала разархивировать сжатый файл .docm/.xlsm, а затем открыть файл vbaProject.bin в hex-редакторе. В этом примере мы изменим "ABC" на "XYZ", но только в месте хранения исходного кода VBA, а не в разделе p-кода. Исходный код VBA хранится в сжатом виде, что объясняет появление непечатаемых или странных символов, которые вы видите на следующем изображении.

Теперь мы откроем документ и проверим исходный код VBA ДО нажатия кнопки "Включить содержимое".

Документ открыт, но макросы не включены. Проверка макроса в редакторе кода показывает, что будет отображено окно сообщения с текстом "XYZ", но это не так. На самом деле, как только содержимое включено, отображается окно сообщения с текстом "ABC", и исходный код в редакторе кода обновляется в соответствии с этим.

Ну, это, конечно, вводило в заблуждение. В исходном коде было сказано, что в окне сообщения будет отображаться "XYZ", но вместо этого было выведено "ABC". Что происходит?

Это связано с тем, что p-код, хранящийся в документе, - это то, что действительно выполняется, если он совместим с текущей версией VBA в системе. Кроме того, то, что отображается в редакторе макросов (если включено содержимое), - это не распакованный исходный текст VBA, а декомпилированный p-код. Интересно!

Если мы откроем документ в другой версии Word (которая использует другую версию VBA), p-код не будет пригоден для повторного использования. Это заставит распаковать исходный код VBA и перекомпилировать его в p-код, что приведет к отображению "XYZ" в окне сообщения. Итак, теперь у нас есть один документ, который на одной версии Office отображает "ABC", а на другой - "XYZ".

Обратите внимание на важную оговорку VBA stomped maldoc может быть выполнен только с помощью той же версии VBA, которая использовалась для создания документа. Это ограничение можно устранить, проведя разведку цели перед генерацией вредоноса, чтобы определить подходящую версию Office для использования или сгенерировав вредоносы с несколькими версиями Office и передать их жертвам.

Каков эффект от stomping VBA с точки зрения защиты? Обнаружение малдоков часто основывается исключительно на источнике VBA. Даже многие из доступных инструментов для анализа документов не в состоянии определить расхождение между источником VBA и p-кодом. Анализ фальсифицированного документа с помощью скрипта olevba показывает только распакованный источник и не содержит деталей p-кода.

Python-скрипт oledump.py дает аналогичные результаты, если не запускать его с плагином для дампера p-кода. В этом случае вывод дает некоторое представление о том, что p-код приведет к отображению в окне сообщения "ABC", как показано на рисунке ниже.

Нужный нам результат выдаёт сценарий pcodedmp.py . Дополнительным преимуществом вывода является отображение имен операций вместо op-кодов, как показано выше.

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

В результате в данном случае редактор VBA вообще не отображает код макроса, однако после включения содержимого все равно появляется окно сообщения с текстом "ABC". Теперь мы повторно запускаем olevba на этом файле, и исходный код VBA не отображается, а вместо таблицы, которая ранее выделяла наше использование подозрительного ключевого слова (AutoOpen), появляется сообщение "No suspicious keyword or IOC found".

Насколько это серьезная проблема?

Теперь мы немного углубимся в то, как Office использует сжатый исходный код VBA и p-код. Это станет известно позже, когда мы рассмотрим, как использовать функциональность Office для легкой модификации вредоносов, чтобы обмануть многие AV-сканеры.

Документы Office содержат два места, из которых можно извлечь VBA: сжатый исходный код VBA и p-код. В следующей таблице подробно описано, какой источник данных VBA когда используется:

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

Пример в реальном мире

Показать, что это работает на игрушечном примере - это все хорошо, но действительно ли эта угроза заставит напрячься синих? Давайте перейдем на следующий уровень, работая с известным вредоносным документом. В данном случае мы начнем с недавнего Emotet maldoc, который в настоящее время определяется как вредоносный 36/59 поставщиками на Virus total.

Если мы возьмем этот документ и просто уничтожим исходный код VBA, как описано выше, уровень обнаружения снизится до 7 из 58 антивирусных решений!

Как видите, это создает серьезную проблему для синих. Даже ручной анализ таких документов может оказаться проблематичным. В этой связи возникает очевидный вопрос: "Можно ли с помощью какого-либо инструмента выполнить автоматическое вырезание VBA или нам всегда придется вручную редактировать документ Office?". Ответ на этот вопрос - да, конечно же, возможно автоматическое " вырезание" VBA с помощью инструмента. Учитывая, насколько легко автоматизировать VBA-stomping, это представляет собой реальную угрозу.

Усугубление ситуации

Рассмотрим случай, когда maldoc предназначен для закрытия MS Word сразу после выполнения вредоносной полезной нагрузки. В сочетании с VBA stomping ни один автономный инструмент извлечения источников VBA не отобразит источник VBA, и источник VBA даже не будет отображаться в окне редактора макросов Office, пока макрос не будет включен. Но включение макроса приводит к немедленному завершению работы Word без возможности просмотреть декомпилированный источник. Хотя мы показали, что "ассемблероподобный" p-код можно извлечь, p-код трудно интерпретировать и невозможно проанализировать в отладчике VBA. Кроме того, p-код работает только на определенной версии VBA. По этим причинам доступ к исходному коду VBA был бы большим преимуществом для аналитика. Но как это можно сделать для такого документа?

Но есть простое решение, позволяющее остановить MS Word от выполнения любого метода, как только макросы будут включены. Обратите внимание, что это решение работает для документов Office 2007+, для более старых форматов документов проводятся дополнительные исследования. Решение для 2007+ заключается в удалении файла vbaData.xml из каталога "word" файла .docm (это легко сделать с помощью программы 7-Zip без необходимости вручную разархивировать и повторно разархивировать документ).

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

Интересным побочным эффектом стирания vbaData.xml является то, что это приводит к тому, что MS Word ошибочно указывает на отсутствие макросов в диалоговом окне "Макросы" (см. рисунок ниже).

Есть инструмент с открытым исходным кодом для обнаружения VBA в документах Office под названием VBA Seismograph. Этот инструмент обнаруживает различия между объявленными именами функций/переменных, строковыми литералами и строками комментариев, которые появляются в скомпилированном p-коде и исходном коде VBA документа Office.

В этой статье мы продемонстрировали, как сжатый исходный код VBA в документе Office может быть изменен или уничтожен, чтобы обойти антивирусные решения и усложнить ручной анализ вредоносных вложений. Защита от этой техники включает обнаружение и пометку документов с действительным p-кодом, но недействительным или отсутствующим исходным кодом VBA, или, в более общем случае, проверку расхождений между сжатым исходным кодом VBA и декомпилированным p-кодом. На данный момент мы не знаем ни одного коммерческого антивирусного решения, которое бы выполняло такую проверку, поэтому это потенциальная область, в которой антивирусные решения для сканирования могут быть улучшены.