Event ID 5145: A network share object was checked to see whether client can be granted desired access

Event 5145 comes from the Detailed File Share subcategory, and its title describes it exactly: a network share object was checked to see whether the client can be granted the access it asked for. The object is a single file or folder, so each path a client opens through a share produces its own record, carrying the rights it requested and the verdict the share gave. Where 5140 marks the session, 5145 is the per-path detail.

Start with the limit, because it decides how to read every record. Failure events are generated only when access is denied at the share level. If the share permission says yes and the NTFS permission says no, no 5145 failure is written. A 5145 success therefore means the share let the request through, not that the file was opened, and the file system's final answer lives in 4663. That event comes from the file system and carries no client address; Microsoft calls out the missing IP address as the difference between the two.

RelativeTargetName is the field that makes this event worth collecting. It holds the path of the file or folder relative to the share, or a lone backslash when the client asked for the share itself. Join it to ShareLocalPath, the NTFS path behind the share in the form \??\PATH, and you have the location on disk: PSEXESVC.exe under \\*\ADMIN$ with a local path of C:\Windows is a file landing in the Windows directory. On IPC$ the local path is empty and RelativeTargetName holds the name of the named pipe being opened. svcctl is the service control pipe used by remote service creation, and srvsvc is the pipe behind share and session enumeration, which is why sweeps across IPC$ line up with network share discovery (T1135). Both are normal for administration tools, so read them as context for the source and the account rather than as alerts.

AccessMask is the sum of the rights requested for that one object, using the same table as 4663: 0x1 ReadData, 0x2 WriteData, 0x4 AppendData, 0x100000 SYNCHRONIZE and so on, and AccessList names them. The sample's 0x100002 is SYNCHRONIZE plus WriteData, shown as %%1541 %%4417. Splitting reads from writes is the most useful cut you can make on this event, because reads are the bulk of the volume and writes are where staging and tampering show up. Microsoft's monitoring guidance names the rights to watch, especially on failures: WriteData (or AddFile), AppendData (or AddSubdirectory or CreatePipeInstance), WriteEA, DeleteChild, WriteAttributes, DELETE, WRITE_DAC and WRITE_OWNER.

The same bit means different things depending on the object, so read the mask together with RelativeTargetName. On a file, 0x2 is WriteData and 0x4 is AppendData. On a folder, 0x2 is AddFile and 0x4 is AddSubdirectory, so a folder path with 0x2 is a request to create a file inside it. On a named pipe, 0x4 is CreatePipeInstance. Further up the table, 0x10000 is DELETE, 0x40000 is WRITE_DAC, the right to change the object's permissions, and 0x80000 is WRITE_OWNER, the right to change the owner.

AccessReason is the access check result, and most guides skip it. For each requested right it records whether access was granted or denied and the SDDL of the access control entry that decided. In the form D:(A;;FA;;;BA), A means allow, FA is file all access and BA is built-in administrators. Microsoft's own sample shows D:(A;;FA;;;WD), which is Everyone with full access, and finding an entry like that behind a share you thought was restricted is a free audit finding. On a failure, the same field tells you which entry refused the request.

The sample on this page is the write pattern defenders hunt. Account adm.lopez writes PSEXESVC.exe into \\*\ADMIN$ from 198.51.100.42 with a write right, and the share's local path points at C:\Windows. That is how PsExec-style tools stage their service binary. MITRE describes the technique as using valid accounts to reach a remote share over SMB, transfer files and run binaries, with Service Execution, Scheduled Task and WMI as the usual follow-ups, and notes that NTLM hashes can open administrator shares through Pass the Hash. The write is only the first step: look for a 7045 or 4697 service installation on the target within seconds, then a 4688 for whatever the service launched.

Per-object logging has a price. Shares have no system access control lists, so enabling the subcategory audits every file and folder check on every share of the machine. Microsoft's guidance follows from that: Failure only on domain controllers, where Group Policy clients read SYSVOL constantly, and Success on member servers only if you need to track every access. Pick hosts by value: file servers that hold regulated data, jump servers and machines only a known set of administrators should touch justify Success auditing with short hot retention. Everywhere else, Failure auditing alone is cheap and still records share-level denials, which is what network share discovery looks like when it half works.

Most 5145 records on a file server are users opening documents with read rights, so baseline the object and the rights, not just the connection: which accounts read which folders under each ShareName, and who normally holds write rights there. Domain controllers add the SYSVOL and NETLOGON reads of every machine applying Group Policy, and backup, antivirus and indexing services read everything. Exclude those by source address or account before setting any threshold, or every count fires for the wrong reasons.

The detections that hold up are keyed on the path and the rights. The first is a write right on ADMIN$ or C$ with a RelativeTargetName ending in .exe, .dll or a script extension, especially from a workstation address, because administrators who push software normally do it from a management host. The second is bulk reading: one source collecting hundreds of distinct files from a share in minutes, which maps to data from a network shared drive (T1039). Count distinct RelativeTargetName values per source rather than raw events, so repeated checks on one file do not inflate the number. The third is an account opening paths on a sensitive share it is not listed for; Microsoft suggests watching specific ShareName and RelativeTargetName values for critical folders, in both Success and Failure, and flagging accounts that reach files outside their allowed list. The fourth is a failure on a destructive or permission-changing right, such as DELETE, WRITE_DAC or WRITE_OWNER, which Microsoft lists among the rights to watch on failures. When you compare IpAddress with your internal ranges, strip the ::ffff: prefix first.

For the PsExec-style chain, correlate on the target host and the file name. The 5145 write of an executable to ADMIN$, a 7045 or 4697 service installation, and a 4688 for the launched process sit seconds apart, and in this pattern the file written through the share is the binary the new service starts. That chain on one host inside a minute is far more convincing than any single event in it, and it is the pattern worth turning into a correlation rule.

Triage starts from the object. Read RelativeTargetName and AccessList to see what was touched and with which rights, then AccessReason for the entry that allowed it. SubjectLogonId groups every check made in the same session, so pull them all in time order to see what else the session touched; it also leads to the 4624 network logon when you need the authentication details. On the target, check whether the file is still there and whether service, scheduled task or WMI activity followed. The share log never names a process, so the source machine is where you find out what opened the connection.

Keep the limit in mind before closing a case. A 5145 success does not prove the file was read or written, only that the share level allowed the check, and silence after an NTFS deny proves nothing.