DC0102: Network Share Access
Opening a network share, which makes the contents available to the requestor (ex: Windows EID 5140 or 5145)
Analyst context for executives and security teams
Network Share Access is evidence that a user, service, or system opened a shared network resource and made its contents available to the requestor. For leaders, this matters because shared storage often contains operational files, sensitive data, scripts, backups, or administrative tooling. Even without a mapped ATT&CK technique in the supplied context, this data component can be important evidence for determining whether access to shared resources was expected, excessive, or relevant during an investigation.
Executive priority
Prioritize this as an audit and incident-response evidence source rather than a standalone risk indicator. Security leaders should ask whether critical shares are identified, whether access to them is logged, whether logs are retained long enough for investigations, and whether SOC teams can distinguish routine business access from unusual access to sensitive shared resources.
Technical view
SOC and IR teams should validate whether network share access events are collected and searchable. The official description gives Windows Event ID 5140 or 5145 as examples, so environments using those logs should confirm audit policy, event forwarding, parsing, retention, and correlation with user, host, share path, and access outcome. Because no tactics, platforms, relationships, or ATT&CK detection guidance are supplied, detection logic should be environment-specific and based on known sensitive shares, expected access patterns, and investigation requirements.
Likely telemetry
- Network share access/open events
- Windows security events such as EID 5140 or 5145 where applicable
- User or service account identity associated with the share request
- Source host or network address of the requestor
- Share name, path, and resource accessed
Detection direction
- Validate that share access logging is enabled for important shared resources and actually reaches the SIEM or log platform.
- Baseline normal access to sensitive shares by user, service account, host, and business function before alerting broadly.
- Tune for high-value scenarios such as first-time access to sensitive shares, unusual source systems, unusual service account use, or access outside expected operating patterns.
- Account for false positives from backup jobs, software deployment, administrative activity, file indexing, and routine business processes.
- Use this data component as corroborating evidence in investigations rather than treating every share-open event as malicious.
Mitigation priorities
- Identify and classify critical or sensitive network shares before building monitoring priorities.
- Apply least-privilege access controls and review membership or permissions for sensitive shared resources.
- Enable and retain share access auditing for resources that matter to compliance, incident response, and operational resilience.
- Ensure SOC playbooks include how to interpret share access events, including expected administrative and service-account activity.
- Periodically test whether representative share access events are generated, collected, searchable, and tied to identity and host context.
Analyst notes and limits
The supplied ATT&CK object is a data component, not a technique, and no relationship context is provided. Its value is mainly evidentiary: it helps defenders prove who accessed which shared resource and when. The only concrete event examples supplied are Windows EID 5140 and 5145, so any broader implementation should be validated against local logging sources and platforms.
No official detection text, tactics, platforms, or related techniques were supplied. This take therefore avoids claims about specific adversary behavior, active exploitation, attribution, impact, or guaranteed detection coverage. Local architecture, audit policy, share sensitivity, and log retention determine practical usefulness.
Network Share Access
Opening a network share, which makes the contents available to the requestor (ex: Windows EID 5140 or 5145)
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 56b87a4d53a1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0102Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.