Detecting T1529 System shutdown/reboot

How T1529 system shutdown/reboot shows up in an intrusion

When a SOC lead sees hosts restarting or dropping offline in the middle of an incident, T1529 System Shutdown/Reboot is one of the explanations to test first. In MITRE ATT&CK, T1529 sits under the Impact tactic (TA0040), where the adversary is trying to manipulate, interrupt, or destroy systems and data. A shutdown or reboot is a simple way to interrupt service, so the technique is a direct expression of that goal rather than a side effect. The mappings described on this page target Enterprise ATT&CK version 20.0, and the reader should confirm which version their detection content references before comparing results across tools.

In intrusions, shutdown or reboot activity tends to appear late. It can follow defense impairment, where logging, endpoint protection or monitoring has already been degraded, or it can be part of a destructive phase alongside data destruction, encryption for impact or service stop. The timing matters: a restart that lands shortly after security tooling goes quiet deserves a different investigation path than one that appears in a routine maintenance window. Ask the change management team for the approved reboot calendar and the owners of each affected host so that unplanned events can be separated from planned ones within the first hours of triage.

The core difficulty is that legitimate reboots are routine. Patching cycles, kernel updates, hypervisor maintenance, failed power events and crashes all generate the same host status transitions that an adversary would produce. Detection therefore depends on context rather than on the event alone: who or what initiated the shutdown, whether a change record exists, whether the parent process is an expected management agent, and whether other suspicious activity on the same host or its neighbors occurs close in time. Confirm with each platform owner which of these fields their telemetry actually records before relying on them, because host status and process lineage are not always captured to the same depth on every system.

Which telemetry reveals a shutdown or reboot

This table maps each telemetry source to the shutdown or reboot signal it can reveal and the open-source collector that gathers it. Read it as a coverage checklist: a reboot is usually visible in several sources at once, so a gap in one source should be covered by another before you rely on it.

Telemetry source	Signal to look for	Open-source collector	Coverage gap to confirm
Process creation (DC0032)	Shutdown, reboot or halt commands launched by an unexpected parent, user or service account	Wazuh agent on Linux and macOS hosts, auditd or Sysmon-equivalent logging forwarded to Wazuh	Confirm the host logs process creation with command line arguments; without arguments, the shutdown verb is invisible
Command execution (DC0064)	Shutdown or reboot invoked through a script, remote session or scheduled job outside change windows	Wazuh agent command monitoring, shell history forwarding, Velociraptor queries for recent command activity	Interactive console sessions on appliances may not write to shell history; confirm what your devices record
Host status and uptime	Unexpected uptime resets, boot events and services stopping in a burst before a reboot	Wazuh system inventory and log collection, Zeek or node exporters for host availability trends	Uptime alone cannot show intent; pair it with a process or command record before escalating
ESXi host logs	Host entering maintenance or shutdown state, VM power-off events and host reboot messages	Syslog forwarding from ESXi hosts to a central Wazuh or Graylog collector	Confirm the ESXi syslog target, log level and retention in your environment; the vSphere event stream may need a separate export
Network device syslog	Reload, restart or power-cycle messages from routers, switches and firewalls	Syslog forwarding into Wazuh or a SIEM, with Zeek or Suricata watching management-plane traffic	Management traffic may be encrypted; confirm which events the vendor logs and whether they reach the collector
Network traffic to management interfaces	Unusual management sessions followed by a device restart or loss of reachability	Zeek connection logs and Suricata alerts on management ports, correlated with syslog timestamps	Session content is often encrypted, so rely on connection metadata, timing and source identity
Authentication events	Administrative logins to a host or device shortly before a shutdown or reboot	Wazuh authentication log decoders, syslog from network devices and hypervisors	Shared administrator accounts weaken attribution; confirm each operator has a named identity

Detection logic for shutdown and reboot activity

A reboot is rarely suspicious on its own, since patching and hardware faults cause most of them. T1529 detection works by attaching context to each restart: the command that preceded it, the change record that explains it, and the other hosts or hours around it. The cards below describe logic you can express in Wazuh, Security Onion or Sigma rules, with tuning advice and the false positives to expect.

Reboot preceded by administrative commands

Correlate host restart events with the shutdown or reboot commands that ran in the preceding few minutes, using Process Creation and Command Execution telemetry from Linux, macOS and Windows hosts. A restart with no recorded command, or one issued from an unexpected parent process or an unfamiliar account, is the strongest signal to triage first. Tune the lookback window to your change procedures so routine maintenance is matched cleanly. Expected false positives: scheduled patch jobs, kernel updates that require a restart, and automation tools that reboot nodes after configuration changes. Confirm each automation identity is on an allowlist.

Host status gaps without a change ticket

Track heartbeat or agent check-in gaps and compare each unplanned outage against your change management system. A host that goes silent and returns with a new boot time, but has no approved change in the same window, deserves review. Set the gap threshold above your normal agent reconnect time so brief network blips do not generate noise. Expected false positives: hypervisor-initiated migrations, cloud host maintenance events and laptops leaving the network. Ask your platform team to confirm which of these your environment produces before setting thresholds.

Multiple hosts restarting in a short window

Count distinct hosts that restart within a sliding window and group them by subnet, role or business service. A restart wave across unrelated systems is far more unusual than one host rebooting, and it matches the pattern of an operator or tool working across an estate. Choose the window and the host count from your normal patch cadence, and alert on departures from that baseline rather than on a fixed number. Expected false positives: scheduled rolling patch windows, cluster rolling updates and mass reboots after a power event. Correlate with facility or power alerts before escalating.

Restarts outside working hours

Flag restarts on production servers that fall outside the approved maintenance calendar, and weight them higher when the account involved is not normally active at that hour. The logic is simple, but the baseline must be per host class, since some workloads run overnight by design. Use your identity provider login times to see whether the restart came from a human session or a service. Expected false positives: time zone errors in logs, follow-the-sun support teams and overnight batch jobs. Verify that every log source is normalized to UTC before you rely on this card.

ESXi and network device restarts

Hypervisors and network devices carry high impact, so restarts on ESXi hosts and on switches, routers and firewalls should match an approved maintenance record. Collect reboot and configuration-change events from the vendor syslog streams and compare each restart with the maintenance calendar. An unmatched restart of a hypervisor can take down many virtual machines at once, so treat it as a priority. Expected false positives: vendor firmware upgrades that restart without a clear change label, and hardware watchdog resets. Confirm with your vendor documentation which events each device emits before writing the rule.

How to validate the T1529 detection in a lab

This sequence proves that the T1529 detection fires on a planned, authorized shutdown or reboot, that the alert carries usable host and user context, and that the same activity during a scheduled patch window is handled as a known false positive. The output is a validation record that shows the detection works, where it has gaps, and what must be retested after each rule change.

Agree scope and rules of engagement
The detection owner, the owner of the test host, and the change manager agree in writing which host, which accounts and which shutdown or reboot methods are in scope, and which systems are excluded. The agreement names the ATT&CK version the detection maps to, so that the test targets the same technique definition the rule was written against. The step is complete when all three parties have signed off on the scope document and the lab environment is confirmed as isolated from production.
Open a change record for the test
Raise a change record that describes the planned reboot on the test host, the time window, the named operator and the expected log sources that should record it. Attach a rollback and recovery note so the host can be brought back quickly if the test causes an unexpected outage. The step is complete when the change record is approved and the monitoring team has acknowledged that alerts from this host during the window are expected for the exercise.
Run the planned reboot on the test host
The operator performs one planned reboot on the test host using the approved method, following the change record exactly and avoiding any steps outside the agreed scope. A second observer records the start time, the method used and the account that initiated it, so the evidence can be compared against the alert later. The step is complete when the host has returned to service and the observer's timeline is saved with the change record.
Confirm the alert and its context
The detection engineer checks the security platform, such as Wazuh or Security Onion, for an alert tied to the test host and the test window. The alert should carry the host name, the initiating user or service account, the process and parent process context where the platform collects it, and a timestamp that can be matched to the observer's timeline. The step is complete when the alert is confirmed, its fields are compared with a checklist, and any missing fields are logged as gaps.
Test the false positive path in a patch window
During a scheduled patch window that includes a normal reboot, the team confirms whether the detection fires and whether the alert can be recognized as expected from the change record. The goal is to see if analysts can separate approved maintenance from unapproved shutdown activity using the fields the alert provides. The step is complete when the team has recorded each alert from the window, its classification, and the suppression or tuning decision, with the change reference attached.
Record time to alert and field coverage
The team writes a validation record that lists the time between the reboot and the alert, the fields present, the fields missing, and any gaps in log sources or parsing. Time to alert is measured from the observer's timestamp to the alert timestamp in the platform, so the figure reflects the actual pipeline. The step is complete when the record is reviewed by the detection owner and the gaps have an owner and a remediation item in the backlog.
Retest after every rule or pipeline change
Any change to the detection logic, log source configuration, parser or suppression rule triggers a repeat of the reboot test and the false positive check on the same lab host. The retest uses the same scope document and validation record template so results can be compared across versions. The step is complete when the new record shows the detection still fires with the expected fields and the change is linked to the validation history.

Preventive controls that limit unwanted restarts

Five ATT&CK mitigations reduce how often an adversary can shut down or reboot hypervisors, servers, and network devices. They work together: access control decides who can restart, permissions protect the scheduling configuration, segmentation and filtering limit who can reach management interfaces, and training helps operators spot unexpected restarts. Confirm how each one applies in your environment before relying on it.

Restrict who can restart hosts

ATT&CK mitigation User Account Management (M1018) limits which accounts can power off, reboot, or reset ESXi hosts, Linux servers, and network devices. Review who holds administrative roles on each hypervisor and device, remove shared or dormant accounts, and separate day-to-day operator rights from the rights to reboot production hosts. Confirm with your platform team which roles in your ESXi, Linux, and device management tools can trigger a restart, and log every change to those roles.

Protect reboot scheduling configuration

ATT&CK mitigation Restrict File and Directory Permissions (M1022) protects the cron entries, systemd timers, scheduled tasks, and automation jobs that can restart systems on a timer. Confirm that only the owning administrators can write these files, that service accounts cannot edit reboot jobs they do not need, and that changes to these locations raise an alert. Ask your team to list every scheduled restart in the environment so that an unfamiliar job stands out during review.

Segment management interfaces

ATT&CK mitigation Network Segmentation (M1030) places ESXi management interfaces, out-of-band controllers, and network device management ports on a dedicated management network. Reachability from user workstations or general server subnets to these interfaces should be the exception. Confirm which subnets can reach hypervisor management and device consoles in your design, and test whether a workstation on a standard user segment can still reach them.

Filter management plane exposure

ATT&CK mitigation Filter Network Traffic (M1037) applies allow-list rules to the management plane so that only named administrative hosts reach the protocols used for power and reboot operations. Review firewall and access control rules on hypervisor, controller, and switch management services, remove rules that allow any source, and record which jump hosts are permitted. Confirm that these rules are enforced at the device or host level as well as at the perimeter.

Train operators to question restarts

ATT&CK mitigation User Training (M1017) prepares administrators and change staff to treat an unplanned reboot as a potential security event. Cover how to verify a restart request against a change record, how to escalate an unexplained shutdown of a hypervisor or network device, and which channel to use. Confirm that the training is tied to your incident response process so that operators know who to contact and what evidence to preserve.

Triage steps when a reboot detection fires

Start by checking the change record, not the alert. A restart of an ESXi host, Linux server, macOS endpoint or network device is often routine patching, a vendor-driven firmware step or a scheduled maintenance window. Compare the host name, the timestamp and the reboot reason recorded by the platform against approved change tickets and maintenance calendars for that asset. If a matching change exists, confirm that the operator who performed it is the expected one and close the alert with that reference attached. If no change matches, do not yet assume an attack. Record the gap, because an unexplained restart is a finding in its own right, whatever its cause turns out to be.

Next, establish who or what initiated the shutdown or reboot. Review process creation and command execution telemetry on the host for the minutes before the restart, including the parent process, the user context and any remote session that was active. On network devices, review the management plane logs and the authentication events for the same window. The question to answer is whether the restart came from a known administrative path, an automated job, or an unrecognized account or process. Also check whether a restart was requested from another host, since a single compromised administrative account can reboot many systems in sequence. Confirm which of these facts your own logging actually captures before you rely on them, because gaps in coverage often explain the absence of evidence.

Then look sideways for related signals on the same asset and its neighbors. Reboots are rarely the only step in an intrusion that targets availability, so search for defense impairment alerts, service stop events and unexpected changes to recovery settings within the same window. Escalate the restart decision based on what you find. Restore service only after you have captured volatile state and copies of the relevant logs, such as the host's system journal, audit trail, hypervisor event stream or device configuration, because a reboot erases memory and may overwrite evidence. If the restart is unexplained, open an incident under your incident response process and let its lead decide between recovery and containment. Recovery restores availability, while containment isolates the host or segment, and the choice should rest on evidence of scope and business impact, not on the alert alone.

Rehearsing T1529 detection in a private cyber range

Build the range with a small ESXi cluster or nested virtualization host, plus several Linux guests that mirror production roles such as web, database and management servers. Forward host logs, hypervisor logs and process creation telemetry into the same Wazuh or Security Onion pipeline used in production, so the rehearsal tests the real collection path and not a lab shortcut. Confirm with your platform team which hypervisor and guest logs are retained and for how long, because detection depends on those logs existing.

Scheduled restart inject: Plan a maintenance-window restart of one guest with a matching change ticket, then check that the alert carries the host name, the time and the change reference.
Unscheduled restart inject: Restart a guest outside any window and confirm that the alert reaches triage with enough context to judge intent.
Multi-host restart inject: Restart several guests or a hypervisor host within a short period to test whether correlation groups the events into one incident.
Host status checks: Verify that the host status and uptime data the SIEM receives match what the hypervisor reports, since a gap here hides the event.
Recovery verification: Confirm that services return and that the team can state which restarts were expected.

Before the exercise, ask your Linux and virtualization owners to document which logs they can provide and the expected delay between an event and its arrival in the SIEM.

Questions detection engineers ask about T1529

How do I tell an attacker-driven reboot from a routine patch reboot?

Treat the reboot as a question of context, not of the reboot itself. A patch reboot usually follows a known package manager or update agent event, comes from an expected administrative account, and happens inside a change window that your change management system records. An adversary-driven shutdown often has no matching change record, is initiated from an unexpected parent process or session, comes from an account that does not normally administer that host, or follows discovery and tampering activity. Build the rule so it raises a higher-priority alert when the reboot lacks a matching change ticket or patch event within a short correlation window, and log the parent process, user and command line for triage. Confirm each field exists in your own environment before relying on it.

Do ESXi and network device logs actually reach our SIEM?

Verify it per source instead of assuming it. For ESXi hosts, confirm that the host syslog is forwarded to your collector and that shutdown and reboot events appear in the stream with a usable timestamp and host name. For network devices, confirm that the device sends syslog or an equivalent event feed, that the reboot or restart messages are enabled at the severity you need, and that the time source is synchronized with your collector. Run a controlled, approved reboot in a test or range environment and check that the event arrives, is parsed into fields and is searchable within your expected latency. Document the result per device model and firmware version, because message text changes between releases.

What should we do with devices that log very little host status?

Accept the gap, compensate for it, and record it as a known coverage limitation. Start by inventorying which devices produce reboot or restart events and which do not. For the gaps, look for indirect signals: loss of heartbeat or availability monitoring, unexpected uptime resets reported by your monitoring platform, changes in boot time collected by an agent, or a sudden drop in telemetry from the device. Each indirect signal is weaker than a direct shutdown event, so pair it with a lower-confidence alert and a documented triage step. Where the device supports it, ask the vendor or your platform team to enable higher logging levels, and track the open items in your detection backlog.

How often should we retest the T1529 rule after ATT&CK version changes?

Retest whenever the ATT&CK version your rules target changes, and also when your data sources or platform versions change. MITRE publishes ATT&CK releases that can rename, deprecate or revoke techniques and that replace detections with detection strategies and analytics, as happened in v18. Record the ATT&CK version each rule maps to, compare its technique and data component references against the new STIX bundle, and re-run your validation test after any mapping change. Recheck the rule after firmware, hypervisor or SIEM parser upgrades, since these often change log formats quietly. Set a review cadence in your detection governance process, and confirm the schedule with your own change board.

How do we tune the rule for maintenance windows without creating blind spots?

Suppress by evidence, not by blanket exclusion. Feed your change calendar into the detection pipeline so that a reboot matching an approved change ticket, host group and time window is logged at low priority rather than dropped. Require that the approval record match the host, the account and the window, so that a broad or long-lived exception cannot hide unrelated activity. Review every suppression on a schedule, expire it automatically where your tooling allows, and alert separately if a reboot occurs on a host that is in maintenance but outside its approved window. Keep the suppression logic in version control so auditors and responders can see when it changed and why.

Which data components should our T1529 detection depend on?

Focus on Process Creation, Command Execution and Host Status-type telemetry, and confirm how each one maps to the current ATT&CK release. In Enterprise ATT&CK 20.0, Process Creation (DC0032) and Command Execution (DC0064) are among the data components most often referenced by Impact detection strategies, which makes them the practical core for shutdown and reboot logic on Linux and similar platforms. Host status and availability data is a supporting signal, because it confirms the event happened even when command-level telemetry is missing. Check the STIX bundle for the version you target to confirm the current data component IDs before you write or document the mapping.

Can our own team rehearse this detection, or do we need outside help?

Your team can run the rehearsal, provided it has the right environment, approvals and skills. The core steps are to build an isolated test scope, run an approved shutdown or reboot under known conditions, confirm the events arrive in the SIEM, verify the rule fires with the expected priority, and capture the response steps. Cost and effort depend on how many platforms you cover, how much of the logging path is already built, whether you have a private cyber range, and how much time your analysts can give to the exercise. Outside help is useful when you need an independent test plan or repeatable range scenarios. Ask any provider for a written scope, the list of platforms covered, and the deliverables before work begins.

How DeployOpen builds T1529 detections and range scenarios

DeployOpen approaches T1529 System shutdown/reboot as a fixed-scope engagement inside your own infrastructure. We agree what is covered in writing, build detections on open-source telemetry, rehearse them in a private cyber range and hand over documented evidence your teams can run and maintain.

How we scope

Confirm which platforms are in scope for T1529, such as ESXi, Linux, macOS and network devices.
Map existing Process Creation, Command Execution and Host Status telemetry to the detection logic before any build starts.
Record the ATT&CK version targeted, since releases can rename or revoke techniques and mappings must stay traceable.

How we build

Write detection logic in open formats such as Sigma and deploy it to your Wazuh or Security Onion stack.
Check that host status and shutdown or reboot events reach the SIEM with the fields the rules depend on.
Tune alert thresholds against planned maintenance windows so routine restarts do not bury genuine shutdown activity.

How we hand over

Deliver a written runbook covering triage, containment and recovery steps for unexpected shutdown or reboot alerts.
Document each detection with its ATT&CK mapping, data source dependencies and known blind spots.
Run a rehearsal in a private cyber range with your responders, then hand over the scenario scripts and results.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-test T1529 detections when platforms, log sources or ATT&CK versions change in your environment.
Ask any vendor or DeployOpen quote to itemize scope, deliverables and what recurs after the initial build.

T1529 System shutdown/reboot