Email Viruses, NOD32v2 ScanLog Questions

Note: As of Thursday 5 February, approximately 7:25 p.m. California time, 03:25 (a.m.) GMT or Zulu time, I have edited the first and last of my messages in this thread. The edits are in boldface.

An InDepthAnalysis of my wife's computer, and then later another context menu scan of her email folder, turned up numerous trojan infected emails, presumably in email attachments. I am having trouble figuring out how to use the Scanning Log to delete the infected emails.

A P.S. Background, at the end of this message, lists the actual trojans found. The email program is Mozilla SeaMonkey, a descendant of the Mozilla Suite (think Firefox and Thunderbird in one program), which uses POP3. The operating system is Windows 2000 Sp4.

Question 1) Why didn't NOD32 2.7.32 catch these threats (described below) when the email was being downloaded? Is there some NOD32 setting I have missed? (In the past, NOD32 has caught email threats as they were downloaded.)

Question 2) The scan log reports the folder containing each entry, followed by:
>>MBOX >>mailnnn.eml >>MIME >> NameOfZipOrRarFile, followed by the threat's filename (e.g. jolie.exe or film.scr) and finally the name of the trojan, where "nnn" is a three digit number as low as 003 and as high as 911. The numbers are not in order. And using either SeaMonkey or Windows Explorer, I cannot find any email numbers. A sample scan log entry is the following:
path to SeaMonkey Mail initial folder, then (with xxxxxxxx being a set of random numbers and characters)
\xxxxxxxx.slt\Mail\pop.redshift.com\Inbox >>MBOX >>mail093.eml >>MIME >>jolie.zip >>ZIP >>jolie.exe - Win32/Wigon.EX trojan .

How can I use the scan log to determine which emails ought to be deleted?

I ask that because during the InDepthAnalysis, the Threat Found! box that appeared as each threat appeared in the scan list had the following Available actions: Leave, Clean, Rename, Delete, Replace. But except for a few threats that I could and did delete (not included in the threat descriptions below, which came from the later Context Menu scan), Leave was the only available choice --- the others all were greyed out. Why, I know not.

Nevertheless, the box did contain statements that "The file can be deleted. It is strongly recommended that you back up any crucial data before you proceed. Cleaning of archive cannot be performed." Before the context menu scan, I had backed up my wife's email (using Windows Explorer to copy it to a separate folder), but how to delete the file (message) containing the trojan is a complete mystery to me.

3) I set up NOD32 v2 several years ago, and now I can't remember or find out (although I did explore the Help) how to make sure that the Context Menu profile is using the same stringent settings as the InDepthAnalysis. Did the layout of those profile settings change between an earlier NOD32 v2.x and the current v2.70.32?

4) Should I temporarily stop worrying about deleting the infected emails, and go ahead and uninstall NOD32 v2.7 (using its own uninstall routine rather than Windows Ann/Remove Programs) and then install NOD32 v3.0.684, in hopes that its more modern scan log would facilitate deleting infected emails?

Thanks for any help.

Roger Folsom
________________________________________________________________

P.S. BACKGROUND
In preparation for installation of NOD32 v3.0.684, I scanned my wife's computer using her installed NOD32 v2.70.32.

To my surprise, when I did an InDepthAnalysis scan of her computer (that's the only type of demand scan we do), it turned up numerous trojans in her SeaMonkey email, plus additional part000.txt and part001.txt or .htm "error occurred while reading archive" reports.

We've been using NOD32 v2.x since 2005 or maybe earlier, and it has caught serious viruses in our incoming email on numerous occasions.

But never before has an InDepthAnalysis scan turned up anything, except one false positive on my computer years ago (NOD32 hadn't heard of WordPerfect's now-deceased Envoy utility).

Given that the InDepthAnalysis was finding threats in my wife's email, I interrupted it, deleted the emails in her trash and junk (spam) mail, and did a context menu scan on her email folder. That turned up a total of six different trojans.

Trojans Detected

The jolie and xjolie.zip containing the Win32/Wigon.BZ or .CB, trojans;

The Angelina_Jolie.rar containing "probably a variant of Win32/TrojanDownloader.SmallTrojan" (my understanding is that the "probably" means that NOD32 didn't have a signature for this trojan, but made a heuristic judgment);

The film.zip containing the Win32/Wigon.EH or .EX trojans;

The UPS_INVOICE_187271.zip containing the Win32/SpyAgent.NHS trojan.

I have read "Infected ~ Virus / Trojan Detection ~ Dealing with New Samples," at
https://www.wilderssecurity.com/showthread.php?t=178177
but I don't think it deals with the trojans on my wife's computer.

 

1, first of all, I'd carry out a test with eicar to see if it's actually intercepted by the POP3 scanner

2, v2 detects less malware than v3/v4, but I don't assume that would be the case of email threats.

3, emails in mailboxes (dbx, mbx files) can only be deleted manually from within the appropriate email client. The scan log should show additional details about infected email, such as the sender, date of sending, subject, etc.

 

Marcos:

Thank you for your very useful reply.

Your point 2 was indirectly useful, because I thought that Nod2 v3's advantages (compared to v2) were primarily its much less chaotic interface. So I'm now more motivated to find the time to upgrade to v3.

Re your point 1: Eicar was brand new to me. After a quick Google search, I found eicar's home page at
http://www.eicar.org/anti_virus_test_file.htm
and found four test file versions: eicar.com, eicar.com.txt, eicar_com.zip and eicarcom2.zip. I downloaded each in turn. For eicar.com, NOD32v2 gave me its standard red virus warning box and quarantined it. For remaining three NOD32v2 did NOT immediately give me the red warning box.

Downloading eicar.com.txt simply opened the string X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* in place of the eicar home page; my backbutton took me back to eicar's home page. I don't know what to make of that result (although Wikipedia did "explain" that that string is what the file contains).

The last two files, eicar_com.zip and eicarcom2.zip gave me no warning so I saved them to my desktop. Winzip opened them with no warning, but when I tried to execute them from within Winzip I got a Winzip warning. When I ignored that Winzip warning and executed their contents anyway, NOD32 came up with its red warning box and quarantined them.

Apparently, when downloading a zipped file, my (and my wife's) NOD32v2 does not check its executable file contents until the executable file is executed. So I'm guessing it doesn't check the contents of email zipped attachments either.

However, when I do an InDepthAnalysis scan, I know I set it (long ago) to check within attachments, although as I write this I am within a Restricted User (i.e. Limited) User account and can't access those settings. But the evidence from the demand scan that has raised this issue is that my InDepthAnalysis scan does look within zip (and also rar and whatever other similar choices were available) files.

I got that same capability to work for Context Menu scans (same evidence as in preceding paragraph).

Re your point 3: I described my scan log entries completely. I don't know what you mean by "mailbox" (I never heard of either dbx or mbx; my scan log entries all included "MBOX"), but in any case in Mozilla SeaMonkey (I don't know about Mozilla Thunderbird), I can guarantee you that my NOD32v2 scan log does not mention any of the following: sender, date of sending, subject, etc.

Also, I did another context menu scan but this time it was instructed to list all of the files it scanned, in hopes that that list would contain sender or date of sending or subject etc., but the scan log format of both OK and trojan files still did not contain any of that identifying information.

I also checked the NOD32v2 Control Panel. Its Event log lists only kernel and regular updates. The Threat log is totally empty! The Scanner log gives scan time, Description, (Number of Files) Scanned, Infected, Cleared and Status (either Completed or Corrected) --- basically the same information as in the scan log when one is actually running a demand scan; nothing there about sender, date of sending, subject, or anything that might help me locate the infected message file within SeaMonkey email.

So I'm still stumped about where to go from here.

While I'm waiting for ideas (I need to post a message on MozillaZine to see if anyone knows how to map NOD32 three-digit message numbers into SeaMonkey identifiable messges), since all of my wife's trojans are within zip or rar archives, is it safe for her to use her machine if she doesn't open any zip or rar archive attachments? Or do the malware writers hide their attached archives that contain their trojans, so that merely opening a message would invoke the trojan?

Also, is there any reason for me not to go ahead and upgrade my wife's computer from NOD32 v2.70.32 to NOD32 3.0.684? (I'll do it first on mine.)

Roger Folsom

 

Hello,

Since my colleague Marcos is helping you, I will not hijack his message thread, but I did want to ask if you knew whether or not Mozilla SeaMonkey was configured to use an SSL connection for sending and receiving email.

Regards,

Aryeh Goretsky

 

Mr. Goretsky:

I'm guessing that your question results from some relationship between connection security (SSL) and whether NOD32 (either v2 or v3) scans within POP3 email attachments.

SeaMonkey Email gives me three security options:
"Use secure connection: _Never, _TLS, if available, _TLS, _SSL" where I'm using an underscore to indicate a round "radio" "check circle" (i.e. obviously you can choose only one of those options). SeaMonkey Mail help says to choose SSL "if your mail server is configured to send and receive encrypted messages." Since I rarely send encrypted messages (the last one was about six years ago, using Verisign's "pretty good privacy" public-private key), I haven't been concerned about this setting.

However, a technician at my email provider, Redshift Internet Services (redshift.com), a local firm in Monterey CA which also serves other parts of Northern California, and which gives me excellent service, recently told me that my setting might as well be Never, because they do not provide either TLS or SSL. (I'll confirm that tomorrow. If I find out that I'm wrong, I'll repost here. I'll also check whether they offer SSL at extra cost.)

One of Redshift's advantages is that I'm behind their firewall as well as my own Danware NetOP Desktop (aka Process Control Client) firewall. Another advantage is that they provide a TMDA (Tagged Message Delivery Agent) spam filter, which follows their preliminary use of Spam Assassin that takes out the truly obvious spam.

Cordially, R.N. (Roger) Folsom
rnfolsom@redshift.com
________________________________________________________________

P.S.: I'd be interested in knowing the relationship between NOD32's email attachment scanning and SSL. If you know of a link where I could read about that, please let me know.

FYI: Redshift's technical support is simply
Redshift Internet Services <support@redshift.com>

But the owner (perhaps with partners) of the business is Karl Van Lear <karl@redshift.com>.

 

This might indicate problems with IMON, the HTTP/POP3 scanner used in v2. If clicking on http://www.eicar.org/download/eicar_com.zip doesn't trigger an alert, IMON most likely doesn't work properly and doesn't scan email either.

As for scanning secured protocols HTTPS/POP3S, these are supported in v4, currently available as beta.

 

Marcos (and also Aryeh Goretsky):

On my wife's computer which is where the zipped trojan messages are (and also, while I was at it, on my computer), NOD32v2 did correctly respond with a warning when I used your eicar_com.zip link. And NOD32v2 again correctly responded when I used a modified link to eicarcom2.zip.

So I went back to http://eicar.org/anti_virus_test_file.htm, where yesterday NOD32 had not warned when I downloaded eicar_com.zip or eicarcom2.zip or eicar.com.txt, and I realized that yesterday I had tested by downloading the "SSL enabled protocol https" test file versions rather than the "standard protocol http" test file versions. Today, NOD32v2 correctly issued warnings for all four "standard protocol http" test file versions, without unzipping either of the zipped versions, when they were simply downloaded from eicar.org without the use of your link.

Since NOD32v2 (and from your message I gather also NOD32v3) does not deal with secured protocols HTTPS/POP3S, and my Redshift.com ISP does not use SSL (as explained in my earlier message in this thread to Aryeh Goretsky), it's not surprising that NOD32v2 did not issue a warning for the SSL test file versions until they were unzipped and also did not issue a warning for eicar.com.txt.

In short, my wife's (and my) IMON modules apparently are working correctly.

We still have no way to determine (within SeaMonkey Email) which are the six remaining zipped trojan-infected messages that need to be deleted.

And we don't know how they got through NOD32v2 when the messages were originally downloaded.

If the infected messages are new, could it be that their trojan attachments were zipped using SSL technology, so that they would slip through AV software (and ISP connections) that were not equipped for SSL?

If the infected messages are old, downloaded prior to 2005 when we were using Norton AV rather than NOD32, perhaps Norton's technology wasn't good enough to catch them? But in that case, previous NOD32 v2 InDepthAnalysis scans presumably should have found them --- unless they could be found only by NOD32v2 definitions issued since my wife's last InDepthAnalysis scan, which we're guessing was in late 2008 (for some reason, her scan logs, and also mine, go back only to 31Jan09).

Remaining Questions

1) Now that we know that IMON works, is it safe for my wife to use her computer if she doesn't open any zip or rar archive attachments? Or do malware writers hide their attached malware archives, so that merely opening a message would invoke the trojan?

In other words, is it safe for my wife to use her computer without deleting the zipped-trojan-infected emails (which we can't identify), because the AMON module would give a warning if the contents of a zipped trojan started to execute and do damage?

2) Is there any reason for me not to go ahead and upgrade my wife's computer from NOD32 v2.70.32 to NOD32 3.0.684? Or, even though my ISP does not use SSL, would there be a security benefit (e.g. malware zipped attachments in SSL "format" like that used in the eicar SSL test files) from moving to version 4 Beta?

3) Ideally, we're hoping that there is some way to get descriptive identifying information (date, sender, etc.) for the the six remaining zipped (or rared) trojan-infected messages that need to be deleted --- or some way to persuade some version of NOD32 (or some other tool) to delete them, even if we don't have that descriptive identifying information.

Thanks again for all of the help.

Roger Folsom

 

To Anyone reading this thread:

Please note that I have edited the first message in this thread, and my message immediately preceding this one. The edits are in non-italic boldface.

Also, I have one more question, in addition to the "Remaining Questions" in my immediately preceding message:

All of my wife's trojan-infected messages apparently are in attached zip or rar files (I'm guessing here, based on my "beginning amateur novice" understanding of NOD32's scan log format).

In SeaMonkey's message lists, legitimate attachments are flagged by what looks like a paper clip or else a safety pin. Would trojan (and other malware) attachments typically be hidden, or would they look like legitimate attachments?

Roger Folsom

 

Aryeh Goretsky and Marcos:

If you have seen message #7 in this thread, which could be titled "RNF's clumsy adventures with Eicar," I now have a much better, although still limited, understanding of SSL. (And I have learned that my Redshift ISP does offer SSL, for a mere $5 extra per month if I create a new domain name still based at Redshift, so I'll likely get SSL when NOD32 v4 is out of Beta, and has gone through a few additional builds.)

And this entire thread has taught me a lot about how to interpret NOD32 scanlogs when they report infections.

Thanks to both of you.

All of my wife's infected email messages finally did get found and eliminated. If you are interested in the details, they are in a short MozillaZine SeaMonkey thread (my initial post describing my problem, a response, and my reply), at http://forums.mozillazine.org/viewtopic.php?f=40&t=1079895

After this experience, I think the following paragraph is correct:

If my wife had not been able to identify the trojan-infected email messages so that she could delete them, the trojans would not have been invoked unless she had not only opened the message but also had started to open the trojan's zip file, at which point AMON would have warned her to stop --- at least assuming that the zip file had not been "designed" to deal with SSL (as one set of eicar zipped files were), in which case AMON would have issued a warning when (hopefully before) the trojan was executed.

I still need to do more research to learn if Trojans and/or other viruses, when borne by email, always are in attached zipped or rar files, and if the attachments ever are hidden from the email program (e.g. hidden from SeaMonkey or other Mozilla based browsers).

Thanks again.

Cordially, Roger Folsom

P.S.: I've printed out NOD32 v3 Quick Start and User Guide, so tomorrow I hope to read them and then install NOD32 v3 (after uninstalling v2, not by using Windows Add/Remove Programs but by using the NOD32 uninstaller).

Incidentally, when printed on U.S. 8.5 x 11 inch Letter size paper, the User Guide print is very small. I suspect that the UG may have been formatted for A4 paper which is a bit longer than U.S letter size paper. In any case, to print the User Guide, Foxit Reader (Adobe Reader alternative) squeezed it to 89.79%, because it said the "document" is 11.7 inches long (presumably including the top and bottom margins).