基于域信任关系的域攻击

域信任

The trust relationship between domains is established so that users of one domain can easily access resources in other domains, and also facilitate the management and maintenance of the domain network. While this model brings convenience, there are also many places that can be exploited by malicious attackers.

Domain trust relationships can be of one-way\two-way trust, passable\non-transmitted trust, internal\external trust, cross link trust, etc. For example, there is a one-way transferable external trust relationship between the 2 domains. The domain trust relationship within the same forest is generally implicit in two-way transitive internal trust relationship.

deploy:

The parent-child trust relationship is the most common domain trust relationship. When adding a new domain within the same forest, the most common one is the child domain pattern (Parent-Child) or the tree root pattern (Tree-Root). These two modes will establish a parent-child trust\tree-root trust relationship, which are both two-way passable internal trust relationships.

Cross-domain link trust refers to establishing a direct trust relationship between two subdomains of the same forest. Because in the same forest, the organizational relationship of a domain is a tree-like structure. From one subdomain to another, you need to find the Forest Root from the branch's subdomain, and then continue to find the other subdomain from the root domain. Cross-domain linking is equivalent to establishing a shortcut trust relationship between the 2 subdomains to reduce the time and steps of authentication and authorization.

Internal trust refers to the trust relationship between the internal domains of the forest. Accordingly, External Domain Trust refers to the trust relationship between the domain and the domain outside the forest.

There is also a kind of MIT trust (the Kerberos protocol and standard are proposed by MIT), which is a trust relationship between Windows domains and non-Windows domains. Due to the few applications, this article will not discuss this type of domain trust relationship.

跨域认证和资源访问授权

When a domain trust relationship is established between two domains, a shared inter-domain key (Inter-Realm Key, abbreviated as IRKey) is established, which is equivalent to Krbtgt. However, IRKey is used for authentication between two domains that are trusted, while Krbtgt is used for authentication between AC and KDC of the same domain server.

The authentication and authorization process between trust domains is roughly similar to the authentication and authorization in the same domain, but there are still many differences.

Jack initiates an authentication request to DC1, and the data is encrypted by Jack's password NTLM value;

DC1 uses Jack's password NTLM value to verify the received authentication request, returning an authenticated TGT ticket to Jack;

Jack uses TGT tickets to initiate an authorization request to DC1, and initiates a TGS_REQ request to access the file service in DC2;

DC1 checks that the file service is in DC2 and returns a redirectable TGT (Referral TGT), indicating that it needs to be transferred to DC2, and uses IRKey to encrypt the authentication information in the redirectable TGT;

After Jack receives the TGT that can be transferred, according to the prompt information, use the TGT to initiate a request to access the file service in DC2 TGS_REQ;

After DC2 receives the request, it uses IRKey to verify the authentication information in TGT, and returns a TGS ticket that allows access to the file service. Some of the information in the ticket is encrypted using the password NTLM value of the service account running the file service;

Jack uses the received TGS tickets to access file services in DC2;

The service account of the file service service uses password NTLM value verification TGS

When a trust relationship is established between two domains, the other party's SPN, DNS and other information will be archived in the global domain database for easy access. For example, in the above figure, DC1 will archive all service SPN, DNS and other information in DC2.

If the service Jack requests access is in DC1's global database, it will return to the TGT. If it is not there, if DC1 has a parent domain, DC1 will request the parent domain until the forest's root domain server. If DC1 itself is the root server (in this case, DC1 is the root domain server), it will directly tell Jack that the service requested access does not exist.

A forest has only one global database.

SIDHistory 版跨域黄金票据

In a domain, once we obtain the NTLM value of Krbtgt, we can construct gold notes, which fake it to arbitrary users in the domain, including administrators, to obtain full access control rights to the domain. But in different domains of the same forest, the gold notes are no longer valid.

Let’s review the major elements of gold notes, namely the domain name, the domain SID (Security Identifier), the NTLM value of the Krbtgt user password, and the user RID (Relative Identifier, without special indication, the Mimikatz tool will set the RID to the domain administrator’s RID). Different domains have different Krbtgts, causing gold notes to fail between different domains.

1

mimikatz.exe 'kerberos:golden /user:anyusername /domain:lab.adsec.com /sid:S-1-5-21-2732272027-1570987391-2638982533 /krbtgt:16ed27ee7848756cfa96b33c25e3ad3d /ptt' exit

Different domains have different Krbtgts, causing gold notes to fail between different domains.

It can be seen that when constructing gold notes for the lab.adsec.com domain, they are valid in this domain, and the notes are invalid in the parent domain adsec.com.

If the SIDHistory property of a user is set to the high-privileged group or the user's ID, the user also has permissions equivalent to the high-privileged group or the user. If we add the SID of the domain administrator group of the target domain into the fake gold notes, we can obtain the domain administrator rights of the target domain. The combination of gold notes and SIDHistory can realize cross-domain gold notes.

Since the SID of each domain is different, gold notes superimposed on SIDHistory are not universal. According to Microsoft's description, within the same domain forest, the enterprise management group EA (Enterprise Administrators) will automatically be added to the domain administrator group of this domain by all domains within the forest, and the EA only exists in the root domain, so the SID of the enterprise management group EA is fixed to the SID of the root domain plus a fixed RID, that is, 519.

Therefore, if the SIDHistory attribute is set using the SID of the Enterprise Management Group EA and combined with the gold notes, cross-domain gold notes for all domains can be realized on the premise that only obtains the NTLM value of any domain krbtgt account, this bill can be referred to as the SIDHistory version of gold notes.

Of course, you can also add the administrator group SID of a specified domain in the forest to SIDHistory, but such gold bills are only valid for the specified domain and are invalid for other domains. It is not as universal as using the bills of the Enterprise Admin SID.

1

mimikatz.exe 'kerberos:golden /user:anyusername sids:[sid for EA group] /sid:[sid for lab.adsec.com domain] /domain:lab.adsec.com /krbtgt:16ed27ee7848756cfa96b33c25e3ad3d /ptt' exit

The gold notes are still constructed in the lab.adsec.com domain, but the SIDS parameter is added, using the root domain's enterprise administrator SID as the parameter value, i.e. the SIDHistory version of the gold notes, which are valid for both the lab.adsec.com and adsec.com domains.

It should be noted here that the basis for implementing the SIDHistory version of gold notes is the trust relationship within the forest, because if it is not the trust relationship within the forest, the SIDHistory will be filtered out by Microsoft's SID Filter rules and thus invalid, but there will be no SID Filter rules within the forest. This is why it is said that forests rather than domains are the security boundaries.

IRKey 版跨域黄金票据

When a domain trust relationship is established between two domains, a shared inter-domain key (Inter-Realm Key, abbreviated as IRKey) needs to be established. Its function is equivalent to Krbtgt, but it is used between two domains that trust each other, and Krbtgt is used between the AC and KDC of the same domain server.

As long as you obtain the NTLM value of the krbtgt account in any domain inside the forest, you can obtain control of all domains in the forest through the SIDHistory version of the gold notes. Therefore, in order to defend, the NTLM value of the krbtgt account in all domains within the forest must be modified 2 times.

In a multi-domain environment, IRKey is similar to the host account. The system automatically modifys NTLM every 30 days by default. Therefore, even if the NTLM of the krbtgt account in all domains in the forest is modified twice, the NTLM of IRKey is likely to not change (the low probability is that the NTLM modification of krbtgt happens to meet the IRKey modification cycle).

Similar to silver notes, you can use IRKey to forge inter-domain transitive bills (Inter-Realm Referral TGT) to obtain domain administrator rights for the target domain, and then combine the SIDHistory version of gold notes in the previous section to obtain control of the entire forest again. What you need to note here is that SID is the SID of the target domain.

In the domain, most accounts with the ‘$’ symbol are Computer accounts, but the accounts with the ‘$’ symbol in the User group are trust accounts. You can obtain all User accounts with the ‘$’ symbol through the Powershell command Get-ADUser, which comes with the domain server. In the figure below, the ADSEC$ account is a trust account and belongs to the Users group.

There are 2 ways to get the NTLM value of a trusted account.

Dcsync 获取信任账号的 NTLM 值

The following figure uses Dcsync method to obtain the NTLM value of the trusted account adsec$ in the lab.adsec.com domain. The result shows that the type of the account is TRUST_ACCOUNT

lsadum 获取信任账号的 NTLM 值

Use lsadump:trust/patch method. From the figure below, you can see two different NTLM values: [IN] LAB.ADSEC.COM - ADSEC.COM and [OUT] ADSEC.COM - LAB.ADSEC.COM, which are the values used when accessing from other domains and from within to this domain. Because the two-way trust relationship is actually a superposition of 2 one-way trust relationships, there will be 2 keys. Here we want to construct the IRKey version of gold notes from this domain to access other domains inside the forest, so use the NTLM value IN.

Since IRKey exists between trust domains inside the forest and also between forests outside the forest, they can be used for transfer to certification. In SIDHistory version of gold notes, it cannot be used between forests due to the SID Filter rule, but the IRKey version does not involve this security filtering rule and is still valid. The IRKey version of gold notes can be divided into two types inside the forest and outside the forest. The operation method is similar. Here we focus on introducing the IRKey version of gold notes inside the forest.

Authentication of inter-domain transvoting bills relies on IRKey encryption. Under the premise that we know IRKey, any user holding the trust domain of the IRKey can be forged. In the test, we construct a ticket and tell the adsec.com domain that the user who switched to the authenticated is the administrator, and SIDHistory is the enterprise administrator of the root domain.

After the construction is successful, you have the administrator rights of adsec.com, but you cannot access lab.adsec.com with high permissions, because the constructed ticket is the administrator ticket to the adsec.com domain. After obtaining high permissions of the adsec.com domain, you can obtain the NTLM value of the krbtgt account of the domain. On this basis, you can continue to construct the SIDHistory version of gold notes, so that you can obtain control of the entire forest.

域信任关系的获取

In large domain networks, the organizational model and trust relationship of the domain network are different due to various reasons such as company mergers and acquisitions, enterprise restructuring, and business expansion. These different trust relationships are stored in the forest root domain database (Global Catalog), and there are many ways to obtain this data

PowerView and BloodHound tools provide a variety of ways to obtain domain trust relationships and can visualize trust relationships. The following will introduce the method and process of obtaining the entire forest trust relationship from the host of a subdomain within the forest.

Powerview:

First use the Get-NetForestTrust command to obtain a forest-level trust relationship. There are 2 forests, which are adsec.com, testlab.com, and two forests to establish a two-way trust relationship.

Use the Get-NetDomainTrust command to obtain the domain-level trust relationship of the adsec.com domain, that is, the forest internal relationship, and there are two forest internal relationships: ParentChild trust relationship to lab.adsec.com and TreeRoot to res.com domain.

In the test, the parameter adsec.com of Get-NetDomainTrust indicates the query of the trust relationship on the specified domain. Generally, as long as the specified domain trusts the domain where the current query host is located, the other party's trust relationship data can be obtained.

When querying, you can use Export-CSV -NoTypeInformation to convert the output results to CSV format, with the command Get-DomainTrustMapping -API | Export-CSV -NoTypeInformation trusts-mapping.csv. Then use the TrustVisualizer tool for visual output. Finally, use the yED tool to convert it to a visual graphics.

利用域信任实现跨域攻击

If a user in a domain (assuming that the user is an eviluser) wants to access resource access in other domains, first make sure that the target domain trusts the domain where the current user is located. This is the basic premise, and then one of the following 3 conditions must be met.

eviluser is added to a group by the target domain, which has resource access permissions in the target domain;

eviluser is added as a local group by some host or server in the target domain, for example by a server as a local administrator group;

The current user is added as the Security Principal of the access control ACL by some domain objects in the target domain. For example, you can modify the password of a domain user object.

Some people may be wondering, according to the previous introduction, since you can obtain the NTLM value of the Krbtgt account or the IRKey account of the current domain, you can obtain control of the entire forest, there is no need to introduce cross-domain attacks within the forest.

This is because in actual situations, it is not necessary to successfully obtain the NTLM value of the Krbtgt account or IRKey account of a certain domain, such as few domain resources, strict configuration, timely system updates, etc. At this time, you need to detour to a larger domain to have more opportunities to obtain the NTLM value of the Krbtgt account or IRKey account, because the more resources, the greater the probability of fragility.

To implement cross-domain attacks on domain A from the current user eviluser, you must first ensure that the current user has the permission to access domain A resources across domains, so the attack process should include several steps

From the database of the current domain, enumerate which domains trust the current domain (out). Since it is attacking other domains, there is no need to pay attention to which external domains trust (in) the current domain is trusted. This can be easily obtained from the method introduced in the previous section.

Using trust relationships, enumerate which groups in the target domain contain users of foreign domains. It should be explained here that there are usually 3 types of groups in the domain. The first is Domain Local Groups, which can add cross-domain and cross-forest group members, which is also the most common group; the second is Global Groups, which does not allow any cross-domain group members, even the same forest, and has higher authority, such as enterprise management groups; the third is Universal Groups, which can add any members in the forest, but cross-forest cannot. In cross-domain attacks within the forest, we only focus on the first and third types of intradomain groups. The memberof attribute of a user is calculated by the member attribute of the group, provided that the member attribute of the group has been updated to the global directory database (Global Catalog). If a user is added as a member of the generic group by another domain in the forest, the generic group updates the member attribute to the forest's global directory database, and the user's memberof attribute will be updated through calculations;

When a user is added as a member of the domain local group by another domain in the forest, since the domain local group does not update the memberf attribute to the global directory database, the user's memberf attribute will not be calculated to be updated. Therefore, even if we have permission to query the forest's global directory database, we can only get the member attributes added to the common groups of other domains. To obtain the member attributes added to the local groups of other domains, we need to poll all domains one by one

Enumerate the local groups of hosts\servers in the target domain, and see which foreign users are added to the local groups of hosts\servers. You can enumerate them through GPO group policy, or you can detect them one by one through PowerView. Of course, all detections of BloodHood automation are all.

Enumerate the ACLs of objects in the target domain and check whether there is a domain object ACL that contains foreign domain users. Generally speaking, any user can view the ACLs of all domain objects, and the ACLs of all domain objects are stored in the global database, which can be easily enumerated. PowerView provides the Get-DomainObjectACL command for easy enumeration

The second filter is performed on the users filtered in steps 2, 3, and 4, and the users belonging to the current domain are selected as attack objects in the current domain, such as obtaining the target user's NTLM value or TGT ticket, the attack method of this domain.

Use step 3 to attack the user NTLM value or TGT ticket to cross-domain access, enter the target domain, and then attack to obtain the target domain's Krbtgt account or IRKey account's NTLM value. If the conditions are not mature, continue the above steps and gradually enter more domains to find opportunities. When a user is joined to a group by the forest external domain, it will appear in the CN=ForeignSecurityPrincipals,DC=domain,DC=com group of the external target domain, which is equivalent to the user's representative or alias in the external domain, and all foreign users in the domain have the same SID, which is the effect of the cross-forest SID filtering security mechanism.

So just enumerate the ForeignSecurityPrincipals group and you can know which users have access to this external forest, assuming that the user results collection is ExternalUsers. Next, check whether the users in our current domain are included. If so, directly attack these users to obtain NTLM values or TGT tickets, thereby obtaining resource access rights to the forest external domain.

If not, check whether ExternalUsers contains users of our current forest, assuming the result collection is InternalUsers. Query the domain where InternalUsers are located in the current forest. Targeting these domains, using the cross-domain attack method inside the forest, attacking these domains, obtaining permissions to enter these domains, and then attacking users in InternalUsers from these domains, thereby obtaining resource access rights to external domains. This is a bypass attack

SID 过滤机制

Microsoft claims that forests are the security boundary of the active directory, but cross-forest attacks have appeared in 2005. First explain what SIDHistory and SID filtering mechanisms are

SIDHistory

SIDHistory (ExtraSids field in the PAC structure) is to facilitate users' migration between domains. When a user migrates to a new domain, the original SID and some SIDs of the group can be added to the SIDHistory property of the new user in the new domain. When this new user accesses a resource, it is determined that access is denied or allowed based on the matching of SID or SIDHistory in the resource ACL. Therefore, SIDHistory is equivalent to having one or more group attributes, and permissions are expanded

In a cross-domain trust relationship within the same forest, the SIDHistory attribute is not filtered by the SID filter protection mechanism. If the SIDHistory attribute of a subdomain adds the SID of the enterprise administrator (the enterprise administrator must be the forest administrator), the subdomain has the forest administrator authority and the permissions are expanded, so the SIDHistory was later modified to a protected attribute.

In the trust relationship across forests, the SIDHistory attribute is filtered by the SID filtering mechanism and no longer has the above privileged attributes. This is also one of the reasons why forests are the security boundaries of the active directory.

SID 过滤机制

When a user's TGT is forwarded to a new domain through a domain trust relationship, the PAC (privileged attribute certificate) in the TGT contains the user's SID and SIDHisto