Update 3918 False Positive Win32/Kriptik.JX trojan

Yes your right switching to decaf will clearly ease the pain of having 100+ clients affected by this mess 1st thing on a Monday morning and ease away all our woes.. how far removed from the bigger picture can you get making a statement like that.

My problem here is as follows:

1) How did this problem get thru testing.
2) The response time of a fix (still waiting)
3) The seemingly useless function of Eset Remote Console to manage your environment to sort a mess of this magnitude out.
4) Confidence in this product that something like this won't happen again.

All these points refer to a business corporate environment with lots of clients where time is money and server functions that rely on some of the services affected being up the creek.

Put yourself in the shoes of someone who has this installed in a Business with multiple clients (not just you and your buddy) and then rethink how you wouldn't be 'flying off the handle' & 'screaming about this being a huge screw up'

 

Please advise us? We have a smallish network and several machines (and servers) were affected by this. I currently have the following information about the system and am told that no further updates are available. Where and how can I get this heuristics update? The heuristics build I have is built today, but is still the old version. It is critical that I get this problem fixed, as not only are we affected, but several of our customers are reporting problems, too.


NOD32 antivirus system information
Virus signature database version: 3919 (20090309)
Dated: 09 March 2009
Virus signature database build: 15299

Information on other scanner support parts
Advanced heuristics module version: 1091 (20090309)
Advanced heuristics module build: 1200
Internet filter version: 1.002 (2004070
Internet filter build: 1013
Archive support module version: 1082 (20090213)
Archive support module build version: 1224

Information about installed components
NOD32 For Windows NT/2000/XP/2003/Vista/x64 - Administrative tools
Version: 2.70.32
NOD32 For Windows NT/2000/XP/2003/Vista/x64 - Base
Version: 2.70.32
NOD32 For Windows NT/2000/XP/2003/Vista/x64 - Internet support
Version: 2.70.32
NOD32 for Windows NT/2000/XP/2003/Vista/x64 - Standard component
Version: 2.70.32

Operating system information
Platform: Microsoft Windows Server 2003 R2
Version: 5.2.3790 Service Pack 1
Version of common control components: 5.82.3790
RAM: 512 MB
Processor: Intel(R) Xeon(TM) CPU 2.80GHz (2800 MHz)

 

Something like this was happen with v3 too, along with AH module update (just like now)...and messed up my Adobe CS3 applications.

 

On one of our servers it has been restored automatically already but the service needed to be started manually.

Note: on workstations this service (msdtc: Distributed Transaction coordinator) is most probably not used, so don't panic!

 

Just for those using Eset 2.7 (or XMon/Eset for Exchange which is currently 2.7), don't worry about the Heuristic module version.

 

My 'decaf' statement was not meant to trivialize your problems, and I am not "removed from the bigger picture" as I manage a few client banks totaling 700 machines, just not with NOD. Most could be baremetal restored for this without trouble or much time, as we do such regularly, but I do understand if your clients cannot. It was directed at the people whining about subscriptions and finger pointing more than those seeking legitimate assistance.

Something similar to this has happened not long ago with NOD, and I had suggested then that they implement a clientside dialog notification for important info, such as this... to inform admins and users in a timely fashion that there could be a problem, and, that it is being worked on. We should not be forced to double check things on their forums before implementing infrastructure wide fixes, such as a baremetal or rollback.

This type of info should, at the very least, be on the main, or off the main page of the site. At least for a few days to inform customers and admins of the issues, and that a fix is implemented or forthcoming.

In fact, I expected to see quite a larger flurry of postings here regarding this issue in the forums by now.

I like NOD32... I use it on my home machines vs. our enterprise based solution, which has a less friendly licensing for home use, and because NOD plays better with CPU hungry environments... such as personal use machines, gaming, and less pointed/structured computing. I also like that it is snappier at finding zeroday and oddball stuff... usually faster than most competitors. Not to mention rarely targeted by malware.

However, this lack of interaction for important information to the users is upsetting. You need to hunt for the forum link on the site, and the "false positive" link is only now showing on the "Recent Articles" of the knowledgebase... one small link. I understand trying to not point out mistakes in neon, but it is just as important to alert users quickly before they do things like shut down an entire department that will take several hours to clear, when the problem was known to be a simple false positive in such a short amount of time.

On the flip side, this was from having a rather touchy, additional feature of advanced heuristics enabled which may or may not be something you want hair triggering on huge banks of client machines. Though I am surprised if the enterprise console doesn't also have a mass quarantine/replace control. That should certainly be implemented.

I've said it before, the bulk of users will understand and appreciate being informed blatantly, rather than thinking this could be swept under the rug.

 

Virus Defs 3920 are out, which it appears auto-unquarantine the false positives. Hopefully for most, the time beween update 3918 and 3920 is short enough not to have even noticed.

Be sure you've checked your quarantine and updated to 3920 before rebooting anyting though ;-)

 

You are not alone.

Luckily enough, some of us don't allow NOD32 to quarantine willy-nilly, so all I had to do was tell it "not for me, thanks."

Even so, someone must've been asleep at the switch to add these two files to the database.

 

Four times bitten, forever shy. We only block access. No delete, no fix, no clean, no quarantine. If you were bitten by this one, you might want to change your settings as this will happen from time to time no matter your AV vendor.

 

The files weren't added to any database. They were accidentally getting flagged by the heuristics scan.

Here's what killed me with the whole thing. Our systems kept restoring these files, and NOD32 kept quarantining them (and emailing us each time it did it). pretty much made all of my system admin's email unusable. Luckily I saw it happening right away when my blackberry started filling up, and I was able to redownload the fixed 3918 virus defs and push those out. However, having my AV solution kill my email isn't very fun. Guess it's time to restrict it.

 

What settings are you changing? Is it simply the "cleaning" item on each of the set up menus; ie from "strict" back to "no cleaning" for each menu, and hence always alert with available actions?

 

@Whitewlf, Fair enough this morning was a tad stressful for us here and I was how can i say... a bit wound up! this problem took down our credit card processing which takes place (MSQVC.exe being quarantined) using the Microsoft Message Queuing service. We lost 20 walk up customers that i know about to other competitors by simply not being able to provide an automated service, not great in the current climate when you have a piece of software designed to protect your business which actually loses you money when the vendor screws up..

Believe it or not the Remote console has no such feature to handle these types of situations it's a real shame as the product is excellent but the 'Centralised Management' aspect has a real lack of Active Directory integration and feels totally underdeveloped compared with ESET's competitors... that said i think recent events has made me realise i need to tweak my settings down but that just goes against the grain of having Optimal protection and something i'll have to accept.

I wholely agree with your points regarding notification as i believe the way ESET communicated this problem out was appalling. Not even worthy of a Sticky on the forum, nothing on the main ESET Site and no desktop notification service for Admins, I accept they don't necessarily want potential new customers being put off seeing Issues on their websites highlighted in such a way but what's worse losing a new customer (even tho it could be percieved as a positive in that ESET openly communicate to it's users) or making the countless existing userbase feel it may be time to look at another vendor as they are effectively resarching ESET problem themselves..

Perhaps the internal fallout within ESET will never be known but it appears from remarks on this forum the confidence level in the ESET from customers has taken a bit of a hit and it would be nice to see at the very least a RCA report to restore a bit of faith.

 

Oh I sympathize with your view but it could quite easily be worse. I respect the fact they had a representative come here and admit the problem, give us status updates, when it will be fixed, that the files will be restored.

Seagate anyone? Deleting/locking all threads mentioning a problem.

If you look to the top, there is stickies for past problems being announced (3901)

I'm sad this passed the testing stage, but happy with how quickly it has been addressed, at least it's not an adobe or a microsoft.

 

Funky, i think we'll have to agree to disagree on that one.
I believe alot more could and should have been done and in a quicker timeframe especially in the communications department. It's great there was a sticky for 3901 but why wasn't there one in this instance? that's just plain inconsistent.
Mistakes will always be made from time to time, I appreciate that and i'm not naive to think we live in a perfect world but what i saw from ESET today in how they deal with a problem like this did not impress me and fill me with confidence should anything like this happen again, i'm just being honest speaking as a corporate customer/user.
I do as i have said believe ESET to be a great bit of software it has just made me totally rethink how I use this program and blindly rely on it, one thing i'm definately going to do is have the updates go to a small group of test machines 1st for a few hours before the updates replicate across the rest of the mirrors i have setup to the majority of the clients, at least that way i can catch any problematic updates before it spreads onto Servers and other important machines within my environment.
Appreciate the staff allow people to vent on here and i've tried to keep it constructive without the fear of deleting post's etc it's just been one of those days and reiterates why like Bob Geldof 'I don't like Mondays!'

 

We have added more information about this to our news page here: http://kb.eset.com/esetkb/index?page=content&id=NEWS9

A Knowledgebase article describing the issue is here: http://kb.eset.com/esetkb/index?page=content&id=SOLN2181

We apologize for problems caused by this issue. If further help from our Customer Care Engineers is needed, please call Toll Free. +1 (866) 343-ESET [3738] or Tel. +1 (619) 876-5400, or through the support request page here: http://www.eset.com/support/contact.php


Thank you,
Richard

 

Or is it another setting or combo of settings? Anyone at all..??

 

1st of all you are being naive because everybody with at least a little knowledge about the OS underneath would have known that it was not a crucial (msdtc) executable, certainly not on Desktop computers.

You could argue that it could have been svchost.exe or winlogon.exe or any other crucial one but this wasn't the case.
So don't get all angry about something that actually didn't happen (some major incident).

 

@Adramalech, perhaps it would be better if you had read the whole thread as 'everybody with at least a little knowledge' of the incident would have known it did not just affect the MS Distributed transaction coordinator service. In my case the biggest problem was the MSQVC (MS Message queue service) it also quarantined other files but since it seems you haven't read throughly i don't see the point listing them.
I also beg to differ on it's impact as it had a negative effect in our business environment and i stated my honest assesment on how i believe it was handled and the lack of centralised management the remote console offers when dealing with such problems, this was purely my own opinion and something i believe we are all entitled to. ESET may even call it 'Feedback' which is something all vendors welcome.

If it didn't affect you on a similar scale fair enough but that's not to say that was the case with all users especially in a business environment, people also use this product on Servers too so you pointing out the obvious in relation to what service is not critical on Desktops doesn't really hold much substance to the problems that were caused.

 

I'm running it on servers too, even with Message queuing installed and I wasn't effected.
And yes, I read through the whole topic but my opinion still stands that this was afar from being a major incident.

Let's not forget about it that it took 10 minutes(!) to remove the signature and the fix was full-automatic, apart from starting the related services which is a joke for a skilled admin.

But thanks for the feedback.
My 2 cents

 

Adramalech i appreciate what you are saying but it caused our credit card proccessing payment service to fail as this utilises Message Queueing thus losing customers from not being able to provide an automated service, i wholely accept this wasnt a 'biggy' for all but it was a problem for some who have services based on the files that were quarantined. I don't believe i've ever said 'Major' incident (i know the difference) but i cannot get away from the fact that ESET's error negatively impacted our business so i can understand why our opinions on the whole differ there.
It may have taken 10 minutes for them to stop the update (which is a good thing) but it took hours for the fix to be implemented to automatically remove the infected files from quarantine by which time i had already taken manual steps to resolve on the server estate. I thought the communication of the update & what they were doing was sparce and they could have updated people more than what they did but that as i say is purely my opinion and i guess people have different levels of expectation when it comes to incident handling.
Yes manually it could be sorted but when you have to do this across 20+ servers it's far from ideal when something hasn't gone thru quality control correctly I'd imagine we can agree on that?

I also think you can probably see my point that with what's happened it's food for thought had this been a major problem across the board how little you can do from the ERAC centrally to rollback updates/mass un-quarratine falsely infected files?

The dust is settled now and it was good to see the ESET Mod's add a sticky on the forum and link a knowlege base article but feedback wise I'd like to see more features in the next release of the ERAC to deal with these scenarios.