How T1039 turns shared drives into a collection point
T1039 Data from Network Shared Drive is the technique an adversary uses to gather data of interest from file shares that the organization already mounts for its own staff. For a SOC lead, the hard part is that shared drives hold much of the business's working data, and reading it looks like ordinary use. Finance folders, project directories and HR shares are opened every day, so a single bulk read can look like a busy colleague. Detection therefore depends less on spotting a forbidden action and more on noticing that a particular account, host or session touched far more files, or different folders, than its role normally does. In ATT&CK, Collection (TA0009) is the tactic that describes the adversary trying to gather data of interest to their goal. It sits after the adversary has found and reached useful systems and before data is moved out, staged or archived. T1039 is one of the Collection techniques that targets a specific source, the network share, rather than a single endpoint or application. Its sub-techniques and related techniques elsewhere in the matrix cover staging and archiving, which is why this page treats share reads as one stage of a longer chain rather than an isolated event.
Because ATT&CK is revised on a regular cycle, defenders should record which version their mappings target. This page uses Enterprise ATT&CK version 20.0, released on 2026-10-13. Releases can rename, deprecate or revoke techniques and change how detections are described, so a rule that cites a technique ID without a version can drift out of step with the matrix. Confirm the version your SIEM content, Sigma rules and coverage reports reference, and check the MITRE ATT&CK updates page before each planned upgrade of your detection content. The practical decision for the SOC lead is which shares and which telemetry to treat as in scope before an incident occurs. Ask the file server and storage owners whether file access auditing is enabled on the sensitive shares, how long those logs are retained, and whether they reach the SIEM in a form that can be queried by account and path. Without that baseline, collection from a shared drive is often only visible after the data has already left the environment.
Which telemetry reveals T1039 on Linux, macOS and Windows
This table maps each platform to the telemetry that reveals T1039 activity against network shares, the open-source collector that gathers it, and the blind spots each source leaves. Read it as a starting inventory: confirm the data component IDs (DC0039 File Creation, DC0055 File Access) against the ATT&CK version your detections target before writing rules. The main takeaway is that no single source covers all three platforms, so network-side visibility into SMB and NFS is needed alongside host logging.
| Platform | Host telemetry and collector | Network telemetry and collector | What the sources cannot see |
|---|---|---|---|
| Windows | File Access and File Creation events from Windows auditing on mapped share paths, collected by the Wazuh agent or Sysmon | SMB traffic captured by Zeek or Suricata at the segment where file servers sit | Access performed through an encrypted channel without a visible share path, and shares auditing that was never enabled |
| Linux | File access on mounted CIFS or NFS paths logged through auditd rules, collected by the Wazuh agent | NFS and SMB sessions parsed by Zeek or Suricata on the server or mirror port | Reads performed on the file server itself, which appear as local access, and mounts made before auditing was configured |
| macOS | File access and creation on mounted SMB volumes through the endpoint security logging, collected by the Wazuh agent where supported | SMB sessions observed by Zeek or Suricata on the network path | Share mounts that are not logged on the endpoint, and file events that the agent does not capture in full detail; confirm coverage in your version |
| Cross-platform | Share access logs on the file server or NAS, forwarded to the SIEM for correlation with endpoint events | Volume and timing of share sessions compared against a per-user baseline | Activity on storage appliances that cannot forward logs, and encrypted sessions where only metadata is visible |
Detection ideas for T1039 share access and file reads
T1039 activity usually looks like ordinary file access that happens at the wrong volume, by the wrong account, or at the wrong time. The four ideas below combine File Access and File Creation telemetry with share access records so that each one can be tuned against a baseline of normal behavior for your own shares.
Unusual read volume from a share
Count file read events per user and host against a mounted network share over a sliding window, and alert when a session exceeds its own historical baseline by a margin you set during tuning. Bulk reads of documents, spreadsheets or database extracts that a user never touched before are the core signal for T1039 Data from network shared drive. Main false positives: backup agents, antivirus full scans, search indexers and sync clients, which read large numbers of files on schedule. Exclude them by service account and host, not by blanket path exclusions.
Access outside normal account pattern
Build a profile for each account and host pair that reaches a given share, including which folders they usually open and from which network segments. Alert when an account reads a share it has never accessed, or when a host that normally hosts a single workload starts reading finance, HR or engineering folders. The key check is whether the access is explained by a current ticket or role change. Main false positives: new project members, reorganized teams and migrated file servers, so tie the baseline refresh to your access review cycle.
Enumeration followed by reads
Correlate directory listing and share mapping events with file read events on the same session, and alert when a long run of folder traversal is followed within a short interval by reads across many of the folders just listed. This sequence separates a person looking for one file from an actor mapping a share before taking data. Main false positives: build systems and deployment pipelines that walk source trees before compiling, and document management tools that index folders on login. Suppress known pipeline hosts only after confirming their enumeration pattern in your baseline.
Share access outside business hours
Compare the time of each share session with the working calendar that applies to each group, and alert on interactive or bulk read sessions that start outside those windows. Use a longer look-back to reduce noise from shift workers and time zone differences across your teams. The check to make is whether the account, its host and its volume of reads all look unusual at the same time, because a single off-hours login on its own is weak evidence. Main false positives: scheduled jobs, overnight batch processing, and regional teams working across time zones.
Pinning T1039 detections to ATT&CK version 20.0
Every T1039 detection should name the ATT&CK version it targets, because a technique mapping that is correct today can change in a later release. ATT&CK publishes new versions several times a year, and releases can rename, deprecate or revoke techniques and sub-techniques. The detection content for T1039 Data from Network Shared Drive is therefore pinned to Enterprise ATT&CK version 20.0, and that pin should be written into every rule, analytic and report that cites the technique. Version 18 is the change that matters most for detection engineers: it replaced the detections in technique pages with detection strategies (DET IDs) and analytics, and it updated data components (DC IDs) and deprecated data sources. A rule written against the older data source model will not map cleanly to the current structure without review.
To trace T1039 through the enterprise-attack bundle for version 20.0, download the STIX 2.1 file for that version from the mitre-attack/attack-stix-data repository and search for the technique ID T1039 among attack-pattern objects. Record its ATT&CK ID, its sub-technique relationships, and the detection strategy and analytic objects that reference it. Then follow the relationships to the data components, which for Collection techniques commonly include File Access (DC0055), File Creation (DC0039) and Network Connection Creation (DC0082). Confirm which of these your T1039 analytics actually depend on, since a rule that claims File Access coverage must have a log source that produces file access events on the systems you monitor. Save the bundle hash or file name alongside the extraction so the mapping can be reproduced later.
Record the version in three places: the rule metadata, the detection inventory and the change log. In rule metadata, add a field that names the ATT&CK version, the technique ID, the detection strategy ID and the data components used, so that a reviewer can see the basis without opening the bundle. In the inventory, keep one row per analytic with its pinned version and the date it was last checked against the current release. Decide in advance who reviews the mapping when a new ATT&CK version appears, and what triggers a re-check, such as a deprecated data source or a renamed technique. Ask your detection tooling vendor or platform partner to confirm how version fields are stored and exported in your stack, because not every rule format carries custom metadata by default.
How to validate that the T1039 detection fires
This sequence proves, in a private cyber range, that activity resembling T1039 collection against network shares produces the expected events and alerts, and it records how long the gap is between the activity and the alert so the team can tune the detection with evidence.
Agree scope and rules of engagement
The detection owner, the range operator and the system owner of the test shares agree in writing which hosts, accounts and share paths are in scope, what simulated behavior is allowed, who can stop the exercise, and how the range is isolated from production. Nothing runs against production shares. The step is done when every party signs off the scope document and the stop conditions, and the agreed ATT&CK version (for example, the version your mappings target) is written into the plan. Confirm with your legal and HR contacts that the exercise is authorized for the accounts used.
Define the simulated collection behavior
Describe the collection behavior at a high level only: an authorized test account reads and gathers a set of planted, clearly labeled files from several test shares across Windows, Linux and macOS clients, in a pattern that mirrors what the team expects an adversary to do with a shared drive. Map each behavior to the T1039 detection strategy and the data components it depends on, such as File Access and Network Share Access telemetry. The step closes when the expected event for each behavior is written down before the run, so results can be judged against a prediction rather than against what happens to appear.
Stage test shares and telemetry sources
The range team creates dedicated test shares with planted decoy files, enables the audit settings on each share and host that the detection needs, and confirms that the telemetry reaches the SIEM or Wazuh manager. Record the configuration state of each source, including audit policy, log forwarding and time synchronization. Verify with a benign, non-collection file access that the event shows up in the pipeline. The step is complete when every telemetry source has a documented baseline and a timestamped health check.
Run the emulation against test shares
The operator runs the agreed behavior from the in-scope clients in a fixed order, logs the start and end time of each action in the exercise log, and notes any deviation from the plan. The operator does not improvise outside the scope document. The step is done when every planned action has a start time, an end time and an outcome recorded, and the stop conditions were not triggered or were triggered and documented.
Confirm events and alerts
The analyst searches the SIEM, Security Onion or Wazuh for the expected file access, share access and process events, then checks whether the T1039 detection rule produced an alert for each action. Record the matched event identifiers, the rule name and version, and any alert that fired without a planned action. Note missing events separately from missing alerts, because they point to different fixes: a missing event is a telemetry gap, while an event without an alert is a logic gap. The step closes when each planned action is marked as detected, partially detected, or missed, with the evidence reference beside it.
Measure the gap between activity and alert
Compare the timestamp of each action with the timestamp of the matching alert, using a single time source for all systems. Record the delay per action and the pipeline stage where it accumulated, such as log forwarding, indexing or rule scheduling. Agree in advance what delay is acceptable for your operations, and state that threshold in the report instead of assuming it. The step is complete when the gap for every detected action is recorded, along with the actions that never produced an alert.
Record results and preserve evidence
Assemble an evidence package with the signed scope, the exercise log, the planned-versus-observed event table, exported raw events, alert screenshots or exports, configuration baselines and hashes of the planted files. Store it under your change control with restricted access, because it contains details of your detection coverage. The step is done when a reviewer who did not run the exercise can trace each result from the plan to the raw evidence without asking the operator.
Close tuning items and retest
Turn each gap into a tracked item with an owner, a category (telemetry, logic, pipeline delay or documentation), and a retest condition. Adjust audit settings, rule logic or forwarding configuration, then rerun the affected actions in the same range to confirm the fix. Keep the original results unchanged so the improvement is visible. The step closes when every item is either verified by a retest or formally accepted as a residual risk by the owner.
What the SOC does when a T1039 alert fires
The first task for the analyst is to establish who touched which share, from which host, and when. Pull the account, source host and share name from the alert, then confirm each one against the directory and the asset inventory. Check whether the account belongs to a user or service that has a documented reason to read that share, such as a finance close job, a backup operator or a project team. Compare the volume and timing of reads with the account's normal pattern on that share. A large number of file reads from a workstation that normally touches a handful of folders is the kind of deviation that justifies escalation. Record the answers in the case notes before moving on, because the later steps depend on them.
Next, widen the view. A single share alert is rarely the whole picture, so review every share the same account, and the same source host, touched in the window around the alert. Use the file server audit trail and your SIEM to list those shares and the file paths within them, and look for sensitive folders such as HR, legal or customer data that the account has no business reading. If the activity spans several shares or hosts, treat it as a campaign rather than a one-off. Containment is a decision you make on the evidence gathered so far: suspending the account or disabling its session is appropriate when the access is unexplained and ongoing, while restricting the share permissions or removing the source host's access is a narrower step when the account is needed for business. Each action should be logged with the approver's name and time.
Preserve evidence before changing anything that would overwrite it. On the file server, export the relevant audit events and the share permission configuration as they stand, and keep copies of any log retention settings you are about to alter. On the endpoint, capture volatile data and the relevant event logs under your documented procedure before reimaging or powering down. Hash exported files and record who collected them. Escalate to incident response when the access cannot be explained by a known job, when sensitive data appears to have left the share, when the same account shows activity on other systems, or when the source host shows signs of compromise. Confirm your internal escalation thresholds and retention periods with your incident response and legal teams in advance, since those values are set by your organization rather than by ATT&CK.
Preventive controls that limit T1039 exposure
T1039 succeeds when an adversary with valid or stolen access can read large volumes of shared data without friction. The ATT&CK mitigations below reduce what is readable, who can reach it, how easily an account is abused, and whether the activity is recorded. Each control needs confirmation against your own share layout, identity provider and logging pipeline.
Encrypt sensitive information
Mitigation M1041 asks you to protect sensitive data at rest and in transit so that a copied file is not readable by default. For T1039, the question is which shares hold regulated or high-value data and whether encryption is enforced at the file server, the storage layer or within the application that owns the data. Confirm that encryption keys are not stored alongside the shares they protect, and that SMB traffic is encrypted where your platform supports it. Encryption does not stop a user with legitimate read rights, so pair it with access control.
Audit file share access
Mitigation M1047 covers enabling and reviewing the audit settings that make T1039 visible. Turn on object access auditing for sensitive shares and forward those events to your SIEM, so that bulk reads, unusual hours and access by accounts that rarely touch a share become searchable. Confirm that audit policy survives server patching, that log volume is sized so events are not dropped, and that someone owns the review of the resulting alerts. Without this control, the detection content described on this page has no source data.
Train users on share hygiene
Mitigation M1017 addresses the human path: users who store credentials in scripts, copy sensitive files to personal locations or approve unusual sign-in prompts give an adversary the access that T1039 needs. Training should cover where regulated data may live, how to report an unexpected share prompt and why bulk copies to local disks are reviewed. Confirm that training content is refreshed after incidents and that completion is recorded for privileged and data-heavy roles.
Enforce multi-factor authentication
Mitigation M1032 raises the cost of reusing a stolen password to reach a file server. Require strong multi-factor authentication for VPN, remote desktop and any interactive or administrative path to file servers, and review whether service accounts with share rights are excluded. Confirm which protocols still accept password-only authentication in your environment, since legacy clients often do. Multi-factor authentication does not protect a session that is already established, so keep session lifetimes short for sensitive shares.
Manage share permissions and accounts
Mitigation M1018 limits the accounts that can read a share in the first place. Review group membership that grants read access to broad shares, remove standing access that is no longer needed, and separate service accounts from people. Confirm that owners are assigned to each share, that access is recertified on a schedule you set, and that dormant accounts are disabled. Overly broad groups such as all staff or domain users are the most common reason a single compromised account can read a large share.
Apply data loss prevention rules
Mitigation M1057 detects or blocks sensitive content leaving controlled locations. For T1039, DLP is most useful when it classifies data on shares and flags or restricts bulk copies to removable media, sync clients and personal cloud storage. Confirm which content classifiers are tuned for your data, how false positives are handled, and whether endpoint and network DLP both see SMB-mounted paths. DLP rules are only as good as the classification of the data they inspect, so start with the shares that hold the most sensitive records.
Rehearsing T1039 detection in a private cyber range
This environment models a Windows file server hosting departmental shares, with endpoint telemetry forwarded from the server and from a sample of user workstations. The range should contain a seeded share with realistic folder structure built from synthetic documents, a service account with read rights to some folders and not others, and a Wazuh or comparable agent collecting file creation and file access events where auditing is enabled. Schedule injects that read many files across several directories in a short window, then a second inject that copies a subset to a staging folder on the user's workstation. Good detection means the File Access and File Creation events are attributed to a specific account and host, and that a rule fires on unusual breadth of access rather than on any single read. Good response means the analyst can identify the account, list the folders touched, and confirm whether the access matched a documented business role.
- Audit policy coverage: Confirm that object access auditing is enabled only on the folders that matter, and that the event volume is still manageable.
- Breadth inject: Schedule a scripted read across many files and folders so the rule threshold is exercised.
- Staging inject: Schedule a copy of collected files to a local folder to test correlation with File Creation telemetry.
- Attribution check: Verify the analyst can tie events to user, host and share path within the case workflow.
- Tuning review: Record which backup or indexing jobs created false positives and document the exclusion logic.
Check that the rehearsal produced a timeline the on-call analyst could follow without access to the range operator.
This environment models Linux and macOS workstations and jump hosts that mount the same network shares through SMB or NFS clients. Detection here depends on file access telemetry from the endpoint agent and on knowing which mount points are expected. The range should include at least one Linux and one macOS client with the share mounted at a documented path, along with an auditing configuration that records file access under those mount points. Schedule injects that traverse a mounted share from a user session and from a scheduled job, so the team can see how the two appear differently. Good detection separates interactive access from automation and flags access from a host that does not normally mount that share. Good response confirms the mount history, the process responsible and whether the host was expected to reach that data.
- Mount inventory: Record which clients mount which shares in the range, so the analyst has a baseline.
- Interactive inject: Schedule a user session that browses and opens a set of documents on the mounted share.
- Scheduled job inject: Schedule a cron or launchd task that reads the same share, to test whether the rule separates automation from people.
- Unexpected host inject: Schedule access from a host outside the mount inventory to confirm the rule raises a finding.
- Platform parity review: Compare Linux and macOS event fields to confirm the same query logic works on both.
Check that each platform's detections were validated separately, since field names and audit sources differ between operating systems.
This environment models a network sensor placed on the segment between clients and file servers, capturing SMB and NFS sessions for correlation with endpoint data. The range should include a sensor such as Zeek or Suricata positioned to see traffic to the file servers, with logs that record session starts, share names and byte counts without relying on decrypted payloads. Schedule injects that open several sessions to different shares from one client, then transfer a large volume of data in a single session. Good detection flags a client that connects to an unusual number of shares or moves unusually large volumes compared with its baseline. Good response uses the network record to confirm which client and server were involved and to establish the time window for the endpoint investigation. Confirm with the sensor vendor or project documentation which SMB and NFS fields your version logs before writing rules that depend on them.
- Sensor placement check: Verify the sensor sees traffic to every file server in scope, including any encrypted SMB sessions.
- Session breadth inject: Schedule connections to several shares in a short period to test share-count logic.
- Volume inject: Schedule a large transfer from one session to test byte-count thresholds against a baseline.
- Cross-source correlation: Match each network finding to the endpoint events from the Windows or Linux tabs.
- Baseline window: Run the sensor through a normal working period first so thresholds reflect real usage in the range.
Check that an analyst can move from a network alert to the matching endpoint events within one investigation record.
Questions SOC leads ask about T1039 detection
How do you separate T1039 collection from normal file server use?
Separate them by behavior over time, not by a single file event. Normal users open a small set of documents tied to their work, from a predictable set of hosts, during working hours. Collection tends to show a single account or host reading a broad spread of directories in a short window, touching shares it rarely uses, and reading far more files than it writes or modifies. Build a baseline per account and per share from your own file server audit logs, then alert on deviations such as a sudden jump in distinct paths read or a first-time access to a sensitive share. Tune thresholds in the cyber range using both benign bulk jobs, like backups and migrations, and simulated collection, so the rule is tested against the traffic it will meet in production. Document the allowlisted backup and sync accounts so each exception is explicit and reviewable.
Can network sensors see share reads on encrypted sessions?
Usually not the file names or content, but the session metadata is often still visible. SMB sessions are commonly encrypted in transit, so a passive sensor such as Zeek or Suricata may see connection records, the endpoints involved, timing, volume and, depending on the protocol version and configuration, some share and tree connect information. Confirm for your environment which SMB versions and encryption settings are in use, because this determines what the sensor can parse. Where content visibility is required, the reliable source is host or server telemetry: file access auditing on the file server or endpoint. Treat network data as a corroborating signal and map each detection to the data component it actually relies on, since ATT&CK v18 moved detections to detection strategies with data components.
How should service accounts be handled in T1039 rules?
Treat service accounts as the highest-risk identities in the rule, not as an automatic exception. Backup agents, sync tools and reporting jobs legitimately read large numbers of files, so they will generate the same volume signal as collection. Inventory each service account, record its expected source hosts, target shares and working hours, and write per-account baselines instead of global allowlists. Alert when a service account is used from a new host, reads a share outside its documented scope, or authenticates interactively. Review password storage and rotation for these accounts, since a compromised service account can read widely with little friction. Validate each exception in the cyber range by replaying the documented job and confirming it stays quiet while an out-of-scope read still fires.
How often should a T1039 detection rule be retested?
Retest after every change that can alter its inputs, and on a fixed schedule in addition. Triggers include new file servers or shares, changes to audit policy, SMB configuration updates, log pipeline changes, new backup or sync software, and any ATT&CK version update that renames or revises the technique. Scheduled retests, for example quarterly, catch silent drift such as an audit setting that was disabled during maintenance. Keep a versioned test record stating the ATT&CK version targeted, the telemetry source, the simulated behavior and the expected alert outcome. Confirm the schedule and scope with your own change management and risk owners, since the right cadence depends on how often your share landscape changes.
How do you tell T1039 alerts apart from T1005 or T1074?
Distinguish them by where the data is read from and what happens next. T1039 concerns data read from a network shared drive, so the key fields are the share path, the remote source host and the access event on the file server. T1005 covers data collected from the local system, so the alert points to a file read on the endpoint itself with no share involved. T1074 covers data staged, meaning gathered files are copied or written into a staging location, often an archive or temporary folder. A sequence of share reads followed by file creation in a staging path points to staging after collection, so correlate those events by account and time window. Document these distinctions in your Sigma rule metadata and analyst playbook so triage starts from the right data source.
What telemetry must be enabled before writing a T1039 rule?
Enable file access auditing on the file servers and the Windows or Linux hosts that mount shares, forward those events to your SIEM, and confirm each event carries the account, path, source host and result. Without access auditing, the rule has no file-level signal and will only see connection metadata. Also confirm that network connection records from the file server segment reach Zeek or Suricata, and that clock sync is consistent across sources so events can be correlated. Audit volume has a storage and retention cost, so scope auditing to sensitive shares first and expand after tuning. Check the exact event IDs and log settings with your operating system and file server vendor documentation before deploying.
Can we run T1039 detection in-house, or do we need outside help?
Many teams can run the detection in-house if they already operate a SIEM, have file server audit logging and staff who can tune rules. The work that usually needs an outside pair of hands is the cyber range rehearsal, where benign backup jobs and simulated collection are replayed to test thresholds, plus documenting the evidence for an assessment. DeployOpen works on fixed scope, agreed in writing before work starts, and can cover platform implementation, security testing and cyber range exercises. Ask any provider to state what is in and out of scope, which telemetry sources they will validate, and what documentation you receive at the end.
How DeployOpen builds T1039 detections and range scenarios
DeployOpen approaches T1039 Data from Network Shared Drive as a fixed-scope engagement inside your own environment, covering detection logic, telemetry checks and cyber range rehearsal. Each step is agreed in writing before work starts, so your team knows what gets built, tested and documented.
How we scope
- Confirm which platforms and file servers are in scope, including Linux, macOS and Windows hosts that access SMB or NFS shares.
- Inventory which share audit and file access logs already reach your SIEM and where gaps exist.
- Agree in writing the ATT&CK version the detections will target, since releases can rename or revoke techniques.
How we build
- Map detection logic for File Access and File Creation telemetry against T1039 and its share access patterns, described in plain language.
- Configure open-source collection with Wazuh, Zeek or Security Onion to capture network share access events in your environment.
- Write Sigma-format rules and tune thresholds against the baseline of normal file server activity in your environment.
How we hand over
- Deliver rule documentation with data source requirements, known false positive sources and the ATT&CK version each rule targets.
- Run cyber range scenarios in a private range that rehearse the detection and the response steps your analysts will follow.
- Provide a written record of test results, gaps found and recommended changes for your security team to review.
How we support
- Ongoing support, rule updates and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Re-validate detections after ATT&CK releases, log source changes or major file server upgrades in your environment.
- Ask any provider to confirm which open-source versions, log formats and hosting model the quote assumes before work starts.
