Overview

Windows Service persistence (T1543.003) allows adversaries to register a malicious executable as a Windows service so it automatically launches every time the system boots or restarts. Because services run under the SYSTEM account by default, attackers also gain an immediate privilege escalation path — turning a foothold into persistent, high-privileged code execution with minimal ongoing effort.

This technique is a staple of ransomware groups, APT actors, and commodity malware alike because it survives reboots, blends into a noisy list of legitimate services, and is trivially simple to implement. Every security team needs reliable detection here: a missed malicious service can quietly phone home or execute payloads for weeks before any other indicator surfaces.

Attacker Perspective

Attackers abuse the Windows Service Control Manager and its supporting interfaces to plant persistent execution that survives reboots and inherits SYSTEM privileges without requiring ongoing user interaction.

• sc.exe for rapid deployment: Attackers use built-in tooling — e.g., sc.exe create MalSvc binPath= "C:\Windows\Temp\payload.exe" start= auto — to register a service in seconds, requiring only local administrator rights.
• Registry direct-write for stealth: Tools like Metasploit’s Meterpreter write service configuration keys directly under HKLM\SYSTEM\CurrentControlSet\Services\, bypassing sc.exe and avoiding process-creation telemetry from that utility.
• BYOVD driver deployment: Threat actors drop a legitimate but vulnerable signed driver (e.g., HW.sys, mhyprot2.sys) and register it as a kernel-mode service using sc.exe create or CreateServiceW() to achieve ring-0 code execution and disable EDR.
• Masquerading as legitimate services: APT29 and similar groups register services with names like Google Update but point the binary path to an attacker-controlled executable outside the legitimate Google installation path, relying on analyst familiarity to avoid scrutiny.

This technique is attractive because it requires no exploitation of a new vulnerability, leverages built-in OS functionality that cannot be disabled, and the sheer volume of legitimate services on any Windows system provides natural camouflage.

Detection Strategy

Required Telemetry

• Windows System Event Log — Event ID 7045 (New Service Installed): Generated by the Service Control Manager whenever a new service is created. Enabled by default. Confirm it is collected by your SIEM by checking for Source = Service Control Manager in your System log pipeline. Contains ServiceName, ImagePath, ServiceType, StartType, and AccountName.
• Windows System Event Log — Event ID 7040 (Service Start Type Changed): Fires when an existing service’s start type is modified (e.g., changed to AUTO_START). Enabled by default. Critical for detecting modification of existing services.
• Windows Security Event Log — Event ID 4697 (Service Installed): Security-channel equivalent of 7045, providing the SubjectLogonID of the account that created the service. Requires Audit Security System Extension to be enabled: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → System → Audit Security System Extension → Success.
• Windows Security Event Log — Event ID 4624 (Logon Success): Required to correlate remote service creation. Logon Type 3 (network) preceding a 7045 event with matching logon ID indicates remote installation. Requires Audit Logon/Logoff → Success to be enabled.
• Sysmon Event ID 1 (Process Creation): Captures the full command line, parent process, user, and hashes when sc.exe, PnPUtil.exe, or similar utilities run. Deploy Sysmon with a configuration that logs all process creations at minimum. Field ParentImage, CommandLine, User, Hashes.
• Sysmon Event ID 6 (Driver Load): Fires whenever a kernel driver is loaded. Captures ImageLoaded, Hashes, and Signed/Signature fields. Essential for BYOVD detection. Requires Sysmon 13+ and enabling the DriverLoad event in your Sysmon config.
• Sysmon Event ID 13 (Registry Value Set): Captures writes to registry keys including HKLM\SYSTEM\CurrentControlSet\Services\. Required for detecting service creation via direct registry manipulation. Enable by adding a Sysmon rule targeting TargetObject containing CurrentControlSet\Services.
• Windows Registry Audit (Event ID 4657): Native Windows audit of registry modifications. Enable via Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Registry → Success/Failure, then set auditing on HKLM\SYSTEM\CurrentControlSet\Services via regedit or Group Policy.
• EDR Process and File Telemetry: If available, EDR tools (CrowdStrike, Defender for Endpoint, SentinelOne) provide parent-child process trees, file write events, and network connections associated with service executables — use these to enrich any alert from the above sources.

Key Indicators

• Suspicious ImagePath locations: In Event ID 7045 or 4697, check ImagePath (also called ServiceFileName in some SIEMs) for paths outside normal service directories. Legitimate services almost always live under C:\Windows\System32\, C:\Windows\SysWOW64\, or vendor-specific Program Files paths. Flag any service with ImagePath pointing to C:\Users\, C:\Temp\, C:\ProgramData\, C:\Windows\Temp\, or any path containing AppData.
• sc.exe with suspicious arguments: In Sysmon Event ID 1, look for Image ending in \sc.exe and CommandLine containing create or config alongside binPath= pointing to writable user paths. Example pattern: CommandLine CONTAINS "sc" AND CommandLine CONTAINS "create" AND CommandLine CONTAINS "binPath".
• Unusual parent process for sc.exe: Legitimate software installers call sc.exe from msiexec.exe, setup.exe, or elevated console hosts. Alert when ParentImage for sc.exe is cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, or any browser process — these indicate script-based or LOLBin-assisted service creation.
• Service name masquerading: In Event ID 7045, compare ServiceName against a known-good baseline. Watch for names that closely mimic legitimate services (e.g., Google Update with an ImagePath not under C:\Program Files (x86)\Google\Update\, or Windowss Update with a double letter).
• Service created by a non-SYSTEM, non-installer account: In Event ID 4697, SubjectUserName should typically be SYSTEM, a dedicated service account, or a known software installer account. Alert when it is an interactive user account or a service account not associated with software deployment.
• Remote service creation correlation: Event ID 4624 with LogonType = 3 from an external IP, followed within 30 seconds by Event ID 7045 on the same host with a matching TargetLogonID / SubjectLogonID, strongly indicates remote service installation (common in lateral movement via PsExec or Impacket).
• Driver load with known-bad hash: In Sysmon Event ID 6, check Hashes against known-vulnerable or known-malicious driver hashes (e.g., the HW.sys SHA256 values from the Sigma rule above). Also flag any driver load where Signed = false or SignatureStatus != Valid.
• Direct registry write to Services key: In Sysmon Event ID 13 or Windows Event ID 4657, flag writes to TargetObject matching HKLM\SYSTEM\CurrentControlSet\Services\*\ImagePath where the process performing the write is not a known installer or SYSTEM.
• PnPUtil used to add a driver: Sysmon Event ID 1 with Image ending in \PnPUtil.exe and CommandLine containing /add-driver or /install is a strong BYOVD indicator when executed outside of a known patch window.

Detection Logic

Rule 1: New Service Created with Suspicious Binary Path
IF (EventID = 7045 OR EventID = 4697) AND ImagePath MATCHES (C:\Users\* OR C:\Temp\* OR C:\ProgramData\* OR C:\Windows\Temp\* OR *\AppData\*) THEN alert HIGH

This catches the most common attacker pattern of dropping a payload to a writable directory and registering it as a service. Expect low-to-moderate volume; most legitimate services install to System32 or Program Files. Review all results — there are few legitimate reasons for a service binary to live in a user-writable path.

Rule 2: sc.exe Service Creation Launched from Suspicious Parent
IF EventID = 1 (Sysmon Process Create) AND Image ENDSWITH "\sc.exe" AND CommandLine CONTAINS "create" AND ParentImage IN (cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe) THEN alert HIGH

Targets script-engine or LOLBin-driven service creation, a hallmark of post-exploitation frameworks like Metasploit, Cobalt Strike, and Impacket. Volume will vary by environment — establish a baseline of legitimate installer behaviour and exclude known-good parent/child pairs (e.g., msiexec → sc.exe during software installs).

Rule 3: Remote Logon Immediately Followed by New Service Creation
IF EventID = 4624 AND LogonType = 3 AND NOT SourceNetworkAddress IN (127.0.0.1, ::1) THEN within 30 seconds on same host IF EventID = 7045 AND SubjectLogonID = TargetLogonID from 4624 THEN alert CRITICAL

Directly targets PsExec-style lateral movement where an attacker authenticates over the network and immediately installs a service for execution. This is a high-fidelity rule with low expected false positive volume; legitimate remote software deployments from SCCM or RMM tools should be baselined and excluded by source IP or account name.

Rule 4: Known-Vulnerable or Known-Malicious Driver Load (BYOVD)
IF EventID = 6 (Sysmon Driver Load) AND (Hashes CONTAINS ANY_OF [known_bad_hash_list] OR (Signed = false AND ImageLoaded ENDSWITH ".sys")) THEN alert CRITICAL

Catches BYOVD attacks and outright unsigned driver loading. The known-bad hash list should be maintained from threat intelligence feeds (LOLDrivers project, MSRC advisories). Unsigned driver loads are rare on well-managed endpoints and should always be investigated. Near-zero expected false positives on a healthy fleet.

Tuning Guidance

• Software deployment tools (SCCM, Intune, PDQ, Ansible): These tools legitimately create services during software installation, often with sc.exe called from msiexec.exe or a deployment agent. Build an allowlist of known deployment tool process names and source IPs: ParentImage IN (msiexec.exe, ccmexec.exe, pdqdeploy.exe) or restrict by source subnet for remote service creation alerts.
• RMM and remote support agents (TeamViewer, ConnectWise, Splashtop): These register services during installation and may update them periodically. Exclude by ServiceName and ImagePath for known-good agent paths — but review these exclusions quarterly since attackers abuse RMM tools for persistence themselves.
• Antivirus and security product installation: AV and EDR products register kernel drivers and services. These will fire on Rule 4 if the driver is unsigned in its test build. Exclude by Image or ImageLoaded path matching your known security vendor directories, not by signing status alone.
• Developer machines running Docker, WSL2, or hypervisors: These regularly create and destroy virtual network adapter and storage services. Scope your detection rules to exclude developer OU or machine groups, or add ServiceName IN (vhdmp, vm3dmp, docker-proxy, wsl) exclusions for known-good virtual infrastructure services.
• False masquerade positives on service name checks: Many products legitimately use generic-sounding service names. Instead of alerting on the name alone, always correlate the name with the ImagePath — a Google Update service is only suspicious if the path is not under C:\Program Files (x86)\Google\Update\. Build your rule as a name/path mismatch check rather than a name-only check.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and retrieve the raw event. Pull the original Event ID 7045 or 4697 from your SIEM using the host name, timestamp, and event ID. Confirm the ServiceName, ImagePath, StartType, and AccountName fields are present and match what triggered the alert — rule out ingestion artifacts or field-parsing errors before proceeding.
2. Identify the affected host and the account responsible. From Event ID 4697, note the SubjectUserName and SubjectLogonID; from Event ID 7045 cross-reference with 4624 logs to find the originating session. Flag immediately if the account is a service account, domain admin, or matches a known privileged identity — escalate priority accordingly.
3. Reconstruct the full process chain leading to service creation. Using Sysmon Event ID 1, query for the process that invoked sc.exe or wrote to the Services registry key in the 5 minutes before the alert, filtering by the same host and logon session. Trace the parent chain back at least three levels — look for scripting engines, Office processes, or browser processes as ancestors, which indicate initial access exploitation.
4. Examine the service binary on disk. Using your EDR or a remote query tool (e.g., Get-FileHash via CrowdStrike RTR, Defender Live Response, or Velociraptor), retrieve the hash of the file referenced in ImagePath. Submit the hash to VirusTotal and your internal threat intel platform; also check the file’s creation timestamp against the service registration time to confirm they are tightly correlated.
5. Check for network connections made by the service process. Query your EDR or Sysmon Event ID 3 (Network Connection) for any outbound connections made by the service executable or its child processes within the first 10 minutes of service start. Note any external IPs or domains — resolve them against threat intel and check if they appear in passive DNS or known C2 infrastructure lists.
6. Search for lateral movement originating from this host. Query your SIEM for Event ID 4624 Logon Type 3 events where the SubjectUserName matches the compromised account and the WorkstationName matches the affected host, looking across all destination systems in the 2 hours following service creation. Also search for Event ID 7045 on other hosts with the same ServiceName or ImagePath pattern — Impacket and PsExec attacks often install identical services across multiple targets.
7. Make the escalation decision based on evidence gathered. Confirm incident if: the binary hash is malicious or unknown, the ImagePath points to a non-standard location, network connections to external IPs are observed, or lateral movement is identified. Treat it as benign only if the service creation is fully attributable to a known software deployment in your CMDB, the binary hash matches a known-good vendor file, and no anomalous network activity is observed — document your reasoning either way and update your alert triage notes.

Response Playbook

Containment

• Isolate the host at the network level immediately, but leave it powered on. Use your EDR’s network isolation feature (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or SentinelOne Disconnect) to cut all network access while preserving the in-memory forensic state. Do not reboot — services registered in memory and any injected code will be lost.
• Disable the malicious service to stop re-execution. From an elevated remote session (or via EDR Live Response), run sc.exe config [ServiceName] start= disabled followed by sc.exe stop [ServiceName]. Confirm the service is stopped with sc.exe query [ServiceName] before proceeding.
• Disable or lock the account used to create the service. If a user or service account performed the installation (from Event ID 4697 SubjectUserName), disable it in Active Directory immediately using Disable-ADAccount -Identity [username] or via the AD Users and Computers console. If it is a machine account or SYSTEM, focus on host isolation instead.
• Block identified C2 IPs and domains at the perimeter. Submit any external IPs or domains identified from network connection analysis to your firewall team and DNS sinkhole (e.g., Cisco Umbrella, Infoblox) for immediate blocking. Also push the block to your proxy and web gateway if applicable.
• Revoke active sessions for the compromised account. In Active Directory, reset the account password immediately to invalidate all Kerberos tickets and NTLM hashes. If the environment uses Azure AD or Entra ID, also revoke all active refresh tokens via Revoke-AzureADUserAllRefreshToken or the Entra portal. Notify the account owner out-of-band.

Eradication

• Remove the malicious service registration. Via EDR Live Response or a privileged remote session, run sc.exe delete [ServiceName] to remove the service. Verify removal by checking HKLM\SYSTEM\CurrentControlSet\Services\ in the registry — delete the key manually if sc.exe does not fully remove it.
• Delete the malicious binary and any dropped files. Based on the ImagePath and any file-write events from your EDR, locate and delete the service executable and any associated files (DLLs, configuration files, additional payloads). Search for files with the same hash across your entire fleet using your EDR’s hash search capability to identify other compromised hosts.
• Scan for additional persistence mechanisms on the same host. Run an autoruns sweep (Autoruns for Windows via EDR Live Response, or Velociraptor’s autoruns artifact) to identify any other persistence — scheduled tasks, run keys, WMI subscriptions, or additional services — created in the same timeframe. Remove all identified artifacts.
• Reset credentials for all accounts that touched the affected host. Reset passwords for every account that logged into the host interactively or over the network during the window of compromise (from 4624 logs). If a service account was used, rotate its password and audit all systems where that service account has rights.
• Audit lateral movement targets for the same service or payload. On every host where the compromised account authenticated (identified in investigation step 6), run the same autoruns sweep and hash search. Remove any matching artifacts found and treat those hosts as potentially compromised.
• Rotate any secrets accessible from the compromised host. Check for stored credentials in LSASS, credential manager, or application config files on the host. Rotate any API keys, service account passwords, or certificates that may have been accessible to a SYSTEM-level process on that machine.

Recovery

• Re-image the host if confidence in full eradication is low. If the service process had SYSTEM privileges, ran for an extended period before detection, or if any rootkit or BYOVD driver activity was observed, do not attempt to clean in place — reimage from a known-good baseline and restore data from backup. A confirmed kernel-level compromise cannot be trusted after cleaning alone.
• Verify cleanliness before reconnecting to the network. Before removing network isolation, run a full EDR scan, re-run the autoruns artifact, and confirm no suspicious services, registry keys, or scheduled tasks remain. Have a second analyst review the findings independently before sign-off.
• Re-enable the user account only after full remediation is confirmed. Restore account access only after all persistence has been removed, credentials have been rotated, and the user has been briefed on how the compromise likely occurred. Provide the user with a new device or freshly imaged workstation if their endpoint was the source.
• Monitor the affected host and account for 72 hours post-remediation. Create a temporary, high-sensitivity watchlist rule in your SIEM that alerts on any service creation, registry modification to the Services key, or new outbound connection from the affected host or account for a minimum of 72 hours. This catches re-infection or a second stage that eradication missed.
• Document the full timeline and close with lessons learned. Record the initial alert time, detection gap (time between service creation and detection), all IOCs, affected systems, and response actions taken in your ticketing system. Review whether any detection rules should have fired earlier, update your SIEM exclusion lists and allowlists based on findings, and share relevant IOCs with your threat intel team for platform-wide blocking.