RODCs, One-Way Trusts, and Credential Exposure
Happy new year!
If you’re not familiar with the concept of tokens or credential theft in general, hit up this post.
A Tale of Two Domains
I was helping a client out with some Active Directory design and ran into an interesting combination of configurations that I’d never had the chance to model in an adversarial engagement.
The client wanted their users to be able to authenticate to a host in the DMZ using their internal domain credentials. This put us firmly in the world of cross-zone trusts (blech). To compensate for this, the client planned on using a combination of RODCs and one-way external trusts.
The idea was to stand up an RODC in the DMZ for
DOMAIN1.COM with a RWDC for
DOMAIN1.COM living on the LAN.
DOMAIN1.COM would be configured with a one-way outbound trust (users from
DOMAIN2.COM are trusted, but not vice versa).
+-------DMZ--------+ | | | RODC.DOMAIN1.COM | | | +--------+---------+ | | | +--------+---------+ +-------------+ | | | | | RWDC.DOMAIN1.COM +------> | DOMAIN2.COM | | | | | +-------LAN--------+ +-----LAN-----+
The hope was that the use of an RODC in the DMZ would protect against the hashes for
DOMAIN1.COM being exposed if the DMZ was breached, and the one-way trust would ensure that anyone gaining access to
DOMAIN1.COM would not be able to access
DOMAIN2.COM resources. The client planned on administering
DOMAIN2.COM administration accounts for simplicity.
I was fairly certain that the use of an RODC would protect against physical theft of a Domain Controller and the entire AD database, but I was less sure that it would protect against token or credential theft.
I was specifically interested if there were instances where an administrator from
RWDC.DOMAIN1.COM could face exposure when logging onto the
RODC.DOMAIN1.COM domain and whether there were any situations in which an administrator from
DOMAIN2.COM would face that same exposure.
To test this, I used Mimikatz to retrieve credentials from interactive logon sessions, and PSInject to test out token theft. After gaining credentials, I then attempted lateral movement with
wmiexec.py to validate my findings. Here are my results.
DMZ to LAN (DOMAIN1.COM)
In this scenario, an Administrator performs an interactive logon to the compromised DC,
RODC.DOMAIN1.COM, to perform maintenance.
So the RODC provided absolutely no protections against credential theft (hashes or cleartext) and token theft worked just fine as well.
LAN to LAN (DOMAIN1.COM => DOMAIN2.COM)
Here, our attacker has successfully compromised RODC, which granted him access to RWDC. An Administrator from
DOMAIN2.COM logs on to the
This one was a little more surprising. I’d expected something about the one-way trust to prevent this sort of access, but that clearly was not the case.
This was surprising. I was not expecting this sort of technique to be successful for full lateral movement from the DMZ to the internal domain. The scenario described above requires SYSTEM-level access to a system before the credentials can be stolen, but with the right exploit or excessive rights granted, this is possible. It most definitely falls short of the sort of segmentation required between external an internal resources.
It is also worth mentioning that the above attacks are only possible when credentials are exposed, which happens for pretty much all logons except Type 3 (more on that here).