DET0073: Detection Strategy for System Services: Systemctl
DET0073 is a MITRE detection strategy object for abuse of systemctl, the Linux systemd service manager, to execute commands or programs. Even though the de...
Analyst context for executives and security teams
DET0073 is a MITRE detection strategy object for abuse of systemctl, the Linux systemd service manager, to execute commands or programs. Even though the detection strategy itself has no official description or detection text, its relationship to ATT&CK technique T1569.003 makes it relevant for organizations that rely on Linux systems for critical services. The business issue is whether defenders can distinguish legitimate service administration from suspicious service-driven execution before it becomes an incident response blind spot.
Executive priority
Prioritize this where Linux servers support business-critical applications, regulated workloads, or operational services. Leaders should ask whether SOC and IR teams have enough Linux service-management visibility to reconstruct who or what invoked systemctl, what service was affected, and whether the activity was expected change activity. This is also useful audit evidence: it tests whether endpoint logging, privileged access oversight, and change-management records align for service execution events.
Technical view
This object detects T1569.003 Systemctl, which is an execution technique on Linux. SOC and detection engineering teams should validate visibility around systemctl invocation and systemd service activity, especially service start, stop, enable, and disable actions referenced in the related technique context. Because ATT&CK provides no detection logic for DET0073, teams should build local analytics around command/process telemetry, service state changes, parent process context, user identity, privilege level, host role, and change-window correlation. Incident responders should ensure they can pivot from a systemctl event to the affected unit/service, initiating user or process, related scripts or applications, and surrounding command history where available.
Likely telemetry
- Linux process creation or command execution logs showing systemctl usage
- systemd journal or service-management logs showing service start, stop, enable, or disable activity
- Endpoint detection telemetry for parent/child process relationships involving shells, scripts, applications, and systemctl
- Authentication and privilege escalation records identifying the user or account context
- File and configuration change telemetry for systemd service unit files where collected
Detection direction
- Validate that Linux systems using systemd produce searchable records for systemctl execution and service state changes.
- Tune detections against host role and administrative baselines, because systemctl is commonly used for legitimate operations.
- Correlate systemctl activity with user identity, privilege context, parent process, affected service, and approved change windows.
- Prioritize unusual systemctl use initiated from unexpected shells, scripts, applications, accounts, or hosts, while avoiding assumptions that any single subcommand is malicious by itself.
- Document telemetry gaps explicitly, since the ATT&CK detection strategy object does not provide official detection logic or platform metadata beyond its relationship to the Linux Systemctl technique.
Mitigation priorities
- Confirm privileged access controls and administrative process governance for Linux service management.
- Ensure Linux endpoint and systemd logging are retained long enough to support SOC triage and incident reconstruction.
- Align detections with change-management processes so legitimate maintenance can be separated from suspicious execution.
- Review service-management permissions and operational ownership for critical Linux hosts.
- Use this detection strategy as a validation item in managed detection, incident response readiness, and compliance evidence exercises rather than as a standalone control.
Analyst notes and limits
The most important decision value is coverage validation: can the organization observe and explain systemctl-driven execution on Linux systems? The relationship to T1569.003 supplies the operational context, while the DET0073 object itself is sparse. Treat this as a prompt to test telemetry, baselines, and response pivots around systemd service execution.
The supplied ATT&CK detection strategy has no official description, detection text, tactics, platforms, labels, or aliases. Platform and tactic context comes only from the relationship to T1569.003 Systemctl, which lists Linux and execution. Local environment baselines are required to determine what is suspicious versus normal administration.
Detection Strategy for System Services: Systemctl
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.
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 | 6b59a4bf4106… |
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 DET0073Open 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.