marc.search.exe allocating all available RAM when indexing certain attachments (virus)
Versions / Builds Affected
20131111, 20140616
Status
Resolved
Problem Summary
marc.search.exe allocating all available RAM when indexing certain attachments (virus)
TT / JIRAID
1989
How 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 20141117
Required Actions
Upgrade to GFI Archiver 2015 build 20141117 or newer
Priyanka Bhotika
Comments