Skip to content
Toolbox containing research notes & PoC code for weaponizing .NET's DLR
PowerShell C# Other
Branch: master
Clone or download
Latest commit efb5913 Feb 5, 2020
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
Kukulkan Updated payload server readme Jan 25, 2019
ClearScript.cs Update ClearScript.cs Jul 10, 2019
Invoke-Boolang.ps1 Update Invoke-Boolang.ps1 Jan 15, 2020
Invoke-ClearScript.ps1 Added Invoke-ClearScript.ps1 May 15, 2019
Invoke-IronPython.ps1
Invoke-JumpScare.ps1 Typo squash, Readme updates, added Invoke-IronPython.ps1 Dec 6, 2018
Invoke-NeoLua.ps1 Added Invoke-NeoLua.ps1 Feb 4, 2020
Invoke-SSharp.ps1 Create Invoke-SSharp.ps1 Jan 21, 2020
LICENSE Added License Dec 6, 2018
README.md Added Invoke-NeoLua.ps1 Feb 4, 2020
SharpSnek.cs Added build instructions to SharpSnek.cs Dec 8, 2018
minidump.boo Typo squash, Readme updates, added Invoke-IronPython.ps1 Dec 6, 2018
runBoo.cs Added SharpSnek.cs Dec 8, 2018
runBooAssemblyResolve.cs Added runBooAssemblyResolve.cs Dec 8, 2018
shellcode.boo Initial Commit Dec 6, 2018

README.md

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

You can’t perform that action at this time.