Security teams detect a new service by monitoring service creation events, change-management records, and host-based telemetry for unexpected service names, binaries, startup settings, and account context. Investigate services installed outside approved maintenance windows, especially those that start automatically, run with elevated privileges, or point to unusual file paths or remote locations.
How to spot an unexpected service installation
The most reliable detection signal is a new service record that does not line up with an approved change. Look for service-creation telemetry, Windows Event ID 7045 or equivalent Linux service registration events, and correlate them with your change ticketing or deployment records. A service that appears without a maintenance record, or under an unfamiliar account, deserves immediate triage.
What makes a new service suspicious
Not every new service is malicious, but several traits raise confidence that it should be investigated. Pay close attention to services that auto-start, run with elevated privileges, use odd or disguised names, or point to binaries in user-writeable, temporary, or network locations. These patterns often indicate persistence, unauthorized software installation, or abuse of trusted startup mechanisms.
Service context matters as much as the service name. Review the binary path, command line, start type, recovery actions, and the account used to run the service. Compare those details to the host’s normal role: a workstation service that looks like a server daemon, or a business app service that launches from an uncommon directory, is often a stronger signal than the creation event alone.
How to confirm whether the install was legitimate
Use a three-part validation approach: first, verify the creation time against a change window; second, identify the parent process or deployment tool that created the service; third, check whether the binary, signer, and service account match your standard build or software distribution pattern. If the service came from an approved installer, patch workflow, or endpoint management action, the event may be expected. If not, treat it as potential unauthorized persistence.
Persistence Techniques Guide is useful here because service creation is a common persistence mechanism, and the surrounding artifacts often reveal whether the service was added for administration or for covert foothold retention. For broader discovery and exposure review, Attack Surface Management Guide helps teams connect a new service to asset inventory gaps and unexpected exposure.
Risk and Threat Considerations
An unexpected service install can be a persistence foothold, not just an administrative mistake. Attackers and unauthorized operators often prefer services because they can survive reboots, start automatically, and inherit trusted operating context on the host.
Failure mechanism: The control fails when service creation is allowed without timely monitoring, so a new binary, startup setting, or run-as account is established before anyone validates the change. Services created from unusual paths or remote payloads can hide inside normal administration activity.
Impact: The host may gain a durable execution path that supports privilege escalation, credential access, lateral movement, or repeated re-entry after remediation. If the service runs as a privileged account, the blast radius can extend well beyond the original endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1543.003 — Create or Modify System Process: Windows Service | Services are a common persistence mechanism on Windows hosts. |
| Recommendation — Map unexpected service creation to T1543.003 and hunt for related persistence activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | New services are detectable adverse events requiring host monitoring. |
| Recommendation — Monitor host service creation events and alert on unapproved installations. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Service creation should be captured in logs and reviewed for unauthorized changes. |
| Recommendation — Centralize and review service-install telemetry for unexpected changes. | ||
| NIST SP 800-53 Rev 5 | CM-03 — Configuration Change Control | Service installs are configuration changes that should be authorized and tracked. |
| AU-12 — Audit Record Generation | Service creation events must be generated for later detection and investigation. | |
| Recommendation — Require approved change control for service installation and modification. Ensure service-creation events are audited and forwarded to monitoring. | ||
Practitioner Guidance
What to verify: Confirm the service owner, the creation source, the binary hash, the signer, and the service account before classifying the event as benign. A service is much more concerning when its executable path is outside standard software locations or its start mode was changed outside a normal deployment pipeline.
Decision rule: If the service was created outside an approved change and you cannot quickly prove provenance, isolate the host, preserve telemetry, and inspect the service binary before restarting or deleting it. If the service is tied to a privileged account, treat credential exposure and host compromise as parallel workstreams.
Practitioner takeaway: The key judgment is provenance, not just presence, a new service becomes a security event when it cannot be explained by normal change control and host role expectations.