TA0003: Persistence
The adversary is trying to maintain their foothold.
Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.
Analyst context for executives and security teams
Persistence is the point where an intrusion can become a recurring business problem instead of a one-time incident. ATT&CK defines this tactic as adversaries maintaining a foothold across restarts, credential changes, or other interruptions, often through access, actions, or configuration changes such as hijacking legitimate code or adding startup code. For leaders, the key question is whether the organization can prove that restored systems, reset credentials, and remediated accounts are actually clean—not just temporarily quiet.
Executive priority
Treat persistence as a resilience and incident-decision priority. If defenders cannot find and remove persistence mechanisms, recovery work may be incomplete and business operations may face repeated compromise after apparent containment. Executives should ask whether incident response playbooks require validation after reboots, credential resets, and configuration restoration, and whether compliance evidence can show that unauthorized persistence-enabling changes would be detected and investigated.
Technical view
Because this object is a tactic and no ATT&CK detection text, platforms, or technique relationships were supplied, teams should use it as a validation category rather than a single detection rule. SOC and IR teams should confirm they can identify unauthorized access, actions, or configuration changes that allow continued access across interruptions. Detection engineering should prioritize coverage for changes to startup behavior, legitimate code replacement or hijacking, and other persistence-enabling configuration changes, then map those controls to the specific ATT&CK persistence techniques relevant to the local environment.
Likely telemetry
- System and application configuration change records
- Startup or auto-execution configuration evidence
- File integrity or code change evidence for legitimate binaries, scripts, or application components
- Authentication and account activity surrounding credential resets or access recovery
- Endpoint, server, and workload logs showing changes that survive restart or user session interruption
Detection direction
- Validate that monitoring can distinguish authorized administrative changes from unexpected persistence-enabling changes.
- Test whether detections still surface suspicious access or configuration changes after restarts, credential changes, and other containment actions.
- Tune for context: startup-related changes and legitimate code modifications can be normal in patching, software deployment, and administration, so approvals, change windows, and asset role matter.
- Avoid treating absence of alerts as proof of eradication; persistence often requires comparison against known-good baselines and post-remediation validation.
- Use this tactic to organize coverage reviews, then map specific rules and evidence requirements to applicable persistence techniques in the environment.
Mitigation priorities
- Establish strong change control and baseline management for systems and applications where persistent access could be established.
- Require IR eradication procedures to verify removal of persistence after reboot, credential reset, and service restoration.
- Limit who can make durable configuration, startup, or code changes and ensure those actions are logged and reviewable.
- Maintain recovery evidence that supports audit and leadership decisions, including what was checked before declaring containment or eradication complete.
- Prioritize deeper technique-level assessment because this tactic object does not specify platforms or concrete mitigations.
Analyst notes and limits
This take is based only on the supplied ATT&CK tactic record for TA0003 Persistence. The value for defenders is in using it as an organizing lens for coverage, response validation, and recovery assurance. No relationship context or technique list was supplied, so local ATT&CK mapping is required before building detailed detection logic.
The supplied object has no official detection guidance, no platforms, and no relationships. This summary therefore does not assert specific telemetry availability, detection coverage, affected technologies, adversary use, or exploitation activity. Environment-specific systems, identity stores, cloud services, and operational change processes must be reviewed locally.
Persistence
The adversary is trying to maintain their foothold.
Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.
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 | 1.0 | Current bundle | 0d06037424f8… |
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 TA0003Open 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.