T1055.015: ListPlanting
Adversaries may abuse list-view controls to inject malicious code into hijacked processes in order to evade process-based defenses as well as possibly elevate privileges. ListPlanting is a method of executing arbitrary code in the address space of a separate live process.[1] Code executed via ListPlanting may also evade detection from security products since the execution is masked under a legitimate process.
List-view controls are user interface windows used to display collections of items.[2] Information about an application's list-view settings are stored within the process' memory in a SysListView32 control.
ListPlanting (a form of message-passing "shatter attack") may be performed by copying code into the virtual address space of a process that uses a list-view control then using that code as a custom callback for sorting the listed items.[3] Adversaries must first copy code into the target process’ memory space, which can be performed various ways including by directly obtaining a handle to the SysListView32 child of the victim process window (via Windows API calls such as FindWindow and/or EnumWindows) or other Process Injection methods.
Some variations of ListPlanting may allocate memory in the target process but then use window messages to copy the payload, to avoid the use of the highly monitored WriteProcessMemory function. For example, an adversary can use the PostMessage and/or SendMessage API functions to send LVM_SETITEMPOSITION and LVM_GETITEMPOSITION messages, effectively copying a payload 2 bytes at a time to the allocated memory.[4]
Finally, the payload is triggered by sending the LVM_SORTITEMS message to the SysListView32 child of the process window, with the payload within the newly allocated buffer passed and executed as the ListView_SortItems callback.
Analyst context for executives and security teams
ListPlanting is a Windows process-injection sub-technique that can make malicious code run inside a legitimate process by abusing list-view UI controls. Its business significance is that process-based allowlists, endpoint alerts, and incident triage can be misled when activity appears to come from a trusted process rather than the initiating code.
Executive priority
Treat this as a validation point for endpoint resilience and incident response readiness on Windows. Leaders should ask whether endpoint controls can detect suspicious inter-process behavior, window-message abuse, and memory allocation patterns rather than relying only on process names or file reputation. It is most relevant to privilege-escalation and stealth risk, especially where business-critical Windows systems depend on strong endpoint monitoring and defensible audit evidence.
Technical view
For SOC, detection engineering, and IR teams, ListPlanting should be reviewed under Process Injection (T1055) coverage for Windows. ATT&CK does not provide an official detection paragraph for this sub-technique, but the object and relationships point defenders toward behavior-based endpoint prevention and a related detection strategy, DET0331. Validate visibility into processes interacting with SysListView32 controls, anomalous use of Windows messaging APIs associated with list-view manipulation, suspicious memory allocation or code execution in another live process, and cases where execution context shifts into a legitimate process. InvisiMole is listed as software that uses this behavior, but that should be treated as relationship context, not as evidence of current activity in any environment.
Likely telemetry
- Endpoint process creation and parent/child process lineage on Windows
- Endpoint API or behavioral telemetry for inter-process access, memory allocation, and process injection patterns
- Windowing/UI interaction telemetry where available, including activity involving SysListView32 controls and list-view messages
- EDR events for suspicious process behavior, code execution in another process, or unusual callbacks
- Security product alerts tied to behavior prevention on endpoint controls
Detection direction
- Map existing T1055 Process Injection analytics to this Windows-specific sub-technique and confirm they do not depend only on WriteProcessMemory-style patterns, because the description notes variations that may use window messages to copy payload data.
- Validate whether DET0331 or equivalent local analytics are implemented, tested, and producing reviewable evidence.
- Tune for suspicious combinations: a process locating or interacting with list-view controls, allocating or preparing memory in another process, sending unusual list-view messages, and subsequent execution under a legitimate process context.
- Expect false positives from legitimate UI automation, accessibility tools, testing frameworks, and administrative utilities that interact with Windows controls; prioritize correlation with memory/process-injection indicators and unusual process relationships.
- During IR, avoid assuming a trusted process name means trusted behavior; inspect memory, loaded code regions, and recent inter-process interaction history.
Mitigation priorities
- Prioritize behavior prevention on endpoint as identified by ATT&CK mitigation M1040, emphasizing behavioral blocking and monitoring of suspicious process, API, and endpoint activity.
- Harden endpoint detection policies for process injection and anomalous inter-process behavior on Windows rather than relying solely on signatures or process reputation.
- Use least privilege and endpoint control baselines to reduce the value of successful injection into higher-privileged processes where applicable.
- Ensure SOC playbooks include triage steps for injected-code scenarios, including memory-oriented investigation and validation of legitimate process misuse.
- Maintain audit-ready evidence that Windows endpoint controls can observe and respond to stealth and privilege-escalation behaviors in the broader T1055 family.
Analyst notes and limits
This take is based on the ATT&CK T1055.015 ListPlanting object, its Windows platform designation, stealth and privilege-escalation tactics, its sub-technique relationship to Process Injection, the M1040 mitigation relationship, the DET0331 detection-strategy relationship, and the InvisiMole software relationship. The supplied references describe the underlying Windows list-view control abuse and related research sources.
MITRE does not provide an official detection section for this object in the supplied fields, and DET0331 details were not supplied beyond its name and relationship. Local validation is required to determine whether a specific EDR, logging configuration, or SOC analytic can observe this behavior. No claim is made that this activity is currently occurring in any environment.
ListPlanting
Adversaries may abuse list-view controls to inject malicious code into hijacked processes in order to evade process-based defenses as well as possibly elevate privileges. ListPlanting is a method of executing arbitrary code in the address space of a separate live process.[1] Code executed via ListPlanting may also evade detection from security products since the execution is masked under a legitimate process.
List-view controls are user interface windows used to display collections of items.[2] Information about an application's list-view settings are stored within the process' memory in a SysListView32 control.
ListPlanting (a form of message-passing "shatter attack") may be performed by copying code into the virtual address space of a process that uses a list-view control then using that code as a custom callback for sorting the listed items.[3] Adversaries must first copy code into the target process’ memory space, which can be performed various ways including by directly obtaining a handle to the SysListView32 child of the victim process window (via Windows API calls such as FindWindow and/or EnumWindows) or other Process Injection methods.
Some variations of ListPlanting may allocate memory in the target process but then use window messages to copy the payload, to avoid the use of the highly monitored WriteProcessMemory function. For example, an adversary can use the PostMessage and/or SendMessage API functions to send LVM_SETITEMPOSITION and LVM_GETITEMPOSITION messages, effectively copying a payload 2 bytes at a time to the allocated memory.[4]
Finally, the payload is triggered by sending the LVM_SORTITEMS message to the SysListView32 child of the process window, with the payload within the newly allocated buffer passed and executed as the ListView_SortItems callback.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1055 | Process Injection | This object subtechnique of Process Injection. |
Groups, software, and campaigns
S0260: InvisiMole
InvisiMole is a modular spyware program that has been used by the InvisiMole Group since at least 2013. InvisiMole has two backdoor modules called RC2FM and RC2CL that are used to perform post-exploitation activities. It has been discovered on compromised victims in the Ukraine and Russia. Gamaredon Group infrastructure has been used to download and execute InvisiMole against a small number of victims.[1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 3d28d0b1ce7e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Hexacorn Listplanting
Hexacorn. (2019, April 25). Listplanting – yet another code injection trick. Retrieved August 14, 2024.
Open source URL -
[2]
Microsoft List View Controls
Microsoft. (2021, May 25). About List-View Controls. Retrieved January 4, 2022.
Open source URL -
[3]
Modexp Windows Process Injection
odzhan. (2019, April 25). Windows Process Injection: WordWarping, Hyphentension, AutoCourgette, Streamception, Oleum, ListPlanting, Treepoline. Retrieved November 15, 2021.
Open source URL -
[4]
ESET InvisiMole June 2020
Hromcova, Z. and Cherpanov, A. (2020, June). INVISIMOLE: THE HIDDEN PART OF THE STORY. Retrieved July 16, 2020.
Open source URL -
[5]
mitre-attack T1055.015Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.