AMON / IMON Behavior With EICAR Test Files

Here are some observations about how AMON and IMON function (similarities, differences, quirks) when confronted with EICAR test files (*.com & *zip). This may be beneficial when you have to address a real virus. Pay particular attention to how each module handles infected / non-infected files inside archives, as the results may not be what you expected or wanted.

I began these tests after reading this:

http://www.wilderssecurity.com/showthread.php?t=18513

to see if I could better understand what was happening to that user. While I found some quirks with IMON, I could not cause an email with an infected attachment to stay on my mail server unless I specifically chose for that to happen (see Action "Disconnect" under the IMON section) or allowed the server request to timeout.

The tests are by no means exhaustive and were done up to the point at which I felt satisfied I understood what I needed to understand about how the two modules actually worked. Feel free to test with other archive algorithms, OSs and mail clients to see if behavior is the same or not.

Tested with:

WIN98
MS Outlook mail client
NOD32 v 2.000.8

(Originally tested and written approx. one month ago but never posted. The post is long, so I have broken it up into three sections: the test summary and purpose, the AMON test, and the IMON test.)

 

***AMON**

AMON was set to the following for testing:
Detection Tab - Scan FILES On: Open; Execute; Create; Rename
Extensions To Scan: All files
Methods Tab - Signatures, Heuristics (Deep)
Actions Tab - Prohibit access and display alert window with action selection
Security Tab - Supported Actions: Clean; Delete; Rename; Replace (?)

*AMON does not use Advanced Heuristics and does not scan inside archives

----------------

*AMON Behavior with Zip Files (e.g., eicar_com.zip; to test AMON actions with multiple files inside *.zips, I added a text file to the archive and renamed it "eicar_com with text.zip")

Upon extraction / detection, AMON presents an Alert box with:
Quarantine [Tick Box], Clean Button [Gray De-activated], Delete Button [Active],
Rename Button [Active], Help Button [Active], Close Button [Active],
Info Button [Gray De-actived]

Action Behavior Descriptions:

- Delete - The Action performs as expected, keeping in mind that AMON can't scan inside *.zips. If multiple files were inside *.zip , only the infected file is deleted upon extraction. Any other files are extracted to the specified destination. Archive and all original files inside the archive (infected and non-infected) remain intact.

- Rename - The Action performs as expected. The extracted file is renamed eicar.Vcom (if the file already exists, V00, V01, etc. is appended); the *.zip file itself is not renamed (see contrasting IMON behavior below).

- Quarantine - The "Action" performs as expected ... I used quotes around Action because Quarantine cannot be performed without first selecting another available Action (Rename / Quarantine or Delete / Quarantine, etc.) One quirk noted: the time stamp of the Quarantine operation as it appears in the Quarantine section of the Control Center reports in GMT (I believe) while the Virus Log shows the same infiltration in local computer time (e.g. 9:04:46 for Quarantine vs. 4:04:46 AM for Virus Log; AM / PM not specified for Quarantine)

- Help - The Action performs as expected ... it opens Help File to Virus Alert page.

- Close - Essentially performs same function as the "Leave" button found on the on-demand scanner Virus Alert; the file detected is left as is (no warning about consequences of leaving file is displayed - see IMON close button).

----------------

*AMON Behavior with Non-Zip Files (e.g., eicar.com)

Behavior of AMON with non-zips is essentially the same as with zips except I did note this quirk:

- Right-clicking on an infected file which has been renamed (renamed via file extension change, either manually changed or through AMON rename function) immediately triggers AMON Virus Alert ... I expected the right-click context menu to appear; by contrast, right-clicking on an infected file that has NOT been renamed (via file extension change) performed as expected, i.e. the right-click context menu was displayed. It seems that whichever way is "correct", the behavior would be the same for files that have been renamed and for files that have not been renamed, but it is not.

----------------

*AMON General Note:
- Even though Replace is selected as a Supported Action, I have never seen this button appear (either active or "grayed-out") on an AMON Virus Alert. What is it and when does it appear?

 

***IMON**

IMON was set to the following for testing:
Scanning Methods: Signatures; Heuristics
Targets: Runtime Packers; Archives
Heuristics Sensitivity: Deep
Advanced Heuristics: Use advanced heuristics
Extensions to Scan: All

*IMON can scan using Advanced Heuristics and can scan inside *.zips. I did not test any other archive type.

----------------

*IMON Behavior with Zip Files (e.g., eicar_com.zip; to test actions with multiple files inside *.zip, I added a text file to the archive and renamed the *.zip "eicar_com with text.zip")

Upon detection, IMON presents an Alert box with Quarantine [Tick Box], Clean Button [Gray - Inactive], Delete Button [Active],
Rename Button [Active], Help Button [Active], Close Button [Active],
Info [Button - Active]

Action Behavior Descriptions:

- Delete - Zip file is left attached to mail and infected file inside is deleted. If other uninfected files are inside the archive, they are deleted also (not so good). Deletion is an assumption as the archive that is left is damaged and fails Archive Integrity Testing. The archive's properties do show that the archive is smaller (byte wise) than before operation by IMON, but because the archive is damaged, it can't be opened to see exactly what has been left inside, if anything.

- Rename - Very "quirky" (someone will no doubt say this is a feature). In one test, the Zip file itself is renamed (e.g., "eicar_com.zip" becomes "eicar_com.Vzip"); in another, evidently the file inside was renamed, as the zip file was again trashed (archive fails Archive Integrity Test and can't be opened). After further testing to see if this was repeatable (it was), here's what I found to be the cause of the different Renaming methods: if you select Rename and there is nothing in the email message's body (i.e., a blank email other than the attachment), IMON Renames the infected file(s) inside the archive (again an assumption) and trashes the archive (archive fails Archive integrity Test); if you choose Rename and the email message has something (text, etc.) in the message body, IMON Renames the *.zip itself and leaves the file(s) inside the archive unchanged ... the archive passes Archive Integrity Test and the files inside the archive are undamaged. Why the difference simply because email message is blank or not, I haven't a clue. I also tested these scenarios with/without an email subject line, but whether the subject line exists in the email or not does not affect the Renaming results.

- Quarantine - "Action" performs as expected. I used quotes around Action because Quarantine cannot be performed without first selecting another available Action (Rename / Quarantine or Delete / Quarantine, etc.) One quirk noted: the time stamp of the Quarantine operation as it appears in the Quarantine section of the Control Center reports in GMT (I believe) while the Virus Log shows the same infiltration in local computer time (e.g. 9:04:46 for Quarantine vs. 4:04:46 AM for Virus Log; AM / PM not specified for Quarantine)

- Help - Action performs as expected ... it opens Help File to Virus Alert page.

- Info - Pops up window with path and name of file found to be infected (in AMON, this Action is "inactive" / "grayed-out" and does nothing)

- Close - If selected, a pop-up message (with Okay / Cancel option) warns of consequences of leaving the infected file (the message says, "Closing this window without selecting an action may result in virus infiltration. Are you sure you want to continue?"). If you select "Yes" (continue), you are returned to the Virus Alert window which now has a "Disconnect" button ... Delete, Replace, Quarantine are now "grayed-out". If you select "Close" again, you get the same warning once more; selecting "Yes" (continue) on the warning this time delivers the email with all attachments intact. If you instead had selected "Disconnect" after the first warning, the mail would be left on the server. Essentially, selecting "Close" in IMON is like the "Leave" button from the on-demand scanner's Virus Alert except with IMON, you have to go through two "Closes" and two warning boxes to achieve the same thing. If you stare at these dialog boxes too long wondering why NOD32 does this, your mail client will time out and the effect is the same as if you hit "Disconnect" (no mail delivery)

----------------

*IMON Behavior with Non-Zip Files (e.g., eicar.com)

IMON behavior with non-zips is essentially the same as it's behavior with *.zips except the Renaming quirk that occurs with *.zips is not relevant (V, V00, V01, etc. is simply appended to the file extension, e.g., "eicar.com" becomes eicar.Vcom). Also, note that if a non-zip file is Deleted, a placeholder is left on the email rather than an empty / damaged *.zip archive (e.g., attachment "eicar.com" becomes an empty text file named "ATT0001.txt" or similar).