DET0021: Behavioral Detection for Service Stop across Platforms
DET0021 is a MITRE detection strategy for identifying behavior consistent with Service Stop, an impact technique where adversaries stop or disable services...
Analyst context for executives and security teams
DET0021 is a MITRE detection strategy for identifying behavior consistent with Service Stop, an impact technique where adversaries stop or disable services to make systems or critical functions unavailable. For leaders, the value is not just detecting a command; it is validating whether the organization can see and respond when important services on ESXi, IaaS, Linux, or macOS environments are intentionally stopped in ways that could disrupt operations or hinder incident response.
Executive priority
Prioritize this as an operational resilience and incident-readiness control. Service stoppage can affect business continuity when critical infrastructure, cloud-hosted workloads, or endpoint services are disabled. Executives should ask which services are business-critical, whether service-stop events are logged centrally, who is authorized to stop them, and whether SOC and IR teams have evidence to distinguish legitimate administration from suspicious disruption.
Technical view
Because the ATT&CK detection strategy object does not provide official detection logic or platform detail, teams should anchor validation to the related technique T1489: Service Stop, under the impact tactic, with related platforms ESXi, IaaS, Linux, and macOS. SOC and detection engineers should confirm visibility into service/process state changes, administrative actions that stop or disable services, and correlated identity/session context. IR teams should validate that alerts preserve enough context to determine which service stopped, on which asset, by which account or automation, and whether the action affected response tooling or critical business services.
Likely telemetry
- Service manager or init/system service state-change logs from Linux and macOS where available
- ESXi management and host activity logs showing service or process stop/disable actions
- IaaS control-plane or workload management logs that record service, instance, or agent disruption events
- Process execution and command-line telemetry related to service control utilities where collected
- Identity and authentication logs for the account, session, or automation responsible for the change
Detection direction
- Validate that detections are behavior-based around unauthorized, unusual, or high-risk service stop/disable activity rather than relying only on a single command pattern.
- Tune against legitimate maintenance, patching, deployment automation, and administrator activity to reduce false positives while preserving alerts for critical services and unusual accounts.
- Correlate service-stop events with identity context, asset criticality, change windows, and nearby impact indicators to improve triage value.
- Check blind spots in ESXi, IaaS, Linux, and macOS logging pipelines, especially where local logs are not forwarded before a service disruption occurs.
- Use the T1489 relationship to frame testing: can the SOC identify when service stoppage could inhibit response or make a service unavailable to legitimate users?
Mitigation priorities
- Define and maintain an inventory of critical services and owners so detection priority reflects business impact.
- Restrict and review privileges that allow users or automation to stop or disable important services.
- Centralize relevant service, host, cloud, and identity logs so evidence survives local disruption.
- Implement change-control context for expected service stops, allowing detections to focus on unexpected or unauthorized activity.
- Include service-stop scenarios in incident response exercises, especially for services that support monitoring, recovery, or critical operations.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no directly specified platforms or tactics. The practical guidance above is derived from its relationship to T1489 Service Stop and the supplied related technique metadata. Local environment knowledge is required to decide which services are critical and what constitutes authorized service administration.
This take does not assert active exploitation, actor attribution, guaranteed detection coverage, or platforms beyond the related T1489 context supplied. Specific detection analytics, event IDs, product configurations, and vendor-specific controls are not provided in the official fields and should be developed from local telemetry and operational requirements.
Behavioral Detection for Service Stop across Platforms
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1489 | Service Stop | This object detects Service Stop. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7668068d3b23… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0021Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.