RedWarden — Cobalt Strike C2 Reverse proxy que repele a Blue Teams, AVs, EDRs, scanners mediante la inspección de paquetes y la correlación de perfiles maleables | Kitploit

proxy

El siguiente ejemplo muestra el resultado de `redirect` a `https://googole.com`:

![redirect](https://assets.kitploit.com/production/public/readmes/4322/2ac28c863e766b5aaa2f225c33c225075c7042383d9c51860342a4da63cc6dcd.png)


Úsalo con prudencia, mantente seguro.

### Requisitos

Este programa solo puede ejecutarse en sistemas Linux, ya que utiliza fork para generar múltiples procesos.

Además, se espera que el comando del sistema `openssl` esté instalado, ya que se utiliza para generar certificados SSL.

Finalmente, instala todos los requisitos de Python3 PIP fácilmente con:```shell
bash $ sudo pip3 install -r requirements.txt

Luego, el programa se puede lanzar proporcionándole una ruta al archivo de configuración:```shell
bash$ sudo python3 RedWarden.py -c config.yaml

  [INFO] 19:21:42: Loading 1 plugin...
  [INFO] 19:21:42: Plugin "malleable_redirector" has been installed.
  [INFO] 19:21:42: Preparing SSL certificates and keys for https traffic interception...
  [INFO] 19:21:42: Using provided CA key file: ca-cert/ca.key
  [INFO] 19:21:42: Using provided CA certificate file: ca-cert/ca.crt
  [INFO] 19:21:42: Using provided Certificate key: ca-cert/cert.key
  [INFO] 19:21:42: Serving http proxy on: 0.0.0.0, port: 80...
  [INFO] 19:21:42: Serving https proxy on: 0.0.0.0, port: 443...
  [INFO] 19:21:42: [REQUEST] GET /jquery-3.3.1.min.js
  [INFO] 19:21:42: == Valid malleable http-get request inbound.
  [INFO] 19:21:42: Plugin redirected request from [code.jquery.com] to [1.2.3.4:8080]
  [INFO] 19:21:42: [RESPONSE] HTTP 200 OK, length: 5543
  [INFO] 19:21:45: [REQUEST] GET /jquery-3.3.1.min.js
  [INFO] 19:21:45: == Valid malleable http-get request inbound.
  [INFO] 19:21:45: Plugin redirected request from [code.jquery.com] to [1.2.3.4:8080]
  [INFO] 19:21:45: [RESPONSE] HTTP 200 OK, length: 5543
  [INFO] 19:21:46: [REQUEST] GET /
  [...]
  [ERROR] 19:24:46: [DROP, reason:1] inbound User-Agent differs from the one defined in C2 profile.
  [...]
  [INFO] 19:24:46: [RESPONSE] HTTP 301 Moved Permanently, length: 212
  [INFO] 19:24:48: [REQUEST] GET /jquery-3.3.1.min.js
  [INFO] 19:24:48: == Valid malleable http-get request inbound.
  [INFO] 19:24:48: Plugin redirected request from [code.jquery.com] to [1.2.3.4:8080]
  [...]

## Casos de Uso

### Imponer geolocalización IP a los originadores de tráfico Beacon

Has hecho muy bien tu Pre-Phish y OSINT. Ahora sabes dónde viven tus objetivos y tienes algunas pistas sobre dónde debería originarse el tráfico, o al menos cómo detectar tráfico completamente auxiliar.
¿Cómo imponer geolocalización IP en las solicitudes Beacon en un redireccionador?

¡RedWarden viene al rescate!

Digamos que solo quieres aceptar tráfico originado desde Polonia, Europa.
Tus resultados de Pre-Phish/OSINT indican que:

- `89.64.64.150` es una IP legítima de uno de tus objetivos, originada desde Polonia
- `59.99.140.76` mientras que esta no lo es y llegó a tus sistemas como un paquete de ruido de Internet normal.

Puedes usar la utilidad de RedWarden `lib/ipLookupHelper.py` para recopilar metadatos de geolocalización IP sobre estas dos direcciones:```shell
bash$ python3 ipLookupHelper.py

Usage: ./ipLookupHelper.py <ipaddress> [malleable-redirector-config]

Use this small utility to collect IP Lookup details on your target IPv4 address and verify whether
your 'ip_geolocation_requirements' section of proxy2 malleable-redirector-config.yaml would match that
IP address. If second param is not given - no

y el último da:```shell
bash$ python3 ipLookupHelper.py 59.99.140.76
[dbg] Following IP Lookup providers will be used: ['ip_api_com', 'ipapi_co']
[dbg] Read 1 cached entries from file.
[.] Lookup of: 59.99.140.76
[dbg] Calling IP Lookup provider: ip_api_com
[dbg] New IP lookup entry cached: 59.99.140.76
[.] Output:
{
  "organization": [
    "",
    "BSNL Internet",
    "AS9829 National Internet Backbone"
  ],
  "continent": "Asia",
  "continent_code": "AS",
  "country": "India",
  "country_code": "IN",
  "ip": "59.99.140.76",
  "city": "Palakkad",
  "timezone": "Asia/Kolkata",
  "fulldata": {
    "status": "success",
    "country": "India",
    "countryCode": "IN",
    "region": "KL",
    "regionName": "Kerala",
    "city": "Palakkad",
    "zip": "678001",
    "lat": 10.7739,
    "lon": 76.6487,
    "timezone": "Asia/Kolkata",
    "isp": "BSNL Internet",
    "org": "",
    "as": "AS9829 National Internet Backbone",
    "query": "59.99.140.76"
  },
  "reverse_ip": ""
}

Cada una de las entradas de ese diccionario acepta una expresión regular para coincidir con los metadatos Geo IP determinados de la dirección IP del par entrante.
Usamos tres entradas en la propiedad `country` para permitir solicitudes que tengan uno de los valores especificados.

Con eso configurado, puedes verificar si otra dirección IP pasaría o no por el discriminador de Geolocalización IP de RedWarden con la utilidad `ipLookupHelper` que acepta un segundo parámetro:

![ipLookupHelper IP Geo discriminator](https://assets.kitploit.com/production/public/readmes/4322/f67983439349d959f5ce0b08c45e53de3664d82796fd15273f3bb72f831ac7dc.png)

La última línea te indica si el paquete sería bloqueado o aceptado.

¡Y eso es todo! Configura tus restricciones de Geolocalización IP de manera prudente y segura, inspecciona cuidadosamente los registros de RedWarden en busca de entradas DROP relacionadas con IP Geo y ¡mantén tu tráfico C2 limpio y ordenado!


### Reparar solicitudes Beacon manipuladas

Si utilizas sistemas intermedios como AWS Lambda o CloudFlare como tus redireccionadores / Domain Fronting, seguramente te has encontrado con situaciones en las que algunos de tus paquetes no pudieron ser aceptados por el Teamserver porque se desviaban del contrato maleable acordado. Ya sea una cabecera HTTP alterada o eliminada, cookies reordenadas o cualquier otra cosa — apuesto que te hizo perder muchas horas de tu vida.

Para combatir los problemas del proceso de configuración de canales C2 y las manipulaciones de los sistemas intermedios, RedWarden ofrece funcionalidad para reparar paquetes Beacon.

Lo hace comprobando lo que el Perfil Maleable espera que sea el paquete y puede restaurar las cabeceras HTTP configuradas a sus valores acordados según los requisitos del perfil.

Considera el siguiente perfil simple:```
http-get {
    set uri "/api/abc";
    client {

        header "Accept-Encoding" "gzip, deflate";

        metadata {
            base64url;
            netbios;
            base64url;
            parameter "auth";
        }
    }
    ...

### Eliminar encabezados de respuesta problemáticos

Con Cobalt Strike 4.7+ noté que Teamserver elimina automáticamente el encabezado Content-Encoding sin previo aviso, violando así nuestro contrato `http-(get|post).server` maleable.

Dado que RedWarden seguía el contrato, Beacon estaba descartando respuestas o descomprimiéndolas incorrectamente.

Esta opción especifica qué encabezados provenientes de las respuestas de Teamserver deben eliminarse antes de llegar al proceso de Beacon:```yaml

remove_these_response_headers:
  - Content-Encoding

Si la solicitud falla en alguna de las comprobaciones que RedWarden realiza en cada solicitud, se emitirá la línea `[DROP, ...]` correspondiente que contiene información sobre la **razón** del descarte.:```
[INFO] 2021-04-24/16:48:28: [REQUEST] GET /
[ERROR] 2021-04-24/16:48:29: [DROP, 2021-04-24/18:48:28, reason:1, 128.14.211.186] inbound User-Agent differs from the one defined in C2 profile.
[INFO] 2021-04-24/16:48:29: [DROP, 2021-04-24/18:48:28, 128.14.211.186] "/" - UA: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
[ERROR] 2021-04-24/16:48:29: [REDIRECTING invalid request from 128.14.211.186 (zl-dal-us-gp3-wk107.internet-census.org)] GET /

Por defecto, todas estas comprobaciones están habilitadas.

Activar `debug: True` inundará tu búfer de consola con muchas líneas de registro que describen cada paso que RedWarden toma en su complejo proceso de toma de decisiones. 
Si quieres ver los cuerpos completos de tus solicitudes y respuestas, establece `debug` y `trace` en true y ¡entierra tu consola en una carga de registros!


## FAQ

**- ¿Puede este programa ejecutarse sin un perfil Malleable?**

Sí, puede. Sin embargo, la lógica de inspección de solicitudes estará desactivada; el resto debería funcionar bien: aplicación de geolocalización IP, lógica de búsqueda inversa, lista de IPs prohibidas, etc.

**- ¿Puede este programa adaptarse fácilmente a otros frameworks C2? ¿Como Mythic, Covenant, etc.?**

No, fácilmente no. Con algo de esfuerzo, sí. Como he descrito más abajo, la herramienta está mal escrita, lo que hará que la adaptación a otros C2 sea un dolor. Sin embargo, es totalmente factible con algo de tiempo y esfuerzo.

**- Mis paquetes están siendo descartados. ¿Por qué?**

Intenta activar `debug: True` y `trace: True` para recopilar tantos registros como sea posible. Luego deberías revisar los registros e inspeccionar qué está sucediendo. ¿Los paquetes se ven exactamente como esperabas en tu perfil Malleable? ¿O tal vez hubo una manipulación sutil en la red que hace que RedWarden descarte el paquete (y podría hacer que Teamserver también lo descarte)?


## Problemas conocidos

- Puede _agregar_ una ligera sobrecarga al rendimiento del sueño interactivo
- La lógica de procesamiento de ProxyPass está lejos de ser perfecta y es _realmente_ buggy (¡y vaya que es fea!).
- Formas extrañas de archivos de configuración pueden descarrilar el analizador de RedWarden y hacer que se queje. La forma más fácil de superar esto sería copiar `example-config.yaml` y trabajar en su lugar.


## Oh Dios mío, ¿por qué este código es una mierda ingenieril?

El código es _UN GRAN CAOS DE MIERDA_ – lo admito – y también hay una razón honesta para ello: el proyecto se desarrolló un 90% durante compromisos reales de Red Team. Como todos sabemos, este tipo de compromisos implican tantas cosas que hacer que apenas queda tiempo para un desarrollo adecuado de herramientas complejas. Sin mencionar la criticidad de este programa en la configuración del proyecto. La herramienta comenzó inicialmente como un script proxy simple escrito en Python2, para luego evolucionar como un proxy con plugins, recibió el plugin `malleable_redirector` – y desde entonces he estado tratando muy duro de mantener `proxy2` con compatibilidad hacia atrás (¡pobre de mí, era como Microsoft!) con otros plugins que he creado para él y mantenerme fiel a su propósito original.

Sin embargo, ha llegado el momento de dejarlo ir, cambiarlo de marca y empezar a arreglar todos los malos olores de código introducidos.

Con todo lo dicho, por favor, muestra algo de compasión hacia mí al plantear problemas, enviar pull requests y trata de ayudar en lugar de juzgar. :-)
¡Gracias!


## TODO

- Investigar la posibilidad de usar feeds de inteligencia de amenazas con fines nefastos, como por ejemplo detectar proveedores de seguridad basados en IPs
- Agregar soporte para la base de datos/API de MaxMind GeoIP
- Implementar soporte para firmas JA3 tanto en detección y bloqueo como en suplantación para falsificar configuraciones de nginx/Apache2/personalizadas
- Agregar lógica de seguimiento de balizas únicas para ofrecer flexibilidad para rechazar los procesos de staging y comunicación a discreción del proxy
- Introducir restricciones de día/hora al ofrecer capacidades de redirección (_proxy solo durante horas de oficina_)
- Agregar lógica de autenticación y autorización de proxy en CONNECT/relé
- Agregar redirección dirigida a usuarios móviles
- Agregar opciones de configuración para definir encabezados HTTP personalizados a inyectar o eliminar
- Agregar opciones de configuración para requerir la presencia de encabezados HTTP específicos en solicitudes que pasan los criterios de ProxyPass
- Interfaz interactiva que permite escribir caracteres simples para controlar la verbosidad del registro de salida, similar a la de Nmap
- Reescribir la lógica del analizador de perfiles Malleable utilizando [pyMalleableC2](https://github.com/Porchetta-Industries/pyMalleableC2). Cuando empecé a programar mi propia lógica de análisis, no existía tal herramienta en Github.
- Refactorizar toda la base de código


---

### ☕ Muestra tu apoyo ☕

Este y otros proyectos son el resultado de noches sin dormir y **mucho trabajo duro**. Si te gusta lo que hago y aprecias que siempre devuelvo a la comunidad, [Considera invitarme a un café](https://github.com/sponsors/mgeeky) _(o mejor una cerveza)_ solo para darte las gracias! 💪 

---

## Autor```   
   Mariusz Banach / mgeeky, '19-'21
   <mb [at] binary-offensive.com>
   (https://github.com/mgeeky)

RedWarden

Más Populares

RedWarden - Redirector Maleable Flexible para CobaltStrike

Resumen

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

Usage

Example usage

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:

Ejemplos de salida

Ajuste Fino de Políticas de Drop

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

[IP: ALLOW, reason:0] Request conforms ProxyPass entry (url="..." host="..."). Passing request to specified host

[IP: ALLOW, reason:2] Peer's IP was added dynamically to a whitelist based on a number of allowed requests

[IP: DROP, reason:1] inbound User-Agent differs from the one defined in C2 profile.

[IP: DROP, reason:2] HTTP header name contained banned word

[IP: DROP, reason:3] HTTP header value contained banned word:

[IP: DROP, reason:4b] peer's reverse-IP lookup contained banned word

[IP: DROP, reason:4e] Peer's IP geolocation metadata contained banned keyword! Peer banned in generic fashion.

[IP: DROP, reason:5] HTTP request did not contain expected header

[IP: DROP, reason:6] HTTP request did not contain expected header value:

[IP: DROP, reason:7] HTTP request did not contain expected (metadata|id|output) section header:

[IP: DROP, reason:8] HTTP request was expected to contain (metadata|id|output) section with parameter in URI:

[IP: DROP, reason:9] Did not found append pattern:

[IP: DROP, reason:10] Did not found append pattern:

[IP: DROP, reason:11] Requested URI does not aligns any of Malleable defined variants:

[IP: DROP, reason:12] HTTP request was expected to contain <> section with URI-append containing prepend/append fragments