MITRE ATT&CK T1653 Power Settings: Detecting and Reversing Sleep and Shutdown Tampering

Malware that dies when a machine sleeps, hibernates or reboots has a simple fix: stop the machine from ever doing so. MITRE ATT&CK T1653 Power Settings, in the Persistence tactic, covers adversaries who change sleep, hibernate, display, disk and lock timeouts, or remove the files that trigger shutdown and reboot, so their code keeps running. It is common in cryptomining loaders and IoT botnets, and it is easy to miss because the same settings are changed every day by users and IT. This guide is for detection engineers, endpoint administrators and incident responders on Windows, Linux, macOS and network devices. It covers what the technique changes, how to baseline and enforce power policy, what to log and alert on, and how to put a tampered host back to a known state.

Key takeaways

• It is a persistence enabler, not a payload. Changing power settings does no harm on its own; it keeps memory-resident or non-persistent malware alive and keeps a mining rig drawing power.
• Enforced policy beats detection. If sleep, hibernate and lock timeouts are set by Group Policy, Intune or a configuration management tool, a local change is overwritten on the next refresh and stands out as drift.
• Command lines are the best signal. ATT&CK's detection guidance centres on powercfg.exe on Windows, systemctl, loginctl and systemd-inhibit on Linux, and pmset on macOS, run outside administrative baselines.
• Servers are the hard case. Many servers are meant never to sleep, so the useful signal there is deleted or altered shutdown and reboot binaries, and inhibitor locks held by unexpected processes.
• Treat a hit as a lead. A suspicious power change means something on the host wanted to stay running: hunt for the process that made the change and what it is protecting.

How the technique works

ATT&CK describes T1653 as impairing a system's ability to hibernate, reboot or shut down to extend access, because a dormant state can stop some or all software and interrupt malicious activity. The technique (version 1.1 in ATT&CK v20) lists Windows, Linux, macOS and network devices, and its one mitigation is M1047 Audit: periodically inspect systems for abnormal or unexpected power settings.

It is related to, but distinct from, T1529 System Shutdown/Reboot, where the adversary forces a shutdown as an impact. Here the aim is the opposite. When the motive is mining, expect T1496 Resource Hijacking alongside it; see the Cryptojacking Guide.

Where the settings live

Knowing the configuration surface per platform tells you what to baseline, what to protect and where to collect telemetry.

Two Windows details matter. powercfg /requestsoverride can tell Windows to ignore power requests from a process, service or driver, and powercfg /requests lists the requests currently keeping the display or system awake, which is useful during triage. On Linux, systemd-inhibit takes a lock of types such as sleep, shutdown or idle in block, block-weak or delay mode, and systemd-inhibit --list shows who holds one. In sleep.conf, setting AllowSuspend=no or AllowHibernation=no also turns off hybrid sleep and suspend-then-hibernate unless they are re-enabled explicitly.

Detection

ATT&CK's detection strategy for T1653 uses process creation and file modification on each platform, tuned with an allowlist of administrative tools and maintenance windows. Build from that.

A configuration audit, the M1047 mitigation, catches what the command-line rules miss, such as a change made through an API rather than the utility. Schedule a fleet query of effective sleep, hibernate and lock values with your EDR or osquery and compare them with policy; see the osquery Guide. For Linux audit rules, see the Linux Logging and auditd for Defenders Guide, and for Windows process and registry events the Sysmon Guide.

Correlations that raise confidence

• Power change plus new persistence: a power change within minutes of a new service, scheduled task or Run key on the same host.
• Power change plus sustained CPU or GPU: a host that stopped sleeping and now runs at high utilisation out of hours points to mining.
• Power change plus outbound connections: new long-lived connections to mining pools or unfamiliar hosts.
• Lock timeout extended plus remote access: lock screen changes followed by a new remote management tool or interactive session.

Prevention and hardening

• Enforce power policy centrally: on Windows, set sleep, hibernate, display and password-on-wake through Group Policy (Computer Configuration, Administrative Templates, System, Power Management, Sleep Settings) or Intune Power CSP settings such as StandbyTimeoutPluggedIn, HibernateTimeoutPluggedIn and RequirePasswordWhenComputerWakesPluggedIn. Enforced values are reapplied, which both reverts and surfaces tampering.
• Enforce screen lock separately: set an inactivity lock (for example the Windows security option "Interactive logon: Machine inactivity limit") so a power change does not also leave sessions open.
• Own the Linux files: let configuration management own sleep.conf, its drop-ins and logind.conf, so local edits are reverted and reported.
• Remove local admin: malware running with administrative rights can change machine-wide settings and the Power registry key. Standard user accounts and managed local admin passwords limit what a loader inherits; see the LAPS Guide.
• Restrict script and binary execution: application control and script restrictions stop the loaders that usually make the change.
• Protect device firmware: on routers and IoT devices, use vendor firmware with integrity checking, change default credentials and close management interfaces to the internet, because botnets that delete reboot binaries usually arrive through exposed services.
• Reboot on a schedule: regular patch reboots flush non-persistent malware. A host that has stopped rebooting is itself worth a look.

Decision guidance by estate

Smaller organisations can get most of the value from enforced power and lock policy plus one EDR rule on powercfg and pmset. Larger estates should add the fleet configuration audit and file integrity on servers and appliances.

Response: putting a host back to a known state

1. Capture first: record current power settings (powercfg /query, powercfg /requests and powercfg /requestsoverride with no arguments on Windows; systemd-inhibit --list and the sleep and logind files on Linux; pmset settings on macOS). Acquire memory before any reboot if memory-resident malware is suspected, because a reboot is exactly what destroys it.
2. Find the actor: identify the process tree that made the change and the account it ran as, then hunt for its persistence, network connections and any mining or botnet activity.
3. Contain: isolate the host through EDR if the parent process is malicious.
4. Eradicate: remove the malware and its persistence. For network devices, follow vendor guidance, which may mean reflashing firmware, and restore removed binaries from known-good images only.
5. Restore policy: force a policy refresh or configuration management run, remove any request overrides and inhibitors, and confirm the effective values match the baseline.
6. Verify: confirm the host sleeps, locks and reboots normally, and keep it on a watch list for a short period (our suggestion: two weeks).

If the host is an edge appliance, follow the Edge Device Compromise Investigation Playbook. For mining infections, the Cryptojacking Incident Response Playbook covers the wider response.

Measuring coverage

• Policy compliance: percentage of endpoints whose effective sleep, hibernate and lock values match policy (target close to 100%, with documented exceptions).
• Telemetry coverage: percentage of Windows hosts sending process creation with command lines, and Linux hosts with auditd rules for the power utilities and files.
• Rule precision: proportion of powercfg, pmset and inhibitor alerts that are true positives after allowlisting; low precision means the allowlist needs work.
• Reboot hygiene: number of hosts that have not rebooted within your patch cycle.
• Server integrity: file integrity coverage of shutdown and reboot binaries on Linux servers and appliances.

Framework mapping

Common failure patterns

• Power settings left to users: without enforced policy there is no baseline, so a malicious change looks like a user preference.
• No command-line logging: event 4688 without command-line capture shows powercfg.exe ran but not what it changed.
• Rebooting first: responders reboot to "clean" a host and destroy the memory-resident evidence the technique was protecting.
• Ignoring servers: teams assume the technique is irrelevant where sleep is already off, and miss deleted reboot binaries and held inhibitors.
• Fixing the setting, not the cause: resetting the power plan without finding the process that changed it leaves the malware in place.

Practitioner checklist

• Enforce sleep, hibernate, display and password-on-wake values through GPO, Intune or MDM.
• Enforce an inactivity screen lock independent of power settings.
• Put Linux sleep and logind configuration under configuration management.
• Turn on process creation logging with command lines on Windows and auditd rules on Linux.
• Alert on powercfg, pmset, systemd-inhibit and sleep target masking from unexpected parents.
• Monitor shutdown and reboot binaries with file integrity monitoring on servers and appliances.
• Run a scheduled fleet audit of effective power and lock values against policy.
• Capture power state and memory before rebooting a suspect host.

Standards and references

• MITRE ATT&CK: Power Settings (T1653)
• MITRE ATT&CK: Audit (M1047)
• Microsoft Learn: Powercfg command-line options
• Microsoft Learn: Power Policy CSP
• Microsoft Learn: Event 4657, a registry value was modified
• man7.org: systemd-sleep.conf(5)
• man7.org: systemd-inhibit(1)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Cryptojacking Guide · MITRE ATT&CK T1529 System Shutdown/Reboot · T1543 Create or Modify System Process Defensive Guide · Sysmon Guide