Which attacks show up in Event ID 7045?

What Event ID 7045 usually means in practice

Event ID 7045 is valuable because it marks a service installation, not just a process launch. That makes it a high-signal artifact for defenders looking for persistence, remote execution, or staged payload execution on Windows hosts. The immediate question is whether the service was expected, who created it, and what binary it points to.

When you see 7045, treat the service name, display name, binary path, account context and installation source as the first clues. A service created from an unusual directory, a temporary path, or a user-writable location is often more concerning than the event itself, because the log records the control point where an attacker tries to turn code into durable execution.

Unexpected services are especially useful for triage because attackers often prefer them when they need execution that survives a logoff, hides in normal admin activity, or runs with higher privilege than an interactive session. That is why 7045 should be read alongside nearby authentication, process creation and service-control events rather than in isolation. Windows Event Log Guide

How attackers abuse service creation

Service installation is a common way to establish persistence on Windows. Once the service exists, it can restart after a reboot, launch automatically, or be triggered by the Service Control Manager without requiring a user to stay logged in. That makes it attractive for both hands-on-keyboard intrusions and automated tradecraft.

It also supports remote execution workflows. An attacker who has admin-level access can drop a binary, create a service to run it, and then use that service as the execution wrapper. In many environments, the service name may look benign while the underlying binary path reveals the real risk. Tracking that path back to the source host, deployment tool or remote admin action is often the fastest way to separate legitimate administration from abuse. MITRE ATT&CK Enterprise Matrix

In practice, the strongest indicators are often the surrounding artefacts: a newly created service followed by a new executable, suspicious PowerShell activity, or lateral movement from another system. Correlating 7045 with those signals helps you decide whether the service is simply a deployment artifact or part of a broader intrusion chain. PowerShell Security Guide

What to check when a 7045 event is suspicious

Start with the service metadata. Compare the service name and display name against your approved baseline, then inspect the binary path for odd quoting, suspicious command-line arguments, LOLBin-style chaining, or references to directories that regular software should not use. If the path points to a script interpreter, launcher or packed executable, that deserves extra scrutiny.

Next, determine whether the installation source makes sense. Legitimate software deployment usually leaves a recognizable trail through endpoint management, installation logs, change tickets or software inventory. If none of those exist, the event should be treated as an unauthorized change until proven otherwise. CISA cyber threat advisories

Finally, confirm whether the new service was used to start child processes, create network connections, or load additional payloads. A service that exists only briefly may still matter if it was enough to run a payload once and then remove itself. Where that pattern appears, containment should focus on the host, the service binary, and any accounts or tools used to create it.

Risk and Threat Considerations

Service-install events can represent direct persistence, privilege abuse, or a foothold for follow-on execution. The risk is not just that a service was added, but that the attacker may have converted one-time access into something that survives reboot and blends into ordinary Windows administration.

Failure mechanism: An attacker with administrative or delegated execution rights creates a service that launches malicious code, often from an unusual path or through a benign-looking service name. If defenders do not correlate 7045 with process, file and account activity, the malicious service can remain trusted long enough to support persistence or further spread.

Impact: The host may continue running attacker-controlled code after reboot, enabling data theft, privilege escalation, lateral movement or repeated payload delivery. In mature environments, this can also create false confidence if the service appears to be a normal operational change.

Practitioner Guidance

What to verify: Check whether the service aligns with a known deployment, the expected binary hash, the creating account and the change window. If any of those are missing, treat the event as suspicious until you can prove otherwise.

Decision rule: If the service path is user-writable, temp-based, script-backed, or otherwise inconsistent with approved software, prioritize containment and triage over assumptions about legitimacy. A service that can execute code is already a security decision point, even before you know the full intrusion story.

Practitioner takeaway: Event ID 7045 is most useful when you treat it as a pivot into execution provenance, not just a log entry, because the service itself is often the mechanism that turns initial access into durable compromise.

Related resources from NHI Mgmt Group

• Which attacks show up in Event ID 4624?
• Which attacks show up in Event ID 4648?
• Which attacks show up in Event ID 4625?
• Which attacks show up in Event ID 4719?