What T1647 Plist file modification means for macOS defenders
T1647 Plist File Modification is a macOS technique in the Defense Impairment tactic (TA0112), which ATT&CK v19 split out of Defense Evasion. MITRE describes this tactic as an attempt to break the security mechanisms, pipelines and tooling that defenders rely on to see and trust activity. For a SOC lead, the concern is that *property list files*, the configuration files macOS uses for services, applications and launch agents, can decide whether endpoint security tooling and logging run as intended. A change to one of these files can reduce visibility without producing an obvious alert. This page targets ATT&CK v20.0, so any detection mapping should be checked against that version before it is deployed.
Conceptually, what an adversary gains is reduced visibility on a Mac, not necessarily new code running on it. Changes of this kind tend to matter most after an intruder already has a foothold and enough privilege to write to the relevant locations, because the goal is to keep defenders from seeing later steps. For that reason, the question is less about whether a plist can be edited at all and more about which plists on your managed fleet govern security agents, logging and update behavior, and who or what is allowed to write them. Start with an inventory of those files on a representative set of Macs, and record the owners and write permissions for each.
Next, confirm with your endpoint detection and device management vendors which security settings are delivered through configuration profiles and which are read from local files, since that determines where a legitimate change should come from. Decide now whether an unexpected modification to a security-relevant plist is treated as a high-severity event, and who receives it out of hours. Finally, plan to rehearse the detection in a private cyber range, so that the alert fires, the analyst can tell an approved change from a tampered one, and the response steps are tested before an incident forces the question.
Which telemetry reveals plist file modification on macOS
This table maps the three data components most often used for T1647 (Command Execution, Process Creation and File Modification) to the signal each one gives on macOS, the open-source collector that can supply it, and the fields that need normalizing. Read each row as a separate source: no single source is sufficient on its own, and coverage must be confirmed in your own estate before you rely on any of them.
| Telemetry source | Signal for plist changes | Open-source collector | Baseline and normalization notes |
|---|---|---|---|
| Command Execution (DC0064) | Shell or utility invocations that read or write property list files, including plist editing tools run from scripts or launch agents | Endpoint agent logs or Velociraptor artifacts that capture command-line activity, if your collector supports it on macOS | Normalize the executing user, parent process, working directory and full command line. Confirm which macOS versions your agent captures arguments for. |
| Process Creation (DC0032) | Process starts linked to plist edits, especially those launched from user-writable locations or by unexpected parents | Wazuh agent on macOS, or Velociraptor process artifacts, with the macOS unified log as a supplementary source | Baseline the expected parent-child pairs for common management, update and developer tools. Normalize process path, code signing identity and parent process ID. |
| File Modification (DC0061) | Changes to plist files in launch daemon, launch agent and preference directories, recorded with hash or attribute change | Wazuh file integrity monitoring on agreed directories, or Velociraptor file change artifacts | Baseline the directories and files that change during normal operation, such as updates. Normalize path, file hash before and after, owner, mode and the modifying process where available. |
| Correlation key across sources | Joining a process start, a command and a file change within a short time window on the same host | Wazuh rules or Sigma rules applied in your SIEM, such as Security Onion, to correlate events | Normalize host identifier, user, timestamp source and time zone. Clock skew between sources is a common reason correlations fail. |
| Coverage confirmation | Whether each source actually fires on your macOS builds, fleet and privilege levels | Test with benign edits in a cyber range before relying on the source in production | Ask your collector vendor and your own administrators to confirm which directories, versions and agent options are covered. Do not assume coverage from documentation alone. |
Detection ideas for plist changes that disable or alter controls
Property list changes on macOS can switch off security settings, logging or update behavior without touching a binary. The ideas below combine file events on specific plists, the utilities used to edit them, the process that made the change, and what changed afterward. Each one is tuned against known administrative and MDM activity so that alerts stay tied to real risk.
File modification on security plists
Watch for writes to a short, deliberately chosen list of security-relevant property lists, such as those governing firewall, Gatekeeper, logging, software update and privacy settings. Use the File Modification data component as the source and key the rule on the exact path of each file rather than on a broad directory. Baseline the normal write frequency per host over several weeks, then alert on any change outside the MDM or update window. Known false positives include MDM profile pushes, operating system updates and administrator maintenance, so suppress by signed process and change window rather than by user name.
Configuration utility execution against plists
Alert when a command-line configuration utility that reads or writes property lists runs with arguments pointing at a protected plist. The Command Execution and Process Creation data components supply the command line and parent details needed for this. Tune by allowing only the known administrative accounts and automation tools that your team has documented, and alert on the rest. Expect false positives from configuration management agents, MDM clients and scripted hardening, so maintain an allowlist of expected command patterns per fleet group.
Parent-child process context
Score a plist change by the process tree that produced it. A write issued by a user-launched shell, a script interpreter or an unsigned binary is more concerning than one issued by a signed system service or the MDM agent. Review the parent chain for a fixed window before and after the event, and escalate when the parent was started from an unusual location or by a remote session. Baseline the normal parent processes for each protected file, since legitimate software updaters can look similar to tampering.
Correlation with logging and security setting changes
A plist edit that disables logging, firewall or update controls is often followed by other changes within a short period. Correlate the plist event with later modifications to audit configuration, unified logging behavior or security preferences, and with silence from expected log sources on the same host. Set the correlation window from your own measured change patterns, since no fixed window is defined for this technique. Known false positives include planned maintenance windows, so link the alert to change tickets where possible.
How to validate the T1647 detection before trusting it
This sequence proves that the T1647 Plist File Modification detections on macOS fire on the expected telemetry, measure how quickly they fire, and show how often they fire on normal activity. It ends with a dated validation record that the team re-runs whenever the ATT&CK version or the macOS fleet changes.
Define the emulation scenario and expected telemetry
The detection engineer writes a short scenario that describes the modification of a property list file in a way that matches the technique, along with the telemetry each detection should produce. The expected record set covers Command Execution, Process Creation and File Modification events, including the process, file path, user and parent process fields the rule depends on. The scenario is signed off by the security engineering lead before anyone runs it, so the expected results are fixed in advance and cannot be adjusted to fit what the sensor happens to record.
Prepare an isolated macOS test host
The platform team builds a dedicated macOS test host inside the private cyber range, with the same agent, logging configuration and endpoint security tooling used on production endpoints. The host has no route to production networks and holds no production credentials. The output is a host inventory that records the operating system build, agent version, log level and forwarding path, so every later result can be traced to a known configuration.
Run the scripted emulation under change control
A named tester runs the agreed scenario on the test host from a written runbook, with a second engineer observing and logging the start and end times of each step. The tester does not improvise beyond the runbook, so any deviation is recorded as a finding. The output is a timed execution log that the detection review can compare against the telemetry.
Confirm each detection fires with the expected fields
The engineer searches the Wazuh or SIEM archive for the events produced by the run and checks each Sigma-derived detection against the expected telemetry. For every rule, the record notes whether it fired, which data component it matched, and whether the fields needed for triage (process, file path, user, parent process and hash where available) are populated. Any missing field or silent rule goes into the gap register before the next step begins.
Measure detection latency and benign false positive rate
The engineer records the time between each emulated action and the alert reaching the case management queue, then replays the same rules over a benign baseline collected from representative macOS endpoints for a period the security lead sets in advance. The output is two figures for each rule: observed latency from the test run and the number of benign matches per baseline period, with the top causes of each false positive listed. Teams should confirm their own latency targets and baseline window with the SOC before the run, since no supplied figure applies to every environment.
Record results and file gaps with owners
The validation record captures the scenario version, ATT&CK version targeted, test host configuration, rule versions, latency, baseline results and each gap with an owner and a retest date. Gaps might include missing audit configuration, an unparsed field, or a rule that depends on telemetry the endpoint agent does not collect. The record is reviewed and approved by the detection lead, and it becomes the evidence that the detection was tested rather than assumed.
Re-validate after ATT&CK or telemetry changes
The team re-runs the scenario and baseline comparison whenever MITRE releases a new ATT&CK version that changes the technique, its detection strategy or its data components, and whenever the endpoint agent, logging policy or macOS version changes in the fleet. Because ATT&CK releases can rename, deprecate or revoke techniques, each validation record names the version it targets. The output is a new dated record that either confirms the detection still holds or opens fresh gaps for the next cycle.
How to baseline property list changes on macOS fleets
Start by building an inventory of the property lists that matter to your security tooling, logging and endpoint management. On macOS these are the .plist files that control EDR and logging agents, unified logging and audit configuration, MDM enrollment and profile handling, Gatekeeper and XProtect behavior, and the login and launch items that start your security agents at boot. Record each file's path, the component that reads it, the component that writes it, and the owner accountable for changes to it. Confirm the inventory against your own estate, because the files present depend on your MDM product, your EDR vendor and the macOS versions in your fleet. Ownership is the piece most teams skip. An entry without a named owner in security engineering, platform engineering or the endpoint management team will generate alerts that nobody can triage.
Next, separate expected changes from unexpected ones. Legitimate writes to these files usually come from a small set of sources: MDM pushing a configuration profile, a macOS update or security response install, your EDR vendor's own updater, or an administrator working through a documented change. Map each expected source to the files it touches and the process or account that performs the write, and record the change window and ticket pattern that should accompany it. Anything that modifies a file outside those mappings, or that comes from an unexpected parent process or an interactive session, becomes the unexpected category. Verify that your MDM and update workflows produce the process and file telemetry you expect before you rely on them, since the exact artifacts depend on your product and macOS version.
The baseline then feeds allow-lists in the detection rules. Each expected writer, identified by signing identity, process path and parent process, becomes an explicit exception scoped to the specific files it is allowed to modify, rather than a blanket suppression for a whole directory. Review these exceptions on a schedule and whenever MDM policy, the EDR vendor or the macOS release changes, because stale allow-lists quietly hide real modifications. Store the inventory and owner register under version control so each change to an exception is traceable to a decision. Validate the tuned rules in your private cyber range by replaying expected update and MDM activity and confirming it stays quiet, then replaying an unexpected modification and confirming it alerts.
Preventive controls for T1647 using ATT&CK mitigations
These controls reduce T1647 exposure by hardening where macOS property list files live, who can change them, and whether changes are recorded. Developers of security tooling are responsible for protecting their own configuration, while your team governs the host controls around it. Confirm each mapping against the ATT&CK page for the version you target before you rely on it.
Application Developer Guidance
The ATT&CK mitigation Application Developer Guidance applies to developers and vendors of security tooling, who should protect the configuration files their macOS agents install or read, including property list files. Treat these files as part of the signed build: sign the application and its helper components, avoid loading configuration from paths that unprivileged users can write, and validate configuration integrity at startup. Ask each vendor how they handle this for every macOS agent you run, and confirm the T1647 mapping on the ATT&CK page for your targeted version.
Restrict file and directory permissions
Mitigation M1022 is the control most directly tied to the file side of T1647. Limit write access to the directories that hold launch and preference property lists so that only administrators and the owning service account can change them. Review ownership and permission settings on those directories after each OS upgrade and software installation, because installers sometimes reset them. Confirm the M1022 mapping for T1647 against the targeted ATT&CK version.
Audit configuration changes
Mitigation M1047 covers the logging needed to see changes to property list files. Enable file change auditing on the directories that hold system-wide launch and preference files, and forward those events to your central log platform, such as a Wazuh deployment, where they can be correlated with process creation records. Set retention long enough to investigate changes found in a periodic review. Ask your team which macOS audit events and paths are collected today, since coverage often has gaps.
Privileged account management
Mitigation M1026 limits who can change system-level configuration in the first place. Keep administrative rights on macOS hosts with a named set of accounts, and require elevation for changes to system launch and preference locations. Review membership of administrative groups on a fixed schedule and remove accounts that no longer need access. Standard user accounts should be unable to alter files that a system service loads at boot. Confirm the M1026 mapping for T1647 against the ATT&CK page for your targeted version.
Validate mappings for your ATT&CK version
ATT&CK mappings can change between releases, and these pages use Enterprise ATT&CK 20.0. Check the T1647 entry on the ATT&CK site and in the enterprise-attack STIX bundle for the version you run, and record that version in your control and detection documentation. Confirm that each mitigation in this section still maps to T1647 and its sub-techniques, and look for any newly added mitigation. Treat any gap between the mapping and your control inventory as an open item for your next review. The attack-stix-data repository publishes the bundles for comparison.
Triage and response when a plist modification alert fires
This sequence turns a plist modification alert into a confirmed finding, a contained endpoint, a restored configuration and a record that an incident responder or auditor can follow. It separates benign administrative changes from tampering that disables logging or security settings.
Confirm the change actually occurred
The on-call analyst opens the raw file modification or command execution event in the SIEM and checks the affected path, the hash before and after where available, and the timestamp. Benign causes such as software updates, MDM check-ins and user preference changes are noted but not closed yet. The step is done when the analyst records whether a change to the property list is confirmed, with the event identifiers attached to the ticket.
Identify the process and user context
The analyst pulls the process creation record for the writing process, including parent process, executable path, code signing status, the user account and the host. They check whether the writer is a known system component, an MDM agent or a user application, and whether the process was launched interactively or by a background service. The step closes when the analyst can name the process lineage and the account, or states that the lineage is unknown and escalates.
Compare the file against its baseline and MDM policy
The analyst compares the current property list with the last known-good copy from the configuration baseline, and checks the managed preference profile in the MDM console for the keys in question. Differences are classified as expected (policy-driven), unexpected (no matching policy) or conflicting (policy says one value, the file says another). The step is done when each changed key has one of these labels in the ticket.
Check for related logging and security setting changes
The analyst looks for nearby events that often accompany tampering: changes to logging or audit configuration, disabled security agents, modified firewall or Gatekeeper-related settings, and new launch items or login items created within the same window. Correlation is done by host and time range in the SIEM, using the detection telemetry already collected. The step closes when the analyst records either no related changes or a list of related events that have been added to the case.
Contain the endpoint if tampering is plausible
If the change is unexpected and the writing process cannot be explained, the responder isolates the host from the network through the endpoint management tool while keeping the agent connected for collection. Containment decisions follow the organization's own runbook and approval path. The step is done when the host status shows isolated and the responder has logged who approved the action and when.
Restore the configuration from a known-good state
The administrator restores the property list from the approved baseline or re-applies the managed profile through MDM, then confirms the restored values match policy. Where the change was made by a trusted process that should not have run, the responder also addresses that process before restoring, so the change does not recur. The step is done when a follow-up comparison against the baseline shows no differences for the affected keys.
Decide when to escalate to incident response
Escalate to the incident response team when the writing process is unknown or unsigned, when logging or security controls were disabled, when the same change appears on several hosts, or when there is evidence of credential access or lateral movement. The triage lead records the escalation decision and reasons in the case. The step closes when the decision is documented, even if the answer is that no escalation was needed.
Preserve evidence and document the outcome
Before reimaging or further changes, the responder preserves the modified property list, a copy of the baseline, the relevant unified log extract, EDR process records and the MDM change history, with hashes and collection times recorded. The case record then states the cause, the restored values, the containment actions and any tuning needed for the detection. The step is done when a reviewer who did not work the alert can reconstruct the timeline from the stored evidence.
Rehearsing T1647 detection and response in a private cyber range
A private cyber range for T1647 needs enough macOS endpoints to show how property list changes appear in logs, and a collector that receives those logs without touching production networks. Keep the range fully isolated from corporate and internet-facing systems, and build each endpoint from a known image so that the baseline of normal plist activity is documented before the exercise starts. The goal is a repeatable lab, not a copy of production.
- Isolated macOS endpoints: Use dedicated test hosts with a recorded macOS version, logging configuration and agent version so results can be compared across runs.
- Collector layer: Deploy a Wazuh manager or a Security Onion sensor in the range, and confirm which endpoint telemetry it ingests for process creation, command execution and file modification.
- Rule set under test: Load Sigma-based rules that describe plist modification behavior, convert them for the chosen platform, and record the rule version under test.
- Baseline capture: Record normal plist activity from installers, updates and device management tools so that benign changes are known before malicious-style injects run.
- Access and scope: Agree in writing who may run injects, which hosts are in scope, and the exercise window.
Confirm with your platform team which macOS agent features and log sources are available in your version, and agree exercise timings in the written scope before the range is powered on.
Injects are scripted events that the exercise control team triggers so the blue team can practice detection and triage. For T1647, injects should describe the outcome, such as a configuration file changing in an unexpected way, and never supply the technique steps, commands or tooling. The control team keeps the script, the timing and the expected detections in a private record that is not shared with responders during the exercise.
- Benign change inject: A planned, change-managed update to a plist, such as a preference change made through an approved management workflow, to test whether analysts can separate authorized activity from suspicious activity.
- Unexpected change inject: An illustrative modification to a plist outside any change ticket, used to test whether the rule fires and whether the alert carries the right process and file context.
- Repeat and volume inject: A small number of similar events spread over time, to check that alerts are not suppressed or duplicated in a way that hides the pattern.
- Control and timing log: Record each inject with its time, expected alert, and the person who triggered it, so results can be checked afterward.
- Stop conditions: Define in advance how the control team halts an inject if the range behaves unexpectedly.
All injects should be reviewed by the security lead before the exercise, and any hypothetical example used in the briefing should be labeled as illustrative.
Good detection in the range means the expected alert appears within the time agreed in the written scope, carries the fields analysts need, and moves through triage without confusion. Measure detection against the injects in the control log, not against memory of what happened, and compare results across runs so that rule tuning is evidence based.
- Timely alert: The alert arrives within the agreed window after the inject, and the team records any delay with the component responsible, such as the agent, the collector or the rule.
- Correct fields: The alert shows the host, user, process, and the path of the modified plist, so analysts can identify what changed without reading raw logs.
- Clean triage: The analyst can classify the event as authorized or unauthorized using the change record, and documents the reasoning in the ticket.
- Benign handling: Authorized changes produce either no alert or a low-severity event that is easy to close, which shows the rule is not generating noise.
- Gap register: Every missed or late detection is logged with a cause and an owner for the fix.
Confirm with your analysts which fields your current rule outputs, and retest after each tuning change so that the results reflect the version of the rule in use.
Good response means the team contains the affected endpoint, restores the plist to its approved state, and records lessons learned in a form that improves the next run. The exercise should test handoffs between the security team and the platform team, because restoration usually depends on configuration management and not on the analyst alone.
- Containment: The responder isolates the endpoint from the range network or limits its access according to the runbook, and records the decision time.
- Restoration: The platform team restores the plist from a known good source, confirms the restored state, and verifies that the endpoint returns to its baseline.
- Evidence preservation: The team keeps copies of the altered file metadata and related log entries before restoration, so the event can be reviewed later.
- Communication: The incident lead sends status updates on the schedule in the runbook, and the exercise log captures who was informed and when.
- Lessons learned: The team holds a short review that updates the detection rule, the runbook and the inject library, and assigns owners and due dates for each change.
Before the exercise, confirm with your platform and legal teams which restoration and evidence steps require approval, and make sure those approvals are reflected in the written scope.
Questions SOC leads ask about detecting T1647
Which macOS log sources give the most reliable signal for plist file modification?
File modification events on the property list locations are the most direct signal, paired with process creation and command execution records that show which binary or script made the change. Endpoint telemetry should capture the writing process, its parent, its code signature and the user context, because a plist change without that context is hard to triage. Unified log entries can add useful detail on services that reload configuration after a change. Confirm with your EDR vendor which of these fields it records by default and how long it retains them, since retention limits decide how far back you can investigate.
How do you separate MDM-driven plist changes from suspicious ones?
Start by tagging changes that originate from your mobile device management platform, using the process identity, parent process and managed preference paths as the baseline. Changes outside that baseline, or made by an interactive user session or an unsigned process, deserve review. Keep a documented list of expected writers per host group, and review it whenever a profile is added or retired. Alerts should carry the MDM profile identifier when your tooling exposes it, so analysts can match a change to an approved deployment quickly.
How should detection mappings handle ATT&CK v18, v19 and v20 changes?
Record the ATT&CK version in every detection rule and mapping, and check each release for renamed, deprecated or revoked techniques before you update content. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics and changed data components, so older rule metadata may cite retired references. ATT&CK v19 introduced Defense Impairment as a separate tactic with ID TA0112, which affects how coverage reports group techniques. Use the STIX bundles from the attack-stix-data repository as the reference, and diff them between versions in a change-controlled process.
How do you measure detection coverage for plist file modification?
Measure coverage by checking which of your macOS endpoints forward the required telemetry, which rules are enabled and tested, and whether alerts reach a responder within your agreed triage process. Track these as separate numbers, because a rule that is deployed but has never fired in testing gives little assurance. Map each rule to the ATT&CK technique and sub-technique it covers, and keep the mapping in version control. Ask your team to define the target coverage in writing before reporting progress to leadership.
How can you test plist detections without live attacker tooling?
Use benign, scripted changes to the same plist paths in a private cyber range, executed under a controlled test account and documented as test activity. Each test should state the expected event, the expected alert and the expected response, so the result is pass or fail rather than a judgment call. Run the same tests after every rule change and after major macOS or EDR updates, since either can alter telemetry. Keep test records as evidence for the detection validation section of your program.
Can our own team run this detection program without outside help?
Many SOC teams can run the program internally if they already operate an EDR or Wazuh deployment, have macOS administration skills and can dedicate time to rule tuning and testing. The work splits into one-time setup, such as telemetry onboarding and baseline building, and recurring work, such as rule maintenance, ATT&CK version reviews and periodic range exercises. Ask an external partner for a written scope that lists the deliverables, the hosts covered and the handover items if you want outside support. DeployOpen plans, implements and documents open-source platforms inside your own environment and runs cyber range exercises, so it can be scoped to any part of this work.
What does a cyber range exercise for this technique typically require?
A cyber range exercise needs an isolated set of macOS test hosts, a log pipeline that mirrors production telemetry, a defined set of benign plist changes, and a scoring sheet that records alerts and response times. The effort depends on how many host builds you test, how many detection rules you validate and how many responders take part. Ask any provider to itemize setup, exercise delivery and debrief as separate line items in a quote, and confirm which environment the range runs in.
How DeployOpen builds T1647 detections and range scenarios
DeployOpen approaches T1647 Plist file modification as a fixed-scope engagement inside the client's own macOS fleet and logging stack. The work starts with written scope, moves into detection engineering and cyber range rehearsal, and ends with documented handover and optional ongoing support.
How we scope
- Confirm which macOS fleet segments, configuration profiles and property list locations fall inside the written scope.
- Agree which telemetry sources, such as Command Execution, Process Creation and File Modification, are available in your environment.
- Record the ATT&CK version the detections target, so mappings stay correct after future releases.
How we build
- Write detection logic in plain language first, then translate it into Sigma rules and Wazuh or Security Onion queries.
- Map each rule to the ATT&CK Application Developer Guidance mitigation and to the relevant data components.
- Build cyber range scenarios that replay controlled property list changes on isolated macOS hosts, with expected alerts documented.
How we hand over
- Deliver detection rules, tuning notes, known false positive sources and test results in a format your analysts can reuse.
- Provide range exercise runbooks covering detection, triage and response steps for T1647 Plist file modification.
- Walk your security engineers through validation results and record open items in the written handover.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial work.
- Confirm with DeployOpen which post-handover changes, such as new macOS releases or ATT&CK version updates, the retainer covers.
