« Process Created with an Elevated Token
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Windows Service Installed via an Unusual Client

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Windows Service Installed via an Unusual Client

edit

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.

Rule type: eql

Rule indices:

  • logs-system.security*
  • logs-windows.forwarded*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Data Source: Windows Security Event Logs
  • Resources: Investigation Guide

Version: 218

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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, and winlog.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, and winlog.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, and winlog.event_data.SubjectLogonId; 4624 source.ip and winlog.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 where winlog.event_data.TargetLogonId equals service-install winlog.event_data.SubjectLogonId; search 4648 where winlog.event_data.SubjectLogonId matches.
  • !{investigate{"description":"","label":"Linked logon for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Explicit-credential events for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
  • 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, and winlog.event_data.SubjectLogonId around @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{"description":"","label":"Same-session service-install events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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, and winlog.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, and winlog.event_data.ServiceFileName, then compare PID 0 recurrence. !{investigate{"description":"","label":"Historical 4697 service-install recurrence","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceFileName","queryType":"phrase","value":"{{winlog.event_data.ServiceFileName}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}}
  • 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 on user.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_id values, service configuration, and the service binary named by winlog.event_data.ServiceFileName before 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.
  • 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.

Setup

edit

Setup

Audit Security System Extension must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-security-system-extension

Rule query

edit
configuration where host.os.type == "windows" and
  event.action == "service-installed" and
  (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and
  startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and
  not winlog.event_data.ServiceFileName : (
    "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe*",
    "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe",
    "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe",
    "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" ",
    "\"%windir%\\AdminArsenal\\PDQDeployRunner\\service-1\\PDQDeployRunner-1.exe\" ",
    "\"%windir%\\AdminArsenal\\PDQInventoryWakeCommand\\service-1\\PDQInventoryWakeCommand-1.exe\" ",
    "\"%SystemRoot%\\nsnetpush.exe\"",
    "\"C:\\WINDOWS\\ccmsetup\\ccmsetup.exe\" /runservice /ignoreskipupgrade /config:MobileClient.tcf",
    "\"?:\\SMS\\bin\\x64\\srvboot.exe\"",
    "%SystemRoot%\\pbpsdeploy.exe"
  )

Framework: MITRE ATT&CKTM

« Process Created with an Elevated Token