Thursday, February 6, 2020

Putting a Spotlight on CSI… the Binary, Not the Show

6 Feb 2020

While PowerShell is likely to be the go to for threat actors looking to gain an initial foothold, the power of .NET development tools cannot go overlooked. A few of these tools come native with a fresh download of Visual Studio and allow for unsigned C# code to be executed.

The focus of this post will be on csi.exe, which provides an interactive console to run C# scripts (.csx). Even for someone like me still learning, C# script files are unbelievably easy to whip up and run. The usual path for csi.exe is:

- C:\Program Files(x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\

You may be saying, 'This comes with VS? Who cares, that means it's trusted".  A few lines of C# can be executed with the same ease as in the VS IDE. If this doesn't get your attention, what if I told you there isn't a great deal of visibility into this tool?



Much research has been put into trusted binaries and their use in bypassing basic application whitelisting. With few dependencies, csi.exe makes for a great tool to be renamed/packaged and brought onto a target for  execution.

For those still following along, the execution of this utility for malicious purposes would fall under the ATT&CK technique T1218, Signed Binary Proxy Execution. With the emergence of great tools utilizing .NET tools, specifically C# it is just a matter of time before csi.exe is used for malicious purposes.

It should be noted that with updated AMSI signatures via Microsoft, or the disabling of these tools on user workstations will negate the attacks.

I decided to forego application whitelisting, and see what interesting items could be discovered utilizing Sysmon and SilkETW.

A Name by Any Other...

While csi.exe may not be a well known tool for malicious content, the ease of renaming and packaging the file to run code is quite interesting.


Figure 1


I wasn't worried about creativity points with the renaming, the intent was to show that csi.exe could be renamed and unsigned C# code executed from anywhere. Obviously there are other tools which provide similar actions, but where else can you execute C# code with such ease?

We have a portable C# utility that can execute whatever a threat actor can imagine. Let's just pack it up and call it a day right? Not so fast...

Figure 2



Figure 3



 The above events are pretty basic and should be available even in the smallest of organizations. Represented in the figures are process creation and termination events. There are a number of low to medium indicators to put to use. Assuming csi.exe usage is authorized, the OriginalFileName field identifies the process being created is csi.exe. This should start raising suspicions immediately. Additionally the usage of the console from a user path and not VS indicates something is up. Lastly, PowerShell being used to execute the script should finish our trifecta.


Figure 4

 With our soft indicators in Figs. 1-3, the addition of a network connection would be the slicing on the cake to declare an incident.

Another tool for picking out malicious use of this utility is event tracing. A word of warning first; ETW events can easily climb to thousands per second. You may want to filter out what is absolutely required before shipping anything to your SIEM of choice.

Figure 5




While csi.exe requires .csx files to run, I would be remiss if I didn't play around with the file extensions.

Figure 6 
The Basics

Assuming we are dealing with a lazy threat actor who finds csi.exe on a victim endpoint who doesn't care about being identified, the same detection opportunities exist.

Figure 7  
 The above image is just a few lines of code to show the ease of C# scripting in creating a network connection and gathering a bit of information. The options for this type of code execution are endless. I did not utilize the interactive capabilities of csi.exe, but one could easily drop into a session, download a DLL or executable in memory (Reflection.Assembly.Load()), and move on with life.

Figure 7
While the DNS query event may seem like an easy win, if csi.exe is allowed in your network, developers could quite often create scripts to pull down other tools.

Silky Smooth

The intent of this post is not to go too far into ETW as a great number of posts have covered the topic in depth. I would like to point out some interesting events that can be of interest if proper filtering (and RAM) is utilized properly.

Figure 8
Unfortunately there is a lack of solid detection logic behind ETW events when it comes to what is or isn't malicious in .NET. Event tracing provides the analyst with an overwhelming view into assemblies loaded/unloaded, AppDomains, and PDB paths.

The loading of System.Management.Automation, a PowerShell class being loaded under a .NET process would probably be an event to look into.

Figure 9
If for some reason an analyst was not able to view the path for the csi process in Sysmon, tracing provides full command line monitoring.

Conclusion

CSI.exe provides a number of options to developers and threat actors alike. The purpose of this post was not to break ground on anything new, but to answer questions I had on gaining visibility into .NET tradecraft. Hopefully this helps to shed some light on detecting malicious C# and others will join in.

Links

- https://www.blackhillsinfosec.com/red-teamers-cookbook-byoi-bring-your-own-interpreter/
- https://blog.f-secure.com/detecting-malicious-use-of-net-part-1/
- https://redcanary.com/blog/detecting-attacks-leveraging-the-net-framework/
- https://enigma0x3.net/2016/11/21/bypassing-application-whitelisting-by-using-rcsi-exe/
- http://www.exploit-monday.com/2016/09/using-device-guard-to-mitigate-against.html
- https://github.com/fireeye/SilkETW
- https://blog.iisreset.me/tracing-as-a-service-with-silketw-pt/

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...