Update: this seems to be affecting all PC's with version 10.1.0.168 of the agent. PC's with the earlier version are not affected.
Further update. PopUpEr.exe scanned by VirusTotal. 9 vendors including Symantec reporting this as a trojan. See URL below:
1 of 1 people found this helpful
This issue happens sometimes after upgrades to our software. New changes in the way it acts sets off pattern flags in the AV software. Unfortunately, we cannot control these patterns in 3rd party AV's
You'll want to mark those flags as safe and report the mis-diagnosis to your AV vendor. This is assuming that the core server has been scanned and reported as clean in regards to viruses.
Popuper.exe file is a part of the initial installation of the LDMS agent when we install some AMT components which read information from the BIOS through the OS.
Does that help?
So I have some good news and bad news:
The good news is that after submitting these files to Symantec, they did confirm that the detection was a false-positive and the files would be whitelisted in virus pattern files released after February 15th.
The bad news is that this morning (Feb 17th), after re-extracting Patch 3 and rescanning the LD folder, Symantec detected two new Trojan.Gen.8 files and deleted them both! The files deleted were:
We are having a lot of 2016.3 files that are getting quarantined by our FireAMP connector malware detection. One that caused me quite a bit of issues was the cba8 msi installer. I informed our account rep the other day and I'm going to send over the file info. For now I'm just white listing them in the application.
This is causing major issues in our organisation. There is a fair amount of resistance to the use of LANDESK and this is adding flames to the fire.
Update: Symantec whitelisted these files on Feb 18th. I've rescanned Patch3 this morning and no trojans or other infections have been detected.
1 of 1 people found this helpful
As was pointed out above, there's not much we can do. If we'd owned Symantec (/replace any other 3rd party AV vendor that runs into this issue), then we could do something about it. As it is, they're an independent content provider, and we have no reach in to them from that side.
From a "getting things sorted" side of things, you've done absolutely the right thing. As an affected customer (in this case - of Symantec's but the same applies with any other company), you've got a "legitimate" thing here that they need to support through their sustaining process. And pretty much every AV company I know has a "False Positive" process precisely because of issues like this (and they happen on a pretty regular basis).
If we approached Symantec on this (and replace "us" with "any affected software house" here, and Symantec with "the relevant AV vendor"), it'd be more of a "hey, we're not a customer. But there's this thing - could you do us a solid? Pretty please, with sugar on top?" type conversation.
It's a simple matter of "we're not a stake holder" / there's no binding agreement (legal contract, $$-s, renewal considerations) in that relationship, so there's no real motivation for them to do anything (other than possibly relying on the kidness of the person on the other end).
But even from a "just business math" point of view, any sustaining effort costs ... and since there's no maintenance $$-s coming from whichever software is being (mis-?)detected ... there's going to be time & effort (even if it's automated, there'll be an associated resource cost) which most businesses will be somewhat loathe to take on without there being some sort of agreement / maintenance / etc-factor involved.
So that's why we (/slash any other affected software company) don't have a lot of pull here in this sort of situation -- and all the power is with you guys as customers of the relevant AV product.
This doesn't mean that we're looking to teflon-shoulder this sort of issue away -- as long as we CAN help, we're happy to do so. It's just that in most cases, we (and pretty much any other software company) are not in any position to do so.
I hope this provides some insight into this particular catch-22 from our perspective?
As an aside, this is something semi-common with management software's (us and others). Reason for this is that we're running (by necessity) at VERY privileged levels, and thus heuristics & co will be extra-sensitive to any changes on our stuff. At the end of the day, the AV / heuristics is doing its intended job (albeit, not necessarily correctly) - it tries to protect you from something that has very privileged access, and based on its pattern files, it thinks that this is / may be "some bad guy", and thus this situation happens.
It'd be *NICE* if AV vendors would scan our / other management tools' legitimately released files & white-list them on their side, but that all comes back to the point of "well - it'd cost the AV vendor money/resources to do this, and they'd need to see valid ROI / benefit to them as a result" ... which in most cases, they don't stand to benefit as such. "Some other software company that isn't us is being detected incorrectly? OK ... well, unless it affects paying/active customers, what's it to us?" in essence.
That's essentially the crux of it - and why we can't do much. And it's just a matter of russian roulette whether you're affected (and I've seen false positives on "us" with pretty much every AV vendor over the years, so I'd be astonished if it doesn't happen to other management tools as well, due to the privileges involved.
Hope that helps?
Thanks PHoffmann. It's interesting to note that among the "major" players, Symantec are the only vendor recording these false positives.
I've checked the patch again this morning using Symantec's virus definition file dated Feb. 20th. The whitelisting seems OK, so we can start planning the roll-out of the latest agent.
Oh, they very much aren't "the only one". If it were so, that'd make life a lot easier.
It's all of them. Just usually at different times.
Whether you use(d) Sophos, Trend Micro, Symantec - even Kaspersky - ... they all have had false-positives on us and that's just stuff I've seen / dealt with over the time. No one's really excluded.
Comparably "minor" players have the same issues (IIRC, my first learning of the existence of Panda AV was based on a false-positive against us).
It's one of the reasons why I've been holding the opinion that pattern-based / traditional AV is essentially a dinosaur, and a HIPS / behaviour based security approach is they only sensible way to go. Especially given the sheer amount of "custom malware" flying around that won't usually be hit up by pattern-based stuff.
It's all part of the same security problem / conversation .
We're just getting an Install today and three of our scanning engines lit up like a Christmas tree, Bitdefender, Sophos and Mimecast. Virus total has also listed 10 or more AV vendors detecting Trojans.
Sure we can Whitelist with our various vendors, but surely there is some responsibility from Ivanti to do the same before releasing the patch? It doesn't take much to scan your files with various products, I am sure Ivanti can afford them! and we're not talking about even having to be customer, you can freely submit false positives to many of the scanning engines. If it lights up, time to contact the vendor to inform them of a false positive. Once given the all clear, perhaps then proceed to release the update. Signatures are shared between various AV solutions these days so I doubt it would take long to propagate. The burdan should not be completely placed on the customer to complete this task for you. This could cause significant delay to our install which is not acceptable.
I would agree that signature based AV solutions are getting a little old hat, but for many of us, this is what we're running for the time being.
My two cents.