KrbRelayUp

Un wrapper sencillo alrededor de algunas de las funcionalidades de Rubeus y KrbRelay (y algunas otras menciones honoríficas en la sección de agradecimientos) con el fin de agilizar el abuso de la siguiente primitiva de ataque:

0. (Opcional) Creación de una nueva cuenta de máquina (New-MachineAccount)
1. Coerción de autenticación de la cuenta de máquina local (KrbRelay)
2. Relay Kerberos a LDAP (KrbRelay)
3. Agregar privilegios RBCD y obtener un ST privilegiado para la máquina local (Rubeus)
4. Usar dicho ST para autenticarse en el Service Manager local y crear un nuevo servicio como NT/SYSTEM. (SCMUACBypass)

Esto es esencialmente una escalada de privilegios local universal sin parche en entornos de dominio Windows donde la firma LDAP no está aplicada (la configuración predeterminada).

ACTUALIZACIÓN: Aquí hay un excelente artículo de @an0n_r0 sobre cómo realizar este ataque manualmente (usando las herramientas originales para esta ruta de ataque: PowerMad/SharpMad, KrbRelay, Rubeus y SCMUACBypass)

Actualización - Soporte de Shadow Credentials

He añadido algunas funcionalidades para soportar esta primitiva de ataque usando shadow credentials. Ten en cuenta que esto elimina la necesidad de añadir (o poseer) otra cuenta de máquina.

Nota: este método de ataque omite la mitigación de Usuarios protegidos (o 'La cuenta es sensible y no se puede delegar') debido al abuso de S4U2Self.

1. Coerción de autenticación de la cuenta de máquina local (KrbRelay)
2. Relay Kerberos a LDAP (KrbRelay)
3. Generar una nueva KeyCredential y añadirla al atributo 'msDS-KeyCredentialLink' de la cuenta de máquina local. (Whisker y KrbRelay)
4. Usar dicha KeyCredential para obtener un TGT para la cuenta de máquina local mediante PKInit. (Rubeus)
5. Usar el TGT para obtener un ST privilegiado para la máquina local mediante S4U2Self y TGSSUB. (Rubeus)
6. Usar dicho ST para autenticarse en el Service Manager local y crear un nuevo servicio como NT/SYSTEM. (SCMUACBypass)

ACTUALIZACIÓN: Aquí hay un excelente artículo de @icyguider sobre cómo realizar el método ShadowCred de este ataque manualmente (usando las herramientas originales para esta ruta de ataque: KrbRelay, Rubeus y SCMUACBypass), junto con el uso de NimCrypt2 para empaquetar las distintas herramientas y evadir parte de la detección por parte de los mecanismos defensivos.

Actualización - Soporte de Inscripción Web de ADCS

He añadido soporte para hacer relay de la autenticación KRB de la máquina a la Inscripción Web de ADCS (en lugar de LDAP). Esto elimina el requisito de que la firma LDAP no esté aplicada en el dominio, ya que este ataque no hace relay a LDAP.

Nota: este método de ataque omite la mitigación de Usuarios protegidos (o 'La cuenta es sensible y no se puede delegar') debido al abuso de S4U2Self.

1. Coerción de autenticación de la cuenta de máquina local (KrbRelay)
2. Relay Kerberos a ADCS (HTTP) (KrbRelay y ADCSPwn)
3. Generar una solicitud de certificado en nombre de la cuenta de máquina local, enviarla a la Inscripción Web de ADCS y, finalmente, recuperar el certificado para la cuenta de máquina local (ADCSPwn)
4. Usar dicho certificado para obtener un TGT para la cuenta de máquina local mediante PKInit. (Rubeus)
5. Usar el TGT para obtener un ST privilegiado para la máquina local mediante S4U2Self y TGSSUB. (Rubeus)
6. Usar dicho ST para autenticarse en el Service Manager local y crear un nuevo servicio como NT/SYSTEM. (SCMUACBypass)

Uso

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)

Ejemplos

TODO

• Refactorización y limpieza del código!!!
• Añadir el ataque ShadowCred como método RELAY
• Añadir el ataque TGTDELEG en el método SPAWN para usarse en escenarios de Network Service->SYSTEM (alternativa a los potatoes)
• Arreglar el problema que estoy teniendo al intentar combinar los métodos RELAY y SPAWN en una sola ejecución para que pueda usarse como un comando completo. Probablemente tenga algo que ver con el hecho de que tanto RELAY como SPAWN dependen de hooks durante la inicialización del Servidor COM (una vez que RELAY inicializa su Servidor COM, SPAWN no puede reinicializarlo para colocar también sus hooks)

Mitigación y Detección

• Exigir la firma LDAP y el enlace de canal LDAP (LDAP Channel Binding) para mitigar el relay de la autenticación KRB de la cuenta de máquina a LDAP. Esto se puede configurar mediante la GPO "Controlador de dominio: requisitos de firma del servidor LDAP". (Gracias a Will Dormann por su tweet sobre este asunto)
• Hacer más difíciles de obtener los requisitos del ataque estableciendo el atributo MS-DS-Machine-Account-Quota en AD a 0, eliminando así la capacidad de cualquier usuario de añadir una nueva cuenta de máquina al dominio. Esta es una configuración predeterminada peligrosa en AD - asegúrate de cambiarla.
• Establecer el indicador "La cuenta es sensible y no se puede delegar" en todas las cuentas de administrador (o ponerlas en usuarios protegidos) haría que no exista ninguna cuenta con los privilegios requeridos que pueda delegarse para completar la ruta de ataque. (Gracias a Christoph Falta por este tweet)
• Mitigación para el relay ADCS: exigir el uso de TLS en el sitio certsrv y habilitar Extended Protection for Authentication (EPA) en IIS evitará el relay a ADCS. (Gracias a Will Dormann por señalarlo en su tweet; esto también se mencionó en la publicación de Dirk-jan Mollema sobre Relaying Kerberos over DNS using krbrelayx and mitm6)
• Recursos para posibles reglas de monitorización y detección:
  1. https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
  2. https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Principalmente la regla sobre la autenticación al Service Manager mediante Kerberos desde 127.0.0.1, ¡gran trabajo!

Agradecimientos

• James Forshaw por su investigación sobre Kerberos relaying y por descubrir cómo usar los Kerberos Service Tickets para la autenticación LOCAL al Service Manager, que fue la pieza que faltaba del rompecabezas para hacer que esta primitiva de ataque fuera solo local (antes de eso, teníamos que exportar el ST a una máquina remota para usarlo y obtener acceso privilegiado a nuestra máquina objetivo). También por su funcionalidad New-MachineAccount, que se utilizó en este proyecto.
• Cube0x0 Este proyecto no existiría sin su increíble trabajo en KrbRelay - se tomó mucho código de allí y me permitió obtener una comprensión más profunda de cómo funciona el Kerberos Relaying (realmente recomiendo revisar el código a cualquiera que desee entender mejor el concepto).
• Elad Shamir por su investigación sobre Shadow Credentials y su increíble herramienta Whisker - se utilizaron partes de su código (y por supuesto el código de KrbRelay de cube0x0) para añadir soporte para el ataque de Shadow Credentials en esta herramienta.
• Will Schroeder y todos los que contribuyeron a Rubeus, que todos conocemos y amamos. Básicamente, toda la funcionalidad RBCD-S4U se tomó de allí. También, por Certify y el whitepaper Certified Pre-Owned (los créditos son también para Lee Christensen), que se utilizaron al añadir la opción de Relay de Inscripción Web de ADCS.
• batsec y todos los que contribuyeron a . Se tomó mucho código relacionado con la opción de Relay de Inscripción Web de ADCS de esta increíble herramienta.