Classical HIPS and policy based HIPS discussion

Again, I don't agree. As I said previously, all HIPS's monitor API hooking. The differences between them is what hooking activities they are monitoring.

Using Malware Defender as an example once it is switched out of learning mode, it will block all hooking activities for which a rule hasn't been created during the learning period. That is extreme and caused problems for people that used the product.

Zemana and SpyShelter primarily monitor API hooking activity associated with keylogging activity. And again, both fail to catch API activity associated with process memory injection.

Comodo Defense+ with minor tweaking will prevent almost all malicious API hooking activities.

Again, API hook monitoring is a balancing act between protection and usability.

 

No, you're still misunderstanding. All HIPS can block code injection, but not all HIPS can block API hooking after code injection has been allowed. So with HIPS like Comodo and ESET, it's game over when you have trusted the wrong app. But HIPS like SS, Zemana and Webroot can still block malware from hijacking the browser even after code injection. I have repeated this numerous of times, and I don't see what's so hard to understand about this, no offence.

I'm not sure what you mean with "fail to catch" because they can both block standard code injection techniques? I'm not sure if they can block the "reflective code injection" method, but most malware are not using this currently.

 

First, Emotet is delivered via e-mail and is targeted to banking organizations. So it is nothing end users have to worry about. Here is a detailed analysis of it from Kapersky: https://securelist.com/analysis/publications/69560/the-banking-trojan-emotet-detailed-analysis/ . From this analysis it injects explorer.exe. So I don't know where this en mass .dll injection business comes from that Trend noted. I suspect they were referring to the infection within explorer.exe could be propagated to any sub-processes it spawns e.g. the browser:

• There has been a slight change in the technology used to inject code into the address space of explorer.exe. Version 2 used a classic model for code injection: OpenProcess+WriteProcessMemeory+CreateRemoteThread. Version 3 uses only two stages of the previous model:OpenProcess+WriteProcessMemory; and the injected code is initiated with the help of modified code of the ZwClose function in the address space of the explorer.exe process, which is also achieved using WriteProcessMemory.​

 

You have it backwards. You perform the hooking activity first, then the code injection. You have to establish a thread/handle to the targeted process before any further activity can take place. In the above Emotet example, the first hook activity being performed is OpenProcess.

Syntax

HANDLE WINAPI OpenProcess(
_In_ DWORD dwDesiredAccess,
_In_ BOOL bInheritHandle,
_In_ DWORD dwProcessId
);

Parameters

dwDesiredAccess [in]
The access to the process object. This access right is checked against the security descriptor for the process. This parameter can be one or more of the process access rights.

If the caller has enabled the SeDebugPrivilege privilege, the requested access is granted regardless of the contents of the security descriptor.

bInheritHandle [in]
If this value is TRUE, processes created by this process will inherit the handle. Otherwise, the processes do not inherit this handle.

Ref.: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspxhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspx

 

Seriously itman, you missed the mark on this one. It seems you don't understand what API hooking is all about. Actually, I believe you're making things too complex. You first have to perform code injection, after that you can hook certain API's inside memory. The usage of "OpenProcess" is not called hooking. Remember the HookMe tool? I suggest you will read this article again. The API's that it hooks are:

send (WS2_32.dll)
sendto (WS2_32.dll)
recv (WS2_32.dll)
recvfrom (WS2_32.dll)
WSASend (WS2_32.dll)
WSARecv (WS2_32.dll)
EncryptMessage (Secur32.dll)
DecryptMessage (Secur32.dll)

http://blog.elevenpaths.com/2013/11/hookme-tool-for-intercepting.html

 

Nope, your missing the mark.

Note that in my the above excerpt on Emotet, version 3 of the malware doesn't even set a physical hook i.e. CreateRemoteThread. Which is exactly the point I am trying in vain to get across. That point is that monitoring hook setting per se is pointless and prone to false positive results. The HIPS's job is to first detect unauthorized access to a trusted process from any unknown and untrusted process.

 

Please explain me if Zonealarm FW falls into the category of HIPS? It has a module monitoring programs.

 

Unless ZA has changed, the answer is no in the context HIPS protection is discussed in this Wilders thread: https://www.zonealarm.com/forums/archive/index.php/t-80718.html

 

Are you for real itman?

Like I said, you seem to be confused about what hooking is all about. When I refer to "hooking", it's related to global hooking and API hooking. If you want to hook a process, you need to load a DLL into a process, this is called code injection.

In order to perform code injection, you don't need to hook anything, you simply use one of the code injecting methods. So code injection is NOT hooking. Code injection is used to perform hooking. Stuff like CreateRemoteThread and WriteProcessMemory is NOT called hooking. HIPS like Zemana and SS only monitor the API's that are hooked by banking trojans, similar to the HookMe tool.

Yes but it's not that handy.

 

We’ve seen how we can inject a DLL into the process’s address space with using the CreateRemoteThread function. The attacker can use this method to hook certain functions of the process’s IAT import table to gather useful information about the process/user.

Ref.: http://resources.infosecinstitute.com/using-createremotethread-for-dll-injection-on-windows/

I agree 100%. Both are totally worthless against today's advanced malware memory injection techniques.

 

Yes exactly, it's used to perform hooking, it's not called hooking itself, like you claimed earlier, see your second quote. In other words, you first need to inject code, before you can get to the API hooking part.

You're missing the point. They are not useless at all, because they actually are able to block both code injection and API hooking. This means they can block most malware, except for the most advanced ones that might use unknown methods, that all HIPS will probably fail. But I only know about one malware sample that used a non-standard method.

 

I came across a posting over at MalwareTips.com on how to create a "total lockdown mode" in Kapersky's HIPS. It uses a custom configuration of the Trusted Application Mode feature. This equates to using Eset's HIPS in "policy" mode. As the article notes and I have stated previously, use of learning mode which is required prior to implementation, should only be performed on new OS installations or PC's that are 100% malware free.
https://malwaretips.com/threads/kaspersky-trusted-application-mode-tam-maximum-settings.43920/

BTW - I forgot to mention something in my previous Eset HIPS comments. Eset will not 100% allow user rules to override its own internal rules. This can be observed in a HIPS log entry with the wording of "some access allowed/blocked." I believe what is going on is that Eset is intercepting any attempts to interfere with its exploit and advanced memory protection features that are part of the HIPS. It also explains how I have been able to create very restrictive rules against system processes and not having the process "borked" by doing so.

 

Close, but still no cigar ......... They are independent functions. You can inject code but perform no hooking as I noted in reply #328. Or you can hook, but perform no memory injection. Finally, both functions can be employed as you noted.

The CreateRemoteThread function causes a new thread of execution to begin in the address space of the specified process. The thread has access to all objects that the process opens.

Ref.: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682437(v=vs.85).aspx

 

It looks interesting. It almost makes me want to install a VM just to check it out. BTW, here is more info about the Kaspersky Whitelist technology:

http://whitelist.kaspersky.com/catalogue
http://whitelist.kaspersky.com/technology#acticle/140

I have to admit that I haven't got a clue what you're talking about, it doesn't make any sense. Keep in mind, we're specifically talking about global and API hooking, and you must perform code injection for both methods. That's just a fact, so I'm not sure why you keep claiming otherwise. Perhaps you should read this article again:

http://nagareshwar.securityxploded.com/2014/03/20/code-injection-and-api-hooking-techniques/

 

What I am saying is that hooking is used for other activities than just code injection such as debugging a process as noted previously: The attacker can use this method to hook certain functions of the process’s IAT import table to gather useful information about the process/user.

And again, you don't have to hook a process to perform injection activities; Emotet Version 3 uses only two stages of the previous model: OpenProcess+WriteProcessMemory; and the injected code is initiated with the help of modified code of the ZwClose function in the address space of the explorer.exe process, which is also achieved using WriteProcessMemory.

 

Thanks for the link and you guys keep going at it because even in contesting differing methods (and explanations) no matter the rub, this is a great thread and one that I for one personally take very seriously. And Why? Because I lost the bulk (teeth) for my Windows defense relied on for a very long time (HIPS) that was near as total coverage as a user could ever want or need without having to resort to a Virtualizer to avoid (malware) (hooking) (injecting etc.).

It matters for me that a strong HIPS can serve it's purpose as initially designed but when PatchGuard + x64 entered, and patchguard is pretty effective, that and the fact most HIPS (which served well for 32bit) were rendered obsolete or at the very least restricted to only 32bit except for those aforementioned in various AV suites and a scant few individual offers like SS etc.

Fabulous discussion

 

Actually I don't think it's a fabulous discussion, at least not when it comes to the latest posts.

I'm not sure why itman is making this so complex.

 

What you're saying doesn't make any sense. The problem is that you use the term "hooking" in the wrong context. Hooking, as in global or API hooking is not the same as code injection. Code injection is used to perform hooking, not the other way around.

See above. Stuff like "OpenProcess+WriteProcessMemory" are code injection methods, but this is not called hooking. I know you have lots of knowledge so I'm puzzled why you don't understand this basic stuff. After all, the last 6 pages or so we have discussed this into details.

 

To give some more info:

DLL Injection is used for both global hooking and API hooking. Global hooking is often used by keyloggers, API hooking is often used by rootkits and banking trojans. In other words, if you block DLL/Code injection, you have already won the battle. Just about all HIPS can do this.

But what if you make the wrong decision and allow some malicious app to inject code? Then you need HIPS that can interfere with malicious usage of global and API hooking. Anti-loggers like Zemana and SS both offer this with keystroke encryption and the blocking of network API hooks inside the browser.

 

Rasheed, appears we have reached a mental block on this so lets move on.

I will give these analogy however. Just as malware evolved from disk to memory based injection use, it has also evolved on how to deploy the memory based injection. It no longer needs a deploy a hook for subsequent use of the injected code. So monitoring of hooks as means to detect malware activities gets less effective each passing day.

 

Yes perhaps it's for the best. But it simply isn't true what you're saying. Both code injection and API hooking as used by most malware, can be easily blocked. This is confirmed in the MRG Online Banking tests.

And this discussion wasn't about disk vs memory based injection. Memory based injection is more likely to be used in exploit attacks, but that is another subject. Speaking of MRG, seems like their website has been updated, they now offer even more malware testing services:

https://www.mrg-effitas.com/

 

Related to the last 3rd quarter 2015 banking test MRG performed, the only AV products that passed in default config. were Kapersky and Webroot. Again, MRG used reflective .dll injection in those tests. The technique is no longer restricted to exploits. In fact, I used it in my Eset tests as I posted in the Wilder's thread on MRG tests. Eset caught the reflective memory injection against IE11 as process modification activity. Note, I have created a specific Eset HIPS rule to protect my browser. Also, Emsisoft detected the activity likewise via its behavior blocker with no special configuration employed.

MRG Effitas Online Banking/Browser Security Certification Project Q3 2015

Simulator Test – API hooking tests

Financial malware developers always find new ways to bypass current protection technologies. One of the oldest techniques is to inject the attacker supplied DLL into Internet Explorer, then hook (redirect) the API calls, where the password can be found in a buffer passed to the function as a parameter. In this test, we used reflective DLL
injection technique for the DLL injection step, and hooked either the HTTPSendrequestW function or the EncryptMessage function, either via not exported functions, or page exceptions. This is a total of four tests.

Ref.: https://www.mrg-effitas.com/wp-cont...itas-Online-Banking-Certification-Q3-2015.pdf
​

-EDIT-

The above MRG testing does reinforce the point that I am trying to get across about hook monitoring. Zemana failed this test and I am pretty sure Spyshelter would have also if it participated in the testing. Excluding the memory injection aspect which has been previously discussed at length in the previous Wilders thread I mentioned, the question is why Zemana didn't detect those hooks? The answer is because they are ones not commonly associated with malicious activity; especially those associated with keylogging, screen capture, and the like activities for which Zemana was designed for. Simple put, today's security software with a HIPS element does not monitor all hooking activity but only API activity that has a known association with specific malware activity.

The point I am trying to get across is that the HIPS's primary function is guard a process against being tampered with primarily by disk or memory based injection methods. For example, a hook set in a process for debugging purpose is in itself not malicious since no process modification has occurred but could be a prelude to further malicious activity. Should that type of hooking activity be blocked? Maybe; especially if the hook is being set in your security applications.

As Rasheed187 is fond of pointing out, the event sequence malware uses in majority of cases is to first - inject the process with its code and second - set a hook. If the HIPS detects the malicious injection activity; blocks it; and quarantines the malware, the hooking activity never takes place. So wholesale monitoring of API hooking is not only ineffective but dangerous due to the high likelihood of a false positive determination.

Again effective security monitoring is always context sensitive. It is not the hook activity in itself that is necessarily malicious but rather the events associated with that activity that determine its malicious intent.

​

 

Thank you. I wish it had HIPS in this thread context.

Thank you.

 

Rasheed187 - I came across a research paper that employs the behavioral aspects of hook monitoring that are necessary to prevent false positives. So here is your prototype for developing your own software to do the same: http://maxwellsci.com/print/rjaset/v9-33-39.pdf

Below is a diagram that illustrates the necessary components:



Here is the code for the DLL classification module:

So in order to allow legitimate system service calls to be serviced as normal, we have developed a new algorithm named it as “DLL Classification Algorithm”:

/*DLL Classification Algorithm*/

Input(s): Imported DllName
Output: Classification of DLL’s either as legitimate or malicious returntype FunctionName (DLL)
{
//declarations
Get dllName and handle
using GetFileVersionInfo() check whether
((szDllName, dwHandle, dwCount, pBuffer) ! = 0)
{
If not, use VerQueryValue() extract VarFileInfo and ValueLen;
if (bVer && dwValueLen ! = 0)
{
print dll file informations
if (extracred dll informations are valid)
{
legitimate dll
}
}
}
malicious dll
}

Since most of the malicious code cannot include properties such as vendor name, description and version details, the DLL/process classification algorithm verifies their properties to check whether the given process is malicious or not. To get the vendor name of the process, the GetFileVersionInfo() function is called to get the file version information buffer which contains all the property values of a dll. To get the specified property value of a dll, the VerQueryValue() function is invoked. Finally VerQueryValue function tells whether the dll is either legitimate or malicious.

And finally the limitations of this approach:

Limitation:

Even though our system successfully defeats native API hooks in user-mode, it still suffers from the following limitations. First, the proposed system is assumed to be installed in a clean system. Any hook which attempts to alter some bytes randomly instead of the first five bytes of a DLL function could not be detected as malicious. Additionally, the proposed method cannot detect malicious code attacks that directly target kernel-mode data structures, specifically System Service Dispatch Table (SSDT). Hence, to provide a tight protection, it needs to work with anti kernel hooking mechanism.

 

Reviewing the above prototype, I don't believe it would work for reflective .dll injection for the following reasons:

•There is no new process created, the DLL is injected into the address space of the target process
•The DLL is not present in the list of modules loaded by that process, because the DLL is not registered in the PEB (the PEB, or the Process Environment Block, is a process specific area of memory which, among others, contains information about the loaded modules)
​

So something along these lines would also have to be incorporated into the DLL Classification module; most likely as separate module since it would be applied against the entire .exe:

I wrote a tool (in C# and powershell using reflection) that walks thread stacks and reports where the function calls are loading from using GetMappedFile. Shows where all functions are executing from (i.e. which dll and where on disk) if the MappedFile property is blank, most likely reflectively loaded https://github.com/secabstraction/PowerWalker

Ref: http://security.stackexchange.com/questions/20815/detecting-reflective-dll-injection
​