Privileged Accounts and Token Privileges
Last updated
Was this helpful?
Last updated
Was this helpful?
Administrators
Domain Admins
Enterprise Admins
There are other account memberships and access token privileges that can also be useful during security assessments when chaining multiple attack vectors.
The Access Control List (ACL) of the AdminSDHolder object is used as a template to copy permissions to all “protected groups” in Active Directory and their members. Protected groups include privileged groups such as Domain Admins, Administrators, Enterprise Admins, and Schema Admins. By default, the ACL of this group is copied inside all the "protected groups". This is done to avoid intentional or accidental changes to these critical groups. However, if an attacker modifies the ACL of the group AdminSDHolder for example giving full permissions to a regular user, this user will have full permissions on all the groups inside the protected group (in an hour). And if someone tries to delete this user from the Domain Admins (for example) in an hour or less, the user will be back in the group.
Add a user to the AdminSDHolder group:
Check if the user is inside the Domain Admins group:
If you don't want to wait an hour you can use a PS script to make the restore happen instantly:
********
Allows creating non administrator accounts and groups on the domain
Allows logging in to the DC locally
Note the spotless' user membership:
However, we can still add new users:
As well as login to DC01 locally:
This membership allows users to configure Domain Controllers with the following privileges:
Allow log on locally
Back up files and directories
Change the system time
Change the time zone
Force shutdown from a remote system
Restore files and directories
Shut down the system
Note how we cannot access files on the DC with current membership:
However, if the user belongs to Server Operators:
The story changes:
As with Server Operators membership, we can access the DC01 file system if we belong to Backup Operators:
A user who is member of the DNSAdmins group or have write privileges to a DNS server object can load an arbitrary DLL with SYSTEM privileges on the DNS server. This is really interesting as the Domain Controllers are used very frequently as DNS servers.
Then, if you have a user inside the DNSAdmins group, you can make the DNS server load an arbitrary DLL with SYSTEM privileges. You can make the DNS server load a local or remote (shared by SMB) DLL file executing:
So, when the DNSservice start or restart, a new user will be created.
Even having a user inside DNSAdmin group you by default cannot stop and restart the DNS service. But you can always try doing:
This group gives you permission to read deleted AD object. Something juicy information can be found in there:
In most of the infrastructures, service accounts are typical user accounts with “Password never expire” option. Maintaining these accounts could be a real mess and that's why Microsoft introduced Managed Service Accounts:
No more password management. It uses a complex, random, 240-character password and changes that automatically when it reaches the domain or computer password expire date.
It is uses Microsoft Key Distribution Service (KDC) to create and manage the passwords for the gMSA.
It cannot be lock out or use for interactive login
Supports to share across multiple hosts
Can use to run schedule tasks (Managed service accounts do not support to run schedule tasks)
Simplified SPN Management – System will automatically change the SPN value if sAMaccount details of the computer change or DNS name property change.
So, if gMSA is being used, find if it has special privileges and also check if you have permissions to read the password of the services.
A very dangerous privilege to assign to any user - it allows the user to load kernel drivers and execute code with kernel privilges aka NT\System. See how offense\spotless user has this privilege:
Whoami /priv shows the privilege is disabled by default:
However, the below code allows enabling that privilege fairly easily:
We compile the above, execute and the privilege SeLoadDriverPrivilege is now enabled:
To further prove the SeLoadDriverPrivilege is dangerous, let's exploit it to elevate privileges.
You can load a new driver using NTLoadDriver:
By default the driver service name should be under \Registry\Machine\System\CurrentControlSet\Services\
But, according with to the documentation you could also use paths under HKEY_CURRENT_USER, so you could modify a registry there to load arbitrary drivers on the system. The relevant parameters that must be defined in the new registry are:
ImagePath: REG_EXPAND_SZ type value which specifies the driver path. In this context, the path should be a directory with modification permissions by the non-privileged user.
Type: Value of type REG_WORD in which the type of the service is indicated. For our purpose, the value should be defined as SERVICE_KERNEL_DRIVER (0x00000001).
Therefore you could create a new registry in \Registry\User\<User-SID>\System\CurrentControlSet\MyService indicating in ImagePath the path to the driver and in Type the with value 1 and use those values on the exploit (you can obtain the User SID using: Get-ADUser -Identity 'USERNAME' | select SID or (New-Object System.Security.Principal.NTAccount("USERNAME")).Translate([System.Security.Principal.SecurityIdentifier]).value
The first one declares a string variable indicating where the vulnerable Capcom.sys driver is located on the victim system and the second one is a string variable indicating a service name that will be used (could be any service). Note, that the driver must be signed by Windows so you cannot load arbitrary drivers. But, Capcom.sys can be abused to execute arbitrary code and is signed by Windows, so the goal is to load this driver and exploit it.
Load the driver:
Once the above code is compiled and executed, we can see that our malicious Capcom.sys driver gets loaded onto the victim system:
No it's time to abuse the loaded driver to execute arbitrary code.
Then, you will need to download a Capcom.sys exploit and use it to escalate privileges.
An example of a valid DLL can be found in . I would change the code of the function DnsPluginInitialize to something like:
****
gMSA accounts have their passwords stored in a LDAP property called msDS-ManagedPassword which automatically get resets by the DC’s every 30 days, are retrievable by authorized administrators and by the servers who they are installed on. msDS-ManagedPassword is an encrypted data blob called and it’s only retrievable when the connection is secured, LDAPS or when the authentication type is ‘Sealing & Secure’ for an example.
Also, check this about how to perform a NTLM relay attack to read the password of gMSA.
Download:
You can download exploits from and and execute it on the system to elevate our privileges to NT Authority\System:
You can use to automatically enable the privilege, create the registry key under HKEY_CURRENT_USER and execute NTLoadDriver indicating the registry key that you want to create and the path to the driver:
