Active Directory Trust 101

In Active Directory, a trust is a relationship established between two or more domains. Trusts can exist in several forms. A Bidirectional trust allows both domains or forests to trust each other. A One-Way Inbound trust allows users from our domain or forest to access resources in another domain. A One-Way Outbound trust allows users from another domain or forest to access resources in our domain, but not the other way around.

For attackers, trust relationships between domains can act as a portal for extending access inside a corporate network. Trusts create implicit pathways that, when abused, allow an adversary to move beyond the initial foothold and reach resources that would otherwise be unreachable.

Environment 1

For my research I created a lab with three forests: kapla.lab, shura.lab, and mdbl.lab. The trust relationships between these forests are shown in the diagram below. Note that this lab will be used to showcase the first 3 POCs and will be tweaked later on

As shown in the image, the kapla.lab forest has a One-Way Outbound trust with the shura.lab forest. This means that shura.lab has a One-Way Inbound trust with kapla.lab and that users in shura.lab can access resources in kapla.lab, but not the other way around. The same configuration applies to mdbl.lab.

The first two domains run Windows Server 2022, while the mdbl.lab domain runs Windows Server 2016.

High-level attack concepts

Trust account attack

Before starting this research, I set out to find new ways to cross forest trusts by abusing common technologies and misconfigurations. I began with Outbound trusts because they are especially interesting and challenging for attackers. In an Outbound trust scenario, we cannot authenticate from our domain to the trusted domain, which can severely limit access. Fortunately for attackers, there is an attack class known as a Trust Account attack or Trust Keys attack.

During Kerberos authentication within a domain, the krbtgt account is responsible for signing ticket granting tickets. In a two forest scenario, a different mechanism is used for cross forest authentication. Instead of using a domain krbtgt key, TGTs that cross forest boundaries are signed with a shared secret derived from the trust configuration, commonly referred to as the inter realm key or trust key. These trust keys rotate by default approximately every 30 days and can be obtained in multiple ways that we will explore later. The account responsible is the Trust account, which uses the NetBIOS name of the forest. For example, if users in forest A.local need to access resources in forest B.local, cross forest TGTs are signed with the Trust account named A$ using the shared secret established between the two domains.

In typical Trust account exploitation scenarios like the one demonstrated here, the trust account credentials are used to request a TGT for the trust account in the target domain. That ticket is then used to enumerate and access resources in the other domain and to perform attacks such as ASREPRoasting and Kerberoasting. The trust account can also enable more targeted attacks and direct exploitation. This is possible because the account has Domain User privileges in the trusted domain, which permits any action available to a normal domain user, including authentication coercion, although there are some caveats.

Trusted CA attack

In this attack the environment differs from the previous one. I changed the trust between kapla.lab and shura.lab to a bidirectional trust and installed Active Directory Certificate Services on kapla.lab. During engagements you might encounter an environment where two forests share the same PKI. ADCS allows administrators and organizations to manage their own public key infrastructure. Certificates from this PKI are commonly used for VPNs, HTTPS, and other secure connections on endpoints that lack built in protections. Unfortunately or fortunately depending on whether you are attacking or defending, trusting a CA from another forest undermines a zero trust model. If an attacker gains administrative access to a CA they can extract the CA private keys and forge certificates for any user in the forest where the CA resides or in forests that trust that CA. With the CA private key an attacker could forge a certificate for any user in the other forest including Domain Administrators.

One-Way Outbound Trust – kapla.lab -> shura.lab

Trust account limitations

In a typical environment, if NTLM is enabled, you can use it to access domain resources. The trust account behaves differently. It can only authenticate using Kerberos. Any attempt to authenticate with NTLM will fail with the error STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT.

CVE-2025-33073 + ESC8

To demonstrate the power of the trust account I reproduced a previously documented attack chain using only that account in an Outbound trust scenario. The two key elements are ESC8, which I covered earlier on this blog, and CVE-2025-33073. ESC8 is an ADCS behavior that allows an attacker to relay authentication from various protocols to the ADCS HTTP endpoint because HTTP does not require a message integrity check. CVE-2025-33073, disclosed on June 10, 2025, enables an attacker to use a forged DNS record to coerce the lsass.exe process on a target machine into authenticating to an attacker controlled endpoint. An example DNS record is SHURADC011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA. This can trigger Kerberos authentication because when the SMB client calls the (LsapCheckMarshalledTargetInfo) function, the resulting stripped target appears as cifs/SHURADC01. For more information on the attack, I invite you in reading this blog from synacktiv.

In this lab the CA lives on shuradc01.shura.lab which is why a normal self-relay is not possible in many scenarios. NTLM relays are blocked from relaying back to the same machine because of the self-relay rule and the NTLM message integrity check. Kerberos does not include that NTLM integrity check so Kerberos self-relay is possible. By combining ESC8 and CVE-2025-33073 we can cause the CA on shuradc01.shura.lab to authenticate to it-self and get a certificate for SHURADC01$.

Performing the Attack

We have compromised the kapla.lab domain and on the domain controller we can run the following PowerShell command to enumerate the existing trusts:

From the output above we can quickly see that the Direction is Outbound. With administrative access to KAPLADC01 we can dump the trust keys using Mimikatz. It is also possible to DCSync these keys by specifying the GUID of the Trusted Domain Object, which I will demonstrate later.

In the output above we see the In and Out values labeled In1 and Out1. These represent the current and previous trust keys respectively. In this case they are identical because the trust was created recently and the 30 day rotation interval has not yet elapsed. After 30 days the older values will move into the In1 and Out1 fields accordingly. The RC4 hash can be used as the trust account credential. The trust account name is the NetBIOS name of our domain with a dollar sign at the end like a computer account, in our scenario is kapla$.

Now we can use these credentials to perform various actions, such as enumerating the other domain or carrying out more direct attacks like coercing machine accounts. Remember to ALWAYS use kerberos authentication

ADCS enumeration:

Knowing that the CA is vulnerable to ESC8, we can attempt the self relay attack by abusing the previously discussed CVE. First we must add the custom DNS record in the shura.lab domain using the trust account privileges. To obtain the necessary credentials we request a TGT for the trust account using Rubeus.

To add the DNS record we use the PowerMad PowerShell tool as follows. Remember to specify the target forest with the Forest parameter and to point the record to our attacker controlled machine with the Data parameter.

Explaining Kerberos "relaying":

In a kerberos “relay” scenario the attacker sits in the middle and tries to take an AP_REQ that a client intended for Service A and forward it to Service B (relay it). If that succeeds, the attacker makes the server at Service B think the client authenticated to it and then the attacker can interact to service B as that client.

But there is a prerequisite for this attack to succeed: the client and the target service must not enforce signing or encryption, because the attacker does not possess the session key required to perform those operations.

Also, an AP_REQ cannot be relayed to a different service identity than the one specified in the ticket. For example, if the AP_REQ is for CIFS/shuradc01.shura.lab, you cannot forward it to CIFS/computer.shura.lab because that is a different service identity. What an attacker can do (if signing is not required) is cause the client to generate an AP_REQ for a different SPN, for example HTTP/shuradc01.shura.lab and then relay that AP_REQ to the service that accepts that SPN.

Now that you understand what is happening, you can run the krbrelayx tool to perform the relay by specifying the victim with the victim flag and the certificate template you want to request. The victim flag is required because during system authentication the username is blank, represented as a single slash. As a result, the tool cannot determine which user initiated the request. I will demonstrate this later using ntlmrelayx.

With the listener up and running we can run the authentication coercion attack with the trust account using NetExec or any other coercion tool that supports Kerberos authentication e.g printerbug.py

After the authentication hits krbrelayx, the tool will do it's magic and request a certificate for the shuradc01$ machine account

Now we can use this certificate with NetExec to authenticate as the Administrator:

What NetExec actually does

1. Uses the certificate to request a TGT for the SHURADC01$ machine account and saves it in the NetExec local directory.

2. Uses the S4U2Self extension to request a service ticket to SHURADC01$ on behalf of another user, for example Administrator.

3. This is necessary because machine accounts do not have administrative privileges on themselves.

4. With the impersonation of an administrator, it is possible to dump the NTDS database and compromise all user credentials.

One-Way Outbound Trust – shura.lab -> mdbl.lab

CVE-2025-33073 + Drop the MIC

At this point I was both satisfied and surprised by what the trust account could achieve, so I wondered whether CVE 2025 33073 could be chained with older vulnerabilities. One such legacy issue is CVE 2019 1040, also known as the remove MIC vulnerability. Older and unpatched Windows Server installations, for example Windows Server 2016 or 2019, may still be vulnerable, and large networks often contain these legacy systems. In NTLM relay scenarios some cross protocol relays are prevented when session signing is enforced, because signing provides integrity protection. The remove MIC exploit allows an attacker to bypass that session signing requirement, which can enable relays on protocols that would otherwise block them.

Performing the Attack

The process of trust enumeration is the same as before. NetExec can also list the trusts in place.

As expected from shura.lab’s perspective, the trust with kapla.lab is inbound, and to our surprise the trust with mdbl.lab is outbound, so you guessed it we will need to perform another trust account attack.

This time, instead of dumping the keys locally on the domain controller, I will show how to retrieve them remotely from an attacker controlled machine. First, edit the hosts file on your Windows machine to map the domain controller FQDN to its IP address or point your DNS resolver to the domain controller for the target forest. Next, perform a pass the hash attack with Mimikatz to open a command prompt as the domain controller machine account. Finally, run a DCSync operation specifying the GUID of the Trusted Domain Object to extract the trust keys remotely.

You can also get the DC's machine account hash with the certificate we used earlier:

To obtain the GUID of the trust account, open a PowerShell prompt on SHURADC01 and run the following command:

Then perform the DCSync. The advantage of this approach is that we do not need to run Mimikatz directly on the domain controller, which may be protected by an AV or EDR solution. Additionally, performing DCSync using the DC machine account can resemble normal replication activity. Some indicators of compromise remain, such as the originating IP address being that of the attacker machine rather than the domain controller.

Then perform PTH on your windows attacker machine:

It's also possible to get the clear text secret by decoding the hex bytes in cyberchef

With the trust keys obtained from Mimikatz, we can now scan the other domain for additional vulnerabilities. Fortunately for us, the domain controller in the other forest appears to be an older Windows Server 2016 machine.

Since this is an older system, it is worth checking for known vulnerabilities. Unfortunately, for some reason the trust account cannot detect the remove MIC vulnerability. Instead, I created a machine account in the domain that can perform the check.

Add computer account using the trust account:

and looks like the DC is vulnerable to the remove-mic attack: CVE-2019-1040

A machine that remains vulnerable to CVE 2019 1040 is likely also vulnerable to the CVE we discussed earlier, CVE 2025 33073. This creates a major opportunity for attackers because the two vulnerabilities can be chained into a self relay to LDAP that would not succeed on patched systems. We can relay any protocol to HTTP ADCS because HTTP does not enforce signing, but relaying to LDAP is normally blocked unless we exploit the remove MIC vulnerability, which is supported by ntlmrelayx.

The first step of this attack, as before, is to add the custom DNS record in the mdbl.lab domain using the trust account.

Like before get a TGT for the trust account:

and then add the DNS record using powermad:

With the computer account, we perform NTLM authentication coercion, but during the relay phase, something strange appears:

From the output above it's clear that the authentication was successful (Authenticating connection from /@10.0.128.13 against ldap://10.0.128.13 SUCCEED [1]) but the tool was unable to grant us the permission we requested with the --delegate flag. Ntlmrelayx was not able to do it's magic because the user (in this case system) returns blank / as you can see here “Authenticating connection from /@10.0.128.13” this is normal when recieving system authentication. Yet we can do something cooler instead, a more manual approach by binding to LDAP and do the RBCD attack manually.

ntlmrelayx supports binding to a protocol and opening a channel that we can connect to using netcat:

Now we can connect with netcat to 127.0.0.1 on port 11000. Running whoami will show that we are, in fact, SYSTEM.

Now it is game over for the domain. With this shell we can reset the Domain Administrator password, grant our computer account EVIL_COMPUTER$ resource based constrained delegation privileges on the domain controller, or add the trust account to the Domain Admins group.

NoPAC

Unless the machine account quota is set to 0 the trust account can effectively abuse the NoPAC exploit as it only requires a machine account creation

Bidirectional Trust – kapla.lab <-> shura.lab

Trusted CA attack

In this attack the environment differs from the previous one. I changed the trust between kapla.lab and shura.lab to a bidirectional trust and installed Active Directory Certificate Services on kapla.lab. The CA lives in kapla.lab and shura.lab trusts that CA. During engagements you may encounter environments where two forests share the same PKI. ADCS allows administrators and organizations to manage their own public key infrastructure. Certificates from that PKI are commonly used for VPNs, HTTPS, and other secure connections on endpoints that lack built in protections. Trusting a CA from another forest undermines a zero trust model. If an attacker gains administrative access to a CA they can extract the CA private keys and forge certificates for any user in the forest where the CA resides or in forests that trust that CA. With the CA private key an attacker could forge a certificate for any user in the other forest including Domain Administrators.

Enumerating Trust and CA's

Like before we need to enumerate the trust between the two domains and observe that there is a bidirectional trust in place

Enumerate ADCS from shura.lab and confirm that the issuing CA is hosted in kapla.lab. Since bidirectional trust is in place, we can use any user from the kapla.lab domain to extract this information

Certificate authentication preview

As shown in the previous attack, we used the SHURADC01 certificate to get a TGT or the NTLM hash of the computer account. There are two main means of authenticating via certificates.

PKINIT allows Kerberos to use public key cryptography during the initial authentication phase instead of relying solely on shared symmetric keys. In this method, a client presents an X.509 certificate to the Key Distribution Center (KDC), which verifies it and issues a Kerberos ticket based on the public key proof. This approach is especially useful in environments where certificates are already managed by ADCS.

Schannel, on the other hand, is Windows implementation of TLS that handles certificate-based authentication. During the TLS handshake, a server can request a client certificate and use it to authenticate the user or machine by mapping the certificate to a Windows account using Kerberos S4U2Self or standard certificate mapping rules such as SAN, subject, and issuer fields. Services like IIS, WinRM, RDP, and LDAPS typically support Schannel authentication when ADCS is configured. In this lab, we leveraged the SHURADC01 certificate to authenticate as the machine account, which can be used through PKINIT for Kerberos-based authentication or through Schannel for TLS-based authentication, both allowing a certificate issued by a trusted CA to be converted into an authenticated Windows identity.

PKINIT may not be available in every environment. In my lab, shura.lab does not support PKINIT, so when we request a certificate for a user we cannot use it with NetExec the way we did before.

To test this, request a certificate for a user in the kapla.lab domain and attempt to authenticate with it via Kerberos; a successful test returns authentication successful, while a failure returns KDC_ERR_PADATA_TYPE_NOSUPP.

Request the certificate:

then save this to a cert.pem file and convert it: Leave the password field empty

We now authenticate using netexec and get back: KDC_ERR_PADATA_TYPE_NOSUPP

This is not an issue since we can use other tools such as PassTheCert, which supports Schannel connections, particularly for LDAP binding.

Performing the attack

Now we have all the information needed to perform the attack. With access to the CA we can forge certificates for any user we choose because we can extract the CA private key and use it to sign forged certificates. SharpDPAPI can be used to extract those keys.

We are interested in the private keys

Now save this keys to cert.pem and convert it to a pfx using openssl, then use ForgeCert tool to forge a certificate. 123 is the password I typed for the pfx file. Also, the subject should point to the Administrator user in the shura.lab domain.

Now move administrator.pfx file to linux, as we need to extract the private and public key from the certificate, these are used by PassTheCert in the authentication process. Certipy can be used for this purpose:

With the two keys extracted, we can authenticate to LDAP using PassTheCert and reset the Administrator password, consequently leading to a full forest compromise

Closing thoughts and Remediations

With this research I aimed to show that trust relationships between domains mean a forest is no longer a security boundary. The attacks I demonstrated are not the only cross forest techniques; there are many more. I also wanted to highlight how powerful the Trust Account can be. Too often it is treated as useful only for basic attacks such as Kerberoasting and ASREPRoasting, when in fact it can perform any action available to a normal domain user.

It is important to avoid sharing critical infrastructure across forests because those shared services can enable lateral and vertical movement, as shown here with ADCS. Each environment should have its own critical infrastructure, including but not limited to SCCM and WSUS. There is no silver bullet to prevent cross forest trust attacks. Implementing zero trust and enforcing least privilege are recommended measures to reduce the risk of cross environment movement.