Mail store file opened over an SMB share

Siemphony@siemphonylowT1114unverified

Matches Detailed File Share auditing where the object opened on a share is an Outlook mail-store container (.pst, .ost, .nst) or a Mac Outlook archive (.olm). This is the one leg of AN1309 that no child of this technique owns: the analytic's forwarding-rule and Exchange-cmdlet half is T1114.003's AN1589, its scripted remote-mailbox half is T1114.002's AN0131, and the host-side command-line view of a local mail store is already published in this corpus as T1114.001 — but 5145 appears in no child brief, and it is the only source here that sees a mail archive being read across the network by a named account and source address. The rest of AN1309 correlates rule creation with outbound SMTP inside a TimeWindow, which is a join Sigma cannot express, so only this single-event step is authored. Two limits worth stating: 5145 is written when the server checks what access to grant for the requested object, so it records an attempt and the rights asked for, not a confirmed read of the bytes; and a mail store copied from a local disk or from a mapped drive on the same host never produces one. Requires the Audit Detailed File Share subcategory, which is off in a default install and in the Microsoft and CIS baselines, and which is among the highest-volume audit subcategories in Windows — no matches here means the feed is off far more often than it means nothing happened. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0476, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

SecurityEvent| where (EventID == 5145 and (RelativeTargetName endswith ".pst" or RelativeTargetName endswith ".ost" or RelativeTargetName endswith ".nst" or RelativeTargetName endswith ".olm"))

Splunk · SPL

Run this as a search.

index=* (EventID="5145" AND (RelativeTargetName="*.pst" OR RelativeTargetName="*.ost" OR RelativeTargetName="*.nst" OR RelativeTargetName="*.olm"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 5145 AND (TO_LOWER(RelativeTargetName) LIKE "*.pst" OR TO_LOWER(RelativeTargetName) LIKE "*.ost" OR TO_LOWER(RelativeTargetName) LIKE "*.nst" OR TO_LOWER(RelativeTargetName) LIKE "*.olm"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^5145$</field>    <field name="RelativeTargetName" type="pcre2">(?i)(\.pst$|\.ost$|\.nst$|\.olm$)</field>    <description>Mail store file opened over an SMB share</description>    <mitre>      <id>T1114</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: low
Category: data_staging_exfil
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: d3e067d5-685d-40e4-a3f8-8c3d0f8cebb8

ATT&CKT1114

T1114Email Collection

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondata staging exfil

data staging exfilAI draft — unreviewed

01 · What this rule detects

AN1309 describes a correlation — a forwarding rule created, .pst/.ost files accessed, outbound SMTP to an external server, all inside a time window. Sigma cannot join three event streams, so this rule authors the one leg no child technique already owns: Windows Security EventID 5145, where the object requested on a file share is an Outlook mail store. Say the consequence plainly. A hit is an access check, not a read. 5145 is written when the server decides what rights to grant for a requested object, so it records the attempt and the rights asked for, not the bytes that moved.

02 · Telemetry you need

product: windows / service: security, copied verbatim from AN1309. EventID 5145 belongs to the Audit Detailed File Share subcategory, which is off in a default install and in both the Microsoft and CIS baselines, and which is among the highest-volume audit subcategories Windows has. That combination matters: no matches here means the feed is off far more often than it means nothing happened. All four backends render this logsource.

03 · How the logic works

One selection, two conditions implicitly ANDed: EventID: 5145 and RelativeTargetName|endswith across .pst, .ost, .nst, .olm. RelativeTargetName is the share-relative path of the requested object, which is the only reason extension matching works on this event — the sibling event 5140 names the share and carries no file name at all. MITRE's analytic names ".pst/.ost file access"; .nst (the Outlook group store) and .olm (Mac Outlook archive) are the pipeline's own additions. What the selection leaves out is as important. 5145 also carries AccessMask/AccessList, and the rule ignores both, so a rename, a delete, or a directory walk that merely touched the object produces the same match as a read. That is the single biggest contributor to the volume described below.

04 · Common false positives

Archived PSTs parked on a departmental share and reopened by Outlook at every logon — ordinary in any estate that never finished an online-archive migration. Where that pattern survives it is the dominant volume the rule returns by a wide margin, which is why level is low and why this is a hunting surface rather than an alert.
Behind it: backup, indexing and eDiscovery agents walking shares on a schedule; PST-import and migration projects reading thousands of stores over days; DLP and quota scanners sizing files.
There is also scope drift worth disclosing. A mail store opened over SMB is equally well described by T1039 (Data from Network Shared Drive); nothing in this logic is email tradecraft beyond the file extension.

05 · Detection maturity

tier_1: the lowest tier, and it stays there until the rule has been run against real data. It was authored from a MITRE scaffold containing no query logic and has never been executed against a log line. Reasoning on paper that a `.pst` fetched over SMB would match is analysis, not verification.
tier_2: run read-only for a fortnight, rank hits by account, source address and share, and turn the top of that list into the `UserContext` exclusions and the share scope.
tier_3: ** rebuild AN1309 as MITRE described it — correlate a match here with forwarding-rule creation and external SMTP inside the TimeWindow knob, so an alert means collection rather than a file being opened.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Narrow on AccessMask/AccessList — ReadData, %%4416 — as a second
Populate MITRE's UserContext knob with the estate's own backup, indexing and
Scope to the shares that hold mail stores rather than shortening the extension
Accept two blind spots rather than patching them: a store copied to a neutral

Declared by the author

Archived .pst files parked on a departmental file share and re-opened by Outlook at every logon, which is still ordinary in estates that never finished an online-archive migration. Where that pattern exists it is the dominant volume this rule returns by a wide margin, and the rule is a hunting surface rather than an alert until the population of shares holding mail stores has been baselined.
Backup, content-indexing and eDiscovery agents that walk file shares on a schedule and open every mail store they find, from a small and nameable set of service accounts and source addresses — MITRE's UserContext knob, populated here by the estate's own agent inventory.
Mailbox migration and PST-import projects, where an administrator or migration service account reads thousands of mail stores out of a staging share over a period of days.
Storage-reporting, quota and DLP scanners that open mail-store files to classify or size them, producing a steady per-share rhythm rather than a one-off access.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1114, evaluated against their — events.

Share this rule

/u/siemphony/d3e067d5-685d-40e4-a3f8-8c3d0f8cebb8

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Mail store file opened over an SMB share

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it