Full Report
Tenable Research reveals an Active Directory anomaly: intra-forest trusts created under Windows 2000 lack a key identifying flag, even after domain and forest upgrades. Learn how to find this legacy behavior persisting to this day, and use crossRef objects to correctly distinguish these trust types.Key takeaways:If your organization has an Active Directory environment that originated in the Windows 2000 era, you may have misidentified trusts in your system. Active Directory's security-analysis tools rely on an attribute called trustAttributes to determine if a trust is internal to the forest (intra-forest) or external. For trusts created on Windows 2000, the specific flag that identifies them as "within-forest" (the TRUST_ATTRIBUTE_WITHIN_FOREST flag) was never set. The Tenable Research team confirmed through lab testing that upgrading both the domain and forest functional levels from Windows 2000 all the way up to Windows 2016 did not retroactively apply the missing "within-forest" flag to the old intra-forest Parent-Child trusts. The solution? CrossRef to the rescue.We don’t always get to go time traveling in our work here at Tenable Research. But a recent investigation into Active Directory trusts sent us on a trip in the wayback machine to the era of Windows 2000. We discovered that on very old Active Directory trusts created on Windows 2000, intra-forest trusts do not have the TRUST_ATTRIBUTE_WITHIN_FOREST flag enabled. The flag, which was introduced in Windows 2003, was not retroactively applied to existing trusts at the time. Even when the domain is upgraded to more modern versions (like 2016), this old trust attribute never updates automatically. This makes an internal Parent-Child trust look exactly the same as a potentially insecure external trust (one lacking the security setting known as SID Filtering/Quarantine), because both can show an empty or zero value for the trustAttributes.A bit of Active Directory historyActive Directory trusts are represented by Trusted Domain Objects (TDOs) stored as objects of class trustedDomain. The description of their trustAttributes in the official [MS-ADTS] Active Directory technical specification defines the TRUST_ATTRIBUTE_WITHIN_FOREST value simply as:If this bit is set, then the trusted domain is within the same forest.Only evaluated on Windows Server 2003 and later.One could easily ignore the mention of Windows Server 2003, considering how old it is, and assume it wouldn’t cause a problem nowadays. But, given what we observed in some AD domains, it also means that trusts created with Windows 2000 didn’t have this flag. And we can only assume that it was never retroactively applied (unless the trust was re-created of course), which is an issue.Unfortunately we didn’t find any official documentation to confirm that theory.We only found an old personal blog where the author wondered about the same issue, while noting that it concerned a migrated NT4 domain. A more recent blog post mentions a very similar situation, with some tricks to fix it; it isn’t official Microsoft guidance, however, and should be taken with extreme caution.Finally, we spoke with several seasoned AD experts who confirmed that they have encountered similar situations.Reproducing the issueTo confirm our hypothesis, we set about reproducing the issue in our lab by creating an Active Directory forest called prehistoric.lan, which comprised two AD domains connected via an intra-forest Parent-Child trust relationship:prehistoric.lan (PREHISTORIC short name): the parentchild.prehistoric.lan (CHILD short name): the childThe setup began with one Windows 2000 domain controller in each domain. Therefore, the forest (FFL) and domain functional levels (DFL) were 2000.Immediately we observed what we expected: the trustAttributes were equal to 0 in the TDO, in the parent domain, representing the trust with the child domain: Attributes of the TDO with the child domain (Windows 2000 DFL) as seen from the parent domain (Windows 2000 DFL). Source: Tenable, November 2025 Out of curiosity, we also looked in the opposite direction to see if the TDO in the child domain represented the trust with its parent: Attributes of the TDO with the parent domain (Windows 2000 DFL) as seen from the child domain (Windows 2000 DFL). Source: Tenable, November 2025 The trustAttributes wasn’t 0, but 4194304 = 0x400000 (TRUST_ATTRIBUTE_TREE_PARENT) which is documented as “Previously used trust bits, and are obsolete.” This one was not a concern for us.Then we upgraded the parent prehistoric.lan domain to the 2003 domain functional level by adding a 2003 domain controller, then removing the initial 2000 domain controller. Remember, this is the version when the new TRUST_ATTRIBUTE_WITHIN_FOREST flag was introduced. However, as we hypothesized, the TDO in the parent domain kept its trustAttributes=0: Attributes of the TDO with the child domain (Windows 2000 DFL) as seen from the parent domain (upgraded Windows 2003 DFL). Source: Tenable, November 2025 We thought perhaps it was a matter of forest functional level, so we also upgraded the child domain to domain functional level 2003 with the same steps, then upgraded the forest functional level to 2003. Same observation for the TDO in the parent domain, which is still set to trustAttributes=0: Attributes of the TDO with the child domain (upgraded to Windows 2003 DFL) as seen from the parent domain (Windows 2003 DFL & FFL). Source: Tenable, November 2025 For an even higher level of confidence, we then upgraded the parent prehistoric.lan to the 2016 domain functional level and the observation remained the same: Attributes of the TDO with the child domain (Windows 2003 DFL) as seen from the parent domain (upgraded to Windows 2016 DFL). Source: Tenable, November 2025 And finally, as you may have guessed, we also upgraded the child domain to domain functional level 2016, then upgraded the forest functional level to 2016, too. And the trust remained stuck with trustAttributes=0 like it did at the very beginning in the Windows 2000 era: Attributes of the TDO with the child domain (Windows 2016 DFL) as seen from the parent domain (upgraded to Windows 2016 DFL & FFL). Source: Tenable, November 2025 We didn’t upgrade further. We were very confident that our hypothesis was confirmed: an intra-forest trust, created under Windows 2000, will never automatically obtain the TRUST_ATTRIBUTE_WITHIN_FOREST flag even when the domain and forest are later upgraded.Here comes the confusionWe have confirmation that we can be missing the TRUST_ATTRIBUTE_WITHIN_FOREST flag even for intra-forest trusts, but is that really an issue? Can’t we simply ignore it? After all, we have the other TRUST_ATTRIBUTE_FOREST_TRANSITIVE flag set for cross-forest trusts. We should be good, right?Unfortunately, the answers are “no.” The reason? External trusts, which are another kind of inter-forest trusts. They don’t have any dedicated flag in “trustAttributes”, so they can be found with trustAttributes=0 or, more commonly, with trustAttributes=4 when the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN flag is correctly enabled.Here’s an example, taken from a different lab, of an external trust between two forests, first with trustAttributes=4 when quarantined, then with trustAttributes=0 after disabling the quarantine: Source: Tenable, November 2025 Here lies our problem: trustAttributes=0 can mean either:intra-forest trust which is too old to have the TRUST_ATTRIBUTE_WITHIN_FOREST flag set; orexternal trust without quarantineSurprisingly, we also noticed that the classic “Active Directory Domains and Trusts” admin tool is not affected by this confusion, as it’s able to show the correct trust type (Parent-Child in our case) for these trusts despite the ! We suppose that there is a mechanism, somewhere, to fix the interpretation of these trusts, or that it relies on other indicator(s). Unfortunately, we didn’t find the definitive location where this magic happens. We confirmed the observation in the first lab we used, see how the “Active Directory Domains and Trusts” admin tool correctly shows the trust type as “Child” despite trustAttributes=0: Source: Tenable, November 2025 We wondered if perhaps we could find the answer in the official AD PowerShell module, which relies on Active Directory Web Services (ADWS), and which is easier to reverse-engineer. Unfortunately, the Get-ADTrust cmdlet doesn’t have the same magic. It interprets directly trustAttributes, and so incorrectly considers that this Parent-Child trust is not intra-forest! Source: Tenable, November 2025 Therefore, we had to find an alternative way to interpret these Trusted Domain Objects where trustAttributes=0. We thought about finding hints in their other attributes but there was nothing characteristic so we had to find a different source of information.CrossRef to the rescueAt this moment we remembered about the crossRef technical objects, also stored in AD. They are used to store different naming context types, but those relevant for us are the domain crossRef objects. Each Active Directory domain has a corresponding crossRef object, but only for those that are in the forest (e.g. a crossRef is not created when there’s a forest trust), so we have our solution.When there’s a trust object with trustAttributes=0, search for a corresponding crossRef object where trustedDomain.trustPartner == crossRef.dnsRoot:There’s a corresponding crossRef, which by definition means that the target domain is in the forest: so it’s an intra-forest trustOtherwise, if there’s no crossRef, it means that the target domain isn’t in the forest: so it’s an external trustThis alternative rule allowed us to interpret the correct types for these confusing trusts (others continue using existing rules) and the updated interpretations were validated outside our lab in a real-world environment.ConclusionActive Directory is full of surprises, even on very old topics, such as trusts, that we may think are fully mastered by now. It was an interesting discovery which brought us back ~25 years in the early days of Active Directory.A correct interpretation of Active Directory trusts is required in AD exposure management solutions such as Tenable Identity Exposure, whose Dangerous Trust Relationships Indicator of Exposure implements the alternative we identified for this confusing case. More broadly, we hope that sharing this discovery will help AD administrators and security experts to properly understand when they stumble upon these in their manual reviews or in their custom scripts.We are very proud to serve Tenable customers who trust us with helping secure their Active Directory domains that they created two decades ago and maintain to this day.
Analysis Summary
As a vulnerability research specialist, I have summarized the disclosed Active Directory anomaly below in an actionable format. This issue is a configuration misidentification risk rather than a traditional software vulnerability requiring a patch.
# Vulnerability: Legacy Active Directory Intra-Forest Trusts Misclassified Due to Missing Windows 2000 Attribute
## CVE Details
- CVE ID: N/A (Configuration/Design Anomaly)
- CVSS Score: N/A
- CWE: CWE-285: Improper Authorization (If external trusts are incorrectly assumed secure)
## Affected Systems
- Products: Microsoft Active Directory Domain Services (AD DS)
- Versions: Any environment where the Domain Functional Level (DFL) and Forest Functional Level (FFL) are **Windows 2000, Windows Server 2003, or later**, *and* the environment originated with Windows 2000 DCs.
- Configurations: Intra-forest Parent-Child trusts created when the originating Domain Controllers were running Windows 2000 lack the `TRUST_ATTRIBUTE_WITHIN_FOREST` flag in their `trustAttributes` LDAP attribute.
## Vulnerability Description
Active Directory trusts created during the Windows 2000 era do not automatically set the `TRUST_ATTRIBUTE_WITHIN_FOREST` flag, even if the domain and forest functional levels are later upgraded to modern versions (e.g., Windows Server 2016).
This causes significant ambiguity because the trust's `trustAttributes` value can be `0`, which is the same value seen for **external trusts that lack SID Filtering/Quarantine enabled**. Security analysis tools that rely solely on LDAP attribute checking (like `Get-ADTrust` cmdlet) may incorrectly classify these legacy intra-forest trusts as potentially insecure external trusts, or fail to confirm they are intra-forest, leading to incorrect risk assessment.
## Exploitation
- Status: Not directly exploitable as a RCE/code execution flaw; this is a **detection and classification bypass risk**.
- Complexity: Low (for detection/scripting logic failure).
- Attack Vector: Configuration Analysis / Information Disclosure Misinterpretation.
## Impact
- Confidentiality: Low to Medium (Risk of unnecessary blanket permission granting if the trust is assumed secure when it shouldn't be, or conversely, if important access logging is missed due to misclassification).
- Integrity: Medium (Incorrect security posture assessment of inter-domain access paths).
- Availability: Low
## Remediation
### Patches
- No specific Microsoft patch is required as this is historical behavior preservation from Windows 2000.
### Workarounds
The recommended corrective action is to **rely on the presence of a `crossRef` object** associated with the trusted domain to definitively determine if a trust is intra-forest when `trustAttributes=0`.
**Detection/Correction Logic:**
1. **Identify Confusing Trusts:** Search for Trusted Domain Objects (TDOs) where `trustAttributes` equals `0`.
2. **Validate Forest Membership:** For any TDO where `trustAttributes=0`, check for the existence of a corresponding domain `crossRef` object where `trustedDomain.trustPartner` matches the `crossRef.dnsRoot`.
* **If a `crossRef` exists:** The trust is **Intra-Forest** (legacy Parent-Child).
* **If no `crossRef` exists:** The trust is likely an **External Trust** (potentially insecure if SID Filtering is absent).
*Note: Existing administrative tools like "Active Directory Domains and Trusts" GUI appear to handle this correctly internally, but custom scripts or standard PowerShell cmdlets may fail.*
## Detection
- **Indicators of Compromise:** No specific IoC, but an environment containing TDOs with `trustAttributes=0` requires immediate auditing of the corresponding `crossRef` objects.
- **Detection Methods and Tools:** Custom LDAP queries or AD auditing scripts must be updated to implement the `crossRef` object validation logic described above, rather than solely relying on the `trustAttributes` field for environments that originated in the Windows 2000 era. Tenable Identity Exposure's Dangerous Trust Relationships Indicator of Exposure (IOE) implements this necessary logic.
## References
- Tenable Research Article: hXXps://www.tenable.com/blog/active-directory-trust-misclassification-why-old-trusts-look-like-insecure-external-trusts