Pentester Notizen: Jagd Fälle - 2

Wir setzen das Gespräch für interessante Fälle in der Arbeit der Pentester fort. Im letzten Beitrag haben wir über externe Penetrationstests gesprochen. Heute werden wir über die interessantesten internen Pentests sprechen, die wir kürzlich implementiert haben. Ihre Essenz ist, dass wir im internen Umkreis des Kunden die maximalen Privilegien in der Domäne erhalten und auf alle wichtigen Daten zugreifen sollten. Es war überrascht. Aber das Wichtigste zuerst.

Fall 1. Password Manager ist gut, aber sie müssen in der Lage sein, zu verwenden

Wir führten interne Penetrationstests für einen großen Kunden durch, der bereits Sysadmins und einen IS-Service geschult hatte. Im Laufe der Arbeit erhielten wir mehrere Accounts, mit denen wir bereits ins Netzwerk gehen und uns mit den Rechnern anderer Benutzer verbinden konnten. Irgendwann ließen sie sich im Auto eines der Systemadministratoren nieder und fanden dort ein Eldorado. Der Systemadministrator verwendete sehr komplexe Passwörter (es wäre schwierig, solche zu finden) und speicherte sie sogar in keepass. Aber hier ist das Pech: Der Passwort-Manager selbst wurde nie gesperrt - nicht nach 15 Minuten oder zum Zeitpunkt der Bildschirmsperre. Mit diesem Bonus haben wir administrative Rechte in kritischen Kundensystemen ohne Lärm und Staub.

Ein anderer Kunde hatte einen ähnlichen Fall. Auch komplizierte Passwörter, auch keepass, obwohl es nach 15 Minuten noch eine automatische Sperre gab. Wie könnten wir das nutzen? Sie warteten, bis der Administrator den Desktop gesperrt hatte und ging (zum Mittagessen?). Dann war es eine Kleinigkeit.

Wenn Sie Kennwort-Manager verwenden, verwenden Sie diese mit Bedacht - aktivieren Sie die Sperroption mit einem Sperrbildschirm und in Abwesenheit von Aktivitäten für 1 bis 5 Minuten.

Fall 2. Entlassene Mitarbeiter

Sehr oft erhalten wir bei internen Pentests Zugriff durch die Auswahl von Kennwörtern. Benutzer sind normalerweise zu faul, um komplexe Kombinationen zu erstellen, insbesondere wenn die Kennwortrichtlinie eine monatliche Aktualisierung erfordert. Oft ändern sich die Zahlen einfach - so wird aus superpassword_03.2019 einen Monat später superpassword_04.2019 und weiter unten in der Liste.

Aber manchmal stoßen Kunden auf unerwartete Ereignisse. Als wir in einem der Unternehmen einen Passwort-Sprühangriff durchführten, bekamen wir eine Reihe von Accounts, von denen einer für uns besonders interessant war: Sie hatte ziemlich weitreichende Rechte, obwohl keine Administratorrechte. Für sie wurde ein leichtes Passwort festgelegt (qaz12345), und die Kommentare zu diesem Eintrag in AD zeigten an, dass die Mitarbeiterin entlassen wurde - gemessen am Datum vor fast einem Jahr. Das heißt, nach der Kündigung wurde das Konto nicht gesperrt, sondern das Passwort einfach auf "Standard" zurückgesetzt und die Option "Passwort bei der ersten Anmeldung ändern" gesetzt. Zum Glück des Kunden waren wir die Ersten, die dazu aufgefordert wurden.

Fall 3. Patches? Nein, nicht

Der schwierigste Teil des internen Pentests besteht darin, den ersten Account zu erhalten. Es gibt viele Tools und Möglichkeiten, um dies zu tun, angefangen bei einer Modenschau der Spionage im Büro, bei der nach geschätzten Aufklebern mit Passwörtern gesucht wird, bis hin zu Angriffen auf Kerberos und dem Knacken von Passwörtern. Aber manchmal können Sie sogar beim ersten Scan Software finden, die seit zehntausend Jahren nicht mehr aktualisiert wurde (warum sollten Sie sich die Mühe machen, die Software in der internen Infrastruktur zu aktualisieren?).

In einem solchen Projekt stießen sie auf die Verwaltungssoftware von HP, in der RCE ohne Authentifizierung gefunden wurde - von dort erhielten sie einen Teil der Konten.

¯ \ _ (ツ) _ / ¯

Es schien, dass alles weiter einfach sein würde - Mimikatz, und die Sache ist in den Hut, aber es stellte sich heraus, dass die erhaltenen Konten nicht die Privilegien besaßen, die wir brauchten. Wie sie sagen, liegt unsere Stärke in der Bereitschaft für die Cloud: Mit der Magie von nmap und dem smb-enum-shares-Skript haben wir herausgefunden, dass eines der Konten lokale Administratorrechte auf dem Testserver hatte, an denen Domainadministratoren zu diesem Zeitpunkt aktiv beteiligt waren =).

Fall 4. Schlösser

Lassen Sie uns abschließend ein wenig über eine mögliche Zugriffsblockierung sprechen. Arbeiten an der "vnutryanka" führen wir am häufigsten mit Fernzugriff durch. Das Schema sieht so aus: Wir verbinden uns mit dem VPN, wir bekommen die interne Adresse und klammern uns dann über RDP an den für uns reservierten Rechner. Und mit dieser Maschine fangen wir schon an zu arbeiten, aber dafür müssen wir irgendwie unsere Werkzeuge transportieren. Viele unserer Clients verwenden Proxyserver mit Whitelists von Sites, manchmal sogar mit Whitelists von Ports, um auf das Internet zuzugreifen (Sie können beispielsweise eine Verbindung zu einer Website mit Port 80 herstellen, aber Sie können keine Verbindung mehr zu 8081 herstellen). Dies erschwert die Arbeit erheblich, insbesondere wenn das Kopieren und Einfügen über RDP verboten ist.

Aber wo in unserem Geschäft ohne Nuancen. Ein Kunde hatte sehr strenge Regeln und wir durften unsere Werkzeuge nicht auf offizielle Weise füllen, sozusagen verhinderten sie das Eindringen durch den „Haupteingang“. Hier ist eine virtuelle Maschine und minimale Rechte für Sie - leiden wie echte Hacker.

Ich musste nicht lange leiden. Der Proxy hat wirklich viel blockiert, es war nicht einmal möglich, sich einfach mit seinem http-Server zu verbinden (er ist nicht in den Whitelists enthalten), das Kopieren und Einfügen war verboten, der Browser weigerte sich, irgendwohin zu gehen, mit Ausnahme von http (80 / tcp) und https (443 / tcp) irgendwo anders als interne Portale. Wir haben versucht, Powershell zu testen - es funktioniert auch nicht, es kommt nicht ohne Proxy aus und Proxies verbieten es. Das integrierte FTP-Dienstprogramm von Windows funktionierte jedoch einwandfrei - es gab keine Regeln für die Firewall, die solchen Datenverkehr blockieren würden. Also zogen wir alle unsere Werkzeuge in den Umkreis und konnten einen tollen Job machen.

Am Ende

Ich werde die Empfehlungen aus dem vorhergehenden Teil wiederholen, weil Wiederholung die Mutter stotternder Lehren ist. Führen Sie regelmäßige Penetrationstests durch - sie helfen Ihnen, empfindliche Stellen in Ihrer Verteidigung zu finden, wie zum Beispiel in Fall 3. Sie könnten der Ansicht sein, dass es nicht notwendig ist, Systeme im internen Umkreis zu patchen, aber manchmal führt dies zu schwerwiegenden Konsequenzen.

Erstellen Sie ein Patch-Management-System - beseitigen Sie nicht nur "hochkarätige" Sicherheitslücken (wie EternalBlue oder BlueKeep), sondern auch weniger bekannte, aber nicht weniger gefährliche Sicherheitslücken (wie dies bei HP AM der Fall ist). Kurz gesagt, behalten Sie alle Ihre Systeme im Auge.