When is Event ID 5140 logged?

What Event ID 5140 tells you about share access

Event ID 5140 is a share-access signal, not a file-open signal. The useful detail is that it marks the first network share access in a session, so it helps you see who reached a share and from where, even when the underlying file activity is spread across multiple subsequent operations. It is most valuable for sensitive shares, administrative shares, and access investigations.

Because it fires once per session at first access, 5140 is best treated as a session marker you correlate with other logons and file-access events. That makes it useful for building a timeline: which account established access, which host originated it, and which share was touched before more specific activity appears elsewhere in the logs. If you want the broader Windows logging context around share access, the Windows Event Log Guide covers where 5140 fits among the other audit events that usually matter in an investigation.

Enable Audit File Share where you need this visibility, but remember that the event itself records access to the share object, not every file action inside it. If investigators need finer detail, pair it with file and process telemetry so you can tell whether the share was simply enumerated, browsed, or used as the entry point for a larger activity chain. For endpoint-side corroboration, the Sysmon Guide is useful for deciding what additional telemetry should accompany Windows Security logs.

How to use 5140 in an investigation

The practical value of 5140 is in correlation. The share name tells you what was reached, the source address tells you where the access came from, and the account name tells you who was involved. That combination is enough to distinguish routine business use from unexpected access paths, especially when a sensitive share should only be reachable by a small set of systems or users.

In a real review, start by grouping 5140s by share name and source address, then compare the account to expected access patterns. A single event may be benign, but repeated first-access events from unusual hosts, service accounts, or remote admin workstations can indicate discovery, lateral movement, or an automated job touching a share that was not supposed to be in scope. If the share is used for scripts, tooling, or remote administration, the source account context becomes just as important as the destination share.

5140 also helps answer a common question during triage: was the sensitive share reached by an interactive user, by a service process, or by a remote management workflow? That distinction matters because the same share can be used legitimately in one context and suspiciously in another. If you need to understand the PowerShell or remote-management side of that distinction, the PowerShell Security Guide is a useful companion when script-based access is part of the path.

What to check when 5140 appears on sensitive shares

The first check is whether the share should have been reachable at all from that source. The second is whether the account had a legitimate reason to use that share at that time. The third is whether the access pattern aligns with normal user or workload behaviour. Those three checks usually tell you whether 5140 is routine inventory noise or a meaningful access event worth escalating.

When 5140 appears alongside suspicious activity, treat it as a starting point for blast-radius assessment. A shared folder often contains scripts, staging files, configuration material, or operational data, so one share access can expose more than the log line suggests. If the access path looks unusual, review nearby authentication events, privilege changes, and subsequent file or process events to understand whether the share was merely touched or used as part of a broader compromise path.

For audit and detection design, the best practice is to define which shares should trigger attention before you need the log. High-value shares, administrative shares, and cross-server shares deserve closer monitoring than ordinary user content. That makes 5140 a policy-driven signal, not just a forensic artifact, because its meaning depends on which shares your environment has deliberately marked as sensitive.

Practitioner Guidance

What to verify: Confirm that Audit File Share is enabled on the systems hosting sensitive shares, and verify that your SIEM retains enough context to link the share name, source host, and account name into one investigation trail.

Decision rule: If 5140 shows access from an unexpected host or account, treat it as a privilege and exposure question first, then decide whether the event is normal only after you have checked the share’s business purpose and the account’s intended use.

What practitioners underestimate: 5140 is often dismissed as “just a share log,” but on sensitive shares it can be the earliest reliable signal that a host or account has entered a path to operational data, scripts, or administrative material.

Practitioner takeaway: Use 5140 as a correlation anchor, not a standalone verdict, because the security value comes from pairing first-access share visibility with expected-access baselines and follow-on telemetry.

Related resources from NHI Mgmt Group

• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?
• When is Event ID 4663 logged?