Document or archive accessed inside a hidden administrative share

Siemphony@siemphonymediumT1039unverified

Covers the share-access leg of AN1145 on the only field set that carries it: Security EventID 5145 records the share, the file within the share and the account that asked for it, so a request for a document, mailbox archive or compressed container inside a hidden administrative share is visible as one event. The share list is MITRE's ShareName knob populated here with the default hidden shares, and the file list stands in for "files of interest", which the analytic describes but does not enumerate. Two things the analytic asks for are not available: 5145 is written by the server hosting the share, so the local process that did the reading is nowhere in the event and the ProcessName knob cannot be applied, and 5145 does not distinguish a read from a write in any form that survives normalisation consistently — a site whose collector preserves the raw `AccessList` codes can add ReadData to tighten this, but the rule does not depend on it. The Sysmon EventID 11 leg of the same analytic is not authored here: file creation records the local destination of a copy, not the network source, so it cannot express reading from a share at all. Requires the *Audit Detailed File Share* subcategory, which is off in a clean install and in the Microsoft and CIS baselines, so an empty result means blind rather than quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0410, 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 (ShareName endswith "\\C$" or ShareName endswith "\\ADMIN$" or ShareName endswith "\\D$" or ShareName endswith "\\E$")) and (RelativeTargetName endswith ".doc" or RelativeTargetName endswith ".docx" or RelativeTargetName endswith ".xls" or RelativeTargetName endswith ".xlsx" or RelativeTargetName endswith ".ppt" or RelativeTargetName endswith ".pptx" or RelativeTargetName endswith ".pdf" or RelativeTargetName endswith ".zip" or RelativeTargetName endswith ".7z" or RelativeTargetName endswith ".rar" or RelativeTargetName endswith ".pst" or RelativeTargetName endswith ".ost" or RelativeTargetName endswith ".kdbx"))

Splunk · SPL

Run this as a search.

index=* ((EventID="5145" AND (ShareName="*\\C$" OR ShareName="*\\ADMIN$" OR ShareName="*\\D$" OR ShareName="*\\E$")) AND (RelativeTargetName="*.doc" OR RelativeTargetName="*.docx" OR RelativeTargetName="*.xls" OR RelativeTargetName="*.xlsx" OR RelativeTargetName="*.ppt" OR RelativeTargetName="*.pptx" OR RelativeTargetName="*.pdf" OR RelativeTargetName="*.zip" OR RelativeTargetName="*.7z" OR RelativeTargetName="*.rar" OR RelativeTargetName="*.pst" OR RelativeTargetName="*.ost" OR RelativeTargetName="*.kdbx"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 5145 AND (TO_LOWER(ShareName) LIKE "*\\\\c$" OR TO_LOWER(ShareName) LIKE "*\\\\admin$" OR TO_LOWER(ShareName) LIKE "*\\\\d$" OR TO_LOWER(ShareName) LIKE "*\\\\e$")) AND (TO_LOWER(RelativeTargetName) LIKE "*.doc" OR TO_LOWER(RelativeTargetName) LIKE "*.docx" OR TO_LOWER(RelativeTargetName) LIKE "*.xls" OR TO_LOWER(RelativeTargetName) LIKE "*.xlsx" OR TO_LOWER(RelativeTargetName) LIKE "*.ppt" OR TO_LOWER(RelativeTargetName) LIKE "*.pptx" OR TO_LOWER(RelativeTargetName) LIKE "*.pdf" OR TO_LOWER(RelativeTargetName) LIKE "*.zip" OR TO_LOWER(RelativeTargetName) LIKE "*.7z" OR TO_LOWER(RelativeTargetName) LIKE "*.rar" OR TO_LOWER(RelativeTargetName) LIKE "*.pst" OR TO_LOWER(RelativeTargetName) LIKE "*.ost" OR TO_LOWER(RelativeTargetName) LIKE "*.kdbx"))

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="7">    <!-- 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="ShareName" type="pcre2">(?i)(\\C\$$|\\ADMIN\$$|\\D\$$|\\E\$$)</field>    <field name="RelativeTargetName" type="pcre2">(?i)(\.doc$|\.docx$|\.xls$|\.xlsx$|\.ppt$|\.pptx$|\.pdf$|\.zip$|\.7z$|\.rar$|\.pst$|\.ost$|\.kdbx$)</field>    <description>Document or archive accessed inside a hidden administrative share</description>    <mitre>      <id>T1039</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: data_staging_exfil
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 70962fc6-a0aa-4dc3-8c3a-4ff249302a1e

ATT&CKT1039

T1039Data from Network Shared Drive

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

AN1145 watches file access on a network share followed by unusual read or copy activity. Security EventID 5145 is the one record carrying a share, a file inside it and the requesting account together, so the rule implements the share-access leg on 5145 and nothing else. What it selects is narrower than the technique: a document, archive or mailbox file requested inside a hidden administrative share. Say that plainly — this is admin-share coverage. The ordinary T1039 case, a compromised host mining \\fs01\Finance\budget.xlsx, produces a 5145 whose ShareName ends in \Finance and never matches.

02 · Telemetry you need

product: windows / service: security, verbatim from the brief. 5145 comes from the Audit Detailed File Share subcategory, which is off in a clean install and off in both the Microsoft and CIS baselines. An empty result means the subcategory is not enabled, not that nobody read anything.
The event is written by the server hosting the share, so the process doing the reading is not in it. MITRE's ProcessName knob — the "PowerShell, certutil" half of the analytic — has no field here and cannot be applied at all. TimeWindow needs a correlation engine. Only ShareName survives. The Sysmon EventID 11 leg is not authored either: file creation records where a copy landed locally, not that it came off a share.

03 · How the logic works

Two selections, ANDed. selection_share pins EventID: 5145 and gates ShareName|endswith on \C$, \ADMIN$, \D$ and \E$. That is MITRE's ShareName knob populated with the default hidden shares — MITRE names the knob and says explicitly that organisations use custom paths; the four values are the pipeline's. selection_files is a RelativeTargetName|endswith list standing in for the analytic's unenumerated "files of interest": Office documents, .pdf, the archive formats an operator stages into (.zip, .7z, .rar), mail stores (.pst, .ost) and .kdbx. Two structural limits. 5145 is an access check, not a read, and no AccessList gate is applied — so a .7z toolkit written into \\host\C$ matches exactly like one read out of it, and that inbound case is lateral tool transfer reported here as collection. And .pst/.ost duplicate the corpus's T1114 rule on the same feed, so a mailbox read from an admin share alerts twice.

04 · Common false positives

Helpdesk and migration work dominates, and the rule's own first entry says so: pulling a user's documents or .pst off a workstation over \\host\C$ before a rebuild is the same account, share and file types as staged collection, and 5145 carries nothing that separates them.
Behind it: remote-collector backup, DLP and eDiscovery products walking administrative shares on a schedule; credentialed vulnerability scanners touching archives incidentally; administrators pulling a .zip log bundle off a C$.
Three of four entries are estate-wide scheduled scanners. level: medium is one step hotter than that supports — the corpus sibling on this feed sits at low.

05 · Detection maturity

tier_1: . Machine-derived from a MITRE strategy carrying prose and log sources but no query logic, and never executed against a log line. Nothing here has been measured — the claim that helpdesk traffic dominates is reasoning, not a count.
tier_2: run read-only, rank by `SubjectUserName` and source host, convert the top of that list into exclusions, and let the observed volume decide whether `medium` or `low` is right.
tier_3: ** correlate share reads with an egress event from the same host inside a window, so the alert means collection followed by movement 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

Add your own named data shares to ShareName before treating this as T1039
Filter SubjectUserName|endswith: '$' to drop machine-account backup, DFSR and
If your collector preserves raw AccessList codes, add %%4416 (ReadData) to
Drop .pst/.ost and let T1114 own them, or keep the overlap deliberately and
Baseline by source host: helpdesk and backup subnets are exclusions, not

Declared by the author

Helpdesk and migration work. Pulling a user's documents or an Outlook .pst off a workstation through \host\C$ before a rebuild or a hardware refresh is the same account reaching the same share for the same file types as an operator staging collection, and nothing in 5145 separates them. In most estates this is the largest benign source.
Backup, DLP and eDiscovery products whose collectors run remotely rather than as a local agent, which read documents and mailbox archives over administrative shares on a schedule and fan out across many hosts in a short window.
Credentialed inventory and vulnerability scanning that walks the filesystem over C$, which touches archives and documents incidentally while it is looking for software versions and unpatched components.
Administrators retrieving log bundles or exported configuration that happen to be .zip or .7z from a remote server's C$ during ordinary troubleshooting.

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 T1039, evaluated against their — events.

Share this rule

/u/siemphony/70962fc6-a0aa-4dc3-8c3a-4ff249302a1e

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.

Document or archive accessed inside a hidden administrative share

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it