DET0253: Detection of Systemd Service Creation or Modification on Linux
This detection strategy matters because systemd services are a common Linux mechanism for keeping processes running across reboots. If an adversary creates...
Analyst context for executives and security teams
This detection strategy matters because systemd services are a common Linux mechanism for keeping processes running across reboots. If an adversary creates or changes a service, it can support persistence or privilege escalation. For leaders, the practical question is whether Linux server monitoring can show when service definitions change and whether the SOC can quickly distinguish authorized administration from suspicious persistence activity.
Executive priority
Prioritize this as a Linux resilience and incident-readiness control area. Coverage is most important for business-critical Linux systems where unauthorized persistence could extend an intrusion, complicate recovery, or weaken audit confidence. Executives should ask whether service creation and modification events are logged, retained, reviewed, and tied to change-management evidence.
Technical view
The supplied ATT&CK object is a detection strategy for Systemd Service Creation or Modification and is related to T1543.002 Systemd Service, which maps to persistence and privilege escalation on Linux. SOC and detection teams should validate visibility into systemd unit file creation, modification, enablement, and related service-management activity on Linux hosts. Because the official detection text is not provided, local detections should be grounded in observed administrative baselines, file integrity monitoring, process execution logs, and change-control context.
Likely telemetry
- Linux file creation and modification events for systemd service/unit locations
- File integrity monitoring for service definition changes
- Process execution telemetry for service-management commands
- Authentication and privilege elevation logs showing who made changes
- System logs or journal data related to service reloads, starts, enables, or failures
Detection direction
- Validate that Linux telemetry covers systemd service creation and modification, not only process execution after a service starts.
- Correlate service file changes with user identity, privilege escalation, remote login, package installation, and approved change windows.
- Tune for common false positives from patching, configuration management, software deployment, and legitimate administrator activity.
- Prioritize unusual service names, unexpected execution paths, recently modified unit files, or changes on high-value Linux systems for review.
- Confirm retention is sufficient for incident response, since persistence changes may occur before discovery of the broader intrusion.
Mitigation priorities
- Establish controlled change management for Linux service creation and modification on critical systems.
- Restrict administrative permissions needed to create or modify systemd services.
- Use configuration management or file integrity monitoring to detect drift from approved service baselines.
- Harden logging and retention for Linux administrative activity and service-management events.
- Include systemd service review in incident response triage and recovery validation for Linux hosts.
Analyst notes and limits
This take is based on the detection strategy object DET0253 and its relationship to ATT&CK technique T1543.002 Systemd Service. The relationship supplies the key context: Linux systemd services can be created or modified for persistence and privilege escalation. The object itself does not include official description, detection logic, tactics, or platforms, so the technical guidance is framed as validation direction rather than a claim of specific MITRE-provided analytics.
The supplied detection strategy has no official description or detection text, and the object-level platforms and tactics are not specified. Linux, persistence, and privilege-escalation context comes from the related T1543.002 technique. Local operating system versions, logging configuration, EDR/FIM coverage, and administrative processes determine actual detection quality.
Detection of Systemd Service Creation or Modification on Linux
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1543.002 | Systemd Service Sub-technique | This object detects Systemd Service. |
All related ATT&CK context
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 | 6f8cf3d3361d… |
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 DET0253Open 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.