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.
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/LaunchDaemon directories, although this leads into a grey area that might fall under the purview of T1569.001 System Services: Launchctl.
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
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.