red.offense.local
of a parent domain offense.local
, Active Directory Domains and Trusts show the parent-child relationship between the domains as well as their default trusts:offense.local
perspective and the second one from red.offense.local
. Note the the direction is BiDirectional
which means that members can authenticate from one domain to another when they want to access shared resources:dc-blue
in a new forest, let's setup a one way trust between offense.local
and defense.local
domains using controllers dc-mantvydas.offense.local
and dc-blue.defense.blue
.dc-mantvydas
a trusted domain:Forest
:dc-mantvydas.offense.local
is now created:dc-mantvydas.offense.local
is not able to share a folder to defense\administrator
(because offense.local
does not trust defense.local
):dc-blue.defense.local
, trusts offense.local
, hence is able to share a resource to one of the members of offense.local
- forest trust relationships work as intended:PC-MANTVYDAS$
:red.offense.local
domain:ps
, we can see a number of process running under the red\spotless
account. Here is one:usemodule situational_awareness/network/powerview/get_user
command to enumerate the red\spotless user and see if it is a member of any interesting groups, however my empire instance did not seem to return any results for this command. For this lab, assume it showed that the user red\spotless is a member of Administrators
group on the red.offense.local
domain.red\spotless
credentials: DC-RED
:DC-RED
- note that the credentials are coming from the previous dump with mimikatz:red.offense.local
is a child domain of offense.local
domain, which is automatically trusting and trusted (two way trust/bidirectional) with offense.local
- read on.red.offense.local
to EA in offense.local
. We need to create a golden ticket for red.offense.local
and forge it to make us an EA in offense.local
.krbtgt
user account in offense.local
:offense.local\krbtgt
, we need to get a password hash of the krbtgt
account in the compromised DC DC-RED
(we can extract it since we are a domain admin in red.offense.local
):offense.local\Domain Admins
since we have the SID of the offense.local\krbtgt
and the hash of red.offense.local\krbtgt
:sids
specification, we replaced the last three digits from 502 (krbtgt) to 519 (enterprise admins) - this part of the process is called a SID History Attack:CredID
property in the dcsync module comes from the Empire's credential store which previously got populated by our mimikatz'ing:offense.local
and we can test it by listing the admin share c$
of the dc-mantvydas.offense.local:
dc-mantvydas
: