Why do adversaries abuse Service Execution?
All production operating systems have one thing in common: a mechanism to run a program or service continuously. On Windows, such a program is referred to as a “service,” and in the Unix/Linux world, such a program is often referred to as a “daemon.” Regardless of what operating system you’re using, being able to install a program so it runs whenever the computer is on has an obvious appeal to adversaries.
In addition to ensuring the program starts after a reboot, this technique usually runs the program with a high privilege level, a win-win for adversaries.
In addition to privilege escalation enabled by weak service permissions or unquoted service paths that can allow an adversary to gain SYSTEM-level privileges, adversaries also abuse Service Execution to persist and move laterally, often via utilities like PSexec and SMBexec or through direct service creation in the Windows Registry.
How do adversaries abuse Service Execution?
In the most general sense, adversaries abuse Service Execution either by installing a service or taking advantage of existing services permissions or abusing the libraries loaded within them. More specifically, we commonly see adversaries leveraging
services.exe to spawn
cmd.exe in order to open highly privileged, interactive shell sessions, execute suspicious batch scripts, or run other processes at the System integrity level. We also detect many forms of suspicious activity associated with
svchost.exe, the host process under which service DLLs are loaded.
In the Windows world, adversaries may use the Windows Service Manager (
net.exe commands to install or manipulate services. All Windows services spawn as child processes of
services.exe (with the exception of kernel drivers). It’s also useful to know that distinct service types have different models of execution. For example, a
SERVICE_USER_OWN_PROCESS service comprises a standalone service executable (EXE) and launches as a child process of
services.exe, whereas a
SERVICE_WIN32_SHARE_PROCESS service comprises a service DLL that’s loaded into either a distinct or shared
svchost.exe process. Additionally, device drivers are traditionally loaded via a
SERVICE_KERNEL_DRIVER service type.
Detection engineers who are familiar with distinct service types are better equipped to scope their detection logic according to the execution options available to an adversary. For example, an adversary might consider executing their malicious service as a
SERVICE_WIN32_SHARE_PROCESS service DLL rather than a standalone binary to stay evasive in cases when DLL loads are likely scrutinized less than standalone EXE process starts. An adversary of sufficient ability may also decide to execute under the context of a device driver, taking into consideration operational needs and perhaps a defender’s inability to discern a legitimate driver from a suspicious one.
In our detection data set, Service Execution commonly co-occurs with Windows Command Shell, Process Injection, and Process Discovery. The reasons for these patterns of co-occurrence are likely that adversaries spawn shells from
services.exe (described above), inject into service processes, and perform discovery actions in search of active services.
We’ve observed the following threats abusing services: