I work on Nitro SIEM and currently monitoring the ePO alerts logging to Nitro. Can some one please suggest how we can determine if a provided file path is genuine and ePO threat action can be ignored?
Here is an event packet-
SourceProcessName='C:\WINDOWS\System32\WScript.exe' TargetFileName='C:\Documents and Settings\blosabia.TEA.027\Local Settings\Temporary Internet Files\Content.IE5\2YAXLZ5Z\desktop.ini'
ThreatCategory='hip.file' ThreatSeverity='5' ThreatName='Anti-spyware Maximum Protection:Prevent execution of scripts from the Temp folder' ThreatEventID='1095' ThreatType='access protection' ThreatActionTaken='would deny read' ThreatHandled='1' ProductFamily='VIRUSCAN' IPv6='::ffff:220.127.116.11' InTrustNetwork=''
SourceProcessName='C:\WINDOWS\system32\CCM\CcmExec.exe TargetFileName='C:\Program Files\VMware\VMware Tools\VMwareUser.exe'
When I researched about Wscript.exe some have stated it might be a virus.
How do I determine from a packet like this- If its safe to let go the event? I usually see the process name and path to figure out, please suggest if there is a better research process.
wscript.exe is the Windows Scripting Host (see more at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/w sh_runfromwindowsbasedhost.mspx?mfr=true )
cscript.exe is the command line version of the same (see more at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/c script_overview.mspx?mfr=true )
The boldfaced letter event - to me- suggests that there were a browser script that has executed and VIrusScan Access Protection relevant rule (Anti-spyware Maximum Protection:Prevent execution of scripts from the Temp folder') was set to notify-only in the case of such event and creating an ePO event in addition.
Browser scripts always download for execution to the %TEMP% folder so whether you monitor or not, this folder will always be used.
Wscript in itself is not a virus, although scripts that it executes (from a webpage, for instance) could be harmful.
I suggest you only use "block and notify" options together in each VirusScan Access Protection rule that you know should prevent the type of action it is named after. Use notify only when you want to test a rule that you want later to use for blocking, for example.
If you ever think something is a virus then go visit Virus Total and submit the file. We don't run that site but it is a decent way to find out what a lot of scanner "think" about a particular file. Surely every vendor can miss something. But it is a decent way to find out EXACTLY what a file is. Don't bother looking at just the filename as that's not terribly effective.
I'd like to complement this with that, that any suspicious executable can also be submitted to ThreatExpert (http://www.threatexpert.com/) that analyzes what your file is doing when executed. Some more useful info could be obtained if you are not totally convinced by VirusTotal, want to have a deeper look or VT just did not detect anything.
It is really worth a try.
Thank you all for your responses .
But as an analyst I can only see source process name and target file name in the log. As I would be monitoring thousands of logs how can I quickly determine from these paths if a log is legitimate ? Any quick tips?
by saying "the log is legitimate" do you mean "the event is signifying a threat" ? If so, maybe SIEM has some processing power (alerts, reports, etc.) to extract important events from the sea of events, but for that you need to know how to tell if an event is ok or could be sign of a threat action. In this example I'd stop using "notfy-only" Acces Protection rules everywhere on clients, and start reviewing what rules should be enabled for block and notify and what rule not at all (or later).
As a rule of thumb then, some Windows processes may need to have greater attention when they occur in such events as they might be having a malware in their memory space. In addition it is also important which Access Protection rule they are blocked by. The two pieces of information should be viewed together.
Generally I'd say that preventing execution of scripts, programs etc. from the Temp folder might not be the first rule I'd monitor, rather, there are more important rules to watch.