---
{
  "title": "Service Stop",
  "summary": "Service stopping interrupts functionality or prepares another action by disabling a component.",
  "topic": "grc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    3
  ],
  "aliases": [
    "T1489"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1489: Service Stop",
      "url": "https://attack.mitre.org/techniques/T1489"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Service stopping interrupts functionality or prepares another action by disabling a component. The operational impact depends on which service and dependencies are affected.


## An investigation example

A suspicious account stops backup and business services shortly before destructive file activity.

## Evidence to examine

Review service control events, caller identity, approved maintenance, dependent outages, and follow-on execution.

## A common analytical pitfall

Service shutdowns also occur during normal updates; evaluate the surrounding sequence and approvals.

## Response considerations

Contain unauthorized control, preserve stop events, and restore services only after assessing the cause and related compromise.


## Stopping a component can enable a wider impact

A service can provide business functionality, protection, logging, or recovery support. Stopping it may directly interrupt users or remove a dependency needed by another action. The same administrative capability is also used during legitimate maintenance. Analysts need to understand the service's role and the sequence around its termination.

Record which identity requested the stop, which process or management interface initiated it, and whether an approved change explains the event. Repeated attempts across unrelated services may carry different significance from one expected restart. A service being stopped is not proof that the system was compromised, nor does a running service guarantee it is functioning correctly.

## A fictional interrupted application

An academy's reporting service stops shortly before records are modified unexpectedly. Investigators compare service-control events with the application and identity logs. They ask whether the stop was required for approved maintenance or whether it helped an unauthorized operation avoid normal processing or detection. The answer depends on correlated evidence, not just the proximity of timestamps.

Restarting the service may restore immediate functionality, but first consider whether its configuration or executable has changed and whether evidence will be lost. Coordinate the response with the service owner, preserve relevant records, and verify normal behavior after recovery. Repeated automatic restarts can obscure the original sequence.

## Interpret a short event sequence

Create fictional events for a login, service stop, configuration change, and service start. Write a benign maintenance explanation and an unauthorized explanation. Identify the approval, process ancestry, and file-integrity evidence that would help distinguish them. This develops contextual analysis without disabling a real protective or business service.

Monitoring should check the business function as well as process state. A restarted service may be running but unable to reach its database or read its configuration. Verification that a representative workflow succeeds provides more useful recovery evidence than a green process indicator alone.

## Related concepts

- [[business-continuity]]
- [[disaster-recovery]]
- [[incident-response]]
- [[data-destruction]]
- [[data-encrypted-for-impact]]