Home Malware Analysis Projects About

Identifying and Extracting the execute-assembly Reflective DLL

Table of Contents


This will be a short one, but what I wanted to do here is grab the component of Cobalt Strike which is responsible for execute-assembly. The goal here is both for detection, but also to see if Cobalt Strike does anything fancy in their implementation as opposed to the publicly available redos:

Cobalt Strike will infamously use a Fork & Run method when running some/most of its Post Exploitation techniques. Beacon Object Files are the proposed solution to this, but are not the focus of this blog. So, as it is known that Fork & Run will be used, likely some kind of injection is being done to have that CLR load in a remote process. Naturally, I'll go ahead with the assumption that the CLR loaded is from a Reflective DLL.

The dotnet

Before poking at Cobalt Strike, the following dotnet code will be used to keep the forked process alive so it can be debugged effectively:

using System;

namespace dotnet_sleep_debug
    internal class Program
        static void Main()

If this was to be ran with Cobalt Strike, the spawnto value will be used to create a process, and inject whatever capability into it:

In this case, RuntimeBroker.exe is the infected process running the Cobalt Strike beacon, and PresentationHost.exe is the spawnto setting.

Searching for the dotnet_sleep_debug namespace:

Extracting the DLL

I'm not that good at Process Hacker'ing and didn't fancy tracking down the addresses so I moved onto more of a whim search: assembly. This was immediately more lucrative:

invokeassembly.x64.dll can be seen within the process. Further on ReflectiveLoader can also be found:


Googling invokeassembly.x64.dll results in RastaMouse tweeting about it:

The invokeassembly.x64.dll string is at 0x1f0936b6a22, locating this:

A PE can be found pretty easily with the MZ Header and DOS Message just hanging out at the base. To save this as a bin, I just hit Save...

Opening the bin file in PE Studio confirms this is a well-and-true DLL:

To confirm this is the CLR, here is the function in IDA:

I have written about implementing a CLR Reflective DLL before:

  • Common Language Runtime #1: An Introduction
  • Common Language Runtime #2: In Memory Execution
  • Common Language Runtime #3: Finalising the CLR Harness
  • Now that I have what I came for, I wanted to check it on VirusTotal before I go through it: ffb43c8c419b934a07f7432c75b834f4068b775991f7f716839fae7594242c1c


    Thats it... A quick blog on how I extracted the execute-assembly Reflective DLL. Looking at the results on VirusTotal, it seems that it was mainly matched on Yara Rules for ReflectiveLoader, specfically: Neo23x0/signature-base/blob/4f0f0ce2c154ca098b3c13f62e44ea383d8b8772/yara/gen_loaders.yar#L14.

    Finally, here is the vendor detections: