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

It is almost 3am so I am going to bed. This is getting really old anyway. I agree that the AppCertDll is not as robust as the KMD. But I have brought up many, many, many great points that you do not reply to because you do not have a good answer. For example, I pointed out that a lot of security software started with the AppCertDll, then later moved to a KMD. You could have said "Yeah Dan, that seems like the logical thing to do in your case because you are not a full time developer." But instead, you just ignore my point altogether. And as I said, you selectively reply to the softballs but do not reply to the hardballs.

I will tell you what, if you can answer my question from post 164, I will be satisfied that you know what you are talking about... because honestly, I do not believe you will have a logical explanation for it. I will PM you the name of one of the security softwares right now, and you can test for yourself. I just do not want to post it publicly, because I do not want anyone to think that I am picking on anyone. If you can answer this question logically, I will be highly impressed, and I will take you at your word for the rest.

 

Yeah, like that is the only place you have trolled me.

 

Actually, kernel mode is where I got the main code example for the AppCertDll. How ironic.

 

I cannot PM you for some reason. I will try tomorrow.

 

One last thing... you tried VS 2.5? That version is quite old, why would you not download the latest version from our website? You are performing a test on security software, and you do not even download the latest version? What is your justification in doing so?

2.5 should not have had the code to disable UAC... I believe I removed that when I started VS 2.0, but I could be wrong about that, I would have to go back and look.

 

WHICH QUESTION ON POST 164?
WHAT HARDBALL?
ALL I SEE IS "POC OR IT DIDNT HAPPEN"
COMPILE A LIST OF QUESTIONS AND SHOOT

 

if this is your question

i have answer: do you even know what the security product does to block a new process?
your question is equivalent to
if i throw apple in air and my net which is on ground catches it, why doesn't a bird who is in sky near to the apple catch it?
do you even know what the bird's intention is? whether it wants to eat the apple or not? just because its in the sky doesn't mean it will catch it
and as for "but the bird is catching the fruit if my net is not there"
answer: is it catching in Air? or going to ground to catch it? you dont know that.
you have no idea on what the product is doing and you dont tell whats the primary work of that product which failed to do so in KM when you were in UM and you expect a logical answer for that?

Lastly
you admit that a product in KM has more power and control over the app than a product in UM.
Yet its not catching if VS is present?
Does this mean that your tech is pimitive because you dont have KM access to do something which you could have performed better had you dont that?
or that your product is superior because another product is not doing what *you* expect it to based on your 5 years of development experience?
again: you dont even know what that security product is doing on the inside.
Stop beating around the bush and ask a logical question in the first place to get a logical answer.
And if you are that confident, post a bug bounty on your website or twitter instead of being hyper active on this thread trying to defend against meaning less comments when you dont even know what they mean.

 

Sorry guys...I don't want to read your personal "excursions"...it has already become a "not tasty".

 

I think we have to retrace events here.

VoodooShield made the initial contact with r41p41. R41p41 gave his opinion and said if you want me to go with this I expect to be compensated. Note that prior to this engagement, r41p41 was not a forum member. Therefore he is under no "sense of duty" to help anyone frankly. Furthermore, he will only be compensated if he indeed does find a bypass.

Voodooshield has already stated all the money his company brings in. I am sure his company can afford to pay for this service. The likelihood of such payment should be extremely low since by his own statements, VoodooShield has never been bypassed to date excluding the instance for ver. 1.0.

 

Another possibility here would be to split this into two different threads. I enjoyed following the OP's purpose to this thread, but at the same time, the other half of this thread has some merit as well for discussion.

 

Before I forget, you said "Common man, this is not even difficult to understand WINAPI calls CreateProcess, CreateProcess calls CreateProcessInternal, CreateProcessInternal calls ZwCreateProcessEx() then after some time gives you callback then resumes the process by using ZwResumeThread or terminates it by using ZwTerminateProcess." I understand this to a certain extent, but this is not what I specialize in. I specialize in the user experience and creating software that people often times remark that they "love" and that is a "masterpiece". How often do you see users make those remarks about their security software? Since I do not specialize in C++ / kernel stuff, whatever you want to call it, I do not pretend to be a know-it-all, and I am smart enough to hire someone who does specialize in this to do this for me. For example, Microsoft has 100,000+ employees... do you expect all of them to be as familiar with C++ / kernel stuff as you are, being that is what you specialize in? I would bet that most of the user experience people at Microsoft are not as familiar with C++ / kernel stuff as their top OS developers. Microsoft is BIG on the user experience... from what I remember, they have their own dedicated user experience group. Do you expect the top OS developers to be as good at designing the optimal user experience as the user experience people?

Maybe you are just smarter than me, apparently not everyone is as smart as you since you specialize in C++ / kernel stuff. Or maybe VS will soon become ubiquitous, then who is smarter than who?

Having said that... I am familiar enough with C++ / kernel stuff to be able to sufficiently develop the other 99% of VS, but honestly, C++ / kernel stuff does not interest me, I actually find it boring. What I find interesting is developing user-friendly software with a great user experience and creating new software that people love.

My example from post 164 should demonstrate that I know C++ / kernel stuff, and process creation mechanisms well enough to hold a semi intelligent conversation on the subject. Since I still cannot send you a PM, let me explain the example in post 164 one last time. If you can logically answer this question, then that will be sufficient evidence for me that you are as knowledgeable, if not more, knowledgeable than the developer who wrote the AppCertDll code for VS. I am just trying to find a way to at least partially validate your claim that the AppCertDll can by bypassed, without you actually developing a PoC to bypass VS, since you are unwilling to do so without a ransom... I mean bounty.

Here is the example... Suppose you have VS 2.0 with the AppCertDll and an anti-executable with a KMD running on the same computer. Both start with identical baseline whitelists. You download a new executable from the internet and try to run it. VS blocks the new process first and the anti-executable that is utilizing the KMD is completely blind to it... it never sees it at all while VS is running. Then you disable VS and run the process again, so then this time, the anti-executable with the KMD sees and blocks the newly created process. This is problematic for your attack design because the AppCertDll blocked it first, without the KMD ever even seeing it... and the anti-executable should not have been blind to it. Correct? If you do not believe me, I can PM you a couple of anti-executables that can demonstrate this.

Maybe the AppCertDll can be easily bypassed, and maybe you are smarter than the developer who wrote the code for it, who knows?. But we will never know unless you produce a PoC. It really does not matter since VS is moving to the KMD, which is why I mentioned that in my initial post. You know, the post where I gave you a direct link to our most recent version... then you started talking about VS disabling UAC for no apparent reason, since the link I sent you was version that did not disable UAC . When I busted you on this, you searched the internet for an old version of VS to save face, even though I provided you a direct link in the requirements. That is just sneaky and shady, an severely questions your character.

 

Sorry Pete, I did not see your last PM while I was writing my response. I am bored with this anyway .

 

I have serious reservations about anti-execs monitoring dlls. Personally, I think they have their hands full just properly monitoring executable's.

Below is a sample McAfee Endpoint HIPS rule for monitoring global hooking in a browser; one of the methods that can be used for dll injection. Note the excluded Handler Module exe's and dll's in the rule - these will not be monitored since they can validly be hooked using the SetWindowsHookEx function.

Now this just one rule for 3 or 4 programs to monitor one API function. Now extrapolate that to all the OS and app programs in your system for all the API functions that can be used to monitor dll injection activities alone. This is the effort that is being attempted by the anti-execs currently.

If you want to stop dll injection in all forms, purchase software with a good behavior blocker. I recommend Emsisoft EAM or EIS; both use the original Mamutu behavior blocker. It will stop malware's attemp's to modify a targeted process's memory via disk or memory based dll injection. This is by far the easiest way to prevent this activity. Is it "bullet proof?" No. But recent AV lab tests have shown it is very close. You can also buy security software that includes a HIPS and define you own rules for known programs that are the favorite targets for memory modification like it do. BTW - HIPS software is by definition an anti-executable and existed long before the current crop of anti-execs on the market.

McAfee HIPS supports monitoring of SetWindowsHookEx usage and can alert you to potential dll injection/hooking attempts. To detect browser keylogging we can use a rule like the following:

Rule {
tag browser_hook
Class Hook
Id 4005
level 3
attributes -no_trusted_apps
Executable { Include { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES (X86)\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES\\MOZILLA FIREFOX\\FIREFOX.EXE" } { -path "C:\\PROGRAM FILES (X86)\\MOZILLA FIREFOX\\FIREFOX.EXE" }}
Executable { Exclude { -path "C:\\example\\exclude" } }
Handler_Module { Exclude { -path "C:\\WINDOWS\\SYSTEM32\\MSHTML.DLL" } { -path "C:\\WINDOWS\\SYSTEM32\\IEFRAME.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\MSCTF.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\EXPLORERFRAME.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEDVTOOL.DLL"} { -path "C:\\WINDOWS\\SYSWOW64\\SHELL32.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\SHELL32.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE"} { -path "C:\\PROGRAM FILES\\MICROSOFT\\INTERNET EXPLORER DEVELOPER TOOLBAR\\IEDEVTOOLBAR.DLL"} { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE"} }
user_name { Include "*" }
directives hook:set_windows_hook
}

Ref.: http://pwndizzle.blogspot.com/2014/03/custom-mcafee-hips-rules-that-actually.html

 

Are we supposed to be impressed?