Saturday, March 14, 2020

Authoring a Sigma Rule for CSI.Exe


I have continued down the rabbit hole with how to detect different .NET framework executable's.  In this blog post, I will cover a quick proof of concept and a soft detection rule via a Sigma rule. Not only does Sigma allow for the quick creation of rules across multiple SIEM environments, but the authors are also nice enough to let anyone submit their own newly created rules.

For those new to information security and looking to get their foot in the door, contributing amongst to projects amongst your peers is a great confidence builder. It took me weeks to get the guts to make my first pull request with a Sigma rule. My first rule breezed right through the pull request and was merged into the Sigma repository.

Continuing on from my last foray into csi.exe, I wanted to find some ways to detect malicious use of this binary without getting overwhelmed by ETW logs. This process also allowed me to see just what I was able to detect in my lab environment. I have moved to researching Reflective DLL injection, that will definitely be another blog post for another time, an eye opening experience indeed.


The Test

The test for this detection isn't overly complicated. The csx file will start calc.exe using a hidden cmd shell. The source C# code can be seen below.

Figure 1



Upon running the csx file, we should get the ever so famous calc.exe to ensure we have successfully completed our test.

Figure 2
With confirmation of a successful test, it is now time to start digging into the logs and our EDR solution to see just what the current setup is capable of seeing.

I can't overstate just how important process creation events are when it comes to a starting point in detecting anomalies on the endpoint. Below is a process tree of what the current EDR solution I am using captured.

Figure 3

The execution path is definitely interesting and I had more than a few alerts in the EDR that weren't worth wasting time with another image. Let's move to see what Sysmon has for us.

Figure 4 
As I progress in researching attack and detection methods, I hope to get away from constantly using process creation events in my rules, however these EID's contain so much info.

Rules Really do Rule

 In an attempt to create rigid rules, I want to attempt to focus on anomalous behavior of known tools, not so much the tools themselves. Hopefully most organizations have enabled PowerShell script block and command line logging (where available), to get a clear picture of commands executed. The C# console may be used in development environments and could possibly reach out to the internet to pull down another file/script.

All is not lost, it may be burdensome, but detecting on any network connections initiated by csi.exe, as well as scripting engines that have created the csi process are great indicators to start with.  Additionally, adding the "OriginalFileName" field to your detection will ensure that even if adversaries attempt to rename the binary, we can still trip them up.

 Here is what I came up with as a rule before making my pull request to the Sigma repo.

Figure 5
I poured over this for some time and was able to get a positive hit in Splunk when I translated the rule. So I thought, "why not, let's create a pull request and see how it goes".

Figure 6

Conclusion

I admittedly wait in suspense and frequently check my email after making pull requests to check whether my rule was merged or kicked back. This would probably be a good time to mention that there is a whole page of specifications that goes into great detail on what makes a quality Sigma rule
(https://github.com/Neo23x0/sigma/wiki/Specification).

To my joy, the rule was merged into the repository. However, there were more than a few changes to my original rule.

Figure 7 


The fixed rule looks much cleaner and upon a second and third look, easier to read. While it sucked to have so many issues that required fixing, it was a great learning experience and has pushed me to use this rule to baseline the rest of my rules from here on out.



JPCert's Log Analysis Training

6 Aug 2020 About a week or so ago, JPCert released their Log Analysis training slides and corresponding CSV files for each hands-on exercise...