Wie Angreifer die Manipulation von Zugriffstoken ausnutzen (ATT&CK T1134)

In unserem vorherigen Blogbeitrag zu Windows-Zugriffstoken für Sicherheitsexperten haben wir Folgendes behandelt:

• Die Beziehung zwischen Anmeldesitzungen und Zugriffstoken
• Wie Netzwerkauthentifizierung in Windows-Umgebungen funktioniert

Nachdem wir einige der wichtigsten Konzepte der Windows-Sicherheit behandelt haben, bauen wir nun auf diesem Wissen auf und beginnen zu untersuchen, wie Angreifer legitime Windows-Funktionalitäten missbrauchen können, um seitlich zu bewegen und Active Directory-Domains zu kompromittieren.

Dieser Blog hat bewusst versucht, die Funktionsweise bestimmter Windows-Netzwerkauthentifizierungsprotokolle (z. B. NTLM und Kerberos) wo möglich zu abstrahieren. Folglich kann es Fälle geben, in denen das Verhalten, das einzigartig für diese Protokolle ist, sich von dem unten beschriebenen Verhalten unterscheidet. Es setzt außerdem ein grundlegendes Verständnis des Kerberos-Authentifizierungsprotokolls¹ voraus.

Zusätzlich wurde das in dieser Blogreihe behandelte Material für eine BlackHat-Präsentation 2020 mit dem Titel "Detecting Access Token Manipulation" verwendet. Die Präsentation ist zu finden hier und die Folien hier.

Zugriffs-Token-Manipulation (ATT&CK-Technik: T1134)

Nachdem wir in unserem vorherigen Blogbeitrag sowohl lokal als auch für verteilte Anwendungen die Grundprinzipien der Funktionsweise von Anmeldesitzungen und Zugriffstokens erklärt haben, wird dieser Abschnitt erklären, wie Angreifer Zugriffstoken missbrauchen und die grundlegenden Vertrauensverhältnisse in Windows-Domänen angreifen können, um ganze Netzwerke zu kompromittieren. Ziel dieses Abschnitts ist es, Techniken zur Manipulation von Zugriffstokens zu beschreiben, die von Angreifern im Rahmen eines simulierten Kompromittierens verwendet werden. 

Zur Anmerkung: Es gibt bereits eine umfangreiche Studie exzellenter Forschung zur Manipulation von Zugangstokens (auf die in diesem Beitrag großzügig verlinkt wird). Dieser Blog versucht, auf diesem Wissensstand aufzubauen, indem er die Manipulation von Zugriffstokens aus einem anderen Ansatz betrachtet, nämlich durch die Beziehung zwischen Zugriffstoken, Anmeldesitzungen und zwischengespeicherten Zugangsdaten. Nach Ansicht des Autors stellt jede Beschreibung von Token-Manipulation ohne Berücksichtigung dieser Beziehungen nur die Spitze des Eisbergs dar. Folglich ist die Definition von Manipulation von Access Tokens in diesem Blog vielleicht viel weiter gefasst, als allgemein angenommen wird.

Anfänglicher Kompromiss

Wenn ein Angreifer sich durch Spear-Phishing einen Fuß in einem Netzwerk erlangt, wird er typischerweise mit einer Shell im Sicherheitskontext des kompromittierten Nutzers betrieben. Dies könnte erreicht werden, indem ein neuer Prozess gestartet oder direkt in den Speicher eingespeist wird (je nach Nutzlast), aber das Endergebnis ist dasselbe: Der Code des Angreifers läuft in einem Prozess, der ein Zugriffstoken des kompromittierten Benutzers besitzt. 

Das bedeutet, dass alle lokalen Zugriffsprüfungen das Zugriffstoken des kompromittierten Benutzers verwenden und alle Fern-Authentifizierungsversuche die zwischengespeicherten Zugangsdaten des kompromittierten Nutzers^{verwenden 2}. Daher kann der Angreifer sowohl lokal als auch im gesamten Netzwerk alle Aktionen ausführen, die der kompromittierte Nutzer kann. Wenn beispielsweise interne Webanwendungen Windows SSO verwenden, kann ein Angreifer darauf zugreifen, als wäre er der Benutzer.

Token-Manipulation: Die 'Kunst des Möglichen'

Typischerweise möchte ein Angreifer so schnell wie möglichvom kompromittierten Endpunkt zu einem anderen Host wechseln³. Betrachtet man die laterale Bewegung aus der Sicht der Token-Manipulation, hat der Angreifer effektiv drei Optionen⁴, von denen jede durch die grundlegende Beziehung zwischen Zugriffstokens, Anmeldesitzungen und zwischengespeicherten Zugangsdaten eingeschränkt ist, wie unten dargestellt:

Wenn ein Angreifer lateral über Windows SSO bewegen möchte, müssen alle drei Verbindungen vorhanden sein (z. B. haben sie einen Handle zu einem Token, das mit einer Anmeldesitzung verknüpft ist, die von ihren Zielzugangsdaten unterstützt wird). Andernfalls hängt die Bewegungsfreiheit eines Angreifers entweder davon ab, neue Links zu erstellen (z. B. neue Anmeldesitzungen) oder bestehende zu verändern (z. B. zwischengespeicherte Zugangsdaten oder die Anmeldesitzung, auf die ihr Zugriffstoken verweist). Diese Einschränkungen werden in den folgenden drei Optionen ausführlicher behandelt:

1.

Stehle das Token eines bereits eingeloggten privilegierten Benutzers (Nicht-Netzwerk-Anmeldung)

Wenn bereits ein anderer privilegierter Nutzer am kompromittierten Host angemeldet ist, kann ein Angreifer seine Rechte eskalieren und einen Zugriff auf ein Zugriffstoken erhalten, das diesen Benutzer repräsentiert. Unabhängig davon, ob der Angreifer das gestohlene Token imitiert oder einen neuen Prozess startet, hat dieses Token bei einer Nicht-Netzwerk-Anmeldungssitzung zwischengespeicherte Zugangsdaten, sodass der Angreifer von der Box an einen anderen Host⁵ authentifizieren kann. Daher ermöglicht diese Technik es einem Angreifer, die Zugangsdaten eines anderen Benutzers zu nutzen, um auf entfernte Hosts im Netzwerk (über Windows SSO) zuzugreifen und somit zu pivotieren, ohne Zugangsdaten⁶ dumpen zu müssen. 

Zur Anmerkung: Token-Manipulationsangriffe beziehen sich im Allgemeinen auf zwei unterschiedliche Ziele: eine seitliche Bewegung (mit der sich dieser Blog beschäftigt) und die Eskalation der lokalen Privilegien⁷. Token-Diebstahl wird meist mit Letzterem in Verbindung gebracht (z. B. das Stehlen/Imitieren eines Tokens, um lokale Zugriffskontrollen zu umgehen, anstatt die zwischengespeicherten Zugangsdaten für die Fernauthentifizierung zu verwenden), weshalb dieser Blog das nicht weiter ausführlich behandelt, aber die folgenden Ressourcen sind nützliche Weiterführende Literatur:

• https://posts.specterops.io/understanding-and-defending-against-access-token-theft-finding-alternatives-to-winlogon-exe-80696c8a73b
• https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/
• https://labs.f-secure.com/assets/BlogFiles/mwri-security-implications-of-windows-access-tokens-2008-04-14.pdf

2.

Erstellen Sie eine neue Anmeldesitzung mit gestohlenen Zugangsdaten und geben Sie sich als das zurückgegebene Token aus oder starten Sie damit einen neuen Prozess

In diesem Fall ist kein privilegierter Benutzer bereits eingeloggt (und somit kein entsprechendes nützliches Zugriffstoken/Anmeldesitzung), aber der Angreifer muss dennoch einen Weg finden, seinen Sicherheitskontext zu ändern. 

Daher muss der Angreifer anderswo Zugangsdaten finden und diese gestohlenen Daten nutzen, um als kompromittierter Nutzer eine neue Anmeldesitzung zu erstellen. Da Windows automatisch Zugangsdaten für bestimmte Anmeldetypen cachet, kann der Angreifer nun ein neu hergestelltes Zugriffstoken erhalten, das durch die gestohlenen Zugangsdaten gesichert wird. Sobald der Angreifer einen Handle für ein Token hat, das den kompromittierten Benutzer repräsentiert, kann er sich direkt authentifizieren und dabei den Standard-Windows-SSO-Prozess verwenden. 

Typischerweise werden Klartextzugangsdaten von Angreifern entweder durch Kerberoasting oder durch die Suche nach ungesicherten Klartextzugangsdaten auf allen zugänglichen Ressourcen wie Netzwerkfreigaben, SharePoint, internen Wikis, Unternehmens-GitHub, Zendesk usw. gefunden.

3. Ändere die zwischengespeicherten Zugangsdaten, die mit ihrem aktuellen Zugriffstoken verknüpft sind, in gestohlene Zugangsdaten (z. B. legitim über eine API oder "illegitim" durchdirekte Änderungdes LSASS-Speichers).

In diesem Szenario erstellt der Angreifer nicht eine neue Anmeldesitzung, sondern ändert die zwischengespeicherten Zugangsdaten, die mit seinem aktuellen Zugriffstoken (und damit der Anmeldesitzung) verknüpft sind. Wie wir sehen werden, bieten viele Windows Security Support Providers (SSPs) native Möglichkeiten dafür an (und ohne erhöhte Privilegien). 

Alternativ können Angreifer den "direkten" Weg gehen und zwischengespeicherte Zugangsdaten, die in LSASS gespeichert sind, manuell ändern. Dies erfordert erhöhte Privilegien, um einen Schreibgriff (z. B. PROCESS_VM_WRITE) für LSASS über OpenProcess zu erhalten. Das ist typisch für Pass-the-Hash-Angriffe, wie wir später noch behandeln werden.

Zugriffstoken-Manipulationsangriffe

Dieser Blogbeitrag wird vier gängige Techniken von Angreifern betrachten (die alle als Varianten der oben genannten Option 3 klassifiziert werden können):

• Die NETONLY-Flagge
• Pass-the-Ticket
• Pass-the-Hash
• Überführung-der-Hash

1. Die NETONLY-Flagge

Die Windows-API bietet die Funktion LogonUser, um eine neue Anmeldesitzung für einen bestimmten Benutzer (oder Prinzipal^{) zu} erstellen9:

BOOL LogonUserW(
  LPCWSTR lpszBenutzername,
  LPCWSTR lpszDomain,
  LPCWSTR lpszPassword,
  DWORD   dwLogonType,
  DWORD   dwLogonProvider,
  PHANDLE phToken
);

Der wichtigste Parameter, den hier zu beachten ist, ist der dwLogonType, der die Art des auszuführenden Logons angibt. Zum Beispiel wird im Fall, dass ein Nutzer sich physisch an seiner Arbeitsstation anmeldet, auf LOGON32_LOGON_INTERACTIVE gesetzt. Der angegebene Anmeldetyp bestimmt den Typ und die Rechte des zurückgegebenen Tokens. 

Zum Beispiel gibt LogonUserW im Fall eines interaktiven Logons ein primäres Zugriffstoken zurück, und wenn UAC aktiviert ist, ist dieses Token ein gefiltertes Token (das heißt, es ist mittlere Integrität und nicht erhöht). Dies hat eine Ausnahme: Wenn der Benutzer ein lokales Administratorkonto ist (z. B. ein *-500 SID), gibt Windows automatisch ein erhöhtes Token¹⁰ zurück.

Im Fall eines Netzwerk-Logons (LOGON32_LOGON_NETWORK) wird ein Impersonationstoken zurückgegeben (da dies typischerweise von einem Server genutzt wird, um im Auftrag der entfernten Clients zu arbeiten). Außerdem wird das Token erhöht, wenn der Benutzer in der lokalen Administratorengruppe ist, und alle Rechte^{sind 11} aktiviert. 

Diese Permutationen von LogonUser sind in der untenstehenden Tabelle erfasst:

(falls Admin)

dwLogonType	Token zurückgegeben	Cache-Zugangsdaten?	Ist der zurückgegebene Token erhöht?
Interaktiv (LOGON32_LOGON_INTERACTIVE)	Grundschule	Ja	Nein (UAC gilt dafür)
Interaktiv (Lokales Admin-Konto, z. B. rid-500)	Grundschule	Ja	Ja
Netzwerk (LOGON32_LOGON_NETWORK)	Imitation	Nr.12	Ja (+ alle Rechte aktiviert)
Netzwerk (Lokales Admin-Konto, z. B. rid-500	Imitation	Nein	Hängt von den entfernten UAC-Einstellungen13ab

Der entscheidende Punkt ist, dass LogonUser einen Handle an ein neu gemintes Token zurückgibt, das nun zur Imitation verwendet werden kann. 

Wenn der zurückgegebene Token ein primärer Token ist, muss er zunächst über DuplicateTokenEx in einen Imitationstoken umgewandelt werden, indem ein TokenType von TokenImpersonate¹⁴ weitergegeben wird:

BOOL DuplicateTokenEx(
  HANDLE                       hExistingToken,
  
  
  
  
  DWORD                        dwDesiredAccess,

br /> LPSECURITY_ATTRIBUTES lpTokenAttributes, SECURITY_IMPERSONATION_LEVEL Imitationsniveau, TOKEN_TYPE TokenType, PHANDLE phNewToken);

Die Funktion SetThreadToken kann dann verwendet werden, um das zurückgegebene Imitationstoken dem aktuellen Thread zuzuweisen:

BOOL SetThreadToken(
  PHANDLE Thread,
  HANDLE-Token
);

Alternativ bietet die Windows-API die Funktion ImpersonateLoggedOnUser , die es dem aufrufenden Thread ermöglicht, den Sicherheitskontext des Benutzers zu imitieren, der durch das übergebene Token repräsentiert wird:

BOOL ImpersonateLoggedOnUser(
  HANDLE hToken
);

ImpersonateLoggedOnUser hat den zusätzlichen Vorteil, dass es automatisch den Typ des weitergegebenen Tokens überprüft und es in ein Imitationstoken (über NtDuplicateToken) umwandelt, wenn ein primärer Token weitergegeben wurde (da dieser Tokentyp von einem Thread nicht zum Nachahmen verwendet werden kann )¹⁵.

Beachte, dass aus Sicht der Verteidigungsumgehung beide Imitations-APIs verwendet werden sind leichte Wrapper über dem undokumentierten Syscall NtSetInformationThread (z. B. aufgerufen mit einer ThreadInformationClass von ThreadImpersonationToken). Daher sind sie ein gutes Ziel für Angreifer, um direkte Syscalls zu nutzen, um Benutzermodus-Hooks mit Techniken wie https://github.com/jthuraisamy/SysWhispers zu umgehen.

Außerdem ist es wichtig zu betonen, dass Windows strenge Regeln für Imitation hat. Diese sind unten aufgeführt und stammen von der MSDN-Seite von ImpersonateLoggedOnUser:

Alle Impersonate-Funktionen, einschließlich ImpersonateLoggedOnUser, erlauben die gewünschte Impersonation, wenn eine der folgenden Kriterien zutrifft:
    - Das gewünschte Impersonationsniveau des Tokens ist geringer als SecurityImpersonation, wie SecurityIdentification oder SecurityAnonymous
    - Der Anrufer hat das Privilegium SeImpersonatePrivilege.
    - Ein Prozess (oder ein anderer Prozess in der Anmeldesitzung des Aufrufers) erstellte das Token mit expliziten Zugangsdaten über die Funktion LogonUser oder LsaLogonUser.
Die authentifizierte Identität ist dieselbe wie beim Anrufer

Zusätzlich muss das Integritätslevel des personierten Tokens ebenfalls geringer oder gleich dem Integritätslevel des anrufenden Prozesses sein, sonst scheitert auch der Imitationsaufruf¹⁶. Daher erhält ein nicht erhöhter Angreifer einen Admin-Nutzer interaktiv über gestohlene Zugangsdaten und die UAC ist aktiviert, ein nicht erhöhtes (z. B. gefiltertes) Token zurück und hat daher keine Probleme, den zurückgegebenen Nutzer zu imitieren und seitlich zu bewegen usw.

"Die kuriose /NETONLY-Flagge"¹⁷

Ein Angreifer kann jedoch feststellen, dass der Versuch, sich mit gestohlenen Zugangsdaten bei einem Benutzer anzumelden , scheitert. Dies kann aus verschiedenen Gründen liegen, zum Beispiel dass die Zugangsdaten gültig sind, das Konto aber keine Berechtigungen hat, sich auf dieser speziellen Arbeitsstation anzumelden, oder nur in einer anderen Domäne gültig sind usw. Darüber hinaus möchte der Angreifer möglicherweise ganz vermeiden, sich in ein hochprivilegiertes Konto einzuloggen, da dies in bestimmten Kontexten sehr anomal erscheinen kann (z. B. Ein Domain-Administrator, der sich auf den Host eines niedrig privilegierten Geschäftsnutzers einloggt, sollte äußerst verdächtig sein.¹⁸

In diesem Szenario kommt die LOGON32_LOGON_NEW_CREDENTIALS Flagge dem Angreifer zu Hilfe. Wenn ein Angreifer die LogonUserW-Funktion mit diesem Flag aufruft und eine gültige Menge Anmeldedaten weitergibt (zum Beispiel gefunden durch das Herumschnüffeln von Dateifreigaben), erlaubt Windows dem Aufrufer, sein aktuelles Token zu duplizieren, weist aber auf eine neue Anmeldesitzung, die als New Credentials-Anmeldesitzung bezeichnet wird und die gestohlenen Zugangsdaten zwischengespeichert wird. Dadurch hat der Benutzer lokal immer noch denselben Sicherheitskontext (z. B. hat er noch eine Kopie desselben Zugriffstokens; es zeigt nur auf eine neue Anmeldesitzung), jedoch liefern Versuche, sich aus der Ferne zu authentifizieren, die neuen Zugangsdaten im Aufruf an LogonUserW¹⁹ übermittelt werden. Dies ist im untenstehenden Diagramm dargestellt:

Daher bietet das LOGON32_LOGON_NEW_CREDENTIALS-Flag einen nativen Mechanismus, mit dem Ihr aktueller Zugriffstoken auf eine andere Anmeldesitzung und damit andere Zugangsdaten verweisen lässt.²⁰

Beachten Sie, dass das Aufrufen von LogonUserW mit dem LOGON32_LOGON_NEW_CREDENTIALS-Flag die Zugangsdaten beim Anruf nicht validiert (sie können kompletter Junk sein), sondern nur von einem Domain Controller zum Zeitpunkt entfernter Authentifizierungsanfragen validiert werden. 

Als weiteres Beispiel eine kurze Durchsicht des Codes für die Aufgabe 'MakeToken' aus dem Open-Source-Bereich. Das NET C2-Framework Covenant zeigt genau denselben Ansatz: Es nimmt eine Benutzername/Passwort-Kombination und erstellt eine neue Anmeldesitzung/Token mit ihnen, indem es die LOGON32_LOGON_NEW_CREDENTIALS-Flagge übergibt, bevor es fortfährt, das zurückgegebene Token zu imitieren. 

Außerdem kannst du genau dasselbe Verhalten mit CreateProcessWithLogonW replizieren, indem du eine dwLogonFlags von LOGON_NETCREDENTIALS_ONLY übergibst.²¹

BOOL CreateProcessWithLogonW( 
  LPCWSTR               lpUsername,
  LPCWSTR               lpDomain,
  LPCWSTR               lpPassword,
  DWORD                 dwLogonFlags,
  LPCWSTR               lpApplicationName,
  LPWSTR                lpCommandLine,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCWSTR               lpCurrentDirectory,
  LPSTARTUPINFOW        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

Der entscheidende Unterschied besteht darin, dass dabei ein neuer Prozess mit dem zurückgegebenen Token gespawnt wird, im Gegensatz zur zuvor besprochenen intra-process-Imitation. Tatsächlich ist das eingebaute Windows-Utility, runas, ein einfacher Wrapper um CreateProcessWithLogonW, und das /NETONLY-Flag bietet eine native Möglichkeit, einen neuen Prozess mit unterschiedlichen Netzwerkzugangsdaten zu starten, wie unten gezeigt:

Genau wie zuvor beschrieben scheint die neue Eingabeaufforderung lokal als derselbe Benutzer zu laufen (d. h. die im Token zwischengespeicherten Attribute sind bei lokalen Zugriffsprüfungen gleich; daher gibt Whoami 'astro\cosmo' zurück), aber alle Fern-Authentifizierungsversuche werden mit den gestohlenen Zugangsdaten des Benutzers 'ASTRO\Administrator' durchgeführt. 

Diese Anmeldesitzungen können mit dem LogonSessions-Tool von SysInternals angesehen werden. Anmeldesitzungen, die mit dem NewCredentials-Flag erstellt wurden, können durch das Logon-Typfeld wie unten gezeigt bestimmt werden:

Darüber hinaus hinterlassen anomale NewCredentials-Anmeldesitzungen (z. B. erzeugt über das NETONLY-Gerät) Artefakte in den Windows-Ereignisprotokollen. Diese können über die Ereignis-ID 4642 und einen LogonType von 9 identifiziert werden. Ein Beispiel ist im untenstehenden Bild zu sehen:

Beachten Sie, dass der ursprüngliche Benutzer im Feld SubjectUserName angezeigt wird und die angegebenen Netzwerkzugangsdaten (z. B. die übermittelten Zugangsdaten) in den Feldern TargetOutboundUser/DomainName angezeigt werden.²²

Auto-Elevation

Eine weitere Besonderheit aus Sicht der lokalen Privilegiensteigerung ist, dass CreateProcessWithLogonW für rid-500-Konten automatisch das zurückgegebene Token für interaktive Anmeldungen erhöht (z. B. wird UAC ignoriert). Daher kann CreateProcessWithLogonW ein lokales/Domain-Admin-Konto zugeordnet werden, um einen erhöhten Prozess aus einem mittleren oder nicht erhöhten Kontext auszuführen.

Dieses Verhalten kann mit Runas überprüft werden. Wenn beispielsweise runas verwendet wird, um einen Prozess mit einem lokalen Admin-Konto zu starten (z. B. runas /user:"Administrator" cmd.exe), wird der resultierende Prozess erhöht (z. B. hohe Integrität). Wenn jedoch ein Nicht-rid-500-Konto verwendet wird (das sich noch in der lokalen Administratorengruppe befindet), bleibt der resultierende Prozess nicht erhöht (z. B. handelt es sich um ein gefiltertes Token / Medium Integrity).

Beachten Sie, dass dieses Verhalten mit den für LogonUserW aufgeführten Permutationen in Tabelle 1 übereinstimmt. Daher könnte ein nicht erhöhter Angreifer auch einen (nicht rid-500) Admin-Benutzer als Netzwerk-Login anmelden und ein erhöhtes Token mit allen aktivierten Rechten erhalten.

Allerdings sollte der Angreifer gemäß den zuvor beschriebenen Imitationsregeln mit diesem Token tatsächlich nichts tun können, da alle Versuche, das erhöhte Token zu imitieren, scheitern, da es eine höhere Integritätsstufe als der Aufrufer hat. Dennoch ist es tatsächlich möglich, den erhöhten Token zu duplizieren, das Integritätsniveau des kopierten Tokens auf Medium zu senken (NB 'isElevated' gilt weiterhin)²³ und damit zu beginnen, den erhöhten Token aus einem Kontext der Unelevated/Medium-Integrität²⁴ zu imitieren. Daher kann man aus Sicht eines Imitationstokens das Standardverhalten von Windows umgehen, das nur bestimmte Konten erhöht, und ein erhöhtes Token nachahmen, unabhängig davon, ob es sich um ein Rid-500-Konto handelt oder nicht.

Prozessentwicklung

Beachte, dass standardmäßig beim Erstellen eines Kindprozesses dein primäres Token erbt, selbst wenn du gerade einen anderen Sicherheitskontext²⁵ imitierst. Wenn du zum Beispiel einen SYSTEM-Token imitierst und CreateProcess() aufrufst, erbt dieser trotzdem eine Kopie des primären Prozess-Tokens (anstatt den SYSTEM-Sicherheitskontext des Threads zu übernehmen).²⁶

Daher muss ein Angreifer, der einen neuen Prozess in einem anderen Sicherheitskontext starten möchte, entweder:

• Verwenden Sie CreateProcessWithLogonW mit expliziten Zugangsdaten (wie bereits besprochen) 
• Rufen Sie entweder CreateProcessWithTokenW oder CreateProcessAsUserW auf und übergeben Sie ein Handle an ein Token (z. B. mit dem Token von LogonUser zurückgegeben oder häufiger über ein gestohlenes Token)

Beide Funktionen können einem Token einen Handle übergeben werden, der den Sicherheitskontext des neuen Prozesses darstellt.²⁷

BOOL CreateProcessWithTokenW(
  HANDLE                hToken,
  DWORD                 dwLogonFlags,
  LPCWSTR               lpApplicationName,
  LPWSTR                lpCommandLine,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  
  
  LPCWSTR

lpCurrentDirectory, LPSTARTUPINFOW lpStartupInfo, LPPROCESS_INFORMATION lpProcessInformation);

BOOL CreateProcessAsUserW(
  HANDLE                hToken,
  LPCWSTR               lpApplicationName,
  LPWSTR                lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL                  bInheritHandles,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCWSTR               lpCurrentDirectory,
  LPSTARTUPINFOW        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

Zum Beispiel wird CreateProcessAsUserW typischerweise vom Betriebssystem selbst verwendet, um nach einem erfolgreichen Login die Shell des Benutzers zu starten (es wird auch vom Secondary Logon-Service genutzt, wenn ein Benutzer creatProcessWithLogonW aufruft). In diesem Sinne erlaubt es einem Nutzer, "einen Prozess in die Anmeldesitzung seiner Wahl einzuschleusen"²⁸. Zur Info: Beide APIs sind Wrapper um CreateProcessInternalW (in KernelBase.dll ansässig).

Der entscheidende Unterschied besteht darin, dass der Aufrufer bestimmte Rechte haben muss, um diese beiden APIs²⁹ aufzurufen. Aus Angreifersicht ist das Ziel hier jedoch dasselbe; die Codeausführung im Sicherheitskontext des Zielbenutzers zu erhalten, um seitlich zu bewegen.

Eine interessante Besonderheit ist, dass das PowerShell Empire-Framework gezwungen war, diesen Prozess-Spawn-Ansatz zu verfolgen (der aus Erkennungssicht wohl deutlich rauscher ist), aufgrund von Einschränkungen bei der Handhabung von PowerShell mit Impersonation und Multithreading, wie die Anmerkungen hier ausführlicher erklären.

In jedem Fall bleibt der Workflow für die Verwendung von Prozess-Spawn-Token-Manipulationstechniken derselbe. Sobald der Angreifer einen Handle für das Token erhalten hat (über OpenProcess/OpenProcessToken , falls es das primäre Token ist, oder OpenThread/OpenThreadToken im Falle eines Threads, der sich ausgibt), muss der Angreifer DuplicateTokenEx aufrufen, um eine lokale (primäre) Kopie des Zieltokens zu erstellen und diese dann entweder an die Funktionen CreateProcessWithTokenW oder CreateProcessAsUserW bereitzustellen.

Beachten Sie, dass Angreifer in diesem Fall nur an privilegierten Anmeldesitzungen interessiert sind, die keine Netzwerkanmeldungen sind, da Netzwerkanmeldungen keine Zugangsdaten zwischenspeichern und sich daher nicht bei anderen Hosts authentifizieren können .

2. Pass-the-Ticket

Windows bietet eine native Methode, um eine sehr ähnliche Technik wie das NETONLY-Flag mit Kerberos³⁰ durchzuführen. Diese Technik ist insofern noch leistungsfähiger, als sie nicht erfordert, dass ein Angreifer eine neue Anmeldesitzung erstellt, sondern vielmehr die zwischengespeicherten Kerberos-Zugangsdaten (z. B. TGT), die mit ihrer Anmeldesitzung (und damit dem aktuellen Zugriffstoken) verbunden sind, willkürlich ändert, wie unten gezeigt:

Um mit dem Kerberos-SSP zu interagieren und den Kerberos-Ticket-Cache zu verwalten, kann ein Prozess LsaCallAuthenticationPackage (in Sspicl.dll) aufrufen:

NTSTATUS LsaCallAuthenticationPackage( 
  HANDLE    LsaHandle,
  ULONG     AuthenticationPackage,
  PVOID     ProtocolSubmitBuffer,
  ULONG     SubmitBufferLength,
  PVOID     *ProtocolReturnBuffer,
  PULONG    ReturnBufferLength,
  PNTSTATUS Protokollstatus
);

Beachten Sie, dass der Nutzer zuvor LsaConnectUntrusted angerufen haben muss, um eine Verbindungsadresse zum LSA-Server und LsaLookupAuthenticationPackage zu erhalten, um die ID des Kerberos-Pakets (MICROSOFT_KERBEROS_NAME_A) zu finden. Zusätzlich zeigt die Inspektion dieser Funktionen in IDA (sie können ebenfalls in Sspicl.dll liegen), dass sie über RPCmit der LSA verbunden sind.³¹.

Über LsaCallAuthenticationPackage kann ein Nutzer eine Anzahl sensibler Anfragen stellen, wobei die genauen verfügbaren Anfragen davon abhängen, ob sie erhöht sind oder nicht. Zum Beispiel kann ein nicht erhöhter Nutzer grundlegende Ticketverwaltungsmaßnahmen³² ausführen, wie das Aufzählen seiner aktuellen aktiven Tickets, das Löschen des Ticket-Caches und das Anlegen beliebiger Tickets auf die aktuelle Anmeldesitzung³³. Dadurch kann ein Nutzer effektiv die mit seiner aktuellen Anmeldesitzung zwischengespeicherten Zugangsdaten ändern und somit beliebige Netzwerkzugangsdaten festlegen.

Zusätzlich kann ein Angreifer aus einem erhöhten Kontext³⁴ Tickets (z. B. Zugangsdaten) anderer Nutzer auflisten und löschen, wodurch ähnliche Funktionen wie Mimikatz bereitgestellt werden, ohne einen Handle für LSASS³⁵ öffnen zu müssen.

Eine vollständige Liste der Nachrichtentypen, die an das Kerberos-Authentifizierungspaket gesendet werden können, finden Sie hier. Um das aktuelle TGT zu ändern, das mit einer bestimmten Anmeldesitzung verknüpft ist, kann die KerbSubmitTicketMessage übermittelt werden, die folgende Nachrichtenstruktur verwendet:

Typedef struct _KERB_SUBMIT_TKT_REQUEST {
    KERB_PROTOCOL_MESSAGE_TYPE MessageType;
    LUID LogonId;
    ULONG Flags;
    KERB_CRYPTO_KEY32 Key;
    ULONG KerbCredSize;
    ULONG KerbCredOffset;
} KERB_SUBMIT_TKT_REQUEST, *PKERB_SUBMIT_TKT_REQUEST

Daher zeigt für eine KerbSubmitTicketMessage der Parameter ProtocolSubmitBuffer einfach auf einen Speicherblock, der aus einer KERB_SUBMIT_TKT_REQUEST Struktur besteht, gefolgt unmittelbar von einem ASN-codierten Kerberos-Ticket (das das Ticket ist, das auf die angegebene Anmeldesitzung angewendet werden soll). Der relevante Code in mimikatz für das Einreichen von KerbSubmitTicketMessage-Anfragen ist hier und in Rubeus hier zu finden. 

Nach dem Anruf bei LsaCallAuthenticationPackage wurde das TGT des Nutzers nun auf das gestohlene Ticket. Ab diesem Zeitpunkt authentifizieren sich alle Versuche, auf Netzwerkressourcen durch einen Prozess/Thread zuzugreifen, der mit dem Zugriffstoken des Benutzers bzw. der interaktiven Anmeldesitzung des Benutzers verknüpft ist, automatisch über Kerberos unter Verwendung des gestohlenen TGT (z. B. durch die Anforderung verschiedener Service-Tickets/TGS für Ressourcen innerhalb der Domäne). 

Beachten Sie, dass ein Nutzer nur eine TGT mit seiner aktuellen Anmeldesitzung verknüpft haben kann. Daher löscht das Anlegen eines neuen Tickets das vorherige Ticket des Nutzers. Was, wenn ein Angreifer sein aktuelles TGT erhalten möchte? In diesem Fall kommt erneut das NETONLY-Flag zur Rettung – ein Angreifer kann über CreateProcessWithLogonW mit beliebigen/unbrauchbaren Zugangsdaten einen "opfernden" NETONLY-Prozess erstellen. Dies wird einen neuen Dummy-Prozess und vor allem eine neue Anmeldesitzung (und damit ein Zugriffstoken) schaffen, auf die ein gestohlenes TGT angewendet werden kann (und somit das aktuelle Ticket des Nutzers erhalten bleibt)³⁶. 

Eine wichtige Schlussfolgerung für Verteidigungspraktiker aus dieser Technik ist, dass alle Aktivitäten über LsaCallAuthenticationPackage (und damit über RPC) ausgeführt werden, weshalb keine direkte Interaktion mit lsass erforderlich ist (Anmerkung: direkt bezieht sich hier auf das Öffnen eines Handles für lsass über OpenProcess). Außerdem erfolgt für diesen speziellen Anwendungsfall (PTT) die gesamte Aktivität über lokale RPC, bis ein Angreifer versucht, sich bei einem entfernten Host zu authentifizieren (der neue Anmeldungen generiert). 

Als weiteres Beispiel enthält die README für Rubeus folgende Aussage: 

"Rubeus hat keinen Code, der LSASS berührt (und keiner ist beabsichtigt), daher ist seine Funktionalität auf das Extrahieren von Kerberos-Tickets über die LsaCallAuthenticationPackage()-API beschränkt." 

Daher könnte jede Erkennungslogik, die auf Handle-Zugriff auf LSASS basiert (z. B. über eine ObjectPreCallback-Kernel-Routine für einen bestimmten Prozess oder einen Thread-Handle oder einen Benutzermodus-Hook auf OpenProcess/NtOpenProcess), diese Aktivität übersehen. Daher ist es ein potenzieller toter Fleck für beispielsweise Verteidiger, die sich auf Sysmon-Prozesszugriffsereignisse verlassen, um bei verdächtigen Zugriff auf Prozesshandlagen zu warnen.

3. Pass-the-Hash (PtH)

Die letzten beiden Techniken, die dieser Blog behandeln wird, sind Beispiele dafür, wie ein Angreifer die zwischengespeicherten Zugangsdaten seines aktuellen Zugriffstokens/der Anmeldesitzung "illegitim" ändert, indem er den LSASS-Speicher direkt modifiziert . Im PtH-Szenario bleibt das Zugriffstoken des Angreifers unverändert und zeigt auf dieselbe Anmeldesitzung, jedoch werden die zugehörigen zwischengespeicherten Zugangsdaten direkt auf einen gestohlenen Hash überschrieben. Ab diesem Punkt verwenden alle Fernauthentifizierungsversuche den gestohlenen Hash, wie unten gezeigt:

In diesem Sinne können sowohl PtH als auch OPtH funktional identisch mit der zuvor diskutierten NETONLY-Technik betrachtet werden.

Der typische Workflow eines PtH-Angriffs ist:

• Öffnen Sie einen Schreibgriff auf LSASS (z. B. über OpenProcess/NtOpenProcess mit einem gewünschten Zugriff von PROCESS_VM_WRITE)
• Listen Sie die verlinkte Liste der Anmeldesitzungen auf
• Finden Sie die interessierende Anmeldesitzung und identifizieren Sie das erforderliche Authentifizierungspaket (im Ticket von PtH/NTLM ist dies das MSV1_0 Authentifizierungspaket )
• Aktualisieren Sie die zugehörigen zwischengespeicherten Zugangsdaten

Beachten Sie, dass diese Techniken oft auf dem Parsen und Ändern undokumentierter Windows-Strukturen basieren. Das wird in diesem Blog nicht behandelt, aber weitere Informationen darüber, wie dies durchgeführt wird, finden Sie hier und hier. 

Daher werden die zwischengespeicherten Zugangsdaten im Speicher automatisch zur Fernauthentifizierung verwendet, wie im üblichen Single Sign-On-Authentifizierung-Design, wenn ein Prozess/Thread, der als Token läuft, versucht, auf eine entfernte Ressource zuzugreifen.  

Beachten Sie, dass in diesem einfachen Ticket keine zusätzlichen Anmelde-Sessions- oder Zugriffstoken erstellt wurden. Ähnlich wie bei Pass-the-Ticket-Angriffen müssen diese Tools jedoch häufig neue Junk-NETONLY-Prozesse/Anmeldesitzungen erstellen, um bestehende Zugangsdaten zu erhalten oder gestohlene Zugangsdaten anzuwenden. 

Als Hinweis: Um einen Schreibgriff für LSASS zu erhalten, Malware typischerweise zwei Ansätze:

• SeDebugPrivilege³⁷erwerben
• Stehle und imitiere einen SYSTEM-Token

Der erste Ansatz wurde im ersten Teil dieser Blogserie besprochen, jedoch ist der letztere ein typisches Beispiel für das Stehlen/Nachahmen eines Tokens, um lokale Zugriffsprüfungen zu umgehen (z. B. das Stehlen eines SYSTEM-Tokens mit aktiviertem Privilegium, z. B. SeTcbPrivilege). Ein SYSTEM-Token wird üblicherweise durch den Diebstahl des primären Tokens aus Winlogon erhalten.

4. Overpass-the-Hash (OPtH)

Die Overpass-the-Hash-Technik verwendet dasselbe Konzept wie Pass-the-Hash, mit einem entscheidenden Unterschied: Sie wandelt einen Hash in ein vollwertiges TGT-Ticket um. 

Wenn sich ein Benutzer erstmals an einer Windows-Arbeitsstation anmeldet, wird im Rahmen des Kerberos-Authentifizierungsprozesses der Passwort-Hash des Benutzers verwendet, um einen Zeitstempel zu verschlüsseln, um die Identität des Benutzers gegenüber dem Domain Controller / Key Distribution Center (KDC) zu validieren und ein TGT zu erhalten. Overpass-the-Hash ändert diese zwischengespeicherten Hashes³⁸ im Speicher und startet dann das normale Kerberos-Authentifizierungsprotokoll (AS-REQ/AS_REP usw.), um ein vollwertiges TGT für einen gestohlenen Hash zu erhalten.³⁹

Diese Technik kann über mimikatz' pth-Befehl ausgeführt werden (der irreführend als pth bezeichnet wird, wenn tatsächlich unter der Haube Overpass-the-Hash ausgeführt wird):

mimikatz # sekurlsa::pth /user:Administrator /domain:ASTRO.testlab /ntlm: c0f969f35beb20e8f09ce86ef42ccd51

Dies führt im Wesentlichen die gleichen Schritte aus wie PtH, nur dass es das Kerberos-SSP (und damit kerberos.dll) anvisiert.⁴⁰

Da diese Technik erneut das Löschen des aktuellen TGT beinhaltet, das mit der Anmeldesitzung des Benutzers verbunden ist, kann ein Angreifer einen NETONLY-Prozess (mit einer zugehörigen Dummy-Anmeldesitzung) verwenden, um sein aktuelles TGT zu erhalten, was genau die Ausführung des Overpass-the-Hash von Mimikatz ist . 

Erstens startet er einen neuen Prozess im suspendierten Zustand über CreateProcessWithLogonW mit dem LOGON_NETCREDENTIALS_ONLY-Flag. Anschließend erhält es einen Handle für das primäre Token dieses ausgesetzten Prozesses und ruft die Authentifizierungs-ID für die neue Dummy-Anmeldesitzung über GetTokenInformation ab. Diese Funktion wird verwendet, um Informationen, die im Token zwischengespeichert sind, über das TOKEN_INFORMATION_CLASS Enum, das in diesem Ticket TokenStatistics ist, abzufragen. 

Nachdem er die Authentifizierungs-ID erhalten hat, kann Mimikatz nun beginnen, die verknüpfte Liste der Anmeldesitzungen innerhalb von LSASS aufzuzählen und nach der neu erstellten Anmeldesitzung zu suchen. Sobald sie die Ziel-Anmeldesitzung (über die Authentifizierungs-ID) gefunden hat, kann sie die damit verbundenen Kerberos-Zugangsdaten aktualisieren. Sobald die Zugangsdaten aktualisiert sind, kann das Token (dessen entsprechende Anmeldesitzung nun mit dem gestohlenen Hash verknüpft ist) über DuplicateTokenEx in ein Impersonationstoken umgewandelt und wie bisher gesehen über SetThreadToken imitiert werden. 

Auch in dieser Phase werden alle Versuche, auf Ressourcen im Netzwerk zuzugreifen, die Hash-Kombination aus Domain/Benutzer und Passwort als Argumente für Mimikatz zur Authentifizierung verwendet. Daher werden alle Ferninteraktionen mit dem Zugriff und den Rechten der gestohlenen Zugangsdaten durchgeführt.

Fazit

Ziel dieser zweiteiligen Blogserie war es, zu erklären, wie grundlegende Konzepte in Windows Security unter der Haube funktionieren und zu zeigen, wie Angreifer diese Features missbrauchen, um Windows-Domains zu kompromittieren. Dieser Blog hat gezeigt, dass Angreifer unabhängig davon, welche Tools oder welcher Authentifizierungsanbieter missbraucht werden, unter einer Reihe von Einschränkungen agieren, die zu denselben anomalen Signalen für die Manipulation von Zugriffstoken führen (z. B. anomale Anmeldungen nur über das Netzwerk). Diese Einschränkungen werden durch die grundlegende Beziehung zwischen Zugriffstoken, Anmeldesitzungen und zwischengespeicherten Zugangsdaten bestimmt.

Bereit für einen ganzheitlichen Datenschutz mit Elastic Security? Probieren Sie es noch heute kostenlos aus oder erleben Sie unsere neueste Version auf dem Elasticsearch-Dienst auf Elastic Cloud. Und nutzen Sie unser Quick Start-Training, um sich auf den Erfolg vorzubereiten.

Quellen

1. Für eine Zusammenfassung, wie die Kerberos-Authentifizierung funktioniert, siehe Programming Windows Security, Keith Brown or https://posts.specterops.io/kerberosity-killed-the.... Außerdem enthält Rubeus, ein Toolkit zur Interaktion mit Kerberos, ein äußerst informatives Readme, das für weiterführende Lektüre empfohlen wird.

2. Denken Sie daran, dass Windows sich automatisch mit den in der Anmeldesitzung zwischengespeicherten Zugangsdaten authentifiziert, wann immer ein Benutzer versucht, gemäß dem Windows-Single Sign-On-Authentifizierung-Mechanismus auf eine Netzwerkressource zuzugreifen. Zwischengespeicherte Zugangsdaten können sich auf jeden Authentifizierungsanbieter beziehen (z. B. NTLM-Hashes oder Kerberos-Tickets). NB: Dies setzt voraus, dass der Nutzer interaktiv eingeloggt ist (nicht im Netzwerk).

3. Dies dient in der Regel dazu, einen Tritt durch Incident-Response oder Isolation des Wirts zu vermeiden.

4. Dies gilt offensichtlich nur für Angreiferaktivitäten auf einem kompromittierten Host, im Gegensatz dazu, dass ein Angreifer Code von einer anderen Quelle, z. B. aus der Ferne über Impacket, ausführt.

5. https://clymb3r.wordpress.com/2013/11/03/powershel...

6. Siehe das 'steal_token'-Befehl aus Cobalt Strike als Beispiel für diese Technik: https://www.cobaltstrike.com/help-beacon

7. Dieser Kommentar aus dem archivierten PowerSploit-Framework sollte auch eine weitere Klarstellung zu diesem Unterschied zwischen Token-Diebstahl zur lokalen Privilegiensteigerung und lateraler Bewegung liefern.

8. Alternativ können Angreifer auch den Passwort-Spray-Weg gehen oder versuchen, NTLM-Schnüffel- und Wiederholungsangriffe über Werkzeuge wie Responder anzuwenden.

9. Beachten Sie, dass beide LogonUserA/W einfache Wrapper um LogonUserExExW in SspiCli.dll

10. Auf genau dieselbe Weise kann CreateProcessWithLogonW ein lokales Admin-Konto (rid-500) übermittelt werden, um einen erhöhten Prozess aus einem mittleren oder nicht erhöhten Kontext auszuführen.

11. Es gibt entfernte UAC-Registrierungsoptionen, die dieses Verhalten ändern können.

12. Es gibt einen zusätzlichen Anmeldetyp, LOGON32_LOGON_NETWORK_CLEARTEXT, der im Wesentlichen ein Netzwerk-Login mit zwischengespeicherten Zugangsdaten ist. Weitere Informationen finden Sie unter Programming Windows Security, Keith Brown.

13. Siehe für weitere Informationen:

https://blueteamer.blogspot.com/2018/12/disabling-...
https://support.microsoft.com/en-gb/help/951016/de...
https://labs.f-secure.com/blog/enumerating-remote-...

14. NB: Es gibt auch eine DuplicateToken-Funktion , die aber nur ein Imitationstoken zurückgibt.

15. Dies kann durch die Betrachtung der Funktion in IDA überprüft werden. Alternativ schau mal hier auf ReactOS nach.

16. Diese Zusammenfassung ist eine leichte Vereinfachung der Identitätssicherheit. Für einen ausführlicheren Überblick siehe James Forshaws "Einführung in die Eskalation des logischen Privilegs auf Windows" (S. 26): https://conference.hitb.org/hitbsecconf2017ams/mat...

17. Dieser Titel stammt aus einem ausgezeichneten Blog von Raphael Mudge: Windows Access Tokens and Alternate Credentials.

18. Dies ist typischerweise der Hauptgrund, warum Option 2 von Angreifern nicht häufig verwendet wird.

19. Daher zeigt das Ausführen von 'whoami' immer noch denselben Benutzer an (da der Token weiterhin derselbe ist), obwohl das duplizierte Token unterschiedliche Netzwerkzugangsdaten hat. Dies ist eine häufige Verwirrungsquelle bei der Verwendung des make_token-Befehls von Cobalt Strike (das die gleiche Technik wie unter der Haube beschrieben ausführt).

20. Die Windows RPC/COM-APIs ermöglichen es dem Benutzer außerdem, ausschließlich netzwerkbezogene Zugangsdaten anzugeben. Dies kann beispielsweise für RPC erreicht werden, indem man RpcBindingSetAuthInfoExW aufruft und eine SEC_WINNT_AUTH_IDENTITY-Struktur über den AuthIdentity-Parameter übergibt. Weitere Informationen finden Sie unter Programming Windows Security, Keith Brown und https://docs.microsoft.com/en-us/windows/win32/wmisdk/setting-authentication-using-c-.

21. Obwohl die beiden Flaggen unterschiedliche Namen haben, bleibt ihre Bedeutung dieselbe; Diese Zugangsdaten dürfen nur im Netzwerk verwendet werden.

22. Beachten Sie, dass es immer noch Wege gibt, verdächtige Ereignisprotokolle für anomale Anmeldesitzungen zu umgehen.

23. Das ist ein James-Forshaw-Trick – siehe den folgenden Blog für weitere Details: https://www.tiraniddo.dev/2017/05/reading-your-way.... Außerdem ist TokenViewer ein ausgezeichnetes Werkzeug, um mit dieser Art von Technik zu experimentieren.

24. Mit diesem resultierenden Impersonationstoken ist es möglich, eine Datei an System32 usw. zu schreiben.

25. Es kann dennoch legitime Gründe geben, sich vor dem Aufruf einer API zu imitieren, zum Beispiel um ein Privileg zu erhalten, das man derzeit nicht hat, bevor man eine API aufruft, die dies erfordert (wobei einige APIs Rechte automatisch aktivieren).

26. Es gibt einige Möglichkeiten, das zu umgehen. Zum Beispiel kann man einen Prozess als Kind eines SYSTEM-Prozesses erzeugen, indem man über OpenProcess mit dem PROCESS_CREATE_PROCESS Zugriff einen SYSTEM-Prozess auf einen SYSTEM-Prozess bekommt. Dieser HANDLE kann dann als ParentProcess-Parameter an NtCreateProcess weitergegeben werden. Dies kann auch über den Parameter PROC_THREAD_ATTRIBUTE_PARENT_PROCESS und CreateProcess: https://gist.github.com/xpn/a057a26ec81e736518ee50...erreicht werden.

27. Merkwürdigerweise nimmt CreateProcessWithTokenW ein dwLogonFlags-Argument, obwohl es auch einen Handle für ein bestehendes Token benötigt, das per Definition bereits eine entsprechende Anmeldesitzung haben sollte. Es scheint wahrscheinlich, dass das etwas mit dem Laden des Benutzerprofils zu tun hat.

28. Programmierung von Windows-Sicherheit, Keith Brown

29. Konkret SE_IMPERSONATE_NAME für CreateProcessWithTokenW und SE_INCREASE_QUOTA_NAME (&) SE_ASSIGNPRIMARYTOKEN_NAME (falls das Token nicht zuweisenbar ist) für CreateProcessAsUserW

30. Eine Zusammenfassung der Kerberos-Authentifizierung finden Sie hier und siehe Folgendes für weitere Informationen zu Kerberos-bezogenen Angriffen: https://www.blackhat.com/docs/us-14/materials/us-1..., , https://github.com/GhostPack/Rubeus#readme

31. https://googleprojectzero.blogspot.com/2019/12/cal...

32. Zum Beispiel bietet das native Windows-Tool klist ähnliche Funktionen und ist eindeutig ein Wrapper um LsaCallAuthenticationPackage.

33. Beachten Sie, dass ein nicht erhöhter Nutzer Tickets nur auf seine eigene Anmeldesitzung anwenden kann; erhöhte Rechte sind erforderlich, um eine TGT auf eine andere Anmeldesitzung anzuwenden.

34. Es gibt einige Vorbehalte/Feinheiten zu dieser Aussage, die besser vom Rubeus-Readme beantwortet werden können. Kurz gesagt, der Anrufer muss eine LSA-Verbindung über LsaRegisterLsaProcess registrieren, was das SeTcbPrivilege-Privileg erfordert (d. h. der Anrufer ist Teil der vertrauenswürdigen Rechenbasis).

35. Als Beobachtung kann man auch mit dem msv1_0-Authentifizierungspaket über LsaCallAuthenticationPackage kommunizieren und folgende Nachrichtentypen senden: https://docs.microsoft.com/en-us/windows/win32/api..., obwohl ich nicht untersucht habe, ob es auch möglich ist, NTLM-Zugangsdaten über diese Schnittstelle abzurufen.

36. Weitere Informationen finden Sie im Rubeus GitHub Repository Readme, das eine fantastische Zusammenfassung vieler kerberos-bezogener Funktionalität und Opsec-Überlegungen enthält.

37. Siehe hier ein Beispiel zur Ermöglichung eines Privilegs

38. Dies kann überprüft werden, indem man in IDA auf PsOpenProcess/Thread schaut und nach einem Anruf bei SePrivilegeCheck sucht.

39. Beachten Sie, dass der Erwerb von SeDebugPrivilege aus Sicht der Erkennungslogik tendenziell sehr rauschig ist.

40. Beachten Sie, dass der Hash/Schlüssel rc4_hmac sein kann (z. B. NTLM), aes128_hmac, aes256_hmac usw. Siehe hier für mehr Informationen.

41. Siehe für weitere Details: https://www.blackhat.com/docs/us-14/materials/us-1...

42. Zur Anmerkung: Die asktgt-Funktionalität von Rubeus führt eine Variante des Overpass-the-Hash durch, indem der rohe AS-REQ-Verkehr für einen gegebenen Hash aus einem nicht erhöhten Kontext gebaut wird, ohne LSASS berühren zu müssen.