Seite 2 - Pass-the-Hash-Angriffe vermeiden (1)

Lesezeit
3 Minuten
Bis jetzt gelesen

Seite 2 - Pass-the-Hash-Angriffe vermeiden (1)

02.05.2022 - 00:00
Veröffentlicht in:
Auch alte Hashes auslesbar
Es geht aber noch einen Schritt weiter: Das Perfide an PtH ist, dass alle Hashes aller Kombinationen von Benutzer und Kennwort der Anwender gespeichert werden, die sich an diesem Rechner anmelden. Neben den flüchtigen, sitzungsbasierten Informationen gibt es statische Informationen. Bei jedem Zugriff von einem Domänenrechner auf einen Workgroup-Rechner wird jedes Mal wieder nach dem Kennwort gefragt, sobald der User sich einmal abgemeldet hat. Diese Verbindungsdaten sind sitzungsbasiert.

Logischerweise gilt das auch für den Zugriff auf eine Ressource innerhalb der Domäne, der Unterschied zur Workgroup ist nur, dass Benutzername und Kennwort beim ersten Zugriff automatisch übergeben und in der Regel direkt bestätigt werden, sodass der Dialog unterdrückt wird.

Bild 1: Tools wie mimikatz machen aus dem komplexen Pash-the-Hash-Angriff eine Angelegenheit weniger Mausklicks.

Wer als Benutzer das Häkchen bei "Kennwort speichern" aus Komfortgründen setzt, hat soeben aus einer flüchtigen eine statische Information gemacht. Statisch sind alle Benutzername/Kennwortkombinationen der lokalen Benutzer eines Rechners. Das sind in der Regel der Administrator oder ein alternativ eingerichteter "LocalAdm", aber auch die Cached Credentials einer Domäne. Per DefaultKonfiguration werden die zehn Konten, die sich zuletzt angemeldet haben, und deren Hashes lokal gespeichert, damit eine Offline-Anmeldung ohne den Domänencontroller (DC) zur Bestätigung erfolgen kann. Bei Anmeldung der elften Kennung fällt die älteste heraus.

Wer als Angreifer Zugriff auf das System und diesen Teil der Sicherheitsinformationen hat, kann diese auslesen und weiterverwenden. Das ist der "Pass", die Weiterverwendung/Weitergabe des Hashes. Jetzt wird es etwas unangenehm für Microsoft, denn dessen Entwickler haben vor 25 Jahren nicht daran gedacht, dass jemand schlau genug ist, den Speicher selber zu schreiben. Das ist der zuvor genannte "ein Schritt weiter": Es werden nicht nur die Hashes gelesen, mit denen ein Angreifer nicht direkt etwas anfangen kann (Stichwort: Rainbow Tables), sondern die notwendigen Einträge selbst erzeugt.

Die Angriffswerkzeuge lesen im ersten Schritt alle interessanten Hashes aus und dann erzeugen sie selbstständig den Eintrag im Speicher, in dem vermerkt ist, mit welcher Kombination von Benutzernamen und Hash auf ein Ziel zugegriffen werden kann. Das ist trivial und effizient. Ziel und Quelle gehen davon aus, dass diese Kombination nur im Speicher existiert, weil jemand das Kennwort eingetippt hat. Sonst gäbe es den Eintrag nicht. Da er existiert, ist er logischerweise ordentlich entstanden. Diese Fehleinschätzung nutzt Pass-the-Hash. Tools wie "mimikatz" erzeugen einen Eintrag, der alles Notwendige enthält, und so gibt es keine weitere Anfrage nach Authentifizierung.

Admin-Account nur erste Anlaufstelle
Es gibt nur eine einzige Hürde im aktuellen System: Der Angriff benötigt zwingend Vollzugriff auf das System. Der Angreifer muss in der Gruppe der lokalen Administratoren sein oder als System agieren. Grundsätzlich lassen sich aber zunächst einmal die größten Einfallstore für PtH definieren, die wir uns später im Detail ansehen werden:

  • Administrator werden ist trivial.
  • Das Lokale Admin-Konto ist aktiv.
  • Der Administrator hat aus Deployment-Gründen auf jedem Rechner dasselbe Kennwort.
  • Clients dürfen miteinander reden.
  • Es melden sich sensible Konten an unsicheren Rechnern an.
  • Es gibt viel zu viele Konten.
Ein ganz wichtiger Punkt an dieser Stelle: Der Administrator-Account ist nur das erste Angriffsziel, damit der Angreifer sich flächendeckend Systemzugriff verschaffen kann – auch dort, wo es den Admin-Account nicht als Benutzer gibt.

Dabei sollten Sie aber unbedingt bedenken, dass der Hash-Diebstahl eines "normalen" Benutzers, der vielleicht Mitglied Ihrer Forschungs- und Entwicklungsabteilung ist, sicherlich das viel kritischere Ziel darstellt. Beziehungsweise sind diese Accounts genau das, wonach ein Angreifer sucht, nachdem er sich zum Administrator gemacht hat. Dort liegen schließlich die wirklich spannenden Informationen einer Firma. Kaputtmachen und Zerstören ist einfach als Admin, mehr Geld wird aber mit Daten generiert. Angreifer nisten sich in das System ein, tauchen geduldig unter, verhindern mit allen Mitteln aufzufallen und verschwinden dann still und heimlich wieder.

Es gibt keine technische Lösung für das Problem, weil keine Technik der Welt einen Keylogger oder andere Werkzeuge blockieren kann, sobald jemand physischen Zugriff auf den Rechner hat. Die Lösung ist organisatorisch und umfasst Prozesse zur Reduktion der Angriffsfläche. Der angesprochene Credential Guard verhindert den Zugriff auf die Hashes. Vereinfacht dargestellt versteckt CG die Hashes in einer virtuellen Umgebung und stellt einen Türsteher davor. Dieser prüft jegliche Anfrage nach Information und erlaubt überhaupt nur Anfragen von Microsoft-zertifizierten Mechanismen. Die anfragende Datei benötigt ein spezielles Zertifikat von Microsoft und selbst dann wird der Hash niemals herausgegeben, sondern CG übergibt die Informationen an das Ziel. Diese Methode kann die Authentifizierung nur initiieren und erhält im Erfolgsfall eine Bestätigung, aber niemals den Hash. Der Job wird in einer sicheren Umgebung ausgeführt, bietet aber keinerlei Schutz vor Keyloggern oder schlechten Kennworten.

Seite 1: Der Pass-the-Hash-Mechanismus
Seite 2: Admin-Account nur erste Anlaufstelle


Im zweiten Teil der Workshopserie veranschaulichen wir, warum Angreifer sich im Handumdrehen als Administrator ausgeben können und warum identische Kennworte tunlichst zu vermeiden sind. Im dritten und letzten Teil geht es unter anderem darum, warum sie überflüssiges Clientgeschwätz abschalten und generell die Anzahl der Konten reduzieren sollten.

<< Vorherige Seite Seite 2 von 2


jp/ln/Mark Heitbrink

Tags

Ähnliche Beiträge

Richtig auf NIS-2 vorbereiten Redaktion IT-A… Mi., 24.04.2024 - 07:41
Bis zum 17. Oktober 2024 müssen zahlreiche Unternehmen ihre Informations- und Cybersicherheitsstrategien anpassen. Dazu gehören regelmäßige Penetrationstests und Meldesysteme für Cybervorfälle. Außerdem sind umfassende Risikobewertungen erforderlich. Die NIS-2-Richtlinie stellt Unternehmen vor Herausforderungen, bietet aber auch Chancen. Sie kann Organisationen sicherer und widerstandsfähiger machen.

Sicherheit in Microsoft Azure (3)

Hybride Szenarien lassen sich je nach eingesetzter Technologie in der Cloud relativ schnell aufbauen. Dies ist etwa für Testszenarien interessant. Planen Sie aber, Teile Ihrer lokalen Infrastruktur dauerhaft auszulagern, sollten Sie die Sicherheit nicht aus den Augen verlieren. In der Cloud warten hier ganz neue Security-Aspekte – und das gleich auf verschiedenen Ebenen. Im letzten Teil des Workshops geht es unter anderem darum, wie Sie mit Microsoft Defender for Cloud für Sicherheit sorgen und warum Sie den Zugriff auf virtuelle Server einschränken sollten.

Sicherheit in Microsoft Azure (2)

Hybride Szenarien lassen sich je nach eingesetzter Technologie in der Cloud relativ schnell aufbauen. Dies ist etwa für Testszenarien interessant. Planen Sie aber, Teile Ihrer lokalen Infrastruktur dauerhaft auszulagern, sollten Sie die Sicherheit nicht aus den Augen verlieren. In der Cloud warten hier ganz neue Security-Aspekte – und das gleich auf verschiedenen Ebenen. Im zweiten Workshop-Teil schildern wir, wie Sie auf der Kommandozeile für den Security-Feinschliff sorgen und wie Sie den Azure-Login absichern.