Runtime component wrongly blocked during setup - Avast "whitelisting" program?

Hello,

We are offering a product that uses a particular runtime. During the setup of our product, Avast will block a certain DLL, rendering our application unusable. Checking with the vendor of the runtime (that we have been using for several years already), they stated that while they participate in whitelisting programs with other security software vendors, they are unaware of any similar channel of communication with Avast. They stated that the only way to report such issues to Avast was the built-in tool.

While Avast has been quick to unblock one of the quarantined files (an executable), the DLL is still being quarantined. Several days later after several of us have reported the same issue, things remain unchanged.

Submitting the file to Virustotal gives it the green mark, but when the setup makes use of the same file, it is blocked. Thus, I suspect the reason is the behavior.

What would be the proper way to follow-up on such issues with Avast, in this case? I would like to speed up the things if possible, by providing the necessary info the vendor.

Thank you,
Szilard

You can contact the viruslab here: https://www.avast.com/contact-us.php?subject=VIRUS-FILE

Thank you, much appreciated.

You don’t mention the details of the avast alert on this dll, mainly the alert information file, location and crucially the malware name given ?

The reason I ask is that virustotal is doing an on-demand scan and this may only be being detected by the real time scanner.

Is this DLL digitally signed ?

The DLL is not digitally signed. I’m not sure it would help, really, if it were - during deployment, there is an executable, part of the runtime (and the one being caught before, but not anymore), that patches a bunch of DLLs (pretty sure this one as well), along with the main executable of the application, thus voiding any signature. I guess this behavior - all of a sudden - looks suspicious, and I can see why. But, again, I am only the end-user of this runtime, building on top of it, so I cannot offer a very in-depth look at thie whole process; what I did, was to let the publisher know that maybe they should push this with Avast a little bit more.

The history we had with the executable was that first it was called a threat, infection was unspecified; upon reporting it as a false positive, it is given the green light; a few days later, the very same file is blocked again (Virustotal shows that only avast considers it a threat, Win32:Malware-gen) - the same result we get by scanning the file’s folder on-demand. Reported again to Avast as a false positive…now it is tolerated again. This happened for the very same copy, from the same machine, tests running only after double-checking that we had the latest definitions.

As for the DLL, Virustotal shows the green checkmark coming in from Avast, but at runtime it is caught as Win32:Evo-gen[Susp].

When we encountered similar issues with a competitor, our vendor whitelisted this much quicker, due to the “whitelisting” program in place - that is why I was asking for directions.

Thank you, David, as well. Not sure about the “alert information file”; as for the location - well, we deploy either in ‘Program Files’, either in user’s ‘appdata’ location; not sure if that’s what you meant.

You’re welcome.

The Win32:Evo-gen [Susp] is as the [Susp] suffix is Suspicious and not necessarily considered 100%. I would suspect that the DLL would be being loaded into the System folder (and possibly why it is getting so much scrutiny) ?

So if a user knows that they downloaded it and installed it, they should be able to select an action from the alert/interactive window.

If they aren’t getting any option, it is being sent to the virus chest, it can also be sent directly to the virus labs from the virus chest.

Hopefully you will get the desired response from the support request from the Virus Labs that you submitted.