Kerberos Double Hop Problem
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Il problema "Double Hop" di Kerberos si presenta quando un attaccante tenta di utilizzare l'autenticazione Kerberos attraverso due hops, ad esempio utilizzando PowerShell/WinRM.
Quando si verifica un'autenticazione tramite Kerberos, le credenziali non vengono memorizzate in memoria. Pertanto, se esegui mimikatz non troverai le credenziali dell'utente nella macchina anche se sta eseguendo processi.
Questo perché, quando ci si connette con Kerberos, questi sono i passaggi:
User1 fornisce le credenziali e il domain controller restituisce un TGT Kerberos a User1.
User1 utilizza il TGT per richiedere un service ticket per connettersi a Server1.
User1 si connette a Server1 e fornisce il service ticket.
Server1 non ha le credenziali di User1 memorizzate o il TGT di User1. Pertanto, quando User1 da Server1 cerca di accedere a un secondo server, non è in grado di autenticarsi.
Se la delegazione non vincolata è abilitata nel PC, questo non accadrà poiché il Server otterrà un TGT di ogni utente che vi accede. Inoltre, se viene utilizzata la delegazione non vincolata, probabilmente puoi compromettere il Domain Controller da esso. Maggiori informazioni nella pagina sulla delegazione non vincolata.
Un altro modo per evitare questo problema, che è notevolmente insicuro, è il Credential Security Support Provider. Da Microsoft:
L'autenticazione CredSSP delega le credenziali dell'utente dal computer locale a un computer remoto. Questa pratica aumenta il rischio di sicurezza dell'operazione remota. Se il computer remoto viene compromesso, quando le credenziali vengono passate a esso, le credenziali possono essere utilizzate per controllare la sessione di rete.
Si raccomanda vivamente di disabilitare CredSSP sui sistemi di produzione, reti sensibili e ambienti simili a causa di preoccupazioni di sicurezza. Per determinare se CredSSP è abilitato, è possibile eseguire il comando Get-WSManCredSSP. Questo comando consente di verificare lo stato di CredSSP e può anche essere eseguito in remoto, a condizione che WinRM sia abilitato.
Per affrontare il problema del doppio salto, viene presentato un metodo che coinvolge un Invoke-Command annidato. Questo non risolve direttamente il problema, ma offre una soluzione alternativa senza necessitare di configurazioni speciali. L'approccio consente di eseguire un comando (hostname) su un server secondario tramite un comando PowerShell eseguito da una macchina di attacco iniziale o attraverso una PS-Session precedentemente stabilita con il primo server. Ecco come si fa:
Alternativamente, stabilire una PS-Session con il primo server ed eseguire il Invoke-Command utilizzando $cred è suggerito per centralizzare i compiti.
Una soluzione per bypassare il problema del doppio salto implica l'uso di Register-PSSessionConfiguration con Enter-PSSession. Questo metodo richiede un approccio diverso rispetto a evil-winrm e consente una sessione che non soffre della limitazione del doppio salto.
Per gli amministratori locali su un obiettivo intermedio, il port forwarding consente di inviare richieste a un server finale. Utilizzando netsh, è possibile aggiungere una regola per il port forwarding, insieme a una regola del firewall di Windows per consentire la porta inoltrata.
winrs.exe può essere utilizzato per inoltrare richieste WinRM, potenzialmente come un'opzione meno rilevabile se il monitoraggio di PowerShell è una preoccupazione. Il comando qui sotto ne dimostra l'uso:
L'installazione di OpenSSH sul primo server consente una soluzione per il problema del double-hop, particolarmente utile per scenari di jump box. Questo metodo richiede l'installazione e la configurazione tramite CLI di OpenSSH per Windows. Quando configurato per l'autenticazione con password, questo consente al server intermedio di ottenere un TGT per conto dell'utente.
Scarica e sposta l'ultima versione zip di OpenSSH sul server di destinazione.
Decomprimi ed esegui lo script Install-sshd.ps1.
Aggiungi una regola del firewall per aprire la porta 22 e verifica che i servizi SSH siano in esecuzione.
Per risolvere gli errori Connection reset, potrebbe essere necessario aggiornare i permessi per consentire a tutti l'accesso in lettura ed esecuzione sulla directory di OpenSSH.
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
