Overview

Service Execution (T1569.002) describes how adversaries abuse the Windows Service Control Manager (SCM) to run malicious commands or payloads — either by creating a new service, modifying an existing one, or using tools like sc.exe, net.exe, or PsExec to trigger execution. This technique lets attackers run code as SYSTEM, persist across reboots, and move laterally to remote hosts by targeting the SCM over the network.

Because service creation and management are everyday administrative activities, malicious use blends easily into normal operations. Detection coverage here is critical: this technique appears in ransomware deployment, APT lateral movement, and post-exploitation frameworks (Cobalt Strike, Impacket) so often that missing it means missing a large portion of serious intrusions.

Attacker Perspective

Attackers use service execution because it provides a high-privilege, low-visibility execution path that survives reboots and is trivially scriptable across remote hosts.

• PsExec lateral movement: PsExec.exe \\target -s cmd.exe /c whoami — PsExec pushes a temporary service (PSEXESVC) to the remote host’s ADMIN$ share and executes commands as SYSTEM without requiring an interactive logon.
• sc.exe remote service creation: sc \\target create backdoor binPath= "cmd.exe /c powershell -enc <base64>" — attackers create a named service pointing to a malicious binary or shell one-liner, then start it immediately with sc start.
• Impacket svcexec/atexec: Impacket’s svcexec.py and similar modules authenticate over SMB, install a transient service, execute a payload, and clean up — leaving a small but detectable artifact window in Windows Event Logs.
• Cobalt Strike service-based execution: Cobalt Strike’s psexec and psexec_psh jump commands create a randomly named service whose binPath contains an encoded PowerShell stager, then delete the service entry after the beacon calls home.

This technique is attractive because it requires only standard Windows APIs, leverages built-in administrative channels (SMB, SCM RPC), and naturally runs payloads as SYSTEM — eliminating the need for a separate privilege escalation step.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Service Operations (Event ID 4697): Logs when a service is installed on the system. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → System → Audit Security System Extension → Success and Failure. This is the single most important event for this technique and is disabled by default on most systems.
• Windows System Event Log — Service Control Manager (Event ID 7045): Also records new service installation; generated by the SCM itself. No additional audit policy required — it is enabled by default in the System log. Provides ServiceName, ImagePath, ServiceType, and StartType fields.
• Windows System Event Log — Service Start/Stop (Event IDs 7036, 7040): Records service state changes. Useful for correlating a newly created service that is started immediately after installation.
• Windows Security Event Log — Process Creation (Event ID 4688): Logs new process creation including full command-line arguments. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line auditing: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1.
• Sysmon Event ID 1 (Process Create): Preferred over Event ID 4688 — captures ParentImage, ParentCommandLine, User, Hashes, and OriginalFileName. Requires Sysmon deployment with a configuration that includes process creation logging.
• Sysmon Event ID 13 (Registry Value Set) and Event ID 12 (Registry Object Create/Delete): Captures writes to HKLM\SYSTEM\CurrentControlSet\Services\ — the registry hive where service configurations are stored. Useful for detecting service creation or modification that bypasses standard SCM API calls.
• Windows Security Event Log — Logon Events (Event IDs 4624, 4625, 4648): Logon Type 3 (network logon) preceding service creation on a remote host is a strong lateral movement indicator. Enable via Advanced Audit Policy → Logon/Logoff → Audit Logon → Success and Failure.
• Windows Security Event Log — Object Access — File System (Event ID 4663): Can capture writes to ADMIN$ or C$ shares (e.g., PsExec dropping PSEXESVC.exe). Requires enabling object access auditing on the specific shares — high volume, so scope carefully.
• Network/Firewall Logs: SMB (TCP 445) and DCE/RPC (TCP 135, dynamic high ports) traffic between workstations is abnormal and is the transport layer for remote service execution. Capture at perimeter and internal segmentation points.
• EDR Telemetry: If available (CrowdStrike, Microsoft Defender for Endpoint, SentinelOne), EDR provides enriched process trees, file write events, and network connection context that significantly accelerates triage — treat as a primary source where deployed.

Key Indicators

• New service with a suspicious ImagePath (Event ID 7045 / 4697): Check the ImagePath (also called ServiceFileName) field for values pointing outside of %SystemRoot%\System32 or %ProgramFiles%, or containing inline shell commands. Examples: ImagePath = "cmd.exe /c powershell -enc <base64>", ImagePath = "%TEMP%\svc.exe", ImagePath = "C:\Users\Public\mal.exe".
• Service name matching known attacker tooling (Event ID 7045 / 4697): Check ServiceName for PSEXESVC (standard PsExec), random short strings (e.g., 4–8 random alphanumeric characters common in Cobalt Strike), or names impersonating legitimate services (e.g., WindowsUpdateSvc, svchost32).
• Transient service lifecycle (Event IDs 7045 → 7036 → 7036 in rapid sequence): A service created, started, and deleted within seconds is a hallmark of PsExec and Impacket. Correlate 7045 (install) with 7036 (running) then 7036 (stopped) within a 60-second window on the same ServiceName.
• services.exe spawning unexpected child processes (Sysmon Event ID 1 / Event ID 4688): services.exe should only spawn known service host processes. Suspicious children include cmd.exe, powershell.exe, wscript.exe, mshta.exe, rundll32.exe, or any binary from a user-writable path. Check: ParentImage = C:\Windows\System32\services.exe AND Image NOT IN approved list.
• sc.exe or net.exe command-line patterns (Sysmon Event ID 1 / Event ID 4688): Watch for: sc create, sc config, sc start in sequence; sc \\<remote_host> indicating remote targeting; net start <servicename> immediately after a new service registration.
• PsExec-specific file indicators (Sysmon Event ID 11 — File Create): PsExec copies itself as PSEXESVC.exe to the target’s %SystemRoot% directory. A file write of PSEXESVC.exe to C:\Windows\PSEXESVC.exe is a near-certain indicator.
• Network logon immediately preceding service creation (Event IDs 4624 Logon Type 3 + 7045): On the target host, correlate a Type 3 logon from an internal source IP within 30 seconds before a new service installation. This is the lateral movement pattern for PsExec and Impacket.
• Encoded or obfuscated ImagePath values (Event ID 7045): Look for Base64 strings in ImagePath using pattern: ImagePath MATCHES ".*-[eE][nN][cC].*[A-Za-z0-9+/]{20,}" or values containing %COMSPEC%, %TMP%, or IEX.

Detection Logic

Rule 1 — Broad: Any new service installed outside standard paths
IF EventID = 7045 OR EventID = 4697
AND ImagePath NOT STARTSWITH ("C:\Windows\System32\", "C:\Windows\SysWOW64\", "C:\Program Files\", "C:\Program Files (x86)\")
AND ImagePath NOT IN [approved_service_allowlist]
THEN alert(severity=MEDIUM)

This catches any service whose binary lives in an unusual location. Expect moderate volume initially — tuning against software deployment tools and known-good third-party services will reduce noise quickly. Cast wide first to build your allowlist.

Rule 2 — Medium: Service ImagePath contains shell execution patterns
IF (EventID = 7045 OR EventID = 4697)
AND (ImagePath CONTAINS "cmd.exe" OR ImagePath CONTAINS "powershell" OR ImagePath CONTAINS "wscript" OR ImagePath CONTAINS "mshta" OR ImagePath CONTAINS "certutil" OR ImagePath CONTAINS "-enc" OR ImagePath CONTAINS "IEX" OR ImagePath CONTAINS "FromBase64")
THEN alert(severity=HIGH)

Targets the “living off the land” pattern where the service binary field is used as a shell command rather than pointing to a legitimate executable. Very low false positive rate — legitimate software almost never embeds a PowerShell or cmd invocation in a service’s binary path. High confidence, high fidelity.

Rule 3 — Medium: services.exe spawning suspicious child processes
IF (EventID = 1 [Sysmon] OR EventID = 4688)
AND ParentImage = "C:\Windows\System32\services.exe"
AND Image IN ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe")
AND NOT (CommandLine CONTAINS known_legitimate_service_patterns)
THEN alert(severity=HIGH)

Service processes inheriting from services.exe and immediately launching an interpreter is the execution pattern for malicious service payloads. Expected volume is low — services.exe spawning cmd.exe directly is rare in healthy environments and almost always warrants investigation.

Rule 4 — Precise: Transient service lifecycle (create → start → delete within 60 seconds)
IF EventID = 7045 [service_name = X, host = H]
AND WITHIN 60 seconds:
EventID = 7036 [service_name = X, state = "running", host = H]
EventID = 7036 [service_name = X, state = "stopped", host = H]
AND NOT ServiceName IN [known_transient_services]
THEN alert(severity=CRITICAL)

This correlation rule directly matches the PsExec and Impacket service execution lifecycle. A service that appears, runs, and disappears within one minute is almost always attacker tooling. False positive rate is very low — this pattern is rare in legitimate operations. Tag immediately for escalation.

Tuning Guidance

• Software deployment tools (SCCM, Intune, PDQ Deploy): These tools routinely create and remove transient services during patch deployment. Exclude by adding ParentImage IN ("ccmexec.exe", "CcmSetup.exe", "PDQDeployRunner.exe") or correlate by time-of-day to approved maintenance windows. Build a named exclusion group so you can audit it quarterly.
• Legitimate remote administration (SysInternals PsExec by IT): Authorized PsExec use by IT or helpdesk staff will trigger PSEXESVC detections. Maintain a named allowlist of SourceUser accounts permitted to use PsExec (User IN [it_admin_accounts]) and suppress only those — do not suppress the event class entirely.
• Antivirus and EDR agents: Security products often install and update services from non-standard paths during agent updates. Identify the specific binary names and paths for your deployed products and add named exclusions tied to ImagePath AND ServiceName together (not either field alone).
• Backup and monitoring agents: Veeam, Backup Exec, and similar products create services in C:\Program Files\<vendor> but also sometimes in non-standard paths during DR operations. Validate with your backup team and exclude specific ServiceName patterns with an associated ticket reference in the exclusion comment.
• Developer workstations running Docker or WSL: These platforms create services (e.g., com.docker.service, WSL-related services) that may trigger path-based rules. Scope your highest-sensitivity rules to servers and exclude workstations in a named group — or add a workstation-specific lower-severity variant.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event from the source log (System Event Log for 7045, Security Log for 4697) on the affected host and confirm the ServiceName, ImagePath, AccountName, and timestamp match what the SIEM alert reported. Do not proceed on a normalized field alone — check the raw event XML to ensure no field was truncated or misparsed.
2. Identify the affected host and account: Determine whether the account that registered the service (AccountName in Event ID 4697) is a standard user, a service account, or a privileged admin. Flag immediately if the account is a Domain Admin, built-in Administrator, or a service account that should never perform interactive operations — this significantly raises severity.
3. Pull the full process chain: Using Sysmon Event ID 1 or EDR telemetry, retrieve the full parent-child process chain for any process spawned by the new service. Specifically look for: what spawned sc.exe or the service binary, what the service binary then executed, and whether any additional processes were launched from the service’s execution context. Capture complete CommandLine values for every node in the chain.
4. Check for files written to disk: Query Sysmon Event ID 11 (File Create) or EDR file events for the 10-minute window around the service creation time on the target host. Focus on writes to C:\Windows\, C:\Users\Public\, %TEMP%, and any path appearing in the service’s ImagePath. Hash any identified files and query VirusTotal or your threat intelligence platform immediately.
5. Identify outbound network connections: Using Sysmon Event ID 3 (Network Connect), EDR network telemetry, or firewall/proxy logs, identify any outbound connections established by the service process or its children within 5 minutes of service start. Look for connections to external IPs, unusual ports (4444, 8080, 443 to unknown destinations), or DNS queries for newly registered or low-reputation domains — these indicate successful C2 establishment.
6. Check for lateral movement originating from this host: On the suspected source host, query Security Event Log for Event ID 4648 (explicit credential use) and Event ID 4624 Type 3 logons sourced from this host on other systems. In your SIEM, search for sc.exe or PsExec activity originating from this host targeting other internal hosts in the same window. If the current alert is on a target host, trace back to the originating source host and repeat this investigation there.
7. Escalation decision: Escalate to a confirmed incident if any of the following are true: the service ImagePath contains encoded or obfuscated commands; a network connection to an external IP was established; the service was created under a privileged account with no corresponding change ticket; lateral movement to additional hosts is confirmed; or the file hash of the service binary returns a malicious verdict. If the service was created by a known deployment tool, the ImagePath points to a signed vendor binary, and a change ticket exists — document and close as a tuning candidate.

Response Playbook

Containment

• Isolate the host — leave it powered on: Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, SentinelOne Disconnect from Network) to cut the host from the network while preserving its running state for memory forensics. Do not shut it down — volatile memory may contain injected shellcode, decrypted payloads, or attacker credentials.
• Disable the affected user account immediately: In Active Directory Users and Computers or via Disable-ADAccount -Identity <username>, disable the account that installed the malicious service. If a service account was used, coordinate with the service owner before disabling to understand downstream impact, but err on the side of disabling unless a business-critical system will immediately break.
• Stop and disable the malicious service: If the host is accessible and the service is still running, execute sc stop <ServiceName> followed by sc config <ServiceName> start= disabled to prevent restart. If the host is isolated via EDR, use the EDR’s remote script execution capability to run these commands.
• Block identified C2 IPs and domains: Take any external IPs or domains identified in Step 5 of the investigation and push blocks to your perimeter firewall, internal DNS sinkhole, and web proxy immediately. Use a named block group/tag in your firewall so the rule can be tracked and reviewed. Notify your threat intelligence team to scan for the same IOCs across all other hosts.
• Invalidate active sessions: Force-revoke all active Kerberos tickets for the compromised account using klist purge on affected hosts or by resetting the account password (which invalidates TGTs). If Azure AD / Entra ID is involved, revoke all refresh tokens via Revoke-AzureADUserAllRefreshToken or the Entra ID portal.

Eradication

• Remove the malicious service: Delete the service registry key at HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName> using sc delete <ServiceName> and confirm the key is removed with reg query HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>. Cross-reference against the offline registry hive if the host is isolated.
• Delete all dropped payloads and attacker tools: Remove every file identified during the file investigation step — the service binary, any staged tools, and any output files written by the attacker. Cross-reference Sysmon Event ID 11 logs for the full time window of attacker presence, not just the service creation event, to ensure you capture all dropped files.
• Reset credentials for all accounts used by the attacker: Reset passwords for the account that created the service AND any accounts whose credentials may have been harvested from the compromised host (LSASS dump, browser credential stores, credential files). This includes service accounts whose passwords are stored on the host.
• Hunt for backdoors on lateral movement targets: For every host the attacker touched (identified in investigation Step 6), run the same service creation query (Event ID 7045) and process execution query (Sysmon Event ID 1 with ParentImage = services.exe) for the full attacker dwell period. Do not declare eradication complete until all lateral targets are cleared.
• Rotate exposed secrets and API keys: If the compromised host ran any applications with stored secrets (application config files, environment variables, Windows Credential Manager), rotate those credentials. Notify the application owners and check audit logs for those services for unauthorized access during the attacker’s dwell time.

Recovery

• Validate cleanliness before reconnecting: Before removing network isolation, run a full EDR scan and confirm no detections. If confidence in the cleanliness of the host is less than high — for example, if the attacker had dwell time longer than 24 hours, or if memory forensics revealed injected processes — reimage the host from a known-good baseline rather than attempting to clean it in place.
• Re-enable the user account only after confirming no persistence: Before unlocking the compromised account, verify that no new scheduled tasks (schtasks /query), startup registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), or additional service entries exist under that account’s context. Reset the password to a new strong credential and enforce MFA if not already required.
• Monitor the affected host and account for 72 hours post-remediation: Create a temporary high-sensitivity watchlist rule in your SIEM scoped to the recovered host’s hostname and the re-enabled account’s UPN for 72 hours. Alert on any service creation, outbound connection to a new external IP, or privileged command execution — treat any hit as a potential re-compromise indicator.
• Document the full incident timeline and close formally: Capture the complete timeline from initial access through containment in your ticketing system, including all IOCs, affected accounts, affected hosts, attacker TTPs, and detection gaps identified. Share a sanitized version with your detection engineering team to update detection rules with newly discovered IOCs and behavioral patterns.
• Review and improve detection coverage based on findings: If the attacker used a technique or tool variant that was not caught by existing rules, draft a new detection rule or update tuning exclusions before closing the incident. Specifically review whether the transient service correlation rule (Rule 4 from Detection Logic) was in place — if not, prioritize deploying it before the next shift change.