T1543.003

Windows Service

Also appears in: Privilege Escalation

Windows

What it is

A Windows service is a background program the operating system itself starts and keeps running, managed by the Service Control Manager rather than launched by a logged-in user. Services commonly start automatically at boot, and they frequently run as SYSTEM, which is the highest privilege level on the machine. Both of those properties are what make the mechanism useful to an administrator and equally useful to an attacker.

Creating or modifying a service is a documented, supported operation. It requires administrative rights and nothing beyond that: no exploit, no vulnerability, just a built-in utility or the equivalent API call. The result is persistence and elevated execution in a single step, which is why this technique sits under both Persistence and Privilege Escalation.

How adversaries use it

The straightforward version is to register a new service whose executable is the attacker's payload, set it to start automatically, and let the operating system relaunch it on every boot. The attacker does not need to hold a session open or re-exploit anything, because the machine itself does the work of keeping them resident.

The quieter version is to modify a service that already exists. Repointing an installed service's image path, or swapping the DLL a shared service host loads, leaves the service inventory looking exactly as it did before, with one entry now running something different. This produces no creation event, which is what most service-focused detection is built to watch for.

It also appears during lateral movement. Creating a service on a remote host over administrative shares is a long-established way to get code executing on another machine using only built-in tooling, and it is the mechanism behind several widely used remote-execution utilities.

Detect it in Elastic

Data source: The Service Control Manager's own record of a service being installed, alongside endpoint process-creation telemetry for the utility that requested it and registry-modification telemetry for the service's configuration keys

Key fields

Windows Security Event ID 4697 ("A service was installed in the system") is the primary signal, captured as event.code: "4697", with winlog.event_data.ServiceName, ServiceFileName (the binary the service actually runs, and the field worth reading first), ServiceType and ServiceStartType. The System log records the same installation as Event ID 7045, which matters when Security-log auditing for this category is not enabled. Registry-modification telemetry (Sysmon Event ID 13) covers the modification case that produces no installation event at all, since a service's image path and DLL are held under its own registry key. Sysmon Event ID 1 identifies the process that performed the change.

Prebuilt Elastic rule: Suspicious ImagePath Service Creation

Hunt guidance

Read the service's target before anything else. A service whose binary sits in a temporary, user-writable or profile directory, or which is unsigned, is worth chasing regardless of how ordinary the service name looks. Names are chosen to blend in and are the weakest part of the evidence.

Then establish who created it. Legitimate services arrive with software installations, management agents and update mechanisms, generally under a system or installer context. A service registered by an interactive user account, outside any change window, is the shape that matters.

Do not stop at creation events. Filtering event.code: "4697" finds newly installed services and misses every hijacked one. Pair it with registry-modification telemetry against existing service keys, because a modified service produces no installation record at all, and that is the variant an attacker familiar with the environment will prefer.

Ruling out legitimate activity

Service creation is routine. Software installers, endpoint security agents, backup tools, hypervisor guest additions and enterprise management suites all register services, and a freshly provisioned or recently patched host will register a number of them in a short window.

The distinguishing signal is the combination of target, creator and timing rather than any one of them alone. A service installed by a known installer process, pointing at a signed binary under Program Files, during a maintenance window, is routine. The same service name pointing at a binary in a user-writable path, registered by an interactive account, with no corresponding change record, is not. Building an expectation of which processes install services in the estate is what makes the unusual ones visible, because the volume of benign activity is too high to review case by case.

References

Practice it

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.