Versions / Builds Affected
20131111, 20140616Status
ResolvedProblem Summary
marc.search.exe allocating all available RAM when indexing certain attachments (virus)TT / JIRAID
1989How to Identify
Certain emails can cause that marc.search.exe to allocate all available RAM on a system which will effectively leave Search and the whole server in an unresponsive state and might also cause other processes to crash.
You can spot the memory allocation via the Windows Task manager.
Based on the cases we have seen all email samples seem to contain the same virus, but the emails / attachments appear to have random names.
Samples of subject:
Track your shipment No037591
Samples of attachment names:
Invoice_ID27515.zip
FedEx_Invoice _Copy_ID24-834.zip
Post_Label_N1478US.zip
Information_UK3320.zip
Ticket_Form#DEP_ID145934.zip
The virus appears to be generic. E.g. VIPRE identified it as: Trojan.Win32.Generic!BT. This lists how other engines named it:
AVG: Generic27.PVC
Agnitum: Trojan.Menti!zUNnQmTgyYM
AntiVir: TR/Offend.7233238
Avast: Win32:SmokeLoader-JZ [Trj]
BitDefender: Trojan.Generic.7233238
ClamAV: Email.Trojan.GZC
Commtouch: W32/Trojan.WQXK-7604
Comodo: UnclassifiedMalware
DrWeb: Trojan.Oficla.zip
ESET-NOD32: Win32/TrojanDownloader.Zurgop.AI
F-Secure: Trojan.Generic.7233238
Fortinet: W32/Menti.AI!tr
GData: Trojan.Generic.7233238
Ikarus: Trojan.Win32.Menti
Jiangmin: Trojan/Menti.trx
K7AntiVirus: Trojan ( 19ee9cec0 )
Kaspersky: Trojan.Win32.Menti.mgjh
McAfee: Generic.ji
McAfee-GW-Edition: Generic.ji
MicroWorld-eScan: Trojan.Generic.7233238
Microsoft: TrojanDownloader:Win32/Dofoil.O
NANO-Antivirus: Trojan.Win32.Menti.mxbax
Norman: Troj_Generic.ACOYE
Panda: Generic Malware
Rising: PE:Malware.FakePDF@CV!1.6AC1
Sophos: Troj/Bredo-SI
Symantec: Backdoor.Trojan
TotalDefense: Win32/Dofoil.ZAAC
TrendMicro: TROJ_SPNR.11BM12
TrendMicro-HouseCall: TROJ_SPNR.11BM12
VBA32: BScope.Trojan-Ransom.Winlock.9212
VIPRE: Trojan.Win32.Generic!BT
Reference: https://www.virustotal.com/en/file/c6396ccfe041a7501b515b78e6a3c86208dcbefeccc575f2573f6a656066bc1f/analysis/
To identify the the last attachment / decompressed file check the last lines of Search/DebugLogs/ZipAttachment.log resp. IndexableAttachment.log from the point in time when the RAM allocation begins. Here is an example:
...
2014-02-28,14:47:24,078,1,"#00000D5C","#0000000C","info ","ZipAttachment","Decompressing Invoice_ID27515.zip at depth 0"
2014-02-28,14:47:24,078,1,"#00000D5C","#0000000C","info ","IndexableAttachment","Processing attachment [file] Invoice_ID27515.exe at depth 1"
2014-02-28,14:47:24,078,1,"#00000D5C","#0000000C","info ","IndexableAttachment","Processing attachment [file] system__/doc-21.txt at depth 1"
2014-02-28,14:47:24,078,1,"#00000D5C","#0000000C","info ","IndexableAttachment","Processing attachment [file] system__/system.docx at depth 1"
At this point in time marc.search.exe is taking up all available RAM very quickly.
Notes:
- The behavior / memory consumption cannot be followed via a set of troubleshooting files on their own. Normally a remote session is needed to determine this issue.Workaround / Fix Details
WORKAROUND
Disable indexing of attachments (see article ) or pause indexing
FIX
Fixed in GFI Archiver 2015 build 20141117Required Actions
Upgrade to GFI Archiver 2015 build 20141117 or newer
