Windows Service Installed via an Unusual Client
Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/02/07"
3integration = ["system", "windows"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator
11privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from
12administrator to SYSTEM.
13"""
14from = "now-9m"
15index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Windows Service Installed via an Unusual Client"
19references = [
20 "https://www.x86matthew.com/view_post?id=create_svc_rpc",
21 "https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697",
22 "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md",
23 "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry",
24]
25risk_score = 73
26rule_id = "55c2bf58-2a39-4c58-a384-c8b1978153c2"
27severity = "high"
28tags = [
29 "Domain: Endpoint",
30 "OS: Windows",
31 "Use Case: Threat Detection",
32 "Tactic: Privilege Escalation",
33 "Data Source: Windows Security Event Logs",
34 "Resources: Investigation Guide",
35]
36timestamp_override = "event.ingested"
37type = "eql"
38
39query = '''
40configuration where host.os.type == "windows" and
41 event.action == "service-installed" and
42 (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and
43 startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and
44 not winlog.event_data.ServiceFileName : (
45 "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe*",
46 "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe",
47 "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe",
48 "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" ",
49 "\"%windir%\\AdminArsenal\\PDQDeployRunner\\service-1\\PDQDeployRunner-1.exe\" ",
50 "\"%windir%\\AdminArsenal\\PDQInventoryWakeCommand\\service-1\\PDQInventoryWakeCommand-1.exe\" ",
51 "\"%SystemRoot%\\nsnetpush.exe\"",
52 "\"C:\\WINDOWS\\ccmsetup\\ccmsetup.exe\" /runservice /ignoreskipupgrade /config:MobileClient.tcf",
53 "\"?:\\SMS\\bin\\x64\\srvboot.exe\"",
54 "%SystemRoot%\\pbpsdeploy.exe"
55 )
56'''
57
58note = """## Triage and analysis
59
60### Investigating Windows Service Installed via an Unusual Client
61#### Possible investigation steps
62
63- Which unusual service-control path did the alert preserve?
64 - Why: Custom Service Control Manager RPC clients can create services without normal attribution; PID 0 is the path this alert needs interpreted.
65 - Focus: `winlog.event_data.ClientProcessId`, `winlog.event_data.ParentProcessId`, `user.domain`, `winlog.computer_name`, and `winlog.event_data.ServiceAccount`.
66 - Implication: escalate when PID 0 attribution combines with a local-account domain and LocalSystem; lower suspicion only when exact host, account, service, and time match a recognized deployment or test explaining zeroed attribution.
67
68- What would the new service execute and how privileged is it?
69 - Why: Event 4697 captures the create-time image path only; later service changes can contradict a clean create-time string.
70 - Focus: `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceType`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceAccount`.
71 - Implication: escalate when the image path is user-writable, temporary, ProgramData, or system-masqueraded; type is driver; start type is boot, system, or disabled; or LocalSystem lacks a matching product. Lower suspicion when all service fields align with one recognized installer, endpoint agent, backup, or deployment tool.
72
73- Which account and logon session requested the service creation?
74 - Focus: service-install `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectLogonId`; 4624 `source.ip` and `winlog.logon.type`; 4648 explicit-credential context.
75 - Implication: escalate when the subject is an unexpected local admin or machine account, origin is remote or rare for the host, explicit credentials appear, or source is absent where remote administration is expected; lower suspicion when subject, logon type, source, and service target fit one recognized management session. Missing 4624/4648 or source fields leaves origin unresolved, not benign.
76 - Hint: on `host.id`, search 4624 where `winlog.event_data.TargetLogonId` equals service-install `winlog.event_data.SubjectLogonId`; search 4648 where `winlog.event_data.SubjectLogonId` matches.
77 - $investigate_0
78 - $investigate_1
79
80- Do surrounding Windows Security records show a contained install or follow-on control activity?
81 - Focus: same-host `event.code`, `winlog.record_id`, `winlog.event_data.ServiceName`, and `winlog.event_data.SubjectLogonId` around `@timestamp`.
82 - Implication: escalate when the same logon session creates multiple services, pairs install with explicit credentials, or shows account changes or failures around service creation; lower suspicion when records stay limited to one expected installer session for the same service. Missing Security telemetry is unresolved, not benign.
83 - Hint: inspect same-session 4697 records for clustered service creation. $investigate_2
84
85- Is the same service-install pattern recurring in a bounded cohort or spreading?
86 - Focus: historical Event ID 4697 records by `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, and `winlog.computer_name`.
87 - Implication: escalate when the same subject creates PID 0 LocalSystem services across unrelated hosts, or service names or paths rotate; lower suspicion when exact service fields recur in the same managed host cohort with a stable subject and no contradictory service metadata.
88 - Hint: query 4697 for the same subject or service fields, group by `winlog.computer_name`, `winlog.event_data.ServiceName`, and `winlog.event_data.ServiceFileName`, then compare PID 0 recurrence. $investigate_3
89
90- Based on the Windows Security evidence, what disposition is supported?
91 - Implication: escalate when PID 0, LocalSystem image, actor/session evidence, or 4697 recurrence does not bind to one recognized workflow; close only when the same fields prove one exact service deployment or test on this host and no contradictory Security evidence remains; if mixed, preserve service-install and logon records, then escalate.
92
93### False positive analysis
94
95- Software deployment, endpoint agent, backup, configuration tools, or authorized service-control/RPC testing can trigger when Service Control Manager behavior leaves PID 0 attribution. Examples include Veeam, PDQ, CrowdStrike installer, SCCM/SMS, nsnetpush, or pbpsdeploy-style patterns. Confirm service name, file, account, subject SID, host cohort, logon session, and test timing align with one product or test workflow, with no contradictory Security records.
96- Before creating an exception, require stable recurrence for the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount`, and host cohort. Avoid broad exceptions on `user.name`, `host.name`, or service name alone.
97
98### Response and remediation
99
100- If confirmed benign:
101 - Reverse any temporary containment and record the exact evidence that confirmed the workflow: service fields, subject and logon IDs, affected host, and recurrence or change context.
102 - Build any exception only from the stable workflow anchors validated above, not from a broad user, host, or service-name match.
103- If suspicious but unconfirmed:
104 - Preserve the alert, original Event ID 4697 record, related 4624/4648 records, `winlog.record_id` values, service configuration, and the service binary named by `winlog.event_data.ServiceFileName` before containment.
105 - Apply reversible containment tied to the findings, such as isolating the host if lateral movement risk is present, restricting the subject account, or disabling the new service after preserving its configuration. Avoid deleting the service or binary until maliciousness and scope are clear.
106- If confirmed malicious:
107 - Preserve the original Event ID 4697 record, related 4624/4648 records, service configuration, service binary, and recurrence evidence before containment or eradication.
108 - Contain the host and affected account based on the service definition, actor/session evidence, and recurrence pattern; weigh host criticality before isolation.
109 - Disable or stop the malicious service after preserving configuration and binary evidence, then remove the service and service binary only after scope is established.
110 - Reset or rotate credentials for the subject account when logon evidence shows misuse, and review other hosts where the same subject or service pattern created LocalSystem services.
111- Post-incident hardening:
112 - Restrict service creation to controlled deployment accounts and administrative hosts.
113 - Retain Audit Security System Extension success logging and enough Windows Security history to correlate 4624, 4648, and 4697 records.
114 - Record the confirmed benign workflow or malicious service pattern so future alerts can compare exact service, subject, and host evidence."""
115
116setup = """## Setup
117
118Audit Security System Extension must be enabled to generate the events used by this rule.
119Setup instructions: https://ela.st/audit-security-system-extension
120"""
121
122[rule.investigation_fields]
123field_names = [
124 "@timestamp",
125 "event.code",
126 "host.id",
127 "winlog.computer_name",
128 "user.id",
129 "user.domain",
130 "winlog.event_data.SubjectUserSid",
131 "winlog.event_data.SubjectLogonId",
132 "winlog.event_data.ServiceName",
133 "winlog.event_data.ServiceFileName",
134 "winlog.event_data.ServiceType",
135 "winlog.event_data.ServiceStartType",
136 "winlog.event_data.ServiceAccount",
137 "winlog.event_data.ClientProcessId",
138 "winlog.event_data.ParentProcessId",
139]
140
141[transform]
142
143[[transform.investigate]]
144label = "Linked logon for the service-install session"
145description = ""
146providers = [
147 [
148 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
149 { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
150 { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
151 ]
152]
153relativeFrom = "now-24h/h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Explicit-credential events for the service-install session"
158description = ""
159providers = [
160 [
161 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
162 { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" },
163 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
164 ]
165]
166relativeFrom = "now-24h/h"
167relativeTo = "now"
168
169[[transform.investigate]]
170label = "Same-session service-install events"
171description = ""
172providers = [
173 [
174 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
175 { excluded = false, field = "event.code", queryType = "phrase", value = "4697", valueType = "string" },
176 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
177 ]
178]
179relativeFrom = "now-1h"
180relativeTo = "now"
181
182[[transform.investigate]]
183label = "Historical 4697 service-install recurrence"
184description = ""
185providers = [
186 [
187 { excluded = false, field = "event.code", queryType = "phrase", value = "4697", valueType = "string" },
188 { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
189 ],
190 [
191 { excluded = false, field = "event.code", queryType = "phrase", value = "4697", valueType = "string" },
192 { excluded = false, field = "winlog.event_data.ServiceName", queryType = "phrase", value = "{{winlog.event_data.ServiceName}}", valueType = "string" }
193 ],
194 [
195 { excluded = false, field = "event.code", queryType = "phrase", value = "4697", valueType = "string" },
196 { excluded = false, field = "winlog.event_data.ServiceFileName", queryType = "phrase", value = "{{winlog.event_data.ServiceFileName}}", valueType = "string" }
197 ]
198]
199relativeFrom = "now-7d/d"
200relativeTo = "now"
201
202[[rule.threat]]
203framework = "MITRE ATT&CK"
204
205[[rule.threat.technique]]
206id = "T1543"
207name = "Create or Modify System Process"
208reference = "https://attack.mitre.org/techniques/T1543/"
209
210[[rule.threat.technique.subtechnique]]
211id = "T1543.003"
212name = "Windows Service"
213reference = "https://attack.mitre.org/techniques/T1543/003/"
214
215[rule.threat.tactic]
216id = "TA0004"
217name = "Privilege Escalation"
218reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating Windows Service Installed via an Unusual Client
Possible investigation steps
-
Which unusual service-control path did the alert preserve?
- Why: Custom Service Control Manager RPC clients can create services without normal attribution; PID 0 is the path this alert needs interpreted.
- Focus:
winlog.event_data.ClientProcessId,winlog.event_data.ParentProcessId,user.domain,winlog.computer_name, andwinlog.event_data.ServiceAccount. - Implication: escalate when PID 0 attribution combines with a local-account domain and LocalSystem; lower suspicion only when exact host, account, service, and time match a recognized deployment or test explaining zeroed attribution.
-
What would the new service execute and how privileged is it?
- Why: Event 4697 captures the create-time image path only; later service changes can contradict a clean create-time string.
- Focus:
winlog.event_data.ServiceName,winlog.event_data.ServiceFileName,winlog.event_data.ServiceType,winlog.event_data.ServiceStartType, andwinlog.event_data.ServiceAccount. - Implication: escalate when the image path is user-writable, temporary, ProgramData, or system-masqueraded; type is driver; start type is boot, system, or disabled; or LocalSystem lacks a matching product. Lower suspicion when all service fields align with one recognized installer, endpoint agent, backup, or deployment tool.
-
Which account and logon session requested the service creation?
- Focus: service-install
winlog.event_data.SubjectUserSid,winlog.event_data.SubjectUserName, andwinlog.event_data.SubjectLogonId; 4624source.ipandwinlog.logon.type; 4648 explicit-credential context. - Implication: escalate when the subject is an unexpected local admin or machine account, origin is remote or rare for the host, explicit credentials appear, or source is absent where remote administration is expected; lower suspicion when subject, logon type, source, and service target fit one recognized management session. Missing 4624/4648 or source fields leaves origin unresolved, not benign.
- Hint: on
host.id, search 4624 wherewinlog.event_data.TargetLogonIdequals service-installwinlog.event_data.SubjectLogonId; search 4648 wherewinlog.event_data.SubjectLogonIdmatches.- $investigate_0
- $investigate_1
- Focus: service-install
-
Do surrounding Windows Security records show a contained install or follow-on control activity?
- Focus: same-host
event.code,winlog.record_id,winlog.event_data.ServiceName, andwinlog.event_data.SubjectLogonIdaround@timestamp. - Implication: escalate when the same logon session creates multiple services, pairs install with explicit credentials, or shows account changes or failures around service creation; lower suspicion when records stay limited to one expected installer session for the same service. Missing Security telemetry is unresolved, not benign.
- Hint: inspect same-session 4697 records for clustered service creation. $investigate_2
- Focus: same-host
-
Is the same service-install pattern recurring in a bounded cohort or spreading?
- Focus: historical Event ID 4697 records by
winlog.event_data.SubjectUserSid,winlog.event_data.ServiceName,winlog.event_data.ServiceFileName,winlog.event_data.ServiceAccount, andwinlog.computer_name. - Implication: escalate when the same subject creates PID 0 LocalSystem services across unrelated hosts, or service names or paths rotate; lower suspicion when exact service fields recur in the same managed host cohort with a stable subject and no contradictory service metadata.
- Hint: query 4697 for the same subject or service fields, group by
winlog.computer_name,winlog.event_data.ServiceName, andwinlog.event_data.ServiceFileName, then compare PID 0 recurrence. $investigate_3
- Focus: historical Event ID 4697 records by
-
Based on the Windows Security evidence, what disposition is supported?
- Implication: escalate when PID 0, LocalSystem image, actor/session evidence, or 4697 recurrence does not bind to one recognized workflow; close only when the same fields prove one exact service deployment or test on this host and no contradictory Security evidence remains; if mixed, preserve service-install and logon records, then escalate.
False positive analysis
- Software deployment, endpoint agent, backup, configuration tools, or authorized service-control/RPC testing can trigger when Service Control Manager behavior leaves PID 0 attribution. Examples include Veeam, PDQ, CrowdStrike installer, SCCM/SMS, nsnetpush, or pbpsdeploy-style patterns. Confirm service name, file, account, subject SID, host cohort, logon session, and test timing align with one product or test workflow, with no contradictory Security records.
- Before creating an exception, require stable recurrence for the same
winlog.event_data.SubjectUserSid,winlog.event_data.ServiceFileName,winlog.event_data.ServiceName,winlog.event_data.ServiceAccount, and host cohort. Avoid broad exceptions onuser.name,host.name, or service name alone.
Response and remediation
- If confirmed benign:
- Reverse any temporary containment and record the exact evidence that confirmed the workflow: service fields, subject and logon IDs, affected host, and recurrence or change context.
- Build any exception only from the stable workflow anchors validated above, not from a broad user, host, or service-name match.
- If suspicious but unconfirmed:
- Preserve the alert, original Event ID 4697 record, related 4624/4648 records,
winlog.record_idvalues, service configuration, and the service binary named bywinlog.event_data.ServiceFileNamebefore containment. - Apply reversible containment tied to the findings, such as isolating the host if lateral movement risk is present, restricting the subject account, or disabling the new service after preserving its configuration. Avoid deleting the service or binary until maliciousness and scope are clear.
- Preserve the alert, original Event ID 4697 record, related 4624/4648 records,
- If confirmed malicious:
- Preserve the original Event ID 4697 record, related 4624/4648 records, service configuration, service binary, and recurrence evidence before containment or eradication.
- Contain the host and affected account based on the service definition, actor/session evidence, and recurrence pattern; weigh host criticality before isolation.
- Disable or stop the malicious service after preserving configuration and binary evidence, then remove the service and service binary only after scope is established.
- Reset or rotate credentials for the subject account when logon evidence shows misuse, and review other hosts where the same subject or service pattern created LocalSystem services.
- Post-incident hardening:
- Restrict service creation to controlled deployment accounts and administrative hosts.
- Retain Audit Security System Extension success logging and enough Windows Security history to correlate 4624, 4648, and 4697 records.
- Record the confirmed benign workflow or malicious service pattern so future alerts can compare exact service, subject, and host evidence.
References
Related rules
- Bypass UAC via Event Viewer
- Potential Privileged Escalation via SamAccountName Spoofing
- Privilege Escalation via Named Pipe Impersonation
- Remote Computer Account DnsHostName Update
- Suspicious SeIncreaseBasePriorityPrivilege Use