Recently I've been looking at the .NET CLR internals and wanted to understand what further techniques may be available for executing unmanaged code from the managed runtime. This post contains a snipped of some of the weird techniques that I found.

In this post, we are going to look at the Application Proxy protocol, how it works, and show how we can recreate enough functionality to allow us to create a custom inbound proxy into a client environment for our C2 traffic.

We've all been there, you've completed your initial recon, sent in your emails to gather those leaked HTTP headers, spent an age configuring your malleable profile to be just right, set up your CDNs and spun up your redirectors. Then it's time, you send in your email aaaaaand... nothing.

For a while I've wanted to explore the concept of leveraging a virtual machine on target during an engagement. The thought of having implant logic self-contained and running under a different OS to the base seems pretty interesting. But more so, I've been curious as to just how far traditional AV and EDR can go to detect malicious activity when running from a different virtual environment. While this is a nice idea, the issues with creating this type of malware are obvious, with increased comple...

While working on some tooling recently I revisited the topic of .NET unmanaged exports and wanted to know just why this works in the way that it does. After all, by now we've all seen the COM calls required to spin up the CLR, so what makes unmanaged exports so special?