AN0701: Analytic 0701
Detects the creation or modification of `.service` unit files in system/user-level directories, combined with execution of `systemctl`, `service`, or dynamically created drop-ins via systemd generators. Detects persistence by analyzing the `ExecStart` path, file entropy, and symlink usage, especially when paired with execution from `/tmp`, `/dev/shm`, or unmounted volumes.
Analyst context for executives and security teams
AN0701 is a Linux detection analytic focused on suspicious creation or modification of systemd `.service` unit files and related execution through `systemctl`, `service`, or systemd generator drop-ins. Its business value is persistence assurance: if an attacker or unauthorized administrator can establish a malicious service, access may survive reboots and routine remediation, creating risk for operational resilience and incident containment.
Executive priority
Treat this as a control-validation item for Linux server resilience, especially where Linux hosts support critical applications, cloud workloads, or regulated systems. Leaders should ask whether SOC and IR teams can prove visibility into systemd service changes, service execution, suspicious `ExecStart` targets, symlink abuse, and execution from temporary or unusual filesystem locations. The priority is not just alerting, but having audit-quality evidence to distinguish authorized service deployment from persistence during an incident.
Technical view
Validate monitoring for Linux system and user-level systemd unit directories, creation or modification of `.service` files, execution of `systemctl` or `service`, and dynamically created drop-ins through systemd generators. Review whether detections inspect `ExecStart` paths, file entropy, symlink usage, and service references to paths such as `/tmp`, `/dev/shm`, or unmounted volumes. Because ATT&CK does not provide a formal detection block or relationships for this analytic, local engineering must define the exact directories, baselines, and allowlists appropriate to the environment.
Likely telemetry
- Linux file creation and modification events for systemd unit directories
- Process execution telemetry for `systemctl` and `service`
- Command-line telemetry associated with service creation, modification, enablement, or start actions
- File metadata for `.service` unit files, including ownership, permissions, timestamps, symlinks, and target paths
- Content inspection or parsing of unit files, especially `ExecStart` values
Detection direction
- Baseline expected service deployment and package-management activity to reduce noise from legitimate administration and software installation.
- Prioritize alerts where `.service` file changes are followed by `systemctl` or `service` execution, or where the service points to temporary, shared-memory, symlinked, or unusual paths.
- Validate whether user-level systemd directories are monitored, not only system-level locations.
- Inspect `ExecStart` targets for unexpected binaries, scripts, high-entropy file content, or paths outside approved application directories.
- Tune false positives for configuration management, patching, container host maintenance, and approved service installers.
Mitigation priorities
- Restrict who can create or modify system and user-level service unit files through least privilege and administrative change control.
- Use file integrity monitoring or equivalent controls on systemd unit directories and generator paths where operationally feasible.
- Harden service deployment workflows so approved automation leaves clear audit trails for SOC review.
- Limit execution from temporary or shared-memory locations where compatible with business operations.
- Ensure incident response playbooks include review of systemd services, drop-ins, symlinks, and `ExecStart` targets during Linux persistence triage.
Analyst notes and limits
This object is a detection analytic, not a technique record, and no tactic or relationship context was supplied. The strongest defensible interpretation is Linux persistence-oriented detection around systemd service manipulation based on the official description. Glexia should position this as a visibility and control-validation requirement for Linux fleets rather than as proof of any specific threat actor or campaign.
The official ATT&CK detection field is not provided, and no relationships are supplied. The object only lists Linux as the platform and does not specify tactics, procedures, data components, mitigations, or adversary use. Effective implementation requires local knowledge of Linux distributions, approved service management practices, EDR/audit coverage, and administrative automation patterns.
Analytic 0701
Detects the creation or modification of `.service` unit files in system/user-level directories, combined with execution of `systemctl`, `service`, or dynamically created drop-ins via systemd generators. Detects persistence by analyzing the `ExecStart` path, file entropy, and symlink usage, especially when paired with execution from `/tmp`, `/dev/shm`, or unmounted volumes.
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 | 1.0 | Current bundle | 7a02ac482cc7… |
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 AN0701Open 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.