Security teams can detect ListPlanting abuse by watching for unexpected use of list-based persistence or start-up locations that load attacker-controlled code. Look for new entries, unusual parent processes, and changes made outside approved software deployment paths. Compare autorun artefacts, scheduled tasks, and startup folders against a known-good baseline.
How ListPlanting abuse shows up in telemetry
ListPlanting is usually easiest to spot as a persistence pattern, not as a single malicious file event. Security teams should treat unexpected writes to autorun locations, startup folders, scheduled tasks, and other list-based launch points as suspicious when they do not align with an approved deployment path or normal administrative tooling. The useful signal is the combination of location, timing, and the process that made the change.
A strong baseline matters because ListPlanting often hides in ordinary-looking persistence locations. Compare current autorun artefacts and startup entries with a known-good inventory, then review whether the entry was created by a packaging tool, a software update mechanism, or an unusual parent process. For defenders building detection content, the MITRE ATT&CK Guide for Defenders is useful for mapping these observations to technique-level detections and prioritising coverage.
In practice, the most reliable indicators are deviation-based: a new or modified persistence entry where the file path, signer, parent process, or time of change does not match your standard software lifecycle. If the entry points to a user-writable or temporary location, or if it loads from a path that normally should not be executed at logon or startup, that increases suspicion further.
What to review when a list-based launch point looks suspicious
Once you find a questionable entry, validate the full chain around it rather than the artefact alone. Review what created the entry, which account performed the change, whether the binary or script is expected in that location, and whether other persistence methods appeared around the same time. ListPlanting is often one part of a broader foothold, so neighbouring changes can reveal whether the activity is opportunistic or part of a more mature intrusion.
Look beyond the registry or folder entry itself and inspect the object that is being launched. A benign-looking name does not make the target safe. Check the file hash, signature, creation time, execution history, and any surrounding downloads or staging activity. If the change was made outside your software distribution channels, treat that as a detection lead even before you have proven malicious intent.
Correlating artefacts also helps separate normal administration from abuse. A scheduled task created by an endpoint management agent is different from one created by an interactive user process or a script dropped into a writable directory. The same applies to startup folder changes that arrive through a managed deployment tool versus those written directly by a suspicious parent process.
Baseline drift is the key detection problem
ListPlanting abuse is fundamentally a baseline problem: attackers benefit when defenders do not know which startup entries are normal, who is allowed to create them, and how often they should change. If your environment has weak software inventory, incomplete autorun visibility, or poor change attribution, malicious persistence can blend into routine churn.
That is why detections should be framed around expected state transitions. A startup item that appears without a corresponding deployment event, software package, or change ticket deserves attention. So does a new entry that references an unexpected executable location, a renamed payload, or a parent process that is rarely associated with software installation. The more tightly you model approved change, the more useful the alert becomes.
Security teams can improve precision by separating persistent entries by source: system-managed, user-managed, installer-managed, and unknown. Unknown should be the smallest category. When unknown entries grow, especially in user-writable locations or across many endpoints, the problem is usually not just one malicious file, but weak control over execution at startup.
Risk and Threat Considerations
ListPlanting abuse is risky because persistence at startup or logon gives an attacker repeated execution without needing to re-enter the environment. Once a malicious entry lands in a trusted list location, it can survive reboots, blend into normal operations, and support follow-on activity such as credential theft or lateral movement.
Failure mechanism: A malicious process creates or modifies a launch entry in a location that the operating system or users trust to execute automatically, often using a path or naming pattern that looks routine.
Impact: The payload can execute repeatedly, making containment harder and giving defenders a narrower window to catch the initial intrusion before persistence is established.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | ListPlanting is a persistence technique that abuses startup and autorun locations. |
| Recommendation — Map suspicious startup artefacts to T1547 and hunt for unauthorized autostart execution paths. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and Network Services Monitored | Detecting ListPlanting depends on continuous monitoring of endpoint persistence changes. |
| Recommendation — Monitor endpoint persistence locations continuously and alert on unauthorized changes. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Unexpected persistence entries are unauthorized configuration changes that need control. |
| Recommendation — Require approval for persistence-related changes and investigate unapproved additions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Baseline comparison of autoruns and startup folders is a secure configuration practice. |
| Recommendation — Baseline autorun locations and investigate drift from approved configuration. | ||
Practitioner Guidance
What to verify: Confirm that each startup, autorun, or scheduled launch entry has a matching change record, installer event, or approved management action. If you cannot tie the entry to a normal software path, treat it as suspicious until proven otherwise.
Common mistake: Teams often alert on the file path but not the creation context. For ListPlanting, the parent process and the origin of the change are often more important than the label on the entry itself.
Practitioner takeaway: The best detections are baseline-driven and change-aware, because ListPlanting abuse is easiest to miss when defenders look only at the persistence artefact and not at how it got there.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org