Inaccurate Attack Path created when ObjectType specified in ACE

[lbrauns]

Description:

In the domain i am analyzing (BHE) the EXCHANGE RECIPIENT ADMINISTRATORS are shown with a lot of WriteDacl and WriteOwner edges. Even to the Domain Root Object:

The only existing ACL that could produce this edge are ACL on the domain root object where the EXCHANGE RECIPIENT ADMINISTRATORS receive CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner on the object type ms-Exch-Dynamic-Distribution-List.

Full ACL:

InheritedObjectType   : All
ObjectDN              : DC=CHILDDOMAIN,DC=net
ObjectType            : ms-Exch-Dynamic-Distribution-List
IdentityReference     : PARENTDOMAIN\Exchange Recipient Administrators
IsInherited           : False
ActiveDirectoryRights : CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner
PropagationFlags      : None
ObjectFlags           : ObjectAceTypePresent
InheritanceFlags      : ContainerInherit
InheritanceType       : All
AccessControlType     : Allow
ObjectSID             : S-1-5-21-[REDACTED]
TargetObjectType      : DomainRoot

In this case the EXCHANGE RECIPIENT ADMINISTRATORS comes from a parent domain and the privileges are present on the child domain root object, this might be relevant.

This is a false positive and creates a LOT of unnecessary edges.

Component(s) Affected:

• [ ] UI
• [ ] API
• [ ] Neo4j
• [ ] PostgreSQL
• [ ] Data Collector (SharpHound, AzureHound)
• [ ] Other (tooling, documentation, etc.)

Steps to Reproduce:

1. Create environment with parent and child domain
2. Install Exchange Organization in the parent domain in Active Directory Split Permission mode.
3. Verify EXCHANGE RECIPIENT ADMINISTRATORS have a permission on the domain root object of the child domain
4. Collect data and run analysis
5. Check outbound control of EXCHANGE RECIPIENT ADMINISTRATORS

Expected Behavior:

Edges should not be created as permissions on the object type ms-Exch-Dynamic-Distribution-List are not abusable.

Actual Behavior:

EXCHANGE RECIPIENT ADMINISTRATORS show outbound control over all objects in the domain.

Screenshots/Code Snippets/Sample Files:

If applicable, add screenshots, relevant code snippets, or sample files that help illustrate the issue.

Environment Information:

BloodHound: Bloodhound Enterprise

Collector: Sharphound 2.3.10.0

Contributor Checklist:

• [X] I have searched the issue tracker to ensure this bug hasn't been reported before or is not already being addressed.
• [X] I have provided clear steps to reproduce the issue.
• [X] I have included relevant environment information details.
• [X] I have attached necessary supporting documents.
• [X] I have checked that any JSON files I am attempting to upload to BloodHound are valid.

[JonasBK]

Hey @lbrauns,

Thanks for reporting this.

I have Exchange configured in the AD split model in my lab, but I do not have the EXCHANGE RECIPIENT ADMINISTRATORS group at all. I guess it depends on the Exchange version.

Is it possible for you to send a screenshot of the ACE(s) the group has on the domain? Potentially from ldp.exe. Then I will try to create it manually in my lab.

[JonasBK]

Oh, you added the ACE. never mind!

[JonasBK]

I just confirmed in my lab that these edges are being generated when creating the given ACE granted to a user, and the user is not able to modify the DACL or change the owner.

When I remove the object type, then I can do those things. So it seems we should confirm that object type is not set before creating WriteDacl and WriteOwner edges. Do you agree @lbrauns?

[JonasBK]

Just confirmed that a clean WriteDacl ACE does not work when object type is set.

[lbrauns]

I just confirmed in my lab that these edges are being generated when creating the given ACE granted to a user, and the user is not able to modify the DACL or change the owner.

When I remove the object type, then I can do those things. So it seems we should confirm that object type is not set before creating WriteDacl and WriteOwner edges. Do you agree @lbrauns?

I am not sure if it is sufficient to check for the presence of an object type. The GUID map of the directory contains abusable object types as well, for example ms-DS-Key-Credential-Link is in there (but is already covered by SharpHound anyways). There might be more abusable object types contained there.

[JonasBK]

Yes, you are right. We should only avoid creating WriteDacl and WriteOwner if an object type is set. Maybe also GenericAll - I need to test that. We should still create edges like WriteAccountRestrictions that depends on the object type to be set 👍