DC0060: Service Creation
The registration of a new service or daemon on an operating system.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4697 - Captures the creation of a new Windows service. - Event ID 7045 - Captures services installed by administrators or adversaries. - Event ID 7034 - Could indicate malicious service modification or exploitation. - Sysmon Logs - Sysmon Event ID 1 - Process Creation (captures service executables). - Sysmon Event ID 4 - Service state changes (detects service installation). - Sysmon Event ID 13 - Registry modifications (captures service persistence changes). - PowerShell Logging - Monitor `New-Service` and `Set-Service` PowerShell cmdlets in Event ID 4104 (Script Block Logging). - Linux/macOS Collection Methods - AuditD & Syslog Daemon Logs (`/var/log/syslog`, `/var/log/messages`, `/var/log/daemon.log`) - AuditD Rules: - `auditctl -w /etc/systemd/system -p wa -k service_creation` - Detects changes to `systemd` service configurations. - Systemd Journals (`journalctl -u
Analyst context for executives and security teams
Service Creation is the evidence that a new operating system service or daemon has been registered. For leaders, this matters because services often run with elevated privileges and can survive reboots, making this data component important for validating persistence monitoring, incident scoping, and audit evidence around administrative change control.
Executive priority
Prioritize this as a resilience and governance signal: teams should be able to prove they can see new service registration across managed systems and distinguish approved administrative activity from suspicious changes. Gaps here can weaken incident response timelines, persistence detection, compliance evidence, and confidence in privileged change management.
Technical view
Validate collection for the specific evidence named by ATT&CK: Windows Event IDs 4697, 7045, and 7034; Sysmon Event IDs 1, 4, and 13; PowerShell Script Block Logging Event ID 4104 for New-Service and Set-Service; Linux/macOS daemon and audit logs; systemd journal data; and macOS LaunchDaemons/LaunchAgents plist creation. Because no ATT&CK detection logic or relationship context is supplied, detection engineering should focus on local baselining of expected service creation, service executable paths, registry or configuration changes, and the account/process responsible for the change.
Likely telemetry
- Windows Event Logs for service creation, service installation, and service-related errors or changes
- Sysmon process creation, service state change, and registry modification events
- PowerShell Script Block Logging for New-Service and Set-Service usage
- AuditD and syslog daemon logs covering service configuration changes
- Systemd journal entries for newly created or modified services
Detection direction
- Confirm that service creation events are collected centrally and retained long enough for incident response.
- Baseline approved administrator, deployment, and software update service creation to reduce false positives.
- Correlate new service registration with process creation, command-line/script evidence, account context, and service executable or configuration path.
- Tune for unusual service names, unexpected executable locations, unexpected parent processes, and service changes outside maintenance windows, where local environment data supports those judgments.
- Validate non-Windows visibility separately using AuditD, syslog, systemd journals, and macOS LaunchDaemon/LaunchAgent monitoring rather than assuming Windows service telemetry covers all hosts.
Mitigation priorities
- Establish change control for new services and daemons, including accountable owner, approved path, and expected host scope.
- Restrict who can create or modify services through administrative privilege management and operating system permissions.
- Enable and verify the ATT&CK-listed logging sources before relying on detections or audit reporting.
- Use incident response playbooks that treat unauthorized service creation as a persistence and privilege-risk lead requiring host, account, and executable review.
- Periodically test whether approved monitoring detects benign service creation events in each managed operating environment.
Analyst notes and limits
This object is a data component, not a technique. Its value is as a coverage and evidence requirement for detections and investigations involving new service or daemon registration. The supplied ATT&CK fields provide concrete collection measures but no official detection analytic, tactics, platforms field, or relationship context.
No relationships, tactics, official detection text, or ATT&CK platform list were supplied. Local asset inventory, administrator workflows, service baselines, and retention settings are required to judge materiality and detection quality.
Service Creation
The registration of a new service or daemon on an operating system.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4697 - Captures the creation of a new Windows service. - Event ID 7045 - Captures services installed by administrators or adversaries. - Event ID 7034 - Could indicate malicious service modification or exploitation. - Sysmon Logs - Sysmon Event ID 1 - Process Creation (captures service executables). - Sysmon Event ID 4 - Service state changes (detects service installation). - Sysmon Event ID 13 - Registry modifications (captures service persistence changes). - PowerShell Logging - Monitor `New-Service` and `Set-Service` PowerShell cmdlets in Event ID 4104 (Script Block Logging). - Linux/macOS Collection Methods - AuditD & Syslog Daemon Logs (`/var/log/syslog`, `/var/log/messages`, `/var/log/daemon.log`) - AuditD Rules: - `auditctl -w /etc/systemd/system -p wa -k service_creation` - Detects changes to `systemd` service configurations. - Systemd Journals (`journalctl -u
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 | 2.0 | Current bundle | fe0b30f6dc5d… |
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 DC0060Open 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.