I definitely do not want to join this discussion as it is not the right place or audience. All I read so far is complaining about not getting a response, but the people who could give a response do not participate here, so while I understand that the situation is frustrating it won't get by complaining at the community.
I think the right processes have already mentioned. It is not the first time the established processes do not work or do not yield the expected result, in such a case the issue should be escalated through the Support Account Manager or Sales representative. I have been working long enough for Web Gateway support to know it is sometimes very hard and time consuming to get a proper response, but usually if escalated to the right channels you should receive the information you are looking for. You may have to accept that there is not too much information disclosed about how the detection worked or what triggers led to the detection, since such details are company confidential.
Actually it was already mentioned that the detection was not by any static pattern but due to behavioral analysis. If I (not being an expert) look at the Virus Total output I think that the file which was examined is not "empty", but it does a couple of things. It imports a couple of other libraries and functions, I supposed all (valid) stuff for an installer, especially capabilities for reading/writing registry entries (for example RegCreateKeyExW) and manipulating files (SHFileOperationW). Additionally - if I understand the initial post correctly - the executable wants to evaluate admin permissions (RequestExecutionLevel)
Such things are perfectly fine for a installer of a product, but also malware (obviously) makes use of such operations.
Without knowing what exactly "WIn32.Dropper" does I assume it uses similar techniques to infect a computer, e.g. gaining admin privileges, write files and registry records. An installer and malware might behave similar. If I now take an executable which performs nothing that we could identify as "wanted behaviour" I don't see a way for the engine to make a difference between good and bad. I would expect if you add more "good" code to this executable the detection will change, but without anything we can identify as "good" I am not surprised the file is blocked.
Every file we do not know is "suspicious" until it proves it is good.
I think the only chance to take this forward is to forget about an "empty installer" which triggers a detection. For the above reasons I (personally!) think that a file which has the capability to read/write to registry and file system, requests admin privileges but does not performance any operation that could be identified as "wanted" should be blocked. If I understood correctly there must be dozens of "real" applications which incorrectly trigger the same detection. We should collect such false positives and escalate them through support.
Yes I get your point and thank you for your detailed explanation. However you are missing one thing here which is the obvious. Forget about the empty installer, what about official NSIS setup that is being detected as a threat in the first place. On the other hand if all the other virus guards could simply scan the empty installer and recognises as safe, why can't mcafee?
However like you said, this is not the place to complaint about these, I truly hope an action will be taken sooner rather than later.
I have to agree with you tuchkina. I have faced the same problem when using nsis. truth is I use many programs and they are in nsis, Mcafee detects them "BehavesLike.Win32.Dropper.nh". i viewed your link and most other virus guards resulting as good yet mcafee acts differently. I really hope this will be fixed in no time.
in my environment (latest 7.4 version) there is no threat detected. GAM is active, also payload heuristics. ATD is connected to MWG. No system detects any threat.
- Whats the difference??
same for me. I think the issue is probably not with MWG but with the Engine itself. There is another thread which mentioned that a background scanner prevents access... since MWG has no background scanner it is probably with some endpoint product. Maybe the engine is called with different settings.
I have done a scan of official nsis installer which is located http://sourceforge.net/projects/nsis/files/NSIS%203%20Pre-release/3.0b1/nsis-3.0b1-setup.exe/downloa... Below is the results of the scan.
also tested this link, there is no threat detected by MWG.
Note, actually we don´t know how virustotal uses the McAfee engine.
We saw similar behavior with the McAfee Antimalware Engine where Virusscan, Virusscan for Storage or e-mail Gateway are using different "Entry Points" to the McAfee engine. This results in different detection rates (sometimes false/positives 🙂 )
From my side, i see virustotal results with caution.
VT just uses the basic engine and artemis scan - it does not use any of the memory protection, BOF, behavioural rules etc which come into play when something actually executes.
VT just answers the question "Does this look like something you've seen before?". Not, "If I tried running this on a real system, would you let me?"
i just wanted to demonstrate different ways how a McAfee engine could be used.
Perhaps VT does something different to MWG and therefore perhaps in this case the detection is different between VT and MWG.