Critical service disruption

Threat snapshot

Windows services are the backbone of both operating system functionality and enterprise application delivery. Security tooling, backup agents, endpoint detection software, database engines, web servers, and hundreds of other critical components run as Windows services. The ability to start and stop services via net.exe, the native Windows network management utility, is a routine administrative capability. In an attacker's hands, it becomes a tool for simultaneously disrupting defenses, disabling backup mechanisms, and creating operational chaos.

Two distinct threat patterns are covered by the detection rules in this use case. Stopping critical services is a pre-ransomware preparation step: attackers stop backup agents, database services, and security tools before deploying an encryptor to ensure these services cannot protect data or interfere with the encryption. Starting services is a different signal: it may indicate an attacker launching a previously installed malicious service, re-enabling a disabled monitoring bypass tool, or restoring a service that was stopped to make room for a replacement payload. Log360 detects both via the Start Windows Service Via Net.EXE and Stop Windows Service Via Net.EXE rules, which monitor for net.exe invocations carrying service start and stop arguments respectively.

At a glance

How this attack works

The net.exe utility provides direct command-line control over Windows services. The start and stop operations take the following forms:

net stop <servicename> -- stops a running service

net stop <servicename> /y -- stops a service and all dependent

services without prompt

net start <servicename> -- starts a stopped service

Service names may be the short internal service name (such as wuauserv for Windows Update, or MSSQLServer for SQL Server) or the display name in quotes. Attackers commonly use both forms and frequently chain multiple stop commands in rapid succession to bring down a group of services before deploying a payload. The /y flag suppresses the confirmation prompt for services that have dependent services, ensuring the stop command completes without requiring interactive input.

Stopping services: pre-ransomware and defense evasion

Stopping services before ransomware deployment serves three purposes. First, security services such as Windows Defender, endpoint protection agents, backup agents, and logging collectors must be stopped because they would either block the encryption or preserve clean copies of files that would undermine the ransom leverage. Second, database and application services that hold file locks must be stopped so that the encryptor can access and encrypt the underlying data files. Database files that are open and locked by a running SQL Server or Exchange instance cannot be encrypted without stopping the service first. Third, backup services must be stopped to ensure no new backup jobs run during the encryption window that would create a clean recovery point.

The services most commonly stopped in pre-ransomware sequences include backup agent services (Veeam, Acronis, Windows Server Backup), database services (SQL Server, MySQL, Oracle), security and endpoint protection services, and shadow copy and volume snapshot services. A sequence of multiple net stop commands in rapid succession across several different critical service names is a high-confidence pre-ransomware preparation indicator.

Starting services: persistence and tool re-enablement

Net start in an attack context serves different purposes. An attacker who has previously installed a malicious service (a RAT, a reverse shell listener, or a persistence agent) uses net start to launch it, either after initial installation or after it was stopped by a security tool. An attacker who disabled a service to prevent interference and now needs to re-enable it for cover uses net start to restore the expected service state before leaving the host. In some post-exploitation scenarios, net start is used to activate a service that was disabled as part of a misconfiguration exploit, where the service configuration was modified by the attacker to point to a malicious binary before being started.

The asymmetry between stop and start signals

Stopping services via net.exe is a more immediate threat signal than starting them. A sequence of net stop commands targeting security, backup, and database services is almost exclusively associated with ransomware pre-deployment and warrants immediate escalation. Starting services is a more ambiguous signal: it may represent an attacker activating a malicious service, but it may also represent legitimate administrative activity. The service name being started is the critical triage factor for the start rule. Starting a service with a name that does not match any documented software installation, or starting a service whose executable path points to a user-writable directory, is high confidence malicious.

Attack chain

The table below maps each stage of a critical service disruption attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A logistics company runs its order management platform on a Windows Server infrastructure. The platform depends on a SQL Server database service, a Veeam backup agent, and a third-party endpoint protection service. A threat actor who has been operating inside the network for eight days using a compromised IT operations account has completed their reconnaissance and is ready to deploy ransomware.

In a scripted preparation sequence that runs in under 90 seconds, the attacker executes seven net stop commands in rapid succession from a remote PowerShell session: stopping the Veeam backup service, the SQL Server service, the Windows Defender service, the endpoint protection service, the Windows Volume Shadow Copy service, and two additional database-related services. They then execute a net stop command for the Windows event log service using the /y flag to suppress the dependent service prompt.

Log360 fires the Stop Windows Service Via Net.EXE alert after the first command. Seven alerts fire within the 90-second window. The SOC analyst reviewing the first alert immediately recognises the Veeam service name in the context of ransomware pre-staging and escalates. By the time the incident response team begins isolation, the attacker has already deployed the encryptor. However, because the ransomware deployment process had only begun encrypting files on two of the six servers targeted before isolation, the majority of the data is preserved.

Why this happens

Net stop is a standard Windows administrative command. Service management via net.exe is routine in Windows environments, used by IT administrators, software installers, and automation scripts constantly. Without specific detection rules targeting service stop operations on high-value service names, or monitoring for the volume and velocity of stop commands in a short window, the pre-ransomware service disruption sequence is indistinguishable from routine administrative activity at a glance. The speed of the sequence, combined with the specific mix of security, backup, and database service names, is the signal that separates ransomware preparation from legitimate administration.

Business impact: What can go wrong

Critical service disruption via net.exe carries both immediate operational consequences and downstream security consequences depending on the services targeted:

• Security tool disablement: stopping endpoint protection, EDR agents, and logging services creates a detection blind spot on the affected host. Any attacker actions taken after security services are stopped will not be monitored, logged, or blocked by those tools, giving the attacker free operation during the most critical phase of their attack.
• Backup destruction without deletion: stopping backup agents before ransomware deployment is more effective than attempting to delete existing backups, because it ensures no new backup job runs during the encryption window. The most recent clean backup was created before the service was stopped, maximising the data loss scope.
• Database data accessibility: database services that hold file locks on their data files must be stopped before those files can be encrypted. Successfully stopping database services means all data stored in those databases, including customer records, financial data, and transaction histories, is directly accessible and encryptable.
• Operational disruption: stopping production services such as web servers, application servers, and database engines causes immediate service unavailability independent of any subsequent ransomware deployment. In environments where the service disruption is the primary objective, operations can be paralysed by the service stop commands alone.
• Malicious service persistence: a net start command used to activate a malicious service establishes a running process with full service-level privileges that restarts automatically on reboot. A malicious service that survives remediation because it was not identified and removed continues to operate indefinitely as a persistence mechanism.
• Recovery complexity: stopping the Windows Event Log service, which is a documented ransomware pre-deployment step, destroys the ongoing log stream for the period during which services are stopped and ransomware is deployed. This forensic gap makes incident scoping more difficult and may limit breach notification accuracy.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Start and Stop Windows Service Via Net.EXE rules can fire reliably, ensure the following are in place:

• Windows Process Creation auditing with command-line logging is enabled on all monitored endpoints, generating Event ID 4688 with the full ProcessCommandLine field populated. Both rules depend on the net.exe command-line arguments being visible. Without command-line logging, net.exe execution will appear in the log but the start or stop verb and the service name that determine whether the activity is suspicious will not be captured.
• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 1 (Process Create). Sysmon provides the parent process chain that is essential for distinguishing attacker-initiated service manipulation from legitimate administrative activity. A net stop command issued from a scheduled task or a remote session has a very different risk profile from the same command issued interactively by a known administrator.
• Windows System event log forwarding is configured to capture Service Control Manager events (Event ID 7036: service state changed). These events confirm that the net.exe commands actually resulted in service state changes, as opposed to command-line arguments that were formed but did not successfully execute.
• Endpoint agents or Windows Event Forwarding are configured to forward Security, System, and Sysmon logs from all monitored endpoints to Log360. Service manipulation occurs on individual endpoints and the relevant telemetry is endpoint-local. Coverage must include all servers hosting critical services, not only domain controllers.

Note: The service name in the net stop or net start command is the most important triage field for both rules. Configuring Log360 to surface the service name prominently in the alert notification, rather than requiring the analyst to drill into the event detail, significantly reduces the time from alert receipt to triage decision. Identify the specific service names that represent your highest-value targets (backup agents, database engines, security tools) and configure alert severity overrides that trigger immediately when any of those specific names appear in the command arguments.

Detecting critical service disruption using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable both rules: Start Windows Service Via Net.EXE and Stop Windows Service Via Net.EXE. Configure an alert profile for the same.

Step 2: Read the alert

The alert will display the hostname, the account that ran net.exe, the full command line including the verb (start or stop) and the service name, the parent process, and the timestamp. For the stop rule, review the service name immediately against your watchlist of high-value services. A backup agent or endpoint protection service name requires immediate escalation. For the start rule, verify the service name against your documented software inventory and check the service's executable path. A service starting from an unusual or undocumented path is high confidence malicious.

Investigating an alert

When either service disruption rule fires, an L2 analyst should work through the following steps:

• Identify the service name and assess its operational significance. For a stop command, determine immediately whether the service is a security tool, backup agent, database service, or logging service. These categories represent the highest-risk stop targets. For a start command, verify the service name against the documented software inventory and check whether a service with that name is expected to be running on that host.
• Check for additional net stop commands in the same session. Query Log360 for all net.exe and net1.exe process creation events on the same host in the 120 seconds surrounding the alert. If multiple stop commands appear targeting different critical service categories in rapid succession, treat this as a confirmed ransomware pre-staging sequence and escalate immediately.
• Identify the parent process chain. Open the Incident Workbench and trace the process tree back from net.exe. Determine whether the command came from an interactive administrator session, a remote session, a script, or a malware process. A remote PowerShell session from an unrecognised source IP issuing stop commands to critical services is the highest-confidence attack scenario.
• For a service start alert, examine the service executable path. Query the Windows registry path HKLM\SYSTEM\CurrentControlSet\Services\<servicename>\ImagePath or use sc qc remotely to retrieve the service configuration. If the ImagePath is a user-writable directory or an unrecognised binary, the service being started is attacker-controlled. Identify the binary, hash it, and check its digital signature.
• Check whether the affected services are still in the stopped state. If net stop commands targeted security services, confirm whether those services are currently stopped on the affected host. A stopped endpoint protection or backup service that has not been restarted indicates that the host is currently in a degraded security state. Treat any subsequent activity on that host as occurring without security tooling protection.
• Verify against documented administrative activity. Check the change management system for any approved maintenance window, software update, or service configuration change that would explain the service manipulation. If no ticket exists and the account owner cannot confirm the activity, treat the event as confirmed malicious.

Escalation trigger

Escalate immediately to L3 if three or more net stop commands targeting different critical service categories fired within a 60-second window on the same host; if any of the stopped services were security tools or backup agents; if the parent process of net.exe is in a user-writable directory or is an unrecognised binary; if a net start command is activating a service whose executable path is in AppData, Temp, or any user-writable directory; or if the commands originated from a remote session from an unrecognised source IP. Stopping backup and security services in sequence is the highest-confidence ransomware pre-staging signal available before the encryptor runs.

Responding and remediating

Immediate containment

• Restart any critical services that were stopped, in the following priority order: security and endpoint protection services first, then backup agents, then logging and event services, then database services. Restoring security tooling immediately returns the host to a monitored state before other remediation steps are taken.
• Isolate the affected host from the network if the service disruption sequence is confirmed as attacker-initiated and the attack appears to be in progress. Isolation prevents the encryptor from being deployed via the network to other hosts while the investigation and remediation proceed.
• Disable the account that ran the net stop commands if it is not a documented service management account. If the account is a named IT administrator, verify with them directly before disabling, but prioritise containment.
• For any malicious service identified via the start rule, stop the service immediately using sc stop or net stop, disable it using sc config <servicename> start= disabled, and prevent it from restarting. Do not delete the binary before forensic preservation.

Forensic preservation

• Export the Windows Security event log, System event log, and Sysmon operational log from the affected host covering the full period from the first net stop or net start command to the time of containment. The System event log Service Control Manager entries confirm which services actually changed state and at what times.
• If a malicious service was identified via the start rule, preserve the service binary before removal. Hash the file, document its path and creation timestamp, and submit to a sandbox for analysis to determine its full capability.
• Document the service state on the affected host at the time of containment. Identify which services are stopped, which are running, and whether any services have been reconfigured to point to different binaries than their documented paths.

Eradication and recovery

• Audit all services on the affected host against a known-good baseline. Compare the current service list, executable paths, and startup types against the documented configuration. Flag any service that was not in the baseline, any service whose executable path has changed, and any service whose startup type has been modified.
• Scan all other endpoints in the environment for the same net stop service name patterns in their process creation logs. Query Log360 for the same stop commands across all agents in the preceding 24 hours. A service disruption campaign affecting multiple hosts indicates a scripted attacker operating broadly across the environment.
• Restore all backup agent services and verify that backup jobs run successfully before returning the host to normal operation. Confirm that a clean backup exists before closing the incident. If backup services were stopped for an extended period, the most recent backup may predate the incident and the backup window gap must be documented.

False positive guidance

Net start and net stop are among the most common administrative commands in Windows environments. False positives are frequent without proper tuning. The following scenarios regularly produce false positive alerts:

• Software installation and updates: software installers routinely stop services before replacing binaries and restart them after installation completes. Windows Update stops services as part of applying patches. These will generate paired stop and start events from the installer or Windows Update process. Verify the parent process is a signed installer or the Windows Update agent, the service name matches a documented software product, and the stop is followed by a start of the same service within a reasonable installation window.
• Scheduled maintenance scripts: IT teams use scripts that start and stop services as part of nightly maintenance, log rotation, or automated housekeeping workflows. These will run at consistent times from a consistent account. Identify the script and its schedule, verify the service names match documented maintenance targets, and create scoped exclusions for the specific parent process and service name combinations.
• IT administrator troubleshooting: helpdesk and systems administrators stop and start services when troubleshooting service failures, applying configuration changes, or testing service recovery. These will come from interactive admin sessions on known management workstations during business hours, typically targeting a single service at a time rather than multiple services in rapid succession. Verify the account, the workstation, and whether a single service was affected. Multiple services in rapid succession from an admin session still warrants investigation.
• Configuration management and deployment tools: SCCM, Ansible, Puppet, and similar tools stop and start services as part of configuration baseline enforcement. These will originate from the management agent process on a consistent schedule across multiple hosts simultaneously. Identify the agent binary and create a scoped exclusion covering the agent process and the specific service names it manages.

Key differentiator

Legitimate service stop and start operations are predictable, singular or low-volume, attributable to a known process, and typically involve one service at a time for a specific operational reason. Attacker-initiated service disruption involves multiple services in rapid succession, targets a mix of security, backup, and database service categories simultaneously, originates from an unusual parent process or a remote session from an unrecognised IP, and occurs outside any documented maintenance window. The combination of high velocity, mixed critical service categories, and an unrecognised parent process in the same session window is the pattern that distinguishes ransomware pre-staging from routine administrative service management.

Hardening and prevention

The following controls reduce the risk of critical service disruption via net.exe in your environment:

• Apply the principle of least privilege to service management permissions. Only named administrators with a documented operational need should hold the rights to stop and start critical services such as backup agents and endpoint protection software. Standard user accounts and general helpdesk accounts should not be able to stop security or backup services.
• Configure endpoint protection and backup agent services with tamper protection enabled. Many modern endpoint protection products include a tamper protection feature that prevents the service from being stopped via external commands including net stop, requiring a specific PIN or console action to stop the service. Enable this for all security and backup services where the vendor supports it.
• Restrict execution of net.exe to documented administrative accounts via AppLocker or WDAC policies on servers hosting critical services. If service management is handled through dedicated management tools rather than net.exe, blocking net.exe execution from non-administrative contexts eliminates this specific technique while preserving management capability through the authorised channel.
• Enable immutable backup storage or offsite backup copies that are not accessible from the systems being backed up. If backup data is stored in a location that cannot be reached from the production environment, stopping the backup agent does not prevent recovery from the most recent stored backup.
• Implement a service configuration baseline audit. Run a weekly automated scan comparing the current service list, executable paths, and startup configurations against a documented baseline. Any service not in the baseline, or any service whose executable path has changed, should generate a remediation alert independent of real-time monitoring.
• Enable Windows Service Integrity Monitoring through Sysmon Event ID 12 and 13 to detect registry modifications to service configurations. Attackers who reconfigure an existing service to point to a malicious binary before starting it will modify the ImagePath value in the service registry key, which generates a Sysmon registry event before any net start command.