Enumerating Object Permissions
In this section, we will enumerate specific permissions
that are associated with Active Directory objects.
AD includes a wealth of permission types that can be used to configure an ACE.
However, from an attacker’s standpoint,
we are mainly interested in a few key permission types.
Here’s a list of the most interesting ones
along with a description of the permissions they provide:
The Microsoft documentation lists other permissions
and describes each in more detail.
We can use Get-ObjectAcl to enumerate ACEs with PowerView.
To get started, let’s enumerate our own user
to determine which ACEs are applied to it.
We can do this by filtering on -Identity:
The amount of output may seem overwhelming since we enumerated every ACE
that grants or denies some sort of permission to stephanie.
While there are many properties that seem potentially useful,
we are primarily interested in ActiveDirectoryRights,
ObjectSID and SecurityIdentifier.
The output lists two Security Identifiers (SID),
unique values that represent an object in AD.
The first (located in the highlighted ObjectSID property)
contains the value, which is rather difficult to read.
In order to make sense of the SID,
we can use PowerView’s Convert-SidToName command
to convert it to an actual domain object name:
The conversion reveals that the SID in the ObjectSID property
belongs to the stephanie user we are currently using.
The ActiveDirectoryRights property
describes the type of permission applied to the object.
In order to find out who has the ReadProperty permission in this case,
we need to convert the SecurityIdentifier value.
Let’s use PowerView to convert it into a name we can read:
According to PowerView, the SID in the SecurityIdentifier property
belongs to a default AD group named RAS and IAS Servers.
Taking this information together,
the RAS and IAS Servers group has ReadProperty access rights to our user.
While this is a common configuration in AD and likely won’t give us an attack vector,
we have used the example to make sense of the information we have obtained.
In short, we are interested in the
ActiveDirectoryRights and SecurityIdentifier
for each object we enumerate going forward.
The highest access permission we can have on an object is GenericAll.
Although there are many other interesting ones
as discussed previously in this section,
we will use GenericAll as an example in this case.
We can continue to use Get-ObjectAcl
and select only the properties we are interested in,
namely ActiveDirectoryRights and SecurityIdentifier.
While the ObjectSID is nice to have,
we don’t need it when we are enumerating specific objects in AD
since it will only contain the SID for the object we are in fact enumerating.
Although we should enumerate all objects in the domain,
let’s start with the Management Department group for now.
We will check if any users have GenericAll permissions.
To generate clean and manageable output, we’ll use the PowerShell -eq flag
to filter the ActiveDirectoryRights property,
only displaying the values that equal GenericAll.
We’ll then pipe the results into select,
only displaying the SecurityIdentifier and ActiveDirectoryRights properties:
In this case, we have a total of five objects
that have the GenericAll permission on the Management Department object.
To make sense of this, let’s convert all the SIDs into actual names:
The first SID belongs to the Domain Admins group
and the GenericAll permission comes as no surprise
since Domain Admins have the highest privilege possible in the domain.
What’s interesting, however, is to find stephanie in this list.
Typically, a regular domain user should not have
GenericAll permissions on other objects in AD,
so this may be a misconfiguration.
This finding is significant and indicates that stephanie is a powerful account.
When we enumerated the Management Group,
we discovered that jen was its only member.
As an experiment to show the power of misconfigured object permissions,
let’s try to use our permissions as stephanie
to add ourselves to this group with net.exe.
Based on the output, we should now be a member of the group.
We can verify this with Get-NetGroup.
This reveals that jen is no longer the sole member of the group
and that we have successfully added our stephanie user in there as well.
Now that we have abused the GenericAll permission,
let’s use it to clean up after ourselves by removing our user from the group:
Once again we can use PowerView to verify
that jen is the sole member of the group:
Great, the cleanup was successful.
In this particular case, we enumerated the Management Group object specifically
and leveraged stephanie’s GenericAll to add our own user to the group.
Although it didn’t grant us additional domain privileges,
this exercise demonstrated the process of discovering and abusing
the vast array of permissions that we can leverage in real-world engagements.