DLL Injection Methods - Test Apps (Discussion)

Excubits protections are indeed rock solid. Somehow I always expected a good wizard in the windows driver arts would Come Forward! and make a huge splash and their tools live up to the metal test.

But as @itman points out, even in this little powershell exhibition, many mainstream commercially popular security solutions likely miss it.

He is done some study on this so I can't vouch on the particular security solutions it would run on without some alert being raised but apparently there are.

 

What I was interested in and no one has responded to yet is if their security solution detected the .Net global keylogger activity. Powershell use and detection of it was not the objective.

 

The problem is that there's absolutely nothing special about this "Powershell .Net keylogger", because it makes use of global hooking just like most other keyloggers. Tools like SpyShelter and KeyScrambler will most likely block it. Let's move on.

 

Test it against SpyShelter and report back. Then we can move on.

KeyScambler doesn't prevent keylogging. It scrambles any keystrokes captured by it. Eset's banking protection for browsers works the same way. I used this Powershell keylogger to test what it captured from keystrokes entered into the browser. Also, I believe SpyShelter doesn't block global keylogging but also scrambles keystrokes for all apps.

 

That is very true @Rasheed187 however I think @itman is eluding to this example as one of many toward all the systems out there that likely are not so equipped with specialized tools designed specifically against this type threat for such purposes. If I read him right.

 

I am going to wrap up the PowerShell .Net based global keylogger discussion by first noting that these are kernel mode keyloggers that hook user32.dll resident in kernel space prior to its loading into a process at startup time. Unlike non-PowerShell based kernel mode global keyloggers that hooked user32.dll via a kernel mode driver, there is no way to stop PowerShell .Net based global keyloggers other than blocking PowerShell execution, only effective for local based execution of it, or deploying Constrained Language mode.

Assume that any PowerShell keylogging script code deployed by an attacker will be packed, possibly encrypted, and obfuscated rendering direct scanning of it by AV scanners ineffective. AV realtime scanning of like scripts running on Win 8.1 or 10 might be effective in detection if they employ the AMSI interface and are effective against highly obfuscated scripts; many are not. Finally, they must have signatures for the C# code being used and malware developers are constantly "tweaking" their code to avoid detection.

Additionally, Constrained Language mode is only effective against C# .Net code contained in a PowerShell script that is using PowerShell assemblies. Those same PowerShell assemblies can be called directly in a C language program thereby bypassing any Constrained Language mode restrictions which is only applicable to .Net execution.

There are two types of PowerShell global keyloggers that are referred to in this article as Type 1 and Type 2: https://www.tarlogic.com/en/blog/how-to-create-keylogger-in-powershell/ .

The Type 2 PowerShell global keylogger is the code I posted previously. It was developed way back in 2013 by Peter Hinchley, works on any vers. of Powershell and .Net on any Win OS ver. as long as .Net is installed, and Powershell exists, can be downloaded or remotely executed: https://hinchley.net/articles/creating-a-key-logger-via-a-global-system-hook-using-powershell/. No need to discuss Type 2 further.

The Type 1 keylogger is:

Note the references to use by Empire and Nishang; favorites of both pentesters and hackers alike. Interestingly, the article author prefers the Type 2 keylogger using the old function SetWindowsHookEx API over the Type 1 global keylogger.

 

Yes, we all know this, but the point is that if keys are scrambled they are useless, so no need to nitpick! And SS does block global hooking, just like any other HIPS, think of Process Guard and System Safety Monitor to name a few.

I have now tried to explain numerous of times that both methods that are used by these "fancy" PowerShell keyloggers are used by most other keyloggers, so I don't see why SS and KS would fail to block it. They either use direct keyboard recording or global hooking, type 1 and type 2.

I have quickly read the articles, but I didn't see any reference to the kernel, so I assume they are both user-mode keyloggers, I think you're wrong about this.

 

Appears folks over at malwaretips.com are following my postings in this thread in regards to C# code global keylogger bypassing via Powershell. Came across this recent posting by a tester there showing Carbon Black being bypassed by same:

Carbon Black CB Defense Bypass - Custom C# Keylogger Deployment
https://malwaretips.com/threads/carbon-black-cb-defense-bypass-custom-c-keylogger-deployment.81438/

What caught my eye was a comment made there hidden in a spoiler tab:

Hum ........ I knew about WDEG's extension point mitigation that is "supposed" to block SetWindowsHookEx, etc.. use at the app level. In fact, I have it enabled for IE11. But, never thought of globally employing it via the MitigationOptions reg. key option. So I set it on, rebooted, and then retested my with above posted PowerShell C# global keylogger code.

Guess what? It did not prevent the global keylogger from capturing keystrokes in IE11. No real surprise to me since I assumed Microsoft excluded WDEG mitigations from Win utility processes like PowerShell.

This is also a great example of when someone makes comments about a certain security solution being able to mitigate something without posting proof to substantiate such claims, take them with a "grain of salt" as people on malwaretips.com are so often fond of quoting.

 

Nice find, so apparently CB doesn't monitor these keylogging methods? If so, it's quite painful. Perhaps you can ask him to test tools like KeyScrambler, SpyShelter and HitmanPro.Alert who all offer keystroke encryption.

What do you mean, did ESET failed to block it? The thing is, in order to install a global hook, you need to perform DLL injection, but if the process is trusted then obviously a HIPS won't alert. And do you agree with me that this PowerShell keylogger is NOT kernel based? I still don't understand why you said that kernel mode drivers are involved.

 

Yes and no. Powershell assembly usage within .Net gives it kernel capability but only for a few limited instances if you would have read the Peter Hinchley article:

https://support.microsoft.com/en-us/help/318804/how-to-set-a-windows-hook-in-visual-c-net

 

But it does not use any kernel mode drivers, so it's not kernel based. The two keylogging methods that were mentioned can both be done from user-mode, so I think you misunderstood.

But I have been reading the other topic, and now I understand this attack a bit better. I assumed this Powershell keylogger was running from a separate process, but apparently it runs directly from inside browser memory? In that case, keystroke encryption may not work, so then you would have to block the DLL Injection/global hooking part.

 

I guess you still don't get it: Low-level hooks do not require that the hook procedure be implemented in a DLL. The hook is set prior to the .dll being loaded into the process.

Again, Windows at boot time loads common .dlls used by every process into reserved kernel memory space. The .dlls loaded are referenced in two kernel root tables named knowndlls and knowndlls32. A low level hook is set in user32.dll as it retrieved from kernel space and prior to its loading at process startup time. Hence the term "global" since it is applicable to all running processes.

A user mode hook that you refer to, hooks the .dll after it has been loaded into the process. These can be detected by HIPS and other security solutions that monitor process memory modification.

 

No offense, but I'm not sure if I'm the one who doesn't get it, because I just saw you had a similar discussion with a developer back in December 2017 on the ESET forum, and he also didn't understand you.

Based on everything I read, I think we can conclude that this PowerShell keylogger is not kernel based at all. HIPS that monitor global hooking and direct keyboard recording will most likely block this keylogger. Anti-loggers like SpyShelter and Keyscrambler who offer keystroke encryption will most likely block it also, you even acknowledged this in the ESET thread.

And the attack described at MalwareTips wouldn't even work if powershell.exe and mshta.exe are blocked, so it's not truly an "in-memory" or file-less keylogger, after all it needs to be downloaded and executed into the browser. So all in all clever attack, but nothing special and CB should be ashamed it couldn't block it.

 

I assume SpyShelter and KeyScambled will block .Net based low-level keyboard hooking via keystroke encryption since both employ kernel mode drivers that can intercept keystroke entry. You don't know for sure until they are both tested which you appear unwilling to do. As such, your statements are speculation at this point. I do know for a fact that Eset's like protection employed in the browser only via Online Payment protection does successfully encrypt the keystrokes when the .Net based keylogger is deployed since I tested and verified it does so as noted in my Eset forum posting.

Did you read what I posted in reply #57? The use of a Powershell script is only one way to deploy a .Net based keylogger.

 

Yes I'm sure there is, but that's not the point. The point is that this "fancy" PowerShell .Net keylogger does not use any new techniques, and can be blocked in the same way you would block commercial keyloggers. You made it sound like it was something special and even implied that these were kernel mode keyloggers, while they are not.

Forgot to respond to this. But what they probably mean is that for low level hooking you don't need to inject any DLL at all. For example SpyShelter will alert about this by saying "process is trying to record keyboard". In other cases it will alert about "process is trying to install global hook" and it will show you the DLL that will be injected. This all hasn't got anything to do with "kernel mode keyloggers".

Exactly, I assume the same based on your test with ESET, and I was hoping that you could test them since I don't use any virtual machines.

 

Just download the file I posted and follow this instructions. The code is 100% safe. I have run it many times. Once you terminate PowerShell, any of the keylogging activities cease.

I refuse to use SpyShelter again after what I saw what it changed on my default Win 10 default system settings.

 

No sorry, I refuse to do certain tests on my real system, so perhaps someone else can do it. Apparently you're not using VM's either, so I can understand your point of view. BTW, this is an interesting article, especially the part about "user mode keyloggers", it explains what I was saying all along, and this is why I was not impressed with this Powershell keylogger. However, if Powershell is trusted by HIPS/anti-logger it would obviously not be blocked, so that's the only interesting part about it.

https://securelist.com/keyloggers-implementing-keyloggers-in-windows-part-two/36358/

 

To clarify, the discussion was about whether keyloggers use DLL injection or not, the end conclusion is: Some do, some don't. BTW, I hope M$ will eventually bring the "module-code-integrity" feature to other processes on the system, this would make code injection attacks much harder, I suppose.

https://blogs.windows.com/msedgedev/2015/11/17/microsoft-edge-module-code-integrity/

 

I saw this in the Win Defender thread, nice find. It just keeps getting weirder, so now there's a process hollowing method that doesn't even need for a process to start up in suspended state, scary stuff!

 

@Rasheed187 , I know you're a big Barkley fan from your past postings. You might find this article title 'Security Through Obscurity', illuminating: http://randy-abrams.blogspot.com/2017/07/stackhackr-useless-for-testing-good-for.html

 

A bit of a late reply, but it does matter to me. You need a pre-execution and post-execution strategy, this means that you will always try to block malware from running, but if this fails for whatever reason, you need a behavior blocker/anti-logger to block possible malicious behavior.

If you have ransomware running but it can't get read/write access to important data you have won the battle. Same goes for a keylogger that can only record scrambled keys. Monitoring DLL/Code injection is especially important to protect against malware that will bypass the firewall by simply injecting code into the browser or perhaps even explorer.exe and svchost.exe for example.

 

Well, I can't say anything about the quality of Stackhackr, if it really simulates bad behavior and security tools can't catch it then I don't see what the problem is. Think of the Zemana and SpyShelter testing tools who work perfectly fine.

Of course the goal is not to block the simulator form running at all, but to block the behavior that is triggered. But anyway, it does not tell anything about the Barkly Endpoint Security tools, which is the only thing what matters.

https://www.spyshelter.com/security-test-tool/