Abstract​

In my previous post, I delineated the primary disadvantage of in-process tool execution, namely, the possibility of a crash. I also sought to present a remedy; however, the proposed solution did not address leftover memory artifacts. Instead, I recommended the migration to another process. The goal of this series is to showcase the construction of a harness for executing .NET assemblies, a common format for post-exploitation tools, in a manner that minimizes memory artifacts. For the first part, the focus will be on the steps that are performed before we start the runtime

Abstract​

In recent years, there has been a shift from the fork and run model to in-process execution. This includes .NET assemblies, beacon object files, among others. Whilst this has been very beneficial OPSEC wise as you avoid the many detection points in the: spawn another process -> inject -> capture output model, it comes at a price. A subtle bug in a post-exploitation tool can cause the process hosting our beacon to become unstable or even crash. This leaves us one unhandled exception away from death.

In this entry, I would like to illustrate an interesting way of monitoring users.

In this post I wish to present my string schema, which has been perceived by many as excessively paranoid.

In this short post I will showcase a fun idea I have been playing with recently. That is, using hardware breakpoints to prevent certain libraries from loading.

This post marks the beginning of my blog and this series. To commemorate this wondrous occasion, I will start by discussing the importance of RAII-based allocators in modern malware design.