Shortcut file written into a Startup folder

Siemphony@siemphonylowT1547.009unverified

Matches Sysmon EventID 11 for a `.lnk` file landing in either Startup location — the per-user and all-users paths share the `\Microsoft\Windows\Start Menu\Programs\Startup\` suffix, so one contains term covers both. This stands in for AN0510's separate file-modification leg (Sysmon EventID 2) too, since that event only fires on a timestamp change and would miss a content edit that leaves it alone, while EventID 11 fires on the create-or-recreate pattern most shortcut editors use. What it cannot do is MITRE's own qualifier — anomalous lineage or an unsigned target — because Sysmon 11 names the shortcut file, never what it points to, so a malicious placement is indistinguishable here from a benign one. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0180, 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.

DeviceFileEvents| where (FolderPath endswith ".lnk" and FolderPath contains "\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\")

Splunk · SPL

Run this as a search.

index=* (TargetFilename="*.lnk" AND TargetFilename="*\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(file.path) LIKE "*.lnk" AND TO_LOWER(file.path) LIKE "*\\\\microsoft\\\\windows\\\\start menu\\\\programs\\\\startup\\\\*")

Wazuh · XML rule

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

<group name="sigma,windows,file_event,">  <!-- 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="TargetFilename" type="pcre2">(?i)\.lnk$</field>    <field name="TargetFilename" type="pcre2">(?i)\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\</field>    <description>Shortcut file written into a Startup folder</description>    <mitre>      <id>T1547.009</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: low
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: e9a69a65-b72e-41f9-b129-9196286903b7

ATT&CKT1547.009

T1547.009Shortcut Modification

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

A .lnk file being written into a Startup folder — the per-user path or the all-users path, both of which end in \Microsoft\Windows\Start Menu\Programs\Startup\. That shared suffix is why the rule needs only one contains term instead of two separate paths. It detects the placement of a shortcut somewhere Windows will auto-launch it at logon — not what the shortcut points to, and not who wrote it.

02 · Telemetry you need

The logsource is category: file_event, product: windows, which maps to Sysmon EventID 11 (FileCreate). Sysmon is not a default Windows component, so this rule returns nothing on a host where it isn't installed, and some slimmed Sysmon configs filter noisy user-writable paths — confirm Startup-folder .lnk creation isn't one of the exclusions before trusting a quiet result.

03 · How the logic works

Two selections, ANDed: selection_lnk (TargetFilename|endswith: '.lnk') and selection_startup_path (TargetFilename|contains: '\Microsoft\Windows\Start Menu\Programs\Startup\'). Both have to match the same event, on the same field, so the condition is just selection_lnk and selection_startup_path — no OR-groups, nothing for Wazuh to refuse. The rule's description says EventID 11 stands in for AN0510's separate file-modification leg (EventID 2) too, on the theory that most shortcut editors delete-and-recreate the file rather than editing it in place. The reviewer flagged this as overstated: some editors, and the Shell's own IShellLink COM interface, can rewrite an existing .lnk's target via an open-write-close on the same file handle — no delete, no recreate. That produces EventID 2 (or, if only content changes and not the timestamp, sometimes no Sysmon file event at all), which this file_event-only rule never sees. In-place target swaps on an already-planted, already-trusted shortcut are exactly the quiet persistence move this gap misses. Learn this pattern: "EventID 11 covers most of the technique" and "EventID 11 covers all of the technique" are different claims, and the gap between them is where an adversary who knows Sysmon internals will sit. Also missing, structurally: MITRE's own qualifier for AN0510 is anomalous process lineage or an unsigned target. Sysmon 11 records the shortcut file's name, not what it resolves to, so this rule can never tell a malicious placement from a benign one on its own.

04 · Common false positives

Four sources, in the order the rule author ranked them: installer/updater tray helpers (cloud storage, chat, printer, VPN, update agents) are the highest-volume match "by a wide margin" on any managed fleet; Group Policy Preferences shortcut items get rewritten on every GPO refresh (~90 minutes plus jitter) whether or not anything changed; a user dragging their own shortcut into their own Startup folder is indistinguishable from an attacker doing the same; and Chocolatey/SCCM/Intune-style deployment tooling stages Startup shortcuts as routine rollout.

05 · Detection maturity

tier_1: UNVERIFIED — the lowest tier. This rule has never been run against a single log line, so there is no false-positive rate, no hit count, and no tuning history to cite. Everything above is reasoning from the logic, not from evidence.

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

MITRE's mutableElements for AN0510 name four knobs: TargetPathRegex, TimeWindow, UserContextScope, and ZoneIdentifierThreshold. None are populated here — this rule doesn't implement any of them. TimeWindow in particular can't be: lib/sigma in this corpus has no aggregation or correlation support, so a rule can only ever cover the precursor event (the file write), never "this write followed by execution within N minutes." That is normal for this corpus, not a defect specific to this rule — every Sigma rule here is a single point-in-time match, and correlating it with a later process launch is SIEM-side work outside what Sigma expresses. Tuning options that stay in-rule: add a TargetPathRegex-style check once you have a logsource that records the shortcut's target (not this one), or narrow UserContextScope by joining against known-admin accounts downstream.

Declared by the author

Application installers and updaters that place a Startup shortcut so their tray helper or update checker launches at logon — this is standard practice for cloud-storage clients, chat apps, printer utilities, VPN clients and update agents, and is the highest-volume match on any managed fleet by a wide margin.
Group Policy Preferences shortcut items reapplied on every Group Policy refresh (roughly every 90 minutes plus jitter) and at every logon, rewriting the same .lnk file in the Startup folder on every in-scope host regardless of whether anything actually changed.
A user manually dragging a shortcut into their own per-user Startup folder for convenience, which this rule cannot distinguish from an adversary doing the same thing with a malicious target — nothing in Sysmon 11 carries who initiated the write or what the link resolves to.
Package managers, imaging tools and endpoint-management platforms (Chocolatey, SCCM/Intune application deployment) staging Startup shortcuts as a standard step of application rollout across the fleet.

Noise check0 of 3 fired

Fires on none of the 3 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 3 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 T1547.009, evaluated against their file_event events.

Share this rule

/u/siemphony/e9a69a65-b72e-41f9-b129-9196286903b7

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.

Shortcut file written into a Startup folder

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it