Event ID 7045: A new service was installed in the system

Event 7045 comes from the Service Control Manager, the component that owns every Windows service's lifecycle, and it lands in the System log rather than Security because service creation itself is not a security-auditing subcategory the way logons or object access are.

Windows fires it the instant a process calls CreateService successfully, whether that call comes from an MSI installer, sc.exe, PowerShell's New-Service cmdlet, or a remote administration tool pushing a service definition over SMB. There is no auditing policy to enable and no subcategory to turn on: 7045 is unconditional, which is exactly why it is more reliable in practice than its closer Security-log cousin.

That cousin is Event 4697, "A service was installed in the system," which lives under the Audit Security System Extension subcategory. 4697 carries slightly richer subject information (a resolvable SID plus logon ID you can pivot to a 4624 network logon), but it only fires if that specific audit subcategory is enabled, and in most environments it is not.

Auditpol defaults and GPO baselines rarely turn on System Extension auditing, so 4697 sits at zero events on the majority of endpoints SOC teams actually monitor. 7045 is the fallback signal for exactly that reason: it captures the same event class unconditionally, at the cost of a shallower subject (frequently just SYSTEM for built-in components, since the Service Control Manager itself performs the registration on behalf of whoever called it).

The event's fields are what make it useful for triage. ServiceName is the internal name registered with the SCM, which may differ from the friendly display name shown in services.msc. ImagePath is the fully qualified path (plus any command-line arguments) that the SCM will execute when the service starts; this is captured at creation time only, so a later binary swap through registry edits will not regenerate 7045.

ServiceType tells you whether this is a Win32 process service (the common case for applications), a Win32 share-process service (svchost-hosted), or a kernel/file-system driver, and driver installations deserve outsized attention because they run with kernel-level privilege before any user session exists.

StartType records whether the service auto-starts at boot, starts manually, or is delayed-auto, and AccountName shows the security context, typically LocalSystem, LocalService, NetworkService, or a specific domain or local account for services that need particular rights.

A typical SOC shift sees 7045 constantly from entirely benign activity: patch Tuesday installing updated driver services, endpoint security agents re-registering their scanning service after an upgrade, backup software installing a new agent service, or a help desk technician deploying a printer driver package. None of that is noise to filter blindly, because the same event class is how service-based persistence and remote execution both surface.

Ransomware operators frequently drop an encryptor as a service so it survives a reboot and to run under SYSTEM without needing a logged-on user. Remote access trojans install a service stub that respawns the implant if the process is killed.

And red-team and criminal tooling built around PsExec, PAExec, or similar SMB-based execution frameworks work by copying a small service binary to the target's ADMIN$ share, remotely creating a service pointing at it, starting the service to run the attacker's command, and then deleting the service, all of which produces one or more 7045 events with a very recognizable shape: a service name like PSEXESVC (or a randomized variant used by PsExec clones), an ImagePath sitting in a temp or ADMIN$-mapped location, and a start type of Demand Start rather than Auto.

Neighboring events worth pairing with 7045 include 7040 (a service's start type was changed, useful for spotting an attacker flipping a disabled service back to automatic), 7036 (a service entered the running or stopped state, which tells you the newly installed service actually executed), and on hosts with Sysmon deployed, Event ID 6 (driver loaded), which corroborates a kernel-driver 7045 with the actual load and its file hash.

On the network side, a 4624 logon with LogonType 3 immediately preceding a 7045 on the same host is the classic signature of remote service installation, since the SCM connection over SMB requires an authenticated session first. An analyst triaging 7045 should always ask where the corresponding install request came from: local console activity, a software deployment tool like SCCM or Intune, or an unexplained network logon that has no ticket or change record behind it.

The benign baseline for 7045 is high and it is worth knowing what it looks like before hunting through it. Windows Update and cumulative patches routinely install or update driver services (ServiceType 0x1 or 0x2) with ImagePath values under %SystemRoot%\System32\drivers. EDR and antivirus agents re-register their kernel filter drivers and user-mode scanning services on every version bump, usually with a vendor-signed path under Program Files.

Backup, monitoring, and remote-support software (the legitimate kind: Datto, N-able, TeamViewer's host service, and similar) installs its own long-running service the first time it is deployed to a machine, and that single 7045 per install is expected. None of these carry an ImagePath outside standard system or vendor directories, none use ServiceType/StartType combinations that look improvised, and the AccountName is consistently LocalSystem or a documented service account, not a plain domain user.

The judgment calls that separate true from false positive start with ImagePath. A path under %TEMP%, a user's \AppData\Local or \AppData\Roaming, \Users\Public, \ProgramData\ with a randomized subfolder name, or an ADMIN$-relative path is a strong indicator of malicious or attacker-tool installation, because legitimate software vendors do not install service binaries into user-writable, non-persistent locations.

The next tier of suspicion is an ImagePath that is not a path to an executable at all but a command line: cmd.exe /c followed by a one-liner, powershell.exe with -enc, -nop, -w hidden, or -sta flags, or an embedded .DownloadString( / .DownloadFile( call. The Service Control Manager will happily run any command line you register, and attackers use this to avoid dropping a second-stage binary entirely, since the payload lives in the ImagePath string itself and is decoded/executed at service start.

ServiceName is the second signal an analyst should check. PSEXESVC is the literal name Sysinternals PsExec uses by default; PAExec and its many forks generate a similarly formatted but randomized service name, often with a numeric or hex suffix, specifically to dodge a static PSEXESVC allow/deny rule.

Legitimate remote administration through PsExec inside change-managed IT work is common, so ServiceName alone is not a verdict; it needs to be read against whether the account performing the install matches a known admin workflow, whether there is a change ticket, and whether the ImagePath and target host make sense for that admin's normal duties.

ServiceType and AccountName round out the picture. A newly installed kernel driver (0x1 or 0x2) outside of a patch cycle or known EDR/AV vendor is rare in a healthy environment and should always get a second look, because a malicious driver bypasses user-mode defenses entirely and is a hallmark of BYOVD (bring-your-own-vulnerable-driver) privilege escalation and rootkit tooling.

Similarly, a Win32 service installed to run as a specific domain user rather than LocalSystem or one of the built-in service accounts is unusual outside of documented service-account patterns (SQL Server, IIS app pools, and similar), and becomes more suspicious if that account was not provisioned through the normal service-account request process, or if the install originates from a workstation rather than a server or deployment tool.

Finally, a service created by a non-administrative workflow, meaning the Subject in the paired 4697 (when available) or the preceding logon session resolves to an account that has no business installing software, running as LocalSystem, is the pattern most consistent with privilege escalation via service abuse rather than a routine software rollout.