RedWarden — Cobalt Strike C2 Reverse Proxy, der Blue Teams, AVs, EDRs und Scanner durch Paketinspektion und malleable Profile Correlation abwehrt. | Kitploit

proxy

Malleable C2 Profile Parser, der eingehende HTTP/S-Anfragen streng nach dem Malleable-Vertrag validieren und abweichende Pakete bei Verstoß verwerfen kann (Malleable Profiles 4.0+ mit abgedeckten Varianten)
Fähigkeit, unerwartete und unerwünschte HTTP-Header, die von zwischengeschalteten Systemen wie Proxys und Caches (z. B. CloudFlare) hinzugefügt wurden, zu entfernen/reparieren, um einem gültigen Malleable-Vertrag zu entsprechen.
Integrierte kuratierte massive Blacklist von IPv4-Pools und -Bereichen, die bekanntermaßen mit IT-Sicherheitsanbietern in Verbindung stehen
Mit grep durchsuchbare Ausgabeprotokolleinträge (sowohl im Apache2 Combined Access Log als auch in benutzerdefinierten RedWarden-Formaten), nützlich zur Verfolgung von Peer-Konnektivitätsereignissen/-problemen
Fähigkeit, die IPv4-Adresse eines verbindenden Peers gegen IP-Geolokalisierungs-/WHOIS-Informationen abzufragen und diese mit vordefinierten regulären Ausdrücken zu konfrontieren, um Peers auszuschließen, die außerhalb vertrauenswürdiger Organisationen/Länder/Städte usw. verbinden.
Integrierte Abschwächung von Replay-Angriffen, erzwungen durch Protokollieren der MD5-Hashsummen akzeptierter Anfragen in einer lokal gespeicherten SQLite-Datenbank und Verhindern bereits akzeptierter Anfragen.
Ermöglicht die Definition von ProxyPass-Anweisungen, um Anfragen, die bestimmten URLs entsprechen, an andere Hosts weiterzuleiten.
Unterstützung für mehrere Teamserver
Unterstützung für viele Reverse-Proxy-Hosts/Weiterleitungsseiten, die in zufälliger Reihenfolge bereitgestellt werden – was Lastausgleich des Datenverkehrs oder den Aufbau vielseitigerer Infrastrukturen ermöglicht.
Kann HTTP-Pakete gemäß dem erwarteten Malleable-Vertrag reparieren, falls einige der Header während der Übertragung beschädigt wurden.
Schlaflose Nächte, die mit der Fehlersuche verbracht wurden, warum mein Beacon nicht über CloudFlare/CDN/Domain Fronting funktioniert, sind jetzt vorbei, dank detaillierter, ausführlicher HTTP(S)-Anfrage-/Antwortprotokolle.

Das folgende Beispiel zeigt das Ergebnis von `redirect` zu `https://googole.com`:

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


Nutze es weise, bleib sicher.

### Voraussetzungen

Dieses Programm kann nur auf Linux-Systemen ausgeführt werden, da es fork verwendet, um mehrere Prozesse zu erzeugen.

Außerdem wird erwartet, dass der Systembefehl `openssl` installiert ist, da er zur Generierung von SSL-Zertifikaten verwendet wird.

Installiere abschließend alle Python3-PIP-Anforderungen ganz einfach mit:```shell
bash $ sudo pip3 install -r requirements.txt

Dann kann das Programm gestartet werden, indem man ihm einen Pfad zur Konfigurationsdatei gibt:```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]
  [...]

## Anwendungsfälle

### IP-Geolokalisierung auf Ihre Beacon-Traffic-Ursprünge anwenden

Sie haben Ihr Pre-Phishing und OSINT sehr gut durchgeführt. Sie wissen jetzt, wo Ihre Ziele leben, und haben Hinweise darauf, woher der Traffic stammen sollte, oder zumindest, wie Sie vollständig zusätzlichen Verkehr erkennen können.
Wie kann man IP-Geolokalisierung für Beacon-Anfragen an einem Redirector erzwingen?

RedWarden hilft!

Nehmen wir an, Sie möchten nur Verkehr akzeptieren, der aus Polen, Europa, stammt.
Ihre Pre-Phish-/OSINT-Ergebnisse zeigen, dass:

- `89.64.64.150` ist eine legitime IP eines Ihrer Ziele, die aus Polen stammt
- `59.99.140.76` hingegen ist keine solche und erreichte Ihre Systeme als gewöhnliches Internet-Rauschpaket.

Sie können das RedWarden-Dienstprogramm `lib/ipLookupHelper.py` verwenden, um IP-Geo-Metadaten zu diesen beiden Adressen zu sammeln:```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

und Letzteres ergibt:```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": ""
}

Jeder Eintrag dieses Wörterbuchs akzeptiert reguläre Ausdrücke, die mit bestimmten IP-Geo-Metadaten der IP-Adresse des eingehenden Peers abgeglichen werden.
Wir verwenden drei Einträge in der `country`-Eigenschaft, um Anfragen zu erlauben, die einen der angegebenen Werte haben.

Wenn Sie das in Ihrer Konfiguration eingestellt haben, können Sie mit dem Dienstprogramm `ipLookupHelper`, das einen zweiten Parameter akzeptiert, überprüfen, ob eine andere IP-Adresse den IP-Geolokalisierungs-Diskriminator von RedWarden passieren würde:

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

Die letzte Zeile sagt Ihnen, ob das Paket blockiert oder akzeptiert wird.

Und das war's! Konfigurieren Sie Ihre IP-Geolokalisierungs-Einschränkungen weise und sicher, überprüfen Sie die RedWarden-Protokolle sorgfältig auf IP-Geo-bezogene DROP-Einträge und halten Sie Ihren C2-Verkehr sauber und ordentlich!


### Reparieren manipulierter Beacon-Anfragen

Falls Sie Zwischensysteme wie AWS Lambda oder CloudFlare als Ihre Domain-Fronting-/Redirectoren verwenden, sind Sie sicherlich schon auf eine Situation gestoßen, in der einige Ihrer Pakete nicht vom Teamserver akzeptiert werden konnten, da sie vom vereinbarten Malleable-Vertrag abwichen. War es ein manipulierter oder entfernter HTTP-Header, neu geordnete Cookies oder etwas anderes – ich wette, das hat Ihnen viele Stunden Ihres Lebens gekostet.

Um Probleme beim Einrichtungsprozess von C2-Kanälen und Manipulationen durch Zwischensysteme zu bekämpfen, bietet RedWarden die Möglichkeit, Beacon-Pakete zu reparieren.

Dies geschieht, indem überprüft wird, was das Malleable-Profil von einem Paket erwartet, und es können konfigurierte HTTP-Header gemäß den Anforderungen des Profils auf ihre vereinbarten Werte zurückgesetzt werden.

Betrachten Sie das folgende einfache Profil:```
http-get {
    set uri "/api/abc";
    client {

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

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

### Problembehaftete Antwort-Header entfernen

Mit Cobalt Strike 4.7+ ist mir aufgefallen, dass der Teamserver den Content-Encoding-Header automatisch und ohne Benachrichtigung entfernt, wodurch unser malleable `http-(get|post).server`-Vertrag verletzt wird.

Da RedWarden dem Vertrag folgte, hat Beacon entweder Antworten verworfen oder sie falsch dekomprimiert.

Diese Option gibt an, welche Header aus Teamserver-Antworten entfernt werden sollen, bevor sie den Beacon-Prozess erreichen:```yaml

remove_these_response_headers:
  - Content-Encoding

Sollte die Anfrage bei einer der Prüfungen, die RedWarden bei jeder Anfrage durchführt, fehlschlagen, wird die entsprechende `[DROP, ...]`-Zeile ausgegeben, die Informationen über den **Grund** des Drops enthält.:```
[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 /

Standardmäßig werden all diese Prüfungen durchgesetzt.

Die Aktivierung von `debug: True` wird Ihren Konsolenpuffer mit vielen Logzeilen überfluten, die jeden Schritt beschreiben, den RedWarden in seinem komplexen Entscheidungsprozess durchläuft.
Wenn Sie die vollständigen Körper Ihrer Anfragen und Antworten sehen möchten - setzen Sie `debug` und `trace` auf true und lassen Sie sich in der Logflut begraben!


## FAQ

**- Kann dieses Programm ohne Malleable Profile laufen?**

Ja, das kann es. Die Anfrageprüfungslogik wird jedoch deaktiviert, der Rest sollte einwandfrei funktionieren: IP-Geolokalisierungsdurchsetzung, Reverse-Lookup-Logik, Liste gesperrter IPs usw.

**- Kann dieses Programm leicht an andere C2-Frameworks angepasst werden? Wie Mythic, Covenant, etc?**

Einfach nein. Mit etwas Aufwand - ja. Wie ich unten beschrieben habe, ist das Tool schlecht geschrieben, was die Anpassung an andere C2s schmerzhaft macht. Das ist jedoch mit etwas Zeit und Mühe durchaus machbar.

**- Meine Pakete werden verworfen. Warum?**

Versuchen Sie, `debug: True` und `trace: True` zu aktivieren, um so viele Logs wie möglich zu sammeln. Dann müssten Sie die Logs durchgehen und prüfen, was los ist. Sehen die Pakete genau so aus, wie Sie es in Ihrem Malleable-Profil erwartet haben? Oder gab es vielleicht eine subtile Manipulation im Netzwerk, die dazu führt, dass RedWarden das Paket verwirft (und es könnte auch den Teamserver dazu bringen, es zu verwerfen?).


## Known Issues

- Es _kann_ einen leichten Overhead beim interaktiven Schlafdurchsatz verursachen
- Die ProxyPass-Verarbeitungslogik ist weit davon entfernt, perfekt zu sein, und ist _wirklich_ fehlerhaft (und oh Junge, sie ist hässlich!).
- Seltsame Formen von Konfigurationsdateien können den RedWarden-Parser aus der Bahn werfen und ihn zum Meckern bringen. Der einfachste Ansatz, dies zu umgehen, wäre, `example-config.yaml` zu kopieren und stattdessen daran zu arbeiten.


## Oh mein Gott, warum ist dieser Code so ein technisches Stück Scheiße?

Der Code ist _EIN VERDAMMT GROßES CHAOS_ - das gebe ich zu - und dafür gibt es auch einen ehrlichen Grund: Das Projekt wurde zu 90 % während echter Red-Team-Einsätze entwickelt. Wie wir alle wissen, bringen solche Einsätze so viele Dinge mit sich, dass kaum Zeit für eine ordentliche Entwicklung komplexer Tools bleibt. Ganz zu schweigen von der Kritikalität dieses Programms im Projektaufbau. Das Tool begann ursprünglich als einfaches Proxy-Skript in Python2, entwickelte sich dann zu einem Proxy mit Plugins, erhielt das Plugin `malleable_redirector` - und seitdem habe ich wirklich hart daran gearbeitet, die Abwärtskompatibilität von `proxy2` mit anderen Plugins, die ich dafür erstellt habe, zu erhalten (armer ich, ich war wie Microsoft!) und an seinem ursprünglichen Zweck festzuhalten.

Die Zeit ist jedoch gekommen, es loszulassen, neu zu brandmarken und damit zu beginnen, all die eingeführten schlechten Code-Riecher zu beheben.

Nach all dem gesagten, bitte zeigen Sie etwas Mitgefühl für mich, wenn Sie Probleme melden, Pull-Requests einreichen, und versuchen Sie zu helfen, anstatt zu urteilen! :-) Danke!


## TODO

- Erforschung der Möglichkeit, Threat Intelligence Feeds für schändliche Zwecke zu nutzen - wie zum Beispiel die Erkennung von Sicherheitsanbietern anhand von IPs
- Unterstützung für MaxMind GeoIP-Datenbank/API hinzufügen
- Implementierung von Unterstützung für JA3-Signaturen sowohl bei Erkennung & Blockierung als auch bei Identitätswechsel, um nginx/Apache2/benutzerdefinierte Setups vorzutäuschen.
- Hinzufügen einer eindeutigen Beacon-Tracking-Logik, um die Flexibilität zu bieten, Staging- und Kommunikationsprozesse nach eigenem Ermessen des Proxys zu verweigern.
- Einführung von Tageszeitbeschränkungen bei der Bereitstellung von Weiterleitungsfunktionen (_Proxy nur während der Geschäftszeiten_)
- Proxy-Authentifizierungs- und Autorisierungslogik für CONNECT/Relay hinzufügen.
- Gezielte Weiterleitung für mobile Benutzer hinzufügen
- Konfigurationsoptionen hinzufügen, um benutzerdefinierte HTTP-Header zu definieren, die eingefügt oder entfernt werden sollen
- Konfigurationsoptionen hinzufügen, um das Vorhandensein bestimmter HTTP-Header in Anfragen zu verlangen, die die ProxyPass-Kriterien erfüllen.
- Interaktive Schnittstelle, die es erlaubt, einfache Zeichen einzugeben, die die Ausgabe-Logging-Ausführlichkeit steuern, ähnlich wie bei Nmap
- Die Parserlogik für Malleable-Profile mit [pyMalleableC2](https://github.com/Porchetta-Industries/pyMalleableC2) umschreiben. Als ich anfing, meine eigene Parserlogik zu programmieren, gab es ein solches Toolkit noch nicht auf Github.
- Die gesamte Codebasis umstrukturieren


---

### ☕ Show Support ☕

Dieses und andere Projekte sind das Ergebnis schlafloser Nächte und **viel harter Arbeit**. Wenn Ihnen gefällt, was ich tue, und Sie schätzen, dass ich immer etwas an die Gemeinschaft zurückgebe, [überlegen Sie, mir einen Kaffee zu kaufen](https://github.com/sponsors/mgeeky) _(oder besser ein Bier)_, um einfach Danke zu sagen! 💪 

---

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

RedWarden

Beliebteste

RedWarden - Flexibler CobaltStrike Malleable Redirector

Abstract

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

Verwendung

Beispielhafte Verwendung

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:

Beispielausgaben

Feinabstimmung der Drop-Richtlinien

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