Thank you once more to everyone who took the time to attend our PowerShell abuse webinar. We had fantastic attendance, and many more questions than we were able to answer. If you missed the webinar, or if you loved it so much that you’d like to watch it again, you can view it here.
I thought I’d take a moment to address some of the unanswered questions and comments that we received, and also link to some of the resources mentioned during the presentation.
Primarily as context for the folks who weren’t able to join or have yet to watch: Red Canary’s focus is on providing the highest quality endpoint-based threat detection to businesses of any size. We leverage Carbon Black Enterprise Response as our primary data source, and pass endpoint telemetry from sensors into our engine. Within our engine we are able to perform deep analysis of both binaries and processes–including their relationships, attributes and behaviors–in a way that no other product or service on the market can claim. The resultant events are sent to our analysis team for review and triage, so that customers receive detections that are both timely and reliable.
So, we have a unique mix of experience not only with Cb Enterprise Response, but with the volume of data and observations that it is capable of providing.
With that foundation established, on to the questions . . .
Request: “Please help with some CB alerts that can help us identify potential malicious activity.”
Absolutely! I probably forgot to mention this as we burned through the content, but all of the Cb Enterprise Response queries referenced during the presentation are available here.
And the Cb team will be releasing the response tool demonstrated by Jonathon in the near future.
Question: “Could signed scripts have stopped or limited this?”
Author’s Note: I assume this is referring to the demonstration, wherein a malicious PowerShell command is used to perform reconnaissance, as well as data and credential theft.
No. By default, PowerShell requires scripts to be signed. Almost all malicious use is predicated on the attacker’s ability to trivially circumvent this signing requirement by using execution policy bypass at the command line or by changing the local system policy via the registry. Further, most PowerShell-based attacks do not leverage scripts at all, relying entirely on the command line to pass payloads without touching disk.
Question: Does this command line look normal?
PowerShell -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass "C:\WINDOWS\TEMP\InstallDVDAppxPackage\DvdInstall.ps1" "C:\WINDOWS\TEMP\InstallDVDAppxPackage\50ea4d02e68f4217869d054e06374b74.appxbundle" "C:\WINDOWS\TEMP\InstallDVDAppxPackage\50ea4d02e68f4217869d054e06374b74_License1.xml"
Herein lies the challenge when attempting to analyze PowerShell utilization. One organization’s “normal” is another’s nightmare. In this case, it looks like a typical PowerShell-based application installer. This is becoming increasingly common, to the point that even other popular security products are using PowerShell as their deployment mechanism of choice.
We at Red Canary are looking across many customers, and in some respects this makes analysis of examples such as the above easier to triage. We’re able to profile things like this based not only on the command line as observed, but also based on the pedigree of the process. This includes attributes such as the parent process(es) but also other endpoint observations such as endpoint role and user context.
Once we find these special cases we’re able to efficiently chain those observations together and use them to suppress future events.
Question: When the system gets hardened, does CB catch changes to names of applications. Such as, if I changed the cmd.exe to bob.exe? It still executes the command prompt just as bob.exe.
Author’s Note: Not directly related to PowerShell, but it’s a fun question and problem so we’ll take it!
Cb Enterprise Protection can be used to mitigate this type of technique, yes. And if you’re looking, Cb Enterprise Response can be used to detect this technique as well.
Red Canary’s perspective:
We refer to this as tool relocation. We maintain lists of relocatable native tools along with their standard paths, and detect when we see them in non-standard locations. This can be done based on the name of the process, the binary’s internal name, and the process path. A very simplistic example using the Cb Enterprise Response query language:
Tools and other resources . . .
As described during the talk, we are very much in the midst of a PowerShell renaissance wherein years of PowerShell product maturity, industry research and experience, and tool development converge. Following are just a few of the many excellent resources available:
I’d also encourage anyone interested in forensic investigation of PowerShell events to check out Investigating PowerShell Attacks by Ryan Kazanciyan and Matt Hastings. A video of their presentation from Black Hat USA in 2014 is available as well.
Lastly, I’d like to pass along a terrific reference submitted by endpoint abuse specialist Casey Smith (@subTee). He reminded us of this fantastic PowerShell-related reference for the blue team: https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team.
Again, thank you for joining us and we hope you found the presentation to be informative. There are many others questions that I was not able to address in this post – stayed tuned for future articles expanding on some of these themes.
If you would like to learn more about how Red Canary is helping organizations all over the world defend their endpoints, send us a note and we can work together to see if we might be a good fit for your organization.