When is Event ID 7045 logged?

What Event ID 7045 tells you about host activity

Event ID 7045 is one of the clearest Windows signals that a service was created. That matters because service creation is often the moment where legitimate software installation and unwanted persistence look the same at first glance. The useful question is not just whether the event exists, but whether the service name, path, and account context fit an approved change.

In practice, 7045 becomes more valuable when you pair it with the surrounding host timeline. A service install that follows a deployment window is usually routine; one that appears outside normal change control deserves closer inspection. The event helps you narrow the time of introduction, then determine whether the service was intended, who introduced it, and what binary it will launch.

For defenders, the event is strongest as a triage pivot. Use it to identify the service binary, the startup account, and the install time, then compare those details to software rollout records, remote administration activity, and any unusual parent process behaviour. That sequence helps separate normal administration from persistence attempts that rely on services for durability.

Why service-install events are useful for detection

Service installation is attractive to attackers because it creates a durable execution path that can survive logoff and often reboots. A single event can therefore reveal both software deployment and a foothold mechanism, especially when the service name mimics a legitimate product or when the binary path points to a user-writable or unusual location.

It is also useful because many service-based threats are simple at the logging level but high impact operationally. A compromised host can quietly gain a new startup point without generating a dramatic alert, so 7045 often becomes the first evidence that a new executable has been granted system-level execution on the machine. That makes the event useful for both change detection and compromise detection.

Correlate 7045 with surrounding Windows telemetry rather than treating it as proof of maliciousness by itself. Process creation, command-line history, remote execution traces, and later service start events help establish whether the install was part of authorised administration or part of an intrusion path. Windows Event Log Guide is the most direct reference for placing 7045 in the wider Windows logging picture.

How to validate a 7045 event before you treat it as suspicious

Start with the service itself. Confirm the exact service name, display name, image path, and account under which it runs. Then ask whether the path points to a trusted software directory, whether the filename resembles the approved application, and whether the timing aligns with patching, onboarding, deployment, or maintenance windows.

Next, check for signs that the service was created as part of an unauthorised toolset or remote execution chain. A service that appears shortly after lateral movement activity, a credential event, or a new executable dropped into a temporary directory deserves escalation. If the service launches a script host, shell, or another unusual binary for that endpoint role, treat it as a stronger indicator of misuse.

Service-install triage becomes more reliable when you pair it with host instrumentation that shows process lineage and persistence behaviour. Sysmon Guide helps practitioners extend visibility beyond the event itself so they can connect service creation to the process that wrote it and the binary it starts.

Practitioner Guidance

What to verify: Treat every 7045 as a change-verification problem first and a threat-hunting problem second. Verify the install path, run account, and installation time against the approved change record before deciding whether it is suspicious.

Decision rule: If the service binary or account is outside normal deployment patterns, prioritise containment and timeline reconstruction over routine software troubleshooting. If the details match an expected rollout, document the match and move on rather than over-investigating a normal service deployment.

What practitioners underestimate: A benign-looking service name can hide a meaningful foothold, so the surrounding context matters more than the event ID alone. The key judgement is whether the new service expands execution rights or simply reflects a planned installation.

Practitioner takeaway: Event ID 7045 is most useful when you treat it as evidence of newly introduced execution capability on a host, then prove whether that capability was authorised before assuming it was benign.

Related resources from NHI Mgmt Group

• What makes Shai Hulud 2.0 different from a normal npm malware event?
• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?