KrbRelayUp

Semplice wrapper attorno ad alcune funzionalità di Rubeus e KrbRelay (e ad alcuni altri ringraziamenti nella sezione acknowledgements) per ottimizzare l'abuso della seguente primitiva d'attacco:

0. (Opzionale) Creazione di un nuovo account macchina (New-MachineAccount)
1. Coercizione dell'autenticazione dell'account macchina locale (KrbRelay)
2. Relay Kerberos verso LDAP (KrbRelay)
3. Aggiunta dei privilegi RBCD e ottenimento di uno ST privilegiato per la macchina locale (Rubeus)
4. Utilizzo del suddetto ST per autenticarsi al Service Manager locale e creare un nuovo servizio come NT/SYSTEM. (SCMUACBypass)

Questa è essenzialmente una escalation di privilegi locali universale senza fix negli ambienti di dominio Windows dove la firma LDAP non è applicata (le impostazioni predefinite).

AGGIORNAMENTO: Qui c'è un eccellente writeup di @an0n_r0 su come eseguire manualmente questo attacco (usando gli strumenti originali per questo percorso d'attacco: PowerMad/SharpMad, KrbRelay, Rubeus e SCMUACBypass)

Aggiornamento - Supporto Shadow Credentials

Ho aggiunto alcune funzionalità per supportare questa primitiva d'attacco usando le shadow credentials. Nota: questo elimina la necessità di aggiungere (o possedere) un altro account macchina.

Nota: questo metodo d'attacco bypassa la mitigazione Protected Users (o 'Account is sensitive and cannot be delegated') grazie all'abuso di S4U2Self.

1. Coercizione dell'autenticazione dell'account macchina locale (KrbRelay)
2. Relay Kerberos verso LDAP (KrbRelay)
3. Generazione di una nuova KeyCredential e aggiunta all'attributo 'msDS-KeyCredentialLink' dell'account macchina locale. (Whisker e KrbRelay)
4. Utilizzo della suddetta KeyCredential per ottenere un TGT per l'account macchina locale tramite PKInit. (Rubeus)
5. Utilizzo del TGT per ottenere uno ST privilegiato per la macchina locale tramite S4U2Self e TGSSUB. (Rubeus)
6. Utilizzo del suddetto ST per autenticarsi al Service Manager locale e creare un nuovo servizio come NT/SYSTEM. (SCMUACBypass)

AGGIORNAMENTO: Qui c'è un eccellente writeup di @icyguider su come eseguire manualmente il metodo ShadowCred di questo attacco (usando gli strumenti originali per questo percorso d'attacco: KrbRelay, Rubeus e SCMUACBypass) insieme all'uso di NimCrypt2 per impacchettare i vari strumenti e aggirare alcune rilevazioni da parte dei meccanismi difensivi.

Aggiornamento - Supporto ADCS Web Enrollment

Ho aggiunto il supporto per il relay dell'autenticazione KRB della macchina verso ADCS Web Enrollment (invece di LDAP). Questo elimina il requisito che la firma LDAP non sia applicata nel dominio, poiché questo attacco non fa relay verso LDAP.

Nota: questo metodo d'attacco bypassa la mitigazione Protected Users (o 'Account is sensitive and cannot be delegated') grazie all'abuso di S4U2Self.

1. Coercizione dell'autenticazione dell'account macchina locale (KrbRelay)
2. Relay Kerberos verso ADCS (HTTP) (KrbRelay e ADCSPwn)
3. Generazione di una richiesta di certificato per conto dell'account macchina locale, invio ad ADCS Web Enrollment e infine recupero del certificato per l'account macchina locale (ADCSPwn)
4. Utilizzo del suddetto certificato per ottenere un TGT per l'account macchina locale tramite PKInit. (Rubeus)
5. Utilizzo del TGT per ottenere uno ST privilegiato per la macchina locale tramite S4U2Self e TGSSUB. (Rubeus)
6. Utilizzo del suddetto ST per autenticarsi al Service Manager locale e creare un nuovo servizio come NT/SYSTEM. (SCMUACBypass)

Utilizzo

KrbRelayUp - Relaying you to SYSTEM

FULL: Perform full attack chain. Options are identical to RELAY. Tool must be on disk.

RELAY: First phase of the attack. Will Coerce Kerberos auth from local machine account, relay it to LDAP and create a control primitive over the local machine using RBCD or SHADOWCRED.
Usage: KrbRelayUp.exe relay -d FQDN -cn COMPUTERNAME [-c] [-cp PASSWORD | -ch NTHASH]

    -m   (--Method)                   Abuse method to use in after a successful relay to LDAP <rbcd/shadowcred> (default=rbcd)
    -p   (--Port)                     Port for Com Server (default=12345)
    -cls (--Clsid)                    CLSID to use for coercing Kerberos auth from local machine account (default=90f18417-f0f1-484e-9d3c-59dceee5dbd8)

    # RBCD Method:
    -c   (--CreateNewComputerAccount) Create new computer account for RBCD. Will use the current authenticated user.
    -cn  (--ComputerName)             Name of attacker owned computer account for RBCD. (default=KRBRELAYUP$)
    -cp  (--ComputerPassword)         Password of computer account for RBCD. (default=RANDOM [if -c is enabled])

    # SHADOWCRED Method:
    -f   (--ForceShadowCred)          Clear the msDS-KeyCredentialLink attribute of the attacked computer account before adding our new shadow credentials. (Optional)

    # ADCS Method:
    -ca  (--CAEndpoint)               CA endpoint FQDN (default = same as DC)
    -https                            Connect to CA endpoint over secure HTTPS instead of HTTP)
    -cet (--CertificateTemplate)      Certificate template to request for (default=Machine)


SPAWN: Second phase of the attack. Will use the appropriate control primitive to obtain a Kerberos Service Ticket and will use it to create a new service running as SYSTEM.
Usage: KrbRelayUp.exe spawn -d FQDN -cn COMPUTERNAME [-cp PASSWORD | -ch NTHASH] <-i USERTOIMPERSONATE>

    -m   (--Method)                   Abuse method used in RELAY phase <rbcd/shadowcred> (default=rbcd)
    -i   (--Impersonate)              User to impersonate. should be a local administrator in the target computer. (default=Administrator)
    -s   (--ServiceName)              Name of the service to be created. (default=KrbSCM)
    -sc  (--ServiceCommand)           Service command [binPath]. (default = spawn cmd.exe as SYSTEM)

    # RBCD Method:
    -cn  (--ComputerName)             Name of attacker owned computer account for RBCD. (default=KRBRELAYUP$)
    -cp  (--ComputerPassword)         Password of computer account for RBCD. (either -cp or -ch must be specified)
    -ch  (--ComputerPasswordHash)     Password NT hash of computer account for RBCD. (either -cp or -ch must be specified)

    # SHADOWCRED | ADCS Method:
    -ce  (--Certificate)              Base64 encoded certificate or path to certificate file
    -cep (--CertificatePassword)      Certificate password (if applicable)


KRBSCM: Will use the currently loaded Kerberos Service Ticket to create a new service running as SYSTEM.
Usage: KrbRelayUp.exe krbscm <-s SERVICENAME> <-sc SERVICECOMMANDLINE>

    -s  (--ServiceName)              Name of the service to be created. (default=KrbSCM)
    -sc (--ServiceCommand)           Service command [binPath]. (default = spawn cmd.exe as SYSTEM)


General Options:
    -d  (--Domain)                   FQDN of domain. (Optional)
    -dc (--DomainController)         FQDN of domain controller. (Optional)
    -ssl                             Use LDAP over SSL. (Optional)
    -n                               Use CreateNetOnly (needs to be on disk) instead of PTT when importing ST (enabled if using FULL mode)
    -v  (--Verbose)                  Show verbose output. (Optional)

Esempi

TODO

• Refactoring e pulizia del codice!!!
• Aggiunta dell'attacco ShadowCred come metodo RELAY
• Aggiunta dell'attacco TGTDELEG nel metodo SPAWN per essere usato in scenari Network Service->SYSTEM (alternativa alle potatoes)
• Risolto il problema che avevo nel combinare i metodi RELAY e SPAWN in un'unica esecuzione così da poter essere usato come un unico comando completo. Probabilmente ha a che fare con il fatto che sia RELAY che SPAWN fanno affidamento su hook durante l'inizializzazione del COM Server (una volta che RELAY inizializza il suo COM Server, SPAWN non può re-inizializzarlo per inserire anche i propri hook)

Mitigazione e Rilevamento

• Applicare LDAP Signing e LDAP Channel Binding per mitigare il relay dell'autenticazione KRB dell'account macchina verso LDAP. Questa impostazione può essere configurata tramite il GPO "Domain Controller: LDAP server signing requirements". (Grazie a Will Dormann per il suo tweet su questo argomento)
• Rendere più difficili da ottenere i requisiti dell'attacco impostando l'attributo MS-DS-Machine-Account-Quota in AD a 0, rimuovendo così la capacità di qualsiasi utente di aggiungere un nuovo account macchina al dominio. Questa è un'impostazione predefinita pericolosa in AD: assicurati di modificarla.
• Impostare il flag "Account is sensitive and cannot be delegated" su tutti gli account amministrativi (o inserirli negli utenti protetti) farebbe sì che non esista alcun account con i privilegi richiesti che possa essere delegato per completare il percorso d'attacco. (Grazie a Christoph Falta per questo tweet)
• Mitigazione per il relay ADCS: applicare l'uso di TLS sul sito certsrv e abilitare Extended Protection for Authentication (EPA) in IIS impedirà il relay verso ADCS. (Grazie a Will Dormann per averlo sottolineato nel suo tweet, è stato menzionato anche nel post di Dirk-jan Mollema su Relaying Kerberos over DNS using krbrelayx and mitm6)
• Risorse per possibili regole di monitoraggio e rilevamento:
  1. https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
  2. https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Principalmente la regola sull'autenticazione al Service Manager tramite Kerberos da 127.0.0.1, Ottimo lavoro!.

Ringraziamenti

• James Forshaw per la sua ricerca sul Kerberos relaying e per aver capito come usare i Kerberos Service Tickets per l'autenticazione LOCALE al Service Manager, che è stato il pezzo mancante del puzzle per rendere questa primitiva d'attacco solo locale (prima di allora, dovevamo esportare lo ST su una macchina remota per usarlo e ottenere accesso privilegiato alla nostra macchina target). Inoltre, per la sua funzionalità New-MachineAccount, utilizzata in questo progetto.
• Cube0x0 Questo progetto non esisterebbe senza il suo straordinario lavoro su KrbRelay: molto codice è stato preso da lì e mi ha permesso di acquisire una comprensione più profonda di come funziona il Kerberos Relaying (consiglio davvero di leggere il codice a chiunque voglia capire meglio il concetto).
• Elad Shamir per la sua ricerca sulle Shadow Credentials e il suo fantastico strumento Whisker: parti del suo codice (e ovviamente del codice di KrbRelay di cube0x0) sono state usate per aggiungere il supporto all'attacco Shadow Credentials in questo strumento.
• Will Schroeder e tutti coloro che hanno contribuito a Rubeus, che tutti conosciamo e amiamo. Praticamente tutta la funzionalità RBCD-S4U è stata presa da lì. Inoltre, per Certify e il whitepaper Certified Pre-Owned (il merito va anche a Lee Christensen), che sono stati usati quando è stata aggiunta l'opzione di relay ADCS Web Enrollment.
• batsec e tutti coloro che hanno contribuito a . Molto codice relativo all'opzione di relay ADCS Web Enrollment è stato preso da questo fantastico strumento.