Object Permission Theory
Let’s begin with a discussion of Active Directory securable object permissions.
Within Active Directory, access to an object
is controlled through a Discretionary Access Control List,
which consists of a series of Access Control Entries (ACE).
Each ACE defines whether access to the object is allowed or denied,
which entity the ACE applies to, and the type of access.
Note that when multiple ACE’s are present, their order is important.
If a deny ACE comes before an allow ACE,
the deny takes precedence, since the first match principle applies.
The concept of DACL and ACE are relatively similar to Windows file access permissions
but the information stored for each ACE is a bit complex.
An ACE is stored according to the Security Descriptor Definition Language,
or SDDL,
which is a string delimited by semicolons.
Each element of the ACE string consists of one or more concatenated values.
The first element is the ace_type,
which designates whether the ACE allows or denies permissions.
Next, the ace_flags set flags related to inheritance on child objects.
The third element is the access rights applied by the ACE,
while object_guid and inherit_object_guid
allows the ACE to apply to only specific objects as provided by the GUID values.
Finally, the account_sid is the SID of the object that the ACE applies to.
For example, imagine that the ACE on object A applies to object B.
This grants or denies object B access to object A with the specified access rights.
Since the ACE is detailed by the SDDL format, it can be difficult to read.
Only the ACE type,
access rights,
and SID are populated,
but are not easily readable.
We can, however, use Microsoft documentation to translate the ACE string.
The translated ACE string reveals that if we control the object given by the ACE SID,
we obtain the WRITE_DAC, WRITE_OWNER, and GENERIC_ALL access rights among others.
From a penetration testing perspective,
this means that improperly configured DACLs
can lead to compromise of user accounts, domain groups, or even computers.
We will discuss these and other compromise techniques in later sections,
but we must first enumerate the DACLs.
All authenticated domain users can read AD objects
(such as users, computers, and groups)
and their DACLs, meaning we can enumerate weak ACL configurations
from a compromised lowprivilege domain user account.
Unfortunately, there are rarely tools installed
for this task but we can perform this lookup through LDAP
with the Get-ObjectAcl PowerView method.
To test this out,
we’ll log in to the Windows 10 client as the Offsec domain user,
and open PowerShell with a bypass execution policy.
PowerView is located in C:\Tools,
and after importing it,
we can use Get-ObjectAcl,
specifying our own user.
The Get-ObjectAcl output
prints the often-lengthy list of ACEs applied to the object.
The fields of particular interest to us are ActiveDirectoryRights,
SecurityIdentifier,
and AceType.
The output tells us that the AD object identified by the this SID
has ReadProperty access rights to the Offsec user.
The SID is difficult to read but PowerView includes the ConvertFrom-SID method,
which can convert the SID to a username or group}.
The converted SID shows us that a default AD domain group
called RAS and IAS Servers
has ReadProperty access rights to our current user.
This is a fairly common access right, however,
and does not indicate a vulnerability.
This enumeration produced a lot of output and required a manual SID conversion.
To automate this, we can wrap Get-ObjectAcl in a ForEach loop
to resolve the SID through ConvertFrom-SID.
This appends the resolved user or group name to each ACE
and shows the ACE for members of the Domain Admins group.
Not surprisingly, members of the Domain Admins group
have the GenericAll access right,
which equates to the file access equivalent of Full Control.
Armed with a basic understanding of
DACLs and ACEs and a working enumeration technique,
we’ll explore a series of misconfigurations in the next two sections
that allow us to compromise additional users or groups.