Editors’ note: While the analysis and detection opportunities remain applicable, this technique page was written for a previous Threat Detection Report and has not been updated in 2022.
Analysis
Why do adversaries use 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.
How do adversaries use Service Execution?
In the Windows world, adversaries may use the Windows Service Manager (services.exe), sc.exe, or the net.exe commands to install or manipulate services. We often see the manipulation of registry entries with the regsvr32.exe program. These attempts to install or modify a service are associated with T1543.003: Windows Service. While installation or modification of services is closely related to the subsequent execution of a service, MITRE ATT&CK classifies execution as a distinct sub-technique. The rationale for this distinction offers an opportunity to highlight detection domains that are separate and not necessarily dependent upon one another.
When beginning to think about detection opportunities for Service Execution, it’s helpful to understand that all Windows services spawn as child processes of services.exe (kernel drivers being the exception). 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), whereas a SERVICE_WIN32_SHARE_PROCESS service comprises a service DLL that’s loaded into a 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.
Definition
Detection
Collection requirements
Process and command-line monitoring
Because adversaries often manipulate Windows services via built-in system tools, telemetry drawn from process monitoring and command-line parameters can be useful for detecting malicious service use. Sources include EDR tools, Sysmon, or native command-line logging.
DLL load 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. Sysmon Event ID 7 is one available data source for gaining visibility into DLL loads.
Device driver load monitoring
As we noted above, adept adversaries may choose to execute services in the context of a device driver, so it’s important to monitor device driver loads. Windows Defender Application Control (WDAC) can be an effective source of device driver monitoring.
Unix/Linux systems
In addition to monitoring command-line signals, alerting on changes to the configuration files for daemons—and/or their startup scripts—is a powerful tool for detecting this tactic. This includes monitoring for the creation of new files in the /etc/rc directory trees.
For macOS, pay special attention to the use of launchctl and manipulation of files in the Library/LaunchAgents and Library/LaunchDaemon directories, although this leads into a grey area that might fall under the purview of T1569.001 System Services: Launchctl.
Detection opportunities
Malicious service execution often incorporates normally benign tools, so it makes sense to focus detection efforts around the use of legitimate tools under unusual circumstances. For example, alert when a normal utility is invoked from non-standard or untrusted parent processes, or with unexpected command-line arguments. You should also watch for services that spawn interactive shells or that run a program from non-system directories.
One useful analytic that we’ve used to detect service execution involves looking for instances of the Windows Command Processor (cmd.exe) spawning from the Service Control Manager (services.exe), which adversaries use to execute commands as the local SYSTEM account. Looking for /c in the command line may help narrow in on potential interactive sessions. The /c switch carries out the command specified by string and then terminates. Building detector logic accounting for this switch has the potential to cast a wider net for catching interactive commands without regard for the respective filename of cmd.exe.
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 create CMDTestService type=own binPath="cmd /c date /T > C:\Windows\Temp\current_date.txt"
sc start CMDTestService
sc delete CMDTestService
What to expect
The first command will install a service named CMDTestService that will run cmd.exe. The next command will start the service, launching cmd.exe, which will write the current date to C:\Windows\Temp\current_date.txt. The final command deletes the service for cleanup. Note: this technique covers service execution. As such, the telemetry below will reflect only service execution. Service creation and modification is covered by T1543.003. (Note: StartService will fail, with a “The service did not respond to the start or control request in a timely fashion.” Notice; however the artifacts will still execute.)
Useful telemetry will include:
| Data source | Telemetry |
|---|---|
| Data source: Process monitoring | Telemetry: A |
| Data source: Process command-line parameters | Telemetry: Command-line logging will capture the context of what is executed. |
| Data source: VirtualAllocEx, WriteProcessMemory, CreateRemoteThread |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.