Event ID 5145 shows a network share object was checked for access. It is useful for spotting share-level access attempts, file browsing, and possible lateral movement on SMB shares. Review the share name, relative target name, source address, and requested access, and remember it records share-level checks rather than NTFS permission outcomes.
What makes Event ID 5145 operationally useful
event id 5145 is valuable because it gives security teams visibility into a share-level access check before file content is actually opened or modified. That makes it useful for spotting reconnaissance against SMB shares, unusual browsing of administrative or sensitive shares, and early movement patterns that may not show up in file-change telemetry alone.
The event is most useful when you treat it as an access-intent signal, not as proof that a file was read or changed. In practice, that means correlating it with the source address, the share name, and the requested access mask so you can distinguish routine application activity from suspicious enumeration or repeated probing of the same share.
Teams that already centralise Windows telemetry usually get the most value when 5145 is handled as part of a broader log source strategy. A good starting point is Windows Event Log Guide, which helps place 5145 alongside other logon, share, and object-access events that provide the surrounding context.
How to interpret 5145 without overreading it
5145 records a check against a network share object, so the event tells you what was requested and from where, but not whether NTFS permissions ultimately allowed access to the underlying file. That distinction matters because security teams often mistake share-level telemetry for full file-access evidence and end up drawing the wrong conclusion about exposure or impact.
The most practical fields are the share name, relative target name, source address, and requested access. Together, they tell you whether the activity was a normal path traversal, a targeted probe of a known share, or a broader scan across multiple shares from the same host. In incident response, that pattern helps separate a legitimate admin workflow from lateral movement staging.
For investigations that need broader host-level context, Sysmon Guide helps because share access often becomes more meaningful when paired with process creation, network connection, and parent-child process evidence on the source system.
What security teams should do with 5145 alerts
Use 5145 as a triage signal when the same source starts touching many shares, when the requested access is broader than the business process usually needs, or when the target share is administrative, finance-related, or otherwise sensitive. A single event is often harmless; repeated checks across several hosts or shares are what usually make the activity worth investigation.
Good handling also depends on whether the access pattern fits the user, service, or workstation that generated it. If the source is a server, backup job, or management host, you may be looking at expected automation. If the source is an endpoint that does not normally browse SMB shares, the same event can indicate discovery activity, stolen credentials being tested, or hands-on-keyboard movement.
When you need to understand whether the broader telemetry pipeline is tuned to keep these signals visible, SIEM Guide is the natural companion because 5145 is only useful if it is collected, retained, and correlated with adjacent log sources.
Risk and Threat Considerations
Share-level access checks can expose early adversary activity because SMB is often used for discovery, staging, and lateral movement after initial foothold. The risk is not the event itself, but the pattern it reveals when an actor is probing shares to find writable locations, accessible data, or paths into higher-value systems.
Failure mechanism: Attackers can use repeated share checks to enumerate accessible SMB resources, validate stolen credentials, and identify a target where later file access, script execution, or payload staging will succeed without immediately triggering a permission failure.
Impact: If teams ignore the pattern, they may miss reconnaissance that precedes lateral movement, data staging, or abuse of administrative shares, especially when the activity looks like ordinary file browsing at the share layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021.002 — Remote Services: SMB/Windows Admin Shares | SMB share probing and lateral movement map directly to remote service abuse. |
| Recommendation — Hunt for SMB share enumeration and lateral movement indicators around T1021.002. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | 5145 is a network-service monitoring signal for suspicious share access patterns. |
| Recommendation — Include 5145 in network monitoring to detect anomalous SMB share activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Security teams must review event patterns to distinguish normal share checks from abuse. |
| AC-6 — Least Privilege | Abusive share access often becomes visible when permissions exceed job needs. | |
| Recommendation — Correlate 5145 with adjacent logs under AU-6 to identify suspicious access patterns. Restrict share permissions to the minimum access needed for each role. | ||
| CIS Controls v8 | CIS-5 — Account Management | Share access checks are only meaningful when tied to expected account use and role. |
| Recommendation — Review account usage against role expectations to spot abnormal share access. | ||
Practitioner Guidance
What to verify: Confirm whether the source address, account context, and requested access match the expected application, admin workflow, or workstation role. If the event comes from an unusual host or the access mask is broader than normal, treat it as investigative rather than routine.
What to prioritise: Look for bursts of 5145 events across multiple shares, repeated checks on administrative shares, and any pairing with authentication, logon, or process activity that suggests an operator is mapping the environment rather than merely opening a file.
Practitioner takeaway: 5145 is most valuable when you treat it as a reconnaissance and lateral-movement signal, then validate it against source context and surrounding telemetry before deciding whether it reflects normal browsing or active abuse.