Service Install Event 7045 is a Windows Security event that records when a service is installed on a system. It is used in logging and intrusion detection to identify new services created for persistence, execution, or remote control, especially when the service binary path or account looks unusual.
What Service Install Event 7045 Tells You
Windows Security event 7045 is a high-value signal because it marks the creation of a service, which can be a legitimate administration action or the first observable step in persistence, execution, or remote control.
The event matters because service creation often outlives the user session that launched it. A service can start at boot, run under a privileged account, and execute even when the original installer, script, or remote tool is gone, so defenders treat 7045 as both an audit record and an intrusion clue.
Why 7045 Is a Common Detection Pivot
Security teams use 7045 to separate routine software deployment from suspicious service creation. The key question is not whether a service was installed, but whether the binary path, service name, start mode, description, or account looks consistent with normal change control.
A 7045 event becomes more interesting when it appears soon after remote logon activity, scripting, a new scheduled task, or other signs of hands-on-keyboard activity. It can also point to persistence techniques that hide in plain sight by registering a service that blends into normal Windows administration.
For detection work, 7045 is most useful when correlated with process creation, account events, and service configuration changes. That context helps distinguish a known deployment from a malicious install that is trying to survive reboots or re-establish control later.
How Analysts Read the Service Details
Not every service install is equally meaningful. Analysts usually review the service name, executable path, startup type, parent process, and the security context under which the service runs, because those fields reveal whether the service is expected infrastructure or an unexpected execution mechanism.
Unusual paths, scripts launched from user-writable locations, services that point to temporary directories, and services created under accounts that do not normally run daemons are common warning signs. A service can also be suspicious when it is installed but designed to remain dormant until a later trigger.
When the service account is itself unusual, the event may expose an identity issue as well as a logging issue. A service created to run under a privileged local or domain account can extend the blast radius of a compromise if the service binary or startup command is malicious.
What To Check After You See 7045
Investigate the host inventory first, then compare the event to approved software deployment records, admin change windows, and vendor installation activity. If the service was not expected, preserve the service configuration, associated executable, and nearby process and authentication telemetry before making changes.
If the service is suspicious but cannot be removed immediately, contain the host, restrict the service account, and block the executable path or parent process where your controls allow it. After remediation, review adjacent events for follow-on persistence, credential use, or service recreation attempts.
When 7045 appears in an incident, it is often worth checking whether the installed service was meant to provide persistence, remote execution, or command and control. That review helps determine whether the service is a benign artifact of administration or the mechanism that anchored the compromise.
Risk and Threat Considerations
Service install events are risky because Windows services are durable by design. An attacker who can register a service may gain a reliable launch point that survives reboots, runs with elevated authority, and blends into routine operating-system activity.
Failure mechanism: A malicious actor creates a service with a misleading name or a suspicious executable path, then uses that service to preserve execution or trigger payloads without needing to re-enter through the original access path.
Impact: The result can be persistence, privilege abuse, hidden remote control, and repeated execution even after the initial compromise is discovered, which is why service-creation telemetry is such a valuable hunting signal.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1543 — Create or Modify System Process | Service installation is a core persistence mechanism covered by this ATT&CK technique. |
| Recommendation — Map suspicious service installs to T1543 and hunt for persistence, execution, and remote control activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | 7045 is a log event that must be reviewed with other audit data to detect abuse. |
| Recommendation — Correlate service-install events with surrounding audit records to identify suspicious changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Service installation events are part of audit logging that supports detection and investigation. |
| Recommendation — Centralize and review Windows service creation logs to spot unauthorized persistence activity. | ||
Practitioner Guidance
Why practitioners should care: Event 7045 is one of the clearest Windows records that a new execution primitive has been introduced. Treat it as a change-control event and a security event at the same time, especially on servers that should have very few service changes.
What to watch for: Prioritize services installed from unusual directories, created by non-administrative workflows, or paired with unexpected service accounts. Correlate the event with nearby authentication, process, and task activity to decide whether the install was approved or adversarial.
Practitioner takeaway: The best value from 7045 comes from correlation, not isolation, because the event is most useful when it is tied to a service account, an execution path, and a change story you can verify.
Related resources from NHI Mgmt Group
- How should security teams handle a supply-chain malware event that runs during npm install?
- Who is accountable when an LLM denial-of-service event is triggered by a legitimate user or service account?
- Who is accountable when an intrusion becomes a service outage and data theft event?
- What breaks when a Homebrew formula writes service files and configuration directly into the main install directory?