Advanced Malicious Document Techniques pt.2
@ap_securityВ этой статье блога мы обсудим "VBA Purging" - технику, которая часто встречается в дикой природе. Мы объясним, как чистка VBA работает с документами Microsoft Office в формате Compound File Binary Format (CFBF), поведаем о некоторых возможностях обнаружения и поиска, а также расскажем про инструмент, созданный командой Red Team компании Mandiant: OfficePurge
Прежде чем погрузиться в тему очистки VBA, важно понять некоторые компоненты спецификаций Microsoft на макросы VBA (MS-OVBA) Microsoft’s specifications on VBA macros. Мы сосредоточимся на MS-OVBA в документах Microsoft Office 97, которые используют формат файлов CFBF, а не современный формат Open Office XML (OOXML), используемый в документах Microsoft Excel ".xlsx" и Microsoft Word ".docx".
Файловая структура MS-OVBA хранит все данные VBA в иерархии, которая состоит из структурированных хранилищ, содержащих различные типы потоков. Код VBA в документе Office хранится в различных потоках модулей, которые состоят из двух частей: PerformanceCache (также известный как P-код) и CompressedSourceCode. Раздел PerformanceCache представляет собой массив байтов, содержащий скомпилированный код VBA. Раздел CompressedSourceCode содержит исходный код VBA, сжатый с помощью фирменного алгоритма Microsoft. Граница между двумя разделами определяется значением MODULEOFFSET, которое хранится в потоке dir. Диаграмма потока модулей показана на рисунке
Когда макрос VBA добавляется в документ, механизм VBA сохраняет скомпилированную версию в разделе PerformanceCache соответствующего потока модулей для повышения производительности. Однако приложение Office получает доступ к PerformanceCache только в том случае, если его версия и архитектура соответствуют той, которая использовалась для компиляции исходного кода VBA. Эта информация о версии и реализации хранится в потоках _VBA_PROJECT и _SRP_. Если версии не совпадают, сжатый исходный код распаковывается, компилируется и запускается вместо него.
VBA Purging vs VBA Stomping
В прошлой статье мы рассмотрели очень похоий метод обфускации, так давайте же сравним эти два метода.
VBA stomping использует преимущества интерпретации потоков модулей и обменивает вредоносный CompressedSourceCode на не вредоносный исходный код VBA, оставляя PerformanceCache нетронутым. Однако успех этой техники зависит от версии Office, что означает, что злоумышленник должен провести дополнительную разведку своей цели и знать версии Office, установленные у жертвы.
VBA Purging изменяет потоки модулей противоположным образом. Вместо изменения CompressedSourceCode, очистка VBA полностью удаляет данные PerformanceCache из потока модуля и потока _VBA_PROJECT, изменяет значение MODULEOFFSET на 0 и удаляет все потоки SRP (это необходимо, поскольку потоки _VBA_PROJECT и SRP содержат зависящие от версии данные PerformanceCache, которые приведут к ошибке во время выполнения, если в потоке модуля нет PerformanceCache). Этот метод удаляет строки, обычно находящиеся в PerformanceCache, которые обнаруживают AV-двигатели и правила YARA. После удаления, злоумышленники могут использовать более стандартные методологии и выполнять подозрительные функции (например, CreateObject) без обнаружения.
На рисунке показаны потоки OLE для обычного и очищенного документа, извлеченные с помощью oledump. В оригинальном документе Module1 PerformanceCache составляет 1291 байт, в то время как в очищенном документе VBA - 0 байт. В очищенном документе нет потоков SRP, а поток _VBA_PROJECT уменьшен до 7 байт.
Команда Red Team компании Mandiant создала инструмент командной строки на языке C# под названием OfficePurge для тестирования этой техники. OfficePurge поддерживает документы Microsoft Office Word, Excel и Publisher, которые соответствуют формату файла CFBF. В следующих примерах мы использовали OfficePurge и полезную нагрузку VBA из публичного набора инструментов Unicorn для проверки эффективности очистки VBA документа Microsoft Office Word, содержащего закодированную в Base64 полезную нагрузку PowerShell.
Вывод строк для оригинального документа Word показывает полезную нагрузку PowerShell в кодировке Base64 от Unicorn, которая обнаруживается многими продуктами безопасности. С другой стороны, вывод для очищенного документа VBA не полностью показывает полезную нагрузку в кодировке Base64, поскольку PerformanceCache удален. CompressedSourceCode по-прежнему содержит полезную нагрузку в кодировке Base64, но пользовательский алгоритм сжатия Microsoft разделяет строки, что затрудняет ее обнаружение статическим анализом.
Оба документа были отправлены в онлайновые песочницы для проверки возможностей обнаружения различными продуктами. Показатель обнаружения VirusTotal оригинального документа (36/60) снизился на 67% после того, как он был очищен с помощью VBA (12/61). VirusTotal также классифицировал нечищеный документ как "create-ole", "doc" и "macros", тогда как чищеный документ был классифицирован только как "doc".
Возможности обнаружения
С помощью OfficePurge мы имеем возможность быстро стереть скомпилированный код VBA и уменьшить количество обнаружений продуктов безопасности в публичных песочницах, но зачем на этом останавливаться? Используя эти тестовые данные, следующим шагом будет создание логики условного обнаружения в форматах, таких как правила YARA, которые могут идентифицировать очищенные документы VBA и позволят нам охотиться за ранее необнаруженными вредоносными документами. В папке "sample-data" в репозитории OfficePurge на GitHub разработчики добавили оригинальные и очищенные документы для каждого поддерживаемого типа файлов с макросом, который порождает calc.exe. SHA256 хэши включены в конце этого сообщения.
Как упоминалось ранее, эта техника включает удаление данных PerformanceCache из потока _VBA_PROJECT_. Документация MSDN показывает, что минимальная длина потока _VBA_PROJECT_ составляет 7 байт, чтобы уместить необходимые поля в заголовке потока. Следующее правило YARA ищет файлы CFBF с потоком _VBA_PROJECT_ длиной 7 байт:
rule FEYE_OLE_VBAPurged_1 {
meta:
author = "Alyssa Rahman (@ramen0x3f)"
description = "This file has a _VBA_PROJECT stream that has been cleared. This is evidence of VBA purging, a technique where the p-code (PerformanceCache data) is removed from Office files that have an embedded macro."
strings:
$vba_proj = { 5F 00 56 00 42 00 41 00 5F 00 50 00 52 00 4F 00 4A 00 45 00 43 00 54 00 00 00 00 00 00 00 00 00 }
condition:
// Remove performance cache in _VBA_PROJECT stream. Replace the entire stream with _VBA_PROJECT header.
byte[] data = Utils.HexToByte("CC-61-FF-FF-00-00-00");
uint32(0) == 0xe011cfd0 and ( uint32(@vba_proj[1] + 0x78) == 0x07 )
}
Поиск по этой логике на VirusTotal выявляет большое количество вредоносных документов, что означает, что этот код очень распространен в природе и используется злоумышленниками. Это правило должно выявить большинство публично задокументированных примеров очистки VBA, например 9fd864e578d8bb985cf71a24089f5e2f (HornetSecurity). Однако он также может выявить несколько ложных срабатываний. Еще одним важным ограничением этого правила является то, что данные потока _VBA_PROJECT не обязательно должны быть полностью удалены. Поэтому, хотя размер потока равен 7 во всех публично документированных примерах этой техники, он не обязательно должен быть именно 7.
Одним из решений этой проблемы является сравнение сжатой и скомпилированной версий макросов документа и поиск неожиданных вариаций. Другой потенциальный вариант - правило YAContentsRA, которое ищет в потоке _VBA_PROJECT ключевые слова или байты, которые должны появиться, если p-код действителен.
Но давайте сначала пойдем по легкому пути и поищем аномалии внутри OfficePurge. В коде есть раздел, который перезаписывает поток _VBA_PROJECT статическим заголовком:
// Remove performance cache in _VBA_PROJECT stream. Replace the entire stream with _VBA_PROJECT header.
byte[] data = Utils.HexToByte("CC-61-FF-FF-00-00-00");
Небольшой поиск в Google показывает, что этот заголовок был создан на основе спецификаций Microsoft. Но если мы сравним очищенный и неочищенный документ, то окажется, что на практике этот заголовок отличается от спецификаций.
Этот заголовок не обязательно является доказательством того, что документ вредоносный или был создан с помощью OfficePurge, но он может быть хорошим индикатором того, что документ был создан программно, а не с помощью продуктов Office. При таких аномалиях мы можем начать создавать правило, подобное следующему, которое будет искать документы с "маленьким" потоком _VBA_PROJECT и этим подозрительным заголовком потока:
rule FEYE_OLE_VBAPurged_2 {
meta:
author = "Michael Bailey (@mykill), Jonell Baltazar, Alyssa Rahman (@ramen0x3f), Joseph Reyes"
description = "This file has a suspicious _VBA_PROJECT header and a small _VBA_PROJECT stream. This may be evidence of the VBA purging tool OfficePurge or a tool-generated document."
strings:
$vba_proj = { 5F 00 56 00 42 00 41 00 5F 00 50 00 52 00 4F 00 4A 00 45 00 43 00 54 00 00 00 00 00 00 00 00 00 }
$cc61 = {CC 61 FF FF 00 00 00}
condition:
uint32(0) == 0xe011cfd0 and ( uint32(@vba_proj[1] + 0x78) >= 0x07 ) and ( uint32(@vba_proj[1] + 0x78) < 0xff ) and $cc61
}
Поиск с помощью двух правил, представленных здесь, позволяет выявить широкий спектр субъектов угроз и типов вредоносных программ, использующих очистку VBA или, по крайней мере, некоторые виды автоматизированного создания документов. На VirusTotal вы, скорее всего, увидите множество полезных нагрузок Emotet, пойманных этим правилом, что вполне объяснимо, учитывая, насколько сильно он полагается на вредоносные почтовые вложения. Другим главным нарушителем, которого мы наблюдали, был AgentTesla.
Поскольку оба эти правила обнаруживают и доброкачественные документы, они не готовы для производственной среды; однако они могут быть полезны в качестве "слабых сигналов" для более ручного поиска угроз.
До тех пор, пока компании будут использовать документы Office, злоумышленники будут пытаться внедрить в них вредоносные макросы. Техника VBA Purging представляет собой свежий пример того, как щлоумышленники постоянно изобретают новые способы обхода защитников.