Event ID 7045 records a service being installed. Attackers often use service installation for persistence, remote execution or to launch payloads with elevated rights. Review the service name, binary path and installation source carefully, because unexpected services on a host usually deserve immediate investigation and containment.
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.
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 | Windows service creation is the core abuse pattern behind Event ID 7045. |
| Recommendation — Map 7045 to service-creation tradecraft and hunt for persistence or remote execution around the new service. | ||
| CIS Controls v8 | CIS-5 — Account Management | Suspicious service installs often hinge on abused admin accounts and delegated change paths. |
| Recommendation — Review who created the service and remove any account access that enabled unauthorized installation. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | 7045 is only useful when service-install audit records are enabled and retained for correlation. |
| CM-5 — Access Restrictions for Change | Unauthorized service creation is a change-control failure as much as a detection issue. | |
| SI-4 — System Monitoring | 7045 requires correlation with process, file and account activity to identify malicious service use. | |
| Recommendation — Ensure service-install events are logged and retained so investigators can reconstruct execution provenance. Restrict who can create services on endpoints and servers to approved change paths only. Correlate service-install events with endpoint telemetry to detect malicious execution chains. | ||
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.