DC0020: Process Modification
Changes made to a running process, such as writing data into memory, modifying execution behavior, or injecting code into an existing process. Adversaries frequently modify processes to execute malicious payloads, evade detection, or gain escalated privileges.
Analyst context for executives and security teams
Process Modification is evidence that a running process has been changed, such as memory being written, execution behavior being altered, or code being injected. For leaders, this matters because it is often the kind of low-level activity defenders need to see when investigating stealthy execution, evasion, or privilege-related behavior. If an organization cannot observe or explain process changes, incident responders may struggle to determine whether a suspicious process is benign, compromised, or being used to hide malicious activity.
Executive priority
Treat this as a visibility and response-readiness checkpoint rather than a standalone risk. Security leaders should ask whether SOC and incident response teams can collect and retain evidence of changes to running processes, whether that evidence is usable during investigations, and whether exceptions for legitimate tooling are documented. This supports better incident decision-making, audit defensibility, and prioritization of endpoint telemetry investments, especially where process-level visibility is required to distinguish normal administration from suspicious manipulation.
Technical view
ATT&CK defines this data component as changes to a running process, including memory writes, execution-behavior changes, or code injection into an existing process. No ATT&CK platforms, tactics, detection guidance, or relationships were supplied for this object, so validation should focus on whether local endpoint and process telemetry can capture process modification events with enough context to support triage. SOC teams should confirm they can correlate the modified process, modifying process, user/session context, command-line or parent-child process context where available, timestamps, and any related memory or injection indicators. Detection engineering should avoid assuming all process modification is malicious; legitimate security, debugging, accessibility, administration, and software-management tools may produce similar signals.
Likely telemetry
- Endpoint process telemetry showing changes to running processes
- Events indicating writes to another process's memory or modification of process execution behavior
- Process injection or code-injection related alerts where collected
- Source and target process identifiers, names, paths, parent process context, and timestamps
- User, session, and host context associated with the modifying process
Detection direction
- Validate that endpoint telemetry records both the process being modified and the process or user responsible for the modification.
- Tune analytics around unusual or unauthorized process modification patterns rather than treating every modification as malicious.
- Baseline legitimate process-modifying tools and workflows to reduce false positives from administrative, debugging, security, or software-management activity.
- Ensure investigation workflows preserve enough context to determine whether process modification was tied to execution, evasion, or privilege-related behavior.
- Because ATT&CK provides no detection text or platform scope for this data component, derive specific rules from local telemetry capabilities and the techniques this data component supports in your environment.
Mitigation priorities
- Prioritize visibility first: confirm endpoint tooling can capture process modification evidence with sufficient retention for investigations.
- Review and document legitimate tools that modify running processes so SOC teams can separate expected behavior from suspicious activity.
- Restrict unnecessary administrative or privileged tooling that can modify processes, using existing access-control and change-management practices.
- Integrate process-modification evidence into incident response playbooks so responders know what data to collect and how to interpret it.
- Use findings from telemetry gaps to guide endpoint monitoring, IAM, and compliance-readiness improvements.
Analyst notes and limits
This object is a data component, not an adversary technique. Its value is in confirming whether defenders can observe process changes that may support investigation of execution, evasion, or privilege-related activity. The supplied ATT&CK object has no platform, tactic, detection text, aliases, or relationship context, so recommendations are intentionally framed as validation and readiness guidance rather than specific detections.
The supplied official fields do not specify affected platforms, concrete detection logic, related techniques, adversary use, or mitigations. Local endpoint architecture, security tooling, retention, and approved administrative workflows are required to determine practical coverage and false-positive handling.
Process Modification
Changes made to a running process, such as writing data into memory, modifying execution behavior, or injecting code into an existing process. Adversaries frequently modify processes to execute malicious payloads, evade detection, or gain escalated privileges.
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 | 70d0b41ad640… |
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 DC0020Open 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.