T1668: Exclusive Control
Adversaries who successfully compromise a system may attempt to maintain persistence by “closing the door” behind them – in other words, by preventing other threat actors from initially accessing or maintaining a foothold on the same system.
For example, adversaries may patch a vulnerable, compromised system[1][2] to prevent other threat actors from leveraging that vulnerability in the future. They may “close the door” in other ways, such as disabling vulnerable services[3], stripping privileges from accounts[4], or removing other malware already on the compromised device.[5]
Hindering other threat actors may allow an adversary to maintain sole access to a compromised system or network. This prevents the threat actor from needing to compete with or even being removed themselves by other threat actors. It also reduces the “noise” in the environment, lowering the possibility of being caught and evicted by defenders. Finally, in the case of Resource Hijacking, leveraging a compromised device’s full power allows the threat actor to maximize profit.[3]
Analyst context for executives and security teams
Exclusive Control is persistence behavior where an intruder tries to keep sole access to a compromised Linux, macOS, or Windows system by removing competition: patching the abused vulnerability, disabling exposed services, reducing account privileges, or removing other malware. For leaders, the key point is that some seemingly positive changes after compromise can be attacker-driven and may hide an existing foothold rather than prove recovery.
Executive priority
Treat unexpected remediation activity on a compromised or suspicious asset as an incident decision point, not automatic evidence of containment. This technique matters to business continuity and IR readiness because it can reduce visible noise while preserving adversary access, complicate root-cause analysis, and create false confidence around patching or service hardening. Leaders should ask whether vulnerability remediation, account changes, service shutdowns, and malware removals are attributable to authorized teams and supported by audit evidence.
Technical view
ATT&CK lists this as an enterprise persistence technique for Linux, macOS, and Windows. No official detection text is provided, but the related ATT&CK detection strategy DET0015 is associated with this object. SOC and IR teams should validate whether they can correlate post-compromise system changes with authorized change records: patch installation, service disablement, privilege stripping, and removal of competing malware or tools. The investigation focus is not the change alone, but suspicious timing, unauthorized actor context, and linkage to prior compromise or exposed-vulnerability activity.
Likely telemetry
- Endpoint process and command execution logs
- Operating system audit logs for service configuration changes
- Patch management and software installation records
- Identity and privilege change audit logs
- EDR or antivirus detections and remediation history
Detection direction
- Correlate remediation-like events with incident timelines and authorized change windows.
- Alert or review when vulnerable services are disabled, patches are applied, or privileges are changed on assets already showing compromise indicators.
- Tune detections to avoid treating all patching or service hardening as malicious; require suspicious context such as unusual actor, time, parent process, remote session, or lack of change ticket.
- Look for sequences where other malware is removed but persistence indicators remain, because reduced noise may be intentional.
- Validate coverage across Linux, macOS, and Windows rather than assuming endpoint telemetry is equivalent on all platforms.
Mitigation priorities
- Maintain authoritative change management for patching, service disablement, and account privilege changes so IR teams can distinguish legitimate remediation from adversary activity.
- After patching a previously exposed or compromised system, perform compromise assessment instead of assuming the patch removed access.
- Review persistence mechanisms and credentials after any unexpected security improvement on a suspicious host.
- Ensure vulnerability management, endpoint security, identity administration, and incident response teams share timelines during containment.
- Preserve forensic evidence before cleanup where possible, because attacker-driven cleanup can remove competing malware and reduce investigative visibility.
Analyst notes and limits
This technique is especially relevant during incident response because attacker actions may resemble defender remediation. The supplied ATT&CK description cites examples including patching vulnerable compromised systems, disabling vulnerable services, stripping privileges from accounts, and removing other malware. Defensive value comes from proving who made those changes, when they occurred, and whether persistence remains.
The official ATT&CK object provides no detection text and only one relationship to detection strategy DET0015 without detailed platform or tactic metadata. Local telemetry, change records, and incident context are required to determine whether any observed remediation-like activity is authorized or adversary-driven.
Exclusive Control
Adversaries who successfully compromise a system may attempt to maintain persistence by “closing the door” behind them – in other words, by preventing other threat actors from initially accessing or maintaining a foothold on the same system.
For example, adversaries may patch a vulnerable, compromised system[1][2] to prevent other threat actors from leveraging that vulnerability in the future. They may “close the door” in other ways, such as disabling vulnerable services[3], stripping privileges from accounts[4], or removing other malware already on the compromised device.[5]
Hindering other threat actors may allow an adversary to maintain sole access to a compromised system or network. This prevents the threat actor from needing to compete with or even being removed themselves by other threat actors. It also reduces the “noise” in the environment, lowering the possibility of being caught and evicted by defenders. Finally, in the case of Resource Hijacking, leveraging a compromised device’s full power allows the threat actor to maximize profit.[3]
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
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 | 576c922b0253… |
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]
Mandiant-iab-control
Michael Raggi, Adam Aprahamian, Dan Kelly, Mathew Potaczek, Marcin Siedlarz, Austin Larsen. (2024, March 21). Bringing Access Back — Initial Access Brokers Exploit F5 BIG-IP (CVE-2023-46747) and ScreenConnect. Retrieved January 31, 2025.
Open source URL -
[2]
CERT AT Fortinent Ransomware 2025
CERT Austria. (2025, March 20). Ransomware-Gruppen nutzen weiterhin kritische Fortinet-Schwachstellen - Warnung vor gepatchten, aber bereits kompromittierten Geräten. Retrieved March 31, 2025.
Open source URL -
[3]
sophos-multiple-attackers
Matt Wixey. (2022, August 9). Multiple attackers increase pressure on victims, complicate incident response. Retrieved January 31, 2025.
Open source URL -
[4]
aquasec-postgres-processes
Assaf Morag. (2024, August 19). PG_MEM: A Malware Hidden in the Postgres Processes. Retrieved January 31, 2025.
Open source URL -
[5]
fsecure-netsky
F-Secure. (2004). Worm:W32/NetSky.H. Retrieved January 31, 2025.
Open source URL -
[6]
mitre-attack T1668Open 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.