Aus dem Tagebuch eines Red Teams – Teil 11

Die Anleitung zum Erfolg (Teil 2/2)

In diesem Blog-Artikel knüpfen wir an den vergangenen Artikel an. Wir sind also im Projekt von außen über die in der Grafik abgebildeten Schritte in die interne Infrastruktur des Kunden eingedrungen.

Kurzer Rückblick

Per Phishing erhielten wir Zugriff auf ein Microsoft-Konto und fanden in SharePoint ein Dokument, in dem die Einrichtung des VPN-Zugriffs beschrieben war. Wir folgten der Anleitung Schritt für Schritt, um selbst eine VPN-Verbindung mit den zuvor gephishten Zugangsdaten aufzubauen.

Damit haben wir das Projektziel bereits erreicht. Da wir noch Zeit zur Verfügung hatten, konnten wir nun – nach Einholen des Einverständnisses unserer Ansprechpartner – das interne Netzwerk genauer unter die Lupe nehmen.

Fleißpunkte sammeln

Von nun an war alles „Bonus“, was wir erreichten. Die verbleibende Projektzeit sahen wir uns weiter im internen Firmennetzwerk um und untersuchten Möglichkeiten, uns „auszubreiten“ und weitere Berechtigungen zu erlangen. Dabei steht bei Red-Teaming-Projekten stets ein „leises“ Vorgehen im Fokus, um unerkannt zu bleiben und Abwehr-Mechanismen auf Kundenseite zu testen. Erst wenn wir bis zum Ende der Projektzeit unerkannt geblieben sind, provozieren wir gezielt „lautere“ Aktionen, um zu prüfen, wann wir erkannt werden würden.

Einfach anmelden

Von unserem Red-Teaming-System aus bestand nun also per VPN eine Verbindung in das interne Kundennetzwerk. Wir scannten vorsichtig und fanden „benachbarte“ Systeme, darunter ein Server, der als Arbeitsstation für Mitarbeitende, die aus der Ferne arbeiten, genutzt wurde.

Erneut fiel die Wahl, mit welchen Zugangsdaten wir eine Anmeldung versuchten, nicht schwer – und erneut funktionierte die Anmeldung mit den gephishten Zugangsdaten einwandfrei.

Auf der Arbeitsstation waren keinerlei Schutzmaßnahmen, wie Antiviren-Software, installiert. Dies ermöglichte uns ohne Umstände und Umwege das Ausführen von eigenen Programmen, über die wir eine permanente Verbindung zu einem Red-Teaming-Server der it.sec aufbauen konnten. Von nun an waren wir nicht einmal mehr auf den VPN-Zugriff angewiesen. 

Die Arbeitsstation, auf der wir uns nun befanden, war an das sogenannte Active Directory (AD) angeschlossen. Das Active Directory kann man sich wie ein großes Verwaltungswerkzeug für alle angebundenen Benutzer und Systeme vorstellen. In der Regel sind dies quasi alle Systeme in einer internen Infrastruktur. Mit entsprechend mächtigen Berechtigungen kann man über das AD alle angebundenen Benutzer und Systeme administrieren, beispielsweise Berechtigungen vergeben und Code auf Systemen ausführen. Das AD selbst wird auf speziellen Servern, sogenannten Domänen-Controllern, verwaltet.

Unser nächstes Ziel war, durch Schwächen in der Konfiguration des AD an genau solche Admin-Berechtigungen zu gelangen. Meist sind Benutzer aus der Domänen-Administrator-Gruppe interessante Ziele.

Einfach abtippen

Mit gängigen Hilfsprogrammen lasen wir allerlei Informationen über die Konfiguration des AD aus. Dabei fanden wir in der Benutzer-Verwaltung in Beschreibungsfeldern zu Benutzern vereinzelt Passwörter. Oft ist es nicht bekannt, dass jeder AD-Benutzer Zugriff auf diese Informationen hat und man dort deshalb keine sensiblen Informationen hinterlegen sollte.

Durch sukzessives Ausprobieren aller Benutzer und Passwörter, die wir in Beschreibungen fanden, erhielten wir Zugriff auf einen anderen Server mit Administrator-Berechtigungen.

Dank der Admin-Berechtigungen konnten wir auf dem Server Passwort-Hashes von anderen Benutzern, die sich zuletzt angemeldet hatten, auslesen. So kamen wir an den Passwort-Hash eines anderen Benutzers, der ebenso Admin-Berechtigungen auf diesem System hatte.

Man könnte denken, dass uns ein weiterer Admin-Benutzer für denselben Server nicht weiterbringen würde, denn auf diesem Server sind wir ja bereits mit Admin-Berechtigungen angekommen. Doch es gibt (mindestens) zwei typische Szenarien, wegen denen es wichtig ist, auch solche Stränge zu verfolgen:

• Szenario 1: Ein Benutzer kann sich oftmals auch auf anderen Systemen anmelden, auf denen neue Angriffsoptionen entstehen. Insofern hilft uns ein weiterer Admin-Benutzer für den uns bekannten Server zwar nicht weiter, aber auf anderen Systemen kann er vielleicht „mehr“ als der bisherige.
• Szenario 2: Damit geht es jetzt weiter 🙂

Den eingesammelten Passwort-Hash des „neuen“ Admins konnten wir aufgrund eines schwachen Passworts schnell knacken, sodass wir das Klartextpasswort – qualitativ ähnlich zu „Passwort1!“ – erhielten.

Ein Passwort reicht (nicht)

Häufig wird, sowohl im privaten als auch in Firmen, das gleiche Passwort für verschiedene Benutzerkonten verwendet. Dieses Phänomen lässt sich in sogenannten Passwort-Spraying-Angriffen ausnutzen, in denen das gleiche Passwort für eine Liste von Benutzerkonten ausprobiert wird. Dies probierten wir nun und auch in diesem Fall hatten wir Erfolg, denn genau ein einziger weiterer Benutzer hatte das geknackte Passwort „Passwort1!“ gesetzt. Gleichzeitig gehörte dieser neue Benutzer zur Gruppe der Domänen-Administratoren, welche die gesamte Infrastruktur verwalten können. Dieser Schritt bedeutete also die vollständige Kompromittierung der Domäne.

Durch Passwort-Spraying-Angriffe wird deutlich, dass man ein Passwort stets für genau ein Benutzerkonto verwenden sollte – und das ganz egal, wie sicher das Passwort ist.

Passwort³

Rekapitulieren wir, was passiert ist:

1. Wir starteten von außen, kamen per Phishing an Passwort Nr. 1, mit dem wir uns im ersten Artikel nach 3-maliger Verwendung bis auf eine Arbeitsstation in der internen Infrastruktur hangelten.
2. Wir lasen aus Beschreibungen im AD ein Passwort Nr. 2 für einen Benutzer aus, der Admin-Zugriff auf einen Server hatte.
3. Auf dem Server gelangten wir an den Passwort-Hash eines anderen Admin-Benutzers. Wir konnten den Hash knacken, da ein leicht erratbares Passwort Nr. 3 („Passwort1!“) verwendet wurde.
4. Ein Domänen-Admin verwendete ebenso Passwort Nr. 3.

Einige unserer Empfehlungen aus dem Projekt leiten sich unmittelbar aus diesen Punkten ab:

1. Verwendung einer 2-Fakor-Authentifizierung, insbesondere für sensible Anmeldungen, wie VPN.
2. Keine Passwörter in Benutzer-Beschreibungen im Active Directory hinterlegen.
3. Sichere Passwörter verwenden.
4. Keine Wiederverwendung vom selben Passwort für verschiedene Benutzerkonten.

Sollten Sie Interesse an einem Red-Teaming-Projekt haben, melden Sie sich gerne!

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