OSCP: Mastering Windows Privilege Escalation Via SC

by Jhon Lennon 52 views

Hey guys! Ever felt like you're so close to popping that box on the OSCP, but you're just stuck in the mud when it comes to Windows privilege escalation? Yeah, we've all been there. One of the most reliable and frankly, underrated methods is leveraging the Service Control Manager (SC). Buckle up, because we're diving deep into how to use sc.exe to potentially go from a low-priv user to SYSTEM. It's a game-changer, trust me.

Understanding the Service Control Manager (SC)

Let's break down what the Service Control Manager (SC) actually is. Think of it as the conductor of an orchestra, but instead of musicians, it's managing Windows services. These services are the unsung heroes that keep everything running smoothly in the background, from handling network connections to managing print jobs. The sc.exe utility is your command-line interface to talk to this conductor. It allows you to query, modify, create, and control Windows services. Understanding this is the first step in exploiting potential vulnerabilities. When we talk about services, we're referring to executable programs that run in the background, often without user interaction. These services are defined with specific configurations, including the user account they run under, their startup type (automatic, manual, disabled), and the executable path. A misconfiguration in any of these settings can open doors for privilege escalation.

Knowing the basics is crucial. Here are some things to keep in mind:

  • Services run as specific users: Most services run under the LocalSystem account (SYSTEM), which has the highest privileges. Some run as NetworkService or LocalService, which have fewer privileges, or even as specific user accounts.
  • Startup types: Services can be configured to start automatically when the system boots, manually when triggered, or be disabled altogether. An automatically starting service running as SYSTEM is a prime target for exploitation.
  • Executable paths: This is the path to the executable file that the service runs. If you can modify this path to point to your own executable, you can potentially execute arbitrary code as SYSTEM.

So why is SC so important for privilege escalation? The answer lies in the potential for misconfigurations. If a service is configured with weak permissions or an insecure executable path, it can be exploited to gain elevated privileges. For example, if a service is configured to run an executable that you can modify, you can replace it with your own malicious executable and then restart the service to execute your code as SYSTEM. We'll explore these scenarios in detail later. For now, just remember that SC provides a powerful interface for managing services, and with great power comes great responsibility...and potential for exploitation!

Enumeration is Key: Gathering Service Information

Before you even think about exploiting anything, you need to gather intel. Enumeration is the name of the game. Your mission, should you choose to accept it, is to find services that you can manipulate. This involves using sc.exe to list services, query their configurations, and identify potential weaknesses. Think of it as reconnaissance before the actual attack. We're looking for services with vulnerabilities like insecure permissions or modifiable executable paths.

Here are some sc.exe commands that you'll become best friends with:

  • sc query: Lists all services on the system. This is your starting point. It gives you a bird's-eye view of all the services running on the machine. The output can be overwhelming, but don't worry, we'll filter it down.
  • sc query type= service: This refines the search to just services.
  • sc query state= all: This is an important command to understand the current state of all services.
  • sc qc <service_name>: Queries the configuration of a specific service. This is where you get the juicy details, like the service's executable path, startup type, and user account. The command retrieves detailed configuration information about a specified service. This includes its binary path, dependencies, start-up type, and the account under which it operates. Analyzing this information is crucial for identifying potential vulnerabilities, such as writable file paths or services running with elevated privileges.
  • sc getdisplayname <service_name>: Retrieves the display name of a service, which can sometimes provide more context or information about the service's purpose.

Let's dive deeper into using these commands effectively. When you run sc query, you'll see a lot of information. The key fields to pay attention to are:

  • SERVICE_NAME: This is the internal name of the service, used by the system.
  • DISPLAY_NAME: This is the user-friendly name of the service.
  • STATE: This indicates whether the service is running, stopped, or in some other state.

Once you have a list of services, you can use sc qc <service_name> to get more detailed information about each service. The output of this command includes:

  • BINARY_PATH_NAME: This is the full path to the executable file that the service runs. This is a critical piece of information, as we'll see later.
  • START_TYPE: This indicates how the service is started (e.g., AUTO_START, DEMAND_START, DISABLED).
  • ACCOUNT_NAME: This is the user account that the service runs under (e.g., LocalSystem, NT AUTHORITY\NetworkService).

Pay close attention to the BINARY_PATH_NAME. If the path contains spaces and isn't enclosed in quotes, it might be vulnerable to a path interception attack. Also, check the ACCOUNT_NAME. If the service is running as LocalSystem, it's a prime target for privilege escalation. Remember, enumeration is not just about running commands; it's about carefully analyzing the output and identifying potential weaknesses. The more information you gather, the better your chances of finding a way to escalate your privileges. So, take your time, be thorough, and don't overlook anything!

Exploitation Techniques: Taking Control

Alright, you've done your homework and found a service ripe for the picking. Now it's time for the fun part: exploitation! There are several ways to exploit misconfigured services, but we'll focus on the most common and effective techniques:

1. Modifying the Service Executable Path

This is a classic technique. If you have write access to the directory containing the service executable, or if the executable path is not properly quoted and contains spaces, you can potentially replace the executable with your own malicious code. Let's break it down:

  • Writable Directory: If the service executable is located in a directory where you have write permissions, you can simply replace the original executable with your own. When the service is restarted, your code will be executed as SYSTEM.
  • Unquoted Path: If the BINARY_PATH_NAME in the service configuration is not enclosed in quotes and contains spaces, Windows will try to execute parts of the path as separate commands. For example, if the path is C:\Program Files\My Service\service.exe, Windows might try to execute C:\Program first, then Files\My, and so on. If you can create a directory or file with one of these names, you can inject your own code.

Here's how to exploit an unquoted path:

  1. Identify a service with an unquoted BINARY_PATH_NAME.
  2. Determine which part of the path is being executed (usually the first word).
  3. Create a directory or file with that name.
  4. Place your malicious executable in that directory or file.
  5. Restart the service (or the entire system) to trigger your code.

2. Modifying Service Permissions

Another powerful technique is to modify the permissions of the service itself. This allows you to change the service's configuration, including the executable path, startup type, and user account. You can use the icacls command to modify service permissions.

Here's how it works:

  1. Use icacls <service_name> to view the current permissions of the service.
  2. Identify the user or group that you can modify permissions for.
  3. Use icacls <service_name> /grant <user>:(GR,GW) to grant yourself the Generic Read and Generic Write permissions.
  4. Use sc config <service_name> binPath= <new_executable_path> to change the service's executable path to your malicious code.
  5. Restart the service to execute your code as SYSTEM.

3. DLL Hijacking

DLL hijacking occurs when a service attempts to load a Dynamic Link Library (DLL) and is tricked into loading a malicious DLL instead of the intended one. This often happens when the service searches for DLLs in directories that are writable by low-privileged users. To exploit this, you need to identify a DLL that the service is trying to load and then create a malicious DLL with the same name in a directory that is searched before the legitimate DLL location.

Example scenario: Exploiting a Writable Path

Let's say you find a service named "MyService" with a BINARY_PATH_NAME of C:\Program Files\MyService\service.exe. You discover that you have write access to the C:\Program Files\MyService directory. Here's how you can exploit it:

  1. Create a malicious executable named service.exe that will execute your code as SYSTEM.
  2. Replace the original service.exe with your malicious service.exe.
  3. Restart the MyService service.

When the service restarts, it will execute your malicious code as SYSTEM, giving you elevated privileges.

Practical Steps and Commands

Let's solidify your understanding with some practical steps and commands. These are the bread and butter of SC exploitation, so get comfortable with them.

Listing Services

To get a list of all services, use the following command:

sc query type= service state= all

This command lists all services, including their names, display names, and states. You can filter the output to focus on specific types of services or states. For example, to list only running services, use:

sc query type= service state= active

Querying Service Configuration

To get detailed configuration information about a specific service, use the sc qc command:

sc qc <service_name>

Replace <service_name> with the actual name of the service. The output will include the BINARY_PATH_NAME, START_TYPE, and ACCOUNT_NAME, which are crucial for identifying vulnerabilities.

Modifying Service Configuration

To modify the configuration of a service, you need to have the necessary permissions. You can use the sc config command to change various service settings, such as the executable path, startup type, and user account. For example, to change the executable path of a service, use:

sc config <service_name> binPath= "<new_executable_path>"

Make sure to enclose the new executable path in quotes if it contains spaces. Also, be careful when modifying service configurations, as incorrect settings can cause the service to fail or even crash the system.

Modifying Service Permissions with icacls

As mentioned earlier, you can use the icacls command to modify service permissions. To view the current permissions of a service, use:

icacls <service_name>

To grant a user or group specific permissions, use:

icacls <service_name> /grant <user>:(GR,GW)

Replace <user> with the user or group you want to grant permissions to, and (GR,GW) with the desired permissions (Generic Read and Generic Write).

Prevention and Mitigation

Okay, so you've learned how to exploit these vulnerabilities. But what about defending against them? Here are some key steps to prevent and mitigate SC-related privilege escalation attacks:

  • Properly Quote Executable Paths: Always enclose service executable paths in quotes to prevent path interception attacks.
  • Secure Directory Permissions: Ensure that service executables are stored in directories with strict permissions, limiting write access to authorized users and groups only.
  • Principle of Least Privilege: Run services under the least privileged account necessary to perform their tasks. Avoid using the LocalSystem account unless absolutely necessary.
  • Regular Security Audits: Conduct regular security audits to identify and address misconfigurations in service settings and permissions.
  • Patch Management: Keep your systems up to date with the latest security patches to address known vulnerabilities in Windows services.
  • Monitor Service Activity: Implement monitoring and logging to detect suspicious activity related to service management, such as unauthorized modifications to service configurations.

Final Thoughts

Mastering Windows privilege escalation via SC is a crucial skill for anyone pursuing the OSCP or working in cybersecurity. By understanding the Service Control Manager, enumerating service configurations, and exploiting common vulnerabilities, you can significantly improve your chances of popping that box and achieving your goals. Remember to always practice in a safe and legal environment, and to use your knowledge for good. Now go out there and conquer those Windows boxes!