Guided lab: a service that starts before you do

One is in System and has existed since long before anyone thought about detection. The other is in Security and needs audit policy.

System log, Event ID 7045, "A service was installed in the system." On by default, everywhere, since Windows 7. It records the service name, the image path, the service type and the account it runs as. If you check one thing on a suspect host, check this.

Security log, Event ID 4697, records the same installation but requires the audit policy for security system extension to be enabled, which it usually is not.

7045 being on by default makes it disproportionately useful. On an estate with no EDR and no Sysmon, it is often the only record that anything was installed at all.

You cannot learn every legitimate path. Think about the properties that hold regardless of which service you are looking at.

Compare where the binary sits against where installed software normally lives, and look at whether the path is quoted.

Three properties that hold without knowing the service:

Location. Legitimate services live in System32, Program Files, or a vendor directory. A service binary in Temp, AppData, ProgramData or a user profile is worth alerting on almost unconditionally, because installers do not put things there.

An unquoted path with spaces. C:\Program Files\My App\svc.exe unquoted is an old and still-present privilege escalation: Windows tries C:\Program.exe first. Attackers exploit it; they also occasionally create it.

The binary itself. Not signed, or signed by someone unexpected, or a copy of a legitimate binary in the wrong directory. That last one is the pattern from the Northwind case: a real Microsoft filename in a directory Microsoft never installs to.

HKLM\SYSTEM\CurrentControlSet\Services, and Autoruns.

The registry. Every service is a key under HKLM\SYSTEM\CurrentControlSet\Services\<name>, with ImagePath for the binary, Start for when it runs, and ObjectName for the account. Start of 2 is automatic, which is what an attacker wants.

Autoruns, on the Services tab, with Microsoft entries hidden.

The registry copy matters for a reason specific to this technique: the registry key can be modified without a 7045 ever firing. Installing a service logs; editing an existing service's ImagePath afterwards does not. An attacker who hijacks a legitimate, unused service rather than creating a new one leaves no 7045 at all, and only a comparison of the current ImagePath against what that service should be will find it.

The question is not "which of these is bad" but "which of these is unusual", and unusual is a property of a fleet rather than of a machine.

Frequency analysis, sometimes called stack counting. Collect service names and image paths from every host, count them, and sort ascending. A service on 1 machine out of 4,000 is interesting; one on 3,998 is Windows.

This is the single most transferable idea in the persistence series. You do not need to know what is bad. You need to know what is rare, and rarity is computable from data you already collect. It works on services, scheduled tasks, Run keys, parent-child process pairs, and almost anything else with a name.

On one machine, without a fleet, you approximate it by comparing against a freshly installed VM of the same build. That is a worse baseline and still catches most things.

Base rule: System 7045 where ImagePath contains \Temp\, \AppData\, \ProgramData\, or \Users\. Add unquoted paths containing spaces. Add services created by a process whose ancestry is a browser, an email client or an Office application.

What is different here: service creation is genuinely rare on a workstation. Run keys and scheduled tasks are written by legitimate software constantly, so those rules live or die on tuning. A new service on a laptop is unusual enough that a much blunter rule survives production.

What is worse here: the ImagePath modification path leaves no creation event. So the rule above catches new services and misses hijacked ones entirely, and the only cover for that is the frequency analysis from Q4. This is the lesson worth carrying: an event-based detection covers the action it logs, and nothing else. Ask what the same outcome looks like without that event, every time.