-AM-

I was too busy of late to deal with this, but having read your post again, let me ask: Marcos, do you understand what we currently need? The last thing needed at the moment is various marketing fluff with terms like "vulnerability shield" tossed around without relevant technical explanation -- there's no way we're buying something else from ESET before pending questions are clarified, so please address them with due diligence. Firm understanding of what are the real technical differences between your antivirus and other products is required, and so far there are many questions which you avoid answering, with portions of your posts only adding confusion (true for the last post as well, more on it below). I don't think I mixed anything up. The page doesn't make it clear which feature refers to what product, and there's little technical clarification elsewhere, but some docs clarify that "Smart Security" is, in fact, antivirus plus parental control etc. (more on it below). I don't know what "vulnerability shield" really means, as the description is very brief (I looked here: hxxp://www.eset.com/int/about/technology/). If there's a proper technical description on your site somewhere, please provide the link. Besides, according to hxxp://www.eset.com/us/home/windows-antivirus/ the difference between "Smart Security" and the antivirus is four extra modules: - anti-theft, - personal firewall, - parental control, - antispam. I'm not too interested in antispam, parental control or anti-theft, and as I said, firewall is a firewall -- if the one in Smart Security is configured to allow inbound traffic to SMB/NBT ports, then the story with Conficker will be exactly the same as with Endpoint (NOD32) antivirus and any other firewall configured in the same manner -- is my understanding in this regard correct? IMO, a firewall from an antivirus vendor worth paying for is one which is configured by default in a way that doesn't simply block some ports, but instead reliably blocks malware while allowing non-malicious code to connect to open ports. With regularly updated rule database, ability to both manually add rules and adjust the ones in the database (e.g. whenever some in-house software gets broken by vendor's rules), and absolutely zero breaches and false positives for such well-known threats like Conficker. I'm not sure if this is the case with the firewall module in your products. At least from your pages it looks like a simple point-and-click software which allows to tick options like "file sharing" etc. hxxp://www.eset.com/us/home/products/cyber-security-pro/. If that's not so, please let me know where I can get details about ESET signature/rule database for the firewall module, some reliable data on zero breach and false positives for popular malware, and other technical stuff. Further, on p. 6 of the user's guide hxxp://download.eset.com/manuals/eset_eav_7_userguide_enu.pdf/, I read that "vulnerability shield" is, in fact, part of the antivirus product, so I understand it is included in Smart Security simply as part of its antivirus module? Is that correct? And, btw, RDP has got nothing to do with Conficker at all; the latter spreads by means of RPC which, in turn, uses services on TCP ports 139 and 445. Marcos, you don't need to tell me that your antivirus doesn't do anything about Conficker until it has executed and dropped the payload -- this is the reason I posted here with my findings in the first place, all right? Besides, some threats are certainly detected at network level, e.g. when I have a go at downloading hxxp://www.eicar.org/download/eicar.com the antivirus won't allow me do so, resetting the connection. So the question stands, is such operation of your antivirus intentional (by design)? In other words, does Endpoint (NOD32) still fail to detect Conficker before it executes the payload, or it doesn't even try to detect it? How can I be more specific about it? Is it a failure at detection, or do your programmers think for some reason that checking what can arrive by http is OK, but checking traffic traveling over services on ports 139 and 445 that Conficker uses is not necessary? Given such behavior of your product, there's simply no confidence as to what kind of protection Endpoint (NOD32) ensures, as there is no detailed information regarding the way it deals with protocols and ports. And I don't want to rely on a black horse; I would prefer to know when and how I'm protected by your antivirus. Are you sure about it, Marcos? I have to say I have a different impression. If that was the case, ESET could have made a hell of a good publicity out of it bashing out press releases, whitepapers, blog posts etc. with some hard data to show and prove that its customers -- the ones without firewall blocking inbound SMB/NBT traffic and MS's security patches installed -- were indeed protected by ESET on day 0 of the attack. And if it even happened without "specific detection", as you say, which apparently means no signature db update or any other ad hoc communication with the host running your software, then ESET software engineers arguably deserve higher credit than certain Nobel laureates in my opinion! But I see nothing of this sort. What I do see is ESET finally addressing Conficker issue two months after the outbreak and saying how complex and sophisticated the worm is to detect and remove compared to other malware, hxxp://www.eset.com/int/about/press/articles/article/press-conficker-continues/ or that ESET were busy working on more effective ways to detect and clean it, that dealing with the worm required creating specific algorithms etc. hxxp://www.welivesecurity.com/2009/01/23/confounding-conficker/ and that as a solution, ESET recommended - installing MS security patches, (!) - downloading Conficker cleanup tool and... - upgrading to a new version of Smart Security or NOD32 (!!!) hxxp://www.eset.com/int/about/press/articles/article/press-conficker-removal-april-1/ On another interesting note, December 2008 issue of ESET Global Threat Report is not available: hxxp://www.eset.com/us/resource/papers/reports/ Why? Was the Conficker embarassment such that December report was removed from your site (or, perhaps, not even written)? Guess the detection "from the very first moment", as you say, was so good, that it not only shot up to the top ten in your chart, but landed pretty high in there. The credit for being the first antivirus vendor to raise the alert flag goes, as far as I can tell, to Symantec who did so on November 21 when some other vendors were in denial of any anomalies in the traffic! Conficker got caught in one of their honeypots, which it didn't blacklist for some reason for all of its sophistication. Whether it was an oversight on the part of worm's authors, or should be attributed to Symantec's agressiveness in deployment of new honeynets or changing addresses of existing ones on a regular basis, I don't know. hxxp://www.computerworld.com/s/article/9121198/Symantec_sees_spike_in_dangerous_Microsoft_attacks?taxonomyId=89 I wouldn't care much to go in detail here, but couldn't help providing some links after reading how your antivirus was able to detect it "from the very first moment the author wrote it" without any specific detection. Makes me smile, but who knows, some people reading that could buy it. So please clarify all pending questions -- we have to make decisions, and I need true and detailed technical information about your products.

Thanks for taking time to post Marcos, but this is not what I asked about, and adds even more confusion. If my question was not well-formulated, or the logs I provided aren't clear or complete enough -- my apologies, I'll try to be more specific in this post. I'm not sure why you bring into view Endpoint Security at all with its firewall, antispam and Web control extra modules compared to Endpoint (NOD32) antivirus. The firewall's no problem at all; even the one in Win XP does just fine wrt unsolicited SMB/NBT traffic to open ports. Below are excerpts from traces I collected today and a week ago from what can be considered a "Conficker stress test", with our little hero hammering a PC every few seconds while being blocked by the firewall: 2014-02-07 10:27:04 DROP TCP agressor victim 1377 445 48 S 1460499284 0 65535 - - - RECEIVE 2014-02-07 10:27:05 DROP TCP agressor victim 1378 139 48 S 3832058908 0 65535 - - - RECEIVE 2014-02-07 10:27:05 DROP TCP agressor victim 63099 139 48 S 4094564635 0 65535 - - - RECEIVE 2014-01-31 19:23:47 DROP TCP agressor victim 62992 139 48 S 305155477 0 65535 - - - RECEIVE 2014-01-31 19:23:50 DROP TCP agressor victim 4693 139 48 S 3452938967 0 65535 - - - RECEIVE 2014-01-31 19:23:52 DROP TCP agressor victim 4692 445 48 S 1065901074 0 65535 - - - RECEIVE 2014-01-31 19:23:55 DROP TCP agressor victim 4692 445 48 S 1065901074 0 65535 - - - RECEIVE 2014-01-31 19:23:56 DROP TCP agressor victim 4693 139 48 S 3452938967 0 65535 - - - RECEIVE So the firewall's fine, thank you -- and you probably know it full well. But the antivirus is not. The whole point of paying for a memory-resident antivirus with advanced heuristics, "anti-stealth" tech, "smart" or "DNA-based" generic signatures (and associated memory and CPU overheads) and Internet protection which ESET Endpoint (NOD32) antivirus claims to be according to this -- as opposed to a simple disk scanner -- is to make sure that payload of incoming traffic which makes it through the firewall is checked against signature database and analyzed using all of the "DNA-based" signature magic, before it gets the opportunity for execution. Not after -- which is the way ESET Endpoint really works. Which brings me to the question I asked: is such behavior of your antivirus intentional (by design), or is it because Endpoint (NOD32) is simply unable to detect the worm? If the former is the case, then when does it check the content before execution and when it doesn't? Where can I find it documented? Since I'll be forced to rely on your antivirus for some time, I need to know. If the latter is the case, then what are all these advanced heuristics, "anti-stealth" tech, "DNA-based" generic signatures worth, if your antivirus can't handle a worm from 2008 it has had in its database for over 5 years now?! Don't get me wrong -- I'm not having fun at you. Conficker's inner workings were described in good enough detail, so that a mod which aims to not add a scheduled task, but do some real harm as soon as it gets control, will certainly succeed when the PC is "protected" by your antivirus. Back to ESET Security -- why do you mention it? According to your product feature page, the difference is antispam and firewall modules; I don't even see the "web control" feature you mentioned. If it's another way to refer to remote management, it's in both packages according to the page (so which is correct?). Does Security have a different antivirus module, perhaps more advanced than the one in ESET Endpoint (NOD32)? Or are they identical, and there will be the same story as soon as the firewall is configured to allow inbound SMB/NBT connections? And the way your software handles a failure at doing its job is totally misleading to an average person. In a situation like this, proper antivirus software instead of reporting success, should first and foremost signal loud and clear breach of protection and perform fs and registry check looking for changes, reporting them, and reverting them whenever possible. Or at least inform the user of the consequences of missed attack if not designed or unable to do what it should. As far as I can tell from my experience and browsing help, Endpoint does absolutely nothing of the above. No breach alert -- unless one learns to treat its "cleaned by deletion -- isolated" success message as such, no fs/registry checks whatsoever -- implanted job quietly sits there smiling, and no user warning that he's on his own to look for changes as Endpoint doesn't do it! So please, don't waste more time posting what's not needed here or evading the issue. Before my company spends more money on crapware that doesn't pass a basic sniff test, I'd like to get some facts straight and be corrected in case I happen to be wrong on some account. I don't want more surprizes like this one.

Hi, yesterday I reported that ESET Endpoint -- my employer's antivirus of choice -- is not only insecure, since it doesn't protect from RCE vulnerabilities, but creates an illusion of safety by logging the threat as cleaned up by deleting and "isolated". I'm a little surprized to not see any response from ESET, so posting here now in case my selection of the section to post was wrong, and since among other things I would really like to clarify: considering that the software can't deal properly even with a worm from 2008, is ESET Endpoint's lack of RCE protection intentional (by design) and won't be fixed? Or will it? Please clarify, thanks.

ESET Endpoint (NOD32) is totally insecure it seems. Tech details are in the logs at the end. In brief, ESET not only allows remote code execution, but informs the user that the virus was cleaned by deleting. Formally it's true, since it does delete the dropped dll indeed, and quite fast, but the problem is, only *after* the code executes. So in a way it's worse than insecure -- it creates a false illusion of safety while security of the PC in question is totally compromised. What you see in the attached log happens on a corporate Windows XP box protected by ESET Endpoint set in max security mode and attacked by a worm which was detected back in 2008, approximately a month after relevant vulnerabilty was described and patched by Microsoft. So 5+ years down the road, ESET Endpoint (NOD32) is absolutely useless against a whole class of malware, considering that Conficker was described in detail a long time ago. Funnily enough, ESET seems to fare very well against the competition, according to hxxp://www.eset.com/us/business/whyeset/compare/. I don't have any anti-ESET bias, nor do I come from a competitor's camp, it's just because my company chose it for protection. Actually, seeing that ESET is based in Bratislava, I'm somewhat torn apart by emotions, as many years ago I had a pretty good time as a visiting grad student to Bratislava tech staying in that Stalinesque Mlada Garda hostel. Good memories. ESET log says the worm was cleaned by deleting and isolated: 04.02.2014 11:52:39 Защита в режиме реального времени файл C:\WINDOWS\System32\vxwmpkj.mu Win32/Conficker.AA червь очищен удалением - изолирован NT AUTHORITY\SYSTEM Событие произошло в новом файле, созданном следующим приложением: C:\WINDOWS\System32\ntoskrnl.exe. TCP log shows relevant connections: 2014-02-04 11:52:39 OPEN-INBOUND TCP offender thisbox 2803 139 - - - - - - - - - 2014-02-04 11:52:39 OPEN-INBOUND TCP offender thisbox 62585 139 - - - - - - - - - 2014-02-04 11:52:39 CLOSE TCP thisbox offender 139 62585 - - - - - - - - - 2014-02-04 11:52:50 CLOSE TCP thisbox offender 139 2803 - - - - - - - - - TCP stats show related traffic surge of ca. 200 segments, with a bump of est. connections by 3, and active/passive by 2. "02/04/2014 11:52:39.231" "0" "2" "2812" "1361" "6" "87" "0" "0" "0" "02/04/2014 11:52:40.232" "226" "5" "2814" "1363" "6" "88" "140" "86" "0" "02/04/2014 11:52:41.247" "0" "5" "2814" "1363" "6" "88" "0" "0" "0" Now, while certainly deleted by ESET, the deletion takes place *after* the worm executes and creates a scheduled task for its daily execution at the nearest-back whole hour (pardon my crippled English): C:\WINDOWS\Tasks>dir at56.job Том в устройстве C не имеет метки. Серийный номер тома: 18EB-C6FF Содержимое папки C:\WINDOWS\Tasks 04.02.2014 11:52 348 At56.job 1 файлов 348 байт C:\WINDOWS\Tasks>at 56 Код задачи: 56 Статус: OK Дата: Каждый M T W Th F S Su Время дня: 11:00 Интерактивная: No Команда: rundll32.exe vxwmpkj.mu,avfbvla --- occurrence #2 --- ESET log: 04.02.2014 13:15:38 Защита в режиме реального времени файл C:\WINDOWS\System32\vxwmpkj.mu Win32/Conficker.AA червь очищен удалением - изолирован NT AUTHORITY\SYSTEM Событие произошло в новом файле, созданном следующим приложением: C:\WINDOWS\System32\ntoskrnl.exe. TCP log: 2014-02-04 13:15:38 OPEN-INBOUND TCP offender thisbox 3985 139 - - - - - - - - - 2014-02-04 13:15:38 OPEN-INBOUND TCP offender thisbox 63163 139 - - - - - - - - - 2014-02-04 13:15:38 CLOSE TCP thisbox offender 139 63163 - - - - - - - - - 2014-02-04 13:15:50 CLOSE TCP thisbox offender 139 3985 - - - - - - - - - TCP stats are very similar: 222 segments, est. conn. up by 3, active and passive by 2. "02/04/2014 13:15:38.658" "0" "3" "3876" "1743" "19" "93" "0" "0" "0" "02/04/2014 13:15:39.658" "222" "6" "3878" "1745" "19" "94" "139" "82" "0" "02/04/2014 13:15:40.658" "0" "6" "3878" "1745" "19" "94" "0" "0" "0" C:\WINDOWS\Tasks>dir at57.job /t:c Том в устройстве C не имеет метки. Серийный номер тома: 18EB-C6FF Содержимое папки C:\WINDOWS\Tasks 04.02.2014 13:15 348 At57.job 1 файлов 348 байт at57.job timestamped 13:15:39.x C:\WINDOWS\Tasks>at 57 Код задачи: 57 Статус: OK Дата: Каждый M T W Th F S Su Время дня: 13:00 Интерактивная: No Команда: rundll32.exe vxwmpkj.mu,rdwhbto --- occurrence #3 --- ESET log: 04.02.2014 14:42:20 Защита в режиме реального времени файл C:\WINDOWS\System32\vxwmpkj.mu Win32/Conficker.AA червь очищен удалением - изолирован NT AUTHORITY\SYSTEM Событие произошло в новом файле, созданном следующим приложением: C:\WINDOWS\System32\ntoskrnl.exe. TCP log: 2014-02-04 14:42:19 OPEN-INBOUND TCP offender thisbox 62039 139 - - - - - - - - - 2014-02-04 14:42:19 OPEN-INBOUND TCP offender thisbox 2381 139 - - - - - - - - - 2014-02-04 14:42:19 CLOSE TCP thisbox offender 139 62039 - - - - - - - - - 2014-02-04 14:42:26 CLOSE TCP thisbox offender 139 2381 - - - - - - - - - TCP stats are the same as above: "02/04/2014 14:42:19.013" "0" "0" "5253" "2278" "30" "113" "0" "0" "0" "02/04/2014 14:42:20.013" "206" "3" "5255" "2280" "30" "114" "131" "74" "0" C:\WINDOWS\Tasks>dir at58.job /t:c Том в устройстве C не имеет метки. Серийный номер тома: 18EB-C6FF Содержимое папки C:\WINDOWS\Tasks 04.02.2014 14:42 350 At58.job 1 файлов 350 байт C:\WINDOWS\Tasks>at 58 Код задачи: 58 Статус: OK Дата: Каждый M T W Th F S Su Время дня: 14:00 Интерактивная: No Команда: rundll32.exe vxwmpkj.mu,sewpthvz