Event ID 7045 vs 4697: New Service Installed (Windows)

Event ID 7045 and Event ID 4697 both mean a new service was installed on a Windows machine. 7045 is written to the System log by the Service Control Manager; 4697 is written to the Security log, but only if the "Audit Security System Extension" audit policy is turned on.

Services start without anyone logging on and usually run as SYSTEM, which is why attackers use them for persistence, privilege escalation and PsExec-style lateral movement. This post covers both events, their fields, attacks, Splunk and Sentinel searches, and false positives. For the rest of the IDs worth knowing, see our Windows Event Log IDs cheat sheet.

What is the difference between Event ID 7045 and 4697?

Same activity, two logs, slightly different detail.

4697 also needs Windows 10 or Windows Server 2016 or later. The practical difference is the Subject block. 4697 tells you which account installed the service and gives you a Logon ID, so you can tie the install to the 4624 logon that opened the session and see whether it came over the network from another machine. 7045 is the one you are more likely to already have, because it does not depend on audit policy.

Microsoft's Windows Event Forwarding baseline collects both: 7045 from the System log and 4697 from the Security log, describing them as service install events that include "the name of the service, the image path, and who installed the service." If you can, collect both.

How do you enable Event ID 4697?

Event 4697 belongs to the Audit Security System Extension subcategory. Turn on Success auditing in Group Policy:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > System > Audit Security System Extension

Microsoft recommends Success auditing for this subcategory on domain controllers, member servers and workstations, and says the main reason is 4697. Event volume is low. To check what a host is actually auditing, run auditpol /get /category:* from an elevated prompt.

What fields do 7045 and 4697 record?

The two events carry the same five service details under different names.

A few details from Microsoft's 4697 documentation that change how you read the event:

• Service File Name is "the fully rooted path to the file that the Service Control Manager will execute to start the service", and if command-line parameters are part of the image path, they are logged too. That is where a cmd.exe /c payload shows up.
• The path is recorded at creation only. If someone changes it afterwards, that change is not logged here. You would need process creation events to see what actually ran.
• Service Account is only filled in for user-mode services. Kernel drivers do not log an account, and a user-mode service installed without one runs as LocalSystem.

Service type and start type values

4697 logs these as numbers. Microsoft's table:

What does normal look like?

On a typical workstation, new services come from software installs and updates: agents, drivers, VPN clients and security products. A Win32 own-process service (0x10), automatic start, running as LocalSystem, with a binary under C:\Program Files\ signed by a vendor you recognise, is the shape of most legitimate installs.

Microsoft's own tooling adds noise. Microsoft Defender installs short-lived driver services with names like MpKsl followed by random characters, pointing into C:\ProgramData\Microsoft\Windows Defender\Definition Updates\, and the names change from day to day. Microsoft's Sentinel exploration query for new services filters out that Defender path and the Azure guest agent for the same reason.

What does attacker activity look like?

MITRE ATT&CK tracks malicious services as T1543.003, Create or Modify System Process: Windows Service, under Persistence and Privilege Escalation. Running a payload through a service is T1569.002, System Services: Service Execution, under Execution. Both show up in 7045 and 4697.

PsExec-style lateral movement

Microsoft's PsExec runs a command on a remote machine without installing client software, and ATT&CK describes it as using a temporary Windows service to do it. Its -s option runs the remote process as SYSTEM, and its -r option lets the operator choose the name of the remote service, so do not rely on a fixed service name. Attack tools copy the same approach: connect to the target with admin credentials, register a service that runs the payload, start it, and often delete it afterwards.

The result on the target is a 7045, plus a 4697 if audited. Here is an illustrative 4697:

Account Name:       helpdesk-02
Logon ID:           0x8F21C4
Service Name:       wkmgmt7
Service File Name:  %COMSPEC% /c powershell -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBi...
Service Type:       0x10
Service Start Type: 3
Service Account:    LocalSystem

A service whose "binary" is a command shell running encoded PowerShell is not software. Pair it with a type 3 network logon on the same host a few seconds earlier and you are looking at lateral movement. Our lateral movement guide walks through that pattern end to end.

Persistence and privilege escalation

An attacker who already has admin rights on a host creates a service set to start automatically, pointing at their implant. It survives reboots and runs as SYSTEM. Expect binaries in places a real vendor would not use: C:\Users\Public\, C:\ProgramData\, %TEMP%, or an admin share path.

What Microsoft says to alert on

Microsoft's monitoring recommendations for 4697 apply equally to 7045:

• Any service install on high-value assets, because a new service "should be planned and expected."
• A Service File Name outside %windir%, Program Files or Program Files (x86).
• Service Type 0x1, 0x2 or 0x8 (drivers, which Microsoft says are "very rarely installed"; ATT&CK notes attackers load malicious or vulnerable signed drivers this way).
• Service Start Type 0 or 1 (driver starts) or 4 (installing a service disabled is unusual).
• A Service Account that is not LocalSystem, LocalService or NetworkService.

Microsoft's Sentinel content adds two more: binaries in user-writable folders such as C:\Users\ and C:\ProgramData\, and service names or paths containing known credential-dumping tool names such as mimikatz, mimidrv, pwdump and wceservice.

How do you search for Event ID 7045 and 4697?

Splunk

These assume the Splunk Add-on for Microsoft Windows with classic event log inputs, so the fields are the add-on's (EventCode, Service_Name, Service_File_Name, Service_Type, Service_Start_Type, Service_Account, Account_Name).

New services whose binary lives somewhere suspicious, or that run a shell:

source="WinEventLog:System" EventCode=7045
(Service_File_Name="*\\Users\\*" OR Service_File_Name="*\\ProgramData\\*" OR Service_File_Name="*\\Temp\\*"
 OR Service_File_Name="*ADMIN$*" OR Service_File_Name="*cmd*/c*" OR Service_File_Name="*powershell*")
| table _time host Service_Name Service_File_Name Service_Start_Type Service_Account

Rare services across the estate, from 4697 so you also get the installing account:

source="WinEventLog:Security" EventCode=4697
| stats count dc(host) AS hosts values(host) AS host_list values(Account_Name) AS installed_by BY Service_Name Service_File_Name
| where hosts <= 2
| sort hosts

A service pushed to 800 machines is probably your deployment tool. One on a single server deserves a look.

KQL (Microsoft Sentinel)

Event 4697 is in the Security log, so it lands in SecurityEvent, and the service fields are already columns:

SecurityEvent
| where EventID == 4697
| where not(ServiceFileName contains @"\Windows\System32\" or ServiceFileName contains @"\Program Files")
| project TimeGenerated, Computer, SubjectUserName, ServiceName, ServiceFileName, ServiceType, ServiceStartType, ServiceAccount

Event 7045 is a System log event, so it is not in SecurityEvent. It lands in the Event table if your data collection rule collects the System log, and the fields have to be parsed out of EventData. This follows the pattern in Microsoft's own Sentinel hunting queries:

Event
| where Source == "Service Control Manager" and EventID == 7045
| parse EventData with * 'ServiceName">' ServiceName "<" * 'ImagePath">' ImagePath "<" *
| parse EventData with * 'AccountName">' AccountName "<" *
| where ImagePath has_any (@"\Users\", @"\ProgramData\", @"\Temp\", "powershell", "cmd.exe")
| project TimeGenerated, Computer, UserName, ServiceName, ImagePath, AccountName

If you also want to see who created the service with sc.exe create, search process creation for it. See Event ID 4688.

What are the false positives?

Service creation is low volume, but not zero.

• Software installs. Installers register services. Check the signer, the path and whether the same install happened on other machines at the same time.
• Updates. Some products re-register their service on every update, so the same service name shows up again. A known name with a new path is worth a second look; a known name with the same path usually is not.
• Microsoft Defender and cloud agents. The MpKsl driver services and Azure guest agent services are expected. Suppress them by path, not by name.
• Admin tools. IT teams use PsExec legitimately. Know which accounts and hosts do this, and alert on the rest.
• Driver installs. New hardware brings new drivers. A kernel driver from a hardware vendor is normal; one from a temp folder is not.

When you triage, ask: who installed it, from where (follow the Logon ID), what does the binary path point at, and has this service appeared anywhere else?

Related event IDs

• 7036: a service entered the running or stopped state. Shows the new service actually started.
• 7040: a service's start type changed. Attackers flip existing services to automatic, or disable security tools.
• 4624: the logon that preceded the install. Type 3 from another host suggests remote creation.
• 4688 / Sysmon Event ID 1: process creation, which catches sc.exe create, PowerShell New-Service, and whatever the service launched.
• 1102 / 104: log cleared. Attackers who install a service sometimes clear logs afterwards. See Event ID 1102.

FAQs

What is event ID 7045?

Event ID 7045 means "A service was installed in the system." The Service Control Manager writes it to the System log with the service name, image path, service type, start type and account.

What is event ID 4697?

Event ID 4697 is the Security log version of the same event. It adds the account that installed the service and its Logon ID, and it only appears if the Audit Security System Extension policy is enabled.

Event ID 4697 vs 7045: which should I monitor?

Both. 7045 is there without any audit changes, so it covers hosts with weak audit policy. 4697 tells you who installed the service, which is what you need to investigate.

What is the service creation event ID?

7045 in the System log and 4697 in the Security log. Sysmon has no dedicated service-install event, but its registry events can show writes under HKLM\System\CurrentControlSet\Services, where service configuration lives.

Why don't I see event 4697?

Audit Security System Extension is probably not enabled, or the host is older than Windows 10 or Windows Server 2016. Check with auditpol /get /category:*.

TL;DR

Event ID 7045 (System log, Service Control Manager) and 4697 (Security log, needs Audit Security System Extension) both record a new service: its name, binary path, type, start type and account, with 4697 adding who installed it. Attackers use services for persistence and SYSTEM-level execution (T1543.003, T1569.002), and PsExec-style tools create a temporary service on every target. Alert on binaries outside %windir% and Program Files, shells in the path, driver types, unusual accounts and services seen on one or two hosts. Expect false positives from installs, updates and Defender.

How EpicDetect Can Help

A suspicious 7045 is a starting point, not an answer. Our free cases are single investigations, including ED-105, an endpoint investigation into a macro click on a finance workstation. You work the evidence in the matching console, pin what supports your verdict and ship the IOCs.

Adventures Season Zero is five free episodes as a new analyst in your first week. The Atlas lays out what to learn next across SOC, detection and threat intel, and Security+ prep (a free practice test and a daily drill) sits in the same account.

Start free. No card needed.