Цель этой статьи - продемонстрировать шаг за шагом работающую цепочку эксплоитов. Идея состоит в том, чтобы предоставить небольшое руководство для многоступенчатой доставки полезной нагрузки, включая обход обычных средств защиты, имеющихся в корпоративных сетях, для получения RCE. Обход антивируса не является предметом данной статьи, так как он не должен быть предметом какого-либо теста на проникновение, однако будут продемонстрированы способы быстрого обхода практически любых антивирусов на рынке. В более общем смысле, будут обсуждаться любые ограничения, стоящие перед атакующим на пути к получению метерпретера, такие как прокси, песочницы, AMSI и так далее, и мы покажем решения каждой из этих проблем.
В этой статье будет приведен пример доставки полезных данных для red team в 2020 году. Для этого задания, был разработан баш сценарий для автоматизации каждого этапа создания полезной нагрузки. Некоторые части будут показаны позже, и вы можете найти ссылку на скрипт в ссылке.
Сценарий доставки полезной нагрузки
Идея заключалась в том, чтобы выполнить доставку с использованием фишинга через ссылку, которая перенаправила бы пользователя на загрузку и выполнение нашей вредоносной полезной нагрузки. Было несколько ограничений для успешного получения RCE. Во-первых, их рабочие станции могли работать под управлением Windows или MacOS, поэтому мы должны были подготовиться к созданию двух разных полезных нагрузок и доставить их соответствующим образом. Затем у них есть прокси. Надеемся, что их прокси прозрачен, так что это будет не так сложно. Наконец, у них также есть песочница, которая проверяет ссылки и вложения в электронных письмах. Мы сосредоточимся на сценарии Windows, так как это наиболее интересный случай с некоторыми ограничениями. Мы выбрали трехступенчатую полезную нагрузку с файлом HTA для передачи данных через PowerShell чтобы получить доступ к метерпретеру через дроппер. PowerShell до сих пор остается одним из самых надежных способов внедрения кода в память в Windows, даже при наличии AMSI (позже мы покажем, как обойти AMSI).
Демонстрация цепочки эксплоитов: HTA + дроппер PowerShell + Meterpreter
Мы решили подготовить файл HTA, который будет запускать наш дроппер PowerShell на компьютере жертвы с Windows. Многие компании по-прежнему используют Internet Explorer или Edge в качестве браузера по умолчанию, поэтому сценарий на основе файла HTA не редкость.
Итак, у нас будет цепочка эксплоитов, похожая на эту:
Для метерпретера, мы использовали реверс нагрузку HTTPS, поскольку есть прокси. Один вопрос, который мы задали себе: "мы должны использовать поэтапный или безэтапный метерпретер?" Технически, с поэтапным метерпретером, цепочка эксплоитов может привести к 4 этапам доставки кода. Здесь необходимо рассмотреть вопрос об обнаружении. Загружая внешние фрагменты кода в память, мы можем легко получить EDR. Вот почему безэтапный метерпретер должен быть предпочтительным вариантом.
Настройка BeEF и реверс прокси
Следующий вопрос у нас был такой: "Как доставить файл HTA?" Для наших обязательств нам нравится использовать BeEF. Хорошим моментом BeEF является то, что даже в случае сбоя доставки полезной нагрузки браузер все еще подключен, и можно попробовать другие методы. Кроме того, у BeeF уже есть модуль, выполняющий доставку файла HTA, который называется "HTA PowerShell". HTA от BeEF использует дроппер PowerShell для инжекта MSF реверс загрузки HTTPS . Однако мы не будем использовать его из BeEF, потому что он, вероятно, помечен, поэтому мы должны использовать настроенный файл HTA и сказать BeEF, чтобы доставить его.
Это возможно путем настройки параметров модуля HTA PowerShell. Однако, мы обнаружили странное поведение с BeEF, которое просто не захватывало бы нашу полезную нагрузку, обслуживаемую Apache или любым другим HTTP-сервером с конфигурацией по умолчанию. Проблема заключалась в жестко заданном пути внутри источника BeEF, поэтому нам пришлось его удалить. Например, если будет обслуживаться файл с именем "hta.hta", он не будет работать из-за отсутствия расширения, если вы не выполните перенаправление URI.
И тогда наш тестовый файл HTA может быть успешно захвачен BeEF и доставлен. Мы настроили наш реверс прокси-сервер для доставки полезной нагрузки на основе User-Agent в песочницу. Полезно предотвратить захват полезной нагрузки изолированной программной средой, потому что мы будем обслуживать нагрузку только законным агентам пользователя. Таким образом, если в песочнице используется пользовательский агент, отличный от Windows, он не увидит ничего, кроме простой HTML-страницы. Это не надежная защита, а хорошо известная уловка, позволяющая избежать обнаружения в песочнице. Поскольку в целевой компании было несколько ОС, она также использовалась для предоставления правильной нагрузки для каждой ОС. Давайте объясним, как нам удается выполнить настройку полезной нагрузки, чтобы иметь рабочие и необнаруживаемые полезные нагрузки.
Изменение шаблона MSF PowerShell
Сначала мы сосредоточимся на нашей стадии PowerShell, которая будет вызываться внутри файла HTA. Мы начали с базовой полезной нагрузки MSF psh-net:
Просто для развлечения, мы попытались загрузить эту полезную нагрузку без шеллкода (заменив base64 шеллкод на закодированное слово "Привет"), и вот обнаружение, которое мы получили:
Это показывает, что большая часть обнаружения происходит из шаблона PowerShell, а не из самого шеллкода. Таким образом, цель состоит в том, чтобы изменить файл PS настолько, чтобы сигнатуры не совпадали, чтобы избежать статического обнаружения. Для этого есть немало "техник":
Этот подход может быть автоматизирован довольно легко.
Ниже приведены простые примеры того, как мы можем запутать части файла PS:
-->
Разделение шеллкода предотвратит совпадение любой части подписи (позже мы также увидим, как изменить шеллкод):
Для поэтапной полезной нагрузки достаточно всего около 7 блоков, однако, поскольку бесступенчатый шеллкод намного больше, может быть интересно автоматизировать этот шаг, как мы покажем в конце статьи. Разделение поэтапных шеллкодов на блоки по 1337 символов дало более 201 фрагмента, поэтому выполнение этого вручную может быть довольно утомительным.
При отправке нашего измененной нагрузки с шеллкодом MSF по умолчанию в VirusTotal, мы получили результат:
Следующая часть будет о модификации шелл-кода и о том, как избежать его захвата в памяти.
Настройка шеллкода
Модификация шеллкода является "самой сложной" частью настройки полезной нагрузки. Некоторые неуместные изменения могут сломать шеллкод, поэтому важно сделать "безопасные" изменения и проверить их после. Есть несколько мест, где нужно искать подпись. В прошлом все полезные данные MSF кодировались с помощью shikata-ga-nai, если не указано иное. Кодер по-прежнему полезен по сравнению с отсутствием кодера, потому что сырой метерпретер в памяти будет легко перехватываться EDR и IPS/IDS. Кроме того, если вы достаточно хорошо измените шеллкод, вы можете обойти AMSI. Для этого вам не нужны знания по сборке, поскольку некоторые инструкции не требуют пояснений, например, inc или dec.
Первый шаг к модификации шеллкода - извлечь шеллкод и поместить его в файл. Здесь мы возьмем дефолтую MSF нагрузку с реверс HTTPS для демонстрации
Извлечем строку полезной нагрузки в кодировке base64:
Извлечем строку полезной нагрузки в кодировке base64:
Затем вставьте шестнадцатеричную строку в дизассемблер. Мы будем использовать онлайн-дизассемблер https://defuse.ca/online-x86-assembler.htm для демонстрационных целей. Не забудьте поставить правильную архитектуру. Здесь у нас полезная нагрузка x64. Обратите внимание, что, поскольку в PowerShell произошли некоторые изменения, вы не можете заставить 32-битный шеллкод работать с 64-битным процессом PowerShell, вы должны использовать x64-шеллкод.
Вы видите первые дизассемблированные инструкции:
Мы хотим поместить ненужные инструкции в начале ассемблерного кода. Будьте осторожны, если вы поместите инструкции после call cld, шелл-код будет перестанет работать, поскольку строковые операции будут влиять на регистры индекса (esi и edi). Вы можете добавить некоторые инструкции, такие как xor, inc, dec, add, sub, mov, nop и так далее в начало. Есть много способов добавить инструкции, но вы можете просто использовать ассемблер на defuse.ca для сборки инструкций и затем вернуть их обратно в шеллкод. Ниже приведен пример инструкций, которые мы добавили:
Не добавляйте слишком много nop подряд, потому что это может быть помечено как подозрительное. Здесь мы изменили регистр rax, потому что он не используется в начале. Конечно, одну и ту же операцию можно выполнить в разных местах шелл-кода. Когда у вас есть готовый шеллкод, вы можете вставить его в файл и преобразовать в base64.
Наконец, вы можете положить его обратно в файл PS.
Подготовка файла HTA
Итак, теперь, когда у нас есть готовый шеллкод и шаблон PowerShell, нам нужно подготовить файл HTA, который будет выполнять наш дроппер. MSF может создать файл HTA с помощью следующей команды:
Здесь полезной нагрузкой является бесступенчатый реверс HTTPS, но нас не волнует сгенерированная полезная нагрузка, поскольку мы будем использовать HTA для вызова собственной полезной нагрузки PowerShell. Она создаст файл со встроенным VBScript, который будет вызывать PowerShell с закодированной командой, которая выполняет загрузку шелл-кода в память.
Мы декодируем исходную полезную нагрузку и адаптируем ее для выполнения нашей собственной полезной нагрузки PowerShell. Поместите это в файл, и мы собираемся декодировать это:
Результат должен выглядеть так:
Здесь мы хотим удалить загрузку шелл-кода base64 и вместо этого выполнить веб-запрос на выполнение полезной нагрузки PowerShell стадии 2, размещенной на нашем веб-сервере. Мы также должны принять во внимание прокси, прежде чем делать запрос. В PowerShell это выглядело бы примерно так:
Здесь мы устанавливаем User-Agent таким образом, чтобы наш веб-сервер обслуживал правильную нагрузку (в соответствии с User-Agent "Windows"). Затем вам нужно конвертировать ваш измененный дроппер в base64 UTF-16LE и поместить его обратно в файл HTA:
Результат выглядит так:
Наконец, у нас есть готовая цепочка эксплоитов.
Запуск атаки
Время проверить! Наша жертва - Windows 10 Pro версии 1909 (сборка ОС 18363.600) со всеми включенными средствами защиты.
Мы моделируем перехват браузера с BeEF, просматривая страницу, содержащую скрипт перехвата BeEF. В реальной жизни это можно сделать с помощью XSS, фишинг-кампании и так далее
Отсюда мы можем перейти к модулю HTA PowerShell и запустить его. Мы переписываем обслуживающий домен и обработчик HTA для обслуживания нашей пользовательской нагрузки:
HTA доставляется нашей жертве:
Как только жертва нажмет на кнопку Открыть, она загрузит дроппер PowerShell (этап 2) и выполнит его. Затем последний вводит полный шелл-код метерпретера в память (так как он бесступенчатый), поэтому при загрузке модулей метерпретера нас не поймают. Все это, конечно, скрыто от жертвы, и через несколько секунд после щелчка мы получаем сеанс метерпретера. Метерпретер полностью работает и не перехватывается антивирусным решением (в данном случае мы протестировали его с помощью новейшего Защитника Windows).
Заключение
Показанный здесь метод довольно прост и не требует больших усилий, что отвечает требованиям тестирования на проникновение, когда у вас обычно не так много времени, чтобы подготовить что-то или создать необычные инструменты. Обратите внимание, что метод, который был показан здесь для обхода антивирусов, является лишь одним из многих способов, которые можно использовать для этого. На самом деле, мы могли бы пойти еще дальше (и планируем), автоматизировав изменения шеллкода. Тогда у нас будет полностью автоматизированная модификация полезной нагрузки MSF. Вы можете столкнуться с другими средствами защиты, такими как AppLocker, о которых мы здесь не говорим, что сделает такой подход бесполезным, поскольку PowerShell больше не будет в нашем распоряжении. Это может стать темой другого поста в будущем, в зависимости от отзывов, которые мы получим.
Использованные источники
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)
В этой статье будет приведен пример доставки полезных данных для red team в 2020 году. Для этого задания, был разработан баш сценарий для автоматизации каждого этапа создания полезной нагрузки. Некоторые части будут показаны позже, и вы можете найти ссылку на скрипт в ссылке.
Сценарий доставки полезной нагрузки
Идея заключалась в том, чтобы выполнить доставку с использованием фишинга через ссылку, которая перенаправила бы пользователя на загрузку и выполнение нашей вредоносной полезной нагрузки. Было несколько ограничений для успешного получения RCE. Во-первых, их рабочие станции могли работать под управлением Windows или MacOS, поэтому мы должны были подготовиться к созданию двух разных полезных нагрузок и доставить их соответствующим образом. Затем у них есть прокси. Надеемся, что их прокси прозрачен, так что это будет не так сложно. Наконец, у них также есть песочница, которая проверяет ссылки и вложения в электронных письмах. Мы сосредоточимся на сценарии Windows, так как это наиболее интересный случай с некоторыми ограничениями. Мы выбрали трехступенчатую полезную нагрузку с файлом HTA для передачи данных через PowerShell чтобы получить доступ к метерпретеру через дроппер. PowerShell до сих пор остается одним из самых надежных способов внедрения кода в память в Windows, даже при наличии AMSI (позже мы покажем, как обойти AMSI).
Демонстрация цепочки эксплоитов: HTA + дроппер PowerShell + Meterpreter
Мы решили подготовить файл HTA, который будет запускать наш дроппер PowerShell на компьютере жертвы с Windows. Многие компании по-прежнему используют Internet Explorer или Edge в качестве браузера по умолчанию, поэтому сценарий на основе файла HTA не редкость.
Итак, у нас будет цепочка эксплоитов, похожая на эту:
Для метерпретера, мы использовали реверс нагрузку HTTPS, поскольку есть прокси. Один вопрос, который мы задали себе: "мы должны использовать поэтапный или безэтапный метерпретер?" Технически, с поэтапным метерпретером, цепочка эксплоитов может привести к 4 этапам доставки кода. Здесь необходимо рассмотреть вопрос об обнаружении. Загружая внешние фрагменты кода в память, мы можем легко получить EDR. Вот почему безэтапный метерпретер должен быть предпочтительным вариантом.
Настройка BeEF и реверс прокси
Следующий вопрос у нас был такой: "Как доставить файл HTA?" Для наших обязательств нам нравится использовать BeEF. Хорошим моментом BeEF является то, что даже в случае сбоя доставки полезной нагрузки браузер все еще подключен, и можно попробовать другие методы. Кроме того, у BeeF уже есть модуль, выполняющий доставку файла HTA, который называется "HTA PowerShell". HTA от BeEF использует дроппер PowerShell для инжекта MSF реверс загрузки HTTPS . Однако мы не будем использовать его из BeEF, потому что он, вероятно, помечен, поэтому мы должны использовать настроенный файл HTA и сказать BeEF, чтобы доставить его.
Это возможно путем настройки параметров модуля HTA PowerShell. Однако, мы обнаружили странное поведение с BeEF, которое просто не захватывало бы нашу полезную нагрузку, обслуживаемую Apache или любым другим HTTP-сервером с конфигурацией по умолчанию. Проблема заключалась в жестко заданном пути внутри источника BeEF, поэтому нам пришлось его удалить. Например, если будет обслуживаться файл с именем "hta.hta", он не будет работать из-за отсутствия расширения, если вы не выполните перенаправление URI.
И тогда наш тестовый файл HTA может быть успешно захвачен BeEF и доставлен. Мы настроили наш реверс прокси-сервер для доставки полезной нагрузки на основе User-Agent в песочницу. Полезно предотвратить захват полезной нагрузки изолированной программной средой, потому что мы будем обслуживать нагрузку только законным агентам пользователя. Таким образом, если в песочнице используется пользовательский агент, отличный от Windows, он не увидит ничего, кроме простой HTML-страницы. Это не надежная защита, а хорошо известная уловка, позволяющая избежать обнаружения в песочнице. Поскольку в целевой компании было несколько ОС, она также использовалась для предоставления правильной нагрузки для каждой ОС. Давайте объясним, как нам удается выполнить настройку полезной нагрузки, чтобы иметь рабочие и необнаруживаемые полезные нагрузки.
Изменение шаблона MSF PowerShell
Сначала мы сосредоточимся на нашей стадии PowerShell, которая будет вызываться внутри файла HTA. Мы начали с базовой полезной нагрузки MSF psh-net:
Просто для развлечения, мы попытались загрузить эту полезную нагрузку без шеллкода (заменив base64 шеллкод на закодированное слово "Привет"), и вот обнаружение, которое мы получили:
Это показывает, что большая часть обнаружения происходит из шаблона PowerShell, а не из самого шеллкода. Таким образом, цель состоит в том, чтобы изменить файл PS настолько, чтобы сигнатуры не совпадали, чтобы избежать статического обнаружения. Для этого есть немало "техник":
Этот подход может быть автоматизирован довольно легко.
Ниже приведены простые примеры того, как мы можем запутать части файла PS:
-->
-->
Разделение шеллкода предотвратит совпадение любой части подписи (позже мы также увидим, как изменить шеллкод):
Для поэтапной полезной нагрузки достаточно всего около 7 блоков, однако, поскольку бесступенчатый шеллкод намного больше, может быть интересно автоматизировать этот шаг, как мы покажем в конце статьи. Разделение поэтапных шеллкодов на блоки по 1337 символов дало более 201 фрагмента, поэтому выполнение этого вручную может быть довольно утомительным.
При отправке нашего измененной нагрузки с шеллкодом MSF по умолчанию в VirusTotal, мы получили результат:
Следующая часть будет о модификации шелл-кода и о том, как избежать его захвата в памяти.
Настройка шеллкода
Модификация шеллкода является "самой сложной" частью настройки полезной нагрузки. Некоторые неуместные изменения могут сломать шеллкод, поэтому важно сделать "безопасные" изменения и проверить их после. Есть несколько мест, где нужно искать подпись. В прошлом все полезные данные MSF кодировались с помощью shikata-ga-nai, если не указано иное. Кодер по-прежнему полезен по сравнению с отсутствием кодера, потому что сырой метерпретер в памяти будет легко перехватываться EDR и IPS/IDS. Кроме того, если вы достаточно хорошо измените шеллкод, вы можете обойти AMSI. Для этого вам не нужны знания по сборке, поскольку некоторые инструкции не требуют пояснений, например, inc или dec.
Первый шаг к модификации шеллкода - извлечь шеллкод и поместить его в файл. Здесь мы возьмем дефолтую MSF нагрузку с реверс HTTPS для демонстрации
Извлечем строку полезной нагрузки в кодировке base64:
Извлечем строку полезной нагрузки в кодировке base64:
Затем вставьте шестнадцатеричную строку в дизассемблер. Мы будем использовать онлайн-дизассемблер https://defuse.ca/online-x86-assembler.htm для демонстрационных целей. Не забудьте поставить правильную архитектуру. Здесь у нас полезная нагрузка x64. Обратите внимание, что, поскольку в PowerShell произошли некоторые изменения, вы не можете заставить 32-битный шеллкод работать с 64-битным процессом PowerShell, вы должны использовать x64-шеллкод.
Вы видите первые дизассемблированные инструкции:
Мы хотим поместить ненужные инструкции в начале ассемблерного кода. Будьте осторожны, если вы поместите инструкции после call cld, шелл-код будет перестанет работать, поскольку строковые операции будут влиять на регистры индекса (esi и edi). Вы можете добавить некоторые инструкции, такие как xor, inc, dec, add, sub, mov, nop и так далее в начало. Есть много способов добавить инструкции, но вы можете просто использовать ассемблер на defuse.ca для сборки инструкций и затем вернуть их обратно в шеллкод. Ниже приведен пример инструкций, которые мы добавили:
Не добавляйте слишком много nop подряд, потому что это может быть помечено как подозрительное. Здесь мы изменили регистр rax, потому что он не используется в начале. Конечно, одну и ту же операцию можно выполнить в разных местах шелл-кода. Когда у вас есть готовый шеллкод, вы можете вставить его в файл и преобразовать в base64.
Наконец, вы можете положить его обратно в файл PS.
Подготовка файла HTA
Итак, теперь, когда у нас есть готовый шеллкод и шаблон PowerShell, нам нужно подготовить файл HTA, который будет выполнять наш дроппер. MSF может создать файл HTA с помощью следующей команды:
Здесь полезной нагрузкой является бесступенчатый реверс HTTPS, но нас не волнует сгенерированная полезная нагрузка, поскольку мы будем использовать HTA для вызова собственной полезной нагрузки PowerShell. Она создаст файл со встроенным VBScript, который будет вызывать PowerShell с закодированной командой, которая выполняет загрузку шелл-кода в память.
Мы декодируем исходную полезную нагрузку и адаптируем ее для выполнения нашей собственной полезной нагрузки PowerShell. Поместите это в файл, и мы собираемся декодировать это:
Результат должен выглядеть так:
Здесь мы хотим удалить загрузку шелл-кода base64 и вместо этого выполнить веб-запрос на выполнение полезной нагрузки PowerShell стадии 2, размещенной на нашем веб-сервере. Мы также должны принять во внимание прокси, прежде чем делать запрос. В PowerShell это выглядело бы примерно так:
[System.Net.WebRequest]:efaultWebProxy=[System.Net.WebRequest]::GetSystemWebProxy();[System.Net.WebRequest]:
Здесь мы устанавливаем User-Agent таким образом, чтобы наш веб-сервер обслуживал правильную нагрузку (в соответствии с User-Agent "Windows"). Затем вам нужно конвертировать ваш измененный дроппер в base64 UTF-16LE и поместить его обратно в файл HTA:
Результат выглядит так:
Наконец, у нас есть готовая цепочка эксплоитов.
Запуск атаки
Время проверить! Наша жертва - Windows 10 Pro версии 1909 (сборка ОС 18363.600) со всеми включенными средствами защиты.
Мы моделируем перехват браузера с BeEF, просматривая страницу, содержащую скрипт перехвата BeEF. В реальной жизни это можно сделать с помощью XSS, фишинг-кампании и так далее
Отсюда мы можем перейти к модулю HTA PowerShell и запустить его. Мы переписываем обслуживающий домен и обработчик HTA для обслуживания нашей пользовательской нагрузки:
HTA доставляется нашей жертве:
Как только жертва нажмет на кнопку Открыть, она загрузит дроппер PowerShell (этап 2) и выполнит его. Затем последний вводит полный шелл-код метерпретера в память (так как он бесступенчатый), поэтому при загрузке модулей метерпретера нас не поймают. Все это, конечно, скрыто от жертвы, и через несколько секунд после щелчка мы получаем сеанс метерпретера. Метерпретер полностью работает и не перехватывается антивирусным решением (в данном случае мы протестировали его с помощью новейшего Защитника Windows).
Заключение
Показанный здесь метод довольно прост и не требует больших усилий, что отвечает требованиям тестирования на проникновение, когда у вас обычно не так много времени, чтобы подготовить что-то или создать необычные инструменты. Обратите внимание, что метод, который был показан здесь для обхода антивирусов, является лишь одним из многих способов, которые можно использовать для этого. На самом деле, мы могли бы пойти еще дальше (и планируем), автоматизировав изменения шеллкода. Тогда у нас будет полностью автоматизированная модификация полезной нагрузки MSF. Вы можете столкнуться с другими средствами защиты, такими как AppLocker, о которых мы здесь не говорим, что сделает такой подход бесполезным, поскольку PowerShell больше не будет в нашем распоряжении. Это может стать темой другого поста в будущем, в зависимости от отзывов, которые мы получим.
Использованные источники
- @kmkz_security @darksh3llRU @bluedenkare
- https://raw.githubusercontent.com/darksh3llRU/tools/master/psh-net_shellcode_fastchange.sh
- https://github.com/kmkz/Pentesting/AV_Evasion
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)