AN1575: Analytic 1575
Detects command-line or API-based creation/modification of Windows Services via `sc.exe`, `powershell.exe`, `services.exe`, or `ChangeServiceConfig`. Looks for creation/modification of autostart services via registry changes, file drops to `System32\services`, and anomalous parent-child process trees.
Analyst context for executives and security teams
AN1575 is a Windows detection analytic focused on identifying creation or modification of Windows Services through command-line tools, PowerShell, service control activity, API use, related registry changes, file drops, and unusual process ancestry. For leaders, this matters because Windows Services are a common operational control point: they can affect persistence, privileged execution, and service availability. The business value is not the analytic name itself, but whether the organization can prove it has reliable endpoint and registry visibility around service changes on Windows systems.
Executive priority
Prioritize this as a control-validation item for Windows endpoint resilience and incident readiness. Security leaders should ask whether service creation and modification events are centrally collected, retained, and reviewed; whether changes to autostart services are tied to approved administration or software deployment; and whether SOC playbooks can quickly distinguish legitimate service management from suspicious persistence-like behavior. This analytic can also support compliance evidence by demonstrating monitoring over privileged system configuration changes, but only if local telemetry and alert handling are validated.
Technical view
For SOC, detection engineering, and IR teams, AN1575 should drive validation of Windows visibility around service creation and modification via sc.exe, powershell.exe, services.exe, and ChangeServiceConfig. The official description also points to registry changes for autostart services, file drops to System32 services-related locations, and anomalous parent-child process trees. Because no ATT&CK tactics or relationships were supplied, teams should avoid over-scoping the analytic and instead test whether expected event sources can reconstruct who changed a service, how it was changed, what executable path was configured, whether startup behavior changed, and what parent process initiated the action.
Likely telemetry
- Windows process creation telemetry including command line and parent-child process relationships
- PowerShell execution telemetry where available
- Windows Service creation and modification events
- Registry telemetry for service configuration and autostart-related changes
- File creation or modification telemetry for service binaries or drops under System32 services-related paths
Detection direction
- Validate alerts for command-line service changes involving sc.exe and PowerShell, including service creation, binary path changes, and startup configuration changes.
- Correlate service configuration changes with process ancestry to identify unusual parents rather than alerting only on the presence of administrative tools.
- Tune for known software deployment, patching, endpoint management, and legitimate administrator workflows to reduce false positives.
- Prioritize autostart service changes because they can materially affect persistence and system behavior.
- Confirm registry and file telemetry coverage; process-only detection may miss API-based or indirect service modification paths referenced by the analytic.
Mitigation priorities
- Establish approved change paths for Windows Service creation and modification, especially on servers and high-value workstations.
- Limit administrative rights needed to create or modify services and review where broad local administrator access exists.
- Baseline legitimate services and service management tooling so detection tuning can focus on unusual service names, paths, parents, accounts, and startup changes.
- Ensure endpoint logging, EDR, registry auditing, and PowerShell visibility are enabled where operationally appropriate.
- Maintain incident response procedures for validating suspicious service changes, preserving service configuration evidence, and safely disabling or reverting unauthorized changes.
Analyst notes and limits
This take is based only on the supplied ATT&CK analytic fields. The object is a detection analytic for Windows and does not include an official detection query, mapped tactics, related techniques, groups, software, or mitigations. The most defensible use is as a coverage and validation guide for monitoring Windows Service creation and modification activity.
No relationship context or official detection logic was supplied, so this summary cannot identify associated techniques, threat actors, software, or confirmed adversary use. Local environment baselines are required to determine severity, false-positive rates, approved administrative patterns, and whether telemetry is complete.
Analytic 1575
Detects command-line or API-based creation/modification of Windows Services via `sc.exe`, `powershell.exe`, `services.exe`, or `ChangeServiceConfig`. Looks for creation/modification of autostart services via registry changes, file drops to `System32\services`, and anomalous parent-child process trees.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 304aac341b7f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1575Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.