Some of you love it and some of you hate it, but at this point it should come as no surprise that .NET tradecraft is here to stay a little longer than anticipated. The .NET framework is an integral part of Microsoft’s operating system with the most recent release of .NET being .NET core. Core is the cross-platform successor to the .NET Framework that brings .NET to Linux and macOS as well. This now makes .NET more popular than ever for post exploitation tradecraft among adversaries and red teams. This blog will dive into a new Beacon Object File (BOF) that allows operators to execute .NET assemblies in process via Cobalt Strike versus the traditional built-in execute-assembly module, which uses the fork and run technique.
Background
Cobalt Strike, a popular adversary simulation software, recognized the trend of red teams moving away from PowerShell tooling in favor of C# due to the increase in detection capability for PowerShell, and in 2018 with Cobalt Strike version 3.11 introduced the execute-assembly module. This allowed operators to take advantage of the power of post-exploitation .NET assemblies by executing them in memory without having the added risk of dropping those tools to disk. While the capability of loading .NET assemblies in memory via unmanaged code wasn’t new or unknown at the time of release, I would say Cobalt Strike brought the capability to the mainstream and helped continue to fuel the popularity of .NET for post-exploitation tradecraft.
Cobalt Strike’s execute-assembly module uses the fork and run technique, which is to spawn a new sacrificial process, inject your post-exploitation malicious code into that new process, execute your malicious code and when finished, kill the new process. This has both its benefits and its drawbacks. The benefit to the fork a ..
Support the originator by clicking the read the rest link below.
