DLL Injection Methods - Test Apps (Discussion)

So now that Windows 10 has reached version 1709 (Fall Creators Update), I have been having a harder time finding DLL Injection Test Apps that will even work successfully on a fully updated 64-bit Windows 10 machine. These apps are either crashing or failing to inject DLLs entirely, likely due to enhanced ASLR mitigations, Control Flow Guard, and such.

Does anyone know of any relatively current DLL Injections Test Apps (GUI preferably, but command line is OK too) that will work on the latest Windows 10 64-bit version 1709 (Fall Creators Update) with both 32-bit and 64-bit apps successfully?

This thread could be used as a current discussion thread as well, I suppose. Please remember not to link directly to any executables though. But it would be good to discuss which DLL Injections Test Apps are reputable, relatively trustworthy (open source), and working successfully on current Windows 10 builds.

It would be good to have a variety of different DLL injection methods to choose from.

I have recently compiled some older (2-3 year old) DLL Injection Test Apps from Github which were command line tools. Some work, some don't. But one thing which is good is that I was able to compile some good DLLs that are safe to inject into processes, both 32-bit DLL and 64-bit, which will show a popup when injected successfully.

RemoteDLL, one of the reputable DLL Injection Test Apps does not work on Windows 10 64-bit version 1709. The latest RemoteDLL version or older versions, they all fail. Well, the 32-bit RemoteDLL does work successfully but the 64-bit version crashes consistently on 1709 and I have had zero luck with it.

On a side note, I had tested several command line DLL Injection Test Apps with Reflective DLL injection and both apps were successful to inject which was great for testing. MemProtect blocked the Reflective DLL injection 100% of the time. But I would really like to test a wider variety of injection methods.

 

This is a great one: https://github.com/countercept/doublepulsar-usermode-injector. This is supposed to be able to inject a non-reflective .dll using reflective .dll injection. I could not get that part to work and resorted to having to use a test reflective .dll. Note you have to supply your own .dlls; I used a message box one.

Note that what is neat about this user mode DoublePulsar based utility is it doesn't actually inject the .dll into another process. Rather it hooks a thread into targeted process and runs the test .dll in the test utility.

Original DoublePulsar write up analysis here which was the basis for creation of the test utility: https://www.countercept.com/our-thi...rmode-analysis-generic-reflective-dll-loader/

 

@itman That is a perfect (and safe) testing example. Great stuff. Thank you, sir!


EDIT: Even better, this also has a CreateRemoteProcess option to test instead of just the APC method utilized by original DOUBLEPULSAR.

 

Actually, APC works great using a reflective .dll. I just couldn't get it to work with a regular .dll on Win 10 1703 which is what I was running at the time. Had conversations with the utility developer and it worked fine on his test build with the .dll I was using.

As I understand it, APC does not involve the use of a hook. I didn't test this using WDEG, so please report back on if it detected any of its activities. I do know Eset's HIPS detected the thread setting activities for processes I manually defined to detect process modification activities.

 

Best (current) command line tool I've found and tested so far.

I have compiled this code myself with VS2017 from:
Web site: https://github.com/fdiskyou/injectAllTheThings

Features (DLL injection methods):

Code:

Method                 | 32 bits | 64 bits |  DLL to use                     |
-----------------------|---------|---------|---------------------------------|
 CreateRemoteThread()  |    +    |    +    | dllmain32.dll / dllmain64.dll |
 NtCreateThreadEx()    |    +    |    +    | dllmain32.dll / dllmain64.dll |
 QueueUserAPC()        |    +    |    +    | dllmain32.dll / dllmain64.dll |
 SetWindowsHookEx()    |    +    |    +    |  dllpoc32.dll / dllpoc64.dll  |
 RtlCreateUserThread() |    +    |    +    | dllmain32.dll / dllmain64.dll |
 SetThreadContext()    |    +    |    +    | dllmain32.dll / dllmain64.dll |
 Reflective DLL        |    +    |    +    |    rdll32.dll / rdll64.dll    |

Usage: inject32.exe -t <option> <process name> <full/path/to/dll>

Download: https://mega.nz/#!y4J11ZwY!Y1gR4NTU_neGrDza-69_6p2GYOxh_LSg8ioK7ia3C6w

Archive Hash SHA256 to check at VT (since VT link now allowed):

c844223975c2f45d59c48965f8a881452d6ac2a96da87f5fde7a36e42541e701

Archive Password: InjectAllTheThings2018


My personally tested, working commands:

Code:

Working Commands (modify <full/path/to/dll> accordingly):

#    1     DLL injection via CreateRemoteThread()
inject32.exe -t 1 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain32.dll
inject64.exe -t 1 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain64.dll

#    2     DLL injection via NtCreateThreadEx()
inject32.exe -t 2 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain32.dll (failed - RemoteDll32 OK)
inject64.exe -t 2 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain64.dll (failed - RemoteDll32 OK)

#    3     DLL injection via QueueUserAPC()
inject32.exe -t 3 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain32.dll
inject64.exe -t 3 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain64.dll

#    4     DLL injection via SetWindowsHookEx()
inject32.exe -t 4 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllpoc32.dll
inject64.exe -t 4 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllpoc64.dll

#    5     DLL injection via RtlCreateUserThread()
inject32.exe -t 5 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain32.dll
inject64.exe -t 5 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain64.dll

#    6     DLL injection via Code Cave SetThreadContext()
inject32.exe -t 6 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain32.dll
inject64.exe -t 6 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\dllmain64.dll

#    7     Reflective DLL injection
inject32.exe -t 7 speedyfox.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\rdll32.dll
inject64.exe -t 7 ProduKey.exe D:\RemoteDLL\Tools\InjectAllTheThings\dll\rdll64.dll

Only number 2 (DLL injection via NtCreateThreadEx() injection method failed for me. But I was able to achieve and test this with RemoteDLL32 anyway. All others, both 32-bit and 64-bit worked successfully on an up-to-date Windows 10 1709 64-bit build.

Although it is command line, this is the most fully featured I've found yet with many injection techniques.

 

Very interesting article that's mentioned on that site! I believe that HIPS should at least monitor all the techniques that were mentioned. But I'm afraid that other more advanced code injection methods are not that easy to monitor.

http://blog.deniable.org/blog/2017/07/16/inject-all-the-things/

Did it auto-block it without any alerts? One problem is that HIPS can only block certain DLL injection methods if they monitor the "Open and Read Process" API, but that's way too common and will give a lot of false positive alerts.

 

Thank you for this suggestion of Extreme Injector. I would suggest removing the link to that web site though because I believe it must be a fake web site not affiliated with the official Extreme Injector because the download stub that they serve from that site only downloads an ancient version of VLC Media Player in an unofficially packaged method.

Anyway, Extreme Injector turns out to be quite nice and the good thing about it is that it gets updated regularly by its developer, including recent updates for Windows 10 Fall Creators Update, etc. I had not used Extreme Injector previously likely because I was thrown off months ago by that shady web site. I would suggest to link to it's official Github page:

Link: https://github.com/master131/ExtremeInjector

From there, the official downloads are hosted on two different gaming forums. Unfortunately, you must create an account first prior to downloading. So I would suggest anybody to use a scrap email account of some sort if they need to sign up. However, those are the official download mirrors and the binary itself works great.

Here are some details of features and injection methods as posted on the gaming forums:

Naturally, I decided to test Extreme Injector (3.7.3) against MemProtect. First, I tested it without MemProtect on so that I could ensure that all injection methods were working successfully on the latest Windows 10 Fall Creators Update (1709) 64-bit Pro. I tested with 32-bit process injection and 64-bit as well and all injection methods worked successfully and accurately each time. So that confirms that Extreme Injector works as expected on the latest Windows platform.

I tested with MemProtect after which was a bit difficult because MemProtect would not even allow Extreme Injector to obtain the PID for speedyfox.exe since the GUI for the injector continuously polls for PID changes based on the process name. MemProtect blocks all of that action. So for each injection test, I had to disable MemProtect, allow the injector to find the PID, choose 1 of the 5 injection methods, re-enable MemProtect, and test injection. Each time, I would then close out of speedyfox.exe and Extreme Injection to start fresh and go through the same procedure.

MemProtect ended up blocking all of the injection methods from Extreme Injector, including the various tweaks within each injection method to try as many options as possible from that program. It's certainly a great DLL injection program with a nice GUI.

If anyone needs some "safe" DLLs for testing injection for both 32-bit and 64-bit, you can get those from my post number 5 in this thread, included in the InjectAllTheThings archive. Those DLLs, once injected, show a small popup to suggest that injection was successful.

MemProtect blocked all without any alerts. I run MemProtect (and Bouncer) with a special flag that disables the detailed system toast/balloon popups. Some users prefer those detailed popups but I prefer to silence them. So I have MemProtect blocking memory access with zero popups. The only indication that I keep is the green icon turning red to indicate blockage to me.

Here are the memory access restrictions of MemProtect:

Code:

The system restricts access to protected processes and the
threads of protected processes. The following standard access rights are
not allowed from a process to a protected process:

-DELETE
-READ_CONTROL
-WRITE_DAC
-WRITE_OWNER
-SYNCHRONIZE

The following specific access rights are not allowed from a process to a
protected process:

-PROCESS_ALL_ACCESS
-PROCESS_CREATE_PROCESS
-PROCESS_CREATE_THREAD
-PROCESS_DUP_HANDLE
-PROCESS_QUERY_INFORMATION
-PROCESS_SET_INFORMATION
-PROCESS_SET_QUOTA
-PROCESS_VM_OPERATION
-PROCESS_VM_READ
-PROCESS_VM_WRITE

Recently, I found an (old) article by Mark Russinovich online which describes some of these memory access restrictions in more detail than I was initially aware of.

 

You can also download .dlls from www.matousec.com test to use. You can download the .dlls from the test they use.

 

My bad, I have removed the post, should have checked it first.

Pretty cool, this means that MemProtect truly offers solid protection. Is it possible for you to test SpyShelter? It doesn't have an option to auto-block, but it should at least give an alert about DLL Injection. BTW, which processes do you protect with MemProtect? Because there are also legitimate apps that need to modify explorer.exe, so that would be a problem I suppose.

 

You can see how it performs against Atom Bombing: https://blog.ensilo.com/atombombing-brand-new-code-injection-for-windows

 

I am curious about testing this out. However, I tried several times to compile the atom-bombing sources and it failed each time while compiling. It seems from the errors that it is missing some important source files needed to compile. I also tried to find some pre-compiled binaries but was not able to find any. I can assume that, due to the nature of these PoC's, they would want to keep these out of the hands of most people.

 

I guess atom bombing detection can best be summarized as:

https://www.carbonblack.com/2016/11/15/largely-hyped-atombombing-new-variation-old-technique/

I assumed most AV HIPS's have been modified to now monitor NtQueueApcThread API usage.

 

Yes, I would think so as well. NtQueueApcThread is blocked by MemProtect. As long as there is any kind of process to process memory communication at all then it would be blocked accordingly.

The only time in which MemProtect and other memory protection software would be essentially guaranteed to fail is something such as Spectre which is utilizing an underlying hardware flaw or also when it comes to kernel exploits. Hypervisor exploits as well, for that matter. However, kernel and hypervisor exploits have become increasingly more expensive year after year.

 

I apologize, but I have zero experience with SpyShelter. I have never actually installed it before. My needs are met with MemProtect, Bouncer, MZWriteScanner, etc. to the point where have had very little desire to try any other security software in quite some time. Which is quite strange because years ago I used to try every security software around (almost) and changed AV's and such far too often. But lately, I just have not had much extra time or any real significant interest in trying anything else.

In theory, you could quite literally run every process as a protected process with MemProtect but that would be one very difficult to manage configuration. I prefer to keep things simple these days so that it's easier to manage and only protect what is worth protecting, particularly web-facing apps. My current configuration is only protecting: Chromium, KeePass, and Thunderbird

Interestingly, I have put them together in a special folder on RAMDisk (although doesn't have to be RAMDisk) so that I can keep my protected processes in a separate location, keeping the config easy to manage.

I don't know if the MemProtect specific discussion is OT for the thread or not, but since the configs can take up some additional room I decided to place those details in a Spoiler tag below.

Spoiler: MemProtect related configuration details

Essentially, here is the memory protection whitelist:

Code:

#   Protected Processes - Chromium, KeePass, and Thunderbird
!C:\Windows\System32\wbem\WmiPrvSE.exe>R:\Program Files\*
!C:\Windows\System32\taskhostw.exe>R:\Program Files\*
!C:\Windows\System32\Taskmgr.exe>R:\Program Files\*
!C:\Windows\System32\svchost.exe>R:\Program Files\*
!C:\Windows\System32\audiodg.exe>R:\Program Files\*
!C:\Windows\System32\csrss.exe>R:\Program Files\*
!C:\Windows\System32\lsass.exe>R:\Program Files\*
!C:\Windows\explorer.exe>R:\Program Files\*
!R:\Program Files\*>R:\Program Files\*

So those protected process apps are only allowed to interact with eachother and with a very small subset of the operating system. So that really is quite minimal and my hope is to reduce attack surface as much as possible. Anything outside of that config above is strictly denied.

Now, a fairly recent addition to MemProtect was the development of a module filter. The idea was similar to EMET ASR (attack surface reduction) feature which essentially allows you to control which modules (DLL's for the most part) are allowed to load into a specific process and you can deny which modules to load as well. This is great for blocking targeted application bypass methods.

My current module filtering whitelist:

Code:

#   Protected Processes - Chromium, KeePass, and Thunderbird
!R:\Program Files\*>R:\Program Files\*
!C:\Windows\explorer.exe>R:\Program Files\*
!R:\Program Files\*>C:\Windows\WinSxS\*.dll
!R:\Program Files\*>C:\Windows\System32\*.ax
!R:\Program Files\*>C:\Windows\System32\*.dll
!R:\Program Files\*>C:\Windows\System32\*.drv
!R:\Program Files\*>C:\Windows\SysWOW64\*.dll
!R:\Program Files\*>C:\Windows\SysWOW64\*.drv
!R:\Program Files\*>C:\Windows\assembly\*.dll
!R:\Program Files\*>C:\Windows\Microsoft.NET\*.dll
!R:\Program Files\*>C:\Program Files\Windows Defender\Mp*.dll
!R:\Program Files\*>C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll

And for both memory protection blacklist and module filtering blacklist, I have protected process > explorer.exe blocked with no ill effects for Chromium, Thunderbird, or KeePass. The $ is also a new development for MemProtect in which is silences any blockages based on this specific rule so that I wont be alerted to it.

Code:

$R:\Program Files\*>C:\Windows\explorer.exe

 

I assume you are using virtual machines to test all of this? If so, you can install SpyShelter without actually having to know anything about it. It will simply alert when it sees some process trying to inject code, or trying to create a remote thread. The question is just how robust it exactly is.

But wouldn't it make sense to also protect explorer.exe and svchost.exe, because they are often targeted? The problem is that sometimes legit apps must modify memory of explorer.exe, so can MemProtect allow them to inject code? That didn't become clear to me.

Nice find, so it wasn't that advanced after all.

 

Process Doppelgänging

https://attack.mitre.org/wiki/All_Techniques

 

Interesting.
Who then uses Windows XP and FAT32 file system should be immune?

 

Good question.

Here's the bleepingcomputer.com write-up on it: https://www.bleepingcomputer.com/ne...g-nging-attack-works-on-all-windows-versions/ . It states all Windows vers. are vulnerable.

However, the API's it uses were introduced in Vista. So I would say that even if NTFS was used in XP, it would not be vulnerable.

Of note is when the bypass was introduce last Dec., no one could stop it. And like atom bombing, OS cannot be patched against it. So the question now is if the AV's with HIPS are monitoring the TxF API? Or, did MS remove the API from at least Win 10 since it is deprecated?

 

From the Blackhat Europe Process Doppelgänging presentation:

Win 10 blue screened initially, but they found a way around that;

Mitigation ....... Does not really sound feasible for AV vendors to even attempt this;

https://www.blackhat.com/docs/eu-17/materials/eu-17-Liberman-Lost-In-Transaction-Process-Doppelganging.pdf

 

I found another great injection testing tool. Again, unfortunately only command line. But super powerful. It's called InjectProc (https://github.com/secrary/InjectProc), is open-source, but also contains binary release so that you don't have to compile it yourself. The main reason for wanting to test more was because this one also has Process Hollowing (although the dev refers to it as Process replacement). I tried several command line test tools which has process hollowing and this one was the best of all.

The instructions provided were not the best which resulted in some users creating issues in the issue tracker. But after playing around for a while, I was able to get all 4 methods working successfully on latest Windows 10 1709 64-bit. This InjectProc tool only works with 64-bit process injections with 64-bit DLL modules. There is no 32-bit support at all but that is fine. 64-bit testing would be more relevant anyway.

Here are the instructions from the command line itself:

Code:

Usage: ./InjectProc.exe <type of injection> <path/to/exe or process_name> <path/to/dll>
                Example:
                ./InjectProc.exe dll_inj path/to/dll.dll notepad.exe
                ./InjectProc.exe proc_rpl path/to/target/exe path/to/exe
                ./InjectProc.exe hook path/to/target/exe path/to//dll
                ./InjectProc.exe APC target/proc/name path/to/dll

These ended up being super specific. Any little mistake to detail and it will fail. So I will provide my working set of commands that work consistently (100% of the time) which anyone testing can utilize and adapt the commands per their own testing setup.

Code:

Working (only 64-bit executables with 64-bit DLL modules):

InjectProc.exe dll_inj D:\RemoteDLL\Tools\InjectProc\mbox.dll ProduKey.exe
InjectProc.exe APC ProduKey.exe D:\RemoteDLL\Tools\InjectProc\mbox.dll
InjectProc.exe proc_rpl D:\RemoteDLL\DenyAll\ProduKey.exe D:\RemoteDLL\DenyAll\shmnview.exe
InjectProc.exe hook D:\RemoteDLL\DenyAll\ProduKey.exe D:\RemoteDLL\Tools\InjectProc\mbox.dll

The Process Hollowing was the proc_rpl command line.

As you can see above, I used Nirsoft's ProduKey and ShellMenuView (shmnview.exe), both being their 64-bit release binaries. I typically use speedyfox.exe for my injection testing, just being a simple portable app, but speedyfox is only 32-bit and therefore failed with testing of this test tool.

So all of those commands were successful in their intended actions

To be honest, I only use my Hyper-V machines for testing Windows Insider builds and for only a small amount of analyzing actual malware actions and such. But for this testing of DLL injection, I am confident about the DLL testing modules that I am using and ensure to use open-source code when possible to ensure safe testing tools.

But I never trust anything 100% and therefore I do have a "safety net" of sorts setup using a few of the Excubits drivers. Quite often I will run MemProtect in logging mode, for example, while keeping Bouncer running in blocking mode for anything outside of the scope that I am testing in case any testing tool does something that it was not documented to do. I've got disk images backed up prior to testing certain tools as well until I've built up more confidence in certain tools.

Yes, absolutely you can use MemProtect to control all memory access to/from explorer.exe and svchost.exe. I recently did some testing with lsass.exe which was successful in testing. The one and only problem here is that those type of rules can become incredibly large and harder to maintain manually. Well, technically you could condense those rulesets and have more lenient rules or you could go the more in depth way of having much larger, more granular rules. That is one thing that I enjoy about the Excubits drivers in general because it puts you in the driver seat to decide entirely which direction you want to take with your rules. Your own fate is, of course, in your own hands. But I thrive off of that responsibility anyhow.

 

So are you stating MemProtect does not prevent Process Hollowing?

 

From my very limited understanding of process hollowing and having testing only a few test examples, so far it seems that MemProtect does not block the process hollowing stage. Since that binary that is being replicated is not actually run from memory; it seems that it is being queried (Read operation) from disk, MemProtect would not pick that stage up. If it was read from memory to memory, that use case would block.

It can block the first stage of the testing but I had to allow that memory action to proceed so that the process hollowing stage would begin.MemProtect stops the first stage but not the actual process hollowing action itself unless it was memory to memory. But being read from a binary on disk, MemProtect would not see that. That is where another file system kernel driver such as Pumpernickel (FIDES) would catch it or also MZWriteScanner but I have not tested that one as of yet.

Interesting stuff though, indeed. I absolutely enjoy the learning experience. And from a pure learning experience, the valuable information that you can get from the logging of any Excubits driver can be truly educational. At the very least, it gives me a great understanding of what is happening under the surface, so to speak.

 

Try using Eset's HIPS. It will block process hollowing since it does indeed monitor any process modification activity against suspended processes. The "rub" is as you mentioned, you have define a rule for any process to be monitored and then of course, create rules for legit processes that perform process modification activity against the monitored process.

 

Now I have temporarily disabled MemProtect protection so that I can allow certain memory operations through for the purpose of testing current Process Mitigations via WDEG in Windows 10 RS3 just for curiosity's sake. This is relatively preliminary in my testing, so I don't have much to discuss yet.

During some of my testing over the past week or so, I noticed that I kept getting some random events in event viewer which were User Mode Mitigation blockages. That particular log for User Mode Mitigations had typically been blank for many months for me. I was more accustomed to mitigation blockages showing up in the Kernel Mode Mitigation blockages log section. So this was my first example of seeing User Mode Mitigation blockages in the log. Anyway, here was the event log detail:

Code:

Process 'D:\RemoteDLL\DenyAll\ProduKey.exe' (PID 9060) was blocked from accessing the Export Address Table for module 'C:\Windows\SYSTEM32\ntdll.dll'.

Therefore we can determine right away that this was the EAF/EAF+ (export address filtering) mitigation that was causing this event. But what I did not know was exactly which type of DLL Injection method caused this because I had been testing various tools over the past week or two and nearly a dozen different injection methods. So essentially I just had to go through my entire testing set until I landed on the method which caused this event/blockage. It turns out that this was the Reflective DLL injection technique which triggered the EAF/EAF+ mitigation blockage.

Another powerful mitigation that came up many times during testing was Control Integrity Guard (CIG) which is essentially blocking the DLL injection of any binaries which are not digitally signed by Microsoft. So this is a powerful mitigation in it's own right and we know also that Google Chrome has also been making use of this mitigation to prevent unsafe injections into chrome.exe as well. As we know, digital signature verification is not the most secure concept these days though since digital signatures can be spoofed in various ways. But that is why the combination of various process mitigations is important to fill in the gaps.

Windows 10 1709 (Fall Creators Update) clearly has added some powerful process mitigations that were brought over from EMET and are now implemented in the kernel. Windows 10 1804 will also be adding some more mitigations but there are not a whole lot of details available yet as far as documentation goes. Also, Microsoft's strategy to bring hardware security via Virtualization Based Security (VBS) to all Windows 10 SKU's (as far as I know) in Windows 10 1804 is going to make for a solid operating system as far as security goes. That will be some serious isolation via hardware virtualization at scale.

Anyway, I've got a whole lot more testing with process mitigations to go still and if I find anything relevant and worthwhile to share I will post again at another time.

 

If you are using this mitigation for your browser for example, beware of the following. Many third party security products inject their own .dlls for protection purposes. Many are not MS code signed. So you could be inadvertently weakening your security product's protection.

I make it a habit to always review the Security - Mitigations log when setting up a process with WDEG app mitigations.