Aus dem Tagebuch eines Red Teams – Teil 9

Wenn die Katze die Maus nur halb erwischt

In diesem Red-Teaming-Projekt starteten wir – abgesehen vom Kundennamen – ohne jegliche Informationen. Ziel war es, von außen ins interne Netzwerk einzudringen. Und wie das funktionierte, erzählen wir euch in der nächsten Mau… ähm, natürlich in diesem Blogartikel!

Zunächst sammelten wir Informationen über alle Systeme, die mit dem Kunden in Verbindung gebracht werden konnten. Da der Kunde international agiert, fanden wir eine Vielzahl von Domänen unter verschiedenen Top-Level-Domains, wie <kunde>.de, <kunde>.com und <kunde>.ch, und sahen uns schnell mit einigen interessanten Zielen konfrontiert.

Ein attraktiver Webserver

Ein Webserver mit einer scheinbar selbstprogrammierten und in Vergessenheit geratenen Webseite lachte uns an und wir witterten unsere Chance. Der Server gab diverse Namen und Versionen von serverseitig verwendeter Software und Informationen über die interne Infrastruktur preis, womit wir uns ein gutes Bild über das Ziel machen konnten. Insbesondere wussten wir, dass wir als lokaler Administrator auf einem System im internen Kunden-Netzwerk landen würden, wenn wir entsprechende Schwachstellen in der Webanwendung finden würden – das wäre ein Jackpot!

Etwas versteckt fanden wir einen Login. Grundsätzlich führen fehlgeschlagene Anmeldeversuche häufig zu Auffälligkeiten im Monitoring, durch die Angriffe erkannt werden können, weshalb man Anmeldeversuche in Red-Teaming-Projekten mit Bedacht durchführen muss. Typischerweise gibt es bei fast allen Anwendungen einen Benutzer „admin“ und dessen Passwort ist häufig standardmäßig „admin“. Und – Trommelwirbel – diesmal auch! Der erste Schritt war gemacht! Nur erschien leider kurz darauf eine Fehlermeldung – die Programmierung der Webseite schien grundsätzlich einfach nicht (mehr?) zu funktionieren. Ärgerlich.

Nach einigem Troubleshooting entschieden wir uns schließlich für eine Planänderung und ließen die Schwachstellen-Suche fürs Erste ruhen.

Ein VPN-Server

Also widmeten wir uns weiteren Angriffsmöglichkeiten. In einem weit entfernten Land fanden wir einen Citrix-Server, der typischerweise VPN-Zugriff in die interne Firmeninfrastruktur ermöglicht.

Der gängigste Angriffsweg ist nun, über Phishing an gültige Zugangsdaten für den VPN-Zugriff zu gelangen. Nun stellten sich also die Fragen, die wir bereits in Teil 6 der Serie beschrieben haben, um die Phishing-Kampagne aufzubauen. 

Zunächst mussten wir E-Mail-Adressen von Mitarbeitenden herausfinden, an die wir eine passende Phishing-Mail senden könnten. Den Aufbau der Mail-Adresse fanden wir durch Inspizieren von Metadaten in PDFs heraus, die auf der Firmen-Webseite zum Download bereitstanden: m.mustermann@<kunde>.com

Eine Vielzahl von Mitarbeitenden waren auf Plattformen wie LinkedIn und Xing angemeldet. Da wir das Mail-Schema bereits kannten, konnten wir auf Basis der Mitarbeiter-Namen viele weitere potenziell gültige Mail-Adressen generieren.

In der Informationssammlungs-Phase hatten wir zudem Indizien gesammelt, dass ein System als Schutzmaßnahme gegen Phishing eingesetzt wurde. Das heißt, alle Mails an Mitarbeiter würden von diesem System gescannt und geprüft werden, bevor sie den Empfängern zugestellt werden.

Ironischerweise ermöglichte genau dieses Anti-Phishing-System das Validieren von Mail-Adressen, das heißt, wir konnten über einen extern erreichbaren Dienst herausfinden, ob die gesammelten Mail-Adressen existierten. Falls eine Mail-Adresse nicht existierte, weil der Mitarbeiter beispielsweise nicht mehr für die Firma arbeitete, erhielten wir eine entsprechende Fehlermeldung.

„Wie zufrieden sind Sie mit dieser Phishing-Mail?“

Als Thema der Phishing-Mail entschieden wir uns für eine Zufriedenheits-Umfrage, die von einer von uns erfundenen Marketing-Mitarbeiterin versendet wurde. Für das Versenden der Mail registrierten wir eine Domäne mit dem Namensaufbau <kunde>-online.com, sodass die Mail-Adresse des Absenders sich gut in die bekannten Kunden-Domänen einreihte.

Nach dem Öffnen eines Links in der Phishing-Mail würden die Empfänger zu einem Login geleitet werden, bei dem sie zur Legitimität ihrer Teilnahme ihre Windows-Zugangsdaten eingeben sollten. E-Mail und Webseite wurden dabei entsprechend der Corporate Identity des Kunden designt.

Beim Vorbereiten der Mail und der Webseite bangten wir, wie das Anti-Phishing-System wohl mit unserer Mail umgehen würde. Eben hatte sie uns noch so nett unterstützt – aber würde sie unsere Phishing-Mail direkt aufdecken und vielleicht gar keine Mails an die Empfänger zustellen? Am Ende läuft es meist auf ein „Probieren geht über Studieren“ hinaus und wir versendeten nach mühevoller Vorbereitung die Mails. Und wir durften uns freuen, denn bereits wenige Minuten nach dem Versenden der Mail trudelten die ersten Passwörter bei uns ein!

Wir versendeten die Mail an insgesamt 155 Benutzer, von denen 10 Benutzer ihre Zugangsdaten preisgaben. Mit einigen davon konnten wir uns bei OWA anmelden und erhielten darüber Zugriff auf interne E-Mails. Am spannendsten war ein Benutzer, der zur Anmeldung an unserem Ziel, dem VPN-Server, berechtigt war. Aus unserer Sicht wurde zum Glück auch kein zweiter Faktor bei der Authentifizierung abgefragt. Der Weg ins interne Netzwerk war geebnet und wir begannen, uns intern umzuschauen.

Wenig später wurden allerdings mehrere Passwörter, die in der Phishing-Kampagne preisgegeben wurden, geändert, denn weitere Anmeldeversuche bei VPN-Server und OWA-Webmail schlugen fehl. Glücklicherweise blieb unsere bestehende VPN-Verbindung davon unbeeindruckt, weshalb wir diese „am Leben hielten“ und uns so im internen Netz weiterbewegen konnten. Diesmal war die Maus also schneller!

Wie hätte man die Infrastruktur besser absichern können?

Am Ende hat es ausgereicht, genau ein Benutzerkonto für den VPN-Zugriff zu kompromittieren, um Fuß im internen Kunden-Netz zu fassen und das Ziel der Red-Teaming-Kampagne zu erfüllen. Dabei haben wir wertvolle Informationen über die externe Angriffsoberfläche der Kunden-Infrastruktur sowie Verbesserungspotenzial bei der Angriffserkennung und dem Unterbinden von Angriffen gewonnen.

Die folgenden Empfehlungen ergeben sich unmittelbar aus den geschilderten Beobachtungen:

• Der Einsatz einer 2-Faktor-Authentifizierung für sensible Anwendungen, wie z. B. VPN, hätte die Phishing-Kampagne technisch deutlich erschwert, da neben dem Passwort auch der zweite Faktor hätte mit abgefragt werden müssen.
• Nach dem Ändern der Passwörter der betroffenen Benutzer hätten auch bestehende Verbindungen beendet werden müssen. Hierzu müsste das Blue Team des Kunden seine Maßnahmen nach einem Phishing-Vorfall um das Beenden von bestehenden Verbindungen ergänzen.
• Die Analyse und Angriffsversuche der Webanwendung blieben ohne erkennbare Reaktion. Diese hätten erkannt und geblockt werden können. Ein Angreifer mit mehr Zeit hätte eventuell über diesen Webserver einen unbemerkten Weg ins interne Netzwerk finden können.
• Nicht zuletzt sollten Metadaten aus Dokumenten, die auf Webseiten veröffentlich werden, entfernt werden und die Möglichkeit, die Gültigkeit von Mail-Adressen über die Anti-Phishing-Software zu prüfen, unterbunden werden. Auch wenn beides häufig erstmal harmlos erscheint, hilft es Angreifern manchmal, die letzten Puzzle-Stücke für einen gezielten Angriff zusammenzufügen. Und je gezielter ein Angriff ist, desto schwieriger ist es, ihn zu erkennen und zu unterbinden.

Haben Sie einen Überblick über alle Ihre Systeme und hätte das Vorgehen Ihres Blue Team den Angriff vollständig erkannt und unterbunden?

Telefon: +49 731 20 589-26
E-Mail: pentests@it-sec.de

Nina Wagner im Namen des Red Teams der it.sec
Senior IT-Security Consultant / Penetration Testing