Wiki zur Sammlung von Ressourcen zur Härtung der Red-Team-Infrastruktur
Dieses Wiki soll eine Ressource für den Aufbau einer widerstandsfähigen Red-Team-Infrastruktur bereitstellen. Es wurde als Ergänzung zum Vortrag „Doomsday Preppers: Fortifying Your Red Team Infrastructure“ (Folien) von Steve Borosh (@424f424f) und Jeff Dimmock (@bluscreenofjeff) auf der BSides NoVa 2017 erstellt.
Wenn du eine Ergänzung beisteuern möchtest, reiche bitte einen Pull Request ein oder erstelle ein Issue im Repository.
DANKE an alle Autoren der in diesem Wiki referenzierten Inhalte und an alle, die beigetragen haben!
Beim Entwurf einer Red-Team-Infrastruktur, die einer aktiven Gegenwehr standhalten oder für ein langfristiges Engagement (Wochen, Monate, Jahre) ausgelegt sein soll, ist es wichtig, jedes Asset basierend auf seiner Funktion zu trennen. Dies bietet Widerstandsfähigkeit und Agilität gegenüber dem Blue Team, wenn Kampagnen-Assets erkannt werden. Wenn beispielsweise die Phishing-E-Mail einer Bewertung identifiziert wird, müsste das Red Team nur einen neuen SMTP-Server und einen Payload-Hosting-Server erstellen, anstatt ein komplettes Team-Server-Setup aufzubauen.
Erwäge, diese Funktionen auf verschiedenen Assets zu trennen:
Jede dieser Funktionen wird wahrscheinlich für jede Social-Engineering-Kampagne benötigt. Da eine aktive Incident-Response bei einer Red-Team-Bewertung üblich ist, sollte für jede Kampagne eine neue Infrastruktur implementiert werden.
Um die Widerstandsfähigkeit und Tarnung weiter zu erhöhen, sollte vor jedem Backend-Asset (d. h. Team-Server) ein Redirector platziert werden. Das Ziel ist es, immer einen Host zwischen unserem Ziel und unseren Backend-Servern zu haben. Die Einrichtung der Infrastruktur auf diese Weise macht das Ausrollen frischer Infrastruktur viel schneller und einfacher – kein Aufsetzen eines neuen Team-Servers, keine Migration von Sitzungen und kein erneutes Verbinden nicht verbrannte Assets im Backend erforderlich.
Häufige Redirector-Typen:
Jeder Redirector-Typ hat mehrere Implementierungsoptionen, die am besten zu verschiedenen Szenarien passen. Diese Optionen werden im Abschnitt Redirectors des Wikis ausführlicher besprochen. Redirectors können VPS-Hosts, dedizierte Server oder sogar Apps sein, die auf einer Platform-as-a-Service-Instanz laufen.
Hier ist ein Beispieldesign unter Berücksichtigung der funktionalen Trennung und der Verwendung von Redirectors:
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
Die wahrgenommene Domain-Reputation variiert stark je nach den Produkten, die dein Ziel verwendet, sowie deren Konfiguration. Daher ist die Auswahl einer Domain, die bei deinem Ziel funktioniert, keine exakte Wissenschaft. Open-Source-Intelligence-Sammlung (OSINT) ist entscheidend, um eine fundierte Vermutung über den Zustand der Kontrollen anzustellen und zu bestimmen, gegen welche Ressourcen Domains geprüft werden sollten. Glücklicherweise stehen Online-Werbetreibende vor denselben Problemen und haben einige Lösungen geschaffen, die wir nutzen können.
expireddomains.net ist eine Suchmaschine für kürzlich abgelaufene oder gelöschte Domains. Sie bietet Suche und erweiterte Filterung, wie Alter des Ablaufs, Anzahl der Backlinks, Anzahl der Archive.org-Snapshots, SimilarWeb-Score. Mit der Seite können wir zuvor genutzte Domains registrieren, die über ein Domain-Alter verfügen, ähnlich wie unser Ziel aussehen, ähnlich wie unsere Täuschung aussehen oder einfach wahrscheinlich im Netzwerk unseres Ziels untergehen.
Bei der Auswahl einer Domain für C2 oder Datenerfiltration solltest du in Betracht ziehen, eine Domain zu wählen, die als Finanzen oder Gesundheitswesen kategorisiert ist. Viele Organisationen führen aufgrund möglicher rechtlicher Probleme oder Datensensibilität kein SSL-Middling in diesen Kategorien durch. Es ist auch wichtig sicherzustellen, dass deine gewählte Domain nicht mit früheren Malware- oder Phishing-Kampagnen in Verbindung gebracht wird.
Das Tool CatMyFish von Charles Hamilton(@MrUn1k0d3r) automatisiert Suchen und Web-Kategorisierungsprüfungen mit expireddomains.net und BlueCoat. Es kann modifiziert werden, um weitere Filter auf Suchen anzuwenden oder sogar eine langfristige Überwachung der von dir registrierten Assets durchzuführen.
Ein weiteres Tool, DomainHunter von Joe Vest (@joevest) & Andrew Chiles (@andrewchiles), liefert BlueCoat/WebPulse-, IBM X-Force- und Cisco Talos-Kategorisierung, Domain-Alter, alternative verfügbare TLDs, Archive.org-Links und einen HTML-Bericht. Zusätzlich führt es Prüfungen auf Verwendung in bekannten Malware- und Phishing-Kampagnen mit Malwaredomains.com und MXToolBox durch. Dieses Tool enthält auch OCR-Unterstützung zur Umgehung der BlueCoat/WebPulse-Captchas. Weitere Details findest du im Blogbeitrag zur Erstveröffentlichung des Tools.
Noch ein weiteres Tool, AIRMASTER von Max Harley (@Max_68), verwendet expireddomains.net und Bluecoat, um kategorisierte Domains zu finden. Dieses Tool verwendet OCR zur Umgehung des BlueCoat-Captchas, was die Suchgeschwindigkeit erhöht.
Wenn eine zuvor registrierte Domain nicht verfügbar ist oder du eine selbst registrierte Domain bevorzugst, ist es möglich, Domains selbst zu kategorisieren. Verwende die direkten Links unten oder ein Tool wie Chameleon von Dominic Chell (@domchell). Die meisten Kategorisierungsprodukte übersehen Weiterleitungen oder geklonten Inhalt bei der Bestimmung der Domain-Kategorisierung. Weitere Informationen zur Verwendung von Chameleon findest du in Dominics Beitrag Categorisation is not a security boundary.
Stelle schließlich sicher, dass deine DNS-Einstellungen korrekt propagiert wurden.
Die Wörter einfach und Phishing scheinen nie wirklich zusammenzupassen. Die Einrichtung einer ordnungsgemäßen Phishing-Infrastruktur kann eine echte Qual sein. Das folgende Tutorial vermittelt dir das Wissen und die Werkzeuge, um schnell einen Phishing-Server einzurichten, der „die meisten“ aktuellen Spam-Filter passiert und dir eine RoundCube-Oberfläche für ein einfaches Phishing-Erlebnis bietet, einschließlich Zwei-Wege-Kommunikation mit deinem Ziel. Es gibt viele Setups und Beiträge zum Thema Phishing. Dies ist nur eine Methode.
Sobald du eine Domain hast, die die im vorherigen Abschnitt aufgeführten ordnungsgemäßen Prüfungen besteht, und deinen Phishing-Server hochgefahren hast, musst du ein paar „A“-Records für deine Domain erstellen, wie abgebildet.
Als Nächstes verbinde dich per SSH mit deinem Phishing-Server und stelle sicher, dass du einen ordnungsgemäßen FQDN-Hostnamen in deiner /etc/hosts aufgeführt hast. Beispiel „127.0.0.1 email.yourphishingserver.com email localhost“
Jetzt installierst du das Web-Frontend zum Phishing in nur wenigen einfachen Schritten. Lade zunächst die neueste „BETA“-Version von iRedMail auf deinen Phishing-Server herunter. Der einfache Weg ist, mit der rechten Maustaste auf die Download-Schaltfläche zu klicken, die Link-Adresse zu kopieren und wget zu verwenden, um direkt auf deinen Phishing-Server herunterzuladen. Entpacke es als Nächstes mit „tar -xvf iRedMail-0.9.8-beta2.tar.bz2“. Navigiere in den entpackten Ordner und mache das iRedMail.sh-Skript ausführbar (chmod +x iRedMail.sh). Führe das Skript als root aus, folge den Eingabeaufforderungen, und du musst neu starten, um alles abzuschließen.
Du solltest sicherstellen, dass alle ordnungsgemäßen DNS-Records auf deinen Mailserver zeigen. (https://docs.iredmail.org/setup.dns.html). Für DKIM sollte der neue Befehl „amavisd-new showkeys“ sein, um deinen DKIM-Schlüssel aufzulisten.
Für DMARC können wir (https://www.unlocktheinbox.com/dmarcwizard/) verwenden, um unseren DMARC-Eintrag zu generieren.
Erstelle nun einen Benutzer zum Phishing.
Melde dich mit deinem neuen Benutzer bei der RoundCube-Oberfläche an und phish verantwortungsvoll!
Cobalt Strike bietet anpassbare Spearphishing-Funktionalität zur Unterstützung von Pentest- oder Red-Team-E-Mail-Phishing. Es unterstützt Vorlagen in HTML- und/oder Klartextformaten, Anhänge, eine Bounceback-Adresse, URL-Einbettung, Verwendung entfernter SMTP-Server und Sendeverzögerungen pro Nachricht. Eine weitere interessante Funktion ist die Möglichkeit, jedem Benutzer einen eindeutigen Token in seiner eingebetteten URL für das Klick-Tracking hinzuzufügen.
Weitere detaillierte Informationen findest du in diesen Ressourcen:
Für Red-Team- und Phishing-Übungen, bei denen Kundenvertrauen und OPSEC wichtig sind, bietet die Speicherung erfasster Kundendaten und primärer Infrastruktur auf den eigenen Servern des Kunden (On-Premises) erhebliche Vorteile gegenüber reinen Cloud-Lösungen. Dieser Ansatz verwendet Cloud-Assets nur für dünne Redirectors und Fronts, während sensible Operationen intern gehalten werden.
Ein robustes On-Premises-Evilginx-Setup besteht typischerweise aus:
Cookie-Gating reduziert Bot-Treffer und automatisiertes Scannen, indem ein bestimmtes Cookie für den Zugriff auf das Phishing-Portal erforderlich ist:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Diese Regel leitet Anfragen an die Portal-Domain um, die das erforderliche Cookie nicht enthalten, während Favicon-Anfragen ausgenommen werden, um Umleitungsschleifen zu verhindern.
### Beispiel-Caddy-Konfiguration```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Führen Sie Evilginx auf dem internen Knoten mit den entsprechenden Flags aus:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Wichtig:** Evilginx sollte nur aus dem privaten Netzwerk erreichbar sein; veröffentlichen Sie seine IP niemals in öffentlichem DNS.
### OPSEC- und Härtungs-Checkliste
1. **Evilginx-IPs niemals in öffentlichem DNS freigeben** – Nur private Netzwerke verwenden
2. **Sensible Daten nur auf Client-Servern speichern** – Redirectors dürfen erfasste Anmeldedaten nicht speichern
3. **Redirectors härten** – Domains rotieren, kurze TTLs verwenden, mehrere kurzlebige Redirectors einsetzen
4. **WAF/Firewall-Regeln implementieren** – Cookie-Prüfungen, IP-Allowlists oder UA-Validierung verwenden
5. **Protokollierung und Aufbewahrung trennen** – Zugriffsprotokolle auf Caddy und Erfassungsprotokolle auf dem Evilginx-Host führen
6. **Fingerprints vermeiden** – Keine vorhersehbaren Muster oder identischen TLS-Fingerprints verwenden
Dieser hybride Ansatz (öffentlicher Redirector/private Erfassung) bietet die Widerstandsfähigkeit von Cloud Fronting, während er die Sicherheits- und rechtlichen Vorteile der Aufbewahrung sensibler Operationen vor Ort beibehält.
## Phishing-Frameworks
Abgesehen von der Einrichtung einer eigenen Phishing-Umgebung oder der Verwendung eines Pentest- oder Red-Teaming-Frameworks wie Cobalt Strike gibt es zahlreiche Tools und Frameworks, die sich auf E-Mail-Phishing spezialisiert haben. Dieses Wiki wird nicht im Detail auf jedes Framework eingehen, aber unten sind einige Ressourcen für jedes gesammelt:
### Gophish
* [Gophish Offizielle Website](https://getgophish.com/)
* [Gophish GitHub-Repo](https://github.com/gophish/gophish)
* [Gophish Benutzerhandbuch](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Phishing Frenzy Offizielle Website](https://www.phishingfrenzy.com/)
* [Phishing Frenzy GitHub-Repo](https://github.com/pentestgeek/phishing-frenzy)
* [Einführung in Phishing Frenzy – Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [The Social-Engineer Toolkit GitHub-Repo](https://github.com/trustedsec/social-engineer-toolkit)
* [The Social-Engineer Toolkit Benutzerhandbuch](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (ehemals FirePhish)
* [FiercePhish GitHub-Repo](https://github.com/Raikia/FiercePhish)
* [FiercePhish Wiki](https://github.com/Raikia/FiercePhish/wiki)
# Redirectors
## SMTP
„Redirector“ ist vielleicht nicht das beste Wort, um zu beschreiben, was wir erreichen wollen, aber das Ziel ist dasselbe wie bei unserer anderen Umleitung. Wir möchten alle Spuren unseres Phishing-Ursprungs aus den endgültigen E-Mail-Headern entfernen und einen Puffer zwischen dem Opfer und unserem Backend-Server schaffen. Idealerweise ist der SMTP-Redirector schnell eingerichtet und leicht außer Betrieb zu nehmen.
Es gibt zwei wichtige Aktionen, die wir einen SMTP-Redirector konfigurieren möchten, um sie auszuführen:
### Sendmail
#### Vorherige Server-Header entfernen
Fügen Sie die folgende Zeile am Ende von `/etc/mail/sendmail.mc` hinzu:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Addiere zum Ende von /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Entfernen der IP-Adresse des Absenders aus dem „Received From“-Header von E-Mails](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Entfernen von Headern aus der Postfix-Konfiguration](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Konfigurieren einer Catch-All-Adresse
Dadurch wird jede E-Mail, die an *@phishdomain.com empfangen wird, an eine ausgewählte E-Mail-Adresse weitergeleitet. Dies ist äußerst nützlich, um Antworten oder Bounce-Backs auf eine Phishing-E-Mail zu empfangen.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Fügen Sie die folgende Zeile direkt vor //Mailer Definitions// (gegen Ende) in /etc/mail/sendmail.mc ein:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Fügen Sie die folgende Zeile am Ende von `/etc/mail/virtusertable` hinzu:```bash
@phishdomain.com external-relay-address
Hinweis: Die beiden Felder sollten durch Tabulatoren getrennt sein
Postfix bietet eine einfachere Alternative zu sendmail mit breiterer Kompatibilität. Postfix bietet außerdem volle IMAP-Unterstützung mit Dovecot. Dies ermöglicht es Testern, in Echtzeit mit Phishing-Zielen zu korrespondieren, die auf die ursprüngliche Nachricht antworten, anstatt sich auf die Catch-all-Adresse zu verlassen und eine neue Nachricht mit Ihrem Phishing-Tool erstellen zu müssen.
Eine vollständige Anleitung zur Einrichtung eines Postfix-Mailservers für Phishing ist in Julian Catrambones (@n0pe_sled) Beitrag Mail Servers Made Easy verfügbar.
Hinweis: Bei Verwendung von C2-Redirectors sollte ein externer Listener auf Ihrem Post-Exploitation-Framework konfiguriert werden, um Staging-Traffic über die Redirector-Domain zu leiten. Dadurch wird der kompromittierte Host wie beim C2-Traffic selbst über den Redirector gestaged.
socat kann verwendet werden, um eingehende DNS-Pakete auf Port 53 an unseren Team-Server umzuleiten. Obwohl diese Methode funktioniert, haben einige Benutzer Staging-Probleme mit Cobalt Strike und/oder Latenzprobleme bei dieser Methode gemeldet. Bearbeitet am 21.04.2017: Der folgende socat-Befehl scheint dank Tests von @xorrior gut zu funktionieren:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables für DNS
iptables-DNS-Weiterleitungsregeln haben sich als gut funktionierend mit Cobalt Strike erwiesen. Es scheint keine der Probleme zu geben, die socat bei der Verarbeitung dieser Art von Traffic hat.
Ein Beispiel-Regelsatz für einen DNS-Redirector ist unten aufgeführt.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Auch: Ändern Sie die "FORWARD"-Chain-Policy auf "ACCEPT"
Einige haben möglicherweise die Anforderung oder das Bedürfnis, einen C2-Server in einem internen Netzwerk zu hosten. Mit einer Kombination aus IPTABLES, SOCAT und Reverse-SSH-Tunneln können wir dies sicherlich auf folgende Weise erreichen.
In diesem Szenario haben wir unseren volatilen Redirector, der IPTables verwendet, um den gesamten DNS-Verkehr mit der zuvor in diesem Abschnitt beschriebenen Regelbeispiel weiterzuleiten. Als Nächstes erstellen wir einen Reverse-SSH-Port-Forward-Tunnel von unserem internen C2-Server zu unserem Haupt-Redirector. Dadurch wird jeglicher Verkehr, den der Haupt-Redirector auf Port 6667 empfängt, an den internen C2-Server auf Port 6667 weitergeleitet. Starten Sie nun socat auf unserem Team-Server, um eingehenden TCP-Verkehr auf Port 6667 auf UDP-Port 53 zu forken, auf dem unser DNS-C2 lauschen muss. Schließlich richten wir ähnlich eine socat-Instanz auf dem Haupt-Redirector ein, um eingehenden UDP-Verkehr auf Port 53 in unseren SSH-Tunnel auf Port 6667 umzuleiten.
Hinweis: Bei Verwendung von C2-Redirectors sollte ein fremder Listener auf Ihrem Post-Exploitation-Framework konfiguriert werden, um Staging-Verkehr über die Redirector-Domain zu senden. Dadurch wird der kompromittierte Host wie der C2-Verkehr selbst über den Redirector gestaged.
socat bietet eine 'dumme Pipe'-Umleitung. Jede Anfrage, die socat auf der angegebenen Quell-Interface/Port empfängt, wird an die Ziel-IP/den Ziel-Port umgeleitet. Es gibt keine Filterung oder bedingte Umleitung. Apache mod_rewrite hingegen bietet eine Reihe von Methoden, um Ihr Phishing zu stärken und die Widerstandsfähigkeit Ihrer Testinfrastruktur zu erhöhen. mod_rewrite hat die Fähigkeit, bedingte Umleitungen basierend auf Anfrageattributen wie URI, User-Agent, Query-String, Betriebssystem und IP durchzuführen. Apache mod_rewrite verwendet htaccess-Dateien, um Regelsätze zu konfigurieren, wie Apache jede eingehende Anfrage behandeln soll. Mit diesen Regeln könnten Sie beispielsweise Anfragen an Ihren Server mit dem Standard-Wget-User-Agent auf eine legitime Seite auf der Website Ihres Ziels umleiten.
Kurz gesagt: Wenn Ihr Redirector bedingte Umleitung oder erweiterte Filterung durchführen muss, verwenden Sie Apache mod_rewrite. Andernfalls reicht socat-Umleitung mit optionaler iptables-Filterung aus.
socat kann verwendet werden, um eingehende TCP-Pakete auf einem bestimmten Port an unseren Team-Server umzuleiten.
Die grundlegende Syntax, um TCP-Port 80 auf localhost auf Port 80 auf einem anderen Host umzuleiten, lautet:``` socat TCP4-LISTEN:80,fork TCP4::80
Wenn Ihr Redirector mit mehr als einer Netzwerkschnittstelle konfiguriert ist, kann socat über die folgende Syntax an eine bestimmte Schnittstelle, per IP-Adresse, gebunden werden:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
In diesem Beispiel ist 10.0.0.2 eine der lokalen IP-Adressen des Redirectors und 1.2.3.4 die IP-Adresse des entfernten Team-Servers.
Zusätzlich zu socat kann iptables über NAT eine „dumme Pipe“-Umleitung durchführen. Um den lokalen Port 80 des Redirectors an einen entfernten Host weiterzuleiten, verwenden Sie die folgende Syntax:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH für HTTP
Wir haben zuvor die Nutzung von SSH für DNS-Tunnel behandelt. SSH funktioniert als solides und robustes Mittel, um NAT zu durchbrechen und einen Weg zu schaffen, über den sich die Implantate mit einem Redirector und in Ihre Serverumgebung verbinden können. Bevor Sie einen SSH-Redirector einrichten, müssen Sie die folgenden Zeilen zu `/etc/ssh/sshd_config` hinzufügen:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Um den lokalen Port 80 des Redirectors an Ihren internen Server weiterzuleiten, verwenden Sie die folgende Syntax auf dem internen Server:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
Du kannst auch mehr als einen Port weiterleiten, zum Beispiel wenn du 443 und 80 gleichzeitig offen haben möchtest:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
Beim Ausliefern von Payloads und Web-Ressourcen möchten wir die Möglichkeit für Incident Responder minimieren, Dateien zu untersuchen, und die Chancen auf eine erfolgreiche Ausführung des Payloads erhöhen – sei es zur Etablierung von C2 oder zur Informationssammlung.
Apache-Mod_Rewrite-Nutzung und Beispiele von Jeff Dimmock:
Weitere Apache-mod_rewrite-Nutzung und Beispiele:
Für die automatische Einrichtung von Apache Mod_Rewrite auf einem Redirector-Server, schauen Sie sich Julain Catrambones (@n0pe_sled) Blogbeitrag Mod_Rewrite Automatic Setup und das zugehörige Tool an.
Die Absicht hinter der Weiterleitung von C2-Traffic ist zweierlei: den Backend-Teamserver zu verschleiern und bei einem Besuch durch einen Incident Responder wie eine legitime Website zu wirken. Durch die Nutzung von Apache mod_rewrite und angepassten C2-Profilen oder anderem Proxying (z. B. mit Flask) können wir zuverlässig den echten C2-Traffic von Untersuchungstraffic filtern.
Aufbauend auf „C2-Weiterleitung" oben ist eine weitere Methode, Ihren Redirector-Server die SSL-Proxy-Engine von Apache nutzen zu lassen, um eingehende SSL-Anfragen anzunehmen und diese als Anfragen an einen Reverse-HTTPS-Listener zu proxen. Verschlüsselung wird in allen Phasen verwendet, und Sie können SSL-Zertifikate auf Ihrem Redirector nach Bedarf rotieren.
Damit dies mit Ihren mod_rewrite-Regeln funktioniert, müssen Sie Ihre Regeln in „/etc/apache2/sites-available/000-default-le-ssl.conf" platzieren, vorausgesetzt Sie haben LetsEncrypt (auch CertBot) zur Installation Ihres Zertifikats verwendet. Außerdem benötigen Sie die folgenden Zeilen in derselben Konfigurationsdatei, um die SSL-ProxyPass-Engine zu aktivieren:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Weitere Apache mod_rewrite-Ressourcen
* [Automatisierung von Apache mod_rewrite und Cobalt Strike-Profilen](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Offizielle Apache 2.4 mod_rewrite-Dokumentation](http://httpd.apache.org/docs/current/rewrite/)
* [Apache mod_rewrite-Einführung](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Ein ausführlicher Leitfaden zu mod_rewrite für Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod_rewrite-for-apache--net-6708)
* [Mod_Rewrite/.htaccess-Syntaxprüfer](http://www.htaccesscheck.com/)
# Modifizieren von C2-Datenverkehr
## Cobalt Strike
Cobalt Strike modifiziert seinen Datenverkehr mit Malleable C2-Profilen. Profile bieten hochgradig anpassbare Optionen zur Modifizierung des Erscheinungsbilds Ihres Server-C2-Datenverkehrs im Netzwerk. Malleable C2-Profile können verwendet werden, um die Umgehung der Incident-Response-Erkennung zu stärken, bekannte Gegner zu imitieren oder sich als legitime interne Anwendungen des Ziels auszugeben.
* [Offizielle Malleable C2-Profile - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Malleable Command and Control-Dokumentation - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - Ein Weg zur Privilegienerweiterung - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [Eine mutige neue Welt: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [So schreiben Sie Malleable C2-Profile für Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [In-Memory-Umgehung (Videoserie) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Wenn Sie mit der Erstellung oder Modifizierung von Malleable C2-Profilen beginnen, ist es wichtig, die Datengrößenlimits für die Platzierung der Beacon-Informationen zu beachten. Beispielsweise erfordert die Konfiguration des Profils zum Senden großer Datenmengen in einem URL-Parameter viele Anfragen. Weitere Informationen hierzu finden Sie im Blogbeitrag von Raphael Mudge [Vorsicht vor langsamen Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Wenn Sie Probleme mit Ihrem Malleable C2-Profil haben und feststellen, dass die Teamserver-Konsole Fehler ausgibt, lesen Sie den Blogbeitrag von Raphael Mudge [Gebrochene Versprechen und Malleable C2-Profile](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) für Tipps zur Fehlerbehebung.
## Empire
Empire verwendet Kommunikationsprofile, die Anpassungsoptionen für die GET-Request-URIs, den User-Agent und die Header bieten. Das Profil besteht aus jedem Element, getrennt durch das Pipe-Zeichen, und wird mit der Option `set DefaultProfile` im Kontextmenü `listeners` festgelegt.
Hier ist ein Beispiel für ein Standardprofil:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
Alternativ kann der Wert von DefaultProfile gesetzt werden, indem die Datei /setup/setup_database.py vor der ersten Einrichtung von Empire modifiziert wird. Dadurch wird das Standard-Kommunikationsprofil geändert, das Empire verwenden wird.
Zusätzlich zum Kommunikationsprofil sollten Sie in Betracht ziehen, die Staging-URIs des Empire-Servers, die Server-Header und den Standard-Webseiteninhalt anzupassen, indem Sie die Schritte befolgen, die in Joe Vests (@joevest) Beitrag Empire - Modifying Server C2 Indicators vorgestellt werden.
Die Nutzung vertrauenswürdiger, legitimer Webdienste für C2 kann einen wertvollen Vorteil gegenüber der Verwendung selbst konfigurierter Domains und Infrastruktur bieten. Konfigurationszeit und -komplexität variieren je nach verwendeter Technik und Dienst. Ein beliebtes Beispiel für die Nutzung von Diensten Dritter zur C2-Umleitung ist Domain Fronting.
Domain Fronting ist eine Technik, die von Zensurumgehungsdiensten und -Apps verwendet wird, um Datenverkehr über legitime und hochvertrauenswürdige Domains zu leiten. Beliebte Dienste, die Domain Fronting unterstützen, sind Google App Engine, Amazon CloudFront und Microsoft Azure. Es ist wichtig zu beachten, dass viele Anbieter wie Google und Amazon Maßnahmen gegen Domain Fronting implementiert haben, sodass einige verlinkte Ressourcen oder Informationen in diesem Wiki möglicherweise veraltet sind, wenn Sie sie verwenden möchten.
Kurz gesagt: Der Datenverkehr verwendet den DNS- und SNI-Namen des vertrauenswürdigen Dienstanbieters, im folgenden Beispiel wird Google verwendet. Wenn der Datenverkehr vom Edge-Server (z. B. unter gmail.com) empfangen wird, wird das Paket an den Origin-Server (z. B. phish.appspot.com) weitergeleitet, der im Host-Header des Pakets angegeben ist. Je nach Dienstanbieter leitet der Origin-Server den Datenverkehr entweder direkt an eine bestimmte Domain weiter, die wir auf unseren Team-Server zeigen lassen, oder es ist eine Proxy-App für den letzten Weiterleitungssprung erforderlich.
Für detailliertere Informationen darüber, wie Domain Fronting funktioniert, siehe das Whitepaper Blocking-resistant communication through domain fronting und die meek-Dokumentation des TOR-Projekts.
Zusätzlich zu den standardmäßig frontbaren Domains, wie z. B. jeder google.com-Domain, ist es möglich, andere legitime Domains für Fronting zu nutzen.
Weitere Informationen zur Suche nach frontbaren Domains finden Sie hier:
Viele PaaS- und SaaS-Anbieter stellen eine statische Subdomain oder URL für die Nutzung mit einer bereitgestellten Instanz bereit. Wenn die zugehörige Domain allgemein hochvertrauenswürdig ist, können die Instanzen Ihrer C2-Infrastruktur zusätzliches Vertrauen verleihen, verglichen mit einer gekauften Domain und einem VPS.
Für die Einrichtung der Umleitung müssen Sie einen Dienst identifizieren, der eine statische Subdomain oder URL als Teil einer Instanz vergibt. Anschließend muss die Instanz entweder mit netzwerk- oder anwendungsbasierter Umleitung konfiguriert werden. Die Instanz fungiert als Proxy, ähnlich wie die anderen in diesem Wiki besprochenen Redirectoren.
Eine weitere interessante Technik, die weitere Forschung verdient, ist die Verwendung übermäßig permissiver Amazon-S3-Buckets für C2. Lesen Sie den Beitrag S3 Buckets for Good and Evil von Andrew Luke (@Sw4mp_f0x) für weitere Details darüber, wie S3-Buckets für C2 verwendet werden könnten. Diese Technik könnte mit den C2-Fähigkeiten von Empire über Drittanbieter kombiniert werden, um die legitimen S3-Buckets des Ziels gegen es zu verwenden.
Ein weiteres Beispiel für die Verwendung von PaaS für C2 finden Sie in Databases and Clouds: SQL Server as a C2 von Scott Sutherland (@_nullbind).
Andere Dienste von Drittanbietern wurden in der Vergangenheit in freier Wildbahn für C2 verwendet. Die Nutzung von Websites Dritter, die das schnelle Posten oder Ändern von benutzergenerierten Inhalten ermöglichen, kann Ihnen helfen, reputationsbasierte Kontrollen zu umgehen, insbesondere wenn die Website des Drittanbieters allgemein vertrauenswürdig ist.
Sehen Sie sich diese Ressourcen für andere C2-Optionen von Drittanbietern an:
Angriffsinfrastruktur ist oft leicht zu identifizieren und wirkt wie eine Hülle eines legitimen Servers. Wir müssen zusätzliche Schritte mit unserer Infrastruktur unternehmen, um die Wahrscheinlichkeit zu erhöhen, sich unter echte Server entweder der Zielorganisation oder von Diensten, die das Ziel möglicherweise nutzt, zu mischen.
Redirectoren können helfen, sich anzupassen, indem sie ungültige URIs umleiten, Phishing-Payload-Links ablaufen lassen oder gängige Techniken von Incident Respondern blockieren; es sollte jedoch auch dem zugrunde liegenden Host und seinen Indikatoren Aufmerksamkeit geschenkt werden.
Zum Beispiel behandelt John Menerick (@Lord_SQL) in dem Beitrag Fall of an Empire Methoden zur Erkennung von Empire-Servern im Internet.
Um diese und ähnliche Indikatoren zu bekämpfen, ist es eine gute Idee, C2-Datenverkehrsmuster zu modifizieren, Server-Landingpages zu ändern, offene Ports einzuschränken und Standard-Antwortheader zu ändern.
Weitere Details dazu, wie diese und andere Taktiken für mehrere Angriffs-Frameworks umgesetzt werden, finden Sie in diesen Beiträgen:
Angriffsinfrastruktur kann genauso angegriffen werden wie jeder andere mit dem Internet verbundene Host und sollte aufgrund der verwendeten Daten und der Verbindungen in Zielumgebungen als HOCHSENSIBEL betrachtet werden.
Im Jahr 2016 wurden Remote-Codeausführungsschwachstellen in den gängigsten Angriffstools offengelegt:
iptables sollte verwendet werden, um unerwünschten Datenverkehr zu filtern und den Datenverkehr zwischen erforderlichen Infrastrukturelementen einzuschränken. Wenn beispielsweise ein Cobalt-Strike-Team-Server Assets nur an einen Apache-Redirector ausliefert, sollten iptables-Regeln nur Port 80 von der Quell-IP des Redirectors zulassen. Dies ist besonders wichtig für alle Verwaltungsschnittstellen wie SSH oder den Standardport 50050 von Cobalt Strike. Erwägen Sie auch, IPs aus Nicht-Zielländern zu blockieren. Alternativ können Sie Hypervisor-Firewalls verwenden, die von Ihren VPS-Anbietern bereitgestellt werden. Digital Ocean bietet beispielsweise Cloud Firewalls an, die einen oder mehrere Droplets schützen können.
chattr kann auf Team-Servern verwendet werden, um zu verhindern, dass Cron-Verzeichnisse modifiziert werden. Mit chattr können Sie jedem Benutzer, einschließlich root, das Ändern einer Datei untersagen, bis das chattr-Attribut entfernt wird.
SSH sollte auf Public-Key-Authentifizierung beschränkt sein und so konfiguriert werden, dass Benutzer mit eingeschränkten Rechten für die erste Anmeldung verwendet werden. Für zusätzliche Sicherheit sollten Sie die Multi-Faktor-Authentifizierung für SSH in Betracht ziehen.
Update! Keine Absicherungsliste ist vollständig ohne die Erinnerung, Systeme regelmäßig zu aktualisieren und bei Bedarf Hotfixes anzuwenden, um Schwachstellen zu beheben.
Natürlich ist diese Liste nicht erschöpfend, was Sie tun können, um einen Team-Server abzusichern. Befolgen Sie gängige Härtungspraktiken für die gesamte Infrastruktur:
Es gibt eine Reihe von Online-Ressourcen, die die sichere Einrichtung und Gestaltung von Infrastrukturen diskutieren. Nicht jede Designüberlegung ist für jede Angriffsinfrastruktur geeignet, aber es ist nützlich zu wissen, welche Optionen verfügbar sind und was andere Tester tun.
Hier sind einige dieser Ressourcen:
Die in diesem Wiki behandelten Themen stärken Angriffsinfrastrukturen, erfordern jedoch in der Regel viel Zeit für Design und Implementierung. Automatisierung kann verwendet werden, um Bereitstellungszeiten erheblich zu reduzieren, sodass Sie komplexere Setups in kürzerer Zeit bereitstellen können.
Sehen Sie sich diese Ressourcen zur Automatisierung von Angriffsinfrastruktur an:
Alles dokumentieren - Der Betrieb einer komplexen Red-Team-Infrastruktur bedeutet viele bewegliche Teile. Dokumentieren Sie unbedingt die Funktion jedes Assets und wohin sein Datenverkehr gesendet wird.
Assets auf verschiedene Dienstanbieter und Regionen verteilen - Infrastruktur-Assets sollten auf mehrere Dienstanbieter und geografische Regionen verteilt werden. Blue-Team-Mitglieder können Überwachungsschwellen gegen Anbieter erhöhen, die als aktiv an einem Angriff beteiligt identifiziert wurden, und einen bestimmten Dienstanbieter sogar vollständig blockieren. Hinweis: Beachten Sie internationale Datenschutzgesetze, wenn Sie verschlüsselte oder sensible Daten über Grenzen senden.
Nicht übertreiben - Es ist leicht, sich für fortgeschrittene Techniken zu begeistern und das gesamte Arsenal auf ein Ziel werfen zu wollen. Wenn Sie eine bestimmte gegnerische Bedrohung emulieren, nutzen Sie nur Techniken, die der echte Bedrohungsakteur verwendet hat, oder Techniken, die innerhalb des Fähigkeitsspektrums des Bedrohungsakteurs liegen. Wenn Ihre Red-Team-Tests dasselbe Ziel langfristig angreifen, sollten Sie in Betracht ziehen, "einfach" zu beginnen und sich im Laufe Ihrer Bewertungen zu den fortgeschritteneren Taktiken vorzuarbeiten. Die Weiterentwicklung der Red-Team-Technik parallel zur Blue-Team-Technik wird die Organisation konsequent voranbringen, während das gleichzeitige Überwältigen des Blue Teams mit allem das Blue Team überfordern und den Lernprozess verlangsamen kann.
Protokolle überwachen - Alle Protokolle sollten während des gesamten Engagements überwacht werden: SMTP-Protokolle, Apache-Protokolle, tcpdump auf socat-Redirectoren, iptables-Protokolle (spezifisch für Datenverkehrsweiterleitung oder gezielte Filterung), Weblogs, Cobalt-Strike/Empire/MSF-Protokolle. Leiten Sie Protokolle an einen zentralen Ort weiter, z. B. mit rsyslog, um die Überwachung zu erleichtern. Die Aufbewahrung von Operator-Terminaldaten kann nützlich sein, um die historische Befehlsnutzung während einer Operation durchzugehen. @Killswitch_GUI hat ein benutzerfreundliches Programm namens lTerm erstellt, das alle Bash-Terminalbefehle an einem zentralen Ort protokolliert. Protokollieren Sie die gesamte Terminalausgabe mit lTerm. Sehen Sie sich Vincent Yius Beitrag CobaltSplunk als Beispiel an, wie Cobalt-Strike-Protokolle zur erweiterten Infrastrukturüberwachung und -analyse an Splunk gesendet werden können.* Hochwertige Ereigniswarnungen implementieren – Konfigurieren Sie die Angriffsinfrastruktur so, dass Warnungen für hochwertige Ereignisse generiert werden, z. B. für neue C2-Sitzungen oder Treffer bei der Erfassung von Anmeldedaten. Eine beliebte Methode zur Implementierung von Warnungen ist über die API einer Chat-Plattform wie Slack. Schauen Sie sich die folgenden Beiträge zu Slack-Warnungen an: Slack Shell Bot – Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike – Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work – Jeff Dimmock (@bluscreenfojeff)
Incident Response identifizieren – Versuchen Sie, wenn möglich, IR-Maßnahmen vor Beginn der Bewertung passiv oder aktiv zu identifizieren. Senden Sie beispielsweise eine mittelmäßige Phishing-E-Mail an das Ziel (unter Verwendung unabhängiger Infrastruktur) und überwachen Sie den Datenverkehr, den diese Infrastruktur empfängt. Untersuchungen des IR-Teams können eine Menge Informationen darüber preisgeben, wie das Team arbeitet und welche Infrastruktur es verwendet. Wenn dies im Voraus ermittelt werden kann, kann es gefiltert oder direkt umgeleitet werden.
Ein GROSSES DANKESCHÖN an alle folgenden Personen (alphabetisch aufgelistet), die Tools, Tipps oder Links zur Aufnahme in das Wiki beigetragen haben, und ein weiteres DANKESCHÖN an alle, die ein Tool oder einen Beitrag geschrieben haben, auf den in diesem Wiki verwiesen wird!