KrbRelayUp

Wrapper simples em torno de alguns dos recursos do Rubeus e do KrbRelay (e algumas outras menções honrosas na seção de agradecimentos) para simplificar o abuso da seguinte primitiva de ataque:

0. (Opcional) Criação de nova conta de máquina (New-MachineAccount)
1. Coerção de autenticação da conta da máquina local (KrbRelay)
2. Relay Kerberos para LDAP (KrbRelay)
3. Adicionar privilégios RBCD e obter ST privilegiado para a máquina local (Rubeus)
4. Usar o referido ST para autenticar no Service Manager local e criar um novo serviço como NT/SYSTEM. (SCMUACBypass)

Isso é essencialmente uma escalada de privilégio local universal sem correção em ambientes de domínio Windows onde a assinatura LDAP não é aplicada (as configurações padrão).

ATUALIZAÇÃO: Aqui está um excelente writeup de @an0n_r0 sobre como executar este ataque manualmente (usando as ferramentas originais para este caminho de ataque: PowerMad/SharpMad, KrbRelay, Rubeus e SCMUACBypass)

Atualização - Suporte a Shadow Credentials

Adicionei alguns recursos para suportar esta primitiva de ataque usando shadow credentials. Observe que isso elimina a necessidade de adicionar (ou possuir) outra conta de máquina.

Nota: este método de ataque contorna a mitigação de Usuários Protegidos (ou 'Account is sensitive and cannot be delegated') devido ao abuso de S4U2Self.

1. Coerção de autenticação da conta da máquina local (KrbRelay)
2. Relay Kerberos para LDAP (KrbRelay)
3. Gerar uma nova KeyCredential e adicioná-la ao atributo 'msDS-KeyCredentialLink' da conta da máquina local. (Whisker e KrbRelay)
4. Usar a referida KeyCredential para obter um TGT para a conta da máquina local via PKInit. (Rubeus)
5. Usar o TGT para obter ST privilegiado para a máquina local via S4U2Self e TGSSUB. (Rubeus)
6. Usar o referido ST para autenticar no Service Manager local e criar um novo serviço como NT/SYSTEM. (SCMUACBypass)

ATUALIZAÇÃO: Aqui está um excelente writeup de @icyguider sobre como executar o método ShadowCred deste ataque manualmente (usando as ferramentas originais para este caminho de ataque: KrbRelay, Rubeus e SCMUACBypass) juntamente com o uso do NimCrypt2 para empacotar as várias ferramentas e evadir parte da detecção por mecanismos defensivos.

Atualização - Suporte a ADCS Web Enrollment

Adicionei suporte para fazer relay da autenticação KRB da máquina para o ADCS Web Enrollment (em vez de LDAP). Isso elimina o requisito de a assinatura LDAP não ser aplicada no domínio, já que este ataque não faz relay para o LDAP.

Nota: este método de ataque contorna a mitigação de Usuários Protegidos (ou 'Account is sensitive and cannot be delegated') devido ao abuso de S4U2Self.

1. Coerção de autenticação da conta da máquina local (KrbRelay)
2. Relay Kerberos para ADCS (HTTP) (KrbRelay e ADCSPwn)
3. Gerar solicitação de certificado em nome da conta da máquina local, enviá-la ao ADCS Web Enrollment e, por fim, recuperar o certificado para a conta da máquina local (ADCSPwn)
4. Usar o referido certificado para obter um TGT para a conta da máquina local via PKInit. (Rubeus)
5. Usar o TGT para obter ST privilegiado para a máquina local via S4U2Self e TGSSUB. (Rubeus)
6. Usar o referido ST para autenticar no Service Manager local e criar um novo serviço 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)

Exemplos

TODO

• Refatoração e limpeza de código!!!
• Adicionar ataque ShadowCred como método RELAY
• Adicionar ataque TGTDELEG no método SPAWN para ser usado em cenários Network Service->SYSTEM (alternativa aos potatoes)
• Corrigir o problema que estou tendo ao tentar combinar os métodos RELAY e SPAWN em uma única execução para que possa ser usado como um comando completo. Provavelmente tem a ver com o fato de que tanto a funcionalidade RELAY quanto a SPAWN dependem de hooks durante a inicialização do COM Server (uma vez que o RELAY inicializa seu COM Server, o SPAWN não consegue reinicializá-lo para colocar seus hooks também)

Mitigação e Detecção

• Aplique a assinatura LDAP e o LDAP Channel Binding para mitigar o relay da autenticação KRB da conta da máquina para o LDAP. Isso pode ser configurado via GPO "Domain Controller: LDAP server signing requirements". (Obrigado Will Dormann pelo seu tweet sobre este assunto)
• Torne os requisitos do ataque mais difíceis de obter definindo o atributo MS-DS-Machine-Account-Quota no AD como 0, removendo assim a capacidade de qualquer usuário adicionar uma nova conta de máquina ao domínio. Esta é uma configuração padrão perigosa no AD - certifique-se de alterá-la.
• Definir o sinalizador "Account is sensitive and cannot be delegated" em todas as contas de administrador (ou colocá-las em usuários protegidos) faria com que não houvesse nenhuma conta com os privilégios necessários que pudesse ser delegada para concluir o caminho do ataque. (Obrigado a Christoph Falta por este tweet)
• Mitigação para ADCS Relay - Aplicar o uso de TLS no site certsrv e habilitar Extended Protection for Authentication (EPA) no IIS impedirá o relay para o ADCS. (Obrigado a Will Dormann por apontar isso em seu tweet, isso também foi mencionado no post de Dirk-jan Mollema sobre Relaying Kerberos over DNS using krbrelayx and mitm6)
• Recursos para possíveis regras de monitoramento e detecção:
  1. https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
  2. https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Principalmente a regra sobre autenticação no Service Manager via Kerberos a partir de 127.0.0.1, Excelente trabalho!

Agradecimentos

• James Forshaw por sua pesquisa sobre Kerberos relaying e por descobrir como usar Kerberos Service Tickets para autenticação LOCAL no Service Manager, que foi a peça que faltava no quebra-cabeça para tornar essa primitiva de ataque somente local (antes disso, tínhamos que exportar o ST para uma máquina remota para usá-lo e obter acesso privilegiado à nossa máquina alvo). Também por sua funcionalidade New-MachineAccount, que foi usada neste projeto.
• Cube0x0 Este projeto não existiria sem seu incrível trabalho no KrbRelay - muito código foi retirado de lá e isso me fez obter um entendimento mais profundo de como o Kerberos Relaying funciona (eu realmente recomendo percorrer o código para qualquer um que deseje entender melhor o conceito).
• Elad Shamir por sua pesquisa sobre Shadow Credentials e sua incrível ferramenta Whisker - partes do código dele (e, claro, do código do KrbRelay de cube0x0) foram usadas para adicionar suporte ao ataque de Shadow Credentials nesta ferramenta.
• Will Schroeder e todos que contribuíram para o Rubeus, que todos conhecemos e amamos. Basicamente, toda a funcionalidade RBCD-S4U foi retirada de lá. Também, pelo Certify e pelo whitepaper Certified Pre-Owned (os créditos também vão para Lee Christensen), que foram usados ao adicionar a opção de Relay para ADCS Web Enrollment.
• batsec e todos que contribuíram para o . Muito código relacionado à opção de Relay para ADCS Web Enrollment foi retirado dessa ferramenta incrível.