1 Reply Latest reply on Apr 5, 2015 11:39 PM by wwarren

    How does VSE On Access Scan really work?


      Hi all,


      My user received an email with an attachment (zip file, lets say 123.zip).  Inside that zip file, there is an exe file (zzz.exe) which turns out be a Trojan.

      It looks like the when my user open 123.zip or save 123.zip, the zzz.exe is automatically extracted which automatically trigger a call back to its Command and Control Server on the internet.


      I know when my user save or open 123.zip, VSE OAS scan 123.zip and zzz.exe.  It will use VSE DAT and GTI to determine if the file is clean or malicious.  It will then take the appropriate action.


      But here is my question:

      Does VSE OAS LOCK both 123.zip and zzz.exe while evaluating the file (sandboxing)



      VSE OAS is a step behind, meaning

      While VSE OAS evaluating 123.zip.  123.zip actually extract and open another process, zzz.exe

      VSE OAS then detect zzz.exe is being open, OAS then evaluates zzz.exe.  In the meantime, zzz.exe is calling C&C Server

      Therefore, VSE can't catch and stop the zzz.exe from releasing its payload from calling back the C&C Server

      If the answer:  VSE is a step behind, then is there any plan to introduce sandboxing capabilities for VSE?


      I know this may sound like McAfee Security Lab question, but its not.  Its really VSE OAS question.


      Thank You

        • 1. Re: How does VSE On Access Scan really work?

          Of your choices for answers, the Locked scenario is more accurate - but that's not how it works either.

          All file I/O goes through our file-system filter driver.

          That means, before process "xyz" has a chance to gain access to their desired file, be it malware or otherwise, we see it first - and their request does not continue until we're done with it and say it can continue. Or we timeout. When a timeout occurs the process "xyz" gains access to the file whether clean or not... because we don't know, we timed out. That is why you shouldn't just ignore timeouts.