Silent Harvest: Windows-Geheimnisse unbemerkt extrahiert

Der Sicherheitsforscher Sud0Ru, Spezialist für Anwendungssicherheit bei Kaspersky, hat eine neue Technik vorgestellt, mit der sich Windows-Anmeldedaten und -Geheimnisse abgreifen lassen – ohne dabei von gängigen Endpoint Detection and Response (EDR)-Systemen entdeckt zu werden.

Die Methode, die den Namen „Silent Harvest“ trägt, nutzt bislang wenig beachtete Windows-APIs. Dadurch gelingt es, sensible Registrierungsdaten auszulesen, ohne Warnmeldungen der üblichen Sicherheitslösungen auszulösen. Für Red-Teaming-Operationen bedeutet dieser Ansatz einen erheblichen Fortschritt, da er aufzeigt, wie lückenhaft die Überwachung von Systemaktivitäten durch EDR-Produkte teilweise ist.

Im Unterschied zu etablierten Methoden, die zunehmend blockiert werden, läuft „Silent Harvest“ vollständig im Arbeitsspeicher. Damit entstehen keine Spuren, die von Überwachungssystemen registriert werden könnten.

In Unternehmensnetzwerken zählt das Abgreifen von Anmeldedaten zu den entscheidenden Schritten, um weitere Systeme kompromittieren zu können. Doch herkömmliche Werkzeuge zum Sammeln solcher Informationen werden inzwischen meist zuverlässig erkannt. Sud0Ru beschreibt in seiner Veröffentlichung zunächst, wie Windows Geheimnisse speichert, und skizziert gängige Angriffstechniken. Anschließend erklärt er, wie EDR-Lösungen entsprechende Aktivitäten durch Kernel-Überwachungsroutinen aufspüren – und zeigt schließlich, wie sein Ansatz diese Erkennung erfolgreich umgeht.

Lokale Sicherheitsbehörde:

Das Windows-Subsystem, das für die Verwaltung von Geheimnissen und Anmeldeinformationen zuständig ist, ist die Lokale Sicherheitsbehörde (LSA), die innerhalb des Prozesses lsass.exe ausgeführt wird. Die LSA verwaltet zwei In-Memory-Datenbanken: die SAM-Datenbank und die Sicherheitsdatenbank (Richtlinie), die den Registrierungsstrukturen SAM und SECURITY auf der Festplatte entsprechen.

• Die SAM-Datenbank speichert vier primäre Objekttypen: Server, Domäne, Benutzer, Alias und Gruppe.
• Die Sicherheitsdatenbank verwaltet vier Schlüsselobjekte: Richtlinie, vertrauenswürdige Domäne, Konto und Geheimnis.

Diese Datenbanken werden über zwei RPC-Schnittstellen verwaltet:

• MS-SAMR für SAM-Datenbankoperationen.
• MS-LSAD für Vorgänge in der Sicherheitsdatenbank.

Die SAM-Datenbank enthält zwar Windows-Benutzer, Gruppen und Anmeldeinformationen, bietet jedoch keine direkten API-Funktionen zum Abrufen von Anmeldeinformationen im Klartext. Ebenso ermöglicht das MS-LSAD-Protokoll das Abrufen von LSA-Geheimnissen, diese bleiben jedoch verschlüsselt, ohne dass eine einfache API-basierte Entschlüsselungsmethode zur Verfügung steht.

Um effektiv auf diese Geheimnisse und Anmeldeinformationen zugreifen zu können, ist häufig eine direkte Interaktion mit den Registrierungsstrukturen SAM und SECURITY erforderlich.

Datenbanken auf der Festplatte

Wie bereits erwähnt, entsprechen sowohl die SAM- als auch die Sicherheitsdatenbank den Registrierungsstrukturen auf der Festplatte: SAM und SECURITY. Diese Registrierungsstrukturen sind durch spezielle DACLs (Discretionary Access Control Lists) geschützt, für deren Zugriff über die standardmäßigen Windows-Registrierungs-APIs SYSTEM-Berechtigungen erforderlich sind. Es gibt jedoch Techniken, mit denen Werte aus diesen Strukturen mit Administrator-Berechtigungen gelesen werden können, indem mit Sicherungskopien der Registrierungsstrukturen gearbeitet wird.

• Benutzeranmeldeinformationen werden in der SAM-Struktur gespeichert (siehe Abbildung unten).

Windows-Geheimnisse, wie zwischengespeicherte Domänenanmeldeinformationen und Computerschlüssel, werden im SECURITY-Hive gespeichert (siehe folgende Abbildung).

Beachten Sie, dass diese Werte in verschlüsselter Form gespeichert sind. Es reicht nicht aus, sie einfach aus der Registrierung zu extrahieren. Um sie zu entschlüsseln, müssen Sie den Entschlüsselungsschlüssel mithilfe zusätzlicher Werte aus dem SYSTEM-Hive rekonstruieren. Der Entschlüsselungsprozess selbst würde den Rahmen dieses Beitrags sprengen.

Seitliche Bewegung unter Windows:

Die folgende Tabelle enthält eine Übersicht über gängige Techniken zum Sammeln von Windows-Anmeldedaten, sowohl für die remote als auch für die lokale Erfassung. Jeder Ansatz umfasst die zugrunde liegende Technik und die damit verbundenen Nachteile.

Remote-Methoden:

Lokale Methoden:

Der Zugriff auf Geheimnisse über den LSASS-Speicher ist zwar eine weitere mögliche Methode, dies würde jedoch den Rahmen dieses Artikels sprengen. Es ist zu beachten, dass LSASS durch moderne Sicherheitslösungen wie EDRs und Windows Defender streng geschützt und überwacht wird. Jede Interaktion mit LSASS löst in der Regel sofortige Abwehrreaktionen aus, wodurch dieser Ansatz ein hohes Risiko für die Betriebssicherheit darstellt.

EDR-Callback-Routinen:

Ein wichtiger Erkennungsmechanismus in moderner Endpoint Detection & Response (EDR)-Software ist die Verwendung von Callback-Routinen im Kernel-Modus. Der Treiber des EDR fordert den Windows-Kernel auf, ihn zu benachrichtigen, wenn bestimmte Systemereignisse auftreten, darunter die Erstellung oder Beendigung von Prozessen, Bildladevorgänge und Registrierungsaktivitäten.

Zur Überwachung der Registrierung ruft der Treiber CmRegisterCallbackExauf und übergibt dabei eine Callback-Funktionsadresse. Bei jedem Zugriff auf die Registrierung ruft der Kernel diese Funktion auf und übergibt zwei wichtige Informationen. Die erste ist ein REG_NOTIFY_CLASS-Wert, der den Vorgang beschreibt, z. B. RegNtPreEnumerateValueKey, wenn ein Thread die Werte unter einem Schlüssel auflisten will. Die zweite ist eine ereignisspezifische Datenstruktur, die Kontextinformationen wie den vollständigen Schlüssel- oder Wertpfad und die Zugriffsmaske des Aufrufers enthält.

Ein typisches Windows-System generiert jede Minute Tausende von Registrierungsoperationen, sodass eine wahllose Überwachung zu einer inakzeptablen Leistungseinbuße führen würde. EDR-Treiber registrieren daher nur Callbacks für eine sorgfältig ausgewählte Teilmenge von Schlüsseln (z. B. diejenigen unter HKLM\SAM oder HKLM\SECURITY) und filtern nach den für die Sicherheit wichtigsten Ereignistypen, wodurch der Overhead minimiert wird und gleichzeitig wertvolle Aktivitäten erfasst werden.

Der stille Harvester:

Bei vielen Sicherheitsbewertungsprojekten ist es nützlich, ein sehr kleines, vollständig natives Dienstprogramm mitzuführen, das sensible Daten aus der Registrierung extrahieren kann, ohne die verräterischen Artefakte zu hinterlassen, nach denen EDR-Produkte suchen. Mein Ansatz basiert ausschließlich auf Windows-Interna und nicht auf speziellen „EDR-Umgehungstricks”.

Geheimnisse im laufenden Betrieb lesen, ohne die Festplatte zu berühren:

Das primäre Ziel ist es, die Erstellung von Sicherungskopien der Hives auf der Festplatte zu vermeiden und die Remote-Registrierung nicht zu aktivieren. Stattdessen sollte das Tool im Sicherheitskontext eines lokalen Administrators (nicht SYSTEM) ausgeführt werden, damit es remote über wmiexec oder einen vergleichbaren Mechanismus gestartet werden kann. Als ich mit dieser Arbeit begann, gab es kein öffentliches Dienstprogramm und keine Anleitung, wie man die geschützten Daten in SAM und SECURITY direkt lesen kann, ohne als SYSTEM ausgeführt zu sein. James Forshaws PowerShell-Modul „NtObjectManager“ brachte mich schließlich auf die richtige Spur: Er mountet die Registrierung als PowerShell-Laufwerk und liest dann Schlüssel, für die normalerweise erweiterte Berechtigungen erforderlich wären.

Eine genauere Untersuchung des Moduls ergab, dass es die undokumentierte native API „NtOpenKeyEx“

Die Funktion ist wie folgt deklariert

NTSTATUS NtOpenKeyEx(
  PHANDLE KeyHandle,
  ACCESS_MASK DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes,
  ULONG OpenOptions
);

Der Zauber steckt in OpenOptions. Neben dem Wert 0 („keine speziellen Optionen“) gibt es zwei Flags, die für uns von Bedeutung sind:

• REG_OPTION_OPEN_LINK (0x00000008) – Symbolischen Link folgen.
• REG_OPTION_BACKUP_RESTORE (0x00000004) – Backup-/Wiederherstellungssemantik anfordern.

Wenn REG_OPTION_BACKUP_RESTORE angegeben ist und der Aufrufer SeBackupPrivilege aktiviert hat, umgeht der Kernel selbst bei den sensibelsten Schlüsseln die normalen ACL-Prüfungen.

Beachten Sie, dass diese APIs OMNS-Pfade für die Registrierungsschlüsselpfade anstelle von WIN32-Pfaden (z. B. HKLM\..) verwenden.

Somit kann ein einfacher Administrator, der SeBackupPrivilege aktiviert, alles unter SAM oder SECURITY öffnen. Sobald der Handle vorliegt, lesen normale Routinen wie NtQueryValueKey oder RegQueryValueExW die Daten direkt aus dem Speicher, ohne dass Hive-Dateien jemals auf die Festplatte gelangen.

Bleiben Sie unter dem Radar:

In der vorherigen Phase haben wir das Problem der Zugriffskontrolle gelöst: Ein Administrator mit SeBackupPrivilege kann nun die geschützten Schlüssel öffnen, aber wir haben uns noch nicht mit der anderen Hälfte des Puzzles befasst: der Erkennung. Selbst wenn die ACLs umgangen werden, lösen die meisten EDR-Produkte sofort einen Alarm aus, sobald ein nicht vertrauenswürdiger Prozess sensible Werte unter SAM und SECURITY berührt, da sie auf gängige APIs wie RegQueryValueExW in Kombination mit risikoreichen Pfaden achten.

Wie wir bereits gesehen haben, können EDR-Treiber es sich nicht leisten, jeden einzelnen Registrierungsvorgang zu überprüfen; das Volumen ist einfach zu hoch. Stattdessen hängen sie sich an eine begrenzte Anzahl „interessanter“ Aufrufe an oder filtern diese. Diese Beobachtung veranlasste mich, nach einer Windows-API zu suchen, die (a) mir weiterhin das Lesen beliebiger Werte ermöglicht, aber (b) so selten ist, dass Anbieter sie nicht in ihre Regelsätze aufgenommen haben.

Microsoft beschreibt RegQueryMultipleValuesW als

„Abrufen des Typs und der Daten für eine Liste von Wertnamen, die mit einem geöffneten Registrierungsschlüssel verknüpft sind”.

Der Prototyp lautet:

LSTATUS RegQueryMultipleValuesW(
    HKEY       hKey,        // handle returned by RegOpenKeyEx/NtOpenKeyEx
    PVALENTW   val_list,    // array describing the values to fetch
    DWORD      num_vals,    // number of elements in val_list
    LPWSTR     lpValueBuf,  // caller-supplied buffer that receives the data
    LPDWORD    ldwTotsize   // in: size of lpValueBuf; out: bytes returned
);

Die Verwendung der Funktion für einen einzelnen Wert ist trivial:

Erstellen Sie einen einzelnen VALENTW, setzen Sie dessen ve_valuename auf den Wert, den Sie lesen möchten, übergeben Sie num_vals = 1und verweisen Sie lpValueBuf auf einen Puffer mit geeigneter Größe. Nach der Rückkehr des Aufrufs werden der Datentyp und die Länge des Werts ausgefüllt.

In der Praxis löste der Aufruf von RegQueryMultipleValuesW (selbst wiederholt bei hochsensiblen Werten in SAM oder SECURITY) auf jeder getesteten EDR-Plattform null Warnmeldungen aus. Die Arbeitshypothese lautet, dass sich die Anbieter auf die weitaus häufiger verwendeten Single-Value-APIs (RegQueryValueExW, NtQueryValueKeyusw.) konzentriert und diese seltenere Schnittstelle einfach nie zu ihren Hook-Listen hinzugefügt haben.

Kombinieren Sie die beiden Teile der Strategie NtOpenKeyEx mit REG_OPTION_BACKUP_RESTORE, um den Handle zu erhalten, und RegQueryMultipleValuesW, um die Daten zu lesen.

Letztendlich findet der gesamte Vorgang im Arbeitsspeicher statt; es werden keine Hive-Dateien erstellt und keine hochfrequenten „Red-Flag“-APIs aufgerufen.

Die Entschlüsselung der Blobs ist ein separater Schritt und bleibt außerhalb des Rahmens dieser Studie, aber die Erfassungsphase ist nun sowohl still als auch portabel.
In den folgenden Abbildungen sehen Sie, wie Sie diese Technik anwenden können.

Zusammenfassend zeigt diese Untersuchung, wie die internen Funktionen von Windows genutzt werden können, um mit minimalem Code sowohl Zugriffskontrollen als auch gängige EDR-Erkennungsmechanismen zu umgehen. Es ist zwar wahrscheinlich, dass Anbieter RegQueryMultipleValuesW letztendlich in ihre Überwachungslogik aufnehmen werden, doch die allgemeine Lehre daraus ist, dass übersehene Funktionen oft einfache Wege bieten, um defensive Annahmen zu umgehen.

Schauen Sie mal hier vorbei

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky