Suggested Articles
Guess whos back...Wacatac....
After updating to 21.4 today, After building my setup.exe (its not actually named "setup.exe"), mind you... But when it tries to update the app via the "setup.exe" Windows Defender is reporting the "Trojan:Win32/Wacatac.B!ml" again. This is happening on about every other build of Advanced Installer. I know what there are other posts about this. It was also reported in October 2023... False positive or not, it doesn't look good to my customers when they try to update an app and windows defender reports it as a Trojan. Furthermore, we can't have every employee at a customer's location send in feedback to Microsoft. ...
![Image]()
- Attachments
-
- WindowsDefender message
- 001586.png (15.23 KiB) Viewed 5989 times
Re: Guess whos back...Wacatac....
Hello and welcome to our forums,
I apologize for the inconveniences you experienced.
Please note that your customers do not have to send reports to Microsoft. You can send to Microsoft a whitelist request and wait for the setup to be whitelisted before sending it to your customers.
This is also done with every version of Advanced Installer. When our setup is detected (before we make it public on our website), we contact specific antivirus vendors to whitelist our product. Sometimes we have to report a false positive detection, as detection algorithms are constantly evolving.
There has been an increase in false positive detections by Windows Defender recently. To tackle this issue effectively, we recommend the following solutions:
1. Add an exclusion for Defender on the output folder where your setup project is built. Detailed instructions on how to add an exclusion can be found here: Windows Security Exclusion Guide
2. Exclude specific processes, namely AdvancedInstaller.com, advinst.exe, and signtool.exe. You can use a PowerShell command like this:
Add-MpPreference -ExclusionProcess "C:\Program Files (x86)\Caphyon\Advanced Installer 21.4\bin\x86\advinst.exe"
For a detailed guide on excluding processes, please refer to Microsoft's documentation: Configure process and file exclusions
Please note that these options are specific to your build computer and might not prevent detection when installing on other computers. However, they can help you bypass build time problems, allowing you to generate a setup file for submission to Microsoft for whitelisting.
After building the final setup on your machine, it is advisable to upload your setup to virustotal.com, an online malware scanning service. If the setup is detected by major antivirus vendors (Microsoft, Bitdefender, McAfee, Avast, etc) contact the respective antivirus company to report the false positive. Here is a list of vendors' contact details (How to submit): VirusTotal contacts
You can submit a false positive report to Windows Defender through this link: Microsoft False Positive Report
As evident from the discussion on the Microsoft forum linked below, similar incidents have been reported in the past, including cases where applications were built directly from Visual Studio:
Windows Defender deleting my own applications
Please note that these steps are essential to maintain the integrity of your software against evolving detection algorithms. Your cooperation is appreciated, and these actions will contribute to improving the accuracy of antivirus software detections.
Best regards,
Liviu
I apologize for the inconveniences you experienced.
Please note that your customers do not have to send reports to Microsoft. You can send to Microsoft a whitelist request and wait for the setup to be whitelisted before sending it to your customers.
This is also done with every version of Advanced Installer. When our setup is detected (before we make it public on our website), we contact specific antivirus vendors to whitelist our product. Sometimes we have to report a false positive detection, as detection algorithms are constantly evolving.
There has been an increase in false positive detections by Windows Defender recently. To tackle this issue effectively, we recommend the following solutions:
1. Add an exclusion for Defender on the output folder where your setup project is built. Detailed instructions on how to add an exclusion can be found here: Windows Security Exclusion Guide
2. Exclude specific processes, namely AdvancedInstaller.com, advinst.exe, and signtool.exe. You can use a PowerShell command like this:
Add-MpPreference -ExclusionProcess "C:\Program Files (x86)\Caphyon\Advanced Installer 21.4\bin\x86\advinst.exe"
For a detailed guide on excluding processes, please refer to Microsoft's documentation: Configure process and file exclusions
Please note that these options are specific to your build computer and might not prevent detection when installing on other computers. However, they can help you bypass build time problems, allowing you to generate a setup file for submission to Microsoft for whitelisting.
After building the final setup on your machine, it is advisable to upload your setup to virustotal.com, an online malware scanning service. If the setup is detected by major antivirus vendors (Microsoft, Bitdefender, McAfee, Avast, etc) contact the respective antivirus company to report the false positive. Here is a list of vendors' contact details (How to submit): VirusTotal contacts
You can submit a false positive report to Windows Defender through this link: Microsoft False Positive Report
As evident from the discussion on the Microsoft forum linked below, similar incidents have been reported in the past, including cases where applications were built directly from Visual Studio:
Windows Defender deleting my own applications
Please note that these steps are essential to maintain the integrity of your software against evolving detection algorithms. Your cooperation is appreciated, and these actions will contribute to improving the accuracy of antivirus software detections.
Best regards,
Liviu
Re: Guess whos back...Wacatac....
With all due respect, this error does not occur in the build process. It occurs when a user downloads the generated file. This post is more or less to identify a specific scenario that consistently causes this, and perhaps it can help all Advanced Installer users that have experienced this in some capacity. Please note, the generated file is not actually named "setup.exe" for obvious reasons, but I will refer to it as the setup.exe. When I use Advanced Installer to generate the "setup.exe", and it is pushed to the server, when a client is notified to update their application to the new version, and the new "setup.exe" is downloaded onto the clients computer, that is when the antivirus detects it, and by your logic in your reply....Each client, as they may all be configured differently would need, to run the exclusion script, but we can't ensure that the user has that type of permissions on their machines. They might be locked down. Also, the trigger would be "On Downloaded" not "On Build Completed". It couldn't be triggered by the setup itself, because the trojan is detected just as soon as it is downloaded.
So, after having seen this happen several times, I have started to test scenarios on when this happens. And I can reproduce it now. Now I am not sure that this is the **only** scenario in which this occurs, but I know that this is one scenario that will consistently cause the "setup.exe" to be flagged with the trojan. Perhaps this will allow you to put in some sort of stopgap, for this specific scenario.
So, in my scenario I run a PowerShell script to publish a self-contained .net6, .net7, or .net8, depending on the application, to ensure the end user does not have to have the .NET core runtime / SDK installed, as well as the WebView runtime / SDK. Those dependencies are packaged in the release build to a folder named "mypubx64". now let's also say, that since the last publish, i did a few windows updates and perhaps the .net8 targets or dependencies changed, when I do my publish and it rebuilds those assemblies to package with my release, it sometimes changes the name of a .DLL that was generated, or copied into the self-contained-package, or sometimes it may even copy a .DLL that was not there the last time we did the same publish. Say for example, we published last week and there was a file in my publish folder named "wpfgfx_cor2_9.dll" and this week, when I did the same publish the publish folder has a file named "wpfgfx_cor3.dll". The issue it seems is on your "Files and Folders" tab. The actual list of files may not be in sync with what is actually in the publish folder. The good thing is you guys already have a mechanism to ensure that the folder synchronizes with the content of the folder on disk. However, it is not the default option, and in my scenario, this will cause the "setup.exe" to eventually be detected as the Wacatac trojan. I do not know why exactly but I have a pretty good idea. But the key, for THIS SCENARIO, is to ensure that the "Synchronize content with folder from disk" is checked. And the cause of the trojan being detected seems to be related to a file missing from the publish folder, or a file being named something different, or even a new file that wasn't there last week but is now. If the synchronization is not selected, then the setup.exe will be detected as Wacatac when a client downloads it. That being said, this scenario might have another layer to it. when the clients download the setup.exe, it goes into their "C:\Users\{username}\Downloads\" folder. I am not sure, but it seems like this could play a role in why its detected "On Downloaded" and not "On Build Completed".
I also identified another scenario, in which the certificate that was being used to sign the files, showed in Advanced Installer as still valid and not expired, but would still fail causing the "setup.exe" to not be signed correctly, and eventually being detected as a Wacatac. No errors were thrown during the first .AIP build, but the "setup.exe" was detected as having Wacatac. I reopened the AIP project without changing ANYTHING and did a rebuild and this time it caught the signing errors in the build and they were displayed in red on the Output tab, unlike the first build. I examined the cert it was trying to use, which is the same one I used with the last successful build, and everything looked good on it, but ultimately I just created a brand new cert to sign with and the "setup.exe" was generated, pushed to the server, downloaded by the client, and installed without a hitch.
So this post is more or less, like I said a journal of things I have found in my own process that can trigger false positives. I hope this can help other users in the future.
So, after having seen this happen several times, I have started to test scenarios on when this happens. And I can reproduce it now. Now I am not sure that this is the **only** scenario in which this occurs, but I know that this is one scenario that will consistently cause the "setup.exe" to be flagged with the trojan. Perhaps this will allow you to put in some sort of stopgap, for this specific scenario.
So, in my scenario I run a PowerShell script to publish a self-contained .net6, .net7, or .net8, depending on the application, to ensure the end user does not have to have the .NET core runtime / SDK installed, as well as the WebView runtime / SDK. Those dependencies are packaged in the release build to a folder named "mypubx64". now let's also say, that since the last publish, i did a few windows updates and perhaps the .net8 targets or dependencies changed, when I do my publish and it rebuilds those assemblies to package with my release, it sometimes changes the name of a .DLL that was generated, or copied into the self-contained-package, or sometimes it may even copy a .DLL that was not there the last time we did the same publish. Say for example, we published last week and there was a file in my publish folder named "wpfgfx_cor2_9.dll" and this week, when I did the same publish the publish folder has a file named "wpfgfx_cor3.dll". The issue it seems is on your "Files and Folders" tab. The actual list of files may not be in sync with what is actually in the publish folder. The good thing is you guys already have a mechanism to ensure that the folder synchronizes with the content of the folder on disk. However, it is not the default option, and in my scenario, this will cause the "setup.exe" to eventually be detected as the Wacatac trojan. I do not know why exactly but I have a pretty good idea. But the key, for THIS SCENARIO, is to ensure that the "Synchronize content with folder from disk" is checked. And the cause of the trojan being detected seems to be related to a file missing from the publish folder, or a file being named something different, or even a new file that wasn't there last week but is now. If the synchronization is not selected, then the setup.exe will be detected as Wacatac when a client downloads it. That being said, this scenario might have another layer to it. when the clients download the setup.exe, it goes into their "C:\Users\{username}\Downloads\" folder. I am not sure, but it seems like this could play a role in why its detected "On Downloaded" and not "On Build Completed".
I also identified another scenario, in which the certificate that was being used to sign the files, showed in Advanced Installer as still valid and not expired, but would still fail causing the "setup.exe" to not be signed correctly, and eventually being detected as a Wacatac. No errors were thrown during the first .AIP build, but the "setup.exe" was detected as having Wacatac. I reopened the AIP project without changing ANYTHING and did a rebuild and this time it caught the signing errors in the build and they were displayed in red on the Output tab, unlike the first build. I examined the cert it was trying to use, which is the same one I used with the last successful build, and everything looked good on it, but ultimately I just created a brand new cert to sign with and the "setup.exe" was generated, pushed to the server, downloaded by the client, and installed without a hitch.
So this post is more or less, like I said a journal of things I have found in my own process that can trigger false positives. I hope this can help other users in the future.
Re: Guess whos back...Wacatac....
Hello John,
After reading your post, my first though was indeed your conclusion - i.e. the fact that the setup was not digitally signed.
What my colleague Liviu explained above was a best-practice, so to say. It is something that we do ourselves as well, each release, to try to avoid the false-positives as much as possible.
However, sometimes this is not possible as at the moment of the scan, everything is alright and the next day we are flagged. That being said, it's not a "bullet proof" method, but it definitely helps, from what we could notice so far.
This is something I would suggest you do as well. After building your project, you can take the resulted EXE and upload in on VirusTotal.
If some well known vendors come up as a detection, the next step, which is optional but something we do, is to install that said AntiVirus on a VM and try to run the same setup that was detected on VirusTotal (as VirusTotal is not 100% accurate either).
If the setup is detected, you can then submit it for whitelisting and publish it on your website after the confirmation that it was whitelisted.
Best regards,
Catalin
First of all, thank you for your contribution to our forum.So this post is more or less, like I said a journal of things I have found in my own process that can trigger false positives. I hope this can help other users in the future.
After reading your post, my first though was indeed your conclusion - i.e. the fact that the setup was not digitally signed.
What my colleague Liviu explained above was a best-practice, so to say. It is something that we do ourselves as well, each release, to try to avoid the false-positives as much as possible.
However, sometimes this is not possible as at the moment of the scan, everything is alright and the next day we are flagged. That being said, it's not a "bullet proof" method, but it definitely helps, from what we could notice so far.
This is something I would suggest you do as well. After building your project, you can take the resulted EXE and upload in on VirusTotal.
If some well known vendors come up as a detection, the next step, which is optional but something we do, is to install that said AntiVirus on a VM and try to run the same setup that was detected on VirusTotal (as VirusTotal is not 100% accurate either).
If the setup is detected, you can then submit it for whitelisting and publish it on your website after the confirmation that it was whitelisted.
Best regards,
Catalin