AN1539: Analytic 1539
Detect 'shutdown', 'reboot', or 'systemctl poweroff' executions with auditd/syslog and absence of scheduled maintenance windows or approved user context.
Analyst context for executives and security teams
This analytic matters because unexpected Linux shutdown or reboot activity can interrupt business services and may indicate misuse, operational error, or unauthorized administrative action. Its value is less about spotting the command alone and more about proving whether power-state changes happened during an approved maintenance window and under an approved user context.
Executive priority
Prioritize this where Linux systems support critical applications, infrastructure services, or regulated operations that require uptime evidence. Leaders should ask whether the organization can quickly distinguish approved maintenance from unexpected shutdown activity, identify the responsible account, and provide audit evidence during an incident or availability review.
Technical view
For Linux environments, validate collection from auditd and/or syslog for executions of `shutdown`, `reboot`, and `systemctl poweroff`. Detection logic should correlate command execution with user identity, host criticality, change or maintenance schedules, and approved administrative context. Because no ATT&CK tactic or relationship context is supplied, treat this as an availability and administrative-action monitoring analytic rather than evidence of a specific adversary objective by itself.
Likely telemetry
- Linux auditd process execution records
- Linux syslog entries related to shutdown, reboot, and systemd poweroff activity
- User/account context associated with command execution
- Hostnames or asset identifiers for affected Linux systems
- Approved maintenance window or change-management records
Detection direction
- Confirm that auditd and/or syslog are enabled and retained on in-scope Linux systems.
- Alert on executions of `shutdown`, `reboot`, or `systemctl poweroff` outside approved maintenance windows or by non-approved users.
- Tune expected administrative automation and scheduled maintenance to reduce false positives.
- Prioritize alerts from production, externally facing, identity, logging, monitoring, or other business-critical Linux hosts.
- Validate that detection content can join security telemetry with change-management or maintenance-window data; command matching alone is likely noisy.
Mitigation priorities
- Define and maintain approved maintenance windows and authorized administrative user groups for Linux power-state changes.
- Restrict privileged command execution to approved administrators and documented operational workflows.
- Ensure auditd/syslog coverage is enabled, forwarded, and monitored for critical Linux assets.
- Review unexpected shutdown or reboot events through incident response or change-control processes to determine whether they were authorized.
- Use asset criticality to prioritize monitoring and response for Linux systems where unexpected downtime has the greatest business impact.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique description. It provides a Linux platform scope and a concise detection idea focused on shutdown, reboot, and systemctl poweroff executions with auditd/syslog plus maintenance-window and user-context validation. No tactics, relationships, adversary procedures, or official detection implementation were supplied.
This take is limited to the official fields provided. It does not establish attacker intent, active exploitation, impact, or coverage. Local environment data is required to define approved users, maintenance windows, asset criticality, normal automation, and acceptable operational exceptions.
Analytic 1539
Detect 'shutdown', 'reboot', or 'systemctl poweroff' executions with auditd/syslog and absence of scheduled maintenance windows or approved user context.
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 | 863a1cfbac81… |
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 AN1539Open 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.