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).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

+-------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 DOMAIN1.COM using 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.

The Attack

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 RWDC.DOMAIN1.COM server.

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.

Conclusion

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).