Windows Group Privileges
Windows Built-in Groups
As mentioned in the Windows Privileges Overview section, Windows servers, and especially Domain Controllers, have a variety of built-in groups that either ship with the operating system or get added when the Active Directory Domain Services role is installed on a system to promote a server to a Domain Controller.
This page has a detailed listing of privileged accounts and groups in Active Directory.
Accounts may be assigned to these groups to enforce least privilege and avoid creating more Domain Admins and Enterprise Admins to perform specific tasks, such as backups. Sometimes vendor applications will also require certain privileges, which can be granted by assigning a service account to one of these groups. Accounts may also be added by accident or leftover after testing a specific tool or script. We should always check these groups and include a list of each group's members as an appendix in our report for the client to review and determine if access is still necessary.
Backup Operators
After landing on a machine, we can use the command whoami /groups to show our current group memberships. Let's examine the case where we are a member of the Backup Operators group. Membership of this group grants its members the SeBackup and SeRestore privileges. The SeBackupPrivilege allows us to traverse any folder and list the folder contents. This will let us copy a file from a folder, even if there is no access control entry (ACE) for us in the folder's access control list (ACL). However, we can't do this using the standard copy command. Instead, we need to programmatically copy the data, making sure to specify the FILE_FLAG_BACKUP_SEMANTICS flag.
We can use this PoC to exploit the SeBackupPrivilege, and copy this file. First, let's import the libraries in a PowerShell session.
Importing Libraries
Import-Module .\SeBackupPrivilegeUtils.dll
Import-Module .\SeBackupPrivilegeCmdLets.dllVerifying SeBackupPrivilege is Enabled
Let's check if SeBackupPrivilege is enabled by invoking whoami /priv or Get-SeBackupPrivilege cmdlet. If the privilege is disabled, we can enable it with Set-SeBackupPrivilege.
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== ========
SeMachineAccountPrivilege Add workstations to domain Disabled
SeBackupPrivilege Back up files and directories Disabled
SeRestorePrivilege Restore files and directories Disabled
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set DisabledEnabling SeBackupPrivilege
If the privilege is disabled, we can enable it with Set-SeBackupPrivilege.
Copying a Protected File
The commands above demonstrate how sensitive information was accessed without possessing the required permissions.
Attacking a Domain Controller - Copying NTDS.dit
This group also permits logging in locally to a domain controller. The active directory database NTDS.dit is a very attractive target, as it contains the NTLM hashes for all user and computer objects in the domain. However, this file is locked and is also not accessible by unprivileged users.
As the NTDS.dit file is locked by default, we can use the Windows diskshadow utility to create a shadow copy of the C drive and expose it as E drive. The NTDS.dit in this shadow copy won't be in use by the system.
Copying NTDS.dit Locally
Next, we can use the Copy-FileSeBackupPrivilege cmdlet to bypass the ACL and copy the NTDS.dit locally.
Backing up SAM and SYSTEM Registry Hives
The privilege also lets us back up the SAM and SYSTEM registry hives, which we can extract local account credentials offline using a tool such as Impacket's secretsdump.py
It's worth noting that if a folder or file has an explicit deny entry for our current user or a group they belong to, this will prevent us from accessing it, even if the FILE_FLAG_BACKUP_SEMANTICS flag is specified.
Extracting Credentials from NTDS.dit
With the NTDS.dit extracted, we can use a tool such as secretsdump.py or the PowerShell DSInternals module to extract all Active Directory account credentials. Let's obtain the NTLM hash for just the administrator account for the domain using DSInternals.
Extracting Hashes Using SecretsDump
We can also use SecretsDump offline to extract hashes from the ntds.dit file obtained earlier. These can then be used for pass-the-hash to access additional resources or cracked offline using Hashcat to gain further access. If cracked, we can also present the client with password cracking statistics to provide them with detailed insight into overall password strength and usage within their domain and provide recommendations for improving their password policy (increasing minimum length, creating a dictionary of disallowed words, etc.).
Robocopy
Copying Files with Robocopy
The built-in utility robocopy can be used to copy files in backup mode as well. Robocopy is a command-line directory replication tool. It can be used to create backup jobs and includes features such as multi-threaded copying, automatic retry, the ability to resume copying, and more. Robocopy differs from the copy command in that instead of just copying all files, it can check the destination directory and remove files no longer in the source directory. It can also compare files before copying to save time by not copying files that have not been changed since the last copy/backup job ran.
This eliminates the need for any external tools.
Event Log Readers
Suppose auditing of process creation events and corresponding command line values is enabled.
In that case, this information is saved to the Windows security event log as event ID 4688: A new process has been created. Organizations may enable logging of process command lines to help defenders monitor and identify possibly malicious behavior and identify binaries that should not be present on a system. This data can be shipped to a SIEM tool or ingested into a search tool, such as ElasticSearch, to give defenders visibility into what binaries are being run on systems in the network. The tools would then flag any potentially malicious activity, such as the whoami, netstat, and tasklist commands being run from a marketing executive's workstation.
This study shows some of the most run commands by attackers after initial access (tasklist, ver, ipconfig, systeminfo, etc.), for reconnaissance (dir, net view, ping, net use, type, etc.), and for spreading malware within a network (at, reg, wmic, wusa, etc.).
Administrators or members of the Event Log Readers group have permission to access this log. It is conceivable that system administrators might want to add power users or developers into this group to perform certain tasks without having to grant them administrative access.
Confirming Group Membership
Microsoft has published a reference guide for all built-in Windows commands, including syntax, parameters, and examples. Many Windows commands support passing a password as a parameter, and if auditing of process command lines is enabled, this sensitive information will be captured.
We can query Windows events from the command line using the wevtutil utility and the Get-WinEvent PowerShell cmdlet.
Searching Security Logs Using wevtutil
We can also specify alternate credentials for wevtutil using the parameters /u and /p.
For Get-WinEvent, the syntax is as follows. In this example, we filter for process creation events (4688), which contain /user in the process command line.
Searching Security Logs Using Get-WinEvent
The cmdlet can also be run as another user with the -Credential parameter.
Other logs include PowerShell Operational log, which may also contain sensitive information or credentials if script block or module logging is enabled. This log is accessible to unprivileged users.
DnsAdmins
Members of the DnsAdmins group have access to DNS information on the network. The Windows DNS service supports custom plugins and can call functions from them to resolve name queries that are not in the scope of any locally hosted DNS zones. The DNS service runs as NT AUTHORITY\SYSTEM, so membership in this group could potentially be leveraged to escalate privileges on a Domain Controller or in a situation where a separate server is acting as the DNS server for the domain. It is possible to use the built-in dnscmd utility to specify the path of the plugin DLL. As detailed in this excellent post, the following attack can be performed when DNS is run on a Domain Controller (which is very common):
DNS management is performed over RPC
ServerLevelPluginDll allows us to load a custom DLL with zero verification of the DLL's path. This can be done with the
dnscmdtool from the command lineWhen a member of the
DnsAdminsgroup runs thednscmdcommand below, theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDllregistry key is populatedWhen the DNS service is restarted, the DLL in this path will be loaded (i.e., a network share that the Domain Controller's machine account can access)
An attacker can load a custom DLL to obtain a reverse shell or even load a tool such as Mimikatz as a DLL to dump credentials.
Leveraging DnsAdmins Access
Generating Malicious DLL
We can generate a malicious DLL to add a user to the domain admins group using msfvenom.
Starting Local HTTP Server
Downloading File to Target
Let's first see what happens if we use the dnscmd utility to load a custom DLL with a non-privileged user.
Loading DLL as Non-Privileged User
As expected, attempting to execute this command as a normal user isn't successful. Only members of the DnsAdmins group are permitted to do this.
Loading DLL as Member of DnsAdmins
Loading Custom DLL
After confirming group membership in the DnsAdmins group, we can re-run the command to load a custom DLL.
Only the dnscmd utility can be used by members of the DnsAdmins group, as they do not directly have permission on the registry key.
After restarting the DNS service (if our user has this level of access), we should be able to run our custom DLL and add a user (in our case) or get a reverse shell. If we do not have access to restart the DNS server, we will have to wait until the server or service restarts. Let's check our current user's permissions on the DNS service.
Finding User's SID
Checking Permissions on DNS Service
Once we have the user's SID, we can use the sc command to check permissions on the service. Per this article, we can see that our user has RPWP permissions which translate to SERVICE_START and SERVICE_STOP, respectively.
(SDDL syntax in Windows)
Stopping the DNS Service
Starting the DNS Service
Confirming Group Membership
Cleaning Up
Making configuration changes and stopping/restarting the DNS service on a Domain Controller are very destructive actions and must be exercised with great care. As a penetration tester, we need to run this type of action by our client before proceeding with it since it could potentially take down DNS for an entire Active Directory environment and cause many issues. If our client gives their permission to go ahead with this attack, we need to be able to either cover our tracks and clean up after ourselves or offer our client steps on how to revert the changes.
These steps must be taken from an elevated console with a local or domain admin account.
Confirming Registry Key Added
Deleting Registry Key
Starting the DNS Service Again
Checking DNS Service Status
Once again, this is a potentially destructive attack that we should only carry out with explicit permission from and in coordination with our client. If they understand the risks and want to see a full proof of concept, then the steps outlined in this section will help demonstrate the attack and clean up afterward.
Using Mimilib.dll
As detailed in this post, we could also utilize mimilib.dll from the creator of the Mimikatz tool to gain command execution by modifying the kdns.c file to execute a reverse shell one-liner or another command of our choosing.
Creating a WPAD Record
Another way to abuse DnsAdmins group privileges is by creating a WPAD record. Membership in this group gives us the rights to disable global query block security, which by default blocks this attack. Server 2008 first introduced the ability to add to a global query block list on a DNS server. By default, Web Proxy Automatic Discovery Protocol (WPAD) and Intra-site Automatic Tunnel Addressing Protocol (ISATAP) are on the global query block list. These protocols are quite vulnerable to hijacking, and any domain user can create a computer object or DNS record containing those names.
After disabling the global query block list and creating a WPAD record, every machine running WPAD with default settings will have its traffic proxied through our attack machine. We could use a tool such as Responder or Inveigh to perform traffic spoofing, and attempt to capture password hashes and crack them offline or perform an SMBRelay attack.
Disabling the Global Query Block List
Adding a WPAD Record
Hyper-V Administrators
The Hyper-V Administrators group has full access to all Hyper-V features. If Domain Controllers have been virtualized, then the virtualization admins should be considered Domain Admins. They could easily create a clone of the live Domain Controller and mount the virtual disk offline to obtain the NTDS.dit file and extract NTLM password hashes for all users in the domain.
It is also well documented on this blog, that upon deleting a virtual machine, vmms.exe attempts to restore the original file permissions on the corresponding .vhdx file and does so as NT AUTHORITY\SYSTEM, without impersonating the user. We can delete the .vhdx file and create a native hard link to point this file to a protected SYSTEM file, which we will have full permissions to.
If the operating system is vulnerable to CVE-2018-0952 or CVE-2019-0841, we can leverage this to gain SYSTEM privileges. Otherwise, we can try to take advantage of an application on the server that has installed a service running in the context of SYSTEM, which is startable by unprivileged users.
Target File
An example of this is Firefox, which installs the Mozilla Maintenance Service. We can update this exploit (a proof-of-concept for NT hard link) to grant our current user full permissions on the file below:
Taking Ownership of the File
After running the PowerShell script, we should have full control of this file and can take ownership of it.
Starting the Mozilla Maintenance Service
Print Operators
Print Operators is another highly privileged group, which grants its members the SeLoadDriverPrivilege, rights to manage, create, share, and delete printers connected to a Domain Controller, as well as the ability to log on locally to a Domain Controller and shut it down. If we issue the command whoami /priv, and don't see the SeLoadDriverPrivilege from an unelevated context, we will need to bypass UAC.
Confirming Privileges
Checking Privileges Again
The UACMe repo features a comprehensive list of UAC bypasses, which can be used from the command line. Alternatively, from a GUI, we can open an administrative command shell and input the credentials of the account that is a member of the Print Operators group. If we examine the privileges again, SeLoadDriverPrivilege is visible but disabled.
It's well known that the driver Capcom.sys contains functionality to allow any user to execute shellcode with SYSTEM privileges. We can use our privileges to load this vulnerable driver and escalate privileges. We can use this tool to load the driver. The PoC enables the privilege as well as loads the driver for us.
Download it locally and edit it, pasting over the includes below.
Next, from a Visual Studio 2019 Developer Command Prompt, compile it using cl.exe.
Add Reference to Driver
Next, download the Capcom.sys driver from here, and save it to C:\temp. Issue the commands below to add a reference to this driver under our HKEY_CURRENT_USER tree.
The odd syntax \??\ used to reference our malicious driver's ImagePath is an NT Object Path. The Win32 API will parse and resolve this path to properly locate and load our malicious driver.
Verify Driver is not Loaded
Using Nirsoft's DriverView.exe, we can verify that the Capcom.sys driver is not loaded.
Verify Privilege is Enabled
Run the EnableSeLoadDriverPrivilege.exe binary.
Verify Capcom Driver is Listed
Next, verify that the Capcom driver is now listed.
Use ExploitCapcom Tool to Escalate Privileges
To exploit the Capcom.sys, we can use the ExploitCapcom tool after compiling with it Visual Studio.
This launches a shell with SYSTEM privileges.
Alternate Exploitation - No GUI
If we do not have GUI access to the target, we will have to modify the ExploitCapcom.cpp code before compiling. Here we can edit line 292 and replace "C:\\Windows\\system32\\cmd.exe" with, say, a reverse shell binary created with msfvenom, for example: c:\ProgramData\revshell.exe.
The CommandLine string in this example would be changed to:
We would set up a listener based on the msfvenom payload we generated and hopefully receive a reverse shell connection back when executing ExploitCapcom.exe. If a reverse shell connection is blocked for some reason, we can try a bind shell or exec/add user payload.
Automating the Steps
Automating with EopLoadDriver
We can use a tool such as EoPLoadDriver to automate the process of enabling the privilege, creating the registry key, and executing NTLoadDriver to load the driver. To do this, we would run the following:
We would then run ExploitCapcom.exe to pop a SYSTEM shell or run our custom binary.
Clean-up
Removing Registry Key
We can cover our tracks a bit by deleting the registry key added earlier.
Server Operators
The Server Operators group allows members to administer Windows servers without needing assignment of Domain Admin privileges. It is a very highly privileged group that can log in locally to servers, including Domain Controllers.
Membership of this group confers the powerful SeBackupPrivilege and SeRestorePrivilege privileges and the ability to control local services.
Querying the AppReadiness Service
Checking Service Permissions with PsService
We can use the service viewer/controller PsService, which is part of the Sysinternals suite, to check permissions on the service. PsService works much like the sc utility and can display service status and configurations and also allow you to start, stop, pause, resume, and restart services both locally and on remote hosts.
This confirms that the Server Operators group has SERVICE_ALL_ACCESS access right, which gives us full control over this service.
Checking Local Admin Group Membership
Modifying the Service Binary Path
Let's change the binary path to execute a command which adds our current user to the default local administrators group.
Starting the Service
Starting the service fails, which is expected.
Confirming Local Admin Group Membership
If we check the membership of the administrators group, we see that the command was executed successfully.
Confirming Local Admin Access on Domain Controller
From here, we have full control over the Domain Controller and could retrieve all credentials from the NTDS database and access other systems, and perform post-exploitation tasks.
Retrieving NTLM Password Hashes from the Domain Controller
Last updated