Penetrationstests, Teil 4: Die Seitwärtsbewegung

Wenn Penetrationstester ins System gelangt sind kann man sich ihre Aktivitäten ein bisschen vorstellen wie die einer Armee oder Rebellengruppe, die ein besetztes Land plündert. Man schmarotzt sich durch das...
Michael Buckbee
4 minute gelesen
Letzte aktualisierung 28. Oktober 2021

Wenn Penetrationstester ins System gelangt sind kann man sich ihre Aktivitäten ein bisschen vorstellen wie die einer Armee oder Rebellengruppe, die ein besetztes Land plündert. Man schmarotzt sich durch das System des Opfers und nimmt mit, was man kriegen kann: Shells, Netzwerkdienstprogramme, schlecht geschützte Passwortdateien und so weiter. Es geht darum, so wenig Malware wie möglich einzuschleusen und das, was man findet zu nutzen, um das System weiter auszukundschaften. Oder damit zu einem späteren Zeitpunkt erneute Angriffe zu starten.

Das Ganze nennt sich „Malware-freies“ Hacken und ist weitaus schwieriger aufzudecken als früher genutzte Techniken. Ed Skoudis hat in einem Interview im vergangenen Oktober erwähnt, dass Angreifer für ihre Aktivitäten nach dem Eindringen in Systeme sogar PowerShell verwenden.

In diesem Beitrag beschäftigen wir uns damit, wie man sich vom ursprünglich gehackten System aus weiterbewegt. Echte Penetrationstester nennen dies „Seitwärtsbewegung“. Wir wollen hier demonstrieren, dass dies mit nur wenigen importierten Tools gelingen kann.

Die Domain des Unternehmens Acme

Hat man die verborgenen Werte bereits im ursprünglichen Zielsystem gefunden sollte man sich schleunigst aus dem Staub machen. Die meisten Hacker haben aber nicht so viel Glück, es sei denn sie landen auf dem Laptop des CEO.

Um unsere Penetrationstests etwas realistischer zu gestalten haben wir eine Domain eingerichtet (Amazon Web Services macht es möglich) und nach sorgfältigem Studieren dieses Dokuments von Amazon Web Services einen Domänencontroller (mit Active Directory und DNS) installiert und anschließend zwei Windows-Server aufgebaut.

In unserem imaginären Unternehmen Acme mit dem imaginären Domainnamen acme.local haben wir zwei imaginäre Mitarbeiter – nennen wir sie Jane und Bob – eingestellt und mit einem Server verbunden. Im Domänencontroller haben wir den Nutzern grundlegende Berechtigungen für das Netzwerk mithilfe der Gruppenrichtlinie „Zuweisen von Benutzerrechten“ erteilt. Um die Sache etwas spannender zu machen, sollten sich die beiden Server nicht miteinander vernetzen lassen. Entsprechend haben wir auch die Firewall etwas weniger streng konfiguriert als von Amazon empfohlen.

Es handelt sich hierbei ganz offensichtlich um eine ziemlich rudimentäre Infrastruktur. Es ist aber durchaus vorstellbar, dass sich solch ein kleines System in einem großen Unternehmen oder vielleicht bei einem externen Lieferanten befindet. Beispiele gibt es.

Hacker-Know-how

Wie zuvor haben wir einen RAT, hier war es Janes Windows 2008-Server, verwendet. Zu Penetrationstest-Zwecken haben wir zwei Tools in Janes Ordner „Eigene Dateien“ geladen: Ncat und ein Hilfsprogramm namens PsExec ( mehr zum Thema Parameterverwendung in diesem Technet-Artikel).

Beide Tools sind Teil einer Grauzone: Sie sind für IT-Administratoren gleichermaßen nützlich wie für Hacker. Ihre alleinige Existenz in einem System ist nicht per se ein Zeichen für kriminelle Handlungen. Man kann sie natürlich in einem weniger offensichtlichen Ordner als „Eigene Dateien“ verstecken, aber das spielt hier keine große Rolle.

more arp

 

Mithilfe von Ncat haben wir eine Shell auf Janes Server ausgeführt und damit begonnen Informationen zu sammeln. Das erklärte Ziel der Penetrationstests besteht darin, wie ein Hacker vorzugehen – also Informationsfetzen zusammen zu tragen und daraus Rückschlüsse zu ziehen.

Mit dem Befehl hostname finden wir den Namen des Rechners heraus, auf dem auf dem wir gelandet sind (siehe oben). Die Antwort war „Miller“.

Der Befehl systeminfo förderte weitere technische Details zutage: neben dem Hostnamen wurden uns die IP-Adresse, der Name und die Version des Betriebssystems sowie der Domänenname angezeigt. Allesamt sehr nützliche Informationen.

Nehmen wir an, wir sind auf der Suche nach personenbezogenen Daten und habe nichts Interessantes gefunden. Wir würden unser Glück gerne auf einem weiteren Server versuchen. Mit Hilfe von Nmap, könnten wir das System nach IP-Adressen durchsuchen, doch wir bleiben bei unserer schlanken Variante von Penetrationstests.

Also geben wir stattdessen den Befehl arp -a ein, um zu sehen, was sich sonst noch im Subnetz befindet. Und siehe da: Der ARP-Cache spuckt einen weiteren Rechner in der Nähe aus.

Doch wie dorthin gelangen?

Der Joker: lokaler Administrator

Hier kann theoretisch PsExec weiterhelfen. Für nicht wenige eines der Lieblingstools. Mit dem Befehl kann man eine Remote-Verbindung zu einem anderen Rechner in der Domäne aufbauen und eine Shell oder einen anderen Windows-Befehl ausführen. Das Windows-Programm netsh bietet ebenfalls Remote-Funktionen, ist jedoch weniger flexibel.

Das erste Problem für Penetrationstester besteht darin, dass PsExec den Namen des Remote-Computers braucht (siehe Syntax). Im Moment haben wir aber nur die IP-Adresse.

Also müssen wir wieder auf Beutezug gehen.

Im Ordner \Windows\system32 finden wir nslookup, das klassische Tool zum Konvertieren von URLs in IP-Adressen und umgekehrt. In der Windows-Version kann eine IP-Adresse direkt in nslookup eingegeben werden und schon wird der DNS-Name ausgeworfen.

Der Remote-Computer hieß „amstel“. Der IT-Administrator hat also nach „Miller“ offensichtlich eine Vorliebe für Biernamen. Etwas, das man im Hinterkopf behalten sollte.

Anschließend versuchten wir Folgendes:

psexec \\amstel.acme.local -u jane@acme.local cmd.exe

Aber Windows lehnte Janes Konto ab.

Es gab zwei Probleme. Erstens hatten wir Jane in unserer Rolle als Administrator von Acme nicht erlaubt, sich an einem anderen Rechner anzumelden. Zweitens benötigte Jane selbst Administratorrechte, um PsExec auszuführen, die sie aber nicht hatte.

Dieses Beispiel ist sehr praxisnah – es ist immer eine gute Idee, den durchschnittlichen Nutzer davon abzuhalten, im Netzwerk herumzustreunen. Hacker und Penetrationstester allerdings wissen: Auf dem Rechner, auf dem sie gelandet sind, gibt es häufig lokale Konten mit erweiterten Berechtigungen.

Bei Windows gibt es seit jeher lokale Konten mit Administratorrechten, die selbst dann noch auf Laptops und Servern schlummern, wenn sie schon lange nicht mehr gebraucht werden. In der Regel haben diese Konten so offensichtliche Namen wie Admin oder Administrator und leicht zu erratende Passwörter wie Admin1234 oder ähnliches.

Hacker nutzen solche Sicherheitslücken aus, indem sie die Passwörter der lokalen Administratorkonten erraten.

Fairerweise muss man einräumen, dass Microsoft sich des Problems bewusst ist und Administratorrechte für lokale Konten in den letzten Betriebssystem-Versionen standardmäßig deaktiviert hat. Außerdem wird versucht, das Hinzufügen lokaler Nutzerkonten zu unterbinden.

Die wundersame Seitwärtsbewegung

Obwohl unser Arsenal an Tools sehr eingeschränkt war hofften wir, dass es nicht so schwierig sein würde, die Kontrolle über Bobs Server zu übernehmen. Es kam anders. Dazu mehr zu einem späteren Zeitpunkt.

Unserer Meinung nach ist die Reverse-Shell-Methode mit Netcat nicht vollständig transparent. Bei Remote-Befehlen mit Eingabeaufforderungen bekamen wir Probleme, von unserem Hacker-Rechner aus Text einzugeben – insbesondere beim Befehl runas.

Also wiesen wir kraft unserer Rolle als IT-Administrator von Acme Jane erweiterte Berechtigungen zu. Aber trotzdem konnte Janes Domänenkonto nicht auf Bobs Server zugreifen.

Als Penetrationstester konnten wir Befehle über PsExec ausführen. PsExec hat die wünschenswerte Eigenschaft, Passwortparameter zuzulassen. In unserem aktuellen Setup konnten wir deshalb eine Brute-Force-Attacke auf das Passwort des lokalen Administrators von Bobs Server starten. Damit hatten wir schließlich Erfolg (siehe unten).

psecex-redirect

Wir hatten gehofft in unserem Reverse-Shell-Szenario mithilfe von PsExec eine Shell auf Bobs Amstel-Server zu erstellen. Es gelang uns aber lediglich, einen einzigen Shell-Befehl (keine Skripte) über die Befehlszeile auszuführen, und selbst das war eine schwere Geburt. Es gab offensichtlich keinen einfachen Weg, nach personenbezogenen Daten und anderen Strings im Remote-Verzeichnis zu suchen. Dennoch war PsExec hilfreich.

Hacker wie Penetrationstester können mit PsExec nach Administratorkonten auf Rechnern in der Domain suchen. Und solche Konten können sehr ergiebig sein.

Wenn alle Stricke reißen, es gibt noch SSH

Nach unserer ersten Übung in Sachen Penetrationstests hatten wir den Eindruck, dass Windows es einem durchaus schwer machen kann, Remote-Befehle auszuführen. Unmöglich ist es nicht, aber schwierig.

Und IT-Administratoren verärgert das ihrerseits. Und genau deshalb installieren sie die Open-Source-Software SSH in Windows-Infrastrukturen!

Es ist also nicht ungewöhnlich, dass ein SSH-Server ausgeführt wird. Als IT-Administrator von Acme hatten wir freeSSHd auf Bobs Server eingerichtet.

Dank SSH begannen die Türen sich nun langsam zu öffnen. Mithilfe der RAT haben wir eine SSH-Clientanwendung auf Janes Rechner geladen und ausgeführt. Und im Handumdrehen gelangten wir mit dem zuvor eingerichteten lokalen Administratorkonto per SSH auf Bobs Server. Dafür nutzen wir die SSH –Portweiterleitung – ebenfalls ein von Penetrationstestern gern genutztes Feature.

Professionelle Penetrationstester (und Hacker) würden wahrscheinlich fortschrittlichere Tools verwenden. Doch das Prinzip ist dasselbe.

Wie soll ich vorgehen?

Im Folgenden finden Sie drei Möglichkeiten, wie Sie das Datenrisiko in Ihrem Unternehmen verringern können:

1

Vereinbaren Sie eine Demo mit uns, um Varonis in Aktion zu erleben. Wir passen die Session an die Datensicherheitsanforderungen Ihres Unternehmens an und beantworten alle Fragen.

2

Sehen Sie sich ein Beispiel unserer Datenrisikobewertung an und erfahren Sie, welche Risiken in Ihrer Umgebung lauern könnten. Varonis DRA ist völlig kostenlos und bietet einen klaren Weg zur automatischen Sanierung.

3

Folgen Sie uns auf LinkedIn, YouTubeund X (Twitter), um kurze Einblicke in alle Themen der Datensicherheit zu erhalten, einschließlich Data Security Posture Management (DSPM), Bedrohungserkennung, KI-Sicherheit und mehr.

Testen Sie Varonis gratis.

Detaillierte Zusammenfassung Ihrer Datensicherheitsrisiken
Umsetzbare Empfehlungen, die auf Ihre Bedürfnisse zugeschnitten sind
Ohne Bedingungen und Auflagen

Weiter lesen

Varonis bewältigt Hunderte von Anwendungsfällen und ist damit die ultimative Plattform, um Datenschutzverletzungen zu stoppen und Compliance sicherzustellen.

penetrationstests,-teil-7:-exfiltration-und-schlussfolgerungen
Penetrationstests, Teil 7: Exfiltration und Schlussfolgerungen
In unserer Blog-Serie haben wir einige Ideen vorgestellt wie man Sicherheitslücken im System mithilfe einfacher Testsoftware identifizieren kann. Es existieren natürlich auch komplexere Tools wie beispielsweise Metasploit, mit denen man...
penetrationstests,-teil-1:-kalkuliertes-risiko
Penetrationstests, Teil 1: Kalkuliertes Risiko
Die weitaus meisten Sicherheitsstandards und -vorschriften, enthalten einen Part zum Thema Risikoanalyse. Diese Anforderung findet sich beispielsweise in HIPAA, PCI-DSS, der Datenschutz-Grundverordnung der EU, NIST und SANS, um nur einige...
„pass-the-hash“-angriffe-genauer-betrachtet,-teil-3
„Pass the Hash“-Angriffe genauer betrachtet, Teil 3
Beim Thema „Pass the Hash“ sollte man sich unbedingt in Erinnerung rufen, dass die im Speicher abgelegten (und von Hackern entwendeten) Passwort-Hashes aufgrund von Single Sign On’s existieren. Die meisten...
pwc-studie:-cyber-kriminalität-ist-chefsache
PwC-Studie: Cyber-Kriminalität ist Chefsache
Ein Wert, der sich in Bezug auf Cyber-Kriminalität nur schwer messen lässt, sind die wirtschaftlichen Auswirkungen aus Sicht von Unternehmen. PwC hat dazu kürzlich die Ergebnisse seiner 19. globalen Studie...