Product: PowerShell Pro Tools 2022.11.2 (and possible previous version)
We are experiencing lots of false positive alerts with various detections by defender. Different Executable are deleted/isolated by defender. Lots a security alerts are going off. What is going on?
We’ve been seeing a large increase in false positives from PowerShell executables across all anti-virus platforms (you can upload it to VirusTotal to get a feeling for that).
Currently, the best options are to:
Just wanted to add what I’ve seen with this. It seems the .NET SDK it’s built with is checking dependencies online. It’s getting flagged as a trojan downloader for trying to download .NET dependences directly from Microsoft in some cases. Is this what you guys are seeing?
The resulting executable should not be downloading anything from Microsoft. The build process can certainly download NuGet packages and even the .NET SDK if necessary.
Thanks for the information. Maybe what I’m seeing is the SAC check being associated with the process running.
I’ve tested with and without obfuscation. I sign my executables with an EV certificate. Still getting flagged right now. Windows Defender just started. I did try a simple PS script to verify it wasn’t my code. Is there anything we can do to help you guys out with this, like submitting executables to AV vendors?
Submitting executables would be helpful. We’ve found it to very much be whack-a-mole. One AV vendor will stop flagging an executable and then another one will start. Because each executable is compiled manually, it seems like even between builds this can happen.
The problem is fundamentally that the packager is creating and embedding PowerShell scripts. AV vendors just really don’t like that. We see that PowerShell 7 executables don’t have quite the same problem because they have an unmanaged bootstrapper around the actual .NET executable so AV vendor is less likely to flag since it doesn’t see a .NET executable right off the bat.
The new Ironman PowerShell Host is a bit different because we don’t perform a compilation each time so the executable itself is more static. Because it’s more static, it seems like the AV vendor is less likely to flag it as suspicious because it has seen it before.
Still having the same issue. I opened a case at MS and delivered some executables. They confirmed it was flagged / detected. After lots of discussions they “promised” to remove the detection. After making some updates to the source files the same discussions / detected started all over again. My conclusion is this will never go away. I am now looking to switch to powershell 7 and executables, but that introduces a whole different challenge. The scripts work 99% of the time just fine, but the exe throws one error after the other. For example using ConvertTo-SecureString. Its was found in the Microsoft.Powershell.Security module but could not be loaded. The suggestion to import the module has no effect. I need to dig deeper and go through the learning curve for this I guess.
Issue with ConvertTo-SecureString solved. Now waiting for the combination powershell 7 and .net 7 to be supported
I have used the Default host and the IronmanPowerShell Host. The former throws wacatac.F!ml and the latter now throws a defender severe warning for Phonzy.B!ml so it doesnt help. The compiled executables are quarantined or removed. Effectively, the Packager is now useless for me given Defender is ubiquitous across all my target PC’s. Any suggestions?
Using PowerShell 5 scripts.