Power Settings
This detection identifies adversaries abusing power management utilities and configuration settings to prevent infected systems from entering sleep, hibernate, or shutdown states, thereby extending their access window. On Windows, suspicious invocations of powercfg.exe with timeout-disabling flags, registry modifications to power scheme keys, and lock screen timeout changes are monitored. On Linux, masking of systemd sleep targets and modifications to /etc/systemd/logind.conf are targeted. The detection also covers deletion of system shutdown/reboot binaries, a behavior observed in Condi botnet campaigns, and unusual processes setting sleep inhibitors outside of known legitimate software contexts.
What is T1653 Power Settings?
Power Settings (T1653) maps to the Persistence tactic — the adversary is trying to maintain their foothold in MITRE ATT&CK.
This page provides production-ready detection logic for Power Settings, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Persistence
- Technique
- T1653 Power Settings
- Canonical reference
- https://attack.mitre.org/techniques/T1653/
let SuspiciousPowercfgArgs = dynamic(["/change", "-change", "/setacvalueindex", "-setacvalueindex", "/setdcvalueindex", "-setdcvalueindex", "/hibernate", "-hibernate", "/x", "-x"]);
let SleepTimeoutKeywords = dynamic(["standby-timeout", "hibernate-timeout", "monitor-timeout", "disk-timeout", "lock-timeout"]);
let PowerRegistryPaths = dynamic([
"HKLM\\SYSTEM\\CurrentControlSet\\Control\\Power",
"HKCU\\Control Panel\\PowerCfg",
"HKLM\\SOFTWARE\\Policies\\Microsoft\\Power",
"HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Power"
]);
// Branch 1: Suspicious powercfg.exe invocations disabling timeouts
let PowercfgAbuse = DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName =~ "powercfg.exe" or ProcessCommandLine has "powercfg"
| where ProcessCommandLine has_any (SuspiciousPowercfgArgs)
| extend TimeoutDisabled = ProcessCommandLine has_any (SleepTimeoutKeywords) and ProcessCommandLine has_any (" 0", " 0 ", "off", "never")
| extend HibernateDisabled = ProcessCommandLine has "hibernate" and ProcessCommandLine has_any ("off", " 0")
| where TimeoutDisabled or HibernateDisabled
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName, FolderPath, SHA256
| extend DetectionType = "PowercfgTimeoutDisabled";
// Branch 2: Registry modifications to power policy keys
let PowerRegistryMod = DeviceRegistryEvents
| where Timestamp > ago(1d)
| where RegistryKey has_any (PowerRegistryPaths)
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| where RegistryValueName has_any ("ACSettingIndex", "DCSettingIndex", "Attributes", "CurrentPowerPolicy", "Hibernate", "StandbyTimeout", "HibernateTimeout", "MonitorTimeout")
| where isnotempty(RegistryValueData) and RegistryValueData in ("0", "00000000")
| project Timestamp, DeviceName, AccountName, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine
| extend DetectionType = "PowerRegistryModification";
// Branch 3: Deletion of shutdown/reboot binaries (cross-platform consideration via Windows subsystem or admin tools)
let ShutdownBinaryDeletion = DeviceFileEvents
| where Timestamp > ago(1d)
| where ActionType == "FileDeleted"
| where FileName has_any ("shutdown.exe", "restart.exe") or FolderPath has_any ("\\Windows\\System32\\shutdown", "\\Windows\\SysWOW64\\shutdown")
| where InitiatingProcessFileName !in~ ("TrustedInstaller.exe", "msiexec.exe", "setup.exe", "wusa.exe")
| project Timestamp, DeviceName, AccountName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine
| extend DetectionType = "ShutdownBinaryDeletion";
// Combine all branches
PowercfgAbuse
| union PowerRegistryMod
| union ShutdownBinaryDeletion
| project-reorder Timestamp, DeviceName, AccountName, DetectionType
| order by Timestamp desc Three-branch detection covering: (1) powercfg.exe invocations that set sleep, standby, hibernate, monitor, or lock timeouts to zero or disable hibernate entirely; (2) direct registry modifications to Windows power policy keys writing zero values to timeout settings; and (3) deletion of Windows shutdown/reboot binaries by non-trusted installers. Alerts are emitted across all three branches and labeled with a DetectionType field for triage prioritization.
Data Sources
Required Tables
False Positives
- IT administrators legitimately using powercfg.exe to configure power plans on server infrastructure or kiosk machines where sleep is intentionally disabled
- Enterprise power management software (e.g., HP Power Manager, Dell Command Power Manager) that sets timeouts to zero on always-on servers or workstations in data centers
- Software deployment systems (SCCM, Intune) that temporarily disable hibernate during patching windows to prevent interrupted updates
- Automated build agents and CI/CD runner hosts that disable sleep to ensure long-running pipelines complete without interruption
- Battery backup (UPS) management software modifying power settings as part of hibernation-on-power-loss configuration
Sigma rule & cross-platform mapping
The detection logic for Power Settings (T1653) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1653
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Disable Standby and Hibernate Timeouts via powercfg
Expected signal: Windows Event ID 4688 or Sysmon EventID 1 for powercfg.exe with the full command line visible. DeviceRegistryEvents entries for HKLM\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes showing ACSettingIndex and DCSettingIndex values set to 0.
- Test 2Disable Hibernate via powercfg hibernate off
Expected signal: Sysmon EventID 1 or Security EventID 4688 with ProcessCommandLine containing 'powercfg' and '/hibernate off' or '-h off'. DeviceFileEvents showing deletion of C:\hiberfil.sys (if hibernate was previously enabled).
- Test 3Mask systemd Sleep Targets on Linux
Expected signal: Syslog or auditd entries showing systemctl execution with 'mask' and target names. If auditd EXECVE rules are configured, full command line will be captured. journalctl will show systemd unit mask operations.
Response Playbook
Triage
- Step 1: Identify the initiating process — check InitiatingProcessFileName and InitiatingProcessCommandLine (KQL) or parent_proc (SPL). Legitimate admin tools like SCCM, Intune, or enterprise power managers will have consistent parent process chains. Malware typically spawns powercfg.exe from cmd.exe, powershell.exe, wscript.exe, or an unexpected binary.
- Step 2: Examine the full command line for the scope of change. A single timeout value set to 0 on a server is low risk. Multiple timeout settings all disabled simultaneously (standby + hibernate + monitor + lock) on an endpoint is high risk and consistent with malware anti-sleep behavior.
- Step 3: Cross-reference the executing account. Domain admin or SYSTEM context for powercfg changes on a workstation warrants immediate escalation. User-context changes on a shared workstation may be legitimate but still require verification.
- Step 4: Check the process tree for 15 minutes before and after the powercfg invocation. Look for coinminer binaries, LOLBins running from unusual paths, or network connections to mining pools or known C2 infrastructure.
- Step 5: For registry branch alerts, verify the exact key path and value modified. HKLM changes affect all users and are more impactful than HKCU changes. Verify whether a corresponding power scheme GUID was also created or modified.
- Step 6: On Linux alerts, verify if systemd sleep targets were masked globally or per-user. Check journalctl output around the time of the mask command: `journalctl --since '10 minutes ago' -u systemd-logind`
- Step 7: Check VirusTotal, MalwareBazaar, or internal threat intel for the SHA256 of the initiating process if it is not a known-good binary.
Containment
- If a coinminer or cryptominer is confirmed: isolate the endpoint immediately via Defender for Endpoint's device isolation feature or EDR console. Miners that disable sleep settings are actively consuming resources and may be exfiltrating wallet data.
- Revoke any suspicious or recently created scheduled tasks on the host that may re-invoke the powercfg changes: run `schtasks /query /fo LIST /v` and look for tasks created around the time of the alert.
- On Windows: restore default power settings with `powercfg -restoredefaultschemes` and verify the active power scheme returns to Balanced or as per organizational policy.
- On Linux: unmask sleep targets if maliciously masked: `systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target` and restore /etc/systemd/logind.conf from backup or known-good configuration.
- If shutdown/reboot binaries were deleted on Linux, restore from the package manager: `apt install --reinstall systemd` or `yum reinstall systemd` as appropriate. Verify binary hashes after restoration.
- Block the hash of any identified malicious binary at the EDR and network firewall level. If a miner pool IP/domain was identified in associated network events, add it to DNS sinkhole or firewall block list.
Evidence Collection
- Export Windows Event Log for the affected host: System, Security, and Microsoft-Windows-TaskScheduler/Operational logs from 24 hours before the alert. Archive as EVTX files.
- Collect the output of `powercfg /list` and `powercfg /query` to document the current state of all power schemes and settings after the incident.
- On Windows, collect Registry hive exports for HKLM\SYSTEM\CurrentControlSet\Control\Power and HKCU\Control Panel\PowerCfg using `reg export` or a forensic collection tool.
- Collect prefetch files from C:\Windows\Prefetch — specifically POWERCFG.EXE-*.pf — which contain execution history and loaded DLLs. Parse with Eric Zimmerman's PECmd.
- Collect the Amcache.hve hive (C:\Windows\appcompat\Programs\Amcache.hve) to identify recently executed programs and their hashes, which may reveal the malware binary that spawned powercfg.
- On Linux, collect: `/etc/systemd/logind.conf`, `/etc/systemd/sleep.conf`, output of `systemctl list-units --type=target | grep -E 'sleep|suspend|hibernate'`, and `systemd-inhibit --list` to document any active sleep inhibitors.
- Capture a full memory image if the system is suspected of running a resident miner — coinminers may only exist in memory or use reflective loading techniques.
Escalation Criteria
- ! Escalate to Tier 2/IR immediately if the powercfg or sleep-mask activity is associated with known cryptominer or botnet process names (xmrig, minerd, cgminer, poolminer, or binaries in %TEMP%, %APPDATA%, or non-standard paths).
- ! Escalate if the host shows concurrent indicators: outbound connections to non-standard high ports, abnormally high CPU/GPU usage, or processes with random 8-12 character names consistent with dropper-installed payloads.
- ! Escalate if the shutdown binary deletion pattern is observed — this is a strong indicator of a destructive or persistent botnet (Condi, Mirai variants) that requires full IR response.
- ! Escalate if lateral movement indicators are found: 4648 (explicit logon), 4624 type 3 from the affected host, or SMB connections to adjacent hosts within the same detection window.
- ! Escalate if SYSTEM or a service account performed the power changes and no corresponding legitimate software deployment event is found in SCCM/Intune deployment logs.
Investigation Guide
Forensic Artifacts
- >
C:\Windows\Prefetch\POWERCFG.EXE-*.pf — prefetch file containing execution history and frequency of powercfg.exe invocations - >
HKLM\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes — registry hive documenting all power scheme GUIDs and their settings - >
HKCU\Control Panel\PowerCfg\PowerPolicy — per-user power policy settings - >
C:\Windows\System32\powercfg.exe — binary integrity check against known-good hash - >
Windows Event ID 4688 / Sysmon EventID 1 logs — process creation records for powercfg.exe with full command line - >
/etc/systemd/logind.conf — Linux login manager configuration, check HandleSuspendKey, HandleLidSwitch, IdleAction fields - >
/etc/systemd/sleep.conf — Linux sleep configuration - >
journalctl -u systemd-logind — journal entries for login manager including sleep/suspend events - >
Output of `systemd-inhibit --list` — lists active inhibitors preventing sleep (malware may hold inhibitor locks) - >
/var/log/auth.log or /var/log/secure — sudo usage preceding systemctl mask commands
Tuning Guidance
To reduce false positives: (1) Build an allowlist of known-good SHA256 hashes for enterprise power management software (HP Power Manager, Dell Command, SCCM client) and suppress alerts where the initiating process hash matches. (2) Filter by device role — servers and kiosk/digital signage machines legitimately have sleep disabled; scope the alert to workstations and laptops. (3) Create a baseline of which accounts and machines regularly invoke powercfg in your environment; suppress recurring patterns that have been vetted. (4) For registry branch alerts, add the power scheme GUIDs managed by your endpoint management tool to an allowlist. (5) Tune confidence to 'high' in environments where server-class devices are excluded from scope and enterprise power management software hashes are allowlisted.
Hunting Queries
Hunts for hosts where three or more distinct power timeout categories (standby, hibernate, monitor, disk, lock) were disabled within the same session — a pattern consistent with automated malware configuration rather than a single legitimate admin change to one setting.
// Hunt: Identify hosts where MULTIPLE power timeout categories were disabled in same session
// Suggests automated malware configuration rather than legitimate admin change
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "powercfg.exe"
| where ProcessCommandLine has_any ("/change", "-change", "/setacvalueindex", "-setacvalueindex")
| extend TimeoutType = case(
ProcessCommandLine has "standby", "standby",
ProcessCommandLine has "hibernate", "hibernate",
ProcessCommandLine has "monitor", "monitor",
ProcessCommandLine has "disk", "disk",
ProcessCommandLine has "lock", "lock",
"other"
)
| summarize
UniqueTimeoutTypes = dcount(TimeoutType),
TimeoutTypeList = make_set(TimeoutType),
CommandLines = make_set(ProcessCommandLine),
InvocationCount = count(),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)
by DeviceName, AccountName, InitiatingProcessFileName
| where UniqueTimeoutTypes >= 3
| project DeviceName, AccountName, InitiatingProcessFileName, UniqueTimeoutTypes, TimeoutTypeList, CommandLines, InvocationCount, FirstSeen, LastSeen
| order by UniqueTimeoutTypes desc index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 OR sourcetype="WinEventLog:Security" EventCode=4688)
| eval proc=lower(coalesce(Image, NewProcessName, ""))
| eval cmdline=lower(coalesce(CommandLine, ProcessCommandLine, ""))
| where proc LIKE "%powercfg%"
| eval timeout_type=case(
cmdline LIKE "%standby%", "standby",
cmdline LIKE "%hibernate%", "hibernate",
cmdline LIKE "%monitor%", "monitor",
cmdline LIKE "%disk%", "disk",
cmdline LIKE "%lock%", "lock",
true(), "other"
)
| eval host=coalesce(ComputerName, host)
| eval user=coalesce(User, SubjectUserName)
| stats dc(timeout_type) AS unique_timeout_types, values(timeout_type) AS timeout_types, values(cmdline) AS cmdlines, count AS invocations BY host, user, _time span=1h
| where unique_timeout_types >= 3
| sort - unique_timeout_types Hunts for powercfg.exe executions spawned by unexpected parent processes outside of common legitimate parents. Targets malware that drops an executable and uses it to invoke powercfg rather than running through cmd.exe or powershell.exe, and flags parent processes running from suspicious paths like %TEMP% or %AppData%.
// Hunt: Detect powercfg changes by non-admin, non-system accounts or from unusual parent processes
// Focuses on parent process anomalies — malware spawning powercfg from scripts or dropped executables
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "powercfg.exe"
| where InitiatingProcessFileName !in~ (
"services.exe", "svchost.exe", "msiexec.exe", "TrustedInstaller.exe",
"ccmexec.exe", "ccmsetup.exe", "cscript.exe", "wscript.exe",
"explorer.exe", "cmd.exe", "powershell.exe", "pwsh.exe"
)
| project Timestamp, DeviceName, AccountName,
ProcessCommandLine, FileName,
InitiatingProcessFileName, InitiatingProcessFolderPath,
InitiatingProcessCommandLine, InitiatingProcessParentFileName
| extend RiskSignal = case(
InitiatingProcessFolderPath has_any ("%temp%", "\\appdata\\", "\\downloads\\", "\\public\\"), "SuspiciousPath",
AccountName !has "admin" and AccountName !has "SYSTEM" and AccountName !has "SERVICE", "UnexpectedAccount",
"AnomalousParent"
)
| order by Timestamp desc index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 OR sourcetype="WinEventLog:Security" EventCode=4688)
| eval proc=lower(coalesce(Image, NewProcessName, ""))
| eval parent=lower(coalesce(ParentImage, ParentProcessName, ""))
| eval parent_path=lower(coalesce(ParentImage, ""))
| eval cmdline=lower(coalesce(CommandLine, ProcessCommandLine, ""))
| where proc LIKE "%powercfg%"
| where NOT (parent LIKE "%services.exe%" OR parent LIKE "%svchost.exe%" OR parent LIKE "%msiexec.exe%" OR parent LIKE "%explorer.exe%" OR parent LIKE "%cmd.exe%" OR parent LIKE "%powershell.exe%")
| eval risk=case(
parent_path LIKE "%temp%" OR parent_path LIKE "%appdata%" OR parent_path LIKE "%downloads%", "SuspiciousParentPath",
true(), "AnomalousParentProcess"
)
| eval host=coalesce(ComputerName, host)
| table _time, host, proc, parent, cmdline, risk
| sort - _time Hunts for power settings reconnaissance (powercfg /energy, /batteryreport) that may precede sleep-disabling activity, and for Linux-specific sleep inhibitor patterns including systemd-inhibit with sleep/shutdown inhibit flags and systemctl mask of sleep targets. These patterns are distinct from the main detection's focus on active timeout disabling.
// Hunt: Detect sleep inhibitor processes on Linux-like environments via WSL or cross-platform telemetry
// Also hunts for powercfg /energy and /batteryreport which may reveal power scheme reconnaissance
DeviceProcessEvents
| where Timestamp > ago(7d)
| where (
(FileName =~ "powercfg.exe" and ProcessCommandLine has_any ("/energy", "/batteryreport", "/sleepstudy", "/systemsleepdiagnostics"))
or (ProcessCommandLine has "systemd-inhibit" and ProcessCommandLine has_any ("--what=sleep", "--what=shutdown", "--what=idle", "--why"))
or (ProcessCommandLine has "systemctl" and ProcessCommandLine has_any ("mask", "disable") and ProcessCommandLine has_any ("sleep", "hibernate", "suspend"))
)
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, FileName,
InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| extend ReconOrInhibit = case(
ProcessCommandLine has_any ("/energy", "/batteryreport", "/sleepstudy"), "PowerReconnaissance",
ProcessCommandLine has "systemd-inhibit", "LinuxSleepInhibitor",
ProcessCommandLine has "systemctl" and ProcessCommandLine has "mask", "LinuxSleepTargetMasked",
"Other"
)
| order by Timestamp desc index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 OR sourcetype="linux_secure" OR sourcetype="syslog")
| eval proc=lower(coalesce(Image, exe, process, ""))
| eval cmdline=lower(coalesce(CommandLine, command, ""))
| where (
(proc LIKE "%powercfg%" AND (cmdline LIKE "%energy%" OR cmdline LIKE "%batteryreport%" OR cmdline LIKE "%sleepstudy%"))
OR (proc LIKE "%systemd-inhibit%" AND (cmdline LIKE "%sleep%" OR cmdline LIKE "%shutdown%" OR cmdline LIKE "%idle%"))
OR (proc LIKE "%systemctl%" AND cmdline LIKE "%mask%" AND (cmdline LIKE "%sleep%" OR cmdline LIKE "%hibernate%" OR cmdline LIKE "%suspend%"))
)
| eval activity_type=case(
cmdline LIKE "%energy%" OR cmdline LIKE "%batteryreport%", "PowerReconnaissance",
proc LIKE "%systemd-inhibit%", "LinuxSleepInhibitor",
cmdline LIKE "%mask%", "LinuxSleepTargetMasked",
true(), "Other"
)
| eval host=coalesce(ComputerName, host)
| table _time, host, proc, cmdline, activity_type
| sort - _time Atomic Red Team Tests
Simulates a cryptominer or botnet disabling both AC and DC sleep timeouts to prevent the system from entering standby or hibernate, keeping the host available for malicious activity.
Command
powercfg /change standby-timeout-ac 0 && powercfg /change standby-timeout-dc 0 && powercfg /change hibernate-timeout-ac 0 && powercfg /change hibernate-timeout-dc 0 && powercfg /change monitor-timeout-ac 0 && powercfg /change monitor-timeout-dc 0 Cleanup
powercfg /change standby-timeout-ac 30 && powercfg /change standby-timeout-dc 15 && powercfg /change hibernate-timeout-ac 60 && powercfg /change hibernate-timeout-dc 30 && powercfg /change monitor-timeout-ac 15 && powercfg /change monitor-timeout-dc 10 Expected Telemetry
Windows Event ID 4688 or Sysmon EventID 1 for powercfg.exe with the full command line visible. DeviceRegistryEvents entries for HKLM\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes showing ACSettingIndex and DCSettingIndex values set to 0.
Expected Detection
PowercfgTimeoutDisabled alert from KQL detection branch 1. Multiple timeout types (standby, hibernate, monitor) should trigger the UniqueTimeoutTypes >= 3 hunting query.
Disables the Windows hibernation feature entirely using the powercfg hibernate off command, removing the hiberfil.sys file and preventing the system from hibernating — a technique used by persistent malware to avoid state loss on power transitions.
Command
powercfg /hibernate off Cleanup
powercfg /hibernate on Expected Telemetry
Sysmon EventID 1 or Security EventID 4688 with ProcessCommandLine containing 'powercfg' and '/hibernate off' or '-h off'. DeviceFileEvents showing deletion of C:\hiberfil.sys (if hibernate was previously enabled).
Expected Detection
PowercfgTimeoutDisabled alert from KQL detection branch 1 matching the HibernateDisabled condition. SPL query should match on 'hibernate off' in cmdline.
Simulates a Linux-targeting threat actor or botnet masking systemd sleep, suspend, and hibernate targets to prevent the system from entering any low-power state, as observed in Condi botnet and similar Linux malware campaigns.
Command
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target && sudo systemctl daemon-reload Cleanup
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target && sudo systemctl daemon-reload Expected Telemetry
Syslog or auditd entries showing systemctl execution with 'mask' and target names. If auditd EXECVE rules are configured, full command line will be captured. journalctl will show systemd unit mask operations.
Expected Detection
SPL detection matching systemctl process with 'mask' and 'sleep'/'hibernate'/'suspend' in command line. KQL hunting query for LinuxSleepTargetMasked should fire if cross-platform Defender for Endpoint Linux agent telemetry is available.