☑️Windows Group Privileges
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
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.
This group also permits logging in locally to a domain controller.
We can use this PoC to exploit the SeBackupPrivilege, and copy this file. First, let's import the libraries in a PowerShell session.
Import-Module .\SeBackupPrivilegeUtils.dll
Import-Module .\SeBackupPrivilegeCmdLets.dllAre the privileges enabled?
PS C:\htb> 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 DisabledIf the privilege is disabled, we can enable it with Set-SeBackupPrivilege.
Copying a protected file
Now we can read it with cat or type.
Copying NDTS.dit
Because we can log into the DC, we can try reading the NTDS.dit file which has all the NTLMv2 hashes for AD accounts. 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.
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.
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.).
Using 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.
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.). Aside from monitoring for these commands being run, an organization could take things a step further and restrict the execution of specific commands using fine-tuned AppLocker rules. For an organization with a tight security budget, leveraging these built-in tools from Microsoft can offer excellent visibility into network activities at the host level. Most modern enterprise EDR tools perform detection/blocking but can be out of reach for many organizations due to budgetary and personnel constraints. This small example shows that security improvements, such as network and host-level visibility, can be done with minimal effort, cost, and massive impact.
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.
We can query Windows events from the command line using the wevtutil utility and the Get-WinEvent PowerShell cmdlet.
We can also pass credentials into this tool:
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.
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.
Lets do it step by step
Step 1: Generating custom DLL
We can generate a malicious DLL to add a user to the domain admins group using msfvenom.
After running a python web server on our machine we can download it on the Windows machine
Step 2: Loading the DLL
If we run the dnscmd as a non-privileged user this is what we see:
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.
We can confirm that we are indeed part of the DnsAdmin group. Now we run our command:
This will update the registry key. Only the dnscmd utility can be used by members of the DnsAdmins group, as they do not directly have permission on the registry key.
With the registry setting containing the path of our malicious plugin configured, and our payload created, the DLL will be loaded the next time the DNS service is started. Membership in the DnsAdmins group doesn't give the ability to restart the DNS service, but this is conceivably something that sysadmins might permit DNS admins to do. If we do not have access to restart the DNS server, we will have to wait until the server or service restarts.
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. Let's check our current user's permissions on the DNS service.
Step 3: Attempting to restart DNS server
Lets first get our users SID:
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.
Now we can stop and start the DNS service:
The DNS service will attempt to start and run our custom DLL, but if we check the status, it will show that it failed to start correctly (more on this later).
If all goes to plan, our account will be added to the Domain Admins group or receive a reverse shell if our custom DLL was made to give us a connection back.
Step 4: 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.
The first step is confirming that the ServerLevelPluginDll registry key exists. Until our custom DLL is removed, we will not be able to start the DNS service again correctly.
We can use the reg delete command to remove the key that points to our custom DLL.
Once this is done, we can start up the DNS service again.
If everything went to plan, querying the DNS service will show that it is running. We can also confirm that DNS is working correctly within the environment by performing an nslookup against the localhost or another host in the domain.
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.
To set up this attack, we first disabled the global query block list:
Next, we add a WPAD record pointing to our attack machine.
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:
After running the PowerShell script, we should have full control of this file and can take ownership of it.
Next, we can replace this file with a malicious maintenanceservice.exe, start the maintenance service, and get command execution as SYSTEM.
Note: This vector has been mitigated by the March 2020 Windows security updates, which changed behavior relating to hard links.
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.
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.
After downling it we need to paste the following includes:
Next, from a Visual Studio 2019 Developer Command Prompt, compile it using cl.exe.
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.
Using Nirsoft's DriverView.exe, we can verify that the Capcom.sys driver is not loaded.
Run the EnableSeLoadDriverPrivilege.exe binary to enable the privilege:
Next, verify that the Capcom driver is now listed.
To exploit the Capcom.sys, we can use the ExploitCapcom tool after compiling with it Visual Studio.
Alternate Exploitation - Reverse Shell
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.
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.
AutoPwn
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
We can cover our tracks a bit by deleting the registry key added earlier.
Note: Since Windows 10 Version 1803, the "SeLoadDriverPrivilege" is not exploitable, as it is no longer possible to include references to registry keys under "HKEY_CURRENT_USER".
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
Let's examine the AppReadiness service. We can confirm that this service starts as SYSTEM using the sc.exe utility.
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
If we check now the local admins group we will confirm that we are not there:
Let's change the binary path to execute a command which adds our current user to the default local administrators group.
This will modify what will run when the service starts.
If we check the membership of the administrators group, we see that the command was executed successfully.
Domain Compromise
Confirm Local Admin access on DC
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