T1569.002
Service Execution
Back after a year-long hiatus, Service Execution remains popular among adversaries seeking access to continuously running services.
Pairs with this song #8
Rank
8.5%
Organizations affected
427
threats
Threat sounds
Here’s the deal, my dear: Services like services.exe and svchost.exe enable adversaries to execute malicious code wherever, whenever, often at a high privilege level.
Analysis
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 (services.exe), sc.exe, or 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.
Associated threats
We’ve observed the following threats abusing services:
- Nitol botnet
- Impacket
- Mimikatz
- Cobalt Strike
- CrackMapExec
Take Action
Strong application control enforcement (e.g.. Windows Defender Application Control) will ultimately help security teams increase the level of control they have over what gets installed in their environment. In turn, this will make it more difficult for adversaries to install or run new services. Application control solutions impose a lot of upfront costs, as security and IT departments have to sort out what is and should be allowed in an environment, but the benefits pay off in the long term. Further, limiting user permissions and access can limit the number of accounts capable of conducting impactful service execution.
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Process monitoring
Since malicious services almost always spawn as a child process of services.exe, it’s critically important that security teams are able to observe processes and process relationships in order to build detection for malicious Service Execution.
Command monitoring
As is often the case, command lines are another telling source of telemetry for identifying malicious service execution. Many of the detection analytics we leverage to uncover Service Execution include a command-line component.
Module monitoring
It may be helpful to monitor for DLL loads in order to identify when a service DLL loads in the context of a shared svchost.exe process.
Driver monitoring
Driver loads are sometimes logged in a context separate from module loads. Drivers are loaded into the System process and do not follow the typical parent/child process relationship that user-mode processes have.
Service monitoring
At the risk of stating the obvious, tracking the services running in an environment will give security teams a big picture view of service execution. Most of them will be benign, which is why it’s important to have a good grasp on the services you’d expect to see running at any given time in your environment.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Endpoint Detection and Response (EDR) tooling
As is the case with nearly every technique in this report, a good EDR tool will provide a rich array or relevant telemetry that security teams can use to observe and detect malicious services.
Sysmon Event ID 7: Image loaded
Sysmon Event ID 7 is a great collection source for security teams seeking to gain visibility into DLL loads, and, therefore, it might be useful in cases where an adversary leverages a DLL to execute a service.
Sysmon Event ID 6: Driver loaded
Sysmon Event ID 6 captures context including the driver file path, hash, and signer information.
A note on Linux systems
/var is a directory for storing variable data files (i.e., log files, transient files, temporary files, and more). For many Linux services, /var/log is the default location to place application or service specific logs. Depending on how the service or application is configured, these log files can have detailed messages about the running state of the service or application, warnings or errors that may have occurred, or information about how it was configured when it started. The systemd journal is another great source of log data for services on Linux systems.
Detection opportunities
We have 33 detection analytics that look for different flavors or Service Execution, although just 13 of them detected an actual threat in 2022. The following pseudo-detector has detected the most Service Execution-related threats across our customer base by far. Given how frequently Service Execution co-occurs with other techniques, you may recognize this detection opportunity from the Windows Command Shell section of this report.
Service Control Manager spawning Command Shell
This pseudo detector looks for instances of services.exe spawning cmd.exe along with a corresponding `echo` or `/c` command. .
parent_process == ‘services.exe’
&&
process == ‘cmd.exe’
&&
command_includes (‘echo’ || ‘/c’)Weeding out false positives
False positives most often involve new programs in which the installation script takes some liberties with how it installs or upgrades software. Games are frequent offenders in this respect. Approaches for filtering on legitimate programs could include excluding specific “known good” hashes from detection analytics. Depending on the environment, it may make sense to take a broader approach of excluding .bat scripts altogether, especially if their inclusion causes too much noise.
Testing
Start testing your defenses against Service Execution using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View atomic tests for T1569.002: Service Execution. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using an elevated Command Prompt:
sc.exe create "AtomicService2" binPath= "C:\WINDOWS\system32\fxssvc.exe" type=own start=autoIn addition to the above atomic, which is technically mapped to T1543.003: Windows Service, the following will highlight just service creation. VSS is a built-in SERVICE_USER_OWN_PROCESS service with a start mode of “Manual”. This simple test will start the service, resulting in vssvc.exe spawning as a child process of services.exe.
Start-Service -Name VSS
Last but not least, the following is a simple test that will start BITS, a built-in SERVICE_WIN32_SHARE_PROCESS service with a start mode of “Manual”, resulting in qmgr.dll (the BITS service DLL) loading into svchost.exe (command line: C:\Windows\System32\svchost.exe -k netsvcs -p -s BITS).
Start-Service -Name BITS