<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
* Um **modelo de certificado** com descritor de segurança excessivamente permissivo **concede direitos de inscrição de certificado a usuários com poucos privilégios**
* _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 Smart Card (OID 1.3.6.1.4.1.311.20.2.2), Qualquer Finalidade (OID 2.5.29.37.0), ou sem EKU (SubCA)._
* O **AD** irá **usar** a identidade especificada pelo campo **subjectAltName** (SAN) de um certificado **se** estiver **presente**. Consequentemente, se um solicitante pode especificar o SAN em um CSR, o solicitante pode **solicitar um certificado como qualquer pessoa** (por exemplo, um usuário administrador de domínio). O objeto AD do modelo de certificado **especifica** se o solicitante **pode especificar o SAN** em sua propriedade **`mspki-certificate-name-`**`flag`. A propriedade `mspki-certificate-name-flag` é uma **máscara de bits** e se a flag **`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`** estiver **presente**, um **solicitante pode especificar o SAN.**
Essas configurações permitem que um **usuário com poucos privilégios solicite um certificado com um SAN arbitrário**, permitindo que o usuário com poucos privilégios se autentique como qualquer principal no domínio via Kerberos ou SChannel.
Isso é frequentemente habilitado, por exemplo, para permitir que produtos ou serviços de implantação gerem certificados HTTPS ou certificados de host instantaneamente. Ou por falta de conhecimento.
Observe que quando um certificado com esta última opção é criado, um **aviso aparece**, mas não aparece se um **modelo de certificado** com esta configuração for **duplicado** (como o modelo `WebServer` que tem `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitado e depois o administrador pode adicionar um OID de autenticação).
Os binários do Windows "Certreq.exe" e "Certutil.exe" podem ser explorados para gerar o PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Além disso, a seguinte consulta LDAP, quando executada contra o esquema de configuração da Floresta AD, pode ser usada para **enumerar****modelos de certificados** que **não exigem aprovação/assinaturas**, que possuem um **EKU de Autenticação de Cliente ou Logon de Cartão Inteligente**, e têm a flag **`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`** ativada:
4. Um descritor de segurança de modelo de certificado excessivamente permissivo concede direitos de inscrição de certificado a usuários com baixos privilégios.
5.**O modelo de certificado define o EKU de Qualquer Propósito ou nenhum EKU.**
O **EKU de Qualquer Propósito** permite que um atacante obtenha um **certificado** para **qualquer finalidade**, como autenticação de cliente, autenticação de servidor, assinatura de código, etc. A mesma **técnica usada para o ESC3** pode ser usada para abusar disso.
Um **certificado sem EKUs** — um certificado de CA subordinada — pode ser abusado para **qualquer finalidade** também, mas poderia **também usá-lo para assinar novos certificados**. Assim, usando um certificado de CA subordinada, um atacante poderia **especificar EKUs arbitrários ou campos nos novos certificados.**
No entanto, se a **CA subordinada não for confiável** pelo objeto **`NTAuthCertificates`** (o que não será por padrão), o atacante **não pode criar novos certificados** que funcionarão para **autenticação de domínio**. Ainda assim, o atacante pode criar **novos certificados com qualquer EKU** e valores de certificado arbitrários, dos quais há **muitos** que o atacante poderia potencialmente **abusar** (por exemplo, assinatura de código, autenticação de servidor, etc.) e que podem ter grandes implicações para outras aplicações na rede como SAML, AD FS ou IPSec.
A seguinte consulta LDAP, quando executada contra o esquema de configuração da Floresta AD, pode ser usada para enumerar modelos que correspondem a este cenário:
Este cenário é semelhante ao primeiro e segundo, mas **abusando** de um **EKU diferente** (Agente de Solicitação de Certificado) e **2 modelos diferentes** (portanto, tem 2 conjuntos de requisitos),
O **EKU de Agente de Solicitação de Certificado** (OID 1.3.6.1.4.1.311.20.2.1), conhecido 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 AC, inscrevendo-se em um **modelo** que **permite "inscrever em nome de"**, e a AC responde com um **certificado pertencente ao "outro" usuário**.
4. Um descritor de segurança de modelo de certificado excessivamente permissivo permite direitos de inscrição de certificado para usuários de baixo privilégio.
5. O **modelo de certificado define o EKU de Agente de Solicitação de Certificado**. O OID de Agente de Solicitação de Certificado (1.3.6.1.4.1.311.20.2.1) permite solicitar outros modelos de certificado em nome de outros principais.
3.**A versão do esquema do modelo é 1 ou é maior que 2 e especifica um Requisito de Emissão de Política de Aplicação exigindo o EKU de Agente de Solicitação de Certificado.**
As Autoridades de Certificação Empresariais podem **restringir** os **usuários** que podem **obter** um **certificado de agente de inscrição**, os modelos de inscrição nos quais os **agentes podem se inscrever** e em quais **contas** o agente de inscrição pode **agir em nome de** ao abrir o `certsrc.msc``snap-in -> clicar com o botão direito na CA -> clicar em Propriedades -> navegar` até a aba "Agentes de Inscrição".
No entanto, a configuração **padrão** da CA é “**Não restringir agentes de inscrição**”. Mesmo quando os administradores ativam “Restringir agentes de inscrição”, a configuração padrão é extremamente permissiva, permitindo que Todos acessem e se inscrevam em todos os modelos como qualquer um.
**Modelos de certificado** possuem um **descritor de segurança** que especifica quais **princípios do AD** têm **permissões específicas sobre o modelo**.
Se um **atacante** tem permissões suficientes para **modificar** um **modelo** e **criar** qualquer uma das **más configurações** exploráveis das **seções anteriores**, ele poderá explorá-las e **escalar privilégios**.
ESC4 ocorre 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 tornar o modelo vulnerável ao ESC1.
Como podemos ver no caminho acima, apenas `JOHNPC` tem esses privilégios, mas nosso usuário `JOHN` tem a nova aresta `AddKeyCredentialLink` para `JOHNPC`. Como esta técnica está relacionada a certificados, eu também implementei este ataque, que é conhecido como [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Aqui está uma pequena prévia do comando `shadow auto` do Certipy para recuperar o hash NT da vítima.
**Certipy** pode sobrescrever a configuração de um modelo de certificado com um único comando. Por **padrão**, Certipy vai **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.
A rede de relações baseadas em ACL interconectadas que podem afetar a segurança do AD CS é extensa. Vários **objetos fora dos modelos de certificado** e da própria autoridade de certificação podem ter um **impacto na segurança de todo o sistema AD CS**. Essas possibilidades incluem (mas não se limitam a):
* Qualquer **objeto AD descendente ou contêiner no contêiner**`CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>` (por exemplo, o contêiner de Modelos de Certificado, o contêiner de Autoridades de Certificação, o objeto NTAuthCertificates, o Contêiner de Serviços de Inscrição, etc.)
Se um atacante com baixos privilégios conseguir **ganhar controle sobre qualquer um destes**, o ataque provavelmente poderá **comprometer o sistema PKI**.
Há outro problema semelhante, descrito no [**post da CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage), que envolve a flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`**. Como a Microsoft descreve, “**Se** esta flag estiver **ativada** na CA, **qualquer solicitação** (incluindo quando o sujeito é construído a partir do Active Directory®) pode ter **valores definidos pelo usuário** no **nome alternativo do sujeito**.”\
Isso significa que um **atacante** pode se inscrever em **QUALQUER modelo** configurado para **autenticação de domínio** que também **permita que usuários não privilegiados** se inscrevam (por exemplo, o modelo de Usuário padrão) e **obter um certificado** que nos permite **autenticar** como um administrador de domínio (ou **qualquer outro usuário/máquina ativo**).
**Nota**: os **nomes alternativos** aqui são **incluídos** em um CSR através do argumento `-attrib "SAN:"` para `certreq.exe` (ou seja, “Pares de Valor de Nome”). Isso é **diferente** do método para **abusar de SANs** no ESC1, pois **armazena informações da conta em um atributo de certificado vs uma extensão de certificado**.
[**Certify**](https://github.com/GhostPack/Certify) e [**Certipy**](https://github.com/ly4k/Certipy) também verificam isso e podem ser usados para abusar dessa má configuração:
Após as atualizações de segurança de maio de 2022, novos **certificados** terão uma **extensão de segurança** que **incorpora** a propriedade **`objectSid` do solicitante**. Para o ESC1, essa propriedade será refletida a partir do SAN especificado, mas com o **ESC6**, essa propriedade reflete o **`objectSid` do solicitante**, e não do SAN.\
Como tal, **para abusar do ESC6**, o ambiente deve estar **vulnerável ao ESC10** (Mapeamentos Fracos de Certificado), onde o **SAN é preferido em detrimento da nova extensão de segurança**.
Uma autoridade de certificação em si tem um **conjunto de permissões** que protegem várias **ações da CA**. Essas permissões podem ser acessadas a partir de `certsrv.msc`, clicando com o botão direito em uma CA, selecionando propriedades e mudando para a aba Segurança:
Isso também pode ser enumerado via [**módulo do PSPKI**](https://www.pkisolutions.com/tools/pspki/) com `Get-CertificationAuthority | Get-CertificationAuthorityAcl`:
Se você tem um principal com direitos **`ManageCA`** em uma **autoridade de certificação**, podemos usar **PSPKI** para alterar remotamente o bit **`EDITF_ATTRIBUTESUBJECTALTNAME2`** para **permitir especificação SAN** em qualquer modelo ([ECS6](domain-escalation.md#editf\_attributesubjectaltname2-esc6)):
Isso também é possível de forma mais simples com o cmdlet [**Enable-PolicyModuleFlag do PSPKI**](https://www.sysadmins.lv/projects/pspki/enable-policymoduleflag.aspx).
Os direitos **`ManageCertificates`** permitem **aprovar uma solicitação pendente**, contornando assim a proteção de "aprovação do gerente de certificados da CA".
No **ataque anterior**, as permissões **`Manage CA`** foram usadas para **ativar** a flag **EDITF\_ATTRIBUTESUBJECTALTNAME2** para realizar o ataque **ESC6**, mas isso não terá efeito até que o serviço de CA (`CertSvc`) seja reiniciado. Quando um usuário tem o direito de acesso `Manage CA`, ele também está autorizado a **reiniciar o serviço**. No entanto, **isso não significa que o usuário possa reiniciar o serviço remotamente**. Além disso, o **ESC6 pode não funcionar imediatamente** na maioria dos ambientes atualizados devido às atualizações de segurança de maio de 2022.
A técnica depende do fato de que usuários com os direitos de acesso `Manage CA`_e_`Manage Certificates` podem **emitir solicitações de certificados falhadas**. O modelo de certificado **`SubCA`** é **vulnerável ao ESC1**, mas **apenas administradores** podem se inscrever no modelo. Assim, um **usuário** pode **solicitar** para se inscrever no **`SubCA`** - o que será **negado** - mas **depois emitido pelo gerente**.
[-] 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.
Com nossas permissões de **`Manage CA` e `Manage Certificates`**, podemos então **emitir o certificado falhado** com o comando `ca` e o parâmetro `-issue-request <request ID>`.
Resumindo, se um ambiente possui **AD CS instalado**, juntamente com um **endpoint de inscrição web vulnerável** e pelo menos um **modelo de certificado publicado** que permite a **inscrição de computadores do domínio e autenticação de cliente** (como o modelo padrão **`Machine`**), então um **atacante pode comprometer QUALQUER computador com o serviço de spooler em execução**!
O AD CS suporta vários **métodos de inscrição baseados em HTTP** por meio de funções adicionais do servidor AD CS que os administradores podem instalar. Essas interfaces de inscrição de certificados baseadas em HTTP são todas **vulneráveis a ataques de relay NTLM**. Usando relay NTLM, um atacante em 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, um atacante poderia acessar essas interfaces web e **solicitar um certificado de autenticação de cliente baseado nos modelos de certificado `User` ou `Machine`**.
* A **interface de inscrição web** (um aplicativo ASP de aparência antiga acessível em `http://<caserver>/certsrv/`), por padrão, suporta apenas HTTP, o que não pode proteger contra ataques de relay NTLM. Além disso, ela explicitamente permite apenas autenticação NTLM por meio de seu cabeçalho HTTP de Autorização, então protocolos mais seguros como Kerberos são inutilizáveis.
* O **Serviço de Inscrição de Certificados** (CES), o Serviço Web de **Política de Inscrição de Certificados** (CEP) e o **Serviço de Inscrição de Dispositivos de Rede** (NDES) suportam autenticação negociada por padrão por meio de seu cabeçalho HTTP de Autorização. A autenticação negociada **suporta** Kerberos e **NTLM**; consequentemente, um atacante pode **negociar para baixo até a autenticação NTLM** durante ataques de relay. Esses serviços web pelo menos habilitam HTTPS por padrão, mas infelizmente HTTPS por si só **não protege contra ataques de relay NTLM**. Apenas quando HTTPS é combinado com vinculação de canal os serviços HTTPS podem ser protegidos de ataques de relay NTLM. Infelizmente, o AD CS não habilita Proteção Estendida para Autenticação no IIS, que é necessária para habilitar a vinculação de canal.
Problemas comuns com ataques de relay NTLM são que as **sessões NTLM são geralmente curtas** e que o atacante **não pode** interagir com serviços que **exigem assinatura NTLM**.
No entanto, abusar de um ataque de relay NTLM para obter um certificado para o usuário resolve essas limitações, pois a sessão viverá enquanto o certificado for válido e o certificado pode ser usado para usar serviços **que exigem assinatura NTLM**. Para saber como usar um certificado roubado, confira:
Outra limitação dos ataques de relay NTLM é que eles **requerem que uma conta vítima se autentique em uma máquina controlada pelo atacante**. Um atacante poderia esperar ou tentar **forçar** isso:
Enterprise CAs também **armazenam pontos de extremidade CES** em seu objeto AD na propriedade `msPKI-Enrollment-Servers`. **Certutil.exe** e **PSPKI** podem analisar e listar esses pontos de extremidade:
Por padrão, o Certipy solicitará um certificado baseado no modelo `Machine` ou `User` dependendo se o nome da conta retransmitida termina com `$`. É possível especificar outro modelo com o parâmetro `-template`.
Podemos então usar uma técnica como [PetitPotam](https://github.com/ly4k/PetitPotam) para forçar a autenticação. Para controladores de domínio, devemos especificar `-template DomainController`.
ESC9 refere-se ao novo valor **`msPKI-Enrollment-Flag`** **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`). Se essa flag estiver configurada em um modelo de certificado, a **nova extensão de segurança `szOID_NTDS_CA_SECURITY_EXT`****não** será incorporada. ESC9 só é útil quando `StrongCertificateBindingEnforcement` está definido como `1` (padrão), já que uma configuração de mapeamento de certificado mais fraca para Kerberos ou Schannel pode ser explorada como ESC10 — sem ESC9 — pois os requisitos serão os mesmos.
Neste caso, `John@corp.local` tem `GenericWrite` sobre `Jane@corp.local`, e desejamos comprometer `Administrator@corp.local`. `Jane@corp.local` tem permissão para se inscrever no modelo de certificado `ESC9` que especifica a flag `CT_FLAG_NO_SECURITY_EXTENSION` no valor `msPKI-Enrollment-Flag`.
Agora, se tentarmos nos autenticar com o certificado, receberemos o hash NT do usuário `Administrator@corp.local`. Você precisará adicionar `-domain <domain>` à sua linha de comando, já que não há domínio especificado no certificado.
Neste caso, `John@corp.local` tem `GenericWrite` sobre `Jane@corp.local`, e desejamos comprometer `Administrator@corp.local`. Os passos de abuso são quase idênticos ao ESC9, exceto que qualquer modelo de certificado pode ser usado.
Agora, solicitamos qualquer certificado que permita autenticação de cliente, por exemplo, o modelo padrão `User`. Devemos solicitar o certificado como `Jane`.
Agora, se tentarmos nos autenticar com o certificado, receberemos o hash NT do usuário `Administrator@corp.local`. Você precisará adicionar `-domain <domain>` à sua linha de comando, já que não há domínio especificado no certificado.
*`CertificateMappingMethods` contém a flag de bit `UPN` (`0x4`)
*`GenericWrite` sobre qualquer conta A para comprometer qualquer conta B sem uma propriedade `userPrincipalName` (contas de máquina e administrador de domínio integrado `Administrator`)
Agora, solicitamos qualquer certificado que permita autenticação de cliente, por exemplo, o modelo padrão `User`. Devemos solicitar o certificado como `Jane`.
Agora, como essa chave de registro se aplica ao Schannel, devemos usar o certificado para autenticação via Schannel. É aqui que entra a nova opção `-ldap-shell` do Certipy.
Se tentarmos nos autenticar com o certificado e `-ldap-shell`, notaremos que estamos autenticados como `u:CORP\DC$`. Esta é uma string enviada pelo servidor.
Um dos comandos disponíveis para o shell LDAP é `set_rbcd`, que definirá a Delegação Restrita Baseada em Recursos (RBCD) no alvo. Assim, poderíamos realizar um ataque RBCD para comprometer o controlador de domínio.
Alternativamente, também podemos comprometer qualquer conta de usuário onde não há `userPrincipalName` definido ou onde o `userPrincipalName` não corresponde ao `sAMAccountName` dessa conta. Pelos meus próprios testes, o administrador de domínio padrão `Administrator@corp.local` não tem um `userPrincipalName` definido por padrão, e essa conta deve ter por padrão mais privilégios no LDAP do que os controladores de domínio.
A configuração para **inscrição entre florestas** é relativamente simples. Os administradores publicam o **certificado da CA raiz** da floresta de recursos **para as florestas de contas** e adicionam os certificados da **CA empresarial** da floresta de recursos aos contêineres **`NTAuthCertificates`** e AIA **em cada floresta de contas**. Para ser claro, isso significa que a **CA** na floresta de recursos tem **controle total** sobre todas as **outras florestas que gerencia PKI para**. Se os atacantes **comprometerem esta CA**, eles podem **forjar certificados para todos os usuários nas florestas de recursos e de contas**, quebrando o limite de segurança da floresta.
Outra coisa que as organizações precisam ter cuidado em ambientes multi-floresta é CAs Empresariais **publicando modelos de certificados** que concedem **Usuários Autenticados ou principais estrangeiros** (usuários/grupos externos à floresta à qual a CA Empresarial pertence) **direitos de inscrição e edição**.\
Quando uma conta **se autentica através de uma confiança**, o AD adiciona o SID de **Usuários Autenticados** ao token do usuário autenticado. Portanto, se um domínio tem uma CA Empresarial com um modelo que **concede direitos de inscrição a Usuários Autenticados**, um usuário em floresta diferente poderia potencialmente **se inscrever no modelo**. Da mesma forma, se um modelo concede explicitamente a um **principal estrangeiro direitos de inscrição**, então uma **relação de controle de acesso entre florestas é criada**, permitindo que um principal em uma floresta **se inscreva em um modelo em outra floresta**.
Em última análise, ambos os cenários **aumentam a superfície de ataque** de uma floresta para outra. Dependendo das configurações do modelo de certificado, um atacante poderia abusar disso para obter privilégios adicionais em um domínio estrangeiro.
* Todas as informações para esta página foram retiradas de [https://www.specterops.io/assets/resources/Certified\_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified\_Pre-Owned.pdf)
<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**merchandising oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas dicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
