Donut v1.0 releases: Generates x86 and x64 position-independent shellcode
Donut is a shellcode generation tool that creates x86 or x64 shellcode payloads from .NET Assemblies. This shellcode may be used to inject the Assembly into arbitrary Windows processes. Given an arbitrary .NET Assembly, parameters, and an entry point (such as Program.Main), it produces position-independent shellcode that loads it from memory. The .NET Assembly can either be staged from a URL or stageless by being embedded directly in the shellcode. Either way, the .NET Assembly is encrypted with the Chaskey block cipher and a 128-bit randomly generated key. After the Assembly is loaded through the CLR, the original reference is erased from memory to deter memory scanners. The Assembly is loaded into a new Application Domain to allow for running Assemblies in disposable AppDomains.
How it Works
Unmanaged Hosting API
Microsoft provides an API known as the Unmanaged CLR Hosting API. This API allows for unmanaged code (such as C or C++) to host, inspect, configure, and use Common Language Runtimes. It is a legitimate API that can be used for many purposes. Microsoft uses it for several of their products, and other companies use it to design custom loaders for their programs. It can be used to improve the performance of .NET applications, create sandboxes, or just do weird stuff. We do the latter.
One of the things it can do is manually load .NET Assemblies into arbitrary Application Domains. It can do this either from disk or from memory. We utilize its capability for loading from memory to load your payload without touching disk.
To see a standalone example of an Unmanaged CLR Hosting Assembly loader, check out Casey Smith’s repo: AssemblyLoader
CLR Injection
The first action that donut’s shellcode takes is to load the CLR. Unless the user specifies the exact runtime version to use, v4.0.30319 of the CLR will be used by default, which supports the versions 4.0+ of .NET. If the attempt to load a specific version fails, then donut will attempt to use whichever one is available on the system. Once the CLR is loaded, the shellcode creates a new Application Domain. At this point, the .NET Assembly payload must be obtained. If the user provided a staging URL, then the Assembly is downloaded from it. Otherwise, it is obtained from memory. Either way, it will loaded into the new AppDomain. After the Assembly is loaded but before it is run, the decrypted copy will be released and later freed from memory with VirtualFree to deter memory scanners. Finally, the Entry Point specified by the user will be invoked along with any provided parameters.
If the CLR is already loaded into the host process, then donut’s shellcode will still work. The .NET Assembly will just be loaded into a new Application Domain within the managed process. .NET is designed to allow for .NET Assemblies built for multiple versions of .NET to run simultaneously in the same process. As such, your payload should always run no matter the process’s state before injection.
Shellcode Generation
The logic above describes how the shellcode generated by donut works. That logic is defined in payload.exe. To get the shellcode, exe2h extracts the compiled machine code from the .text segment in payload.exe and saves it as a C array to a C header file. donut combines the shellcode with a Donut Instance (a configuration for the shellcode) and a Donut Module (a structure containing the .NET assembly, class name, method name and any parameters).
Changelog v1.0
Version v1.0 “Cruller” of Donut has been released, including Module Overloading for native PEs, ETW bypasses, a Dockerfile, support for binaries without relocation information, and many other minor improvements and bugfixes.
Copyright (c) 2019, TheWover, Odzhan. All rights reserved.
