SONAR.Powershell detections

[Torb]

Lately I have been seeing more SONAR.Powershell!gx detections beeing blocked by SEP.

In the SONAR logs powershell.exe is listed as maclicious with a an action taken of "access denied". From my understanding this means that SONAR has blocked a malicious Powershell action.

https://support.symantec.com/en_US/article.TECH102052.html

It's very recent that we began to see these SONAR.Powershell detections. A few of them I actually manually identified by timestamp that matched scheduled tasks.These scripts were legit.

My main problem is that I don't know how to validate if the detections are true positives or not. I can't see the Powershell CLI arguments or script that SONAR has blocked as its not found in the SONAR logs. This is kind of strange as the arguments fields are usually found in other SEP alerts.

This also makes me wonder how I am supposed to whiteliste false positives?  Have anyone came across this before?
 

 

[John Owens]

Hi Torb, What version of powershell are you running in your environment?

[John Owens]

Increased Detections SONAR.Powershell!G10 Symantec Security Response has been increasing our aggressiveness toward the current trend of malicious Powershell scripts and fileless threats. We are currently evaluating this detection to determine its efficacy and will be removing detection while this investigation progresses. In the mean-time, Please submit any suspect scripts to the False Negative site

[ℬrίαη]

We ended up turning on powershell logging and pulling those logs into our SIEM for correlation. Script logging shows a good amount of info as to what PS is doing. Granted still don't know what SONAR sees but we can validate if the script is part of a scheduled task or something from our deployment team or just malicious.

[Torb]

Don’t get me wrong. Blocking file-less attacks are important, but we really need to see the evidence as part of the alert. For example the argument or script that was blocked. Just showing powershell blocked is not enough, I was really stressed when our exchange server alerted about a sonar powershell attack. It took me almost a full day to identify that the detection was cased by a legit third party script. And i still don’t know what part of that script that caused the incident or how to exclude it..

[Torb]

.

[John Owens]

Powershell v5 does offer better logging. Additional logging in Sonar would make a good enhancement request.

[Mick2009]

Hi TORB,

Run LiveUpdate now to received ​new SONAR update 15 March 2018 rev 1.  That should help! &: )

Regarding Powershell: take measures to protect your organization!  This tool is more and more being used maliciously.

 

What You Can Do About Powershell Threats
https://www.symantec.com/connect/articles/what-you-can-do-about-powershell-threats

 

 

 

 

 

[WatchYourSEP]

Can we get some detail on this change?  While I appreciate the fact that you want to be more aggressive in fighting script base threats, the fact that you're quarantining some versions of powershell.exe comes as a rather huge surprise.

[WatchYourSEP]

My specific questions:

*What versions of Powershell.exe were blocked by what versions of SONAR defs?

*Do March 15 2018 rev 1 defs now leave any flavor of Powershell.exe alone? 

*Do you have plans to make a change like this again in the future for which we should prepare?

 

[John Owens]

Hi,

Powershell itself is not being detected.  Certain scripts being run are being detected if deemed suspicious to Sonar  We are always adding better protection into our products based on what is going on out in the wild. The March 15th Sonar defs lowers how aggressive we will be with such threats until we can determine what happened.

 

John

[Torb]

It is very important to highlight what John is saying. Powershell was not deleted or quarantined. The sonar.powershell signature only has an action of «access denied». This means that SEP blocked powershell from accessing something. In this case a script or running a powershell command.

[WatchYourSEP]

Is there a way to see what script was detected?  The alerts only show powershell.exe

[John Owens]

This explains how you can see what Script.

What You Can Do About Powershell Threats
https://www.symantec.com/connect/articles/what-you-can-do-about-powershell-threats

[Torb]

Thats nice and all, but I want to see it in SEPM, not use GPO or any third party tools. I am almost certain that the argument info is stored by the SEP agent as part of SONAR evaluation. You just need to present the info in the SEPM GUI. I

[John Owens]

I agree it should be shown. I would suggest an Enhancement Request.

[WatchYourSEP]

Will do - what's the best place to submit an enhancement request these days?  I

[John Owens]

Here you go.

https://support.symantec.com/en_US/article.TECH215657.html

[RMcKee]

I can concurr that SONAR was really bad yesterday.  It was killing all of the powershell scripts (including one by Microsoft used to compile visual studio projects) on our build server yesterday.

[Torb]

I have created the idea John.

Please forward it to your development team.

https://www.symantec.com/connect/ideas/sonar-should-log-powershell-arguments

 

[Shawn D]

I work for a very large healthcare organization and part of my InfoSec role is the management of our Symantec endpoint technologies.

Yesterday's SONAR squeeze on Powershell caught me completely offguard.

I took advantage of submitting a false positive report in hopes the analysis and results will benefit all.  Weblink provided:

https://submit.symantec.com/false_positive/

 

[Migration User]

We plan on adding additional information such as command line arguments to SONAR and IPS events later this year.

Adam

[Torb]

That is great Adam! I really think this should be prioritized as the STAR team is putting alot of effort into protecting against file-less attacks these days. If it takes to long for SYMC to fix this it will backfire and we will see the same discussion as we are seeing in this thread come up again and again. IMHO it should be added to the feature list of the April/May release of SEP 14 RU1 MP2