Last updated
Last updated
Remember that if Domain A trusts Domain B, users in Domain B can access resources in Domain A; but users in Domain A should not be able to access resources in Domain B. If we're in Domain A, then it's by design that we should not be able to access Domain B. An outbound trust exists between cyberbotic.io and msp.org. The direction of trust is such that cyberbotic.io trusts msp.org (so users of msp.org can access resources in cyberbotic.io).
Because DEV has a trust with CYBER, we can query the trusts that it has by adding the -Domain parameter.
We can still partially exploit this trust and obtain "domain user" access from CYBER to MSP by leveraging the shared credential for the trust. Both domains in a trust relationship store a shared password (which is automatically changed every 30 days) in a Trusted Domain Object (TDO). These objects are stored in the system container and can be read via LDAP. Here we see that the DC in CYBER has two TDOs for its trusts with DEV and MSP.
There are two options for obtaining the key material. One is to move laterally to the DC itself and dump from memory.
This performs memory patching, which is very risky, particularly on a domain controller.
The second is to use DCSync with the TDO's GUID.
[Out] and [Out-1] are the "new" and "old" passwords respectively (they're the same here because 30 days hasn't elapsed since the creation of the trust). In most cases, the current [Out] key is the one you want. In addition, there is also a "trust account" which is created in the "trusted" domain, with the name of the "trusting" domain. For instance, if we get all the user accounts in the DEV domain, we'll see CYBER$ and STUDIO$, which are the trust accounts for those respective domain trusts.
This means that the MSP domain will have a trust account called CYBER$, even though we can't enumerate across the trust to confirm it. This is the account we must impersonate to request Kerberos tickets across the trust.
Remember that RC4 tickets are used by default across trusts.
This TGT can now be used to interact with the domain.
This account is obviously not a domain admin, but there are multiple abuse primitives that can now be performed across the trust to elevate privileges - including kerberoasting, ASREPRoasting, RBCD, and vulnerable certificate templates.
As a challenge, try and find a way to get DA in this forest.