DET0417: Detection Strategy for Power Settings Abuse
DET0417 is a detection strategy for identifying abuse of power settings related to ATT&CK technique T1653, Power Settings. The business issue is persistenc...
Analyst context for executives and security teams
DET0417 is a detection strategy for identifying abuse of power settings related to ATT&CK technique T1653, Power Settings. The business issue is persistence: if an adversary can prevent systems or devices from sleeping, rebooting, or shutting down, malicious activity may continue longer than expected and normal containment assumptions may fail.
Executive priority
Leaders should treat this as a resilience and incident-response readiness question: can the organization prove when power-management settings are changed, by whom, and on which critical assets? This matters for uptime, containment planning, audit evidence, and prioritizing controls on Windows, Linux, macOS, and network devices where T1653 applies.
Technical view
The supplied detection strategy object does not include official detection logic, platforms, or tactics, but it is related to T1653, which is a persistence technique affecting Windows, Linux, macOS, and network devices. SOC and IR teams should validate whether they can observe changes to power-management configuration, system utility execution that modifies sleep/hibernate/reboot/shutdown behavior, and administrative actions that prevent dormant states. Detection engineering should tie alerts to asset criticality and identity context because legitimate administrators and device-management tooling may also change these settings.
Likely telemetry
- Endpoint configuration change events for power, sleep, hibernate, reboot, and shutdown settings
- Process execution telemetry for system utilities used to modify power-management behavior
- Operating system logs showing power-state policy changes or failed/blocked sleep, shutdown, or reboot behavior
- Administrative command, script, or configuration-management activity on Windows, Linux, macOS, and network devices
- Identity and access telemetry showing the user, service account, or management system responsible for the change
Detection direction
- Confirm telemetry exists before writing analytic logic; the ATT&CK object provides no official detection text.
- Baseline normal administrative and device-management changes to reduce false positives.
- Prioritize alerting when power-setting changes occur on high-value systems, outside maintenance windows, or by unusual accounts.
- Correlate power-setting changes with other persistence or post-compromise indicators rather than treating every change as malicious.
- Check blind spots on non-Windows systems and network devices, since the related technique lists Windows, Linux, macOS, and Network Devices.
Mitigation priorities
- Restrict who can modify power-management and reboot/shutdown behavior on critical assets.
- Use change-management or configuration-management controls to define approved power settings and detect drift.
- Require logging and retention for administrative configuration changes that affect sleep, hibernate, reboot, and shutdown behavior.
- Review privileged account use and service-account permissions for tools that can change system configuration.
- Include power-setting abuse checks in incident response containment and recovery validation for affected assets.
Analyst notes and limits
This take is based on the supplied DET0417 metadata and its relationship to T1653 Power Settings. Because the detection strategy has no official description or detection content, the guidance focuses on defensive validation questions and evidence classes implied by the related technique.
Platforms and persistence context come from the related T1653 technique, not from DET0417 itself. No active exploitation, actor attribution, prevalence, specific procedures, or guaranteed detection coverage are provided by the supplied fields.
Detection Strategy for Power Settings Abuse
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 | T1653 | Power Settings | This object detects Power Settings. |
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 | 2fab5549b009… |
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 DET0417Open 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.