Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1055.015Sub-techniqueObject v2.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1055 Process Injection This object subtechnique of Process Injection.
Associated objects

Groups, software, and campaigns

Malware Enterprise

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]

Windows
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
3d28d0b1ce7eb8c3...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 3d28d0b1ce7e…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Hexacorn Listplanting

    Hexacorn. (2019, April 25). Listplanting – yet another code injection trick. Retrieved August 14, 2024.

    Open source URL
  2. [2]
    Microsoft List View Controls

    Microsoft. (2021, May 25). About List-View Controls. Retrieved January 4, 2022.

    Open source URL
  3. [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. [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. [5]
    mitre-attack T1055.015
    Open source URL
Source and licensing

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.