T1489 Service stop

A service stop on its own is weak evidence of an attack. Patching windows, configuration changes, autoscaling events, failed deployments and routine restarts all stop services every day, often through the same service managers, the same hypervisor management interfaces and the same automation accounts that an adversary would use. An alert that fires on the stop alone will mostly describe maintenance, and analysts who learn to close those alerts quickly will close the one that matters too. Detection for T1489 Service stop should therefore treat the stop as the start of an investigation, not as its conclusion.

The useful question is whether the stop can be tied to an approved change and to a plausible reason. Correlate each stop event with the change record in your ticketing or change management system, the deployment pipeline run that touched the host or cluster, and the autoscaling or maintenance schedule for that workload. Then check the host state: was the service expected to stop, did it restart cleanly, and did the stop come from an identity that normally administers that system? Stops that cannot be matched to any of these sources, that come from an account with no recent administrative history on the host, or that occur outside the maintenance window deserve escalation. Confirm with the owning team which of your service managers, hypervisor interfaces and orchestration tools write stop events to your logs and with which fields, because the answer determines what correlation is possible.

Finally, the stop must be followed through to its effect. A stopped service that was expected to be down during a change should produce no outage in dependent services, no failed health checks that persist and no unexpected loss of data access. When a stop is followed by failed dependencies, degraded application responses or unexplained changes on the same host within a short period, the event moves from routine operations to a probable incident. Document this decision path in the runbook so that the first responder records the change match, the host state and the downstream impact for every escalated stop, and so that auditors can see the same logic applied consistently.

When a service stop alert fires for T1489 Service stop, the first decision is whether the stop was authorized. Check the change calendar, the maintenance tickets and the on-call handover notes for the affected host or cluster before anything else. A stop that matches an approved change window can be closed with evidence attached, while an unexplained stop of a security control, a backup agent, a logging forwarder or a hypervisor management service should be treated as a live incident. Next, identify the account and session that issued the stop. On Linux, that means the user that ran the service manager command and the login source behind it. On ESXi, it means the vCenter or host account and the source address of the management session. Confirm whether the account was used for other activity in the same window, and whether it was recently created, elevated or changed. Record the exact time of the stop, because every later step depends on that timeline. Next, map the business impact before you restart anything. List the services that depend on the stopped unit, such as applications that fail when a database listener or message broker goes down, and note which ones are customer-facing or subject to recovery time commitments. Decide whether containment is needed. If the account is suspected, disable or lock it, revoke its active sessions and rotate any credentials it could reach. If the host is suspected, isolate it at the network layer while keeping it powered on, so volatile state survives. Before any restart, preserve evidence: collect service manager logs, journal entries, the relevant Wazuh alerts and Velociraptor artifacts for process and service state, and a copy of the unit files and configuration in their current form. Hash what you collect and record who collected it and when. Coordinate with the incident response owner from the first hour, and agree with them who approves the restore. Restore services from a known-good configuration, not by editing the current unit files in place. Compare the running configuration with the versioned source held in your configuration management system, and confirm the restore point is one that predates the suspected activity. Restart dependencies in the order your runbook defines, and check health at each step. Then close the loop: confirm which detections fired, whether the alert was actionable, and whether the account or host baseline needs adjustment. Ask your managed service provider or internal team to confirm, in writing, the evidence retention period in your Wazuh or Velociraptor deployment before you rely on it for an investigation.

DeployOpen starts every T1489 Service Stop detection engagement with a written scope that names the platforms in play, such as ESXi hosts, IaaS control planes, Linux servers and any macOS endpoints, and the telemetry the client can actually provide, such as process creation events, file deletion events and process termination records. The scope also states which service-stop paths matter most to the client, for example stops of hypervisor management services, backup agents or database daemons, because those are the stops that carry business impact. Agreeing these points in writing before work begins keeps the detection logic tied to the client's real estate rather than a generic rule pack. Confirm with your team which platforms and log sources are in production today and which are planned, since a detection cannot be tuned against telemetry that is not collected.

Each detection is mapped to the ATT&CK version named in the engagement, and the mapping records the technique, its detection strategy and analytics, and the data components it relies on, such as Process Creation (DC0032) and File Deletion (DC0040). Because ATT&CK releases can rename, deprecate or revoke content, the mapping file states the exact version it targets, so later upgrades show what changed. DeployOpen then exercises the detections in a private cyber range that mirrors the client's platforms. Purple team runs cover the mitigations the client has in place, including User Account Management (M1018) and Restrict File and Directory Permissions (M1022), so the team can see whether a blocked stop is also a detected stop. Scenarios are scripted against an agreed plan, and the expected alerts are recorded before each run, so gaps and false positives are measured rather than assumed.

DeployOpen hands the tuned rules to the client's security engineers with the test results, the scenario definitions, known gaps and the tuning decisions behind each threshold. Rules are delivered in the client's chosen format, which may be Sigma or the native format of the SIEM or Wazuh deployment, and the handover includes the steps to load and validate them in the client's environment. Ask in any proposal who owns the rules after handover, how re-testing is scheduled when ATT&CK or the client's platforms change, and what evidence will be delivered for internal or external audit review. DeployOpen prepares that evidence, but independent auditors and certification bodies decide whether it meets their requirements.