(Only) Windows Defender reporting installer as Wacatac.b!ml trojan

[Grayseon]

• Electron-Builder Version: 22.14.5

• Node Version: v16.13.1

• Electron Version: 16.0.4
• Electron Type (current, beta, nightly): Current

• Target: Windows

When the installer is done downloading, ONLY Windows Defender reports the file as a Wacatac.b!ml trojan. I've tried scanning my computer after it is done downloading, but it finds nothing even though I have the installer fully downloaded. Malwarebytes does not report this as a trojan, so I'm thinking this is a false positive.

[Grayseon]

I was able to avoid it using electron-builder@22.10.5 but I'm still going to keep it open so the developers know about this.

[pietersartain]

My Windows Defender is doing the same, but showing as Trojan:Win32/Bulta!rfn (using Electron 15.3.3, Node 17.1 on Windows 10). Rolling back to 22.10.5 also works for me.

[zSakuraEvilz]

I also encountered the same situation. Had to downgrade to electron-builder@22.10.5 to works.

[xmedeko]

Maintainers should use https://www.microsoft.com/en-us/wdsi/filesubmission and then choose option Software developer (works in Chrome or Edge only).

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[xmedeko]

It seem OK now (we use ver. 22.14.13).

[fr3shn3ss]

I had the same issue with V22.11.9 then upgraded to V23.1.0 and still see the same issue. Here is the strange part, sometimes Win Defender blocks it, sometimes it doesn't and let it install.

If you right click and scan exe, Defender won't find a threat

[fr3shn3ss]

Here is another strange find. I had the exe file uploaded to AWS S3. Now that I uploaded it to google drive and created a public link, windows doesn't recognize it as a trojan

[tonpap]

Any update on that? I am using v22.2.0 and I also sometimes have the issue..

[tjx666]

Still exists this issue in both version 22.10.5 and 23.6.0

The .exe file will not be report trojan, but compressed to .zip format will be reported. So, one solution is to compress .exe using other format, for example .rar

[hiagodotme]

Here it only started to happen after I created an automatic updater.

Apparently Windows marks the URL of the downloaded exe and it goes into a blacklist.

What I did was the following:

I used the electron-dl library to download my executable in an AWS bucket in a temporary folder, after the download was complete I tried to initialize the executable through the exec command in the child_process package.

I don't know if this helps to understand the problem, I haven't found a solution.

Here is an example of my code.

import { BrowserWindow, app } from "electron";
import { exec } from 'child_process';
import { join } from 'path';
import { download } from "electron-dl";

class Example {
    async startUpdate(vc_url: string) {
        const win = BrowserWindow.getFocusedWindow();
        const hostAtual = await win.webContents.executeJavaScript('location.host');

        if (
            hostAtual !== 'myui-stage.mydomain.com' &&
            hostAtual !== 'myui.mydomain.com'
        ) {
            throw `The host ${hostAtual} does not have permission to use the method..`
        } else if (!vc_url.startsWith('https://')) {
            throw 'Only updates from secure sources are allowed.'
        }

        // all ok, start the update
        try {
            const filename = `myapp-update-${Date.now()}.exe`,
                filepath = join(app.getPath('temp'), filename);
            const down = await download(win, vc_url, {
                directory: app.getPath('temp'),
                filename: filename,
            });

            // starting update
            exec(filepath);
            return true;
        } catch(e) {
            return false;
        }
    }
}

Does the act of downloading an unsigned executable and trying to run it classify the application as a trojan?

[samlhuillier]

Still experiencing this here: https://github.com/reorproject/reor/issues/58

Using electron builder: 24.9.1 And electron: 28.2.1

Is a solution to this to setup code signing? Perhaps that'd make windows defender trust it more...

[pietersartain]

@samlhuillier we used to code sign our electron apps, which worked fine with the CI environment (gh actions) but didn't change the fact local dev builds on our machines triggered this. In the end I just marked the directory I was building into as an exclusion on defender (Virus & threat protection -> settings -> exclusions).

[samlhuillier]

Thank you @pietersartain !

You're saying that code signing your electron apps made windows defender stop showing Wacatac.b!ml trojan when it was downloaded as an exe?

[pietersartain]

Thank you @pietersartain !

You're saying that code signing your electron apps made windows defender stop showing Wacatac.b!ml trojan when it was downloaded as an exe?

Not quite. When downloaded from our CDN, signed or otherwise, it seemed to be fine. It was just when built locally that Defender got twitchy.

For completeness, I never saw Wactac.b!ml, but I did see Trojan:Win32/Bulta!rfn (as listed in my comment 2 years ago). I raised it in this thread because it the symptoms felt more similar than not :)

We code signed at the time and never had any reports of our exe being listed as a trojan. Additionally, we've since stopped code signing (for various reasons, and only for a few months now) and still haven't had any reports.

Right now we're using electron-builder 23.3.3. I haven't tested a more recent build of electron-builder and I still have the directory-based exclusion for testing local builds.

In short: this seemed to be an entirely local build problem, not a distribution problem.

[mmaietta]

I found this other issue/comment that calls out that elevate.exe may not need to be signed. Anyone willing to give that a shot using the custom win.sign hook? https://github.com/electron-userland/electron-builder/issues/6304#issuecomment-1057739612

I haven't been able to replicate on my windows VM or windows gaming rig.

[MWstudio]

I haven't had this issue in the last few months, but since last week when I released the product, suddenly had this issue.

[capc0]

We noticed the same issue appearing since last week. Maybe Windows Defender updated its database/detection causing this issue to appear again... No current solution at the moment.

[mmaietta]

I found this previous comment for a custom sign implementation that may be impactful or fix this issue (in which case I can open a PR to fix this) https://github.com/electron-userland/electron-builder/issues/6304#issuecomment-1057739612

Specifically, this part of the comment stuck out to me:

// Do not sign elavate file, because that prompts virus warning.
if (targetPath.endsWith('elevate.exe')) {
  return
}

Would someone mind testing out that custom sign hook? It's very easy to set up, you just pass the path to the win: { sign: <path to sign.js file> }

I'd test this approach myself, but I don't receive any trojan alert via Windows Defender so I can't verify the fix

[capc0]

(un)fortunately I am also no longer able to reproduce this. The same installer .exe that was throwing the alert last week is now working without any alert. I did check the windows defender settings and made sure that the allow-entry was not present beforehand.

[Grayseon]

Same thing here, yesterday I found the exact file on my Google Drive that I was using when I posted this issue. Running it through VirusTotal or Windows Defender does not get flagged anymore.

[mmaietta]

Thanks for the update!

I'll leave this issue open as I'm sure it will occur again, in which case, I would really appreciate anyone testing this approach out https://github.com/electron-userland/electron-builder/issues/6474#issuecomment-1964716787

I'll keep an eye out during my local testing as well.

---

To make it easier for anyone willing to test out my suggestion, here's the code for copy-paste windows-sign.js

const { doSign } = require('app-builder-lib/out/codeSign/windowsCodeSign')

/**
 * @type {import("electron-builder").CustomWindowsSign} sign
 */
module.exports = async function sign(config, packager) {
  // Do not sign if no certificate is provided.
  if (!config.cscInfo) {
    return
  }

  // Do not sign elevate file, because maybe that prompts virus warning?
  const targetPath = config.path
  if (targetPath.endsWith('elevate.exe')) {
    return
  }

  return doSign(config, packager)
}

[tinyCoder32]

Thanks for the update!

I'll leave this issue open as I'm sure it will occur again, in which case, I would really appreciate anyone testing this approach out #6474 (comment)

I'll keep an eye out during my local testing as well.

To make it easier for anyone willing to test out my suggestion, here's the code for copy-paste windows-sign.js

const { doSign } = require('app-builder-lib/out/codeSign/windowsCodeSign')

/**
 * @type {import("electron-builder").CustomWindowsSign} sign
 */
module.exports = async function sign(config, packager) {
  // Do not sign if no certificate is provided.
  if (!config.cscInfo) {
    return
  }

  // Do not sign elevate file, because maybe that prompts virus warning?
  const targetPath = config.path
  if (targetPath.endsWith('elevate.exe')) {
    return
  }

  return doSign(config, packager)
}

I tested that, and only signed the installer, and I got the same result. It's still identified as Win32/Wacapew.C!ml

[Antelope-IT]

We have just started to encounter this problem. We are building an Electron v27.3.9 app using electron-builder v24.13.3. Up until very recently we used to sign the msi and Setup.exe build artefacts but we did not sign elevate.exe and Windows Defender used to give both artefacts a clean bill of health. The most recent build CI build we did (without signing) triggers Windows Defender which quarantines the Setup.exe as Trojan:Win32/Wacatac.b!ml. The msi which is built at the same time from the same source is given a clean bill of health though. In addition testing the troublesome setup.exe on two different Windows machines with identical up-to-date virus signatures one machine identifies the virus the other does not - we can see no reason why this should be.

Our workaround will be to only build/deploy msi's

[Grayseon]

Just to be clear, the false positive only gets triggered when you target NSIS (which creates setup.exe), but when you target MSI it is clean? Are you ever targeting NSIS? Sorry if I'm misunderstanding, thanks

[Antelope-IT]

We started from the beginning of the project with a CI Build on Jenkins targetting NSIS (setup exe)

We then added signing to the build via a custom sign hook - which only signs our dlls and exe's we make. So Exe's from third parties like elevate.exe and ffmepg.exe are not signed in the build but the NSIS Setup.exe is.

We then added the MSI to the build outputs because the msi was preferred by some of our customers. The msi was also signed.

Up until this point we had never had problems triggerring the virus protection.

Due to circumstance we have had to turn off signing in CI the build.

The first build we did after turning off signing (nothing signed), the Setup.exe triggered defender and also Chrome when we tried to download it from our artefact repo or Jenkins. Interestingly Defender/Chrome is triggered when my colleague tries to download the unsigned Setup.exe from Jenkins but not when I do- we have the exact same versions of virus signatures / defender the only difference I can see is that he is on Win11 (latest) and I'm on Win10 (latest) I can download and scan the Setup.exe locally and it is fine but his triggers with the false positive.

The MSI, built at the same time as the NSIS Setup.exe, is clean - no false positives, and that is regardless of who downloads it.

As a result of this we have stopped building the NSIS Setup.exe and we only build the MSI (we can't distribute something that may throw false positives).

[tinyCoder32]

For us, after a long clean history of successful releases, and after trying a lot of solutions that failed:

The problem: started when we changed the Code Sign certificate. The solution: submitted the file once to Microsoft and reported a false positive, a few hours later, we're clean again to all users who received the warning.