T1218.015: Electron Applications
Adversaries may abuse components of the Electron framework to execute malicious code. The Electron framework hosts many common applications such as Signal, Slack, and Microsoft Teams.[1] Originally developed by GitHub, Electron is a cross-platform desktop application development framework that employs web technologies like JavaScript, HTML, and CSS.[2] The Chromium engine is used to display web content and Node.js runs the backend code.[3]
Due to the functional mechanics of Electron (such as allowing apps to run arbitrary commands), adversaries may also be able to perform malicious functions in the background potentially disguised as legitimate tools within the framework.[3] For example, the abuse of `teams.exe` and `chrome.exe` may allow adversaries to execute malicious commands as child processes of the legitimate application (e.g., `chrome.exe --disable-gpu-sandbox --gpu-launcher="C:\Windows\system32\cmd.exe /c calc.exe`).[4]
Adversaries may also execute malicious content by planting malicious JavaScript within Electron applications.[5]
Analyst context for executives and security teams
Electron apps are common business desktop tools built on web and Node.js technologies. This technique matters because trusted-looking apps such as collaboration clients can be abused to run malicious code or spawn commands in the background, making activity look like normal software behavior rather than obvious malware execution.
Executive priority
Prioritize this as a stealth and control-validation issue across Windows, macOS, and Linux endpoints. Leaders should ask whether the organization knows which Electron-based apps are installed, whether unnecessary or end-of-life apps are removed, and whether SOC tooling can distinguish legitimate Electron behavior from proxy execution. ATT&CK relationships to the 3CX Supply Chain Attack and Lumma Stealer show why this behavior is relevant to incident readiness and software trust decisions, without implying local exposure.
Technical view
For SOC, detection engineering, and IR teams, treat this as a System Binary Proxy Execution sub-technique. Validate monitoring for Electron applications launching unexpected child processes, unusual command-line flags, shell interpreters, or modified JavaScript/application resources. Because MITRE does not provide object-level detection text, use the related DET0025 detection strategy as a starting point and test against local baselines for approved Electron apps on Linux, macOS, and Windows.
Likely telemetry
- Endpoint process creation with parent-child relationships
- Full command-line arguments for Electron apps and spawned processes
- Application inventory for Electron-based software, install paths, versions, and business ownership
- File modification events in application resources, user profile app data, or JavaScript-related content locations
- Code signing, package provenance, and application control decision logs
Detection direction
- Baseline normal child-process behavior for approved Electron apps and alert on shell, script, or command execution that is not expected for that application.
- Tune carefully for developer and admin workflows where Electron-based tools may legitimately launch helpers or terminals.
- Correlate suspicious Electron child processes with recent file writes to application resources or user-writable app directories.
- Validate coverage across Windows, macOS, and Linux; do not assume Windows-focused detections cover cross-platform Electron abuse.
- Use the parent T1218 context to look for trusted application proxy execution rather than only known malware names.
Mitigation priorities
- Inventory Electron-based applications and remove or disable unnecessary, legacy, or unsupported software where business use is not justified.
- Apply execution prevention controls so only trusted and authorized code can run, including application control and script blocking where feasible.
- Use exploit protection and OS hardening capabilities to reduce abuse opportunities in desktop applications.
- Maintain ownership and approval records for collaboration and productivity apps so exceptions can be audited and incident responders can quickly separate normal from suspicious behavior.
Analyst notes and limits
The supplied ATT&CK object identifies Electron Applications as a stealth sub-technique under System Binary Proxy Execution and lists Linux, macOS, and Windows platforms. The strongest defensive value is in validating endpoint telemetry and application governance around trusted desktop apps that can execute code or spawn commands.
MITRE does not provide official detection text for this object. The take is based only on the supplied ATT&CK fields, external references, and relationships; local software inventory, telemetry quality, and business-approved Electron workflows are required to make detection and mitigation decisions.
Electron Applications
Adversaries may abuse components of the Electron framework to execute malicious code. The Electron framework hosts many common applications such as Signal, Slack, and Microsoft Teams.[1] Originally developed by GitHub, Electron is a cross-platform desktop application development framework that employs web technologies like JavaScript, HTML, and CSS.[2] The Chromium engine is used to display web content and Node.js runs the backend code.[3]
Due to the functional mechanics of Electron (such as allowing apps to run arbitrary commands), adversaries may also be able to perform malicious functions in the background potentially disguised as legitimate tools within the framework.[3] For example, the abuse of `teams.exe` and `chrome.exe` may allow adversaries to execute malicious commands as child processes of the legitimate application (e.g., `chrome.exe --disable-gpu-sandbox --gpu-launcher="C:\Windows\system32\cmd.exe /c calc.exe`).[4]
Adversaries may also execute malicious content by planting malicious JavaScript within Electron applications.[5]
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 | T1218 | System Binary Proxy Execution | This object subtechnique of System Binary Proxy Execution. |
Groups, software, and campaigns
S1213: Lumma Stealer
Lumma Stealer is an information stealer malware family in use since at least 2022. Lumma Stealer is a Malware as a Service (MaaS) where captured data has been sold in criminal markets to Initial Access Brokers.[1][2][3][4][5]
C0057: 3CX Supply Chain Attack
The 3CX Supply Chain Attack was the first publicly reported case of one supply chain compromise triggering another, leading to a cascading, two-stage intrusion. The initial supply chain attack began when a 3CX employee downloaded and executed a trojanized, end-of-life version of the X_Trader trading software from Trading Technologies. This provided UNC4736, a threat cluster associated with AppleJeus, access to the 3CX environment. From there UNC4736 compromised the Windows and macOS build environments used to distribute the 3CX desktop application to their customers.[1] While 3CX serves more than 600,000 customers and 12 million users, only a subset of systems were affected. Subsequent targeting focused on victims in the defense and cryptocurrency sectors, where attackers deployed secondary payloads such as Gopuram for credential theft and persistence.[2] The campaign began in late 2022 and was disrupted after security vendors publicly reported the compromise in March 2023.[3][4]
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 | 075c45fed048… |
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]
Electron 2
Trend Micro. (2023, June 6). Abusing Electronbased applications in targeted attacks. Retrieved March 7, 2024.
Open source URL -
[2]
Electron 3
Alanna Titterington. (2023, September 14). Security of Electron-based desktop applications. Retrieved March 7, 2024.
Open source URL -
[3]
Electron 1
TOM ABAI. (2023, August 10). There’s a New Stealer Variant in Town, and It’s Using Electron to Stay Fully Undetected. Retrieved March 7, 2024.
Open source URL -
[4]
Electron 6-8
Kosayev, U. (2023, June 15). One Electron to Rule Them All. Retrieved March 7, 2024.
Open source URL -
[5]
Electron Security
ElectronJS.org. (n.d.). Retrieved March 7, 2024.
Open source URL -
[6]
mitre-attack T1218.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.