<summary><strong>Aprenda hacking 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ê deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
* **Direitos de inscrição são concedidos a usuários de baixo privilégio pela CA da Empresa.**
* **Aprovação do gerente não é necessária.**
* **Não são necessárias assinaturas de pessoal autorizado.**
* **Descritores de segurança nos modelos de certificado são excessivamente permissivos, permitindo que usuários de baixo privilégio obtenham direitos de inscrição.**
* **Os modelos de certificado são configurados para definir EKUs que facilitam a autenticação:**
* Identificadores de Uso Estendido de Chave (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 Finalidade (OID 2.5.29.37.0), ou nenhum EKU (SubCA) estão incluídos.
* **A capacidade para solicitantes incluírem 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, especificando 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 é um bitmask, e a presença da flag `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permite a especificação do SAN pelo solicitante.
A configuração descrita permite que usuários de baixo privilégio solicitem certificados com qualquer SAN de escolha, possibilitando a autenticação como qualquer principal de domínio através do Kerberos ou SChannel.
Essa funcionalidade às vezes é habilitada para suportar a geração sob demanda de certificados HTTPS ou de host por produtos ou serviços de implantação, ou devido a uma falta de compreensão.
Observa-se que a criação de um certificado com essa opção gera um aviso, o que não ocorre quando um modelo de certificado existente (como o modelo `WebServer`, que tem `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitado) é duplicado e então modificado para incluir um OID de autenticação.
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, possuindo uma 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:
1. Os direitos de inscrição são concedidos a usuários de baixo privilégio pela CA da Empresa.
2. O requisito de aprovação do gerente é desativado.
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 de baixo privilégio.
5.**O modelo de certificado é definido para incluir o EKU de Qualquer Finalidade ou nenhum EKU.**
O **EKU de Qualquer Finalidade** permite que um certificado seja obtido por um atacante para **qualquer finalidade**, 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 esse cenário.
Certificados sem **EKUs**, que atuam como certificados de CA subordinados, podem ser explorados para **qualquer finalidade** e também podem **ser usados para assinar novos certificados**. Portanto, um atacante poderia especificar EKUs ou campos arbitrários nos novos certificados utilizando um certificado de CA subordinado.
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.
Este cenário é semelhante ao primeiro e ao segundo, mas **abusando** de um **EKU diferente** (Agente de Solicitação de Certificado) e **2 modelos diferentes** (portanto, possui 2 conjuntos de requisitos).
O **EKU do 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 a um principal **inscrever-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, se inscrevendo em um **modelo** que **permite "inscrever-se em nome de"**, e a CA responde com um **certificado pertencente ao "outro" usuário**.
- Direitos de inscrição são concedidos a usuários de baixo privilégio pela CA da Empresa.
- O requisito de aprovação do gerente é omitido.
- Sem requisito de assinaturas autorizadas.
- O descritor de segurança do modelo de certificado é excessivamente permissivo, concedendo direitos de inscrição a usuários de baixo privilégio.
- O modelo de certificado inclui o EKU do Agente de Solicitação de Certificado, permitindo a solicitação de outros modelos de certificado em nome de outros principais.
- A CA da Empresa concede direitos de inscrição a usuários de baixo privilégio.
- A aprovação do gerente é contornada.
- A versão do esquema do modelo é 1 ou excede 2 e especifica um Requisito de Emissão de Política de Aplicativo que exige o EKU do Agente de Solicitação de Certificado.
- Um EKU definido no modelo de certificado permite autenticação de domínio.
- Restrições para agentes de inscrição não são aplicadas na CA.
Os **usuários** que têm permissão para **obter** um **certificado de agente de inscrição**, os modelos nos quais os **agentes** de inscrição têm permissão para se inscrever e as **contas** em nome das quais o agente de inscrição pode agir podem ser restritos pelas CAs corporativas. Isso é feito abrindo o `certsrc.msc`**snap-in**, **clicando com o botão direito no CA**, **clicando em Propriedades** e, em seguida, **navegando** até a guia "Agentes de Inscrição".
No entanto, observa-se que a configuração **padrão** para as CAs é "**Não restringir agentes de inscrição**". Quando a restrição de agentes de inscrição é habilitada pelos administradores, definindo-a como "Restringir agentes de inscrição", a configuração padrão permanece extremamente permissiva. Isso permite que **Todos** tenham acesso para se inscrever em todos os modelos como qualquer pessoa.
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.
Caso um **atacante** possua as **permissões** necessárias para **alterar** um **modelo** e **instituir** quaisquer **configurações incorretas exploráveis** descritas em **seções anteriores**, a escalada de privilégios pode ser facilitada.
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 tornar o modelo 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, conhecido como [Credenciais Sombrias](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 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.
A extensa teia de relacionamentos baseados em ACL, que inclui vários objetos além de modelos de certificados e a autoridade de certificação, pode impactar a segurança de todo o sistema AD CS. Esses objetos, que podem afetar significativamente a segurança, englobam:
- O objeto de computador AD do servidor CA, que pode ser comprometido por 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=Serviços de Chave Pública,CN=Serviços,CN=Configuração,DC=<DOMÍNIO>,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 de Certificação, 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 baixos privilégios conseguir obter controle sobre qualquer um desses componentes críticos.
O assunto discutido no [**post da CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) também aborda as implicações da flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, conforme delineado pela Microsoft. Essa configuração, quando ativada em uma Autoridade de Certificação (CA), permite a inclusão de **valores definidos pelo usuário** no **nome alternativo do assunto** para **qualquer solicitação**, incluindo aquelas construídas a partir do Active Directory®. Consequentemente, essa disposição permite que um **intruso** se inscreva por meio de **qualquer modelo** configurado para **autenticação de domínio**—especificamente aqueles abertos para inscrição de usuários **não privilegiados**, como o modelo de Usuário padrão. 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), por meio do argumento `-attrib "SAN:"` no `certreq.exe` (referido como “Pares de Nome Valor”), apresenta um **contraste** com a estratégia de exploração de SANs em ESC1. Aqui, a distinção está em **como as informações da conta são encapsuladas**—dentro de um atributo de certificado, em vez de uma extensão.
Ferramentas como [**Certify**](https://github.com/GhostPack/Certify) e [**Certipy**](https://github.com/ly4k/Certipy) são capazes de detectar essa configuração incorreta e explorá-la:
Para alterar essas configurações, assumindo que se possua direitos administrativos de domínio ou equivalentes, o seguinte comando pode ser executado a partir de qualquer estação de trabalho:
Após as atualizações de segurança de maio de 2022, os **certificados** recém-emitidos conterão uma **extensão de segurança** que incorpora a **propriedade `objectSid` do solicitante**. Para o ESC1, esse SID é derivado do SAN especificado. No entanto, para o **ESC6**, o SID reflete o **`objectSid` do solicitante**, não o SAN.\
Para explorar o ESC6, é essencial que o sistema seja suscetível ao ESC10 (Mapeamentos de Certificado Fracos), que prioriza o **SAN sobre a nova extensão de segurança**.
O controle de acesso para uma autoridade de certificação é mantido por meio 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 guia Segurança. Além disso, as permissões podem ser enumeradas usando o módulo PSPKI com comandos como:
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.
Ter direitos de **`ManageCA`** em uma autoridade de certificação permite ao principal manipular configurações remotamente usando o PSPKI. Isso inclui alternar a flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`** para permitir a especificação de SAN em qualquer modelo, um aspecto crítico da escalada de privilégios de domínio.
A simplificação desse processo é alcançável por meio 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 certificado 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 CA (`CertSvc`) seja reiniciado. Quando um usuário tem o direito de acesso `Manage CA`, o usuário também tem permissão para **reiniciar o serviço**. No entanto, **isso não significa que o usuário pode 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 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**.
[-] 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 nosso **`Gerenciar CA` e `Gerenciar Certificados`**, podemos então **emitir a solicitação de certificado falhada** com o comando `ca` e o parâmetro `-issue-request <ID da solicitação>`.
Em ambientes onde o **AD CS está instalado**, se existir um **ponto de extremidade de inscrição na web vulnerável** e pelo menos um **modelo de certificado publicado** que permita a **inscrição de computadores de domínio e autenticação de clientes** (como o modelo padrão **`Machine`**), torna-se possível para **qualquer computador com o serviço spooler ativo ser comprometido por um atacante**!
Vários **métodos de inscrição baseados em HTTP** são suportados pelo AD CS, disponibilizados por meio de funções de servidor adicionais que os administradores podem instalar. Essas interfaces para inscrição de certificados baseada em HTTP são suscetíveis a **ataques de relay NTLM**. Um atacante, a partir de uma **máquina comprometida, pode se passar por qualquer conta AD que se autentique via NTLM de entrada**. Ao se passar pela conta da vítima, essas interfaces da 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 na web** (uma aplicação ASP mais antiga disponível em `http://<caserver>/certsrv/`), por padrão, utiliza apenas HTTP, o que não oferece proteção contra ataques de relay NTLM. Além disso, ela permite explicitamente apenas autenticação NTLM por meio de seu cabeçalho HTTP de Autorização, tornando métodos de autenticação mais seguros como o Kerberos inaplicáveis.
* O **Serviço de Inscrição de Certificados** (CES), **Serviço Web de Política de Inscrição de Certificados** (CEP) e **Serviço de Inscrição de Dispositivos de Rede** (NDES) suportam por padrão a autenticação de negociação por meio de seu cabeçalho HTTP de Autorização. A autenticação de negociação **suporta tanto** Kerberos quanto **NTLM**, permitindo que um atacante **rebaixe para a autenticação NTLM** durante ataques de relay. Embora esses serviços da web habilitem o HTTPS por padrão, o HTTPS sozinho **não protege contra ataques de relay NTLM**. A proteção contra ataques de relay NTLM para serviços HTTPS só é possível quando o HTTPS é combinado com o vínculo de canal. Infelizmente, o AD CS não ativa a Proteção Estendida para Autenticação no IIS, que é necessária para o vínculo de canal.
Um **problema** comum dos ataques de relay NTLM é a **curta duração 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 relay NTLM para adquirir um certificado para o usuário, pois o período de validade do certificado dita a duração da sessão, e o certificado pode ser utilizado com serviços que **exigem assinatura NTLM**. Para instruções sobre como utilizar um certificado roubado, consulte:
Outra limitação dos ataques de relay NTLM é que **uma máquina controlada pelo atacante deve ser autenticada por uma conta da vítima**. O atacante pode esperar ou tentar **forçar** essa autenticação:
A propriedade `msPKI-Enrollment-Servers` é usada por Autoridades de Certificação (CAs) empresariais para armazenar os 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**:
A solicitação de um certificado é feita pelo Certipy por padrão com base no modelo `Machine` ou `User`, determinado pelo fato de o nome da conta estar terminado 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](https://github.com/ly4k/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.
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 torna-se relevante quando `StrongCertificateBindingEnforcement` está definido 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 em ESC10), dado que a ausência de ESC9 não alteraria os requisitos.
Suponha que `John@corp.local` detém 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` tem permissão para se inscrever, está configurado com a flag `CT_FLAG_NO_SECURITY_EXTENSION` em sua configuração `msPKI-Enrollment-Flag`.
Tentar 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 do certificado:
- O valor padrão para `CertificateMappingMethods` em `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` é `0x18` (`0x8 | 0x10`), anteriormente definido como `0x1F`.
- A configuração padrão para `StrongCertificateBindingEnforcement` em `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` é `1`, anteriormente `0`.
Com `StrongCertificateBindingEnforcement` configurado como `0`, uma conta A com permissões de `GenericWrite` pode ser explorada para comprometer qualquer conta B.
Por exemplo, tendo permissões de `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`.
```bash
certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane
```
Posteriormente, o `userPrincipalName` de `Jane` é alterado para `Administrator`, omitindo deliberadamente a parte `@corp.local` para evitar uma violação de restrição.
Autenticar com o certificado obtido resultará no hash NT de `Administrator@corp.local`, sendo necessária a especificação do domínio no comando devido à ausência de detalhes do domínio no certificado.
Com o `CertificateMappingMethods` contendo o bit flag `UPN` (`0x4`), uma conta A com permissões de `GenericWrite` pode comprometer qualquer conta B que não tenha a propriedade `userPrincipalName`, incluindo contas de máquinas e o administrador de domínio integrado `Administrator`.
Aqui, o objetivo é comprometer `DC$@corp.local`, começando pela obtenção do hash de `Jane` através das Credenciais de Sombra, aproveitando o `GenericWrite`.
```bash
certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane
```
`userPrincipalName` de `Jane` é então definido como `DC$@corp.local`.
Através do shell LDAP, comandos como `set_rbcd` habilitam ataques de Delegação Constrained Baseada em Recursos (RBCD), comprometendo potencialmente o controlador de domínio.
Esta vulnerabilidade também se estende a qualquer conta de usuário que não tenha um `userPrincipalName` ou onde não corresponda ao `sAMAccountName`, sendo o `Administrator@corp.local` padrão um alvo principal devido aos seus privilégios elevados do LDAP e à ausência de um `userPrincipalName` por padrão.
A configuração para **inscrição entre florestas** é relativamente simples. O **certificado da CA raiz** da floresta de recursos é **publicado nas florestas de contas** 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 contas**. Para esclarecer, esse arranjo concede à **CA na floresta de recursos controle completo** sobre todas as outras florestas para as quais gerencia a PKI. Se essa CA for **comprometida por atacantes**, certificados para todos os usuários nas florestas de recursos e de contas podem ser **forjados por eles**, quebrando assim a fronteira de segurança da floresta.
Em ambientes de múltiplas florestas, é necessário cautela em relação às CAs Empresariais que **publicam modelos de certificados** que permitem **Usuários Autenticados ou princípios estrangeiros** (usuários/grupos externos à floresta à qual a CA Empresarial pertence) **direitos de inscrição e edição**.\
Após autenticação em uma confiança, o **SID de Usuários Autenticados** é adicionado ao token do usuário pelo AD. Portanto, se um domínio possuir uma CA Empresarial com um modelo que **permite direitos de inscrição a 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 princípio estrangeiro por um modelo**, uma **relação de controle de acesso entre florestas é criada**, permitindo que um princípio de uma floresta **se inscreva 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 podem ser exploradas por um atacante para obter privilégios adicionais em um domínio estrangeiro.
