dec0ne/shadowsprayEin Tool zum Verteilen von Shadow Credentials über eine gesamte Domäne in der Hoffnung, längst vergessene GenericWrite/GenericAll-DACLs über andere Objekte in der Domäne auszunutzen.
Ein Tool, um Shadow Credentials über eine gesamte Domain zu streuen, in der Hoffnung, längst vergessene GenericWrite/GenericAll-DACLs über andere Objekte in der Domain auszunutzen.
In vielen Engagements sehe ich (in BloodHound), dass die Gruppe „Everyone“ / „Authenticated Users“ / „Domain Users“ oder eine andere breite Gruppe, die fast alle Benutzer der Domain enthält, einige GenericWrite/GenericAll-DACLs über andere Objekte in der Domain besitzt.
Diese Rechte können missbraucht werden, um Shadow Credentials zum Zielobjekt hinzuzufügen und dessen TGT und NT-Hash zu erhalten.
Mir kam der Gedanke, dass wir einfach versuchen können, Shadow Credentials über die gesamte Domain zu streuen und zu sehen, was hängen bleibt (offensichtlich ist dieser Ansatz besser für nicht verdeckte Engagements geeignet – nicht in einem Red Team verwenden, wenn Heimlichkeit erforderlich ist). Wenn ein Shadow Credential erfolgreich hinzugefügt wird, führen wir einfach den gesamten PKINIT + UnPACTheHash-Tanz auf und voilà – wir erhalten NT-Hashes.
Da der Prozess extrem schnell ist, kann er gleich zu Beginn des Engagements eingesetzt werden, und hoffentlich hast du einige Benutzer und Computer eingenommen, bevor du überhaupt richtig anfängst.
Hinweis: Ich habe viel Code aus meinem vorherigen Tool wiederverwendet, daher könnten AV/EDRs dies als KrbRelayUp markieren...
Es läuft ungefähr so ab:
ShadowSpray unterstützt STRG+C. Wenn du die Ausführung also zu irgendeinem Zeitpunkt abbrechen möchtest, drücke einfach STRG+C, und ShadowSpray zeigt die bisher wiederhergestellten NT-Hashes an, bevor es beendet wird (wie in der Demo unten gezeigt).
__ __ __ __ __ __
/__` |__| /\ | \ / \ | | /__` |__) |__) /\ \ /
.__/ | | /~~\ |__/ \__/ |/\| .__/ | | \ /~~\ |
Usage: ShadowSpray.exe [-d FQDN] [-dc FQDN] [-u USERNAME] [-p PASSWORD] [-r] [-re] [-cp CERT_PASSWORD] [-ssl]
-r (--RestoreShadowCred) Restore "msDS-KeyCredentialLink" attribute after the attack is done. (Optional)
-re (--Recursive) Perform ShadowSpray attack recursivly. (Optional)
-cp (--CertificatePassword) Certificate password. (default = random password)
General Options:
-u (--Username) Username for initial LDAP authentication. (Optional)
-p (--Password) Password for initial LDAP authentication. (Optional)
-d (--Domain) FQDN of domain. (Optional)
-dc (--DomainController) FQDN of domain controller. (Optional)
-ssl Use LDAP over SSL. (Optional)
-y (--AutoY) Don't ask for confirmation to start the ShadowSpray attack. (Optional)
Entnommen aus Elad Shamirs Blogbeitrag über Shadow Credentials:
Wenn PKINIT-Authentifizierung in der Umgebung nicht üblich ist oder für das Zielkonto nicht üblich ist, kann das Ereignis „Kerberos-Authentifizierungsticket (TGT) wurde angefordert“ (4768) auf anomales Verhalten hinweisen, wenn die Attribute für Zertifikatinformationen nicht leer sind.
Wenn ein SACL für die Überwachung von Änderungen an Active Directory-Objekten für das Zielkonto konfiguriert ist, kann das Ereignis „Directory service object was modified“ (5136) auf anomales Verhalten hinweisen, wenn der Betreff, der msDS-KeyCredentialLink ändert, nicht das Azure AD Connect-Synchronisierungskonto oder das ADFS-Dienstkonto ist, die normalerweise als Key Provisioning Server agieren und dieses Attribut legitimerweise für Benutzer ändern.
Eine genauere präventive Kontrolle besteht darin, einen Access Control Entry (ACE) hinzuzufügen, der dem Prinzipal EVERYONE das Ändern des Attributs msDS-KeyCredentialLink für jedes Konto, das nicht für die passwortlose Key Trust-Authentifizierung vorgesehen ist, und insbesondere für privilegierte Konten, VERWEIGERT.
Detecting UnPACing and shadowed credentials von Henri Hambartsumyan von FalconForce
ShadowSpray-spezifische Erkennungen: