DC0033: Process Termination
The exit or termination of a running process on a system. This can occur due to normal operations, user-initiated commands, or malicious actions such as process termination by malware to disable security controls.
Analyst context for executives and security teams
Process Termination is a basic but important signal: it records when a running process exits or is killed. For leaders, its value is not that every termination is suspicious, but that unexpected termination of important business, security, or operational processes can be an early indicator of disruption, control impairment, or incident activity. Because ATT&CK provides no platform or tactic scope for this data component, organizations should treat it as a coverage question: do we reliably know when critical processes stop, why they stopped, and whether that event is visible to the SOC or incident responders?
Executive priority
Prioritize this as evidence for operational resilience and security control assurance. Executives should ask whether the organization can prove that key business services and security tooling remain running, and whether abnormal termination events trigger investigation fast enough to support incident decisions. This data component can also support audit and compliance evidence where control availability, monitoring, and incident response readiness must be demonstrated.
Technical view
SOC, detection engineering, and IR teams should validate collection of process exit or termination events for systems and processes that matter most locally. ATT&CK notes that termination may be normal, user initiated, or malicious, including attempts to disable security controls. Because no official detection logic, platforms, tactics, or relationship context are supplied, detection should be environment-led: baseline normal process lifecycle behavior, identify unexpected termination of critical services or security processes, and correlate termination events with nearby user activity, administrative actions, service failures, or other host telemetry.
Likely telemetry
- Process exit or termination events
- Process name, path, command line, process ID, and parent process context where available
- Timestamp and host identifier
- User or account context associated with the process or termination event where available
- Service or application health events indicating stopped or failed processes
Detection direction
- Validate that process termination telemetry is collected consistently for high-value systems and critical processes.
- Establish baselines for expected process exits, restarts, software updates, administrative maintenance, and service recycling to reduce false positives.
- Prioritize alerting on unexpected termination of security controls, monitoring agents, identity-related services, backup components, or business-critical applications where applicable to the local environment.
- Correlate termination with surrounding activity rather than treating every exit as malicious; normal operations and user-initiated commands are explicitly in scope for this data component.
- Check blind spots where endpoint logging, service monitoring, or agent health reporting may stop at the same time as the process being monitored.
Mitigation priorities
- Define and maintain an inventory of critical business, security, and operational processes that require monitoring.
- Ensure monitoring and alerting exist for unexpected stoppage or termination of those critical processes.
- Harden operational procedures so authorized maintenance, patching, and administrative termination activity is documented and distinguishable from abnormal activity.
- Use health checks or watchdog-style monitoring for essential services and security tooling where appropriate.
- Review incident response playbooks so unexpected termination of critical or security-related processes has clear triage, escalation, and evidence-preservation steps.
Analyst notes and limits
This object is a data component, not a technique. Its practical value depends on whether the organization collects process lifecycle telemetry and can separate normal process exits from suspicious or harmful termination. The supplied ATT&CK fields specifically mention malicious termination to disable security controls, so security tool availability should be a priority validation area, but conclusions require local telemetry and asset context.
ATT&CK provides no platforms, tactics, official detection guidance, or relationship context for this object. This take therefore avoids platform-specific assumptions and does not claim detection coverage, active exploitation, attribution, or impact. Local logging capabilities, endpoint tooling, and business process criticality determine how useful this data component will be.
Process Termination
The exit or termination of a running process on a system. This can occur due to normal operations, user-initiated commands, or malicious actions such as process termination by malware to disable security controls.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.0 | Current bundle | f14aae3e2db3… |
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 DC0033Open 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.