AD CS Domain Persistence
Questo è un riassunto delle tecniche di persistenza del dominio condivise in https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf. Consultalo per ulteriori dettagli.
Falsificazione di certificati con certificati CA rubati - DPERSIST1
Come puoi capire se un certificato è un certificato CA?
È possibile determinare se un certificato è un certificato CA se si verificano diverse condizioni:
Il certificato è memorizzato sul server CA, con la sua chiave privata protetta dal DPAPI della macchina, o da hardware come un TPM/HSM se il sistema operativo lo supporta.
I campi Issuer e Subject del certificato corrispondono al nome distintivo del CA.
È presente un'estensione "CA Version" esclusivamente nei certificati CA.
Il certificato non ha campi di utilizzo esteso della chiave (EKU).
Per estrarre la chiave privata di questo certificato, lo strumento certsrv.msc sul server CA è il metodo supportato tramite l'interfaccia grafica integrata. Tuttavia, questo certificato non differisce dagli altri memorizzati nel sistema; pertanto, possono essere applicati metodi come la tecnica THEFT2 per l'estrazione.
Il certificato e la chiave privata possono anche essere ottenuti utilizzando Certipy con il seguente comando:
Una volta acquisito il certificato CA e la sua chiave privata nel formato .pfx, è possibile utilizzare strumenti come ForgeCert per generare certificati validi:
L'utente preso di mira per la falsificazione del certificato deve essere attivo e in grado di autenticarsi in Active Directory affinché il processo abbia successo. La falsificazione di un certificato per account speciali come krbtgt è inefficace.
Questo certificato falsificato sarà valido fino alla data di scadenza specificata e finché il certificato CA radice è valido (di solito da 5 a 10+ anni). È anche valido per le macchine, quindi combinato con S4U2Self, un attaccante può mantenere la persistenza su qualsiasi macchina di dominio finché il certificato CA è valido. Inoltre, i certificati generati con questo metodo non possono essere revocati poiché la CA non ne è a conoscenza.
Affidarsi a Certificati CA Rogue - DPERSIST2
L'oggetto NTAuthCertificates è definito per contenere uno o più certificati CA nel suo attributo cacertificate, che Active Directory (AD) utilizza. Il processo di verifica da parte del domain controller prevede il controllo dell'oggetto NTAuthCertificates per una voce corrispondente alla CA specificata nel campo Issuer del certificato di autenticazione. L'autenticazione procede se viene trovata una corrispondenza.
Un certificato CA autogenerato può essere aggiunto all'oggetto NTAuthCertificates da un attaccante, a condizione che abbia il controllo su questo oggetto AD. Normalmente, solo i membri del gruppo Enterprise Admin, insieme a Domain Admins o Amministratori nel dominio radice della foresta, hanno il permesso di modificare questo oggetto. Possono modificare l'oggetto NTAuthCertificates utilizzando certutil.exe con il comando certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA126, o utilizzando lo Strumento di salute PKI.
Questa capacità è particolarmente rilevante quando viene utilizzata in combinazione con un metodo precedentemente descritto che coinvolge ForgeCert per generare dinamicamente i certificati.
Configurazione Maliziosa - DPERSIST3
Le opportunità di persistenza attraverso modifiche dei descrittori di sicurezza dei componenti AD CS sono abbondanti. Le modifiche descritte nella sezione "Escalation di Dominio" possono essere implementate in modo malizioso da un attaccante con accesso elevato. Ciò include l'aggiunta di "diritti di controllo" (ad esempio, WriteOwner/WriteDACL, ecc.) a componenti sensibili come:
L'oggetto computer AD del server CA
Il server RPC/DCOM del server CA
Qualsiasi oggetto o contenitore AD discendente in
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>(ad esempio, il contenitore dei modelli di certificato, il contenitore delle autorità di certificazione, l'oggetto NTAuthCertificates, ecc.)Gruppi AD delegati con diritti di controllo su AD CS di default o dall'organizzazione (come il gruppo Cert Publishers incorporato e i suoi membri)
Un esempio di implementazione maliziosa potrebbe coinvolgere un attaccante, che ha permessi elevati nel dominio, aggiungendo il permesso WriteOwner al modello di certificato User predefinito, con l'attaccante come principale per il diritto. Per sfruttare ciò, l'attaccante dovrebbe prima cambiare la proprietà del modello User a se stesso. Successivamente, il valore mspki-certificate-name-flag verrebbe impostato su 1 nel modello per abilitare ENROLLEE_SUPPLIES_SUBJECT, consentendo a un utente di fornire un Nome alternativo del soggetto nella richiesta. Successivamente, l'attaccante potrebbe registrarsi utilizzando il modello, scegliendo un nome di amministratore di dominio come nome alternativo e utilizzare il certificato acquisito per l'autenticazione come DA.
Last updated