chispaluz 0 Report post Posted August 25, 2017 Hi there, I have a client with newly installed Emsisoft AntiMalware. He was visiting an MSN website and a notification popped up that said "Behavior blocker detected suspicious behavior "Exploit" of C:\\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. It was blocked by default. Any idea what caused this? After going through his history, we tried to replicate the situation by visiting the same page, and nothing happened. Thanks. Quote Share this post Link to post Share on other sites
JeremyNicoll 57 Report post Posted August 26, 2017 I've tried to replicate visits to pages where I've had alerts... and it's more or less impossible. Many webpages these days have ads etc which are selected for display by some 'random' process that you have no control over. Each of those ads is likely to require the browser to fetch some files, of graphics/video, or maybe some JavaScript. On subsequent visits to the same page you'll get a different selection of ads, and I doubt you can ever guarantee to get offered the same set of things again, even if you clear cookies etc - not least because they probably weren't all clear on the visit that had the problem. I fairly often get file-quarantined alerts when I open a Facebook message stream for one specific friend of mine... and since that only happens for him, I guess it might be because some of the things he shares with me by message are hosted on non-Facebook sites. Then, as the brower fetches those files and attempts to store them in the browser cache, EIS quarantines them. Maybe, if I poked my way around the browser's cache I could find out which fetched file the quarantined thing was. (Firefox's about:cache url gives access to lots of control info for what is cached, but I'm not sure if it is readily searchable nor whether you can see the filename on disk under which each cached item is stored - which is what the EIS alert names.) It might be possible that a malicious ad provided a powershell script as a resource, but I what I don't understand is how (once that was in your browser cache, if it was), anything could try to run it under powershell. That should be impossible. Quote Share this post Link to post Share on other sites
chispaluz 0 Report post Posted August 28, 2017 Thanks, Jeremy. I can reassure the client that Emsisoft is protecting him with the Behavior Blocker, even if we don't know exactly how the threat came to be. Quote Share this post Link to post Share on other sites
GT500 574 Report post Posted August 29, 2017 Did the Forensics log show anything? PowerShell was more than likely either executing a script, or had been executed with some sort of parameter that might give a clue as to what it was doing and why it was blocked. If the logs show the script that was running or any parameters that had been passed to PowerShell when it was executed, then that might help figure out why it was running. Note that it may not have necessarily had anything to do with the website they visited, or even their web browser. It is entirely possible that a Scheduled Task or a program running in the background was responsible for launching PowerShell. What launched the application (the parent process) won't be in the Forensics log, so the only want to get that information is with advanced process monitoring tools like Process Hacker and Process Explorer (you can also use them to see the full command that was executed when a program was launched), however these tools do require that the offending process (PowerShell in this case) still be running to get that information. Quote Share this post Link to post Share on other sites
chispaluz 0 Report post Posted September 5, 2017 Thanks for the feedback. So the same issue has been coming up. Powershell being blocked. Different days, but always at 6:57pm. I pulled up the forensics log (attached), and the Event Viewer Powershell log (attached). Looks like it's been going on since at least June 2017. How can I dig into this further to find out what is making in run everyday at 6:57pm? Do I need to remote in at that time to see what was going on using Process Explorer or Process Monitor or can I see the application in some sort of other event log? I tried looking in Event Viewer Applications, but nothing was shown for those specific days and times that I could find. The client is older, and very concerned about computer safety. He's been shutting his computer down each time the Emsisoft alert pops up. I'd like to reassure him, or tun off that specific notification if it's not something to worry about. Thanks! Download ImageDownload Image Quote Share this post Link to post Share on other sites
JeremyNicoll 57 Report post Posted September 6, 2017 If it's always the same time of day, then I'd look closely at Scheduled Tasks to see if one of those is starting some process/ script at that time of day. If that doesn't help, then it's possible to turn on eventlog 'Auditing' of process start and process stop, which would show powershell being started and the process id (pid0 of the process that is starting it. There's also an eventlog 'Audit' option that remembers in eventlog records the command line of every started process. Some people view the latter as a security risk (on shared computers anyway) because command lines for some commands sometimes contain userids or passwords or other confidential information, and if all commands for all users of a machine get logged anyone who can see the eventlogs can see other people's confidential info. Turning on auditing of proces start/stop is easy if you have a 'Pro/UltimateEnterprise' version of Windows (via altering the appropriate policy entry using gpedit.msc) - that was possible in XP too. But in (my) non-Enterprise version of W8.1 it took me quite an effort to find out how to do it. I read: I read here: http://blogs.technet.com/b/askds/archive/2007/11/16/cool-auditing-tricks-in-vista-and-2008.aspx and: http://blogs.technet.com/b/askds/archive/2007/10/19/introducing-auditing-changes-in-windows-2008.aspx and https://support.microsoft.com/en-gb/kb/921469 about a command-line command, auditpol, which allows you to interrogate and alter these policies (from an administrator command-prompt). Basic synatx: C:\Windows\system32>auditpol /? Usage: AuditPol command [<sub-command><options>] Commands (only one command permitted per execution) /? Help (context-sensitive) /get Displays the current audit policy. /set Sets the audit policy. /list Displays selectable policy elements. /backup Saves the audit policy to a file. /restore Restores the audit policy from a file. /clear Clears the audit policy. /remove Removes the per-user audit policy for a user account. /resourceSACL Configure global resource SACLs Use AuditPol <command> /? for details on each command For example to list all the things that could in theory be turned on and off for auditing: C:\Windows\system32>auditpol /get /category:* whose output might look like: System audit policy Category/Subcategory Setting System Security System Extension No Auditing System Integrity Success and Failure IPsec Driver No Auditing Other System Events Success and Failure Security State Change Success Logon/Logoff Logon Success Logoff Success Account Lockout Success IPsec Main Mode No Auditing IPsec Quick Mode No Auditing IPsec Extended Mode No Auditing Special Logon Success Other Logon/Logoff Events No Auditing Network Policy Server Success and Failure User / Device Claims No Auditing Object Access File System No Auditing Registry No Auditing Kernel Object No Auditing SAM No Auditing Certification Services No Auditing Application Generated No Auditing Handle Manipulation No Auditing File Share No Auditing Filtering Platform Packet Drop No Auditing Filtering Platform Connection No Auditing Other Object Access Events No Auditing Detailed File Share No Auditing Removable Storage No Auditing Central Policy Staging No Auditing Privilege Use Non Sensitive Privilege Use No Auditing Other Privilege Use Events No Auditing Sensitive Privilege Use No Auditing Detailed Tracking Process Creation No Auditing Process Termination No Auditing DPAPI Activity No Auditing RPC Events No Auditing Policy Change Authentication Policy Change Success Authorization Policy Change No Auditing MPSSVC Rule-Level Policy Change No Auditing Filtering Platform Policy Change No Auditing Other Policy Change Events No Auditing Audit Policy Change Success Account Management User Account Management Success Computer Account Management No Auditing Security Group Management Success Distribution Group Management No Auditing Application Group Management No Auditing Other Account Management Events No Auditing DS Access Directory Service Changes No Auditing Directory Service Replication No Auditing Detailed Directory Service Replication No Auditing Directory Service Access No Auditing Account Logon Kerberos Service Ticket Operations No Auditing Other Account Logon Events No Auditing Kerberos Authentication Service No Auditing Credential Validation No Auditing These four commands tell Windows to Audit (ie create eventlog records) for successful and failed process creation: Auditpol.exe /set /subcategory:"process creation" /success:enable Auditpol.exe /set /subcategory:"process creation" /failure:enable and successful & failed process termination: Auditpol.exe /set /subcategory:"process termination" /success:enable Auditpol.exe /set /subcategory:"process termination" /failure:enable If you execute those then do the list command (shown above) again you should see these slightly different lines: Detailed Tracking Process Creation Success and Failure Process Termination Success and Failure If you want the commands actually used to start processes also to get audited (ie details included in process-creation eventlogs) you need to make a registry change. You define a DWORD value, value 1, named ProcessCreationIncludeCmdLine_Enabled in: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit I found that out by looking at a table: http://gpsearch.azurewebsites.net/#10674 Quote Share this post Link to post Share on other sites
chispaluz 0 Report post Posted September 14, 2017 Thanks so much for the in depth reply, Jeremy. I appreciate the time you took to do it. I'm still waiting to remote in to the client's machine to see what I find in Task Scheduler. I'll report back when I do. Thanks again! Quote Share this post Link to post Share on other sites
