SharpSploit is a .NET post-exploitation library written in C# that aims to highlight the attack surface of .NET and make the use of offensive .NET easier for red teamers.

It is named, in part, as a homage to the PowerSploit project, a personal favorite of mine! While SharpSploit does port over some functionality from PowerSploit, my intention is not at all to create a direct port of PowerSploit. It will be it’s own project, albeit with similar goals to PowerSploit.

SharpSploit Appeal of C#

There seems to be a trend developing on the offensive side of the security community in porting existing PowerShell toolsets to C#. And SharpSploit is another piece to that puzzle. With the added security features in PowerShell (ie. ScriptBlock Logging, AMSI, etc.), it makes sense that red teamers are investing in other options. And C# is the logical next step from PowerShell, seeing that they both are based on the .NET framework and porting toolsets from PowerShell to C# is fairly easy to do.

However, C# does not come without it’s own set of issues from an offensive perspective. It certainly seems as if optics into .NET are on the way, and from an operator usability perspective we lose quite a bit of flexibility moving from a scripting language like PowerShell to a compiled language like C#.

We also need to start worrying about .NET versions. You’ll find .NET v3.5 on a majority of Windows OS versions by default, but newer Windows 10 and Server 2016 systems will only have .NET v4.0+ installed by default. Another “gotcha” is that .NET is not enabled by default on all Windows OS versions either, you’ll find that it needs to be explicitly enabled on Windows Server 2008 and earlier server OS versions. SharpSploit attempts to deal with this by targeting .NET v3.5 and v4.0 to get the most coverage possible, but you’ll need to be careful to use the correct version on the correct system.

SharpSploit Console or Not to Console?

The most significant difference you will see between SharpSploit and most other offensive C# libraries that have been released so far, is that there is no SharpSploit.exe! SharpSploit is designed as a library, so there is only a SharpSploit.dll.

My intention is for SharpSploit to be primarily used as a library for operators to reference in their own toolsets. However, I anticipate some limitations from this implementation that will likely force me to add a console-based interface eventually. For instance, Cobalt Strike’s execute-assembly module expects an application to have an EntryPoint (i.e. “main” function) to execute, so SharpSploit currently does not operate easily with Cobalt Strike. This is a great example of some of the flexibility issues with offensive C# we will have to solve in the transition from PowerShell.

Try not to worry about this too much for now, you’ll see some other creative methods for SharpSploit execution from me here in the near future 🙂 And I will likely add a follow-up post at some point on convenient methods for executing SharpSploit functions.