Idea: Check for correct functioning of trust scanner for AD trusts

[ralish]

A few years ago Microsoft released an update which adds additional protections for abuse of NTLM pass-through authentication:
Windows updates add new NTLM pass-through authentication protections for CVE-2022-21857

One component of this protection is a new "trust scanner" function wherein the PDC of the forest root domain will scan all domains in each trusting forest by issuing LDAP queries every 8 hours. The gathered information is stored in the msDS-TrustForestTrustInfo attribute of each Trusted Domain Object (TDO). In most configurations the trust scanner will work without any configuration changes, but some will require changes so the PDC can successfully issue the required LDAP queries to the trusting domains.

In addition to the the obvious network connectivity requirements (LDAP access, associated services for name resolution, etc ...):

• The PDC needs the "Access this computer from the network right" to the trusting DCs (would be unusual not to)
• The PDC needs read access to the trusting forest configuration NC partition container (and the child objects)
• The PDC needs to be granted "Allowed to authenticate" permission to the trusting forest DC accounts

The latter one is probably the most common misconfiguration, as it requires explicit steps that are not a default configuration when a trust using selective authentication is used.

As for what PingCastle could potentially do, by reading the msDS-TrustForestTrustInfo attribute it should be possible to determine if the trust scanner is operating correctly by the presence of a ForestTrustScannerInfo record. In addition, it can be determined if the protections are disabled for the trust or specific domains via the flags in the records stored in the attribute.

[vletoux]

I do not see in the documentation what flag is corresponding to that

[ralish]

You can find it in the first linked article. See the TRUST_ATTRIBUTE_DISABLE_AUTH_TARGET_VALIDATION and LSA_SCANNER_INFO_DISABLE_AUTH_TARGET_VALIDATION flags and the new /AuthTargetValidation parameter supported by netdom.exe.

Unfortunately, reading the flag is a little tricky as it's encoded as part of a binary structure stored in the msDS-TrustForestTrustInfo attribute on the TDO. The second article provides the details of structure per [MS-ADTS].

[vletoux]

got it & thanks for reporting

For me this is too short to include this in the upcoming version.
I propose to add it in the next version.
I'm missing an example of data to test the produced code.
Can you share to me (privately to [email protected]) one example of the attribute msDS-TrustForestTrustInfo with the scanning info ?
I'll make a private release and share it with you for final tests.

[vletoux]

implemented a parser.
But apparently there is an error in the MS documentation (unless I'm mistaken)
https://learn.microsoft.com/en-us/answers/questions/1520623/(ms-adts)-6-1-6-9-3-1-record

[ralish]

Awesome work, hopefully the open specifications team can answer your query quickly. Do you still need an example record from myself per your earlier comment?

[vletoux]

I'll take any samples to double check the current code

[vletoux]

Trying to reformulate what would be the rule:

• if flag LSA_SCANNER_INFO_DISABLE_AUTH_TARGET_VALIDATION present on child forest trust (msDS-TrustForestTrustInfo)
• if flag TRUST_ATTRIBUTE_DISABLE_AUTH_TARGET_VALIDATION present on domain trust (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e9a2d23c-c31e-4a6f-88a0-6646fdb51a3c - trustattribute not documented)
• or flag XXX that determines that there is an issue such as a network issue
  Then Domain vulnerable to CVE-2022-21857

[ralish]

Hey Vincent,

I don't think I can provide a sample due to potential sensitivities around the data but very happy to test any beta builds when they're ready. Your proposed rule logic looks right to me (possibly influenced by Microsoft Open Specifications response).

[vletoux]

the answer was from me. There is no answer yet from MSFT