Overview

Service Stop (T1489) is a technique where adversaries deliberately halt or disable running services on a target system to prevent legitimate users from accessing them or to enable follow-on destructive activity. Attackers use this to take critical business services offline — such as database engines, mail servers, backup agents, or endpoint security tools — either to cause direct operational damage or to unlock data files that can then be encrypted or destroyed.

Every security team needs visibility into service stop activity because it is a reliable late-stage indicator of ransomware or wiper deployment, often occurring minutes before mass encryption begins. Missing this signal means losing the last actionable window to intervene before significant business impact occurs.

Attacker Perspective

Attackers use service stop as a deliberate enablement step that clears the path for destruction, encryption, or denial of service by removing the software guards protecting critical data.

• Ransomware pre-encryption sweep (Windows): Ransomware families like REvil, LockBit, and BlackCat execute batch loops using net stop <service> /y and sc stop <service> to terminate database (MSSQLSERVER, MySQL80), backup (VeeamDeploymentSvc, BackupExecAgentAccelerator), and AV services (WinDefend, MsMpEng) before encrypting files, because these services hold exclusive locks on their data stores.
• ESXi hypervisor jackpotting: Threat actors such as those behind Cheerscrypt and BlackBasta ESXi variants use esxcli vm process kill --type=force --world-id=<id> and vim-cmd vmsvc/power.off <vmid> to forcibly power off all running virtual machines so their VMDK flat files can be accessed and encrypted without filesystem locks.
• Incident response disruption (Linux): Attackers use systemctl stop <service> and systemctl disable <service>, or service <name> stop, to kill EDR agents, syslog forwarders (rsyslog, syslog-ng), and auditd itself — deliberately blinding defensive tooling before conducting further operations.
• Cloud API abuse (AWS): Using compromised high-privilege IAM credentials, attackers call organizations:DisableAWSServiceAccess to prevent AWS services from creating service-linked roles across an organization, disrupting security tooling like GuardDuty or Security Hub that depend on those roles for cross-account visibility.

This technique is attractive precisely because it is often a native operating system capability requiring no custom tooling, making it blend into normal administrative activity and leaving a very short window between execution and impact.

Detection Strategy

Required Telemetry

• Windows — System Event Log, Service Control Manager: Enable auditing of service state changes. Event ID 7036 (service entered stopped/running state) and 7040 (start type changed) are generated by default in the System log (%SystemRoot%\System32\winevt\Logs\System.evtx) with no additional configuration. Ensure these logs are forwarded to your SIEM.
• Windows — Security Event Log, Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging: GPO path Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled, or registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with full command-line arguments — critical for catching net stop, sc stop, and taskkill invocations.
• Windows — Sysmon (Event ID 1, 5, 13): Deploy Sysmon with a configuration that captures process creation (Event ID 1), process termination (Event ID 5), and registry value changes (Event ID 13). Sysmon provides richer parent-child process context than native 4688 events. Use the SwiftOnSecurity or Olaf Hartong Sysmon config as a baseline.
• Windows — Security Event Log, Audit Policy Changes: Event ID 4719 captures audit policy modifications; attackers sometimes disable auditing before stopping services. Enable via Audit Policy Change → Success and Failure.
• Linux — auditd rules for process execution and service management: Add the following rules to /etc/audit/rules.d/service-stop.rules:
  -a always,exit -F arch=b64 -S execve -F path=/usr/bin/systemctl -k service_stop
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/service -k service_stop
-a always,exit -F arch=b64 -S kill -k process_kill
  These generate audit records in /var/log/audit/audit.log with full argument lists. Forward via auditbeat, Filebeat, or rsyslog to your SIEM.
• Linux — systemd journal: journalctl records service unit state transitions. Ensure journald is configured to forward to syslog (ForwardToSyslog=yes in /etc/systemd/journald.conf) and that syslog is shipping to your SIEM. Look for journal entries containing Stopped, Deactivated, or Failed for critical units.
• macOS — Endpoint Security Framework / EDR telemetry: Native macOS does not produce service stop events in a SIEM-friendly format without an EDR or the Endpoint Security Framework. Ensure your macOS EDR is configured to log launchctl unload, launchctl bootout, and kill syscalls. Apple Unified Log (via log stream or log collect) captures com.apple.launchd messages for service state changes.
• ESXi — shell and API logs: Enable ESXi Shell logging and forward /var/log/shell.log and /var/log/hostd.log to your SIEM. These capture esxcli and vim-cmd commands. Also enable vSphere API call logging in vCenter via vpxd logs at /var/log/vmware/vpxd/vpxd.log.
• AWS CloudTrail: Ensure CloudTrail is enabled with management events (read and write) across all regions. The relevant API calls are organizations:DisableAWSServiceAccess, iam:DeleteServiceLinkedRole, and guardduty:DeleteDetector. These appear in CloudTrail as eventName values in the CloudTrail log source. Confirm multi-region trail is active in your AWS Organizations management account.

Key Indicators

• Windows Event ID 7036 — mass service stop burst: In the System event log, field param2 = stopped with multiple unique values of param1 (service name) occurring within a short time window (e.g., 10+ services stopped within 60 seconds from the same host). This is the clearest ransomware pre-encryption signal.
• Windows process creation — net.exe stopping services: In Event ID 4688 or Sysmon Event ID 1, look for Image ending in net.exe or net1.exe with CommandLine matching net stop * /y. High-confidence pattern: CommandLine CONTAINS "net stop" AND CommandLine CONTAINS "/y".
• Windows process creation — sc.exe service control: Image = sc.exe with CommandLine matching patterns like sc stop <servicename> or sc config <servicename> start= disabled. Particularly suspicious when the stopped service is a security or backup product: CommandLine CONTAINS "WinDefend" OR "MsMpEng" OR "VeeamDeploymentSvc" OR "BackupExec".
• Windows process creation — taskkill targeting security processes: Image = taskkill.exe with CommandLine containing /f /im followed by known AV/EDR process names such as MsMpEng.exe, cb.exe, CSFalconService.exe, bdagent.exe.
• Windows — suspicious parent process for service stop commands: net stop, sc stop, or taskkill spawned by an unusual parent such as cmd.exe → wscript.exe, powershell.exe, mshta.exe, or any process running from a temp directory (ParentImage CONTAINS "\Temp\" OR "\AppData\").
• Linux auditd — systemctl stop on critical services: In auditd records with key=service_stop, look for a1 (argument) = stop or disable targeting service names such as auditd, rsyslog, sshd, or any EDR agent daemon (e.g., falconctl, cbdaemon).
• ESXi — mass VM power-off via shell: In /var/log/shell.log, look for repeated occurrences of vim-cmd vmsvc/power.off or esxcli vm process kill within a short window, particularly if executed from an interactive session outside normal maintenance hours.
• AWS CloudTrail — security service deletion: eventName = DeleteDetector (GuardDuty), DisableSecurityHub, StopLogging (CloudTrail), or DisableAWSServiceAccess. Any of these from a non-automation IAM principal or outside a change window should be treated as high severity. Check userIdentity.arn and sourceIPAddress for anomalies.

Detection Logic

Rule 1 (Broad — high sensitivity): Mass service stop burst on Windows
IF EventID = 7036 AND param2 = "stopped" THEN count(distinct param1) BY host WITHIN 60 seconds >= 10 → ALERT HIGH

This catches the wide-net service-stop sweep used by ransomware families before encryption. Expected volume is very low in healthy environments — legitimate patching may trigger a handful of stops but rarely 10+ unique services in 60 seconds. Tune the threshold based on your environment’s baseline during patch windows.

Rule 2 (Medium — process-based): Service stop commands from anomalous parent processes
IF (Image ENDS WITH "net.exe" OR Image ENDS WITH "sc.exe" OR Image ENDS WITH "taskkill.exe") AND (CommandLine CONTAINS "stop" OR CommandLine CONTAINS "disabled") AND ParentImage NOT IN ["services.exe", "svchost.exe", "msiexec.exe", "SCCM_known_process_list"] THEN ALERT MEDIUM

This catches attackers using scripting engines, malicious documents, or reverse shells to invoke service stop commands. Legitimate IT tooling almost always chains through services.exe or a known management agent as the parent. Medium volume expected — requires tuning for your patch management toolchain.

Rule 3 (Narrow — high precision): Service stop targeting security and backup products
IF (Image ENDS WITH "net.exe" OR Image ENDS WITH "sc.exe" OR Image ENDS WITH "taskkill.exe") AND CommandLine CONTAINS_ANY ["WinDefend", "MsMpEng", "CSFalconService", "cbdaemon", "VeeamDeploymentSvc", "BackupExecJobEngine", "SQLWriter", "MSSQLSERVER", "MSExchangeIS"] THEN ALERT HIGH

This is a precision rule targeting the exact services that ransomware and destructive malware prioritize stopping. Very low false positive rate — legitimate administrators almost never stop these services via command-line one-liners outside of documented maintenance. Expect near-zero benign alerts; investigate every firing.

Rule 4 (Cloud): AWS security service disabled via API
IF eventSource = "guardduty.amazonaws.com" AND eventName = "DeleteDetector" OR eventSource = "cloudtrail.amazonaws.com" AND eventName = "StopLogging" OR eventName = "DisableAWSServiceAccess" AND userIdentity.type NOT IN ["Service"] AND userAgent NOT CONTAINS "terraform" THEN ALERT HIGH

This catches adversaries disabling cloud-native detection capabilities using compromised IAM credentials. Exclude known automation principals (Terraform, CloudFormation service roles) by ARN. Any human-identity principal triggering this outside a documented change window should be treated as a confirmed incident until proven otherwise.

Tuning Guidance

• Patch management and software deployment tools (SCCM, Intune, Ansible, Chef): These tools legitimately stop and start services during software installation. Identify the process names and service accounts used by your deployment tooling and exclude them: ParentImage IN ["ccmexec.exe", "msiexec.exe", "ansible-runner"] OR user IN [svcSCCM, svcAnsible]. Baseline during known patch windows to establish normal volume.
• Windows Update and servicing: Windows Update stops services like wuauserv, bits, and sometimes IIS during cumulative updates. These stop events originate from TiWorker.exe or TrustedInstaller.exe as parent processes. Add exclusion: ParentImage CONTAINS "TiWorker.exe" OR ParentImage CONTAINS "TrustedInstaller.exe".
• Legitimate database maintenance windows: DBAs routinely stop SQL Server services during maintenance. Detect this legitimate activity by correlating with your ITSM change management system — if a change ticket exists for the time window and host, suppress the alert. Alternatively exclude: user IN [sa_dba, svcSQL] AND hours BETWEEN 02:00 AND 06:00 if maintenance windows are consistent.
• Security product updates (AV/EDR self-update): Some endpoint security products stop and restart their own services during self-update. These will appear as service stop events for the exact process names in Rule 3. Identify the update process name for your security stack (e.g., SenseCnfg.exe for Defender for Endpoint) and add it as a parent exclusion.
• Linux container orchestration and CI/CD pipelines: Jenkins build agents, Docker daemon operations, and Kubernetes node maintenance can trigger systemctl stop events at high volume. Exclude by the invoking user account (user IN [jenkins, gitlab-runner, k8s-node-agent]) or by source host type (CI worker nodes identified by hostname pattern).

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event in the source log. Pull the raw System Event ID 7036 or process creation Event ID 4688/Sysmon Event ID 1 from your SIEM using the exact host name, timestamp, and EventID from the alert. Confirm the event is not a duplicate, replay, or parser artifact before proceeding.
2. Identify the affected host and the account that performed the action. Extract the Computer field from the event and look up the host in your asset inventory — note its role (domain controller, database server, workstation), OS, business criticality, and owner. Check the SubjectUserName or user field and flag immediately if the account is a service account, administrator, or has elevated privileges.
3. Pull the full command-line and reconstruct the parent process chain. In Sysmon Event ID 1 or 4688, capture CommandLine, Image, ParentImage, ParentCommandLine, and ProcessGuid/ParentProcessGuid. Use ProcessGuid chaining to walk the full ancestor tree — if the chain leads to cmd.exe spawned by wscript.exe or an Office application, treat this as confirmed malicious.
4. Identify which services were stopped and assess business impact. Query Event ID 7036 for all param2 = "stopped" events on the same host within a ±30-minute window and list the unique service names (param1). Cross-reference against your critical service inventory — if backup agents, AV services, or database engines are in the list, escalate immediately as a likely ransomware precursor event.
5. Check for files written to disk and network connections around the same timeframe. Use Sysmon Event ID 11 (FileCreate) and Event ID 3 (NetworkConnect) on the same host in the ±10-minute window around the alert. Look for new executables or scripts dropped in %TEMP%, C:\ProgramData, or C:\Windows\Temp, and for outbound connections to unusual IP ranges or on non-standard ports.
6. Search for lateral movement originating from this host. Query your SIEM for authentication events (Windows Security Event ID 4624 logon type 3, or 4648 explicit credential use) sourced from the affected host to other internal systems in the past 24 hours. Also check for new SMB connections, RDP sessions, or WMI/PSRemoting activity using Sysmon network events or your EDR’s lateral movement detection.
7. Make the escalation decision — confirmed incident vs. benign administrative action. Escalate to a confirmed incident if any of the following are true: the stopped services include security tools or backup agents; the parent process chain is anomalous or routes through a scripting engine; files were dropped to temp directories; network connections to external IPs were made; or lateral movement is detected. If all activity traces cleanly to a documented maintenance ticket and known admin account, close as a false positive after documenting your reasoning in the ticket.

Response Playbook

Containment

• Isolate the host immediately but leave it powered on: Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Device Isolation, or equivalent) to cut off network access while preserving volatile memory and process state for forensics. Do not power off — you will lose in-memory artifacts including encryption keys if ransomware is mid-execution.
• Disable the implicated user account: In Active Directory, use Disable-ADAccount -Identity <username> or the ADUC console to immediately disable the account that executed the service stop commands. If the account is a service account, coordinate with the application owner before disabling to understand downstream impact.
• Kill the malicious process if still running: Use your EDR’s remote kill capability or, if you have shell access on an isolated host, identify the process by PID from the Sysmon events and terminate it. Do not do this before capturing process memory if your IR procedure allows it.
• Block identified C2 infrastructure at the perimeter: If network connections to external IPs were identified in Step 5 of the investigation, push blocks to your firewall and DNS filter immediately. For cloud environments, update Security Group rules or Network ACLs to deny outbound traffic to those destinations.
• Revoke active cloud sessions and tokens: If the activity involved AWS, Azure, or GCP, immediately invalidate the IAM credentials or access tokens used. In AWS: iam:UpdateAccessKey --status Inactive and attach an explicit deny policy to the user. In Azure: revoke all active sessions via Conditional Access or Revoke-AzureADUserAllRefreshToken.
• Snapshot affected cloud resources before remediation: If ESXi VMs or cloud instances are involved, take forensic snapshots using vSphere snapshot or cloud-native snapshotting before making changes, to preserve evidence and enable recovery.

Eradication

• Remove identified persistence mechanisms: Search the affected host for new scheduled tasks (Event ID 4698, or schtasks /query), new services (Event ID 7045), autorun registry keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), and WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter). Delete any entries not present in your baseline.
• Find and delete dropped payloads and tools: Based on the file write events identified in the investigation (Sysmon Event ID 11), enumerate and hash all files written to temp directories during the attack window. Submit hashes to VirusTotal or your threat intel platform, then delete confirmed malicious files. Preserve copies in quarantine for forensic analysis.
• Reset credentials for all accounts involved: Reset passwords for every account that authenticated from the affected host during the attack window, not just the directly implicated account. Assume any credentials cached on the host (LSASS, credential manager, browser stores) are compromised. Force token revocation for cloud identities.
• Check lateral movement targets for persistence: For every host the affected system connected to during the attack window, run the same persistence check (scheduled tasks, new services, autorun keys) to ensure the attacker did not establish footholds on those systems before containment.
• Rotate any secrets or API keys that may have been accessed: Review the host’s running applications and configuration files for embedded secrets, API tokens, or cloud credentials. Rotate all of them as a precaution. For AWS environments, run aws iam list-access-keys for affected principals and rotate immediately.

Recovery

• Verify the host is clean before reconnecting it to the network: Have a senior analyst or IR lead sign off that all persistence mechanisms are removed and a full AV/EDR scan returns clean. If confidence in the host’s integrity is less than high — for example, if the attacker had weeks of access or used a rootkit — re-image from a known-good gold image rather than attempting in-place remediation.
• Restart stopped services in the correct order: Re-enable and start all services that were stopped by the attacker, beginning with security services (AV, EDR agent, log forwarder) before returning the system to production. Verify each service reaches a running state and is generating expected telemetry in your SIEM before proceeding.
• Re-enable the user account only after confirming no persistence remains: Before restoring the account, confirm the account’s MFA device is intact and not registered to a new device, review its role and access permissions for unnecessary privileges, and notify the account owner of the incident and required security steps.
• Monitor the affected host and account for 72 hours post-remediation: Create a temporary high-sensitivity detection rule scoped to the specific host and user that alerts on any service stop, new process creation from temp directories, or outbound network connections for 72 hours. Review these alerts manually rather than relying on automated suppression.
• Document the full timeline and update detections: Write an incident timeline from first indicator to containment and capture all new IOCs (file hashes, IPs, service names, account names). Submit IOCs to your threat intel platform and update detection rules to incorporate any gaps discovered — for example, if the attacker used a service stop command pattern not previously covered by Rule 3, add it now.