How T1653 Power settings supports persistence and where SOC teams see it
If you are a SOC lead or detection engineer who needs coverage for T1653 Power settings under the Persistence tactic (TA0003), you need to know that this technique helps an adversary keep a foothold by changing how a system manages power, so access can survive the conditions that would otherwise end it. Telemetry for it on Windows, Linux, macOS and network devices centers on Process Creation, Command Execution and File Modification. MITRE defines the Persistence tactic as the adversary trying to maintain their foothold, and this technique is one way that goal is pursued.
What an adversary gains is continuity with less exposure to routine operations. A host configured to stay reachable or to avoid the states that interrupt activity keeps a foothold longer without needing a new entry point. In intrusions, changes like this usually appear alongside other persistence methods, so a power configuration alert is most useful when correlated with account, service or autostart activity on the same host. Illustrative example: a single settings change on an endpoint, followed by unexplained overnight activity from that host, would justify an investigation, though it does not prove compromise on its own.
Mappings change between ATT&CK releases, so record the version your detections target. These pages use Enterprise ATT&CK 20.0, released by MITRE on 2026-10-13. Before you rely on any mapping, confirm in the 20.0 enterprise-attack STIX bundle which platforms, detection strategies, data components and sub-techniques the technique currently references. Check the MITRE ATT&CK updates page for renames, deprecations or revocations that could affect the technique in your environment.
Which telemetry reveals T1653 Power settings across platforms
This table maps the data components ATT&CK most often references for Persistence techniques to T1653 Power settings, with one row per data component and platform group. Read each row as a telemetry source, the signal to alert on, and the open-source collector that brings it into Wazuh, Security Onion or a Velociraptor hunt. Process and command telemetry covers most platforms, while network device coverage depends on syslog forwarding. Confirm the exact T1653 mapping in the enterprise-attack 20.0 STIX bundle before writing analytics.
| Data component | Platforms | Signal to look for | Open-source collector |
|---|---|---|---|
| Process Creation (DC0032) | Windows | Power configuration utilities launched from unexpected parent processes or outside change windows | Sysmon-style process logging forwarded to the Wazuh agent |
| Process Creation (DC0032) | Linux and macOS | Power management utilities or scheduled power actions started by accounts that do not normally manage power | auditd execve records collected by the Wazuh agent |
| Command Execution (DC0064) | Windows | Script block or command logs showing changes to power plan or sleep and hibernate settings | PowerShell logging collected by Wazuh, with Velociraptor for retrospective hunts |
| Command Execution (DC0064) | Linux and macOS | Shell or service commands that alter power state, idle timers or lid and suspend behavior | auditd command records via Wazuh, with Velociraptor artifacts for macOS unified logs (confirm coverage) |
| File Modification (DC0061) | Windows and Linux | Changes to power configuration files, registry-backed policy stores or systemd power settings | Wazuh file integrity monitoring (syscheck) with Velociraptor for targeted file hunts |
| File Modification (DC0061) | macOS | Changes to system power preference property lists outside managed configuration profiles | Wazuh file integrity monitoring on preference paths, confirmed per macOS version |
| Command Execution and Process Creation (confirm) | Network devices | Configuration change events that alter power, environmental or idle settings on managed devices | Device syslog forwarded to Security Onion, with Zeek or Suricata for management session context |
| Mapping check | All platforms | Confirm which data components the T1653 entry in the Enterprise 20.0 bundle references before tuning rules | Review the STIX bundle and record the version used in the analytic |
Detection logic for T1653 Power settings that SOC teams can tune
T1653 Power settings is a Persistence technique, so the detections below focus on changes to power configuration that persist across reboots or sessions. Each card pairs a telemetry source with a baseline to tune and the benign activity that will flood the queue if it is left unexcluded.
Process creation on Windows power utilities
Alert when a power configuration utility runs from an unexpected parent process, under an unexpected account, or outside a maintenance window. Process Creation (DC0032) is the usual source, and Sigma is a practical format for sharing the rule across SIEM backends. Baseline the parent process and account pairs per host group for two to four weeks before enabling alerting. Expected false positives come from administrators running power plan scripts by hand, endpoint management agents that enforce power policy at logon, and patch tooling that reboots machines with scheduled power settings.
File modification on Linux and macOS
Watch configuration files and directories that govern sleep, suspend, hibernate and power management on Linux and macOS hosts. File Modification (DC0061) events from a file integrity monitor, such as the Wazuh syscheck module, are the main signal. Tune by excluding package manager writes and configuration management runs, and alert on writes by interactive sessions or unexpected service accounts. Expect false positives from desktop environment updates, laptop power profile tools and configuration management agents that rewrite files on every convergence cycle.
Command execution correlated with startup or scheduled context
Correlate a power setting change with a new scheduled task, startup entry or cron job created in the same window. Command Execution (DC0064) on its own is noisy, but the pairing of a power change followed by persistence-related context is far more specific. Tune the correlation window to match your change control cadence, and suppress known imaging and maintenance jobs by name and signer. Expect false positives from imaging tools, first-boot provisioning scripts and help desk scripts that set power plans and create tasks together.
Network device configuration change alert
On network devices that expose power or hardware management features, alert on configuration commits that change power or sleep behavior and are not linked to an approved change ticket. Feed device configuration logs and syslog into the SIEM and compare each change against the change management record. Baseline normal change frequency per device class so that routine maintenance windows do not trigger constant alerts. Expect false positives from scheduled firmware maintenance, vendor support sessions and automated backup or compliance scanning tools that touch configuration.
Privileged change review and exception handling
Route every confirmed power setting alert through a documented triage path that checks the change ticket, the account, and whether the host is in a planned maintenance group. Keep a tuning log that records each suppression with its owner, reason and review date so exclusions do not silently widen. Validate the workflow in the cyber range before production use. Expect the largest false positive volume during patch cycles, so tie suppressions to those windows rather than to permanent allow lists.
How to validate the T1653 detection in a lab before production
This sequence proves that the T1653 Power settings detection fires on an approved, scoped emulation of the behavior, and it records the evidence needed before the rule moves to production. It turns a rule that looks correct on paper into one whose alerts, timing and false positive profile the team has measured.
Define the emulation scope and ATT&CK reference
The detection owner and the security lead agree in writing on the technique reference, the ATT&CK version the mapping targets, the platforms in scope (Windows, Linux, macOS and network devices), and the data components the rule depends on, such as Process Creation, Command Execution and File Modification. Name the ATT&CK version explicitly, because releases can rename or deprecate techniques. The step is done when the scope document is approved and stored with the detection record.
Confirm telemetry reaches the platform
Before any emulation, the platform engineer checks that the agents, collectors and log sources named in the scope are sending events to Wazuh or Security Onion, and that timestamps are synchronized across hosts. Missing telemetry is the most common cause of a silent detection failure, so this check comes first. The step is done when a known benign event from each in-scope source is visible in the search interface with the expected fields.
Run the approved emulation in the range
The red or purple team runs the agreed emulation of the T1653 behavior inside the private cyber range, following the scope document rather than an improvised plan. The operator logs the start and end times of each action and the host it ran on, so the results can be matched to events later. The step is done when the operator's activity log is complete and signed off by the test lead.
Confirm expected alerts in the platform
The analyst reviews Wazuh or Security Onion for alerts that match the emulation window and host list. Each expected alert should be traced to the rule ID that produced it, and any expected alert that does not appear is logged as a gap. The step is done when every planned action has either a matching alert or a documented gap with a probable cause.
Record timestamps, rule IDs and false positives
The analyst records, for each action, the emulation timestamp, the alert timestamp, the delay between them, the rule or decoder identifier, and any unrelated alerts that fired in the same window. Unrelated alerts are labeled as false positives with a short reason, such as a scheduled maintenance task. The step is done when the results table is complete and reviewed by the detection owner, and it becomes the baseline for later comparison.
Tune the rule and re-run the emulation
The detection owner adjusts the rule to close gaps or reduce false positives, for example by narrowing a field match or adding an exclusion for a documented administrative activity, and records each change with its reason. The same emulation scope is then run again against the tuned rule. The step is done when the second run shows the expected alerts, the reduced false positive count, and a change log tied to the rule version.
Approve promotion to production
The security lead reviews the baseline, the tuned results and the change log, then decides whether the rule can move to production, must be tuned further, or should stay in the range. Production promotion should include a note on the ATT&CK version, the data sources required, and the known limits found during testing. The step is done when the approval and its conditions are recorded, and a review date is set for re-validation after the next ATT&CK release.
Preventive controls that reduce T1653 exposure
T1653 Power Settings abuses configuration that most estates never review, so preventive work centers on making power and system configuration changes visible and constrained. The cards below cover the primary mitigation, Audit (M1047), and the supporting mitigations that the ATT&CK STIX bundle maps most often to Persistence techniques.
Audit configuration and process activity
Audit (M1047) is the primary mitigation for T1653. Enable operating system auditing for process creation and changes to power management settings on every endpoint class in scope, then forward those events to a central store. The evidence this produces is a timestamped record of who changed a power setting, from which process, and on which host. Confirm the mitigation text and its mapped techniques for your ATT&CK version in the enterprise-attack STIX bundle before you cite it in a control matrix.
Baseline power configuration
Define a approved baseline for sleep, wake, hibernation and any power-related scheduled behavior on each platform, and record it as code or as a configuration management profile. Drift from that baseline is the signal you want to see. The evidence is the baseline file itself, the last compliance scan result per host, and a list of approved exceptions with owners. Ask your configuration management vendor which settings they can report as drift without custom scripting.
Restrict who can change power settings
Limit local administrative rights so that routine users cannot alter system-wide power or boot-time behavior. This is the main application of Privileged Account Management (M1026) to this technique, and it should be confirmed for your estate in the STIX bundle rather than assumed. The evidence is a current list of accounts with local administrator rights per device class, reviewed on a schedule you document.
Protect files and registry keys that store settings
Where power behavior is stored in files or registry values, apply Restrict File and Directory Permissions (M1022) so that only designated service and administrative identities can write to them. Pair this with Windows Registry Key Modification logging where the platform supports it. The evidence is an access control list export for the protected paths and a test showing that a standard user write attempt is denied and logged.
Limit uncontrolled change paths
Use Disable or Remove Feature or Program (M1042) to remove power utilities, scripting hosts or remote management features that the estate does not need on endpoints and servers. Fewer available tools reduce the number of ways a power setting can be changed without an audit trail. The evidence is a documented list of removed or disabled components and the build record showing the change, with any exceptions tied to a named owner.
Triage steps when a T1653 detection fires
The first decision on a T1653 Power settings alert is whether the change was authorized, and that question is answered before anyone touches the host. Pull the change record for the affected Windows, Linux, macOS or network device and compare it with the event time, the account that made the change and the setting that moved. Power settings changes are often part of standard imaging, laptop lifecycle or energy policy work, so an approved change ticket that matches the host, user and timestamp usually closes the alert with a documented reason. If no ticket exists, treat the alert as an unexplained configuration change and continue the triage. Confirm with your change manager which change sources are authoritative in your environment, such as a configuration management system, a Group Policy or MDM record, or a network device change log, because a missing ticket in one system may still be covered in another.
Next, compare the device with its approved baseline. On Windows, that means the effective power plan, sleep and hibernate timers, and any lid, button or idle actions as they were captured by your configuration management tooling. On Linux, check the power management settings applied by your desktop or systemd configuration. On macOS, check the energy settings profile. On network devices, check the configuration against the golden copy. Then pivot on the same host and the same user across the persistence-related detections, particularly T1547 Boot or logon autostart execution and T1543 Create or modify system process, along with any T1037 or T1098 alerts in the same window. A power setting change that appears alongside new autostart entries or service changes is a materially different case from one that stands alone, so record the pivot results even when they are negative. Preserve evidence before remediating. Velociraptor or an equivalent collection tool can capture the relevant registry or configuration files, the event logs covering the change window and the current power configuration, with hashes recorded and chain of custody noted. Decide on containment only after this evidence is in hand, and document the decision, the owner who made it and the escalation path, including who is notified for suspected unauthorized changes on critical hosts.
Rehearsing T1653 detection and response in a private cyber range
The Windows range should include a domain controller, a domain-joined workstation and a member server, all on a segmented lab network. Endpoint telemetry is forwarded to a Wazuh manager, and network sensor feeds reach a Security Onion node through a mirrored span port. Injects arrive as scenario events, such as a report that a workstation's power behavior changed outside a change window, so analysts must work from the telemetry rather than from a known command.
- Range topology: one domain controller, one workstation, one member server, a Wazuh manager with agents, and a Security Onion node. Confirm with your Windows administrators which event categories are already collected.
- Injects: a scenario event reports unexplained wake or sleep behavior on a workstation, followed by a later report of a scheduled task on the same host.
- Good detection: process creation events for the power configuration utility are correlated with the parent process, the account and the host, and a Wazuh or Sigma-based alert fires within the window the exercise team agreed.
- Good response: the analyst records the first event time, the account, whether the change survived a reboot, and the systems touched, then hands the case to the platform team with those timings.
Before the exercise, check that the alert reaches the on-call queue and that the handoff template includes the timing fields your auditors will ask for.
Linux hosts in the range should be a mix of a general-purpose server and a jump host, both enrolled with Wazuh agents and configured for file integrity monitoring over the locations that hold power and system management settings. Auditing should be enabled for changes to those paths. Security Onion collects host and network context so analysts can see what happened before and after a configuration change. The scenario uses events, such as a change ticket that does not match an observed configuration change, so the team must prove the change from host evidence.
- Range topology: a server, a jump host and a Wazuh manager, with Security Onion watching the segment. Confirm which paths and audit rules your distribution and hardening baseline already cover.
- Injects: a scenario event reports a host waking at an unusual hour, and a later change record references a maintenance window that was never opened.
- Good detection: file modification events on the monitored power configuration locations generate a Wazuh alert that names the file, the user and the process context, and the analyst can match it to the audit trail.
- Good response: the analyst preserves the modified file and its prior state, notes the time of first change, and confirms whether other hosts in the same configuration group show the same change.
- Handoff: the record goes to the platform owner with the host list, the evidence hash and the time between detection and containment.
Close the exercise by checking that detection still fires after a configuration management run, because approved automation can produce the same file changes.
macOS hosts in the range should reflect the managed fleet your organization actually runs, with the endpoint management platform and logging agent confirmed before the exercise. Power settings on macOS are stored in system configuration and can be changed through management profiles, so the range should test whether the team can tell an approved profile push from an unapproved change. The scenario relies on events such as a user report of a laptop that stays awake overnight and an unexplained entry in the management console.
- Range topology: one managed laptop, one managed desktop and a log collector feeding the Wazuh manager. Confirm with your endpoint team which logs and file paths the agent can read on each supported macOS version.
- Injects: a scenario event reports a laptop with altered sleep behavior after a user logged in from an unfamiliar network, followed by a profile appearing in the management console.
- Good detection: the detection separates profile-based changes from direct edits, and the alert includes the profile identifier, the enrolling account and the device serial.
- Good response: the analyst checks whether the profile is in the approved catalog, records the time of installation and the time of first alert, and isolates the device through the management platform if the profile is unapproved.
- Handoff: the endpoint team receives the device record, the profile details and a list of other devices that received the same profile.
Before the exercise, verify that your management platform exposes profile installation history, since that history is often the fastest route to a conclusion.
Network devices in the range should include a switch, a firewall or router and an out-of-band management path, all sending syslog to the Wazuh manager and, where supported, to Security Onion. Many devices record configuration changes in logs or allow configuration backups that can be compared over time. The scenario uses events, such as a maintenance report that mentions a device restart and a backup file that differs from the previous one, so analysts must confirm the change against both logs and backups.
- Range topology: one switch, one firewall, one out-of-band console server and a syslog path into Wazuh. Confirm the vendor's logging and configuration backup options before building the lab.
- Injects: a scenario event reports a device restart during a window with no approved change, and a later backup comparison shows a power-related parameter that differs from the last approved configuration.
- Good detection: a configuration change message in syslog is correlated with the backup diff and the change ticket, and a Wazuh rule flags the event for review within the agreed window.
- Good response: the analyst records the device, the parameter, the time of change and the management path used, then restores the approved configuration under change control.
- Handoff: the network team receives the backup versions, the syslog excerpt and the change ticket reconciliation, with timings for each step.
Check that the team can reach the out-of-band path during the exercise, because a response that depends on the affected management path will fail under pressure.
Questions SOC leads ask about detecting T1653 Power settings
How does T1653 map to ATT&CK 20.0 and what changed in v19 or v20?
T1653 Power Settings is a Persistence technique, so it appears under the Persistence tactic (TA0003) in the Enterprise matrix. Map your detections to the ATT&CK version you run, because releases can rename, deprecate or revoke techniques. The recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. v18 replaced technique-page detections with detection strategies and analytics and deprecated data sources, so older rules may cite retired references. Confirm T1653's status, any sub-techniques and its data component references in the enterprise-attack 20.0 STIX bundle, then read the ATT&CK updates page for changes to this ID before you promote rules.
Which data components should we enable first for T1653 detection?
Enable Process Creation, Command Execution and File Modification first, since these are the telemetry sources the ATT&CK mapping points to for this technique. Each one answers a different question:
- Process Creation shows which binary, parent process and account initiated a change.
- Command Execution shows the arguments and the context of administrative commands.
- File Modification shows writes to the configuration files that hold power settings.
Wire these into Wazuh, Security Onion or your existing collector and confirm each host forwards them before you write any rule. Verify the data component IDs against the current bundle, because component references change between versions.
How do we reduce false positives from endpoint management tools?
Start by inventorying every endpoint management agent, script and scheduled job that changes power configuration on your fleet. For each one, record its parent process, signing identity, service account and normal change window. Build allowlists on that combination of attributes rather than on a process name alone, since names are easy to reuse. Scope the allowlists by host group so a change that is normal on workstations stays visible on servers and network-adjacent systems. Review the allowlist after each management tool upgrade, because new agent versions often change parent processes and command formats. Keep a log of every suppression with an owner and an expiry date.
How can we test T1653 detections without disrupting production?
Test in a private cyber range that mirrors your build images, management stack and logging pipeline, and keep it isolated from production networks. Replay known benign administrative changes first to measure false positives, then run controlled, documented exercises that produce the telemetry the rule expects. Record which events fire, how long they take to reach the SIEM and whether the alert carries enough context to triage. Promote a rule only after it passes that review. DeployOpen builds and operates private cyber ranges inside the client's own infrastructure, and scope, deliverables and timelines for that work are agreed in writing before it starts. Confirm with your team how the mitigation Audit (M1047) is already applied, since audit configuration is a prerequisite for the telemetry.
How do we tell a sub-technique alert from the parent technique?
Read the technique ID carried in the rule metadata. A sub-technique ID in ATT&CK ends with a three-digit suffix, such as T1059.001, and a parent-level ID does not. Confirm in the enterprise-attack 20.0 bundle whether T1653 currently has any sub-techniques, since that determines which IDs your rules can carry. Keep both levels in alert enrichment so an analyst can see the parent tactic and the narrower behavior together. If a rule maps to the parent only, document that choice so reviewers do not assume a more specific mapping exists. Revisit the mapping after each release, because sub-techniques are added and changed over time.
How do we keep T1653 detection mappings current over time?
Treat the ATT&CK mapping as a versioned dependency. Pull the STIX 2.1 bundle for each new Enterprise release from the mitre-attack/attack-stix-data repository, compare the technique objects against your last version and flag any change to T1653 or its data components. Assign a named owner who re-runs the range tests, updates rule metadata and records the ATT&CK version each rule targets. Schedule a review after each release, and check the updates page for renames, deprecations or revocations. Ask your managed support provider, if you use one, to include this review in the written scope so ownership is clear before the next release arrives.
How DeployOpen builds T1653 detections and range scenarios
DeployOpen starts every T1653 Power settings engagement with a written scope that names the platforms in play, which of them are Windows, Linux, macOS or network devices, and which telemetry the client can actually supply. For this technique, the scope should be explicit about power configuration changes on endpoints and the process, command and file activity that accompanies them, because those are the signals that a detection can rely on. The scope also records the ATT&CK version the mapping targets, since the technique and its data component references can change between releases. Ask the provider to state in the statement of work which deliverables are rule files, which are tuning reports, and which are range results, and to confirm the fixed timeline and acceptance criteria before any work begins.
On the client's own stack, the detection work is built and tuned in the tools the security team already operates. Sigma rules are written from the telemetry model, then converted for the SIEM or data platform in use, with Wazuh, Security Onion, Suricata, Zeek and Velociraptor used where they provide the relevant visibility. Each rule is reviewed against normal administrative activity, such as scheduled power policy changes made by management tooling, so that the false positive profile is documented before go-live. Where a platform does not expose a needed field, the report says so and names the collection change required, instead of implying coverage that does not exist. Confirm with the vendor which log sources and fields each platform version supports in your environment.
Detections are then exercised in a private cyber range using purple team scenarios that replicate the technique on lab copies of the client's operating systems, with the blue team watching the alerts fire or fail to fire. Results are recorded per scenario: what was executed, what was logged, which rule responded, and what tuning was applied. This evidence supports compliance readiness conversations, such as mapping the controls the client already claims to the monitoring they have in place, but DeployOpen prepares that evidence and does not issue audit reports or attestations, which remain the role of independent auditors. Ongoing tuning as the environment and ATT&CK content change is available as a retainer, and the fixed-scope engagement ends with a handover that the client's own team can maintain.
