Angriffssimulation: Realitätscheck für Unternehmen

Was ist eine Gegner-Simulation?

Im Gegensatz zu Standard-Penetrationstests, die in der Regel auf eine bestimmte Lösung, Anwendung oder ein Netzwerk abzielen, ist eine Gegner-Simulationsübung eher auf einen realistischen Ansatz ausgerichtet, wobei nur Ziele (Flaggen) und Out-of-Scope-Szenarien definiert werden. Das bedeutet, dass wir als Angreifer jeden Angriffsvektor einsetzen dürfen, der uns vielversprechend erscheint, um unser Ziel zu erreichen, wie z. B. Phishing-Angriffe, physische Angriffe oder/und Angriffe auf über das Internet zugängliche Vermögenswerte, wenn die Kunden mit solchen Szenarien einverstanden sind.

Ziel dieser Mission ist es auch, die Erkennungsfähigkeiten und die Verfahren zur Reaktion auf Zwischenfälle zu testen und Techniken, Taktiken und Verfahren (TTPs) zu ermitteln, die von einem externen Bedrohungsakteur verwendet werden könnten, um ohne Vorkenntnisse einen erfolgreichen gezielten Angriff auf die Infrastruktur unseres Kunden durchzuführen.

Gegner-Simulationen werden von den Kunden sehr geschätzt, da sie die Schwachstellen in ihren Verfahren und der aktuellen Konfiguration ihrer Infrastruktur offenlegen und so zeigen, ob Kunden morgen von einem Angreifer vollständig kompromittiert werden könnten. Bitte beachten Sie, dass wir bereits viele Gegner-Simulationen durchgeführt und unsere Ziele immer erreicht haben.

Einleitung

Ein internationaler Finanzkonzern beauftragte uns mit der Durchführung eines gezielten Angriffs auf sein Unternehmen.
Von den Angriffsvektoren kam nur das physische Eindringen nicht infrage. Wir waren also nicht befugt, physisch in das Büro des Zielunternehmens einzudringen, um den Raspberry an das Netzwerk anzuschließen, auf den Firmencomputer zuzugreifen oder zu versuchen, Zugang zum WLAN zu erhalten oder ähnliche Szenarien durchzuführen.

Die folgenden Ziele wurden festgelegt:

• Unerlaubter Zugang zum internen Kundennetzwerk
• Höhere Berechtigungen im lokalen Active Directory
• Zugriff auf sensible Daten
• Änderung spezifischer ERP-Daten (z. B. RIB), um nachzuweisen, dass Finanzbetrug möglich ist.

Vorbereitung des Angriffs

Infrastruktur

Vor Beginn der Mission wurde eine vollständige Infrastruktur für die Offensive aus folgenden Komponenten eingerichtet:

• Redirectors: Diese sind mit dem Internet verbunden und stellen die Weiterleitung der Verbindung des Opfers zu den Servern des Angreifers sicher
• SMTP-Server: Mail-Server für den Versand von Phishing-E-Mails
• HTTP-Server: Webserver, der zur Verbreitung von Malware und Angriffswerkzeugen verwendet wird + Web-Phishing-Template
• C&C/C2-Server (Command & Control Server): Malware-Panel zur Kontrolle kompromittierter Hosts

Nur die Redirectors waren über das Internet zugänglich, so dass es nicht möglich sein sollte, die Backend-IPs der gegnerischen Infrastruktur direkt zu identifizieren.
Jeder Server erhielt spezifische Konfigurationen wie DKIM, SPF und DMARC für SMTP, die es ermöglichen, das Risiko der Kategorisierung unserer Phishing-E-Mails als Spam zu verringern, SSL-Zertifikate für HTTP und C2 zu validieren und zudem die Domain-Kategorisierung für den Web-Proxy durchzuführen.

OSINT und Erkennung externer Oberflächen (internetbasierte Dienste)

Nach der Einrichtung der offensiven Infrastruktur bestand der erste Schritt darin, die aus der Ferne zugänglichen Dienste des Unternehmens zu identifizieren, eine Liste zu erstellen und auf potenzielle Schwachstellen zu prüfen.
Außerdem wurden Mitarbeiterdaten über Social-Media-Plattformen wie LinkedIn gesammelt, um später eine Liste von Firmen-E-Mail-Adressen für die Phishing-Kampagne zusammenzustellen:

Es wurden auch Brute-Force-Suchen auf shodan.io und Subdomains durchgeführt, um die Liste der im Internet verfügbaren Server zu finden:

Szenario-Definition:

Zugriff auf Citrix mit 2FA

Da in der externen Phase keine kritische Schwachstelle gefunden wurde, die eine Remote-Code- oder Befehlsausführung (RCE) auf einem internen Objekt der anvisierten Infrastruktur ermöglicht, wurde beschlossen, für den ersten Zugriff ein Phishing-Szenario zu verwenden.

Dieses Szenario wurde gewählt, weil das Unternehmen eine Fernzugriffslösung verwendet, in unserem Fall CITRIX NetScaler.

Solche Fernzugriffslösungen (Citrix, VPN) sind ein bevorzugtes Ziel für Angreifer, denn wenn der Angriff in großem Umfang durchgeführt wird, und je nach Konfiguration der Fernzugriffslösung, kann dies ein ideales Einfallstor für Angreifer sein.

Dies liegt auch daran, dass es in den meisten Fällen einfacher ist, die Zielpersonen dazu zu bringen, ein Anmeldeformular mit ihren Zugangsdaten auszufüllen, als eine Malware auszuführen, die obendrein noch erfolgreich ausgeführt werden muss und in einigen Fällen von Antiviren- oder EDR-Lösungen erkannt werden kann.

Es wurden zwei Optionen diskutiert:

• Senden eines Droppers per E-Mail an die Mitarbeiter (im Anhang oder über einen externen Link).
• Entwenden der Firmen-Zugangsdaten, um diese auf der echten Citrix-Plattform abzulegen, eine gültige Sitzung zu starten und manuell mit Plattform zu interagieren.

Es wurde eine Mischung aus beiden Szenarien gewählt, um die Erfolgsquote des Angriffs zu erhöhen.
Zunächst wurde während unserer Forschungs- und Entwicklungsphase ein unseren Anforderungen entsprechendes Skript entwickelt, das automatisch gestohlene Citrix-Zugangsdaten, einschließlich 2FA-Token, übermittelt und eine gültige Sitzung generiert.

Je nach Webbrowser des Benutzers könnte dann eine Malware abgelegt werden.

JavaScript wurde verwendet, um einen Fingerprint des Webbrowsers des Nutzers zu erstellen und nur dann zum Dropper weiterzuleiten, wenn „Internet Explorer“ erkannt wird.
Sobald der Zugriff jedoch erfolgt ist, muss eine Persistenz installiert werden, damit der Zugriff im Falle einer Passwortänderung oder eines Timeouts der Citrix-Sitzung erhalten bleibt.

Dropper

Eine HTA-Dropper-Datei wurde erstellt und funktioniert wie folgt:

• In die .HTA-Datei ist ein VB-Skript eingebettet, das eine böswillige DLL ablegt und sie mit rundll32.exe ausführt.
• Bei dieser DLL-Datei handelt es sich um eine angepasste Binärdatei, die eine Verbindung zum Steuer- und Kontrollserver herstellt und dem infizierten Client (mit den aktuellen Benutzerrechten) Fernzugriff gewährt.

Persistenz

Um auf den Citrix-Hosts auch nach einem Session-Timeout zu bestehen, wurde eine spezielle Malware entwickelt.
Die Malware stellte eine HTTPS-Verbindung zu unserem C2-Server her, und ihre Ausführung wurde durch das Öffnen eines beliebigen Word-Dokuments ausgelöst.

Dies war darauf zurückzuführen, dass die Anwendung Microsoft Word automatisch jede externe Bibliothek (DLL) mit der Erweiterung „.wll“, die sich im Ordner %APPDATA%\Microsoft\Word\Startup des Benutzers befindet, in Word öffnet.
Die DLL hatte die Aufgabe, Process Hollowing durchzuführen und einen Cobalt Strike Shellcode im Speicher des Prozesses iexplore.exe (Internet Explorer) auszuführen.

Natürlich haben wir für unsere gesamte Payload verschiedene AV/EDR-Umgehungstechniken verwendet, die wir während unserer spezifischen Forschungs- und Entwicklungsphase entwickelt und getestet haben, um nicht von irgendeiner Lösung entdeckt zu werden.
Die Payload-Injektion wurde in einem anderen Prozess als WORD durchgeführt, um die Remote-Sitzung nicht zu verlieren, wenn der Benutzer die Anwendung Microsoft Word schließt.

Instrumente

Um die erstellten Ressourcen wieder zu nutzen, haben wir vor dem Phishing Folgendes vorbereitet:

• Einen HTA-Dropper;
• Eine .DLL-Payload;
• Eine .WLL-Word-Payload für die Persistenz;
• Ein E-Mail-Phishing-Template;
• Eine Web-Phishing-Seite;
• JavaScript-Browser-Fingerprinting;
• Ein Python-Skript zur Weiterleitung gefälschter Zugangsdaten an das eigentliche Citrix-Ziel.
• Wie Sie sich vorstellen können, bedarf es daher einer gründlichen Vorbereitung, um unsere Ziele bei einer solchen Mission zu erreichen. Wir könnten die sehr spezifischen Details für die Vorbereitung der Payload, des Droppers und des Skripts zum Wiedereinspielen der Zugangsdaten eingeben, aber das ist so lang, dass es einen eigenen Artikel erfordern würde, und ist nicht das Thema dieses Blogs. Vielleicht im nächsten Artikel? =) #teasing

Phishing-Vorbereitung

Wie bereits erwähnt, haben wir auf der Grundlage der identifizierten Hosts und der gesammelten E-Mails beschlossen, eine Phishing-Kampagne mit dem Citrix-Szenario durchzuführen. Zu diesem Zweck wurden eine Phishing-E-Mail und eine Phishing-Webseite (Landing Page) erstellt, die der ursprünglichen Citrix-Client-Seite ähnelt.

Ausführung des Angriffs

Erster Zugriff

Nachdem wir ein Maximum an E-Mail-Adressen gesammelt und die Phishing-Webseite und die E-Mail vorbereitet hatten, war es an der Zeit, den Angriff zu starten.
Das Phishing wurde gestartet und ermöglichte den Erstzugriff mithilfe eines internen Skripts, das die gestohlenen Zugangsdaten, einschließlich OTP, automatisch auf der echten CITRIX-Zielplattform ablegt, um gültige Citrix-Sitzungen zu sammeln.
Eine Bibliothek wie Selenium kann auch verwendet werden, um das Wiedereinspielen der Zugangsdaten und das Speichern/Laden von Cookies zu automatisieren.
Das Python-Skript, das sowohl das Citrix-Cookie-Grabbing als auch den Selenium-Cookie-Refresher kombiniert, finden Sie auf unserem GitHub hier: Offensive_tools/citrix_selenium.py at main · post-cyberlabs/Offensive_tools · GitHub

Abbildung 1 - Automatisches Wiedereinspielen von Citrix-Zugangsdaten (2FA) zur Erzeugung einer Sitzung

Abbildung 2 – Web-Citrix-Zugriff (über Sitzung)

Die Verbindung mit der Citrix-Sitzung des Nutzers kann unterbrochen werden, was das Risiko erhöht, entdeckt zu werden, insbesondere wenn die Verbindung unterbrochen wird, kurz nachdem der Nutzer seine Zugangsdaten auf unserer Phishing-Seite eingegeben hat. Deshalb warten wir in der Regel den Abend ab und lassen den Sitzungs-Cookie bis zum Ende der Arbeitszeit gültig, um eine Verbindung herzustellen.

Persistenz

Sobald der Citrix-Zugriff erlangt war, wurde auf den kompromittierten Hosts eine Persistenz eingerichtet, um sicherzustellen, dass der Zugriff im Falle eines Sitzungs-Timeouts, eines Zurücksetzens der Zugangsdaten oder anderer Aktionen nicht verloren geht.
Bitte beachten Sie, dass eine Neuinstallation der infizierten Hosts die Malware nicht entfernen würde, da in der angegriffenen Infrastruktur die privaten Ordner der Benutzer einschließlich der installierten Anwendungsdaten auf einer Netzwerkfreigabe abgebildet waren und sich die Malware daher im Microsoft-Word-Ordner befand.
Dies bedeutet, dass die Malware auf einem Dateiserver lag und nur dann gestartet wurde, wenn der Benutzer Word von einem beliebigen Citrix-Host aus öffnete, auch wenn dieser gerade erst eingerichtet wurde.

Abbildung 3 – Cobalt Strike Beacons (WLL und Process Hollowing)

Übernahme der Infrastruktur

Die Übernahme der Active Directory-Domain war einfach.
Da das DFL (Domain Functional Level) recht alt war, wurde angenommen, dass Domain Controller ihre Authentifizierungsmechanismen herabstufen durften, damit ältere Systeme korrekt arbeiten können.
Für diese Art von Angriffsszenario ist jedoch ein Listener erforderlich, der das Relay auf TCP-Port 445 durchführt, und in unserem Fall konnte nur eine Malware, die auf einem Windows-Citrix-System läuft, in die Zielinfrastruktur gelangen.

Da Windows Port 445 für SMB verwendet und das Stoppen dieses Dienstes oder das Binden an diesen Port lokale Administratorrechte erfordert, war es nicht möglich, den kompromittierten Host in dieser Weise zu nutzen.

Um diese Einschränkung zu umgehen und den Angriff durchzuführen, wurde ein Test durchgeführt, um einen unserer über das Internet zugänglichen Server auf Port 445 von dem kompromittierten Citrix-Host aus zu erreichen. Wenn die TCP-Verbindung erfolgreich ist, bedeutet dies, dass keine Netzwerkfilterung durchgeführt wurde, um ausgehende TCP-Verbindungen auf bestimmten Ports zu filtern.
Daher wurde eine Herabstufung des Net-NTLM-Protokolls zusammen mit einem Authentifizierungszwang unter Verwendung von PrinterBug und PetitPotam auf DCs über das Internet ausprobiert, was es ermöglichte, Net-NTLMv1-Hashes mit einer spezifischen Challenge-Response zu sammeln.

Net-NTLMv1 ist bekanntermaßen schwach, es gibt „Rainbow Tables“ (Regenbogentabellen) für eine vordefinierte Challenge-Response, die es ermöglichen könnten, den NTLM-Hash von Net-NTLMv1 in wenigen Sekunden zu erhalten.

Mit dem geknackten NTLM-Hash von DC und Pass-The-Hash war es dann möglich, direkt einen DCSync-Angriff durchzuführen und die gesamte AD-Domain zu übernehmen.

Abbildung 4 – Net-NTLMv1 über Internet

Sobald die Infrastruktur fertig war, war es einfach, sich seitlich im internen Netzwerk unter Verwendung eines geeigneten NTLM-Hashs zu bewegen, insbesondere um die Oracle-Zahlungsdatenbank anzuvisieren und die RIB eines Mitarbeiters zu ändern, um die vierte Flagge zu erhalten.

Simulations- und Angriffsschema