Curi-oddity: Trusted Domain Object Password Rotation
A short post on unexpected behavior within a lab environment which resulted me running down a rabbit hole until I could discover the answer to why an Active Directory Trust Key was always resetting.
In my review of the PEN-300 course, and overall research of supplemental information, I found a peculiarity within the lab environment. Don't worry Offsec lawyers - I'm not sharing any course content or trade secrets - so plz don't sue. This is a short write up of the odd behavior, which bugged me so much I had to figure out what was going on - hence, the"curioddity" title.
The Oddity
The issue was in regards to looking at Trusted Domain Objects (TDO) within a domain trust. I was noticing that while working within a lab environment, attempting to perform a SID History Referral Ticket forgery, the computer account's password hash of the trusted domain would change - without reverting the lab environment. It was often happening shortly after I completed my first attempt at forging the referral ticket, leading to an invalid referral ticket. This was super frustrating, to say the least. I asked the Offsec Student Mentors, who literally said "we're not sure why this happens." - which didn't help quell my curiosity. -_-
The change in password hashes was uniform across both mimikatz
and secretsdump
which eliminated any initial tool-specific concerns. This occurred multiple times, over multiple lab environment reversions. The reversion were not the cause of the TDO password hash change, but to confirm the behavior multiple times within a single static environment. I even setup a bash one-liner to track the password hash value change - pictured below - which would show the change of the trust key approximately 10 - 15 minutes after the environment was created.

The Curiosity (& Subsequent Research)
Even though I had successfully creating the referral ticket forgery with an updated password hash, it still ate at me why this was occurring. I had moved on, instead focused on supplementing my knowledge on AD Forest Domain Trusts. That post by dirkjanm then led me to harmj0y's blog post on Domain Trusts. I had read it previously, but was going over the content in more detail. This brought me to the MS Learn page on trusted domain objects - which discusses password rotation. Specifically:
"As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO ." Source: MS Learn
Something to work with! My guess was that this was the contributing factor to the password hash change. I spun back up the environment, and used PowerView to test the assumption. The goal was to specifically look at the password last set attribute from the trusted domain object. Using the Get-DomainComputer
or Get-DomainUser
cmdlets would not work - as user, machine, and trust accounts have different samAccountType
s. This is most easily represented by running either cmdlet with the -debug
flag. Alternatively, you could review the PowerView source code.

Get-DomainComputer
default LDAP filter
Get-DomainUser
default LDAP filterInstead, I used the Get-ADObject
cmdlet with a filter to specify a samAccountType
for a Trust Account.
date ; Get-DomainObject -LDAPFilter '(samAccountType=805306370)' -Properties name,pwdlastset |ft
I ran the query twice. Firstly, shortly after the environment was activated. It showed the password was last set nearly 5 years ago (lol). This presumably was when the course creators last modified the baseline lab environment. Which also corresponded closely to a creation date of April 2020. I then waited ~15 minutes or so, leaving the lab untouched, and reran the command. Sure enough, the pwdlastset
value changed, indicating a password change - validating my earlier hypothesis!

Conclusion
To recap - Active Directory trusted domain object passwords rotate their passwords every 30 days by default. It appears that it took the AD lab environment ~15 minutes or so after the lab was spun up to go through it's checks to then identify the outdated password for the trusted domain object to subsequently change it. An annoying nuance, that turned out to be fun to hunt down - only incidentally after moving on to tangential items. Moral of the story - read the vendor documentation 😄.
Zettelkasten FTW? TBD
A big reason I found this discrepancy was from recently deciding to change my note taking habits to zettlekasten. I'll probably write a separate post about my reflections on the technique. However, I'm still in the process of formulating my thoughts on the process. Thus far, it's been an exponential increase in the amount of work. I find that it takes me much longer to review course material, or any documentation I may be reviewing. That being said, it helps instill the content much faster. Additionally, I find myself having more of a curious mindset while reviewing material. Trying to experiment and tinker with things as I'm learning, as opposed to just barreling through the content as I used to in the past. More to come. Stay tuned...