Grant rights
Last updated
Last updated
This abuse can be carried out when controlling an object that has WriteDacl over another object.
The attacker can write a new ACE to the target object’s DACL (Discretionary Access Control List). This can give the attacker full control of the target object.
Instead of giving full control, the same process can be applied to allow an object to DCSync by adding two ACEs with specific Extended Rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All). Giving full control leads to the same thing since GenericAll includes all ExtendedRights, hence the two extended rights needed for DCSync to work.
Story time, Exchange Servers used to have WriteDacl over domain objects, allowing attackers to conduct a PrivExchange attack where control would be gained over an Exchange Server which would then be used to grant an attacker-controlled object DCSync privileges to the domain.
ACE inheritance
If attacker can write an ACE (WriteDacl) for a container or organisational unit (OU), if inheritance flags are added (0x01+ 0x02) to the ACE, and inheritance is enabled for an object in that container/OU, the ACE will be applied to it. By default, all the objects with AdminCount=0 will inherit ACEs from their parent container/OU.
Impacket's dacledit (Python) can be used with the -inheritance flag for that purpose (PR#1291).
From UNIX-like systems, this can be done with Impacket's dacledit.py (Python).
At the time of writing, May 2nd 2022, the Pull Request (#1291) is still pending.
For a DCSync granting attack, instead of using dacledit, ntlmrelayx has the ability to operate that abuse with the --escalate-user option (see this).
To enable inheritance, the -inheritance switch can be added to the command. Then it is possible to find interesting targets with AdminCount=0in BloodHound for example, by looking at the object attributs.
