Logon script written to the NETLOGON or SYSVOL share

Siemphony@siemphonymediumT1037.003unverified

AN1034 correlates a Group Policy change that configures a network logon script with the script later executing at logon. Of the two halves, only the change is worth alerting on: the execution half fires for every user at every logon in any domain that uses logon scripts at all, while the domain-wide script files themselves are written only when someone edits them. So this rule takes the brief's Security EventID 5145 leg and matches a detailed file-share access in which the requested access includes write or append, the share is NETLOGON or SYSVOL, and the target file carries a script or executable extension — the act of planting or tampering with the script, on the domain controller that serves it. This is the surface two neighbouring published rules deliberately leave open: T1037.001 suppresses command lines naming these two shares because the ordinary domain logon script would otherwise match at every logon, and the T1080 share-write rule excludes them because tampering there is this technique. The access check is written twice over because collectors disagree on the value: raw event data carries the unresolved message-table codes `%%4417`/`%%4418`, while a collector that resolves message strings writes the same access as `WriteData (or AddFile)` / `AppendData (or AddSubdirectory)`. Confirm which form your pipeline stores before trusting the result. MITRE's `TargetObject` knob — "path to network-based script execution" — is what the share gate implements, populated here with the two default domain script shares; its `ParentProcessName` and `UserContext` knobs belong to the process leg and have no counterpart on 5145. Three limits. 5145 records the access a client requested at the share check, not a completed write. Anything done on the domain controller's own filesystem rather than over the share — an interactive session on the DC, or a service running locally — produces no 5145 at all. And the extension list only sees the file; a payload appended to an existing logon script produces the same record as any other write to it. This rule is written in the native Security 5145 vocabulary (`ShareName`, `RelativeTargetName`, `AccessList`). 5145 requires the *Audit Detailed File Share* subcategory, which is off by default and absent from the Microsoft and CIS baselines — with it off this rule returns zero rows, and zero rows here means blind, not quiet. The brief's third log source, System EventIDs 4016 and 5312, is not used: those are Group Policy processing records emitted on every host at every policy refresh, and they name no script. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0367, 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 "\\NETLOGON" or ShareName endswith "\\SYSVOL") and (AccessList contains "%%4417" or AccessList contains "%%4418" or AccessList contains "WriteData" or AccessList contains "AppendData") and (RelativeTargetName endswith ".bat" or RelativeTargetName endswith ".cmd" or RelativeTargetName endswith ".ps1" or RelativeTargetName endswith ".vbs" or RelativeTargetName endswith ".vbe" or RelativeTargetName endswith ".js" or RelativeTargetName endswith ".jse" or RelativeTargetName endswith ".wsf" or RelativeTargetName endswith ".hta" or RelativeTargetName endswith ".exe" or RelativeTargetName endswith ".dll"))

Splunk · SPL

Run this as a search.

index=* (EventID="5145" AND (ShareName="*\\NETLOGON" OR ShareName="*\\SYSVOL") AND (AccessList="*%%4417*" OR AccessList="*%%4418*" OR AccessList="*WriteData*" OR AccessList="*AppendData*") AND (RelativeTargetName="*.bat" OR RelativeTargetName="*.cmd" OR RelativeTargetName="*.ps1" OR RelativeTargetName="*.vbs" OR RelativeTargetName="*.vbe" OR RelativeTargetName="*.js" OR RelativeTargetName="*.jse" OR RelativeTargetName="*.wsf" OR RelativeTargetName="*.hta" OR RelativeTargetName="*.exe" OR RelativeTargetName="*.dll"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 5145 AND (TO_LOWER(ShareName) LIKE "*\\\\netlogon" OR TO_LOWER(ShareName) LIKE "*\\\\sysvol") AND (TO_LOWER(AccessList) LIKE "*%%4417*" OR TO_LOWER(AccessList) LIKE "*%%4418*" OR TO_LOWER(AccessList) LIKE "*writedata*" OR TO_LOWER(AccessList) LIKE "*appenddata*") AND (TO_LOWER(RelativeTargetName) LIKE "*.bat" OR TO_LOWER(RelativeTargetName) LIKE "*.cmd" OR TO_LOWER(RelativeTargetName) LIKE "*.ps1" OR TO_LOWER(RelativeTargetName) LIKE "*.vbs" OR TO_LOWER(RelativeTargetName) LIKE "*.vbe" OR TO_LOWER(RelativeTargetName) LIKE "*.js" OR TO_LOWER(RelativeTargetName) LIKE "*.jse" OR TO_LOWER(RelativeTargetName) LIKE "*.wsf" OR TO_LOWER(RelativeTargetName) LIKE "*.hta" OR TO_LOWER(RelativeTargetName) LIKE "*.exe" OR TO_LOWER(RelativeTargetName) LIKE "*.dll"))

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)(\\NETLOGON$|\\SYSVOL$)</field>    <field name="AccessList" type="pcre2">(?i)(%%4417|%%4418|WriteData|AppendData)</field>    <field name="RelativeTargetName" type="pcre2">(?i)(\.bat$|\.cmd$|\.ps1$|\.vbs$|\.vbe$|\.js$|\.jse$|\.wsf$|\.hta$|\.exe$|\.dll$)</field>    <description>Logon script written to the NETLOGON or SYSVOL share</description>    <mitre>      <id>T1037.003</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 3453e505-7ef5-4436-8376-d75e5f775ff6

ATT&CKT1037.003

T1037.003Network Logon Script

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

Someone writing a script or executable into the domain's NETLOGON or SYSVOL share — the act of planting or tampering with a network logon script, caught on the domain controller that serves it. AN1034 correlates a Group Policy change that configures a logon script with the script later executing at logon. Only the first half is worth alerting on: the execution half fires for every user at every logon in any domain that uses logon scripts, while the domain-wide script files themselves change only when somebody edits them. Two neighbouring rules leave this surface open on purpose — T1037.001 and the T1080 share-write rule both exclude these shares, because tampering here is this technique.

02 · Telemetry you need

product: windows, service: security, from AN1034's Security EventID 5145 log source, and the rule is written in that event's native vocabulary — ShareName, RelativeTargetName, AccessList.
5145 requires the Audit Detailed File Share subcategory, which is off by default and absent from both the Microsoft and CIS baselines. With it off the rule returns zero rows, and zero rows here means blind, not quiet. The brief's third source, System EventIDs 4016 and 5312, is unused: policy-processing records emitted on every host at every refresh, naming no script. All four backends render the rule.

03 · How the logic works

One selection, four conditions ANDed. EventID: 5145 pins the event. ShareName|endswith takes \NETLOGON and \SYSVOL. That share gate is what MITRE's TargetObject knob — "path to network-based script execution" — becomes here, populated with the two default domain script shares; its ParentProcessName and UserContext knobs belong to the process leg and have no counterpart on 5145. AccessList|contains is written twice over, because collectors disagree: raw event data carries the message-table codes %%4417 and %%4418, while a collector that resolves message strings writes WriteData and AppendData. Confirm which form your pipeline stores — the codes are locale-independent, the resolved strings English only, so on localised Windows only the %% half fires. RelativeTargetName|endswith lists script and executable extensions, .bat through .hta, plus .exe and .dll. That list is the pipeline's own, and .dll is scope drift: neither the AD scriptPath attribute nor a GPO logon script accepts a DLL, so that leg covers no mechanism this technique names.

04 · Common false positives

Administrators editing the logon script over NETLOGON are the loudest source by far and produce the identical record — a Notepad save of logon.bat is indistinguishable from the attack, so matches must be paired with change control rather than triaged from the event. Group Policy tooling is next: authoring a script through GPMC drops the file into the GPO's Scripts folder over the same share with the same extensions. Then software deployment staged out of NETLOGON, and SYSVOL restores after a DC rebuild, which rewrite the tree at once.
One more that the rule's description explains but its false positives omit: 5145 records the access a client requested, not a completed write. An editor or Explorer open by an account holding write on the share produces %%4417 with no byte written — so the rule fires precisely when a defender inspects the script.

05 · Detection maturity

tier_1: , the lowest tier, and it stays there until it has been run against real data. UNVERIFIED: authored from DET0367, never executed against a log line.
tier_2: is cheap here — these writes are rare enough that a month of collection names the full population of legitimate writers.

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

Baseline by account and source host first; the set of principals that legitimately write NETLOGON is tiny, and that list is the filter. Drop .dll.
Then close the real coverage hole. The rule sees the payload landing, not the assignment. A GPO registers its script in \User\Scripts\scripts.ini inside SYSVOL, and .ini is not in the extension list — so the write that actually creates the persistence is invisible. Add a second selection on RelativeTargetName|contains: '\Scripts\' with |endswith: '.ini'; the contains keeps GPT.INI, rewritten on every policy change, out of it. And accept a hard limit: assigning an already-present script via the AD scriptPath attribute is an LDAP write with no share access, and emits no 5145.

Declared by the author

Domain administrators and helpdesk staff editing the logon script itself over the NETLOGON share, which is the same event this rule is looking for — a Notepad save or an Explorer copy of logon.bat produces exactly this record, and in an estate that still maintains logon scripts by hand it is the loudest source by far. Pair every match with change control rather than expecting the event to distinguish them.
Group Policy tooling writing script policies into SYSVOL: creating or editing a logon, logoff, startup or shutdown script through the Group Policy Management Console or the GroupPolicy PowerShell module drops the script file into the GPO's Machine\Scripts or User\Scripts folder over the same share, with the same extensions.
Software deployment done out of NETLOGON, a long-standing habit in smaller estates, where packaging staff stage installers, drive-mapping scripts and helper executables in the share and produce a burst of matching writes on every application release.
Restoring SYSVOL or the scripts folder from backup over the share after a domain controller rebuild or a replication repair, which rewrites every script file in the tree from a remote host in a single pass.

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

Share this rule

/u/siemphony/3453e505-7ef5-4436-8376-d75e5f775ff6

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.

Logon script written to the NETLOGON or SYSVOL share

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it