Detecting and Mitigating Electron Application Abuse (T1218.015)

Plenty of the desktop apps your staff use all day are web pages in a wrapper. The Electron framework hosts applications such as Signal, Slack and Microsoft Teams. MITRE ATT&CK tracks the abuse of that framework as T1218.015, Electron Applications, a System Binary Proxy Execution sub-technique in the Stealth tactic. It applies to Linux, macOS and Windows.

How attackers use it

Electron was originally developed by GitHub. It is a cross platform desktop framework built on web technologies: JavaScript, HTML and CSS. It uses the Chromium engine to display web content and Node.js to run backend code.

That design is the root of the issue. Electron allows apps to run arbitrary commands, so adversaries may be able to do harmful work in the background, potentially disguised as legitimate tools within the framework. MITRE gives an example of abusing teams.exe and chrome.exe so that malicious commands run as child processes of the legitimate application. The example passes a launcher option to Chrome that hands a command line to the operating system, and MITRE shows it opening cmd.exe.

Adversaries may also run malicious content by planting malicious JavaScript inside Electron applications. That is a different angle: instead of abusing a command line option, the attacker changes what the app itself loads.

Why it is hard to see

Collaboration apps are on every machine, start at login and talk to the internet. A new child process of Teams or Slack does not look odd to a person who is not looking for it. Rules that trust the parent because it is a well known signed application will not fire.

The signals are structural. Electron apps do not usually spawn shells. They rarely start script interpreters or download tools.

How to detect it

The MITRE detection strategy has one analytic per platform:

• Windows and general: trusted Electron apps such as Teams, Slack or Chrome spawning child processes or executing payloads through malicious command line arguments, for example a GPU launcher option, or through modified application resources (.asar files). The chain is a suspicious parent (the Electron app), unusual arguments, child process creation, and optional DLL or network artifacts.
• Linux: modification of app.asar or configuration JavaScript files, with unexpected child processes such as bash, curl or python.
• macOS: modification of app.asar bundles, with child processes such as osascript, curl or sh spawned from Electron executables.

So you need three kinds of telemetry:

1. Process creation with parent, child and command line.
2. File integrity monitoring on application resource files. The app.asar file normally changes only when the app updates.
3. Network connections from child processes of Electron apps.

Tuning

Build a short list of child processes each Electron app legitimately starts. Updaters and helper processes are normal. Shells, script interpreters, curl and osascript are not. Alert on those, and on command lines containing unusual launcher options.

How to reduce the risk

MITRE lists three mitigations.

• Exploit protection. Attack Surface Reduction features can block methods of using trusted binaries to bypass application control. Make sure Electron is updated to the latest version and that critical vulnerabilities, such as nodeIntegration bypasses, are patched and cannot be exploited.
• Disable or remove the feature or program. Remove or deny access to unnecessary and potentially vulnerable software. For app developers, MITRE suggests disabling Node.js integration in all renderers that display remote content, which limits what planted JavaScript can do.
• Execution prevention. Where possible, enforce binary and application integrity with digital signature verification. Do not use shell.openExternal with untrusted content. Where possible, set nodeIntegration to false, which disables access to Node.js functions.

If your own team ships an Electron app, those developer settings are your job. If you only run other people's Electron apps, keep them patched and watch what they spawn.

Keep your own Electron dependencies in view

If you build Electron apps, the mitigation about staying current is also a dependency question. Electron and the packages bundled into your app are part of your supply chain, and an old version carries whatever flaws were fixed after it shipped. An inventory of what you bundle is the starting point.

You can scan a dependency manifest for free in your browser at gold.safeguard.sh/scan. No login is needed, the file never leaves your machine, and it handles up to 100 dependencies.

Try it yourself

Click through it at your own pace, or open it full screen.

Check your own environment

• Which Electron based apps are installed on your fleet, and which versions?
• Do your endpoint tools alert when Teams, Slack or a browser starts cmd.exe, a shell or a script interpreter?
• Is there file integrity monitoring on app resource files such as app.asar?
• For apps you build, is Node.js integration off in renderers that show remote content?

This read-only command lists direct child processes of a given parent on Linux or macOS. Replace the process name with the app you care about:

ps -eo pid,ppid,comm | grep -i slack

Use the PID in the first column to look for children by matching it against the PPID column.

What good looks like

A good setup watches parent and child relationships for the collaboration apps in your fleet. Teams, Slack and the browser should not start shells or script interpreters, and when they do, someone sees it. The apps stay patched, application resource files are monitored for change, and any Electron app your own team ships has Node.js integration turned off for remote content.

Quick check

Sources

• MITRE ATT&CK, T1218.015: https://attack.mitre.org/techniques/T1218/015