NOD32 email detection misses what it otherwise catches <== why?

Discussion in 'ESET NOD32 Antivirus' started by plax, Dec 29, 2008.

Thread Status:
Not open for further replies.
  1. plax

    plax Registered Member

    Joined:
    Dec 29, 2008
    Posts:
    13
    Hello,

    Allow me to better explain. I'm using Outlook Express 6 on XP with the NOD32 threat detection element integrated and activated in OE. When I initially installed NOD32 over a month ago I performed a full on-demand scan. It found and quarantined 2 threat files. One was labeled as the "Perl/Shellbot.B trojan" and the other was labeled as "probably a variant of JS/Exploit.Blinker trojan". The former was a txt file that I pulled from a malicious shell account user's file structure on a unix server a while back, but had forgotten about. The latter is a windows-crashing htm document that I found somewhere years ago; I've kept it around to test anti-malware apps.

    I used to have a constantly updated copy of NAV 2004 Professional on this particular box and it never once alerted on the shellbot file. NOD32 caught both files right away during the on-demand scan, and it catches them fine when trying to access or move either file.

    The other day, I decided to restore these files from quarantine and disable NOD32 to send them to myself for an email protection test. Once sent, I re-enabled NOD32 and received the emails containing these test malware attachments. There was no alert from NOD32 for either one of them. It's only upon saving the attachment that NOD32 will alert and quarantine the files. The same is true if I rescan the emails after receiving them. Nothing.

    NOD32 has, however, been catching and auto-deleting multiple instances of the W32/Netsky.Q.worm upon receipt in OE.

    Does anyone have an idea that might explain this behavior?

    TIA
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Most likely it's a false positive triggered on the text file, maybe it was fixed in the mean time. If it's still detected, you can send it to samples[at]eset.com with "False positive - Perl/Shellbot.B trojan" in the subject.
     
  3. plax

    plax Registered Member

    Joined:
    Dec 29, 2008
    Posts:
    13
    That can't be it because this .txt file contains a Perl DDoS script and other malicious elements. AFAIK, it's no threat to Windows OS's, but it is a malicious file. I was told by eset phone support that the same mechanism that detects these files in the real-time monitoring for file activity and the on-demand scanning element is used in the email detection. If that's true then the files should be detected in all cases I'd think. And these are two completely different and unrelated malware files that are not being detected by the email scanning component of NOD32.

    I'm going to completely uninstall v3.0.672.0 and install v3.0.684.0 and see if it makes any difference.

    Any further thoughts will be appreciated.
     
  4. plax

    plax Registered Member

    Joined:
    Dec 29, 2008
    Posts:
    13
    My uninstall of .672 and installation of .684 made no difference. The aforementioned malware files attached to test messages are still ignored upon being received and when rescanned. Also, the 'Infected Items' folder (initially installed in the OE folders tree by NOD32 as a sub-folder under the 'Deleted Items' folder) was not created with the installation of version .684 today for some reason. None of this makes me feel very secure email-wise.

    Any ideas about any of this from anyone? I'd kind of like to know that NOD32 is effectively protecting my email.

    Thanks
     
  5. agoretsky

    agoretsky Eset Staff Account

    Joined:
    Apr 4, 2006
    Posts:
    4,032
    Location:
    California
    Hello,

    Is the problem still occurring? If so, can you tell me which version of the virus signature database is installed with your copy of the software?

    Regards,

    Aryeh Goretsky
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    The best would be to provide the files to customer care so that they can try to reproduce the issue.
     
Thread Status:
Not open for further replies.