RedWarden — Proxy inverse C2 Cobalt Strike qui repousse les Blue Teams, AVs, EDRs, scanners grâce à l'inspection de paquets et la corrélation de profils malléables. | Kitploit

proxy

Analyseur de profil Malleable C2 capable de valider strictement les requêtes HTTP/S entrantes selon le contrat malleable et de rejeter les paquets non conformes en cas de violation (profils Malleable 4.0+ avec variantes couvertes)
Capacité à défiltrer/réparer les en-têtes HTTP inattendus et indésirables ajoutés par des systèmes intermédiaires tels que les proxys et les caches (pensez à CloudFlare) afin de se conformer à un contrat Malleable valide.
Liste noire massive et organisée de pools et plages IPv4 connus pour être associés à des fournisseurs de sécurité informatique
Entrées de journal de sortie consultables (à la fois dans le journal d'accès combiné Apache2 et les formats RedWarden personnalisés) utiles pour suivre les événements/problèmes de connectivité des pairs
Capacité à interroger l'adresse IPv4 du pair connecté par rapport aux informations de géolocalisation IP/whois et à les confronter à des expressions régulières prédéfinies pour exclure les pairs se connectant en dehors des organisations/pays/villes de confiance, etc.
Atténuation intégrée des attaques par rejeu, appliquée en enregistrant les sommes de contrôle MD5 des requêtes acceptées dans une base de données SQLite locale et en empêchant les requêtes déjà acceptées.
Permet de définir des instructions ProxyPass pour transmettre des requêtes correspondant à une URL spécifique vers d'autres hôtes
Prise en charge de plusieurs Teamservers
Prise en charge de nombreux hôtes de proxy inverse/sites de redirection donnés dans un ordre aléatoire - ce qui permet d'équilibrer le trafic ou de construire des infrastructures plus polyvalentes
Peut réparer les paquets HTTP selon le contrat malleable attendu au cas où certains en-têtes auraient été corrompus dans le trafic
Les nuits blanches passées à dépanner "pourquoi mon Beacon ne fonctionne pas sur CloudFlare/CDN/Domain Fronting" sont maintenant terminées grâce aux journaux détaillés des requêtes/réponses HTTP(S)

L'exemple ci-dessous montre le résultat de la redirection vers `https://googole.com` :

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


Utilisez-le avec sagesse, restez en sécurité.

### Prérequis

Ce programme ne peut fonctionner que sur les systèmes Linux car il utilise fork pour lancer plusieurs processus.

De plus, la commande système `openssl` doit être installée car elle est utilisée pour générer des certificats SSL.

Enfin, installez facilement toutes les dépendances Python3 PIP avec :```shell
bash $ sudo pip3 install -r requirements.txt

Ensuite, le programme peut être lancé en lui donnant un chemin vers le fichier de configuration:```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]
  [...]

## Cas d'utilisation

### Imposer la géolocalisation IP aux émetteurs de trafic de votre Beacon

Vous avez très bien réalisé votre Pre-Phish et votre OSINT. Vous savez maintenant où vivent vos cibles et avez des indices sur l'origine attendue du trafic, ou au moins comment détecter un trafic complètement auxiliaire.
Comment imposer la géolocalisation IP aux requêtes Beacon sur un redirecteur ?

RedWarden est là pour vous aider !

Disons que vous souhaitez n'accepter que le trafic provenant de Pologne, en Europe.
Vos résultats Pre-Phish/OSINT indiquent que :

- `89.64.64.150` est une IP légitime d'une de vos cibles, provenant de Pologne
- `59.99.140.76` quant à elle, ne l'est pas et a atteint vos systèmes comme un paquet de bruit Internet régulier.

Vous pouvez utiliser l'utilitaire `lib/ipLookupHelper.py` de RedWarden pour collecter les métadonnées de géolocalisation IP de ces deux adresses :```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

et ce dernier donne :```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": ""
}

Chacune des entrées de ce dictionnaire accepte une expression régulière à faire correspondre sur les métadonnées IP Geo déterminées de l'adresse IP du pair entrant.

Nous utilisons trois entrées dans la propriété `country` pour autoriser les requêtes ayant l'une des valeurs spécifiées.

Ayant cela défini dans votre configuration, vous pouvez vérifier si une autre adresse IP passerait ou non le discriminateur de géolocalisation IP de RedWarden avec l'utilitaire `ipLookupHelper` acceptant un second paramètre :

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

La toute dernière ligne vous indique si le paquet serait bloqué ou accepté.

Et voilà ! Configurez vos contraintes de géolocalisation IP avec sagesse et sécurité, inspectez attentivement les logs de RedWarden pour toute entrée DROP liée à la géolocalisation IP et gardez votre trafic C2 propre et ordonné !

### Réparer les requêtes Beacon falsifiées

Si vous utilisez des systèmes intermédiaires tels qu'AWS Lambda ou CloudFlare comme frontaux de domaine / redirecteurs, vous avez sûrement rencontré une situation où certains de vos paquets n'ont pas pu être acceptés par le Teamserver car ils s'écartaient du contrat malléable convenu. Que ce soit un en-tête HTTP falsifié ou supprimé, des cookies réordonnés ou autre chose - je parie que cela vous a fait perdre des heures de votre vie.

Pour lutter contre les problèmes de configuration des canaux C2 et les falsifications des systèmes intermédiaires, RedWarden offre une fonctionnalité pour réparer les paquets Beacon.

Il le fait en vérifiant ce que le profil malléable attend du paquet et peut restaurer les en-têtes HTTP configurés à leurs valeurs convenues selon les exigences du profil.

Considérez le profil simple suivant :```
http-get {
    set uri "/api/abc";
    client {

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

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

### Supprimer les en-têtes de réponse problématiques

Avec Cobalt Strike 4.7+, j'ai remarqué que Teamserver supprime automatiquement l'en-tête Content-Encoding sans aucun avertissement, violant ainsi notre contrat malleable `http-(get|post).server`.

Étant donné que RedWarden respectait le contrat, Beacon supprimait les réponses ou les décompressait incorrectement.

Cette option spécifie quels en-têtes provenant des réponses de Teamserver doivent être supprimés avant d'atteindre le processus Beacon :```yaml

remove_these_response_headers:
  - Content-Encoding

Si la requête échoue à l'un des contrôles que RedWarden effectue sur chaque requête, la ligne `[DROP, ...]` correspondante sera émise contenant des informations sur la **raison**.:```
[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 /

Par défaut, toutes ces vérifications sont appliquées.

Activer `debug: True` inondera votre tampon de console avec de nombreuses lignes de journal décrivant chaque étape du processus décisionnel complexe de RedWarden. 
Si vous souhaitez voir le corps complet de vos requêtes et réponses, réglez `debug` et `trace` sur true et préparez-vous à être submergé par les journaux !


## FAQ

**- Ce programme peut-il fonctionner sans profil Malleable ?**

Oui, il le peut. Cependant, la logique d'inspection des requêtes sera désactivée ; le reste devrait fonctionner correctement : application de la géolocalisation IP, logique de recherche inverse, liste des IP bannies, etc.

**- Ce programme peut-il être facilement adapté à d'autres frameworks C2 ? Comme Mythic, Covenant, etc. ?**

Non facilement. Avec des efforts, oui. Comme je l'ai décrit plus bas, l'outil est mal écrit, ce qui rendra l'adaptation à d'autres C2 fastidieuse. Cependant, c'est tout à fait réalisable avec un peu de temps et d'efforts.

**- Mes paquets sont rejetés. Pourquoi ?**

Essayez d'activer `debug: True` et `trace: True` pour collecter autant de journaux que possible. Ensuite, vous devrez parcourir les journaux et inspecter ce qui se passe. Les paquets ressemblent-ils exactement à ce que vous attendiez dans votre profil Malleable ? Ou peut-être y a-t-il eu une altération subtile le long du réseau qui amène RedWarden à rejeter le paquet (et cela pourrait également amener Teamserver à le rejeter ?).


## Problèmes connus

- Cela _peut_ ajouter une légère surcharge au débit du sommeil interactif
- La logique de traitement de ProxyPass est loin d'être parfaite et est _vraiment_ boguée (et oh là là, c'est moche !).
- Des formes étranges de fichiers de configuration peuvent dérailler l'analyseur de RedWarden et le faire se plaindre. L'approche la plus simple pour contourner ce problème serait de copier `example-config.yaml` et de travailler dessus à la place.


## Oh mon Dieu, pourquoi ce code est-il une telle merde d'ingénierie ?

Le code est _UN VRAI BORDEL MONSTRUEUX_ - je l'admets - et il y a aussi une raison honnête à cela : le projet a été développé à 90 % pendant des missions réelles de Red Team. Comme nous le savons tous, ce genre de missions implique tellement de choses à faire qu'il ne reste quasiment pas de temps pour un développement d'outil complexe approprié. Sans parler de la criticité de ce programme dans la configuration du projet. L'outil a commencé comme un simple script proxy écrit en Python2, pour ensuite évoluer en un proxy avec des plugins, a reçu le plugin `malleable_redirector` - et depuis, j'ai essayé très fort de maintenir la compatibilité ascendante de `proxy2` (pauvre de moi, j'étais comme Microsoft !) avec les autres plugins que j'ai créés et de rester fidèle à son objectif initial.

Cependant, le moment est venu de le laisser tomber, de le renommer et de commencer à corriger toutes les mauvaises pratiques de code introduites.

Cela dit, je vous prie de bien vouloir faire preuve d'un peu de compassion à mon égard lorsque vous ouvrez des issues, soumettez des pull requests et essayez d'aider plutôt que de juger ! :-)
Merci !


## TODO

- Rechercher la possibilité d'utiliser des flux de Threat Intelligence à des fins malveillantes - par exemple détecter les fournisseurs de sécurité en fonction des IPs
- Ajouter le support de la base de données/API MaxMind GeoIP
- Implémenter le support des signatures JA3 à la fois pour la détection et le blocage, et pour l'usurpation afin de simuler des configurations nginx/Apache2/personnalisées.
- Ajouter une logique de suivi unique des beacons pour offrir la flexibilité de refuser les processus de staging et de communication à la discrétion du proxy
- Introduire une contrainte de jour et d'heure lors de l'offre de capacités de redirection (_proxy uniquement pendant les heures de bureau_)
- Ajouter une logique d'authentification et d'autorisation du proxy sur CONNECT/relais.
- Ajouter une redirection ciblée pour les utilisateurs mobiles
- Ajouter des options de configuration pour définir des en-têtes HTTP personnalisés à injecter ou à supprimer
- Ajouter des options de configuration pour exiger que des en-têtes HTTP spécifiques soient présents dans les requêtes répondant aux critères de ProxyPass.
- Interface interactive permettant de taper des caractères simples pour contrôler la verbosité des journaux de sortie, similaire à celle de Nmap
- Réécrire la logique d'analyse du profil Malleable avec [pyMalleableC2](https://github.com/Porchetta-Industries/pyMalleableC2). Lorsque j'ai commencé à coder ma propre logique d'analyse, il n'existait pas encore un tel outil sur Github.
- Refactoriser toute la base de code


---

### ☕ Montrez votre soutien ☕

Ce projet et d'autres sont le fruit de nuits blanches et de **beaucoup de travail acharné**. Si vous aimez ce que je fais et appréciez que je donne toujours en retour à la communauté, [Envisagez de m'offrir un café](https://github.com/sponsors/mgeeky) _(ou mieux une bière)_ juste pour dire merci ! 💪 

---

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

RedWarden

Populaires

RedWarden - Flexible CobaltStrike Malleable Redirector

Résumé

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

Utilisation

Exemple d'utilisation

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:

Exemples de sorties

Réglage fin des politiques de rejet

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