DET0231: Behavioral Detection of Systemd Timer Abuse for Scheduled Execution
DET0231 is a detection strategy for spotting abuse of systemd timers, a Linux scheduling mechanism that can be used for recurring or delayed execution. The...
Analyst context for executives and security teams
DET0231 is a detection strategy for spotting abuse of systemd timers, a Linux scheduling mechanism that can be used for recurring or delayed execution. The business value is persistence and execution visibility: if Linux servers are material to operations, identity services, applications, or infrastructure management, unauthorized timer activity can let an intruder survive reboots or trigger code later when responders are not looking.
Executive priority
Treat this as a Linux operational resilience and incident readiness question: do security teams have enough visibility to distinguish approved systemd timer administration from suspicious persistence? Leaders should ask whether critical Linux assets are inventoried, whether timer changes are logged centrally, and whether SOC/IR playbooks include validation of scheduled execution mechanisms during containment and recovery.
Technical view
This detection strategy is linked to ATT&CK T1053.006 Systemd Timers, under execution, persistence, and privilege escalation. Because the supplied DET0231 object has no official description, detection text, or platforms, teams should anchor validation to the related technique: monitor creation, modification, enablement, and execution of systemd .timer units and associated service units on Linux systems, then compare activity against known administrative baselines.
Likely telemetry
- Linux host logs related to systemd unit and timer activity
- File creation and modification events for systemd timer and service unit paths
- Process execution telemetry showing systemctl or related service-management activity
- Authentication and privilege-use logs for accounts making timer changes
- Configuration management or asset inventory records showing approved timers on critical Linux systems
Detection direction
- Validate that telemetry covers both user-level and system-level systemd timer locations where applicable in the local Linux build and logging configuration.
- Baseline approved timers and alert on new, modified, enabled, or unusual timer-service pairings, especially on high-value servers.
- Correlate timer changes with the initiating account, privilege context, parent process, and subsequent service execution to reduce false positives from patching, deployment, and administration.
- During incidents, review systemd timers alongside other scheduled execution mechanisms so persistence is not missed by cron-only checks.
- Do not assume DET0231 provides ready-made analytics; the supplied ATT&CK object contains no official detection logic.
Mitigation priorities
- Maintain an inventory of approved systemd timers on critical Linux assets.
- Restrict who can create, modify, or enable systemd units through least privilege and administrative change control.
- Centralize and retain Linux host telemetry needed to reconstruct timer creation, modification, and execution.
- Include systemd timer review in incident response persistence checks and recovery validation.
- Use configuration management or file integrity monitoring where appropriate to identify unauthorized unit-file changes.
Analyst notes and limits
The ATT&CK detection strategy itself is sparse: no official description, detection text, platforms, or tactics are provided. The practical framing here is derived from the relationship showing that DET0231 detects T1053.006 Systemd Timers, whose related tactics are execution, persistence, and privilege escalation on Linux.
This take does not assert active exploitation, actor use, detection coverage, or specific vendor capability. Local Linux distributions, logging settings, systemd configuration, administrative workflows, and asset criticality determine what telemetry is available and what should be considered suspicious.
Behavioral Detection of Systemd Timer Abuse for Scheduled Execution
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 | T1053.006 | Systemd Timers Sub-technique | This object detects Systemd Timers. |
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 | 760d10f56fde… |
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 DET0231Open 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.