Windows Service

Why do adversaries use Windows Service?

Windows services are imperative to the normal functions of the operating system. They are common binaries that run in the background and are typically not cause for alarm when executed. Since Windows services already exist on the system, an adversary who is able to modify or install a new service is less likely to draw attention to their activities than an adversary who installs and runs an unknown binary or spawns a command from a command or scripting interpreter.

Outside of assisting in concealing malicious activity, Windows services typically run automatically during the boot cycle of the operating system and with elevated privileges. This provides the adversary two distinct benefits:

• a means of persistence using an executable under their control that can automatically start and remain on indefinitely
• a reliable means to leverage elevated permissions

MITRE ATT&CK scopes the Windows Service technique to the creation or modification of the services, while the execution of a service falls under our ninth most prevalent technique in 2020, T1569.002: Service Execution. The two techniques rely on each other, but considering them separately allows defenders to think about how threats and detection strategies differ.

In order to achieve service execution, an adversary must first install a new service or modify an existing one, meaning they must have the requisite permissions to do so. The choice between creation and modification is a matter of preference, practicality, and opportunity. When choosing whether to create or modify an existing service, an adversary may consider—or be implicitly bound by—the following criteria:

• Do their tools support service creation and/or modification?
• If a defender might monitor for service creation, could modification offer additional evasion opportunities?
• Would it be more evasive to modify an existing service than to create a new service?
• If an adversary does not have permissions to create or modify a service directly, are any existing services configured in an insecure fashion that would permit tampering and, ultimately, privilege escalation?
• Is service creation easier and less prone to error or system instability?

How do adversaries use Windows Service?

The majority of detections show adversaries using Windows services to establish a persistence mechanism, ensuring that their script or file will continue to run. A common pattern is the use of the Windows Service Control Manager Configuration Tool (sc.exe) to modify or create a service based on the adversary’s needs.

The presence of Windows Service in our top 10 is due almost entirely to a single threat: Blue Mockingbird, an activity cluster we identified that deploys Monero cryptocurrency-mining payloads and leverages Windows services for persistence. Because we counted our top techniques based on the number of times we observed their use, several widespread Blue Mockingbird outbreaks in a few environments caused a large number of Windows services sightings. This is why the Windows Service technique ranks so highly while affecting a relatively small percentage of customers.

Blue Mockingbird used sc config to modify an existing service named wercplsupport to automatically start a malicious DLL named wercplsupporte.dll (an attempt to masquerade by using a slightly different name that defenders might miss):

Another interesting use of Windows services emerged in 2020 as part of a novel technique used by RagnarLocker ransomware. RagnarLocker deployed custom virtual machines to prevent direct analysis of the encryption malware on the endpoint. As part of its setup script, RagnarLocker leverages sc.exe to create the service VBoxDRV using these commands:

Detection

Collection requirements

Command-line monitoring

The use of sc.exe to manually create, register, or modify a service is a good indication of malicious use of Windows services. While there are many methods of creating and modifying services, adversaries still regularly leverage sc.exe to perform service operations.

Adversaries also make use of reg.exe to modify service parameters—for example, to point an existing service to an adversary-controlled executable.

Process monitoring

Much like process command-line parameters, process monitoring is a reliable method for detecting malicious activity when the services in the environment are well known and well documented. Processes with randomly generated names (especially names consisting exclusively of numbers) may indicate malicious services running on the system. For example, Cobalt Strike, our second most prevalent threat, uses seven alphanumeric characters in its service name by default, appearing in telemetry in a manner similar to:\\172.0.0.1\ADMIN$\1a2b3c4.exe

Windows Event Logs

While certain event logs will produce a large number of events and hence a large number of false positives, others would be more reliable in detecting malicious use of Windows services. Windows Event Logs such as 4697, 7045 and/or 4688 will respectively alert on new services and processes being created. In a perfect world, this should be fairly quiet, but depending on the environment, what systems are being monitored, and how often this type of activity occurs, these logs may generate a lot of noise depending on how often software is installed on monitored systems.

Windows Registry

In general, anomalous modifications to the registry are a good indication of malware or, at the very least, suspicious activity. More specifically, modifications to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services may be a good indication of an untrusted or malicious service. As this registry tree updates frequently as an artifact of legitimate user-mode service and driver installations, registry monitoring has the potential to generate a large number of false positives without additional context and baselining.

File monitoring

File monitoring can be a useful data source for observing malicious creation of Windows services, but only if you use it in context with other behavioral identifiers or other specific indicators of malware.

Detection opportunities

While many Windows Service techniques incorporate similar naming conventions or binaries across multiple environments, over time these attributes may and do change. While conventions may help to locate malicious behaviors for a short period of time, it is more important to focus on behavioral patterns than specific commands or names.

You may be able to detect malicious use of Windows services by monitoring for and alerting on the following:

• changes within the Service Control Manager registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
• service binaries loaded from unusual directory paths (e.g., via the PUBLIC or APPDATA)
• anomalous and unique services being created on a single device or across the environment
• suspect creation of a service by the Windows Service Control Manager (e.g., service executables with a low reputation, like those that deviate from an established organizational baseline)

To expand on that last bullet just a bit, one method of assessing executable reputation is to enable the following Microsoft Defender Attack Surface Reduction rule in audit mode: “Block executable files from running unless they meet a prevalence, age, or trusted list criterion”. Executables that fail to meet an established reputation will be logged accordingly.

Weeding out false positives

The installation of benign software may generate a large number of false positives for analysts monitoring Windows Event Logs. Similarly, randomly generated benign files or files created in uncommon directories can make a lot of noise if you’re leveraging a file-monitoring solution. Baselining and enforcing application-control solutions can help reduce false positives associated with both these data sources.

Testing

Start testing your defenses against Windows Service 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 T1543.003: Windows Service. 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: