Could anti-exe programs prevent applications from executing unknown dlls?

This thread is turning out to be quite interesting.

@Peter2150 Do you know which hashing algorithm Faronics AE utilizes?

 

I did some digging in Google and it looks as though Faronics AE was using SHA-1 algorithm around 2011 or so. They don't seem to publish much specifications on it, but it's possible that they are still using SHA-1 now or may have moved on to SHA-256 but I cannot say for sure.

 

If you want an exe and dll to test with from there, send me an e-mail. I will reply with a zipped folder containing same. It only works for x64 OS and must be injected into a x64 browser. You run it as follows. Note you will probably have to change the directory info to where you downloaded it to:

C:\Users\xxx\Downloads\inject.x64.exe 3948 C:\Users\xxx\Downloads\reflective_dll.x64.dll

Note: 3948 was the target process id.

 

Thank you, I appreciate the offer, but I have already tested VS against several hundred items like this. VS will block the inject.x64.exe before the reflective_dll.x64.dll will ever have the chance to execute its code. Online_Sword might like to try it though.

 

Hi, @VoodooShield .

I think here we go back to the old problem.
Let's see it. If no malicious dll can be droped on the hard disk without running whitelisted code, then why we still need to "partially" whitelist rundll32.exe?
I mean, if you are right, then we can just "completely" whitelist it, because there would be NO malicious dll on our hard disk at all.

Thank you for these materials.

I am looking forward to such a feature.

 

I am not suggesting that files cannot be dropped to the hard drive... that is very possible, I have some samples that are very sneaky in doing so. But dropping files and actually being able to execute them are 2 different things. I can send them to you tomorrow if you would like.

I guess partially whitelist is not the correct term, probably selectively would be better. For example, we want rundll32 to open the control panel mouse applet using this command line with the shell32.dll:

"c:\windows\system32\rundll32.exe" c:\windows\system32\shell32.dll,control_rundll c:\windows\system32\main.cpl

But we do not want rundll32 to run just any random, unknown dll.

 

Yes, as Emisoft's behavior blocker did(alert) when I was testing with it. Interestingly, Eset's advanced heuristics let it run unchecked; most likely since Eset's exploit and memory protection exists in its network filter and this activity was originating with the PC.

However, my testing was to verify that Eset's HIPS would catch this activity from an unknown process using a specific rule to prevent memory modification. It did.

I don't believe any security software can catch every malware injection attempt. So to prove you are truly protected, you would need to allow inject.x64.exe to run. What you are testing is the security software's effectiveness against the memory injection of the target process by a undetected malicious source process.

 

I see what you are saying, and I appreciate that. I agree, legitimate software occasionally uses dll injection, and it is almost impossible to detect if the injection is malicious or not. Until someone can create a method to detect whether the dll injection is malicious, with greater than 99% accuracy (> 99.999% preferred), it is probably best to block it altogether. On the other hand, if it is a whitelisted (known good) process, then it is safe to allow it. Would you agree? This is how VS handles it.

 

This is where a HIPS differs from conventional anti-malware methods. A HIPS doesn't care who the source/actor process is. It is protecting the target process from all rule specified actions.

In certain corp. endpoint solutions, you can even define the specific OpenProcess API calls you want to monitor such as VirtualAllocEx/VirtualFreeEx/,WriteProcessMemory, and CreateRemoteThread for example.

On the retail consumer side, most of the HIPS's have predefined rules to allow loading of signed system dlls and the like. So any end user rules to prevent process modification will detect any unknown disk or memory based dll injection.

Then there is this little "goodie" that the latest versions of Poweliks when coupled with an exploit uses:

The vulnerability is in the TS WebProxy component and the specific vulnerable function is CTSWebProxy::Start RemoteDesktop. Normally, this function executes the terminal services executable (mstsc.exe) and the path to mstsc.exe is supplied by the user. Before executing the filepath provided, Windows checks that the supplied path
legitimately leads to mstsc.exe. The path must end with mstsc.exe and it must start in the system folder, as seen in the following example:

• %Windir%\System32\mstsc.exe

This can be changed when the zero-day exploit is used. By using directory traversal characters, the check can be bypassed so it leads to a path that no longer points to mstsc.exe, as seen in the following example:

• %Windir%\System32\..\..\temp\bad.exe\mstsc.exe\..

Continuing with the example, this path will pass the check, but will actually execute the following file instead:

• %Temp%\bad.exe

There were actually two different vulnerabilities that had the same effect. In the 32-bit version of twsbprxy.exe, there were no checks on the path and in the 64-bit version of the file, there were checks but Windows allowed an incorrect path to be provided.​

Ref.: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/evolution-of-poweliks.pdf

-EDIT- BTW, this vulnerable has been patched. So the above no longer works; you will get an invalid path error.

 

Interesting thread! I think you guys will find this debate interesting as well.
https://www.wilderssecurity.com/threads/voodooshield.313706/page-314#post-2529066

So did I just bypass VoodooShield? Apparently, it's a matter of definition.

Perhaps I should start a pull so we can have democracy decide.

 

You might want to read my last post before you start a poll... Just a thought .

 

Correct, but tools like HMPA, Zemana and SpyShelter can block API hooking, this is the the stuff that banking trojans often use. If the browser is "hooked" after dll injection that is performed by a non-security tool, there is a big chance that it's malicious.

 

Hello TNO_sec!

I read your link above. Yes, I suppose "bypass" is a matter of definition.

I do not use VoodooShield, nor am I aware of how it works. However I have a few observations from my own point of view.

Your testing methodology reminds me of the Firewall Leaktests I encountered 10 years ago. According to one test site, my firewall, Kerio 2, failed most of the tests. Not very encouraging! I decided to test for myself, and guess what: I passed them all!

Why? Because the test required that I download an executable file -- to simulate what a trojan executable would do once installed on my system, to bypass the firewall's outbound protection. The test executable from the web site was blocked by my security because it was unauthorized (not on the White List). In order to run their test, I would have to compromise my security.

To simulate a drive-by exploit, I put the test executable into a MDAC exploit and ran it from my web site. Same result: the test executable could not get into my system.

Conclusion: if the test executable cannot get into my system, it cannot bypass my firewall.

As I understand your test methodology, If I were to run your test, I would have to disable some of my perimeter security, specifically, permit the Flash plug-in to be enabled globally. Otherwise, the site hosting the exploit being a non-trusted site, Flash would not be enabled, thus, the exploit would not be triggered.

Not fair, you might say? I should let the exploit run? Yet from my point of view, my perimeter security is my most important security, and I would not compromise it.

By perimeter, I'm referring to the some of the entry points at which malware can be triggered:

• firewall (eg: Conficker.A exploit via port 445)

• browser (plug-ins, etc. exploit)

• email links/attachments (trick to click exploit)

• USB (executables permitted to run from external media)

So, by my definition, as with the Firewall Leaktests, the "bypass" against VoodoShield occurred only because it required lax security to start with.

regards,

----
rich

 

Interesting... yeah Poweliks... that is the memory only malware that everyone talks about, and the only real world example I have ever heard of. I have never had a sample to test with VS, but it should have blocked it for several different reasons. First, the reg changes would have been blocked. And bad.exe should have been blocked too. I need to read more about Poweliks, I just have not had the time. I know it is file-less and does not write to the hard drive, but does it ever try to create a new process? Thank you!

 

By "big chance" do you mean approaching 100%? Why take the chance? All I am saying is that if a web app is running, the computer should be locked as tight as possible... would you agree that makes the most sense?

 

THAT is what I am talking about!!!

Here is a GREAT test that is super quick and easy to use, and to demonstrate that when the initial executable is blocked, then no further testing is required... the security solution blocked the dll injection... ie. no bypass. And in a real world scenario, the initial process would be blocked... game over for the malware.

http://securityxploded.com/remotedll.php

I had a similar experience years ago when I downloaded remotedll and tested it against VS. EVERYTHING seemed to be bypassing VS. Then I realized, the initial process was blocked, so that is all that mattered... VS was simply blocking it much sooner than I expected. As my old boss used to say "you can't get there from here."

BTW, when you get a chance, you might want to watch all of the RSA Conference youtube videos from this year (2015). Pretty much every presentation was about perimeters versus end point protection... you will find them extremely interesting, I know I did. Both are absolutely vital... they are just now figuring this out . So pretty much the entire conference was about how the perimeter has always been the focus, and it still vital, but basically every presentation was about how they are just now realizing how important end point protection is. The wilders people who believe strongly in whitelisting / anti-executables could have told them this 5 years ago .

 

dll monitoring is a massive waste of resources. If it were at all viable, then it would have been implemented long ago.

Adding dll alerts to VS will result in a massive number of alerts that will overwhelm the user. The only way to circumvent that is to white-list known, safe dlls - which will be a massive effort in terms of the code required to accomplish it. I can only see this achieved by performing a post-VS install complete system scan and white-listing everything on the system.

Most current HIPS will alert the user to memory injections.

The better alternative is emulation (Cuckoo sandbox) - which is already a feature of VS - because it specifically targets Unknown files. Carefully review all file activities as the Cuckoo sandbox will reveal suspicious activities - including memory injections (if I recall correctly).

• Clean install your OS of choice.
• Install VS and enable Training Mode.
• Install desired applications from Trusted vendors with a good reputation.
• Do not install traditionally exploited softs like Adobe, Oracle, Microsoft Office, Windows Media Player, Real Player, etc, etc; there are very high quality alternatives.
• Add an Anti-Exploit for your browser(s) - although with VS installed there is no absolute necessity to do so.
• After VS goes through an entire Training Mode cycle and prompts you to switch over to Smart Mode, enable it and stick with it; use due discretion when downloading and installing new softs.

Just food for thought...

Trying to create an impenetrable fortress by plugging every single potential vulnerability will result in an overly complex, over-burdened, completely user-unfriendly configuration...

 

You will find many technical analyses of this thing, but rare is it that an article mentions the delivery methods. Some are:

• malicious websites, or legitimate websites that have been hacked, can infect your machine through exploit kits that use vulnerabilities on your computer to run the exploit

• spam email containing links to malicious websites

• tricking the user into thinking they are installing a useful piece of software, for instance a bogus update for Adobe Flash Player or another piece of software

• embedding it in a Microsoft Word document, which is then sent as an attachment to spam emails, and which the attackers hope your curiosity will lead you to open

Nothing here that hasn't been seen for the past 10 years.

----
rich

 

No matter how it is delivered, VS alerts to\blocks Powershell.exe. In short, VS stopped Poweliks...

 

Yeah, I just read all about Poweliks, and VS would stop it on sooo many different levels, it is not even funny. The fact that it is memory only, would only work to its disadvantage, simply because VS blocks the process that is loaded into memory, it really doesn't care if it is written to the hard drive or not.

I really am tired of buzzwords like "memory only", "dll injection", etc.

There should be an unwritten rule on wilders that if someone suggests that a certain threat would be able to bypass a certain security software, then they have to demonstrate the bypass .

 

Yeah Buddy...

 

That's a credit to VS!

Nonetheless, I can't see anyone here at Wilders letting Poweliks be delivered in the first place.

----
rich