What happens from start to finish when a user accesses a file share?

1. Core mechanism

The client application and Windows SMB client operate between the SMB service and resource manager on the file server. This lesson separates discovery, the SMB session, the share connection, and the file-open decision; Kerberos message detail belongs in 06.x, and DACL evaluation in 05.03–05.04.

Interfaces and specifications

• UNC name: \server\share\path identifies the target server, share, and relative path.
• MS-SMB2: NEGOTIATE establishes connection capabilities; SESSION_SETUP establishes the user security context; TREE_CONNECT establishes share context; CREATE requests that a file or directory be opened.
• SSPI: during SESSION_SETUP, SMB uses Kerberos or another suitable Windows authentication package; Kerberos is not the only option.
• CREATE request: the target object and requested access mask become inputs to the file-server resource decision.
• Windows Security Event 5145 records the subject, share, relative target, and audited access fields on the resource host.

Finding a path is not granting access

When an application requests \FS01\Finance\reports\summary.txt, the first step is to determine which address and current connection state correspond to FS01. This stage only resolves how to reach the target.

After connecting to the server, the SMB client selects common protocol features with NEGOTIATE. Completing negotiation does not show that the user identity was verified or that the Finance share can be opened.

Each stage supplies input to the next, but success at an earlier stage does not predetermine the next decision.

The session and share are separate contexts

SESSION_SETUP uses the selected authentication package through SSPI and establishes an SMB session security context representing the client on the server. Depending on the environment and conditions, a supported package other than Kerberos may be used.

TREE_CONNECT binds the session to a specific share. Authentication to the server does not mean that every share connection will be accepted.

This distinction is important in the event review: the ticket operation on the domain controller does not replace the session and share request on FS01.

The file decision is made at CREATE

The client carries the target and requested rights in the CREATE message. CREATE does not mean only “make a new file”; it also requests that an existing file or directory be opened.

The server evaluates the client token or security context against share and file-system security definitions. Authentication supplies a principal for that evaluation; it does not guarantee the result.

A reliable evidence chain records the user or session, share, relative target, requested right, and host that made the decision separately.

State and data flow

1. The application requests a UNC path; the client resolves the target server and selects a connection.
2. The client and FS01 negotiate the SMB version and connection capabilities with NEGOTIATE messages.
3. SESSION_SETUP authenticates through SSPI and establishes a session security context on FS01.
4. TREE_CONNECT binds that session to the Finance share.
5. CREATE carries the requested access mask for reports\summary.txt.
6. FS01 evaluates the security context against share and file-system permissions.
7. The allowed operation proceeds; evidence for a rejected stage is sought at that stage’s observation point.

2. Exploitation

Broken trust assumption

Broken assumption: the party using valid identity material is necessarily the account owner, and successful authentication is sufficient to access the target file.

Technical prerequisites

• Available account, ticket or existing session material.
• Access to the file server and the target share is available.
• The represented principal has at least one relevant share and file right on the target.

Exploitation mechanism

An attacker uses the legitimate SMB flow to establish a session as the represented principal and requests listing, reading, or writing within that principal’s existing rights. The mechanism does not bypass the DACL: an incorrect target, unusable credential, closed network path, or insufficient right stops the operation.

A valid session does not upgrade authorization

Acceptance of SESSION_SETUP shows only that the server established a security context. The target resource still makes the subsequent share and file decisions.

The effect of a captured secret is limited to the rights the account actually has. A credential does not automatically open every share and file.

The attack boundary for this lesson

This lesson does not describe credential extraction, relay, or ticket-forging steps. Its purpose is to show which trust assumption normal access flow carries when identity material is available.

To measure impact, record the resource host, share, target path, and requested right along with the principal name.

3. Defense & Detection

Telemetry scope

• Enable the Audit Detailed File Share subcategory for Success and/or Failure on the resource file server.
• A share SACL is not required for 5145, but measure scope and storage before enabling collection because event volume can be high.
• 5145 Failure indicates a denial at the share level; the same failure record may not be generated for an NTFS-level denial.
• Domain-controller ticket events support the ticket process; they do not by themselves prove that a file was opened.

Events and relevant fields

• 5145 / SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId: security context that made the request.
• 5145 / IpAddress, IpPort: the client network context.
• 5145 / ShareName, ShareLocalPath, RelativeTargetName: the share and relative target on the resource.
• 5145 / AccessMask, AccessList, AccessReason: requested rights and the decision reason reported by Windows.
• 5145 / Version 0: the documented schema applies at least to Windows Vista and Windows Server 2008.

What question does 5145 answer?

Event 5145 shows which subject requested access to which share and relative target on the resource host. It is therefore a more direct observation point for the file target than a ticket record on the DC.

The evidence boundary still matters: a final NTFS decision is not the same as a share-level event.

Strengthening the correlation evidence

With 4624 on the same resource host, SubjectLogonId can be compared using client address and time. Account for collection delay and field normalization when assessing the match.

Ticket, session, and object-request evidence may come from different hosts. The absence of one event does not automatically disprove success at another stage.

Detection logic · Sigma

title: Hassas SMB hedefinde ayrintili dosya paylasimi istegi
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    ShareName|endswith: '\\Finance'
  condition: selection
fields:
  - SubjectUserName
  - SubjectDomainName
  - SubjectLogonId
  - IpAddress
  - ShareName
  - RelativeTargetName
  - AccessMask
  - AccessReason
falsepositives:
  - Yetkili kullanici ve uygulamalarin normal dosya islemleri
level: low

Query assumptions

• The field names are Windows EventData/Data[@Name] names; map them if the target backend normalizes fields.
• The rule selects candidate events only; it does not by itself establish success, an NTFS result, or file content access.
• Collectors may store ShareName with different escaping or normalization.
• The rule was not run against a real SIEM or dataset.

False positives

• Normal file access by authorized users and applications.
• Backup, software-distribution, antivirus-scanning, and indexing processes.
• High event volume is expected on busy shares such as SYSVOL.

Hardening

• Manage share and NTFS permissions with least privilege and remove unnecessary shares.
• Enable Success auditing for critical paths, then introduce Failure auditing gradually for broader coverage.
• Document the current workflow and rollback path before a change, then verify the resource-host telemetry for the access result.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" />
    <EventID>5145</EventID>
    <Version>0</Version>
    <Channel>Security</Channel>
    <Computer>FILE01.besiktas.example</Computer>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-21-111111111-222222222-333333333-1104</Data>
    <Data Name="SubjectUserName">kayra</Data>
    <Data Name="SubjectDomainName">BESIKTAS</Data>
    <Data Name="SubjectLogonId">0x123</Data>
    <Data Name="ObjectType">File</Data>
    <Data Name="IpAddress">192.0.2.10</Data>
    <Data Name="IpPort">50123</Data>
    <Data Name="ShareName">\\*\Finance</Data>
    <Data Name="ShareLocalPath">\??\D:\Shares\Finance</Data>
    <Data Name="RelativeTargetName">reports\summary.txt</Data>
    <Data Name="AccessMask">0x1</Data>
  </EventData>
</Event>

Two reality checks

Assumption: If a Kerberos service ticket was issued, access to the file was granted.

In fact: A service ticket supports authentication to the target service. After the SMB session is established, the resource host evaluates share and file rights; the ticket alone is not evidence of that decision.

Assumption: If no 5145 Failure is visible, all file access succeeded.

In fact: 5145 Failure indicates a share-level denial. Under Microsoft’s documented boundary, an NTFS-level denial may not produce 5145 Failure; verify the result with other resource-host evidence.

Sources

• Microsoft Open Specifications · [MS-SMB2]: Server Message Block (SMB) Protocol Versions 2 and 3
  Protocol Details: NEGOTIATE, SESSION_SETUP, TREE_CONNECT, and CREATE messages.
• Microsoft · Kerberos authentication overview
  “How Kerberos authentication works”: the client presents its service ticket to the target service.
• Microsoft · How DACLs control access to an object
  The relationship between access-token SIDs and requested access when evaluating DACLs and ACEs.
• Microsoft · 5145(S, F) A network share object was checked to see whether client can be granted desired access
  Event XML, event versions, field descriptions, and the Important note on the NTFS Failure boundary.
• Microsoft · Audit Detailed File Share
  Description, event volume, SACL requirement, and Events List.