KrbRelayUp

Ein einfacher Wrapper um einige der Funktionen von Rubeus und KrbRelay (sowie ein paar weiteren erwähnenswerten Projekten im Abschnitt „Danksagungen"), um den Missbrauch der folgenden Angriffsprimitive zu vereinfachen:

0. (Optional) Erstellung eines neuen Maschinenkontos (New-MachineAccount)
1. Erzwingung der Authentifizierung des lokalen Maschinenkontos (KrbRelay)
2. Kerberos-Relay zu LDAP (KrbRelay)
3. Hinzufügen von RBCD-Rechten und Erlangen eines privilegierten ST für die lokale Maschine (Rubeus)
4. Verwendung dieses ST zur Authentifizierung am lokalen Dienst-Manager und Erstellung eines neuen Dienstes als NT/SYSTEM. (SCMUACBypass)

Dies ist im Wesentlichen eine universelle, nicht behobene lokale Privilege Escalation in Windows-Domänenumgebungen, in denen LDAP-Signierung nicht erzwungen wird (die Standardeinstellung).

UPDATE: Hier ist ein hervorragender Artikel von @an0n_r0 darüber, wie man diesen Angriff manuell durchführt (unter Verwendung der Original-Tools für diesen Angriffspfad: PowerMad/SharpMad, KrbRelay, Rubeus und SCMUACBypass)

Update – Unterstützung für Shadow Credentials

Ich habe einige Funktionen hinzugefügt, um dieses Angriffsprimitiv mithilfe von Shadow Credentials zu unterstützen. Beachte, dass dadurch die Notwendigkeit entfällt, ein weiteres Maschinenkonto hinzuzufügen (oder zu besitzen).

Hinweis: Diese Angriffsmethode umgeht die Abschwächung durch Protected Users (bzw. „Konto ist sensibel und kann nicht delegiert werden") aufgrund des S4U2Self-Missbrauchs.

1. Erzwingung der Authentifizierung des lokalen Maschinenkontos (KrbRelay)
2. Kerberos-Relay zu LDAP (KrbRelay)
3. Generierung einer neuen KeyCredential und Hinzufügen derselben zum 'msDS-KeyCredentialLink'-Attribut des lokalen Maschinenkontos. (Whisker und KrbRelay)
4. Verwendung dieser KeyCredential, um über PKInit ein TGT für das lokale Maschinenkonto zu erhalten. (Rubeus)
5. Verwendung des TGT, um über S4U2Self und TGSSUB ein privilegiertes ST für die lokale Maschine zu erhalten. (Rubeus)
6. Verwendung dieses ST zur Authentifizierung am lokalen Dienst-Manager und Erstellung eines neuen Dienstes als NT/SYSTEM. (SCMUACBypass)

UPDATE: Hier ist ein hervorragender Artikel von @icyguider darüber, wie man die ShadowCred-Methode dieses Angriffs manuell durchführt (unter Verwendung der Original-Tools für diesen Angriffspfad: KrbRelay, Rubeus und SCMUACBypass) sowie über die Verwendung von NimCrypt2, um die verschiedenen Tools zu packen und einige Erkennungen durch Verteidigungsmechanismen zu umgehen.

Update – Unterstützung für ADCS Web Enrollment

Ich habe Unterstützung für das Relaying von KRB-Authentifizierung von Maschinenkonten an ADCS Web Enrollment (anstelle von LDAP) hinzugefügt. Dadurch entfällt die Anforderung, dass LDAP-Signierung in der Domäne nicht erzwungen wird, da dieser Angriff nicht zu LDAP relayt.

Hinweis: Diese Angriffsmethode umgeht die Abschwächung durch Protected Users (bzw. „Konto ist sensibel und kann nicht delegiert werden") aufgrund des S4U2Self-Missbrauchs.

1. Erzwingung der Authentifizierung des lokalen Maschinenkontos (KrbRelay)
2. Kerberos-Relay zu ADCS (HTTP) (KrbRelay und ADCSPwn)
3. Generierung einer Zertifikatsanfrage im Namen des lokalen Maschinenkontos, Übermittlung an ADCS Web Enrollment und schließlich Abruf des Zertifikats für das lokale Maschinenkonto (ADCSPwn)
4. Verwendung dieses Zertifikats, um über PKInit ein TGT für das lokale Maschinenkonto zu erhalten. (Rubeus)
5. Verwendung des TGT, um über S4U2Self und TGSSUB ein privilegiertes ST für die lokale Maschine zu erhalten. (Rubeus)
6. Verwendung dieses ST zur Authentifizierung am lokalen Dienst-Manager und Erstellung eines neuen Dienstes als NT/SYSTEM. (SCMUACBypass)

Verwendung

KrbRelayUp - Relaying you to SYSTEM

FULL: Führt die vollständige Angriffskette aus. Optionen sind identisch mit RELAY. Das Tool muss auf der Festplatte liegen.

RELAY: Erste Phase des Angriffs. Erzwingt die Kerberos-Authentifizierung des lokalen Maschinenkontos, relayt sie zu LDAP und erstellt ein Kontrollprimitiv über das lokale Maschinenkonto mittels RBCD oder SHADOWCRED.
Verwendung: KrbRelayUp.exe relay -d FQDN -cn COMPUTERNAME [-c] [-cp PASSWORD | -ch NTHASH]

    -m   (--Method)                   Missbrauchsmethode, die nach einem erfolgreichen Relay zu LDAP verwendet werden soll <rbcd/shadowcred> (Standard=rbcd)
    -p   (--Port)                     Port für den COM-Server (Standard=12345)
    -cls (--Clsid)                    CLSID, die zum Erzwingen der Kerberos-Authentifizierung des lokalen Maschinenkontos verwendet werden soll (Standard=90f18417-f0f1-484e-9d3c-59dceee5dbd8)

    # RBCD-Methode:
    -c   (--CreateNewComputerAccount) Neues Computerkonto für RBCD erstellen. Verwendet den aktuell angemeldeten Benutzer.
    -cn  (--ComputerName)             Name des Angreifer-eigenen Computerkontos für RBCD. (Standard=KRBRELAYUP$)
    -cp  (--ComputerPassword)         Passwort des Computerkontos für RBCD. (Standard=ZUFALL [wenn -c aktiviert ist])

    # SHADOWCRED-Methode:
    -f   (--ForceShadowCred)          Das msDS-KeyCredentialLink-Attribut des angegriffenen Computerkontos löschen, bevor die neuen Shadow Credentials hinzugefügt werden. (Optional)

    # ADCS-Methode:
    -ca  (--CAEndpoint)               FQDN des CA-Endpunkts (Standard = gleicher Wert wie DC)
    -https                            Verbindung zum CA-Endpunkt über gesichertes HTTPS anstelle von HTTP)
    -cet (--CertificateTemplate)      Zertifikatsvorlage, die angefordert werden soll (Standard=Machine)


SPAWN: Zweite Phase des Angriffs. Verwendet das entsprechende Kontrollprimitiv, um ein Kerberos-Dienstticket zu erhalten, und verwendet es, um einen neuen Dienst zu erstellen, der als SYSTEM läuft.
Verwendung: KrbRelayUp.exe spawn -d FQDN -cn COMPUTERNAME [-cp PASSWORD | -ch NTHASH] <-i USERTOIMPERSONATE>

    -m   (--Method)                   Missbrauchsmethode, die in der RELAY-Phase verwendet wurde <rbcd/shadowcred> (Standard=rbcd)
    -i   (--Impersonate)              Zu impersonierender Benutzer. Sollte ein lokaler Administrator auf dem Zielcomputer sein. (Standard=Administrator)
    -s   (--ServiceName)              Name des zu erstellenden Dienstes. (Standard=KrbSCM)
    -sc  (--ServiceCommand)           Dienstbefehl [binPath]. (Standard = cmd.exe als SYSTEM starten)

    # RBCD-Methode:
    -cn  (--ComputerName)             Name des Angreifer-eigenen Computerkontos für RBCD. (Standard=KRBRELAYUP$)
    -cp  (--ComputerPassword)         Passwort des Computerkontos für RBCD. (entweder -cp oder -ch muss angegeben werden)
    -ch  (--ComputerPasswordHash)     NT-Hash des Passworts des Computerkontos für RBCD. (entweder -cp oder -ch muss angegeben werden)

    # SHADOWCRED | ADCS-Methode:
    -ce  (--Certificate)              Base64-kodiertes Zertifikat oder Pfad zur Zertifikatsdatei
    -cep (--CertificatePassword)      Zertifikatspasswort (falls zutreffend)


KRBSCM: Verwendet das aktuell geladene Kerberos-Dienstticket, um einen neuen Dienst zu erstellen, der als SYSTEM läuft.
Verwendung: KrbRelayUp.exe krbscm <-s SERVICENAME> <-sc SERVICECOMMANDLINE>

    -s  (--ServiceName)              Name des zu erstellenden Dienstes. (Standard=KrbSCM)
    -sc (--ServiceCommand)           Dienstbefehl [binPath]. (Standard = cmd.exe als SYSTEM starten)


Allgemeine Optionen:
    -d  (--Domain)                   FQDN der Domäne. (Optional)
    -dc (--DomainController)         FQDN des Domänencontrollers. (Optional)
    -ssl                             LDAP über SSL verwenden. (Optional)
    -n                               CreateNetOnly (muss auf der Festplatte liegen) anstelle von PTT verwenden, wenn das ST importiert wird (aktiviert, wenn der FULL-Modus verwendet wird)
    -v  (--Verbose)                  Ausführliche Ausgabe anzeigen. (Optional)

Beispiele

TODO

• Code-Refactoring und Aufräumarbeiten!!!
• ShadowCred-Angriff als RELAY-Methode hinzufügen
• TGTDELEG-Angriff in der SPAWN-Methode hinzufügen, für Szenarien Network Service->SYSTEM (Potatoes-Alternative)
• Das Problem beheben, das beim Versuch auftritt, die RELAY- und SPAWN-Methoden in einem Lauf zu kombinieren, sodass es als ein vollständiger Befehl verwendet werden kann. Wahrscheinlich hat es damit zu tun, dass sowohl RELAY- als auch SPAWN-Funktionen auf Hooks während der Initialisierung des COM-Servers angewiesen sind (Sobald RELAY seinen COM-Server initialisiert, kann SPAWN ihn nicht erneut initialisieren, um auch seine Hooks zu platzieren)

Abschwächung & Erkennung

• Erzwinge LDAP-Signierung und LDAP-Channel-Binding, um das Relaying der KRB-Authentifizierung des Maschinenkontos zu LDAP abzuschwächen. Dies kann über die GPO „Domänencontroller: LDAP-Server-Signaturanforderungen" konfiguriert werden. (Danke an Will Dormann für seinen Tweet zu dieser Angelegenheit)
• Erschwere die Erfüllung der Angriffsvoraussetzungen, indem du das MS-DS-Machine-Account-Quota-Attribut in AD auf 0 setzt. Dadurch wird die Möglichkeit entfernt, dass ein beliebiger Benutzer ein neues Maschinenkonto zur Domäne hinzufügt. Dies ist eine gefährliche Standardeinstellung in AD – stelle sicher, dass du sie änderst.
• Das Setzen des Flags „Konto ist sensibel und kann nicht delegiert werden" auf allen Admin-Konten (oder deren Aufnahme in Protected Users) würde dazu führen, dass kein Konto mit den erforderlichen Berechtigungen existiert, das delegiert werden kann, um den Angriffspfad abzuschließen. (Danke an Christoph Falta für diesen Tweet)
• Abschwächung für ADCS-Relay – Die Erzwingung der Verwendung von TLS auf der certsrv-Site und die Aktivierung von Extended Protection for Authentication (EPA) in IIS verhindert das Relay zu ADCS. (Danke an Will Dormann für den Hinweis in seinem Tweet, dies wurde auch in Dirk-jan Mollemas Beitrag über Relaying Kerberos over DNS using krbrelayx and mitm6 erwähnt)
• Ressourcen für mögliche Überwachungs- und Erkennungsregeln:
  1. https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
  2. https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Hauptsächlich die Regel über die Authentifizierung am Dienst-Manager über Kerberos von 127.0.0.1, großartige Arbeit!.

Danksagungen

• James Forshaw für seine Forschung zum Kerberos-Relaying und dafür, dass er herausgefunden hat, wie man Kerberos-Diensttickets für die LOKALE Authentifizierung am Dienst-Manager verwendet. Dies war das fehlende Puzzlestück, um dieses Angriffsprimitiv nur lokal zu ermöglichen (davor mussten wir das ST auf eine entfernte Maschine exportieren, um es zu verwenden und privilegierten Zugriff auf unsere Zielmaschine zu erlangen). Außerdem für seine New-MachineAccount-Funktionalität, die in diesem Projekt verwendet wurde.
• Cube0x0 Dieses Projekt würde ohne seine erstaunliche Arbeit an KrbRelay nicht existieren – ein großer Teil des Codes stammt von dort und hat mir ein tieferes Verständnis dafür vermittelt, wie Kerberos-Relaying funktioniert (ich empfehle wirklich jedem, der das Konzept besser verstehen möchte, den Code durchzugehen).
• Elad Shamir für seine Forschung zu Shadow Credentials und sein großartiges Tool Whisker – Teile seines Codes (und natürlich cube0x0s KrbRelay-Code) wurden verwendet, um die Unterstützung für den Shadow-Credentials-Angriff in diesem Tool hinzuzufügen.
• Will Schroeder und alle, die zu Rubeus beigetragen haben, das wir alle kennen und lieben. Im Grunde wurde die gesamte RBCD-S4U-Funktionalität von dort übernommen. Außerdem für Certify und das Certified Pre-Owned-Whitepaper (Anerkennung gebührt auch Lee Christensen), die beim Hinzufügen der Option für das ADCS Web Enrollment Relay verwendet wurden.