RedWarden - Гибкий перенаправляющий сервер для CobaltStrike Malleable

(ранее известный как proxy2's плагин malleable_redirector)

Повысим планку устойчивости перенаправляющих серверов C2 к IR, не так ли?

RedWarden

В сфере Red Teaming было несколько разных отличных идей о том, как бороться с incident responders и вводить их в заблуждение, одновременно создавая устойчивую сеть перенаправляющих серверов C2.

Эта работа объединяет многие из этих отличных идей в одну легковесную утилиту, подражающую Apache2 в своей основе — простого HTTP(S) обратного прокси.

Сочетание понимания Malleable C2 профилей, знания пула плохих IP-адресов и гибкости легкого добавления новой логики проверки и ошибочной маршрутизации привело к созданию хитрого средства отпугивания IR-проверок.

RedWarden

Если любой недопустимый входящий пакет достигает RedWarden, вы можете redirect, reset или просто его убрать!

Видите этот `Accept-Encoding`? Каждый запрос Beacon должен содержать этот заголовок и это значение. Что произойдет, если ваш Beacon попадет на системы CloudFlare, и они отправят запрос, из которого будет удален этот заголовок или он будет иметь `Accept-Encoding: gzip` вместо этого? Teamserver отбросит запрос на месте. Установив этот заголовок в разделе конфигурации RedWarden под названием `repair_these_headers`, вы сможете сохранить ваше соединение.:```yaml # # This option repairs Beacon requests's header value by restoring to what was expected in Malleable C2 profile. # # If RedWarden validates inbound request's HTTP headers, according to policy drop_malleable_without_expected_header_value: # "[IP: DROP, reason:6] HTTP request did not contain expected header value:" # # and detects some header is missing or was overwritten along the wire, the request will be dropped. # # We can relax this policy a bit however, since there are situations in which Cache systems (such as Cloudflare) could tamper with our # requests thus breaking Malleable contracts. What we can do is to specify list of headers, that should be overwritten back to their values # defined in provided Malleable profile. # # So for example, if our profile expects: # header "Accept-Encoding" "gzip, deflate"; # # but we receive a request having following header set instead: # Accept-Encoding: gzip # # Because it was tampered along the wire by some of the interim systems (such as web-proxies or caches), we can # detect that and set that header's value back to what was expected in Malleable profile. # # In order to protect Accept-Encoding header, as an example, the following configuration could be used: # repair_these_headers: # - Accept-Encoding # # Default: <empty-list> # repair_these_headers: - Accept-Encoding

### Тонкая настройка политик сброса Есть множество причин, определяющих, может ли запрос быть отклонён. Каждая из этих проверок может быть независимо включена или отключена в соответствии с требованиями или в процессе тонкой настройки или исправления ошибочных решений: Выдержка из `example-config.yaml`:```yaml # # Fine-grained requests dropping policy - lets you decide which checks # you want to have enforced and which to skip by setting them to False # # Default: all checks enabled # policy: # [IP: ALLOW, reason:0] Request conforms ProxyPass entry (url="..." host="..."). Passing request to specified host allow_proxy_pass: True # [IP: ALLOW, reason:2] Peer's IP was added dynamically to a whitelist based on a number of allowed requests allow_dynamic_peer_whitelisting: True # [IP: DROP, reason:1] inbound User-Agent differs from the one defined in C2 profile. drop_invalid_useragent: True # [IP: DROP, reason:2] HTTP header name contained banned word drop_http_banned_header_names: True # [IP: DROP, reason:3] HTTP header value contained banned word: drop_http_banned_header_value: True # [IP: DROP, reason:4b] peer's reverse-IP lookup contained banned word drop_dangerous_ip_reverse_lookup: True # [IP: DROP, reason:4e] Peer's IP geolocation metadata contained banned keyword! Peer banned in generic fashion. drop_ipgeo_metadata_containing_banned_keywords: True # [IP: DROP, reason:5] HTTP request did not contain expected header drop_malleable_without_expected_header: True # [IP: DROP, reason:6] HTTP request did not contain expected header value: drop_malleable_without_expected_header_value: True # [IP: DROP, reason:7] HTTP request did not contain expected (metadata|id|output) section header: drop_malleable_without_expected_request_section: True # [IP: DROP, reason:8] HTTP request was expected to contain (metadata|id|output) section with parameter in URI: drop_malleable_without_request_section_in_uri: True # [IP: DROP, reason:9] Did not found append pattern: drop_malleable_without_prepend_pattern: True # [IP: DROP, reason:10] Did not found append pattern: drop_malleable_without_apppend_pattern: True # [IP: DROP, reason:11] Requested URI does not aligns any of Malleable defined variants: drop_malleable_unknown_uris: True # [IP: DROP, reason:12] HTTP request was expected to contain <> section with URI-append containing prepend/append fragments drop_malleable_with_invalid_uri_append: True

RedWarden

Популярное

Краткое описание

What to do with the request originating not conforming to Beacon, whitelisting or

ProxyPass inclusive statements:

- 'redirect' it to another host with (HTTP 301),

- 'reset' a TCP connection with connecting client

- 'proxy' the request, acting as a reverse-proxy against specified action_url

(may be dangerous if client fetches something it shouldn't supposed to see!)

Valid values: 'reset', 'redirect', 'proxy'.

Default: redirect

Использование

Пример использования

Восстановление поврежденных запросов Beacon

Удаление проблемных заголовков ответов

Часто задаваемые вопросы

Известные проблемы

О боже, почему этот код такое инженерное дерьмо?

Планы (TODO)

☕ Поддержать ☕

Автор```