AN0071: Analytic 0071
Abuse of trusted Electron apps (Teams, Slack, Chrome) to spawn child processes or execute payloads via malicious command-line arguments (e.g., --gpu-launcher) and modified app resources (.asar). Behavior chain: suspicious parent process (Electron app) → unusual command-line args → child process creation → optional DLL/network artifacts.
Analyst context for executives and security teams
This analytic is about a trust-abuse pattern on Windows where commonly allowed Electron-based applications such as Teams, Slack, or Chrome become the parent process for unusual child execution, suspicious command-line arguments, modified application resources, and possible DLL or network artifacts. For leaders, the value is not in treating the named apps as malicious, but in validating whether the SOC can distinguish normal collaboration/browser activity from execution chains that abuse trusted software to bypass user trust, allow-listing assumptions, or weak process monitoring.
Executive priority
Prioritize this as a control-validation and incident-readiness question: can the organization prove it monitors trusted desktop applications when they launch unexpected children or use unusual arguments? This matters for business resilience because collaboration and browser applications are widely deployed, frequently trusted by users and controls, and often generate high event volume. Security leaders should ask whether endpoint telemetry, detection engineering, and incident response playbooks cover abuse of trusted application parents without creating unmanageable false positives.
Technical view
On Windows, validate detections around Electron application parent processes spawning unusual child processes, especially when paired with uncommon command-line arguments such as the supplied example '--gpu-launcher', changes to application resource files such as '.asar', and follow-on DLL or network artifacts. Because ATT&CK provides no official detection logic and no tactic mapping for this object, teams should treat AN0071 as a behavior-chain hypothesis to test against local baselines rather than a ready-made rule. Focus on parent-child process relationships, command-line capture, file modification evidence for Electron app resources, DLL load context where available, and network activity temporally associated with the suspicious process chain.
Likely telemetry
- Windows endpoint process creation events with parent process, child process, image path, user, and full command line
- Command-line telemetry for Electron-based applications and their child processes
- File modification or integrity telemetry for Electron application resources, including .asar files
- DLL load or module telemetry associated with the suspicious process chain, where collected
- Network connection telemetry tied to the parent or child process
Detection direction
- Baseline normal child processes and command-line arguments for approved Electron-based applications such as Teams, Slack, and Chrome in the local environment.
- Look for suspicious chains combining a trusted Electron parent, unusual command-line arguments, unexpected child process creation, and optional DLL, file-resource, or network artifacts.
- Tune carefully for software updates, legitimate plug-ins, accessibility tools, enterprise management agents, and normal browser or collaboration-app behavior that may create noisy parent-child relationships.
- Confirm full command-line logging is enabled; without it, argument-focused detection such as use of unusual flags will be weak.
- Correlate process lineage with file modification and network evidence to reduce false positives, since the supplied object does not include a complete official detection analytic.
Mitigation priorities
- Ensure endpoint logging captures process creation, parent-child lineage, and full command lines on Windows systems running trusted Electron applications.
- Review application allow-listing, endpoint policy, and trust assumptions so trusted application names alone do not suppress suspicious child execution.
- Monitor integrity or unexpected modification of Electron application resources where feasible, especially .asar resources referenced by the object.
- Prepare incident response triage steps for trusted-application abuse, including collection of process trees, command lines, modified resources, DLL evidence, and related network activity.
- Use local baselining before enforcement, because collaboration and browser applications are high-volume and legitimate behavior varies by organization.
Analyst notes and limits
AN0071 is a detection analytic object, not a technique, and the supplied ATT&CK fields provide a behavioral description but no official detection text, tactic mapping, or relationship context. The strongest use is as a validation scenario for Windows endpoint visibility and detection engineering around trusted Electron application abuse.
This take is limited to the supplied ATT&CK fields. It does not establish active exploitation, actor attribution, impact, prevalence, or guaranteed detectability. Local application versions, endpoint logging depth, command-line collection, and normal enterprise software behavior will determine practical coverage.
Analytic 0071
Abuse of trusted Electron apps (Teams, Slack, Chrome) to spawn child processes or execute payloads via malicious command-line arguments (e.g., --gpu-launcher) and modified app resources (.asar). Behavior chain: suspicious parent process (Electron app) → unusual command-line args → child process creation → optional DLL/network artifacts.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | 8c12c24577c9… |
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]
mitre-attack AN0071Open 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.