MITRE ATT&CK T1489 Service Stop: Detecting and Limiting the Damage

Ransomware operators stop databases, backup agents and hypervisor workloads seconds before encryption, and a service stop is often the last event you can still act on. MITRE ATT&CK T1489 Service Stop is an Impact (TA0040) technique: an adversary stops or disables services so that they are unavailable to legitimate users, so that data stores are released for encryption or destruction, or so that response is slowed. This guide covers how the technique shows up on Windows, Linux, macOS, VMware ESXi and cloud control planes, the detection strategy MITRE maps to it, the controls that stop an attacker reaching service control at all, and how to measure coverage. It is written for detection engineers, SOC analysts and platform owners and covers defence only. For the tactic-level picture, see the ATT&CK Impact Tactic Guide.

Key takeaways

• It is a precursor, not an end in itself. ATT&CK says services may be stopped so that the adversary can run Data Destruction (T1485) or Data Encrypted for Impact (T1486) against stores such as Exchange, SQL Server and ESXi virtual machines.
• It is one of the most used Impact techniques. In the ATT&CK v20 dataset T1489 is linked to 7 groups and 50 malware families, most of them ransomware.
• Every route needs privilege. Stopping a service needs local administrator, root, an ESXi shell role or a cloud management account permission; restricting those rights prevents more than any detection.
• Volume and target are the signal. One service stopping is normal. Many stops in a short window, or any stop of backup, database, security or hypervisor services outside a change window, is the alert.
• Plan for the stop you miss. Out-of-band communications, isolated backups and pre-agreed restart runbooks limit the damage when service stops are followed by encryption.

What T1489 describes

ATT&CK v20 lists T1489 under the Impact tactic for ESXi, IaaS, Linux, macOS and Windows. It has no sub-techniques. The technique description covers three goals:

• Denial of service to users: stopping a single high-value service, such as MSExchangeIS to make Exchange content inaccessible, or stopping or disabling many services so that the system becomes unusable. ATT&CK records Lazarus Group stopping MSExchangeIS and Olympic Destroyer calling ChangeServiceConfigW to disable all services.
• Releasing data for destruction or encryption: services such as database engines hold locks on their files. Stopping them lets an encryptor or wiper reach the data. ATT&CK records Sandworm Team attempting to stop the MSSQL service before Prestige encryption, and Royal using the Restart Manager call RmShutDown to close applications holding target files.
• Cloud service disruption: ATT&CK gives the AWS Organizations DisableAWSServiceAccess API as an example. AWS documents that it can only be called from the management account, and that afterwards the integrated service can no longer create service-linked roles in new accounts in the organisation.

How it relates to neighbouring techniques

Malware entries in ATT&CK often mix these. Clop, for example, is recorded as killing processes and services related to backups and security solutions, which touches T1489 and T1685 at once. Map detections to the target of the stop, not to the command used.

Where it shows up

• Windows server estates: the encryptor or a script stops backup, database, mail and security services with net stop, sc, taskkill, PowerShell Stop-Service or direct Service Control Manager API calls. ATT&CK records Wizard Spider using taskkill.exe and net.exe to stop backup, catalog and cloud services before encryption. The CISA advisory on Medusa ransomware (March 2025) says the encryptor process gaze.exe terminates all services related to backups, security, databases and communication.
• VMware ESXi: virtual machines are powered off or their processes killed so that VMDK files can be encrypted. ATT&CK records Cheerscrypt using esxcli vm process kill, LAPSUS$ shutting down virtual machines in on-premise ESXi, and VIRTUALPITA starting and stopping vmsyslogd. See the ESXi Ransomware Playbook.
• Linux: systemctl stop or service ... stop against databases, web servers and backup agents, followed by file deletion or encryption; MITRE's Linux analytic pairs the stop with unlink activity on data paths.
• macOS: launchctl bootout or disable against background services, then destructive commands.
• Operational technology: ATT&CK records EKANS stopping database, backup, antivirus and ICS-related processes. For plant-side impact, see the ATT&CK for ICS Inhibit Response Function Tactic Guide.
• Cloud control planes: trusted access for organisation-wide services disabled, managed services stopped or scaled to zero through a compromised management identity.

Detection

ATT&CK v20 maps one detection strategy, DET0021 "Behavioral Detection for Service Stop across Platforms", with an analytic per platform. The table combines MITRE's analytics with the Windows events defenders normally have.

Windows System event 7040 (start type changed, for example to disabled) and 7045 (new service installed) are useful companions to 7036: attackers often disable a service so that it does not restart, and remote execution tools install a temporary service to run the stop commands. See the Windows Event Log Guide.

Detections to build first

1. Burst of stops: more than a threshold of distinct services entering the stopped state (7036) or disabled (7040) on one host within a few minutes, or the same stop command across many hosts. Set the threshold from your patch-night baseline.
2. Protected-list stops: any stop or disable of a named list: backup agents, database engines (MSSQL, Oracle, PostgreSQL, MySQL), Exchange, Volume Shadow Copy, hypervisor management agents and security tools. Alert outside change windows.
3. Stop then touch data: a stop followed within minutes by mass file writes, renames or deletions on the same host, which matches MITRE's behavioural chain.
4. ESXi mass power-off: many VMs powered off from the shell or by a single account in a short window, especially followed by datastore writes.
5. Remote service control: service stops issued from another host through SMB named pipes, PsExec-style service installs (7045) or WMI, by an account that does not normally administer the target.

Tuning notes

• Patching and backups stop services legitimately. Feed change calendars and patch-orchestration account names into the rule so that suppressions are explicit, not silent.
• Restart Manager is noisy. Installers use it daily; alert on it only when combined with unsigned or new binaries or with mass file modification.
• Service accounts matter. Many stops come from deployment and backup service accounts. A stop from such an account against a service it never manages is a strong lead.

Prevention and hardening

ATT&CK v20 lists five mitigations for T1489. The table expands them into concrete settings.

Platform controls beyond the list

• Protected anti-malware services: on Windows 8.1 and Server 2012 R2 and later, a security vendor with an Early Launch Anti-Malware driver can register its service as protected (SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT). Microsoft documents that non-protected processes, even administrators, then cannot stop the service or inject into it. Confirm your EDR uses it and that tamper protection is on.
• Service recovery actions: set restart-on-failure for critical services and alert when the recovery configuration is changed or the start type is set to disabled.
• ESXi: lockdown mode, SSH and ESXi Shell disabled by default, vCenter accounts separated from the Windows domain where possible, and execInstalledOnly enforced so that unsigned binaries cannot run. See the VMware ESXi Hardening Guide.
• Cloud guardrails: deny organizations:DisableAWSServiceAccess and stop or delete calls on production data services to all but a break-glass role through organisation policies, and require approval workflows for service integration changes.
• Backups outside the blast radius: backup servers and their credentials outside the production domain, with immutable copies, so that stopping the backup agent does not also remove recovery. See the Backup Identity Isolation Guide.

Choosing controls by size

How to implement

1. Build the protected-service list: per platform, name the services whose stop would hurt (backup, database, mail, hypervisor management, security, identity). Owners sign it off.
2. Baseline: collect two to four weeks of 7036, 7040 and 7045 events, systemd stop messages and ESXi hostd power operations; note which accounts and tools stop which services.
3. Deploy in report-only: run the first five detections for two weeks, tie every hit to a change ticket or tune the suppression.
4. Restrict privilege: remove standing admin and shell access in rings, starting with backup and database servers. Rollback is restoring the group membership or policy.
5. Turn on alerting and response: route bursts and protected-list stops to the on-call queue with a runbook that says who can isolate the host.
6. Test: in a lab or an approved maintenance window, stop a test service from an unexpected account and power off a test VM from the ESXi shell; measure time to alert. See the Purple Teaming Guide.

Detection and measurement

• Telemetry coverage: percentage of servers and ESXi hosts forwarding the service events above to the SIEM. Target close to 100 percent.
• Protected-list coverage: percentage of critical services with an alerting rule and an owner.
• Unattributed stops: protected-list stops per month with no matching change record. Target zero.
• Time to alert: median time from a test stop to analyst notification, measured each quarter.
• Standing service-control rights: number of accounts able to stop services on tier-zero and backup systems, trending down.

Common failure patterns

• Only alerting on encryption: by the time ransom notes appear, the service stops a few minutes earlier were the missed warning. Alert on the stops.
• Suppressing all stops at night: blanket patch-window suppression hides the burst that ransomware operators deliberately time for the same hours.
• Ignoring the hypervisor: Windows guests are monitored but ESXi hostd logs are not forwarded, so mass VM power-off goes unseen. The Storm-0501 hybrid cloud attacks show how ransomware operators move across on-premise and cloud estates; every layer needs its own service telemetry.
• Backup agent and backup server share a domain: the same stolen admin can stop the agent and delete the repository.
• No out-of-band plan: when Exchange or chat services are stopped, responders lose their own coordination channel.

Framework mapping

Where identity fits

Every T1489 route runs through an identity with service-control rights: a local or domain administrator, a software deployment or backup service account, an ESXi root or vCenter role, or a cloud management account principal. Those service accounts often hold rights on hundreds of servers and are rarely monitored like human admins. Inventory them, scope each to the services it really manages, remove interactive logon, and alert when one stops a service outside its normal set. See the Service Account Security Guide.

Practitioner checklist

• Publish a protected-service list per platform with named owners.
• Forward System 7036, 7040 and 7045, Sysmon 1, auditd EXECVE, macOS unified log and ESXi hostd events to the SIEM.
• Alert on bursts of service stops and on any protected-list stop outside a change window.
• Correlate stops with mass file modification on the same host.
• Remove standing admin and shell access to backup, database and hypervisor hosts.
• Confirm the EDR runs as a protected service with tamper protection on.
• Put ESXi in lockdown mode and enforce execInstalledOnly.
• Deny cloud service-integration and production stop actions to all but break-glass roles.
• Keep backups and their credentials outside the production domain.
• Test an out-of-band communication channel every quarter.

Standards and references

• MITRE ATT&CK: Service Stop (T1489)
• MITRE ATT&CK: Impact (TA0040)
• CISA: #StopRansomware: Medusa Ransomware (AA25-071A)
• Microsoft Learn: Protecting anti-malware services
• AWS: DisableAWSServiceAccess API reference
• MITRE D3FEND: Process Spawn Analysis
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ATT&CK Impact Tactic Guide · ESXi Ransomware Playbook · Medusa Ransomware Threat Actor Profile · Top 10 Financial Services Cyber Threats · Ransomware Prevention Guide