---
{
  "title": "Data from Network Shared Drive",
  "summary": "Collection from network shared drives accesses information on remote file resources.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1039"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1039: Data from Network Shared Drive",
      "url": "https://attack.mitre.org/techniques/T1039"
    }
  ],
  "editorialVersion": 2
}
---

## Shared files extend collection beyond one host

Collection from network shared drives retrieves information stored on remote file resources accessible from an accessed system. The files may appear as an ordinary mapped drive or shared path, but the permissions and audit records can reside on another server. An actor can use existing access to gather material beyond the original endpoint.

The network share is a storage source, not automatically an exfiltration destination. Reading an internal shared document and transferring it outside the organization are different actions requiring different evidence.

## Follow a shared-file access pattern

In a fictional company, a staff workstation reads files from several departmental shares in quick succession. The analyst checks the account, source device, share and file paths, timestamps, and server-side access records. Endpoint evidence may show the process requesting the files or creating a local copy.

A migration, backup, search index, or approved project task could explain the pattern. The team compares the activity with its owner and scheduled work. A mapped-drive name alone can be ambiguous, so preserve the underlying server and share identifiers where available.

Review whether the account accessed only expected folders or crossed into material unrelated to its role. Permissions may allow a read technically while the business use remains unauthorized. The investigation needs both the access result and the intended purpose.

## Correlate both sides carefully

Client and file-server logs can provide complementary views. Their clocks, identity formats, and event semantics may differ. [[log-correlation]] helps join the records without assuming that a shared address or similar username proves the connection.

A successful authentication to the server does not establish that every file on the share was read. Conversely, limited file auditing can prevent a complete list of accessed objects. State the scope supported by the available events and identify the gaps.

[[data-from-local-system]] covers material already on the endpoint. [[automated-collection]] can explain repeated gathering across shares, while [[data-staged]] describes any later aggregation.

## Restrict the relevant path

Containment may involve the workstation, account, share permissions, or a specific access route. Coordinate with the file-service owner because broad share shutdown can disrupt many users. Preserve relevant server and client records before retention or cleanup removes them.

For practice, compare an approved departmental migration with unexplained cross-department reads by a dormant account. Identify the records establishing the actor, target, result, and business explanation. Write separate conclusions for authentication, file access, and confirmed copying. [[incident-response]] manages the coordinated actions, and [[incident-reporting]] keeps the resulting impact statement within the evidence.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]