How T1668 Exclusive control supports persistence and where it appears
For an adversary, T1668 Exclusive control falls under the Persistence tactic (TA0003), and its purpose there is to help maintain the foothold. MITRE defines the tactic as the adversary trying to maintain their foothold, and this technique serves that goal by holding a resource so that legitimate users and components cannot take it back. At a high level, if an adversary keeps exclusive control of a lock, file, process slot or similar shared resource, its access can survive restarts and cleanup attempts because the environment never reclaims the resource. This tends to appear after initial access has already succeeded, in the phase where the intruder is making sure it keeps a way back in. The technique is defined for Linux, macOS and Windows, so the SOC lead should expect it to surface on all three platforms. The page on MITRE ATT&CK's Persistence tactic is the reference for the tactic's scope.
The reason this technique is easy to miss is that exclusive locking looks like ordinary resource contention. Schedulers, databases, package managers and service managers all produce lock conflicts and held-resource warnings during normal operations, so a suspicious holder can blend into routine noise. The practical decision for the SOC lead is which resources in the estate are expected to be held exclusively, and which processes or accounts should own them. Teams should baseline the expected holders on each platform, then confirm that process creation, command execution and process termination telemetry is collected from the hosts where those resources live. A holder that never releases, or that is started from an unexpected location, is the kind of deviation worth triaging. Where telemetry gaps exist on any of the three platforms, record them as detection risks before the rehearsal begins.
Detection mappings for this page should name the ATT&CK version they target, which is Enterprise ATT&CK 20.0 here. Releases can rename, deprecate or revoke techniques and change how detections are described, so the team should confirm the technique name, its sub-technique structure and its detection strategy identifiers against the version it runs. MITRE's ATT&CK updates page lists the release history that explains these changes. Record the version next to every rule, dashboard and test result so that a later upgrade does not silently break the coverage claim. This version discipline also makes the cyber range exercise repeatable, because the same technique definition is used when the team rehearses detection and when it reports results.
Which telemetry reveals exclusive control and which tool collects it
This table maps the telemetry that can expose exclusive control to the signals an analyst should look for and the open-source tool that collects them. Confirm each data component against the T1668 detection strategy in the ATT&CK version you target before writing rules. Process-level events rarely prove intent on their own, so pair them with evidence of a held resource and blocked access by other processes.
| Data source or component | Signal to look for | Platform | Open-source collector or tool |
|---|---|---|---|
| Process Creation (DC0032) | A process starts and then keeps a shared resource that backup, security or sync tools expect to open | Linux, macOS, Windows | Sysmon with the Wazuh agent on Windows; Wazuh agent on Linux and macOS |
| Command Execution (DC0064) | Scripted commands that take a lock on files, databases or services and then wait instead of exiting | Linux, macOS, Windows | Wazuh agent for collection; Velociraptor for targeted hunts |
| Process Termination | An expected security or backup process ends unexpectedly, or a later instance fails to start because another process already holds the resource | Linux, macOS, Windows | Wazuh agent event collection; Velociraptor artifacts run on demand |
| Open handle duration | A process holds an open handle to a shared resource for far longer than its normal pattern | Linux, macOS, Windows | Velociraptor live hunts; Sysmon process and file events on Windows |
| Application Log Content (DC0038) | Application logs record repeated access failures or lock timeouts from legitimate clients | Linux, macOS, Windows | Wazuh log collection from application and service log files |
| File Modification (DC0061) | Changes to lock or marker files in shared paths, included only if the T1668 analytics reference it | Linux, macOS, Windows | Wazuh file integrity monitoring; Velociraptor file hunts |
Detection ideas for exclusive control on each platform
Exclusive control is hard to spot because a legitimate lock and a malicious lock look the same at the resource level. Each card below describes a detection concept built on process and command telemetry, compared against a documented baseline of which processes normally hold each resource. Tune every rule to your own environment and map it to the ATT&CK version you target.
Linux lock holder mismatch
On Linux, alert when a process takes an advisory lock, opens a pid file, or binds a socket that belongs to a service, and its executable path or owner does not match the expected service account for that resource. Build the baseline from Process Creation and Command Execution records collected by auditd or a comparable agent, and record which holders are expected for each lock directory. Tune on new holder paths, holders started from /tmp or user home directories, and holders that appear shortly after a service stops. Expect false positives from backup agents, database engines that lock their data directories, package managers and scheduled jobs. Confirm each exception by owner and path before suppressing it.
macOS launchd and lock ownership
On macOS, compare processes that hold files, sockets or lock files against the launchd job inventory. Alert when a holder is not registered as a launch agent or daemon, or when it was started from a user-writable location and then keeps a lock on a path used by a system service. Use Process Creation and Command Execution telemetry from your endpoint agent, and keep a documented list of expected holders per path. Tune the window in which a new holder is treated as unusual, and review any holder that is not signed by an expected developer identity. Expect false positives from endpoint protection scans, Time Machine, software updaters and MDM agents, which all hold resources on a schedule. Verify each exception against the vendor's documented behavior.
Windows named object ownership
On Windows, track Process Creation events and the parent process of any process that creates a named mutex, opens a file with exclusive share mode, or holds a named pipe used by a security product or database service. Alert when the creator is not the expected executable, or when its parent is a script host, a user-writable folder or a process that was recently spawned. Baseline the expected owners per object name from a known-good build of the host, and document the exceptions. Expect false positives from antivirus scans, SQL Server, Windows Update, backup agents and endpoint management tools, which legitimately hold exclusive resources during maintenance. Confirm each owner before adding it to the allowlist.
Termination followed by resource hold
Correlate Process Termination events for monitored services with any new resource hold on the same resource identifier by a different process within a bounded time window. The rule fires when a protected service ends and a new, unexpected process claims its lock, port or file path before the service restarts. Set the window and the resource key during tuning, and keep the baseline of normal restart behavior per service. False positives come from planned maintenance, service restarts by a supervisor, and updaters that replace binaries and reacquire resources. Review each match with change records and confirm the restart history before treating it as a finding.
How to validate the T1668 detection in a lab before production
This sequence shows whether the T1668 detection works end to end: the behavior is produced on a range, the telemetry reaches the SIEM, the alert fires with usable fields, and the results are recorded for review. Each step closes with a check that someone can audit later.
Agree scope and ATT&CK version
The detection owner, range operator and SIEM administrator agree in writing which hosts, accounts and log sources are in scope, and which platforms (Linux, macOS and Windows) the test covers. Record the ATT&CK version the test targets, because releases can rename, deprecate or revoke techniques and change detection strategies. Confirm the version against the ATT&CK updates pages before testing. The step is done when a signed test plan names the version, the platforms and the stop conditions.
Map the test to the technique
Write down the T1668 behavior the test will imitate, based on the current ATT&CK description and its linked detection strategy for the targeted version. List the expected data components, which are Process Creation, Command Execution and Process Termination for this topic, and name the analytic that should fire. Note any sub-technique or platform variation you are not testing. The step is done when each expected log source and analytic is mapped to a line in the test plan.
Run an approved high-level emulation
A named operator runs an emulation on an isolated range host that reproduces the behavior described in the mapping, at a high level, under the approved plan. Keep the run to the agreed scope, log the operator's start and end times, and avoid any live production system or real credentials. Use a clearly labeled test account and a fixed run identifier so every event can be traced back to this exercise. The step is done when the operator has signed the run log and the range snapshot is preserved.
Confirm telemetry arrives in the SIEM
Search the SIEM for the run identifier and the test host to confirm that process creation, command execution and process termination events arrive from the endpoint agent. Check the timestamps against the operator's log, look for dropped or delayed events, and verify that the parsing maps fields such as host, user, parent process and command line correctly. The step is done when every expected event type appears for the run, or when each gap is logged with a cause and an owner.
Check the alert fires with expected fields
Confirm that the T1668 analytic produces an alert within the window you agreed, that it carries the ATT&CK technique and version tags, and that it includes the host, user, process details and the run identifier. Compare the alert with the mapping from step two. Note any false positives from the lab's normal activity. The step is done when the alert matches the expected logic, or when the gap is documented as a tuning item with an owner.
Verify alert reaches the analyst queue
Confirm the alert appears in the analyst queue, case management system or ticketing integration that your operations team uses, not only in the SIEM dashboard. Check that the assigned severity, routing and notification match the response runbook. A test that stops at the SIEM does not prove the detection is usable. The step is done when an analyst can open the case from the queue and see the same fields as the SIEM alert.
Record results for each test
For every test, record the run identifier, ATT&CK technique and version, platform, host, user, process details, the timestamps of the operator action, the telemetry arrival and the alert, and whether the alert reached the analyst queue. Add the outcome (detected, partially detected or missed), the tuning changes made and the retest result. Store the record in the evidence repository with restricted access. The step is done when the results sheet is reviewed and the open gaps have owners.
Preventive controls that limit exclusive control on endpoints
T1668 Exclusive control depends on an adversary holding a resource that others need, so these controls aim to make holds visible, hard to set and easy to reverse. Confirm the T1668 mapping for each mitigation in the enterprise-attack 20.0 STIX bundle, and check each control against your own endpoint estate before relying on it.
Audit lock and control activity
Audit policies that record handle requests, file locks and service control changes let you see who holds a shared resource and when that hold started. Confirm that endpoint audit settings cover these events on Linux, macOS and Windows, that the events are forwarded to your monitoring platform, and that someone reviews them. Without this record, a resource held by an unfamiliar process is difficult to attribute.
Restrict permissions on shared paths
Limit write, delete and permission-change rights on directories that applications share so that an ordinary user process cannot take a lock on them or alter their access rules. Review ACLs and file modes on application data, spool and configuration paths, and test them with a standard user account. Pay attention to inherited permissions, because a broad grant on a parent directory can undo a narrow fix on a child.
Limit privileged accounts
Holding a resource owned by another user usually requires elevated rights, so narrowing who can reach them reduces this technique's options. Review membership of local administrator, sudo and root-equivalent groups, separate administrative accounts from daily-use accounts, and confirm that service and maintenance accounts are scoped to their own tasks. Check the results with a periodic access review rather than assuming the design holds.
Remove unused endpoint features
Software that offers optional services, helper agents or legacy utilities can provide an easy route to hold a resource. Build an inventory of installed features, services and agents on each endpoint class, then disable or uninstall those without a named owner or a current business need. Record each removal so that a later rebuild does not quietly restore the component.
Control account lifecycle
Unused, shared or forgotten accounts can be reused to take and keep control of a resource. Review how accounts are created, added to groups and retired, and set an owner for every service account. Remove dormant accounts and check that changes to privileged groups generate an alert. Ask your identity team to confirm which of these steps are already enforced by the directory service and which depend on manual review.
Triage and response when a T1668 alert fires
Start triage by answering four questions before anyone changes the host. First, is the holding process expected? Compare its binary path, signer and launch context with your software inventory and change records, because a backup agent, database maintenance job or file indexer can legitimately hold a lock for long periods. Second, is the locked resource business critical? A lock on a payment batch file or a clinical records store changes the urgency and the approvers you need. Third, what was the parent process and which account started it? An interactive session, a service account and a scheduled task each point to a different owner. Fourth, does the same host show other persistence signals, such as new autostart entries, scheduled tasks or unexpected account changes? Record the answers in the case ticket with timestamps so the decision can be audited later.
Containment should keep evidence intact. Before terminating the holding process, capture its process details, open handles, loaded modules, network connections and the relevant event log entries, using your EDR or Velociraptor collection so the artifacts are hashed and stored off the host. If the resource is still needed for service, isolate the host at the network layer while you collect evidence, and only then end the process. Confirm with the resource owner before any forced release, because releasing a lock on a file that another process is writing can corrupt data. Escalate to your incident response team when the holding process cannot be explained, when other persistence signals are present, or when the resource holds regulated data. Hand over the artifacts, the timeline and the open questions, and let the responders decide on reimaging.
Recovery checks confirm that the resource is released and that the condition does not return. Verify that the legitimate owner process can open the resource, that integrity checks on the resource pass, and that no new holder appears after a reboot or after the next scheduled job runs. Keep the monitoring window open long enough to cover those scheduled jobs, and confirm its length with your own operations team, since the right window depends on your workload calendar. Then feed lessons into detection tuning: record which allowlisted holders created noise, which signals were missing, and which ATT&CK version the rule targets. Update the Sigma or Wazuh rule, log the change, and rerun the same scenario in your cyber range to confirm the tuned detection still fires.
Rehearsing T1668 detection and response in a private cyber range
The range should mirror the client's own estate closely enough that the telemetry resembles production. Include Linux, macOS and Windows endpoints enrolled with an agent that forwards logs to a SIEM such as Wazuh, plus network sensors such as Zeek and Suricata so that host events sit next to network context. The logging pipeline between endpoints and the SIEM belongs in the exercise, because gaps on that path are a common reason detections fail in production.
- Endpoint coverage: Linux, macOS and Windows hosts with process creation, command execution and process termination logging enabled at the level the production estate uses.
- SIEM and rules: Wazuh or the chosen SIEM, with detection logic written as Sigma rules and labeled with the ATT&CK version under test.
- Network sensors: Zeek and Suricata placed on segments that carry management and identity traffic.
- Logging pipeline: Forwarding, parsing and time synchronization checked end to end, including behavior when queues back up.
- Isolation: A private network with no route to production, plus snapshots that allow a clean reset between runs.
Confirm agent versions, log sources and parser health before the first inject, and record them in the range runbook.
Injects are scheduled events that the white cell delivers to the range to test a specific detection goal. Describe each inject in words in the runbook, state the expected telemetry and name the analyst action it should trigger. Keep injects at the level of intent and observable effect, so the exercise tests the detection and response chain rather than memorized steps.
- Benign baseline: Routine administrative changes made by known accounts, so the blue team learns what normal looks like on each platform.
- Targeted inject: A single event that touches the T1668 detection logic on one platform, with the expected log fields written down in advance.
- Confounder: A legitimate change that resembles the target behavior, to test whether analysts can separate it from a true positive.
- Telemetry fault: A deliberately stopped forwarder or delayed log source, to test whether the team notices missing coverage.
- Escalation point: A decision point where the blue team must choose between containment and continued observation.
Run the baseline first and keep the timeline in a shared log so the debrief can match each inject to what the SIEM recorded.
A cyber range exercise needs three cells with clear authority. The red cell prepares and runs the agreed inject set within the rules of engagement. The blue cell operates the SIEM, sensors and response procedures as it would in production, without advance knowledge of inject timing. The white cell controls the exercise: it owns the schedule, approves any deviation, records the timeline and protects the exercise from spilling into production systems.
- Red cell: Executes only the injects in the approved plan and reports exactly what was run and when.
- Blue cell: Triages alerts, documents decisions and follows the incident response procedure for the client.
- White cell: Holds the master timeline, monitors safety controls and calls time when the exercise must pause.
- Observers: Platform and compliance staff who record gaps in process, tooling and evidence.
- Debrief: A blameless session within a set period after the exercise, comparing the timeline with alerts, response actions and evidence.
Agree on the debrief format, the owner of each follow-up action and the date the detection change will be retested before the exercise begins.
Success means the detection logic produces the expected alert from the expected telemetry, and the response team acts on it within the time the client has set for its own procedures. A run that produces an alert only by luck, or that depends on a single analyst's knowledge, is not a successful detection. Define these criteria before the exercise so the result is measured, not argued after the fact.
- Telemetry present: Every expected process creation, command execution and process termination event reached the SIEM and parsed correctly.
- Alert fidelity: The rule fired on the targeted inject and stayed quiet on the benign baseline, with confounders documented.
- Response timing: Triage and escalation followed the client's internal targets, which the client should state in writing.
- Evidence quality: Analysts preserved the logs and notes needed for an audit trail and later review.
- Gap detection: The telemetry fault was noticed and reported.
Record each criterion as met, partly met or missed, and link every missed criterion to a named owner and a retest date.
Questions SOC leads and detection engineers ask about T1668
How do SOC teams tell legitimate exclusive locks from malicious ones?
Start by baselining which processes normally take exclusive control of files, devices or resources on each host class, using Process Creation and Command Execution telemetry gathered over a representative period. Legitimate activity usually traces to a known parent process, a signed binary, a managed deployment path and a predictable schedule. Investigate when the requester is unusual for the host role, when the parent process runs from a user-writable location, when a lock persists far longer than the application normally needs, or when Process Termination events remove a security or backup agent nearby. Confirm each hit with the system owner and record the decision, so the allowlist stays auditable.
Which ATT&CK version should a T1668 detection rule target?
Target the exact ATT&CK version your detection library references, and write that version into the rule metadata. ATT&CK v18, released October 28, 2025, replaced technique-level detections with detection strategies and analytics and changed data components, so rules written against older technique pages need re-mapping. Pin one version, download the matching STIX bundle from the attack-stix-data repository, and check T1668's platforms and data components there before writing logic. Confirm the current release status on the ATT&CK updates page before any rollout, and treat any version change as a planned change, not a silent edit.
How do we cover T1668 when it has no clear sub-technique structure?
Do not invent sub-technique coverage. Treat T1668 as a single technique and organize rules by platform (Linux, macOS and Windows) and by the telemetry each rule consumes, such as Process Creation, Command Execution and Process Termination. If the ATT&CK version you pin lists no sub-techniques for T1668, build detections around observable behaviors you can test, and record remaining gaps openly in the coverage matrix. Have a detection engineering lead verify the technique's sub-technique entries directly in the version-pinned bundle before reporting coverage to leadership or auditors.
How do we test T1668 detections without disrupting production systems?
Rehearse in a private cyber range that mirrors production logging, not on live endpoints. Build a lab with the same operating systems, agent versions and log pipeline, replay benign administrative activity alongside controlled, scripted test activity, and measure whether alerts fire and reach the analyst queue. Label test artifacts so they can be filtered from production dashboards, and use a change window and a rollback plan for any rule that touches live hosts. Measure false positives against normal administrative work across the business cycles your team runs, including scheduled jobs and month-end. DeployOpen builds private cyber ranges, so the test environment can sit inside your own infrastructure.
How do we map T1668 rules to data components after ATT&CK v18?
After v18, map each rule to the detection strategies and analytics for T1668, and drop legacy detection text from your library. Each analytic should name the data components it reads, such as Process Creation (DC0032) or Command Execution (DC0064), along with the log source fields that populate them. Keep a mapping table in version control with the technique ID, the detection strategy or analytic ID, the data component ID, the log source and the ATT&CK version. Check that every referenced data component exists in the target bundle. Confirm field-level mappings with your telemetry vendor or agent documentation, because ATT&CK does not define your log schema.
How often should we re-check T1668 mappings after new ATT&CK releases?
Re-check on every ATT&CK release your team adopts, and also on a fixed review cycle set by your governance process. The releases in the supplied timeline are v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Each release can rename, deprecate or revoke techniques, so diff the new STIX bundle against your pinned version and check T1668's name, platforms, data components and analytics. Route any rule changes through change control, and record the review date and ATT&CK version in the mapping file so auditors can trace which version governed each rule. Ask any provider how they handle releases during a retainer before you sign.
How DeployOpen builds T1668 detections, purple team exercises and range scenarios
DeployOpen works on T1668 Exclusive control inside your own infrastructure, starting from a written scope and ending with detections your team can run and maintain. The work covers open-source platforms, security testing and private cyber range exercises, with each step documented for your security engineers and compliance leads.
How we scope
- Agree in writing which operating systems, such as Linux, macOS and Windows, are in scope for T1668 detections.
- Confirm which telemetry sources exist today, including process creation, command execution and process termination logs.
- Name the ATT&CK version each detection maps to, so later releases can be reviewed against the same baseline.
How we build
- Write detection logic in Sigma and map it to the data components used for Persistence techniques in your environment.
- Configure collection and alert rules in your existing open-source stack, such as Wazuh, Zeek or Security Onion, where those tools are deployed.
- Build purple team test cases in a private cyber range so each detection is exercised before it reaches production.
How we hand over
- Deliver detection documentation covering data sources, logic, known gaps and the ATT&CK mapping for each rule.
- Provide response runbooks that describe triage steps, containment options and escalation paths for T1668 alerts.
- Walk your analysts through validation results and the range exercise so they can repeat the tests after handover.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, ATT&CK version reviews and continuous testing are available as a retainer.
- Ask any provider how they will track rule changes when MITRE releases updates that rename or deprecate techniques.
