Here we are finally at the last part of my series on backdooring dll files. I wanted to cover again detours as a means of backdooring dll files and executables. A fellow 2600 member I spoke to asked me the other day about what it would take to modify an exe without changing it on disk. For that I say detours! That’s what I’m going to do this in example, on top of popping a message box up, I’m also going to pop a shell.
Recall that we covered this once before. All I’m doing is slightly modifying the detours code from before to include some shellcode from MSF. I also modified the launcher slightly because of a unicode conversion error. I’ll link all projects source and all towards the end. We’re of course modifying our detours project to allow for shellcode to be implanted. Sure we *could* do our own shellcode right there in the dll with inline assembly, but MSF does a better job than me.
You’ll notice how we don’t directly place our shellcode in the stack. This is because doing so will fail. Modern Windows employs the use of Data Execution Prevention (DEP) which prevents execution in the stack. To get around this, we allocate a chunk of memory and mark it read write execute. We’ll be doing the same thing with .net.
As an added bonus, I’m going to go over backdooring a .Net class library / .net executable. I will be using Red Gate Reflector and the reflector plugin Reflexil. Reflexil also works for IlSpy as well if you’re cheap and like free stuff. DnSpy doesn’t work for my examples because its a piece of shit.
The obvious thing that comes to mind is “joe, how in the hell are we supposed to inline shellcode for a backdoor into a managed language that doesn’t even support inline assembly?” and to that I say good point. But there’s more than one way to skin a cat.
There are 2 ways to run shellcode in a C# application. The first way is to use C and inline assembly and pointers and such, then compile your code as a dll and call the dll from within your C# application. Imagine calling a dll within a dll. Inception and shit.
The other way to do it is:
- Define an array of bytes (our shellcode)
- Allocate a chunk of memory (length of shellcode)
- Set the memory protection flags on the chunk as Read Write Execute
- Write the array of bytes (our shellcode) into this same allocated chunk
- Create a thread, setting the ‘LpStartAddress’ to our chunk of memory.
Side note – there are 2 other variations on this that have similar results. We could call CreateRemoteThread and inject into an already running process such as the host process or explorer or whatever. We could also create a suspended process of something (svchost.exe, or whatever) and write our code in there. In fact that’s how JoeCrypt works with its wrapper around executables.
First things first, we need some shellcode. In following with the ‘backdoor’ theme, I’m choosing a simple single stage TCP bind shell. MSF is nice enough to provide us with a C# output via its ‘generate’ application. Thanks HDM.
Now that we have our app, how do we get it into an existing managed library? Same way we do it with regular .net exes? Haven’t I been over this subject before?
So how do we inject into a managed dll? We don’t. Reflexil doesn’t allow the use of the ‘dllimport’ directive in its generated code. It fails to add a proper reference in the .net metadata section for imported dll references. It looks like it would work at first, producing what looks like working MSIL code: But oh no it doesn’t work. This is a reflexil bug.
Well fuck. What can we do? I tried with DnSpy, but god damn, same problem.
We could always just compile our code as a dll and straight up replace it with the name of another C# class library. So how could we technically backdoor a C# dll? We would have to look for unsafe calls to Assembly.LoadFile or Assembly.LoadFrom and ensure our dll is called instead. As for backdooring a .net exe, your best bet looks like total replacement of the exe if we do it this way.
There is another way however. We don’t need shellcode to pop a shell – the .net framework should have everything we need. Luckily for us in C#, spawning a remote socket and process is trivial.
We’re going to backdoor my JoeHasher app. Loading the thing into Reflector, we locate the method associated with ‘cancel’ and see its for a background worker cancellation instructions. This is a suitable spot.
Select the method in the tree view, bring up Reflexil from the file menu (tools->Reflexil), right click and select “Replace all with code”.
Now press ‘ok’ and right click on the module in the tree menu, choose the Reflexil menu, then click ‘Save as…’. This will save our work.
Running our patched ‘JoeHasher’ app and clicking the ‘Cancel’ button does exactly what we want, spawns a shell on port 31337.
So that’s how you backdoor a .net binary. For a .net class library, you do the exact same – find a method that looks suitable, and replace with your backdooring code. Shellcode is nice, but not necessary for our needs of spawning a cmd shell.
Hope you all learned something. Attached here are all the files. The detours launcher, dll, source for both, the C# shellcode app and source, the C# cmd shell app / source, and the backdoored c# hasher / regular hasher thingy.