Data from Network Shared Drive

Once an attacker has valid access to a network, one of the richest sources of data isn't a single compromised workstation, it's whatever file shares that access happens to reach. A shared drive built for legitimate collaboration, holding years of business documents, is just as visible to an attacker with the right credentials as it is to the employees it was built for.

This technique is about reading and pulling data from those shares directly, not about scanning to find out they exist. Discovery answers "what's out there"; this is the actual collection step that follows it.

With a working set of credentials, an attacker connects to a share exactly the way a legitimate user would, there's no exploit involved, since the access itself is often completely valid. What makes it malicious is the pattern: rather than opening the handful of files a normal workday would touch, the attacker systematically reads through folders, often far more broadly and quickly than any single employee's actual job would require.

The access itself frequently generates no alert on its own, since file shares are read constantly for entirely ordinary reasons. The signal is in the shape of the activity, not any single read.

Data source: the file server's Windows Security event log (Event 5145, Detailed File Share), scoped per account and filtered on the access mask to keep only real data reads

{
  "host": {
    "name": "fileserver"
  },
  "event": {
    "code": "5145",
    "action": "Detailed File Share"
  },
  "winlog": {
    "event_data": {
      "IpAddress": "10.0.30.101",
      "ShareName": "\\\\*\\TeamShare",
      "AccessMask": "0x120089",
      "SubjectUserName": "j.doe",
      "RelativeTargetName": "Facilities\\handbook.docx"
    }
  }
}

Prebuilt Elastic rule: No dedicated prebuilt rule (detection relies on file-access audit correlation)

Hunt this as a volume-and-breadth problem, the same way network scanning is: no single file read looks malicious, but an account touching an unusual number of files, folders, or file types in a short window does. Filter file-access events on the share by user.name and count distinct files touched in a rolling window, then look at outliers against that account's own normal baseline, not a platform-wide average, since normal access volume varies enormously by role. Filter the access mask to genuine reads (0x120089) and leave out the enumeration masks (0x100081, 0x80) that a directory listing produces, or browsing inflates it; and look in the file server's Security log, since Sysmon has no file-read event.

Correlating with how the account authenticated matters too: access immediately following an unusual login (a new source host, an odd time of day) is a stronger signal than the same volume of access from the account's usual daily pattern.

Legitimate bulk file access happens constantly: a new employee's onboarding sync, a backup job, a migration, an audit or e-discovery process, or simply someone reorganizing a folder structure they own. All of these can look identical to collection at the level of "many files read quickly."

The distinguishing signal is whether the account and the activity match an expected, known process. A scheduled backup service account behaving exactly as scheduled reads very differently from a human user account suddenly reading far outside its normal pattern, especially on a share unrelated to that person's actual role.

• MITRE ATT&CK T1039: Data from Network Shared Drive

1 scenario in this catalog covers T1039. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →