Behavior Blocker and Powershell

[chispaluz]

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.  

[JeremyNicoll]

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.

[chispaluz]

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.  

[GT500]

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.

[chispaluz]

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!

 

[JeremyNicoll]

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 

 

[chispaluz]

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!