AN0779: Analytic 0779
Detect unusual invocations of systemctl, service, or init scripts creating or modifying daemons. Monitor audit logs for execution of binaries from unexpected paths linked to service start/stop activity.
Analyst context for executives and security teams
This analytic matters because unauthorized or unusual Linux service management can turn a one-time command into a persistent operational foothold. For leaders, the decision value is whether critical Linux servers have enough audit visibility to show who created, modified, started, or stopped daemons, especially when service-related binaries are executed from unexpected paths.
Executive priority
Prioritize this where Linux systems support business-critical operations, regulated workloads, or incident response evidence requirements. The key management question is not whether the organization has a SIEM rule named AN0779, but whether Linux audit logging can reliably prove service changes and distinguish approved administration from suspicious daemon creation or modification.
Technical view
Validate monitoring for unusual invocations of systemctl, service, and init scripts on Linux. Focus on executions associated with creating or modifying daemons and on service start/stop activity where binaries are run from unexpected paths. Because no tactic, relationship context, or formal detection logic is supplied, detection engineering should treat this as a behavior-oriented analytic requiring local baselining of legitimate service administration patterns.
Likely telemetry
- Linux audit logs showing process execution
- Command-line arguments for systemctl, service, and init scripts
- Parent process, user, timestamp, and host context for service-management commands
- File path evidence for binaries linked to service start or stop activity
- Records of daemon or service creation, modification, start, and stop events
Detection direction
- Confirm audit logs are collected from in-scope Linux systems and retain command-line and executable path details.
- Baseline expected administrative use of systemctl, service, and init scripts to reduce noise from routine operations.
- Alert or investigate service start/stop activity tied to binaries executed from unexpected paths.
- Correlate service-management activity with user context and host criticality before escalating.
- Account for false positives from patching, deployment tooling, configuration management, and legitimate administrator maintenance.
Mitigation priorities
- Define and document approved Linux service administration methods and expected binary locations.
- Restrict service-management privileges to authorized administrators and service accounts.
- Ensure audit logging is enabled and centrally retained for Linux systems where service changes affect business operations.
- Review change-management evidence for daemon creation or modification on critical hosts.
- Use incident response playbooks that preserve audit logs and service configuration evidence when unusual daemon activity is suspected.
Analyst notes and limits
This is a detection analytic object for Linux only. The official description emphasizes unusual invocations of systemctl, service, or init scripts and audit-log monitoring for binaries from unexpected paths linked to service start/stop activity. No ATT&CK tactics, related techniques, or explicit detection logic were supplied, so local environment context is required to operationalize it.
The object provides a short description but no official detection implementation, no relationships, and no tactic mapping. This take should not be interpreted as evidence of active exploitation, attribution, impact, or existing coverage in any environment.
Analytic 0779
Detect unusual invocations of systemctl, service, or init scripts creating or modifying daemons. Monitor audit logs for execution of binaries from unexpected paths linked to service start/stop activity.
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 | c4f3b893533e… |
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 AN0779Open 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.