Я не являюсь автором статьи, только перевел, оригинал:
Для атакующего первоначальный доступ может оказаться довольно сложной задачей, если цель хорошо защищена. При выборе пэйлоада для первоначального доступа атакующий должен выбрать формат файла, который позволяет выполнять произвольный код или команду оболочки с минимальным взаимодействием с пользователем. Эти форматы файлов могут быть редкими, поэтому атакующие полагались на такие типы файлов, как .HTAs, макросы в MS Word, .VBS,.JS и другие.
Очевидно, что существует ограниченное число встроенных расширений файлов в Windows, и по мере улучшения защиты количество эффективных полезных нагрузок продолжает сокращаться.
Кроме того, атакующий должен доставить этот файл для конечного пользователя с уверенностью, что его приведут в исполнение.Опять же, возможности для этого могут быть ограничены, поскольку прямое связывание с пэйлоадом или прикрепление их к электронным письмам, как правило, блокируется антивирусной или браузерной защитой.Именно поэтому злоумышленники прибегают к связыванию и внедрению (OLE), zip файлы и т. д. Для борьбы с доставкой файлов, в Office 2016 ввели блокировку всех опасных форматов файла.Это снижает эффективность одного из наиболее надежных методов доставки полезной нагрузки. При попытке активировать заблокированное расширение файла, Office выдаст ошибку и предотвратит выполнение.
При попытке активировать заблокированное расширение файла Office выдаст ошибку и предотвратит выполнение. В дополнение к блокировке OLE Майкрософт также ввел правила ASR в Windows 10 (которые требует антивирус Windows Defender в качестве зависимости). Целью этих правил является сокращение возможностей, которыми атакующий может злоупотреблять или использовать для выполнения кода в системе. Одним из наиболее эффективных правил ASR это “Блокировка в приложениях office создания дочерних процессов". Это правило блокирует любые попытки создания процесса в качестве дочернего:
При объединении OLE блокировки и ASR правил, выполнения кода на конечной цели из интернета становятся немного ограниченным. Как мы можем обойти этот контроль? Сначала я решил проблему формата файла. Я потратил много времени, просматривая реестр в поисках новых форматов файлов, которые могли бы позволить выполнение. Большинство из этих форматов можно найти в корневом каталоге HKCR:\ registry hive.
После бесчисленных часов чтения спецификаций файлов, я наткнулся на тип файла “.SettingContent-ms ". Этот формат был введен в Windows 10 и позволяет пользователю создавать "ярлыки" для различных настроек. Это просто XML файлы и содержат пути к различным двоичным файлам параметров Windows 10. Файл .SettingContent-ms будет выглядеть следующим образом:
Этот файл открывает Панель управления для пользователя. Интересным аспектом этого файла является элемент <Deep Link>. Этот элемент принимает любой двоичный файл с параметрами и выполняет его. Что произойдет, если мы просто заменим "control".exe “что-то вроде " cmd.exe / c calc.exe"?
Затем, если мы дважды щелкнем на файл:
Что интересно, так это то, что при двойном щелчке мышью на файла нет подсказки "открыть". Windows переходит сразу к выполнению команды. Отлично! Таким образом, у нас есть формат файла, который позволяет выполнять команды шела через открытый файл. Это решает проблему ”какой формат файла использовать" при первоначальном доступе. Итак, как мы можем его доставить? Моя следующая мысль заключалась в том, чтобы увидеть, что произойдет, если этот файл поступает из интернета по ссылке.
Когда этот файл поставляется прямо из интернета, он выполняется, как только пользователь нажимает кнопку “открыть”. Итак, теперь у нас есть формат файла, который позволяет выполнять произвольные команды шела и не отображает никаких предупреждений или диалогов для пользователя. В идеале этот файл должен быть помещен в контейнер более общего типа, например в документ Office. Как упоминалось ранее, Office 2016 блокирует предустановленный список "плохих" типов файлов при связывание и внедрения объектов. Однако, формат файла .SettingContent-ms не включен в этот список:
На этом этапе можно обойти блок расширения файла OLE Office 2016 путем внедрения вредоносного .SettingContent-ms файла через OLE:
Когда документ приходит из интернета с помощью .SettingContent - MS файл, встроенный в него, единственное, что видит пользователь, это приглашение "открыть". Нажатие кнопки "открыть" приведет к выполнению. Если в среде не включены правила ASR, это все, что нужно атакующему для выполнения кода на конечной точке. Мне было любопытно, поэтому я разобрался, как это происходит с включенными правилами ASR. Также стоит отметить, что на момент этой публикации(11 июня) правила ASR не работают в Office, если Office был установлен из магазина Windows.
Включение этих правил довольно просто и может быть выполнено с помощью одной команды PowerShell: “Set-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions Enabled”. Параметр <rule ID> - это идентификатор GUID правила, которое необходимо включить. Идентификатор GUID для каждого правила ASR можно найти здесь(
). Для этого теста, я хочу включить Child Process Creation правило, его индификатор GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A. После включения правила атака больше не работает:
Так как правило предназначено для блокировки создания дочерних процессов из приложения Office, пэйлоад выполняется, но правило блокирует команду. Это заставило меня задуматься о том, как ASR достигает этого, не нарушая некоторой функциональности. Сначала я начал просто тестировать случайные двоичные файлы, чтобы узнать, блокируется ли ASR на основе пути к изображению. Это отняло у меня много времени и не приблизило меня к решению.
Я закончил это тем, что сделал шаг назад и думал о том, какие части офиса должны работать. После запуска ProcMon и немного посмотрев на Process Explorer, щелкнув в Word, я заметил, что все еще были дочерние процессы, порожденные Word-ом.
Я думал, что, возможно, правило ASR блокирует дочерние процессы на основе пути к изображению, но изображения в пути Office могут быть созданы при активации функций. Чтобы проверить эту теорию, я изменил свою .SettingContent-ms файл по пути " Excel.exe”:
Следующим шагом является внедрение этого нового файла в документ Word и посмотреть, блокирует ли ASR "Excel.exe".
Интересно, что ASR позволяет запустить Excel.exe. Таким образом, правило создания ASR дочернего процесса, по-видимому, принимает решения на основе путей из белого списка. Это отправило меня вниз по длинному, длинному пути, пытаясь найти двоичный файл, который я мог бы использовать, который существовал в этом пути “C:\Program Files\Microsoft Office”. Пройдя через несколько из них и пройдя “C:\Windows\System32\cmd.exe” в качестве параметра в командной строке, один из них заработал:
Прекрасно! Мы можем злоупотреблять "AppVLP" для выполнения команд шела. Обычно этот двоичный файл используется для виртуализации приложений, но мы можем использовать его в качестве двоичного файла для злоупотребления, чтобы обойти правило ASR пути к файлу. Чтобы проверить эту полную цепочку, я обновил ее .Файл SettingContent-ms выглядит следующим образом:
Теперь файл нужно просто встроить в документ Office и выполнить:
Как вы можете видеть, с включенным правилом блока OLE Office 2016 и правилом запрета на создания дочернего процесса ASR, .SettingContent-файлы ms в сочетании с "AppVLP.exe" в папке Office позволяет обходить эти элементы управления и выполнять произвольные команды. Хотя документы Office часто помечаются MOTW и открываются в безопасной среде защищенного просмотра, существуют форматы файлов, которые не запускаются в безопасной среде защищенного просмотра.
Вы можете найти больше об этом здесь: (
)
Вот и все)) От себя хочу добавить, что в инструменте unicorn(
) уже есть поддержка создания таких файлов, с вредоносным содержимым.
Код:
https://posts.specterops.io/the-tale-of-settingcontent-ms-files-f1ea253e4d39Для атакующего первоначальный доступ может оказаться довольно сложной задачей, если цель хорошо защищена. При выборе пэйлоада для первоначального доступа атакующий должен выбрать формат файла, который позволяет выполнять произвольный код или команду оболочки с минимальным взаимодействием с пользователем. Эти форматы файлов могут быть редкими, поэтому атакующие полагались на такие типы файлов, как .HTAs, макросы в MS Word, .VBS,.JS и другие.
Очевидно, что существует ограниченное число встроенных расширений файлов в Windows, и по мере улучшения защиты количество эффективных полезных нагрузок продолжает сокращаться.
Кроме того, атакующий должен доставить этот файл для конечного пользователя с уверенностью, что его приведут в исполнение.Опять же, возможности для этого могут быть ограничены, поскольку прямое связывание с пэйлоадом или прикрепление их к электронным письмам, как правило, блокируется антивирусной или браузерной защитой.Именно поэтому злоумышленники прибегают к связыванию и внедрению (OLE), zip файлы и т. д. Для борьбы с доставкой файлов, в Office 2016 ввели блокировку всех опасных форматов файла.Это снижает эффективность одного из наиболее надежных методов доставки полезной нагрузки. При попытке активировать заблокированное расширение файла, Office выдаст ошибку и предотвратит выполнение.
При попытке активировать заблокированное расширение файла Office выдаст ошибку и предотвратит выполнение. В дополнение к блокировке OLE Майкрософт также ввел правила ASR в Windows 10 (которые требует антивирус Windows Defender в качестве зависимости). Целью этих правил является сокращение возможностей, которыми атакующий может злоупотреблять или использовать для выполнения кода в системе. Одним из наиболее эффективных правил ASR это “Блокировка в приложениях office создания дочерних процессов". Это правило блокирует любые попытки создания процесса в качестве дочернего:
При объединении OLE блокировки и ASR правил, выполнения кода на конечной цели из интернета становятся немного ограниченным. Как мы можем обойти этот контроль? Сначала я решил проблему формата файла. Я потратил много времени, просматривая реестр в поисках новых форматов файлов, которые могли бы позволить выполнение. Большинство из этих форматов можно найти в корневом каталоге HKCR:\ registry hive.
После бесчисленных часов чтения спецификаций файлов, я наткнулся на тип файла “.SettingContent-ms ". Этот формат был введен в Windows 10 и позволяет пользователю создавать "ярлыки" для различных настроек. Это просто XML файлы и содержат пути к различным двоичным файлам параметров Windows 10. Файл .SettingContent-ms будет выглядеть следующим образом:
Этот файл открывает Панель управления для пользователя. Интересным аспектом этого файла является элемент <Deep Link>. Этот элемент принимает любой двоичный файл с параметрами и выполняет его. Что произойдет, если мы просто заменим "control".exe “что-то вроде " cmd.exe / c calc.exe"?
Затем, если мы дважды щелкнем на файл:
Что интересно, так это то, что при двойном щелчке мышью на файла нет подсказки "открыть". Windows переходит сразу к выполнению команды. Отлично! Таким образом, у нас есть формат файла, который позволяет выполнять команды шела через открытый файл. Это решает проблему ”какой формат файла использовать" при первоначальном доступе. Итак, как мы можем его доставить? Моя следующая мысль заключалась в том, чтобы увидеть, что произойдет, если этот файл поступает из интернета по ссылке.
Когда этот файл поставляется прямо из интернета, он выполняется, как только пользователь нажимает кнопку “открыть”. Итак, теперь у нас есть формат файла, который позволяет выполнять произвольные команды шела и не отображает никаких предупреждений или диалогов для пользователя. В идеале этот файл должен быть помещен в контейнер более общего типа, например в документ Office. Как упоминалось ранее, Office 2016 блокирует предустановленный список "плохих" типов файлов при связывание и внедрения объектов. Однако, формат файла .SettingContent-ms не включен в этот список:
Код:
https://support.office.com/en-us/article/packager-activation-in-office-365-desktop-applications-52808039-4a7c-4550-be3a-869dd338d834?ui=en-US&rs=en-US&ad=USНа этом этапе можно обойти блок расширения файла OLE Office 2016 путем внедрения вредоносного .SettingContent-ms файла через OLE:
Когда документ приходит из интернета с помощью .SettingContent - MS файл, встроенный в него, единственное, что видит пользователь, это приглашение "открыть". Нажатие кнопки "открыть" приведет к выполнению. Если в среде не включены правила ASR, это все, что нужно атакующему для выполнения кода на конечной точке. Мне было любопытно, поэтому я разобрался, как это происходит с включенными правилами ASR. Также стоит отметить, что на момент этой публикации(11 июня) правила ASR не работают в Office, если Office был установлен из магазина Windows.
Включение этих правил довольно просто и может быть выполнено с помощью одной команды PowerShell: “Set-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions Enabled”. Параметр <rule ID> - это идентификатор GUID правила, которое необходимо включить. Идентификатор GUID для каждого правила ASR можно найти здесь(
Код:
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guardТак как правило предназначено для блокировки создания дочерних процессов из приложения Office, пэйлоад выполняется, но правило блокирует команду. Это заставило меня задуматься о том, как ASR достигает этого, не нарушая некоторой функциональности. Сначала я начал просто тестировать случайные двоичные файлы, чтобы узнать, блокируется ли ASR на основе пути к изображению. Это отняло у меня много времени и не приблизило меня к решению.
Я закончил это тем, что сделал шаг назад и думал о том, какие части офиса должны работать. После запуска ProcMon и немного посмотрев на Process Explorer, щелкнув в Word, я заметил, что все еще были дочерние процессы, порожденные Word-ом.
Я думал, что, возможно, правило ASR блокирует дочерние процессы на основе пути к изображению, но изображения в пути Office могут быть созданы при активации функций. Чтобы проверить эту теорию, я изменил свою .SettingContent-ms файл по пути " Excel.exe”:
Следующим шагом является внедрение этого нового файла в документ Word и посмотреть, блокирует ли ASR "Excel.exe".
Интересно, что ASR позволяет запустить Excel.exe. Таким образом, правило создания ASR дочернего процесса, по-видимому, принимает решения на основе путей из белого списка. Это отправило меня вниз по длинному, длинному пути, пытаясь найти двоичный файл, который я мог бы использовать, который существовал в этом пути “C:\Program Files\Microsoft Office”. Пройдя через несколько из них и пройдя “C:\Windows\System32\cmd.exe” в качестве параметра в командной строке, один из них заработал:
Прекрасно! Мы можем злоупотреблять "AppVLP" для выполнения команд шела. Обычно этот двоичный файл используется для виртуализации приложений, но мы можем использовать его в качестве двоичного файла для злоупотребления, чтобы обойти правило ASR пути к файлу. Чтобы проверить эту полную цепочку, я обновил ее .Файл SettingContent-ms выглядит следующим образом:
Теперь файл нужно просто встроить в документ Office и выполнить:
Как вы можете видеть, с включенным правилом блока OLE Office 2016 и правилом запрета на создания дочернего процесса ASR, .SettingContent-файлы ms в сочетании с "AppVLP.exe" в папке Office позволяет обходить эти элементы управления и выполнять произвольные команды. Хотя документы Office часто помечаются MOTW и открываются в безопасной среде защищенного просмотра, существуют форматы файлов, которые не запускаются в безопасной среде защищенного просмотра.
Вы можете найти больше об этом здесь: (
Код:
https://posts.specterops.io/phishing-against-protected-view-enigma0x3-on-wordpress-com-eed399fca512Вот и все)) От себя хочу добавить, что в инструменте unicorn(
Код:
https://github.com/trustedsec/unicorn
