🦦
Otter's Notes
  • Introduction
  • Articles
    • Dumping data from the Microsoft Recall folder
    • Gaining persistence on Windows with Time Providers
    • Reverse engineering LSASS to decrypt DPAPI keys
    • Intro to Hypervisor Implants
    • In-depth Windows Telemetry
  • Notes
    • Active Directory
      • Active Directory Structure
      • Active Directory Terminology
      • Active Directory Objects
      • Active Directory Groups
      • Active Directory Functionality
      • Active Directory Protocols
      • Active Directory Rights and Privileges
      • Security in Active Directory
      • Users and Machine Accounts
      • NTLM
      • LDAP
      • Making a Target User List
      • Enumerating & Retrieving Password Policies
      • Enumerating Security Controls
      • Examining Group Policy
      • GPOs
      • LAPS
      • LLMNR & NBT-NS Poisoning
      • LOLBIN Enumeration
    • AAD
      • Useful Links
      • Overview of Azure & M365
      • Enumerate Users and Domains
      • Post-exploitation Reconnaissance
      • OAuth 2.0 Abuse
      • Abusing Device Code Authentication
      • Abusing Cloud Administrator Role
      • Abusing User Administrator Role
      • AAD Federated Backdoor
      • Service Principal Abuse
      • Compromising Azure Blobs and Storage Accounts
      • Malicious Device Join
      • Disabling Auditing (Unified Audit Logs)
      • Spoofing Azure Sign-In Logs
      • Registering Fake Agents for Log Spoofing
      • Pass the PRT
      • Pass the Cookie
      • Abusing Managed Identities
      • Virtual Machine Abuse
      • Attacking Key Vaults
    • Forest Trust Abuse
      • Parent-Child Trust Abuse
      • One-Way Inbound Trust Abuse
      • Foreign Group Membership
      • Foreign ACL Principals
      • SID History
      • SID Filter Bypass
      • Intra-Forest Attacks
        • Configuration Naming Context Replication
        • ADCS NC Replication Attack
        • GPO On-Site Attack
        • GoldenGMSA Attack
        • DNS Trust Attack
      • Cross-Forest Attacks
        • Trust Account Attack
        • Abusing SQL Linked Servers
        • Abusing PAM Trusts
    • Kerberos
      • Overview of Kerberos Authentication
      • Silver Tickets
      • Golden Tickets
      • Diamond Tickets
      • Kerberoasting
      • AS-REPRoasting
      • Resource-Based Constrained Delegation
      • Constrained Delegation
      • Unconstrained Delegation
      • S4U2Self & S4U2Proxy
      • Golden Certificates
    • DACL Abuse
      • DACL Overview
      • DACLs Enumeration
      • AddMembers
      • GPO Attacks
      • Granting Rights and Ownership
      • Logon Scripts
      • NoPAC
      • Password Abuse
      • SPN Jacking
      • Shadow Credentials
      • Targeted Kerberoasting
    • ADCS
      • Introduction to ADCS
      • ESC1
      • ESC2
      • ESC3
      • ESC4
      • ESC5
      • ESC6
      • ESC7
      • ESC8
      • ESC9
      • ESC10
      • ESC11
      • Certificate Mapping
    • PowerShell
      • PowerShell Basics
      • PowerShell Remoting
      • Alternate PowerShell Hosts
      • PowerShell Pipeline Runners
      • PowerShell Code Signing
      • Scriptblock Logging
      • PowerShell CLM
      • AMSI
      • PowerShell Reflection
      • WMI - Windows Management Instrumentation
      • Interfacing with AD
      • PowerShell Snippets
        • Bypass application whitelisting and CLM with runscripthelper and WMI
        • Create fake PowerShell logs
        • Enumerate AD ACLs
        • Enumerate WMI events
        • Enumerate Domain Trusts
        • Enumerate change metadata
        • Enumerate non-signed service binaries
        • Enumerate with GPOs
        • Find signed alternate PowerShell hosts
        • Get AMSI module
        • Group processes by user with WMI
        • Hide processes from Get-Process
        • Malware re-purposing with PowerShell reflection
        • Monitor PowerShell hosts with WMI
        • PowerShell reflection offensive use-case
        • Query PowerShell alternative hosts with WMI
        • Retrieve file certificate
        • Search LDAP for misconfigurations
        • Sign custom code with PowerShell
        • WMI service creation
        • Weak folder permission enumeration
    • AWS
      • AWS Organizations
      • AWS Principals
    • Binary Exploitation
      • Environment setup for Browser Exploitation
      • Browser Overview and Components
    • Kernel Development
      • Windows
        • Configuring a VM for driver development
Powered by GitBook
On this page
  1. Notes

ADCS

ADCS allows organizations to establish and manage their own PKI to ensure secure communications, authentication and data protection.

ADCS is made of these main components

  • CA: Certification Authority, an entity that issues and manages certificates. There can be multiple CAs, organized in a hierarchy to add more layers of "movement" between the end user and the main CA

  • Certificate Templates: these templates define settings for a certificate and dictate who can enroll in one, with which permissions and all the other critical information used to successfully push out a valid certificate

  • CES: Certificate Enrollment Server, its main role is allowing end users to renew certificates via HTTPS requests by setting up web endpoints for certificate enrollment

  • Certificate Enrollment Policy Web Server: allows users to view information about the enrollment policy of a specific certificate

  • CA Web Enrollment: empowers hosts that are not domain-joined or running other OSs to renew certificates

  • NDES: Network Device Enrollment Service, allows offline network devices to obtain certificates

Certificate Authorities (CAs)

CAs are pivotal entities in the ADCS infrastructure as they issues and manages certificates.

CAs can be organized in hierarchies, with a root CA managing intermediate CAs; this configuration allows to add more "layers" between the users and the root CA.

The root CA issues itself a self-signed certificate using its private key, this certificate called the "root CA certificate" will then be used to sign the certificates requested by the PKI users. The root CA certificates are stored in four main locations:

  1. Certification Authorities container: This section defines top-tier root CA certificates, forming the foundation of trust within AD CS environments. Represented as AD objects with the certificationAuthority objectClass, each CA's certificate data resides within this container. Windows machines universally incorporate these root CA certificates into their Trusted Root Certification Authorities store, forming the basis for certificate trust verification.

  2. Enrollment Services container: Dedicated to Enterprise CAs enabled within AD CS, this space hosts AD objects for each Enterprise CA. These objects encapsulate key attributes such as pKIEnrollmentService objectClass, cACertificate data, dNSHostName defining the CA's DNS, and certificateTemplates outlining the certificate configurations. Clients within AD interact with these Enterprise CAs to request certificates, adhering to the settings specified in certificate templates. The certificates issued by Enterprise CAs are deployed to the Intermediate Certification Authorities store on Windows machines.

  3. NTAuthCertificates AD object: This element defines CA certificates pivotal for authenticating to AD. Identified by the certificationAuthority objectClass, it contains cACertificate properties defining a series of trusted CA certificates. Windows devices in AD networks integrate these CAs into their Intermediate Certification Authorities store. Authentication to AD using certificates necessitates client certificates being signed by one of the CAs listed within NTAuthCertificates.

  4. AIA (Authority Information Access) container: Hosting AD objects representing intermediate and cross CAs, this repository aids in validating certificate chains. Each CA, denoted by the certificationAuthority objectClass, contains cACertificate data representing its certificate. These intermediate CAs are deployed to the Intermediate Certification Authorities store on Windows machines, crucial for seamless certificate chain validation within the PKI hierarchy.

Certificates and Certificate Templates

ADCS uses X.509 certificates with the following formats

  • PEM: this is the equivalent of a base64-encoded DER certificate, it can store multiple keys with no password protection

  • DER: raw PEM certificate

  • PFX / P12 (PKCS#12): can store a number of private keys with password protection

  • P7B (PKCS#7): used to store multiple chain certificates but not private keys

CAs use certificate templates to look up certificate settings when issuing new certificates for users.

Each certificate (and certificate template) has some main attributes"

  • Subject: the entity to which the certificate is issued

  • Issuer: usually the CA

  • SAN: Subject Alternative Name

  • Validity Period

  • EKU: Extended Key Use, defines where the certificate can be used

  • OID: Object Identifier, indicates the purpose / usage scenarios of a certificate

  • Public Key

  • NotBefore and NotAfter value to define the certificate's lifespan

  • Serial number

  • SubjectAlternativeName to specify alternative names associated with the Subject

  • Basic constraints to determine whether the certificate is for a CA or a end user and its usage constraints

The following are some common OID used to abuse ADCS misconfigurations

OID
Certificate use

1.3.6.1.5.5.7.3.1

Server Authentication

1.3.6.1.5.5.7.3.2

Client Authentication

1.3.6.1.5.5.7.3.3

Code Signing

1.3.6.1.5.5.7.3.4

Secure Email

1.3.6.1.5.2.3.4

PKINIT Client Authentication

1.3.6.1.4.1.311.20.2.2

Smart Card Logon

2.5.29.37.0

Any Purpose

Enrollment Process and Requirements

Assuming there is at least a CA in the infrastructure, authenticated users can create CSRs (Certificate Signing Request), the CA determines if the client has the right permissions to enroll in the requested certificate, if the permissions match a certificate is generated and signed using the CA's private key before being returned to the user.

Issuance requirements are another important aspect to control enrollment requests. We can access these requirements from the certsrv.msc console (Certificate Templates > Manage > Issuance Requirements).

PreviousTargeted KerberoastingNextIntroduction to ADCS

Last updated 1 year ago