How network share discovery shows up in an intrusion
T1135 Network share discovery matters to the SOC lead because it is how an attacker who already holds an account learns which file shares exist on the network and which of them that account can reach. Under the Discovery tactic (TA0007), ATT&CK frames the goal as working out the environment the adversary has landed in, and share enumeration is one of the quickest ways to do that. It is often one step before lateral movement, since shares holding documents, scripts, backups or configuration files are where an attacker looks for the next foothold, credentials or data to collect. The lead's first question is therefore not whether a share list was queried, but whether that query came from an account, host or process that has no business asking.
Visibility varies widely by environment. In some networks, share enumeration is routine for administrators, backup agents, endpoint management and monitoring tools, so the same activity generates a steady stream of benign events and the malicious ones are easy to lose. In other networks, a query from a workstation to the file server's administrative shares is rare enough to stand out immediately. Before writing detections, the lead should ask the platform and endpoint teams which tools legitimately enumerate shares, from which hosts, and under which service accounts. That baseline decides how much of the noise can be suppressed without creating blind spots.
This page targets MITRE ATT&CK v20.0, released on 2026-10-13 according to the attack-stix-data repository index, and every mapping in later sections names that version. ATT&CK can rename, deprecate or revoke techniques between releases, so the lead should confirm the current technique text and its data component references in the MITRE ATT&CK updates page before turning any detection into a production rule. Recording the version alongside each rule makes later reviews faster when the knowledge base changes.
Which telemetry reveals network share discovery
This table maps the data components that most often reveal T1135 activity to Linux, macOS and Windows, with the signal to look for and an open-source collector for each. Read each row as a starting point: confirm every signal against your own hosts, file share layout and logging baseline before relying on it for alerting. Network Traffic Content is listed as supporting evidence only.
| Data component | Linux | macOS | Windows |
|---|---|---|---|
| Process Creation (DC0032) | 新 process starts of share enumeration utilities by unusual parent processes or interactive shells. Collector: auditd execve records forwarded to Wazuh. | Process starts of built-in share listing tools from non-administrative sessions. Collector: Wazuh agent with endpoint process logging, confirmed per macOS version. | Process starts of net-style share enumeration binaries and scripts run by standard users. Collector: Sysmon-style process creation logging shipped through the Wazuh agent. |
| Command Execution (DC0064) | Command lines that list mounted or exported remote filesystems in bursts. Collector: auditd with command capture, or shell history forwarded to Wazuh, subject to privacy review. | Command lines querying SMB or AFP mount points and mounted volumes in quick succession. Collector: Wazuh log collection of shell history and unified logs, confirmed in your environment. | Command lines that enumerate shares across many hosts or query share permissions. Collector: Windows event logging with command line auditing enabled, forwarded by the Wazuh agent. |
| File Access (DC0055) | Reads of mount tables, fstab, and autofs or credential-related configuration by non-admin accounts. Collector: auditd file watch rules feeding Wazuh. | Access to network location preference or mount-related files by unexpected users. Collector: Wazuh file integrity monitoring, confirmed for your macOS build. | Access to share-related registry or configuration data and file share metadata by unexpected accounts. Collector: Wazuh file integrity monitoring and Velociraptor hunts for historical review. |
| OS API Execution (DC0021) | Limited visibility without kernel or library instrumentation. Treat as a gap to confirm, not a primary signal. Collector: auditd syscall rules where performance allows. | Share listing through system frameworks is hard to see without endpoint security tooling. Confirm what your macOS telemetry actually records before depending on it. | Calls to network share enumeration APIs from unexpected processes. Collector: ETW-based sensors or Sysmon-style logging via Wazuh, confirmed for your Windows build. |
| Network Traffic Content (DC0085), supporting only | Share protocol traffic can corroborate host findings. Collector: Zeek or Suricata sensors in Security Onion, with protocol parsing confirmed. | Corroborating SMB or AFP session metadata from sensors. Collector: Zeek or Suricata, confirming whether encrypted sessions limit content visibility. | SMB session and tree connect activity across many hosts can corroborate enumeration. Collector: Zeek SMB logs in Security Onion, confirmed for your network segments. |
| Hunting and retrospective review | Search for bursts of share listing across hosts over a defined window. Collector: Velociraptor artifacts run against a scoped host group. | Search for unusual mount activity across endpoints. Collector: Velociraptor hunts, scoped and approved before running. | Search for share enumeration patterns over recent logs. Collector: Velociraptor hunts combined with Wazuh alert history. |
Detection logic for T1135 that SOC teams can tune
T1135 Network share discovery shows up as a sequence of small, ordinary-looking actions: enumerating shares, reading mount configuration, and touching many targets in a short window. The cards below describe four detection ideas, each with the logic, the thresholds to tune and the benign sources that will fire first, so a SOC can build and adjust them against its own baseline. Confirm every threshold in a lab before it reaches production.
Share enumeration utilities on Windows
This rule watches process creation on Windows hosts for built-in or administrative utilities whose main purpose is listing or mapping remote shares, and it flags them when they run from an unexpected parent process, under an account that does not normally administer file servers, or from a user session with no change ticket. Log Process Creation with full command line auditing enabled so the rule has arguments to match. Tune by allowlisting known management hosts and monitoring servers. Expect false positives from backup agents, endpoint management suites and scheduled inventory scripts, so suppress them by parent process and service account rather than by tool name alone. Start with alerting only and review for two weeks.
Share listing on Linux and macOS
This rule uses Command Execution telemetry from Linux and macOS endpoints to detect shell sessions that list mounted network filesystems or query remote share exports from a user context. The signal is strongest when the same host also shows a new outbound connection to a file server port shortly before the listing. Tune the window and the minimum number of listings per session. Common false positives include configuration management runs, cron jobs that check mount health, and developers using shares for legitimate work. Record the expected admin hosts in your inventory so the rule can treat them as a baseline rather than an anomaly.
Mount configuration reads
This File Access rule fires when a process other than an approved configuration tool reads files that define network share mounts or credential references on Linux or macOS, or when a Windows host reads share definitions from a non-administrative process. Those files are high value for both attackers and defenders, so the rule should also cover writes and permission changes. Set the file list to the paths your platform team actually uses, and confirm audit watches are in place before tuning. Expect noise from backup software, sync clients and provisioning tools that read these files on a schedule. Suppress by known process and service account, and review any exception at each change cycle.
Distinct share targets per account
This correlation rule counts the number of distinct share targets contacted or enumerated by a single account within a fixed time window, then alerts when the count passes a threshold that you set from your own baseline. It is the most useful of the four because it catches T1135 even when each individual action looks normal. Start with a per-role baseline, since file server administrators and backup operators will legitimately touch many targets. Tune the window length, the target count and whether repeated access to the same share counts once. Expect false positives from backup jobs, migration projects and sync clients, so maintain a documented exception list tied to service accounts.
How to validate that the T1135 detection fires
This sequence proves, in a private cyber range or approved lab, that the T1135 Network share discovery detection raises a usable alert, reaches the SOC queue and carries enough context for triage. It also produces a measured false-positive picture and a backlog of tuning items for detection engineering.
Agree scope and rules of engagement
The detection owner, the SOC lead and the range operator agree in writing which hosts, accounts, operating systems and time windows are in scope, who approves each emulation step and how the test is stopped. The emulation is limited to the Linux, macOS and Windows hosts that the detection targets. Confirm with your own change process whether the range or production monitoring needs a notice window. The step is done when the signed scope note names an emulation owner, a witness and a stop condition.
Map the behavior to T1135 and its telemetry
Document the behavior the test will represent, which is network share discovery under the Discovery tactic (TA0007), and record the ATT&CK version the detection targets so the mapping stays valid after future releases. List the data components the detection depends on, such as Process Creation, Command Execution and OS API Execution, and confirm each one is collected on every in-scope host. The output is a short mapping sheet that a reviewer can check against the current technique page. Confirm the technique and its platform coverage in the ATT&CK STIX data for the version you target.
Run an approved emulation without scripted commands
An approved operator, often from a red team or the range team, carries out the agreed behavior on a named test host using a test account, following the scope note. Your team should keep the executed steps in a private runbook held by the emulation owner rather than in the detection ticket, so the detection engineers test against behavior and not against a memorized script. The step is done when the operator confirms in writing the host, account, start time and end time of each activity, and the witness countersigns.
Record timestamps, host and account context
Capture the start and end times of every emulated activity in UTC, along with the host identifier, operating system, the account used and the source address. Pull the matching raw events from the log pipeline and confirm the timestamps line up with the test window, allowing for ingestion delay. Gaps here usually point to a collection problem, not a detection problem, so record them separately. The output is a timeline that links each emulated action to the events it produced.
Confirm the alert reaches the SOC queue
Check that the rule or analytic fires for the test activity, that the alert is created in the SIEM or alerting platform such as Wazuh, and that it lands in the queue the on-duty analyst monitors. Verify the alert carries the ATT&CK technique and sub-technique tags, the host and user fields, and enough detail for a first-line triage decision. The step is done when a ticket or case exists with the alert identifier linked to the timeline from the previous step.
Measure false positives against normal activity
Run the same rule over a representative window of normal administrative activity on the in-scope hosts, such as backup jobs, inventory scans and admin troubleshooting, and count how many alerts fire that are not the emulation. Classify each one by the process, account or path that triggered it. Confirm the baseline window and its length with the data owner, since the appropriate period depends on your environment. The output is a false-positive table that states the alert count, the categories and the proportion reviewed.
Record findings for the detection backlog
Write up each gap as a backlog item with the ATT&CK technique and sub-technique, the rule identifier, the data component involved, the observed behavior and the proposed fix, such as a tuning change, a missing log source or a documentation update for the SOC. Link the item to the timeline and the false-positive table. Assign an owner and a review date during the retrospective. The sequence is complete when the backlog items are reviewed and the rule version used in the test is recorded for the next validation cycle.
Detection differences across Linux, macOS and Windows
On Linux, share enumeration usually leaves a trail through process execution and through reads of client configuration and mount state. Process Creation and Command Execution telemetry are the most reliable signals because most share listing runs as an external program that the host must launch, and auditd or Sysmon for Linux can record each execution with its arguments and parent process. File Access telemetry adds a second view on the files that define remote mounts.
- Process execution with arguments: Collect execution records with full argument vectors and parent process, and tag them with a rule key so your SIEM can filter them consistently.
- Client configuration reads: Watch read access to files that define remote mounts and stored credentials, such as
/etc/fstaband any SMB client credential files your distribution uses. - Mount table changes: Add mount-related audit rules so a new remote mount is visible even when the command that created it was never logged.
- Blind spots: Shell built-ins and scripts launched through a trusted interpreter may appear only as the interpreter. Containers that share the host kernel need audit rules on the host, because rules inside the container will not see host activity.
Confirm that audit rules load in the expected order on each host image and that log forwarding delivers records during a rehearsal, not only in production.
On macOS, the signal depends on how the endpoint agent is authorized and how the unified log is configured. Process telemetry is reliable for command-line activity, but a user who browses to a share through the graphical file manager may produce little process activity to match. The collector design therefore has to cover both process events and the subsystem logs that record network filesystem activity.
- Agent permissions: Confirm that the endpoint security agent holds the entitlements and privacy permissions it needs, and deploy those permissions through your device management profile so they survive reimaging.
- Unified log streaming: Define log predicates for the network filesystem and SMB client subsystems, and stream the matching entries to your SIEM with a retention period that covers your investigation window.
- Audit trail coverage: Where the audit subsystem is still enabled on your build, route its records to the same pipeline so process and file events can be correlated by time and user.
- Blind spots: Graphical mounts may generate fewer process events than command-line mounts. Unified log volume is high, so filters that are too narrow will hide the events you need, and filters that are too broad will bury them.
Confirm with your endpoint vendor and your macOS release notes which events each sensor records, because coverage changes between releases.
On Windows, share enumeration is visible through process creation, through PowerShell activity, and through object access on the shares themselves. Process telemetry shows which tools ran and with what parent, while object access auditing shows which accounts touched which share. Network sensors add a third view by inspecting SMB traffic when the host itself is not instrumented well enough.
- Process creation with command line: Enable command-line capture in process creation logging so that signed built-in tools can be distinguished by their arguments and parent process.
- PowerShell logging: Enable script block logging and module logging so scripted enumeration is recorded even when it does not spawn an external process.
- Share access auditing: Enable auditing on the file share objects and the relevant SACLs, and size the Security log so enumeration bursts do not overwrite earlier records before forwarding.
- Blind spots: Enumeration through API calls may not create a new process at all, so OS API Execution telemetry or network content from a sensor is needed. Remote enumeration is recorded on the target host only in part, so the source host and network sensors must be included.
Confirm that event forwarding subscriptions deliver the share and process events from every domain-joined host, and test this with a controlled enumeration in the cyber range.
Operating System Configuration and related controls
Operating System Configuration (M1028) is the main ATT&CK mitigation for T1135 Network share discovery, because the settings that decide which shares exist, who can list them and what they reveal are set on the host. Network Segmentation (M1030) and Audit (M1047) support it by limiting where share enumeration can reach and by making it visible when it happens.
Inventory exposed shares per host
Start by listing every SMB, NFS or similar share that each Linux, macOS and Windows host publishes, including administrative and hidden shares. Discovery succeeds when a share is visible to a low-privilege account, so the inventory tells you what an adversary would see. Compare the list against the owner and business purpose of each share. Ask your platform team which configuration source is authoritative for share definitions, and whether drift between that source and live hosts is checked.
Restrict default share access
Review the default access settings for each share, including the authentication requirement for anonymous or guest listing and the permissions on the share root. A share that lists its contents to any authenticated user gives discovery far more than a share that only resolves when the caller already knows its name. Confirm with your operating system vendor documentation which defaults apply to your versions, because defaults differ between releases and distributions.
Remove unused and legacy shares
Shares that are no longer needed still answer enumeration requests and still advertise naming patterns, such as backup or finance folders. Remove them from the host configuration rather than leaving them empty. Disable legacy protocol versions that you no longer need, and confirm the change on a sample of hosts with a configuration scan. Record each removal with its owner so the change can be audited later.
Segment file server reachability
Network Segmentation (M1030) limits which subnets can reach a file server's share service at all. A workstation VLAN that has no business reason to talk to a finance file server cannot enumerate its shares, even if the host is misconfigured. Ask your network team to document which source ranges are permitted to the SMB and NFS ports, and to test those rules from each segment during your validation exercise.
Audit share enumeration activity
Audit (M1047) covers the logging needed to see who listed or connected to shares. Confirm that share access and share enumeration events are generated on each platform and forwarded to your central monitoring stack, such as Wazuh. Check that the audit policy is not disabled by local overrides, and that retention is long enough for your investigations. Confirm these details with your operating system and file server documentation rather than assuming the defaults.
Verify controls in the cyber range
Changes to share configuration only count when they are tested. Build a small set of hosts in your private cyber range with the same share settings as production, run a controlled enumeration from a low-privilege account and from a segment that should be blocked, and confirm both the hardening and the resulting alerts. Record the ATT&CK version you tested against, since mappings can change between releases.
Triage steps when a network share discovery alert fires
The first decision is whether the alert reflects an administrator doing routine work or an adversary mapping file shares. Confirm four facts before anything else: the account, the source host, the time, and the share targets. Pull the account's identity record and check whether it is a named administrator, a service account or a standard user. Confirm the source host's asset owner and whether it is a managed workstation, a jump host or a server. Note the exact window of activity and whether it falls inside a change record or a scheduled job. Then list every share the activity touched. A single administrative share enumerated from a managed admin workstation during business hours reads very differently from broad enumeration across departmental shares from an endpoint that has no business reason to browse them.
Next, compare the activity with the baseline for that account and host. Your detection pipeline should already hold several weeks of share enumeration events, so ask how often this account has produced similar activity, from which hosts, and against which shares. Confirm the baseline window with your own SIEM retention settings, since the period you can query determines how much history you can rely on. Then look for follow-on activity against the same shares. Discovery that is followed by file reads, bulk copies, new mappings to unusual shares or authentication failures against those targets is a stronger signal than discovery alone. Check whether the same account authenticated to hosts it had not previously reached, and whether any share access was denied, since repeated denials after broad enumeration often indicate a search for reachable targets.
Escalate with a containment decision, not only a ticket. If the activity matches a documented admin task, close the alert with the change reference and record what you verified. If it cannot be explained, or follow-on access is confirmed, the on-call responder should decide between restricting the account, isolating the source host and preserving its volatile data, or monitoring while the investigation continues. Document who made that decision and on what evidence. Your runbook should name the people authorized to make each containment call and state how quickly they must be reached outside business hours. Agree these roles before an incident, and rehearse them in your cyber range so the decision is not made for the first time under pressure.
Rehearsing T1135 detection in a private cyber range
The range should mirror the parts of your estate where network share enumeration would matter, while staying isolated from production. Build it as segmented networks with Linux, macOS and Windows endpoints, each forwarding logs to a Wazuh manager and sensor traffic to a Security Onion stack. File shares should use naming conventions copied from production (department names, project codes, home directory patterns) so that alerts and analyst queries behave the same way they would at work. Keep the share configuration, account groups and logging settings under version control so each exercise starts from a known baseline.
- Segmented zones: Separate user, server and management segments, with the range having no route to production file servers or identity systems.
- Mirrored share naming: Use production-style share and path names with synthetic data, so detection content is tested against realistic patterns without real records.
- Telemetry coverage: Confirm that process creation, command execution and file access events reach Wazuh and Security Onion on every endpoint type before the first exercise.
- Baseline snapshots: Snapshot each endpoint and share server so the team can reset between runs.
- Ownership: Name who maintains the range, who approves changes and who can stop an exercise.
Before the first run, confirm with your platform and security leads that each log source and share configuration matches what you plan to test.
Injects are staged actions that the exercise control team triggers at times the blue team does not know in advance. For T1135, a useful sequence starts with low-volume enumeration from a single Linux host, then moves to a macOS or Windows endpoint using a different method, then adds a second source to see whether correlation holds. Each stage should have a written expected signal, so the control team can compare what the blue team observed with what the range produced. Keep the sequence of attempts described in the exercise plan, not in the detection content.
- Staged progression: Plan three to five stages of increasing scope, from one host to several, so the team tests both sensitivity and correlation.
- Unannounced timing: Let the control team choose start times within an agreed exercise window, and record the actual times for debrief.
- Mixed platforms: Include at least one Linux, one macOS and one Windows source so platform-specific telemetry gaps appear early.
- Noise injection: Add ordinary administrator activity on the same shares so the team has to separate benign from suspicious patterns.
- Stop conditions: Define when the control team halts an inject, such as a fault in the range or a false alarm that affects other systems.
Send the plan to the exercise lead for approval, and confirm the approach with your legal and HR owners if the exercise touches monitored user accounts.
Scoring should measure detection and response separately. Detection covers whether the expected telemetry arrived, whether an alert fired and whether the alert reached an analyst with enough context to act. Response covers triage time, containment decisions and whether the team followed its own runbook. Record each stage on a common scale agreed before the exercise, and avoid awarding credit for outcomes the team could not have seen. The debrief should produce a short list of changes with named owners, not a general summary.
- Telemetry checks: Score whether each expected event appeared in Wazuh or Security Onion within the time your SOC agrees is acceptable.
- Alert quality: Note whether the alert named the host, account, share and source, and whether it was grouped with related activity.
- Response steps: Check whether the analyst followed the runbook for scoping, evidence capture and containment.
- Gap register: Log each missing source, rule or runbook step with an owner and a retest date.
- Blameless debrief: Review decisions based on what the team knew at the time, and update detection content under version control afterward.
After the debrief, rerun the affected stages on the same baseline to confirm that each change works as intended.
Questions detection engineers ask about T1135
How do I tell admin share listing from attacker network share discovery?
Start by treating the activity as ambiguous: the same enumeration commands run by an administrator, a backup agent or a monitoring tool can look identical to an adversary probing for shares. Separate them by context rather than by command alone. Build an allowlist of known management hosts, service accounts and scheduled jobs, then score the remaining activity on breadth, such as how many hosts are queried in a short window, whether the source is a workstation rather than a server, whether the account has recently logged on interactively, and whether share enumeration is followed by discovery of other hosts or accounts. Confirm the baseline in your own environment before you set thresholds, because the right values depend on how your administrators work.
How should our team handle ATT&CK version changes in detection content?
Name the ATT&CK version every detection maps to, and record the date you last checked it. MITRE publishes updates on a regular cycle, and releases can rename, deprecate or revoke techniques, so a mapping that was correct in one version may need a change in the next. The supplied release history lists v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Pin your rule metadata to a version, then diff the relevant technique and detection strategy entries against each new STIX bundle in the attack-stix-data repository before you update the mapping. Keep the change in version control so auditors can see what changed and why.
Should we alert on network share discovery or only hunt for it?
Alert on the high-confidence combinations and hunt for the rest. Enumeration of shares from a host that has no business doing it, or a burst of share queries across many systems, is usually worth a notification that routes to an analyst. Single, low-volume queries from administrative hosts are better handled as scheduled hunts that review trends, since alerting on them will mostly generate noise. Tune the split with real alert data from your range and production systems, and review it after each tuning cycle so that alerts are not quietly suppressed over time.
How do we map T1135 to ATT&CK v20.0 detection strategies and data components?
In ATT&CK v18 and later, technique pages point to detection strategies (DET IDs) and analytics rather than the older free-text detection sections, and telemetry is described through data components (DC IDs). For T1135, check the technique page and the enterprise-attack 20.0 STIX bundle for the detection strategies that reference it, then list the data components they use, such as Process Creation (DC0032) and Command Execution (DC0064), along with any File Access (DC0055) or Network Traffic Content (DC0085) references that apply to your platforms. Write the mapping as a table with the ATT&CK version, detection strategy ID, data component ID, the log source you actually collect and the rule name. Confirm the platform coverage for each platform you run, because a data component that works on Windows may have no equivalent on Linux or macOS in your pipeline.
How do we measure detection quality for network share discovery in a cyber range?
Measure detection in terms of what you saw, how fast, and how often the alert was useful. Write down the scenario steps before the exercise, run them in a private cyber range, and record for each step whether a rule fired, the time from activity to alert, and whether the analyst reached a correct conclusion. Track false positives from the administrative baseline separately, since they cost analyst time even when the detection works. Repeat the exercise after each rule change and after each ATT&CK version update, and keep the results as evidence. Avoid relying on a single pass rate, because a rule that performs well on one scripted scenario may miss variations that an adversary would use. Ask any testing partner to define in writing which scenarios they will run and what evidence they will hand over.
Which mitigations should we review alongside network share detection?
Review the ATT&CK mitigations that ATT&CK maps to Discovery techniques in general, since they change how much enumeration an adversary can do and how much your logs show. Operating System Configuration (M1028) covers hardening settings that limit what an unprivileged account can list, and Audit (M1047) covers the logging that makes discovery visible. Network Segmentation (M1030) reduces how many hosts a single compromised account can reach, which limits what share enumeration reveals. Document which of these you have implemented, the owner of each control, and the evidence you can show, rather than assuming coverage from the names alone.
What does a cyber range exercise for this technique need to include?
A useful exercise defines the target platforms, the accounts used, the baseline administrative activity running at the same time and the expected detections before anyone starts. Include normal administrative traffic on the same hosts so the team can test how well the allowlist and scoring separate it from the scenario. Run the exercise in an isolated range that mirrors your logging pipeline, so the same collectors, parsers and retention settings are in play. Afterward, hold a review that compares expected and observed results, and assign owners to each gap. Confirm with your range provider which platforms and log sources the range supports before you commit to the scope.
How DeployOpen builds T1135 detections and range exercises
DeployOpen treats T1135 Network share discovery as a detection engineering and validation task inside your own environment, not a generic tool installation. Work starts with a written scope that names the platforms, log sources and ATT&CK version the detections must target.
How we scope
- Confirm which Linux, macOS and Windows hosts, file servers and identity sources feed the detections for T1135.
- Record the ATT&CK version the detection mappings target, since releases can rename or deprecate techniques.
- Agree in writing which telemetry, such as Process Creation and Command Execution, is in and out of scope.
How we build
- Configure Wazuh, Security Onion, Sigma and Velociraptor against the agreed log sources and detection logic for T1135.
- Document detection logic in plain words so analysts can review why each alert fires for share enumeration.
- Test detections against the OS configuration baseline, including the ATT&CK mitigation Operating System Configuration.
How we hand over
- Deliver the detection rules, data source mappings and tuning notes in a format your team can version and review.
- Run a private cyber range exercise that rehearses T1135 detection and response with your analysts.
- Provide runbooks covering triage, containment and evidence collection for network share discovery alerts.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing for T1135 detections are available as a retainer.
- Revisit detection mappings when MITRE publishes a new ATT&CK version that changes the technique or its data components.
