Post Exploitation - Trusts hopping
Overview
Trust relationships define an administrative and security link between two Windows forests or domains. They enable a user to access resources that are located in a forest or domain that's different from the user's own forest or domain.
Trusts directions
The direction of an Active Directory trust relationship defines the direction of the accesses and can be:
one-way
, given by one forest or domain, thetrusting object
, to another domain or forest, thetrusted object
.bidirectional
ortwo-ways
, meaning are reciprocated by both objects forming the trust. Abidirectional
trust is actually implemented as twoone-way
trusts.
The trusting object
will define outbound
trusts with the objects that it directly trust and principals from the trusted objects will be allowed access to the trusting object
resources. Reciprocally, the trusted object
will define an inbound
trust with object that directly trust it.
Transitivity
A transitive trust
is a trust that is extended not only to the directly trusted object, but also to each objects that the trusted object trusts. A transitive trust will thus give access to the resources of the trusting domain to all domains or forests that are trusted by the trusted object defined in the trust.
A trust that is non transitive will limit access to the resources of the trusting object only to the trusted domain or forest and will not extend to any other object.
Default and possible trusts
All domains in a forest trust each others by default. External trusts can also be configured between domains of different forests.
The following different types of trusts are or can be configured in Active Directory (either by default or manually):
Authentication mechanisms for Active Directory trusts
Both the Kerberos
and the NTLM
protocols are used for authentication across Active Directory trusts. An authentication is first attempted using the Kerberos
protocol and, in case of failure, a rollback authentication is made through the NTLM
protocol.
If the authentication is made through the Kerberos
protocol, a new Kerberos
ticket is issued to the user: the referral ticket
. This ticket corresponds to a reissue of the user's current Ticket-Granting Ticket (TGT)
encrypted with one of the secrets (RC4
, corresponding to the NTLM hash
, or AES 128/256 bits
keys) of the trust account
.
The referral tickets, as with any other Kerberos
tickets, contain the user authentication information (SID
, eventual extra SIDs
and the user's groups) in its Privilege Attribute Certificate (PAC)
. The referral tickets
are subsequently used to request service tickets (ST)
and access resources in the trusting domain or forest.
Authentication and access control across trusts
The access to securable resources, that is resources that define a security descriptor
, is based on a security principal
's SID
, eventual extra SIDs
, and security group SIDs
. Indeed, these SIDs
are compared to the access rights defined in the Access Control Entries (ACEs)
of the accessed object's Discretionary Access Control List (DACL)
.
Users, computer machine accounts, and Global
and Universal
security groups of the trusted domain or forest can be added to Domain local
security groups of the trusting domain or forest. As the Domain Admins
and Enterprise Admins
groups are, respectively, Global
and Universal
security groups, only the built-ins Administrators
and Operators
groups (and others non-default Domain Local
security groups) can be used to grant privileges to security principals of a trusted domain / forest in the trusting domain / forest. For instance, the trusted domain / forest's Domain Admins
group can be added to the Administrators
group of the trusting forest but the trusted forest's Administrators
group cannot.
The SIDs
that are not from the trusted domain or forest are subject to the SID filtering
security mechanism.
Security mechanism: SID filtering
A filtering policy governs the Security Identifiers (SIDs)
that can be used for authentication and access control through Active Directory trusts. The filtering depends on the type of the trust, the SID
, as well as the activation or not of the security filtering mechanism known as SID filtering
. This filtering applies on the current SID
of the account as well as any SIDs
present in the user SIDHistory
attribute.
SIDs
are categorized into the following classes, with specific rules being applied to each class:
SID categorization
SID filtering policy for intra-forest trusts
SID filtering
is by default disabled for all intra-forest
trusts. Any eventual extra SIDs
or security group SIDs
, except the SIDs
categorized as Alwaysfiltered
, will thus be taken into account for the authorization and access control process whenever accessing resources through an intra-forest
trust. In an Active Directory forest with trusts in their default configuration, the initial compromise of a domain of the forest can lead to the full compromise of the forest.
A form of SID filtering
can be configured on intra-forest
trusts by marking the trusts as QuarantinedWithinForest
. In such configuration, the trustAttributes
attribute of the TDO
object defining the trust has its TRUST_ATTRIBUTE_QUARANTINED_DOMAIN
bit set. The only SIDs
that will be allowed across the trust are the SIDs
from the trusted domain, the SID
Enterprise Domain Controllers
(S-1-5-9
), categorized as EDC
, and "the SID described by the Trusted Domain Object (TDO)
".
Note that activation of the QuarantinedWithinForest
mechanism for intra-forest
trusts may give rise to operational issues and is not recommended. This is why the forest is commonly considered as a security boundary while the domain only as an operational boundary.
SID filtering policy for inter-forests trusts
The SIDs
categorized as Alwaysfiltered
and ForestSpecific
are filtered across all inter-forests
trusts (CrossForest
and External
) boundaries.
For External
trusts, non-default domain users and groups SIDs
, in the format S-1-5-21-<Domain>-R
with R >= 1000
, are not filtered.
SID filtering
is however by default enabled for all CrossForest
trusts and all SIDs
that do not directly refer to the trusted domain or forest are filtered across the trust boundaries. This filtering can be relaxed by disabling the SID filtering
mechanism. In such configuration, the trustAttributes
attribute of the TDO
object defining the trust has its TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL
bit set and the trust is considered, for SID
filtering, as an External
trust (thus allowing non-default SIDs
across the trust).
Security mechanism: TGT delegation
Security mechanisms restricting the delegation of Ticket-Granting Ticket (TGT)
through Kerberos unconstrained delegation
across trust boundaries were introduced in March - July 2019 security updates. The features were implemented on Windows Server 2012
, and later, as well as backported to Windows Server 2008
.
The restriction are implemented through two trust flags stored in the trustAttributes
attribute of TDO
objects:
CROSS_ORGANIZATION_NO_TGT_DELEGATION
CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
As of July 2019
, TGT
delegation is by default disabled and must be explicitly enabled which result in the setting of the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
flag. The CROSS_ORGANIZATION_NO_TGT_DELEGATION
must also be unset in order for the TGT
delegation to be effective.
In essence:
If the
CROSS_ORGANIZATION_NO_TGT_DELEGATION
is set,TGT
delegation is disabled if all Domain Controllers are runningWindows Server 2012
(or newer) orWindows Server 2008 / 2008 R2
with March 2019 security updates.If the
CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
flag is set (while theCROSS_ORGANIZATION_NO_TGT_DELEGATION
flag is not)TGT
delegation is possible across the trust (independently of the level of patching of the Domain Controllers).if neither flags are set,
TGT
delegation is allowed if Domain Controllers do not have the May 2019 security updates.
Security mechanism: selective authentication
By default, any users of the trusted domain or forest can authenticate to the Domain Controllers
of the trusting domain or forest. This results in the possibility of conducting authenticated enumeration of the objects of the trusting domain / forest by all the users of the trusted domain / forest.
The selective authentication
security restricts the authentication to specifically defined security principals.
Forest and domain trusts enumeration
Various tools or utilities can be used to retrieve the trusts defined for a domain or at the forest level:
In additions, more comprehension and automated Active Directory scanners implemented in .NET
, such as BloodHound
or PingCastle
, include modules to enumerate trusts information. Refer to the [ActiveDirectory] AD scanner
note for more information on how to conduct enumeration using automated scanners.
Intra-forest trusts hopping
Intra-forest
trusts that are not marked as QuarantinedWithinForest
can be jumped after the initial compromise of a domain by simply adding the Enterprise Admins
security group SID
in the SIDHistory
of an user of the compromised domain or directly in the extra SIDs
field of a crafted Kerberos ticket
. Alternatively, an Enterprise domain controller
can be impersonated in order to conduct DCSync
attacks on the root domain with out generating Windows Security
events and possibly raising security alerts.
Jumps using the SID History attribute
Under normal circumstances, SIDs
will only be added (automatically) to the SIDHistory
attribute of a security principal during domain migration and cannot be manually added (but can be manually removed).
This restriction can be bypassed and SIDs
added to a security principal
's SIDHistory
attribute with mimikatz
by either:
executing code locally on a Domain Controller to patch its
NTDS
serviceregistering a rogue Domain Controller to inject and replicate arbitrary modifications (attack known as
DCShadow
)
The following command can be used to validate the SIDHistory
attribute modification:
SID History modification through local patch of the NTDS service
This technique of modification of the SIDHistory
attribute requires privileges granted to the Domain Admins
group and must be conducted on a Domain Controller as the Windows NT Directory Services (NTDS)
service must be locally patched. While the SID History
modification will persist, the NTDS
service patch will not be persistent across reboot of the Domain Controller.
mimikatz
's sid
module can be used to add SIDs
in the SIDHistory
attribute of any users of the current domain (the following commands must be executed directly on a Domain Controller):
SID History modification through DCShadow
The restriction on the modification of the SIDHistory
attribute can be also bypassed through a DCShadow
attack to arbitrarily set an account SIDHistory
attribute. For more details on the DCShadow
attack, refer to the "DCShadow ACL" section of this note.
This technique will override any SID(s)
currently present in the security principal
's SIDHistory
attribute.
Jumps using Kerberos Golden tickets
The mimikatz
's kerberos::golden
module can be used to generate golden tickets
that may include arbitrary extra SIDs
as well as arbitrary group identifiers
. A golden ticket for the current domain can be generated, using one of the secrets of the current domain's krbtgt
account, to include SIDs
or group identifiers
related to the root domain of the forest. The specified SIDs
and / or group identifiers
will, respectively, populate the ExtraSids
and GroupIds
fields of the ticket's Privilege Attribute Certificate (PAC)
. For example, specification of the SID
of the Enterprise Admins
group (S-1-5-21-<ROOTDOMAIN_ID>-519
) will effectively impersonate membership to the group and grant full access to the domains in the forest.
Through this level of privileges, the secrets of the krbtgt
account can be retrieved through DRSUAPI
replication functions, attack known as DCSync
, or extracted from the Active Directory database ntds.dit
after exfiltration from a Domain Controller. The secrets of krbtgt
account can then further be used to craft Golden tickets
for the root domain of the forest. For more information, refer to the [ActiveDirectory] ntds.dit dumping
and [ActiveDirectory] Golden Tickets
notes.
Inter-forests trusts hopping
External and CrossForest trusts with out SID Filtering
Inter-forests
external
and CrossForest
trusts with out SID Filtering
can be jumped by impersonating non-default security principals (SID
S-1-5-21-<Domain>-R
with R >= 1000). Depending on the targeted Active Directory domain configuration, this level of impersonation can likely be leveraged to elevate privileges on the domain or take control of the non-tier 0 assets (servers and workstations) in a properly hardened domain implementing an administrative tiering model.
Among many possibilities, the following techniques may be leveraged:
Impersonation of membership to the
DnsAdmins
non built-indomain local
group. Members of theDnsAdmins
group can load and execute an arbitraryDynamic Link Library (DLL)
on the servers executing the Active DirectoryDNS
service (usually the Domain Controllers). Refer to the[ActiveDirectory] Operators to Domain Admins
note for more information on how to leverage impersonation of membership to theDnsAdmins
group for privilege escalation.Impersonation of membership to non built-in groups having the necessary rights to make replication requests through the
DRSUAPI
functions (DCSync
attack). For environment with an on-premise Exchange infrastructure with out theFebruary 12th 2019
security update applied, the non-defaultExchange Trusted Subsystem
andExchange Windows Permissions
security group may be (indirectly) granted such privileges. Indeed, for such Exchange installation inShared permissions
(default) orRBAC split
permissions (common), theExchange Windows Permissions
group is grantedWriteDacl
on theDomain root
object (which can be abused to grant oneself replication rights).Impersonation of membership to non built-in groups having administrator privileges on the tier 1 or 2 assets. Such groups can be identified through:
Local groups enumeration. Refer to the
[ActiveDirectory] Credentials theft shuffling
note for more information on how to enumerate members of the localAdministrators
groups.Enumeration of the security principals having delegated read access to the
LAPS
password of multiple computers. TheFind-LAPSDelegatedGroups
PowerShell cmdlet can be used to conduct this enumeration. Refer to the[ActiveDirectory] ACL exploiting
note for more information.Groups naming convention, with the potential use of keywords such as "adm", "admin", etc. to tag privileged groups.
External and CrossForest trusts with SID Filtering - "Printer Bug"
Bidirectional External
and CrossForest
trusts with SID Filtering
enabled may be jumped by leveraging a Kerberos
unconstrained delegation
on the source forest and the Print Spooler
service on a Domain Controller of the targeted forest.
The attack is based on the fact that a MSRPC
function exposed by the Print Spooler
service (on the MS-RPRN
interface) can be used to force the machine running the service to authenticate to a specified remote system. If the Print Spooler
service is exposed on a Domain Controller, a Kerberos
authentication of the Domain Controller machine account can thus be triggered to a controlled machine trusted for unconstrained delegation
. This Kerberos
authentication will result in the TGT
of the Domain Controller machine account to be sent and further retrievable on the controlled machine. The obtained TGT
can be used to request Kerberos
service tickets
under the identity of the Domain Controller, to conduct, for example replication operations (DCSync
).
The attack requires the following prerequisites to be satisfied:
An
External
andCrossForest
trusts allowingTGT
delegation. Refer to the "Security mechanism: TGT delegation" overview for the conditions in which this can be the case.The
Print Spooler
service to be enabled and exposed to at least one Domain Controller of the targeted forest.The control of a machine configured for
unconstrained delegation
on the source forest side. All Domain Controllers are by default trusted forunconstrained delegation
.
Identification and authentication trigger of Domain Controllers exposing the Print Spooler
service
Multiple tools can be used to scan the Domain Controllers of the targeted forest for exposed Print Spooler
services:
The printerbug.py
Python script and SpoolSample
can be used to trigger an authentication request to the specified host (using its hostname to generate a Kerberos authentication):
For more information, refer to the [L7] MSRPC - MS-RPRN "printer bug"
note.
Optional - configuration of unconstrained delegation on a controlled machine
The Domain Controllers are trusted for Kerberos
unconstrained delegation
.
However, if a Domain Controller (exposing the Print Spooler
service) of the targeted forest is accessible from the attacking machine, a computer can be joined to the domain and configured to be trusted for unconstrained delegation
. Doing so will allow to jump the trust with out deploying third party tools on a Domain Controller.
TGT extraction and usage
The TGT
of the Domain Controller machine account received after triggering the Print Spooler
service authentication can be extracted using Rubeus
's monitor
module:
The base64 encoded ticket can be injected in the current session using, among others, Rubeus
's ptt
module:
Replication operations, attack known as DCSync
, can then be conducted, using mimikatz
for example, through the session in which the Domain Controller machine account's TGT
was injected. The specified Active Directory objects' sensible information (NTLM
hash and Kerberos
secrets) can be remotely retrieved.
For more information on how to make use of the obtained TGT
and conduct the DCSync
attack, notably from a Linux attacking machine, refer to the [ActiveDirectory] Kerberos tickets usage
and [ActiveDirectory] ntds.dit dumping
notes.
References
https://docs.microsoft.com/fr-fr/azure/active-directory-domain-services/concepts-forest-trust https://blogs.msmvps.com/acefekay/2016/11/02/active-directory-trusts/ https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/c9efe39c-f5f9-43e9-9479-941c20d0e590 https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e9a2d23c-c31e-4a6f-88a0-6646fdb51a3c https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962 https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/ https://gist.github.com/xan7r/ca99181e3d45ee2042425f4f9181e614 https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/55fc19f2-55ba-4251-8a6a-103dd7c66280 https://www.ssi.gouv.fr/uploads/IMG/pdf/Aurelien_Bordes_-Secrets_d_authentification_episode_II_Kerberos_contre-attaque--_planches.pdf https://github.com/wavestone-cdt/MISC-AD-trusts-relationships/SIDHistoryInjection http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/ https://support.microsoft.com/fr-fr/help/4490425/updates-to-tgt-delegation-across-incoming-trusts-in-windows-server https://github.com/vletoux/pingcastle/issues/9
Last updated