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.
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.