XLL Фишинг-методы
После недавнего объявления Microsoft о блокировке макросов в документах, полученных из интернета (по email И загрузки из сети), злоумышленники начали активно искать другие способы получения доступа через действия пользователя (UDA). При поиске жизнеспособного метода фишинга для получения доступа необходимо взвесить несколько факторов:
Это основные вопросы, но, безусловно, есть и другие. Ситуация усложняется, когда вы понимаете, что эти факторы накладываются друг на друга; например, если у клиента есть веб-прокси, запрещающий загрузку исполняемых файлов или DLL, возможно, придётся поместить полезную нагрузку в контейнер (ZIP, ISO и т.д.). Это, в свою очередь, может создать дополнительные проблемы в дальнейшем в плане обнаружения. Более надёжная защита требует более сложных комбинаций методов для её преодоления.
Эта статья написана с учётом вымышленной целевой организации; в этой организации внедрены несколько защитных мер, включая правила фильтрации электронной почты, блокировку загрузки определённых типов файлов, блокирование приложений по белому списку на конечных точках, а также Microsoft Defender для конечных точек в качестве решения EDR.
Реальные организации могут не применять ни одну из этих мер, некоторые или даже больше, что может упростить или усложнить методы, описанные в этом исследовании. Как всегда, знайте свою цель.
XLL — это DLL, специально созданные для Microsoft Excel. Неискушённому глазу они очень похожи на обычные документы Excel.
XLL представляют собой очень привлекательный вариант для UDA, поскольку они выполняются Microsoft Excel — очень часто встречающимся ПО в клиентских сетях; в качестве дополнительного бонуса, так как они выполняются Excel, наша полезная нагрузка почти наверняка обойдёт правила блокирования приложений по белому списку, поскольку их выполняет доверенное приложение (Excel). XLL можно писать на C, C++ или C#, что обеспечивает гораздо большую гибкость и мощность (и вменяемость) по сравнению с макросами VBA, что делает их ещё более желанным выбором.
Недостатком, конечно, является то, что законных способов использования XLL очень мало, поэтому организациям ДОЛЖНО быть очень легко заблокировать загрузку этого расширения файла как по электронной почте, так и при скачивании из сети. К сожалению, многие организации отстают от современных стандартов на годы, и поэтому XLL остаются жизнеспособным методом фишинга ещё некоторое время.
Существует ряд различных событий, которые можно использовать для выполнения кода внутри XLL, самым заметным из которых является xlAutoOpen. Полный список можно увидеть здесь:
При двойном щелчке по XLL пользователь видит такой экран:
Это единственное диалоговое окно отделяет пользователя от выполнения кода; при достаточно тонкой социальной инженерии выполнение кода практически гарантировано.
Необходимо помнить, что XLL, как исполняемые файлы, являются архитектурно-зависимыми. Это означает, что вы должны знать свою цель; версия Microsoft Office/Excel, которую использует целевая организация, (обычно) определяет, под какую архитектуру нужно собирать полезную нагрузку.
Существует достаточно чёткое разграничение по версиям Office, которое можно использовать как эмпирическое правило:
Office 2016 или старше: x86
Office 2019 или новее: x64
Следует отметить, что для каждого продукта возможно установить другую архитектуру, однако это архитектуры, устанавливаемые по умолчанию, и в большинстве случаев это должно быть надёжным способом принятия решения о том, для какой архитектуры создавать XLL. Конечно, в зависимости от метода доставки и предлога, используемого в фишинговой кампании, возможно предоставить обе версии и положиться на то, что жертва выберет подходящую для своей системы.
Полезная нагрузка XLL, созданная в ходе этого исследования, основана на этом проекте edparcell. В его репозитории есть хорошие инструкции по началу работы с XLL в Visual Studio, и я использовал его код в качестве отправной точки для разработки вредоносного файла XLL.
Заметное отличие от его репозитория заключается в том, что если вы хотите создать свой собственный проект XLL, вам понадобится загрузить последнюю версию SDK Excel, а затем следовать инструкциям из ранее указанного репозитория, используя эту версию вместо версии SDK 2010, упомянутой в README.
Доставка полезной нагрузки является серьёзным фактором в контексте UDA. Мы сосредоточимся на двух основных методах:
Будь то прикрепление файла или включение ссылки на веб-сайт, где можно загрузить файл, электронная почта является критически важной частью процесса UDA. За прошедшие годы многие организации (и поставщики электронной почты) усовершенствовали и внедрили правила для защиты пользователей и организаций от вредоносных вложений. Результаты могут различаться, но в настоящее время организации могут:
«Фаззинг» правил электронной почты организации может быть важной частью вовлечения, однако всегда нужно быть осторожным, чтобы не выдать, что проводится операция Red Team и информация активно собирается.
Для целей этой статьи будем считать, что в целевой организации действуют строгие правила вложений, препятствующие доставке полезной нагрузки XLL. Мы перейдём к веб-доставке.
Электронная почта всё ещё будет использоваться в этом векторе атаки, однако вместо отправки вложения она будет использоваться для отправки ссылки на веб-сайт. Правила веб-прокси и сетевые меры, контролирующие разрешённые типы загружаемых файлов, могут отличаться от тех, которые применяются к вложениям электронной почты. Для целей этой статьи предполагается, что организация блокирует загрузку исполняемых файлов (MZ-заголовков) из сети. В таком случае стоит изучить упаковщики/контейнеры.
Идея заключается в том, что мы можем поместить наш исполняемый файл внутрь файла другого типа и провезти его контрабандой мимо политик организации. Важным фактором является родная поддержка файлового типа; например, файлы 7Z нельзя открыть в Windows без установки стороннего ПО, поэтому они не лучший вариант. Такие форматы, как ZIP, ISO и IMG, привлекательны тем, что они поддерживаются Windows изначально, и, как дополнительный бонус, они добавляют очень мало дополнительных шагов для жертвы.
К сожалению, организация блокирует загрузку ISO и IMG из сети; кроме того, из-за использования системы предотвращения утечки данных (DLP) пользователи не могут монтировать внешние устройства хранения, к которым причисляются ISO и IMG.
К счастью для нас, хотя организация блокирует загрузку файлов с MZ-заголовками, она разрешает загрузку zip-файлов, содержащих исполняемые файлы. Эти zip-файлы активно сканируются на предмет вредоносного ПО, включая запрос пароля для защищённых паролем zip-файлов; однако, поскольку исполняемый файл заархивирован, он не блокируется в противном случае общим запретом на MZ-файлы.
Zip-файлы были выбраны в качестве контейнера для полезной нагрузки XLL, потому что:
Удобно, что двойной щелчок по ZIP-файлу в Windows открывает этот zip-файл в проводнике:
Менее удобно, что двойной щелчок по файлу XLL из заархивированного местоположения вызывает Windows Defender; даже при использовании стандартного проекта от edparcell, который не содержит вредоносного кода.
При взгляде на предупреждение Windows Defender мы видим, что это просто общее предупреждение «Wacatac»:
Однако есть нечто странное; файл, который был определён как вредоносный, находился в c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, а не в C:\users\user\Downloads\ZippedXLL, где мы на него нажали. Просмотр экземпляра Excel в ProcessExplorer показывает, что Excel на самом деле запускает XLL из appdata\local\temp, а не из ZIP-файла, из которого он был извлечён:
Похоже, это особенность ZIP-файлов, а не XLL. Открытие TXT-файла из zip-архива с помощью блокнота также приводит к копированию TXT-файла в appdata\local\temp и его открытию оттуда. Хотя открытие текстового файла из этого расположения нормально, Defender, похоже, определяет любое выполнение кода в этом расположении как вредоносное.
Если бы пользователь извлёк XLL из ZIP-файла, а затем запустил его, он выполнился бы без каких-либо проблем; однако нет никакой гарантии, что пользователь это сделает, и мы действительно не можем рисковать, надеясь обойти AV/EDR, если он этого не сделает. Кроме того, двойной щелчок по ZIP-архиву, а затем двойной щелчок по XLL гораздо проще, и жертва гораздо более склонна выполнить эти простые действия, чем возиться с извлечением ZIP-архива.
Эта проблема заставила меня задуматься о другом типе полезной нагрузки, отличном от XLL; я начал изучать VSTO — шаблоны Visual Studio для Office. Настоятельно рекомендую ознакомиться с той статьёй.
VSTO в конечном итоге вызывают DLL, которая может находиться локально вместе с .XLSX, инициирующим всё, или размещаться удалённо и загружаться .XLSX через http/https. Локальный вариант не даёт реальных преимуществ (и на самом деле имеет несколько недостатков, так как с VSTO-атакой связано ещё несколько файлов), а удалённый вариант, к сожалению, требует сертификата подписи кода или наличие доверенной сети для удалённого расположения. Не имея действительного сертификата подписи кода, VSTO не устраняют ни одну из проблем, с которыми сталкивается наша полезная нагрузка XLL.
Кажется, мы загнаны в угол. Запуск самого XLL работает нормально, однако XLL не может быть доставлен жертве отдельно ни в виде вложения электронной почты, ни через веб-загрузку из-за политик организации. XLL необходимо упаковать в контейнер, однако из-за DLP такие форматы, как ISO, IMG и VHD, нежизнеспособны. Жертва должна иметь возможность открыть контейнер нативно, без стороннего ПО, что оставляет ZIP в качестве варианта; однако, как обсуждалось, запуск XLL из заархивированной папки приводит к его копированию и запуску из appdata\local\temp, что вызывает срабатывание AV.
Я потратил много часов на мозговые штурмы и тестирование, углубился в кроличью нору VSTO, исследовал все мыслимые варианты, пока наконец не решил попробовать что-то настолько глупое, что это может сработать.
На этот раз я создал папку, поместил в неё XLL, а затем заархивировал папку:
Перейдя в папку, видим файл XLL:
Двойной щелчок по XLL показывает окно надстройки от Excel. Обратите внимание, что XLL всё ещё копируется в appdata\local\temp, но из-за дополнительной папки, которую мы создали, появляется дополнительный слой:
Нажатие «Включить» выполняет наш код без срабатывания Defender:
Отлично! Выполнение кода. Что дальше?
Предлог, используемый для того, чтобы жертва загрузила и выполнила XLL, будет сильно различаться в зависимости от организации и метода доставки; темы могут включать данные о зарплате сотрудников, калькуляторы для компенсации на основе навыков, информацию о проекте, список участников мероприятия и т.д. Какой бы ни была приманка, наша атака будет гораздо более эффективной, если мы действительно предоставим жертве то, что ей обещали. Без выполнения обещания жертвы могут заподозрить неладное и сообщить о документе своим службам безопасности, что может быстро раскрыть атакующего и ограничить доступ к целевой системе.
XLL сам по себе оставит пустое окно Excel после завершения выполнения нашего кода; было бы гораздо лучше, если бы мы предоставили ту самую электронную таблицу Excel, которую ищет жертва.
Мы можем встроить наш XLSX в виде массива байтов внутрь XLL; когда XLL выполняется, он сбрасывает XLSX на диск рядом с XLL, после чего он открывается. Мы назовём XLSX так же, как XLL, разница будет только в расширении.
Поскольку наш XLL написан на C, мы можем применить некоторые возможности из моей предыдущей статьи о Возможностях полезной нагрузки на C, а именно самоудаление. Объединение этих двух методов приводит к тому, что XLL удаляется с диска, а XLSX с тем же именем помещается на его место. Для неискушённого глаза будет казаться, что XLSX был там всё время.
К сожалению, место, где XLL удаляется, а XLSX сбрасывается, — это папка appdata\temp\local, а не исходный ZIP; чтобы решить эту проблему, мы можем создать второй ZIP, содержащий только XLSX, и также прочитать его в массив байтов внутри XLL. При выполнении, в дополнение к вышеупомянутым действиям, XLL может попытаться найти исходный ZIP-файл в c:\users\victim\Downloads\ и удалить его, прежде чем поместить на его место второй ZIP, содержащий только XLSX. Это, конечно, может не сработать, если пользователь сохранил исходный ZIP в другом месте или под другим именем, однако во многих/большинстве случаев он автоматически окажется в папке загрузок пользователя.
На этом скриншоте в нижней панели показана временная папка, созданная в appdata\local\temp, содержащая XLL и сброшенный XLSX, а в верхней панели — исходное окно проводника, из которого был открыт XLL. Обратите внимание, что в нижней панели размер XLL равен 0. Это потому, что он удалил себя во время выполнения, однако, пока верхняя панель не закрыта, файл XLL не исчезнет полностью из расположения appdata\local\temp. Даже если жертва снова нажмёт на XLL, он теперь инертен и на самом деле не существует.
Аналогично, как только жертва выйдет из открытого ZIP-архива в проводнике (закрыв его или перейдя в другую папку), при повторном нажатии на spreadsheet.zip она обнаружит, что папка test теперь содержит importantdoc.xlsx; таким образом, XLL был удалён и заменён безвредным XLSX в обоих местах, где он существовал на диске.
Эта GIF-анимация демонстрирует загрузку и выполнение XLL на пробной виртуальной машине MDE. Обратите внимание, что по какой-то причине здесь Excel открывается в двух экземплярах; на моём домашнем компьютере открылся только один, так что не совсем понятно, почему так различается.
Как всегда, спросим: «Что видит MDE?»
Быстрый сброс скриншотов, чтобы доказать, что я действительно выполнил это на цели и получил обратный маяк на TestMachine11:
Во-первых, ноль предупреждений:
Что захватывает временная шкала/журнал событий?
Ого. Честно говоря, понятия не имею, откуда берутся предупреждения о регистрации нажатий клавиш, шифровании и расшифровке учётных данных, поскольку мой код ничего этого не делает. Наши действия, конечно, выглядят подозрительно, когда так разложены, но я снова отмечу, какой объём данных собирает MDE на одной конечной точке, не говоря уже о сотнях, тысячах или сотнях тысяч, которые могут быть подключены к EDR в организации. Пока мы не вызываем никаких реальных предупреждений, вероятно, всё в порядке.
Момент, которого большинство, вероятно, ждали: я предоставляю пример кода моего разработанного средства запуска XLL, ограниченный только теми частями, которые обсуждались здесь, в разделе «Тактика». Читателю предстоит самостоятельно встроить код в XLL и реализовать его совместно с остальной частью средства запуска. Как всегда, не причиняйте вреда, имейте разрешение на фишинг организации и т.д.
Я включил исходный код программы, которая принимает файл и генерирует шестнадцатеричные данные, которые можно скопировать в массивы байтов, определённые во фрагменте. Используйте это для XLSX, который вы хотите показать пользователю, а также для ZIP-файла, содержащего папку с тем же XLSX, и сохраните их в соответствующих массивах байтов. Скомпилируйте этот код с помощью:``` gcc -o ingestfile ingestfile.c
У меня возникли некоторые проблемы при компиляции моих XLL с помощью MingW на машине kali, поэтому решил опубликовать команды здесь: **x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
После компиляции вам нужно будет создать новую папку и скопировать XLL в эту папку. Затем заархивируйте её с помощью:```
zip -r <myzipname>.zip <foldername>/
Note that in order for the tradecraft outlined in this post to work, you are going to need to match some variables in the code snippet to what you name the XLL and the zip file.
С уходом эпохи макросов Office XLL представляют собой привлекательный вариант для фишинговых кампаний. Проявив немного творчества, их можно использовать в сочетании с другими техниками для обхода множества уровней защиты, реализованных организациями и командами безопасности. Спасибо за чтение, и я надеюсь, вы узнали что-то полезное!