OffensiveDLR

Toolbox containing research notes & PoC code for weaponizing .NET's DLR

447
108
PowerShell

OffensiveDLR

Toolbox containing research notes & PoC code for weaponizing .NET’s DLR

Contents

Script Description
Kukulkan A slimmed down version of SILENTTRINITY, C# DLL & EXE that embed an IPY engine. Comms are encrypted and can be used with CobaltStrike
Invoke-JumpScare.ps1 Executes shellcode using an embedded Boolang compiler, nothing touches disk (at least from what I’ve seen) and no calls to csc.exe are made 😃
Invoke-IronPython.ps1 Executes IronPython code using the embedded IPY engine. Same concept as Invoke-JumpScare only using IronPython.
Invoke-ClearScript.ps1 Executes JScript (or VBScript) using the embedded ClearScript engine
SharpSnek.cs C# code that embedes an IronPython engine and executes embedded IPY code. Hooks AppDomain.CurrentDomain.AssemblyResolve to resolve needed Assemblies at runtime.
runBoo.cs C# version of Invoke-JumpScare. Executes shellcode using an embedded Boolang compiler.
runBooAssemblyResolve.cs C# code that embeds a Boolang compiler and executes embedded Boolang code. Hooks AppDomain.CurrentDomain.AssemblyResolve to resolve needed Assemblies at runtime.
minidump.boo Native Boolang script to dump memory using MiniDumpWriteDump
shellcode.boo Native Boolang script that executes shellcode. Currently contains 3 diffrent techniques (QueueUserAPC, CreateThread/WaitForSingleObject, WriteProcessMemory/CreateRemoteThread)
Invoke-SSharp.ps1 Executes SSharp from an embedded compiler within PowerShell. Compilation does not call csc.exe
Invoke-Boolang.ps1 Executes Boo code from an embedded compiler. It also provides workarounds for some bugs I discovered when the Boolang compiler get’s embedded within PowerShell.
Invoke-NeoLua.ps1 Executes Lua code from an embedded compiler within PowerShell.

Why?

The .NET DLR is just straight up bonkers, it allows you to do crazy things like embed freaking compilers/engines within other .NET languages (e.g PowerShell & C#) while still remaining Opsec safe & staying in memory.
In IronPython’s case, you can even have what I call ‘engine inception’: wanna embed a IPY engine within an IPY engine within another IPY engine? (yo dawg, I heard you liked IPY engines…).

From an offensive perspective this has an insane amount of flexibility and a number of advantages, to name a few:

  1. Out-of-the-box access to the .NET API, without going through Powershell in anyway. Essentially, using the DLR allows you to have all the power of Powershell, only without Powershell and in a language that’s (usually) easier to script in (e.g. Python)

  2. Crazy amounts of reflection/embedding going on all the time, which means more evasion.

  3. Using the DLR you always bypass AMSI (if you properly instrument your payloads), no need to obfuscate, patch stuff etc…

  4. All your ‘evil’ can be coded in the language of your embedded engine/compiler. If you do this using PowerShell, ScriptBlock Logging sees nothing since all the magic happens in the DLR.

  5. Usually, all of the DLR languages have a way of calling native methods either through the language itself or by dynamically compiling C# (e.g PowerShell’s Add-Type).
    If you go with the former method no calls to csc.exe are made and usually nothing is dropped to disk as the languages generate everything needed in memory through IL code.
    We can go as “…low and high as we want…” (@Op_nomad) & this allows us to do all the good stuff we all love (inject shellcode, unmanaged DLLs, load PEs etc…)

  6. Allows for quick re-tooling and weaponization of payloads. No manual compilation is necessary.

Other Offensive DLR projects

If you’re interested in this, here’s some other tools that also try to weponize the DLR:

Credits

  • @Op_nomad
  • @subtee
  • @pwndizzle
  • @malcomvetter
  • @harmj0y
  • @elitest

References

Fair warning, if you start reading this stuff it’s gonna send you down a hellish rabbit hole (with actual deamon rabbits).

Talks