The CreateService API is a Windows service management interface used to register a new service entry. It creates a service configuration in the Service Control Manager, including the executable path, start type and service account, so administrators and malware alike can establish persistence or controlled startup behaviour.
What CreateService does in Windows
CreateService is the Service Control Manager entry point that registers a new Windows service definition. It writes the service’s core configuration, including the binary path, startup mode and service account, so the service can be launched later by the operating system rather than by an interactive user.
That makes the API important for both normal administration and abuse. A legitimate installer or operations tool can use it to introduce a managed service, but the same mechanism is also a common persistence path when an attacker can create or replace a service entry.
Why CreateService is dangerous when abused
The security impact comes from the trust Windows places in service entries. A newly created service can run automatically at boot, start under elevated context, or execute a chosen binary path, which gives it durable execution and a strong foothold on the host.
Service creation also changes the access picture, because the selected service account determines which local or domain resources the service can reach. If an attacker can register a service with an over-privileged account, they may inherit more authority than a standard process would have.
For defenders, the relevant question is not just whether a service exists, but whether its executable path, startup configuration and account selection match an approved operational need. That is why service creation is often reviewed alongside endpoint hardening and execution-control policy.
How organisations check exposure to service-creation abuse
Exposure begins with inventory. Organisations need to know which systems allow service creation, which deployment tools legitimately use it, and whether those systems are internet-exposed, remotely administered or broadly delegated to support staff and automation.
Reviewing vendor guidance and Windows configuration baselines helps distinguish expected service deployment from suspicious use. Security teams should compare new or changed services against approved software deployment, patching and remote administration workflows, then investigate any service whose binary path, parent process or account choice does not fit the normal pattern.
Detection is also a configuration problem. Logging and endpoint telemetry should show service creation events, subsequent process launches and any follow-on changes to the service binary or start parameters. OWASP API Security Top 10 is a useful reminder that abuse often hides in ordinary management interfaces, where authorised actions can still be misused for persistence or unauthorised execution.
Remediation and monitoring after suspicious service creation
When a suspicious service is found, the immediate task is to validate whether it was authorised, then remove or disable it if it was not. Organisations should review the executable referenced by the service, the service account assigned to it and any persistence that may have been chained to the new entry.
Because service creation is often used to establish long-lived access, post-incident review should include the service binary, related scheduled tasks, registry changes, adjacent admin activity and any credentials or tokens that were exposed to the service account. If the service was created during compromise, the account and any dependent credentials should be treated as potentially impacted until proven otherwise.
Hardened baselines, constrained administrative rights and application control reduce the chances that hostile code can turn service creation into durable persistence. The control objective is simple: make service registration visible, deliberate and rare.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while 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 — Windows Service | CreateService registers Windows services, which maps directly to service-based persistence and execution abuse. |
| Recommendation — Hunt for service-creation activity and investigate unexpected Windows services as persistence. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Service creation depends on administrative authority and should be tightly limited to approved operators. |
| Recommendation — Restrict service-creation privileges to approved admins and service-deployment tooling. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Service creation and subsequent execution need audit visibility to support detection and investigation. |
| Recommendation — Enable audit logging for service-creation and service-start events to support monitoring and forensics. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The interface is an administrative function that must be restricted to authorised callers to prevent misuse. |
| Recommendation — Enforce function-level authorization on service-management interfaces and administrative APIs. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org