Event ID 7045 shows that a service was installed in the system. Attackers and administrators both use service installation for persistence, remote execution and software rollout, so context matters. Check the service name, binary path and source host or account where available, and review whether the installation matches approved change activity. It is logged by the Service Control Manager in the System log.
Why Event ID 7045 is a useful detection point
Event ID 7045 is valuable because service creation is a common inflection point in Windows operations and in adversary tradecraft. A new service can be the legitimate start of software deployment, but it can also be used to establish persistence, launch tooling, or execute code with elevated context. Security teams care because the event records an action, not intent, so the surrounding context determines whether it is routine or suspicious.
The most useful interpretation starts with the service name, the binary path, and where the request originated. A normal change window, a known management host, and an approved installer point to routine administration. An unexpected service name, an unusual executable location, or a source account and host that do not match the asset’s change history should immediately raise review priority. That is why 7045 is best treated as a triage signal, not a stand-alone verdict.
When teams build their review process around the Windows Event Log Guide, they can place 7045 alongside the other Windows events that explain what happened before and after the service was installed. That makes it easier to distinguish service rollout from tampering, and it reduces the chance that a single event is over- or under-interpreted.
How attackers and administrators use service installation differently
Administrators often create services to deploy software, monitoring tools, patching agents, backup components, or internal utilities. In those cases the service installation is usually tied to a change record, a deployment source, and a known binary location. Attackers use the same mechanism for persistence because services can survive logoff, run at startup, and sometimes execute under privileged accounts. The technique is attractive precisely because it blends into a normal management action.
The practical difference is not the event itself, but the pattern around it. Legitimate installs usually have a clear chain of custody, such as an approved package, a managed endpoint, and an expected account. Suspicious installs often break one or more of those assumptions. A service created from a temporary folder, a user-writable path, or a remote host that never appears in administration workflows deserves immediate scrutiny, especially if it appears outside maintenance hours or on a sensitive system.
Correlating 7045 with process and network telemetry helps security teams decide whether the service was part of a rollout or part of Sysmon-visible activity such as suspicious process creation, image loading, or lateral movement after initial access.
What to check when 7045 appears unexpectedly
Start with the service configuration itself. Confirm the exact service name, display name, startup type, and binary path, then compare those fields with what your software deployment standards normally generate. Review the source host, the initiating account, and any nearby logon or remote administration activity to understand how the service was created. If the path points to a user profile, temp directory, or other unusual location, treat that as a stronger indicator of abuse than the event alone.
Next, verify whether the installation aligns with approved change activity. If there is no matching ticket, package record, or deployment job, investigate whether the service was created to establish persistence, stage tooling, or support a follow-on action. If the service was installed on multiple hosts, look for a common operator pattern, because repeatable service creation can indicate a coordinated intrusion or a misused automation workflow.
For teams that already collect the SIEM Guide signals, the value of 7045 increases when it is enriched with change data, asset ownership, and known-good deployment baselines. That context turns the event from a raw alert into a decision point.
Risk and Threat Considerations
Service installation is a high-value action because it can turn one-time access into durable access. The same mechanism used for software rollout can also create persistence, enable privilege abuse, or hide malicious execution inside a normal-looking administration flow. The risk rises when teams monitor the event but do not validate the source host, account, or binary path against an approved maintenance process.
Failure mechanism: An attacker or rogue operator creates a service that points to a trusted-looking or user-controlled binary, then relies on startup execution, privileged context, or weak change validation to keep it running.
Impact: The service can provide persistent execution, broaden blast radius, and give defenders a false sense that the activity is routine administration instead of an intrusion path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1543.003 — Create or Modify System Process: Windows Service | Service creation is the core technique behind 7045. |
| Recommendation — Map 7045 hits to T1543.003 and hunt for persistence or startup abuse. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | 7045 is a log-based detection point that needs collection, review, and correlation. |
| Recommendation — Centralise and review service-creation logs with correlated change evidence. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Teams must analyze 7045 with surrounding context to tell routine installs from abuse. |
| CM-3 — Configuration Change Control | Service installation should align to approved change activity and baseline control. | |
| Recommendation — Correlate 7045 with adjacent events and investigate anomalous service installs. Require approved change records for new services and investigate unplanned installs. | ||
Practitioner Guidance
What to prioritise: Treat 7045 as a correlation anchor, not a final verdict. The first question is whether the service install has a matching change record and an expected source host or account; if either is missing, the event deserves escalation.
What to verify: Confirm the service binary path, startup type, and identity under which it runs. Path anomalies and unexpected privilege context are often more informative than the service name itself.
What good looks like: A clean 7045 event usually has a known deployment source, a standard installation path, and nearby activity that fits an approved rollout pattern. When those three do not line up, assume the event may be security-relevant until proven otherwise.
Practitioner takeaway: Event ID 7045 matters because service creation is both a normal admin action and a common persistence technique, so defenders must judge it by provenance and context, not by the event alone.