Classical HIPS and policy based HIPS discussion

Gleaned more tech details on Dridex. I can't think of a better example for using a HIPS with RMI capability with proper rules set to prevent process and registry modification :

The Main module is injected into the explorer.exe process. The module will also inject itself into web browser processes such as Firefox and Chrome to perform MITB attacks.

The Main module can perform the following core functions:

• Steal information from forms
• Take screenshots
• Redirect HTTP requests
• Inject code into web applications
• Log keystrokes
• Steal password
• Virtual network computing (VNC)
• Back connect
• Act as a mini server (peer node)
• Delete files
• Download other modules
• Steal cookies

The Main module is configured to perform man-in-the-browser attacks by a “settings” configuration, which is stored encrypted in the registry​

Ref.: http://www.symantec.com/content/en/...ponse/whitepapers/dridex-financial-trojan.pdf

A bit more detail on the process injection and registry modification:

The downloaded DLL runs with the command rundll32<dllname> NotifierInit. The DLL then deletes the original exe and injects to the explorer.exe process. The injected thread then deletes the DLL itself. The following activities done by injected thread:

 - Connects to the server and drops the payload to the system.
 - Downloads the DLL again before the system shutdowns.

Before the system shutdown, the malware runs in the legitimate process memory. It drops the DLL and creates the registry entry so that malware can run again after the system restarts. After the system restarts, the DLL and registry entry are removed again:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] "wwnotify"="rundll32.exe C:\\Document and Settings\\Administrator\Local Settings\Temp\cab[random hex].tmp NotifierInit"

Note the stealth techniques used above.

Ref.: https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/25000/PD25982/en_US/McAfee Labs Threat Advisory - Dridex.pdf

​

 

The Main module is injected into the explorer.exe process.: a well setted, granular HIPS should protect against it, is it ?

 

Yes correct, just what I expected, Dridex still needs to perform code injection into system processes like explorer.exe (and the browser) before it can perform all of the steps. In other words, it's likely that when you block code injection/API hooking, it will not be able to do any damage.

I do know of certain malware that simply changes DNS settings on either Windows or the router, some more general info:

http://blog.trendmicro.com/trendlab...-changer-malware-sets-sights-on-home-routers/
http://www.howtogeek.com/227384/how-to-check-your-router-for-malware/
http://www.howtogeek.com/167533/the-ultimate-guide-to-changing-your-dns-server/

 

All classical HIPS's will prevent disk based .dll injection; either by providing default rules for select vulnerable processes or by the user creating same rules manually.

Very few HIPS's prevent reflective memory injection, i.e. source to target process disk-less memory injection. I believe the reason Eset's HIPS provides RMI protection is that they integrated their exploit and advanced memory scanning features into the HIPS module. Also Eset created their HIPS "ground up" with the memory protection integrated from the start. Eset's HIPS feature is relatively new in that it was not offered until a couple of years ago.

Also some behavior blockers such as Emsisoft will detect RMI. The difference between a behavior blocker and HIPS in this regard is a HIPS will detect the activity per se. That is the HIPS will block any attempt regardless of the source. A behavior blocker however must first detect the malware process execution in able to monitor it. Then the BB must determine if the process is doing something malicious. If the malware is able to avoid those detections, it is game over.

A good analogy is a castle gate access policy. Two choices:

1. I lock the gate at dusk and do not open it to anyone till dawn. HIPS
2. Once the gate is locked, I will allow in someone I recognize that I know is safe. Behavior blocker.

 

@ itman

Here is some interesting stuff about API's that HIPS should be monitoring, and check out the demo of CrowdStrike Falcon, a corporate level HIPS in link 3.

http://resources.infosecinstitute.com/windows-functions-in-malware-analysis-cheat-sheet-part-1/
http://resources.infosecinstitute.com/windows-functions-in-malware-analysis-cheat-sheet-part-2/
http://www.crowdstrike.com/falcon-tour/

 

Demo doesn't work for me. Might use FlashPlayer which I uninstalled months ago?

As far as the InfoSec articles, I believe I previously posted links to those also? In any case, most of those APIs can be/are used by non-malicious processes. Again, the "catch-22" problem of directly monitoring API without a context reference - false positives up the wazoo.

 

I was going to respond to this, but this topic should be discussed in the firewall forum.

 

Getting back to DNS poisoning, I did find a detailed test of Eset Smart Security ver. 6; current release is 9. Although the tester found issues with a number of the IPS protections, ARP/DNS poisoning was not one of them. He could find no way to bypass either.

Case in point is the number of queries to Eset tech support/forum on the number of legit connections that have been blocked by the ARP/DNS Poisoning option. It is very aggressive.

 

A .vbs script run from a MS Word macro usually.

 

If in spite of my recommendations not to use Trusteer that I posted previously, there is a way to use it properly. Also using Trusteer this way will minimize your privacy risks:

The downside to using Rapport is that it locks user’s desktops down quite thoroughly when a protected browser is up and running. That’s probably why Trusteer’s support organization recommends that IT set up separate accounts for employees to use specifically for online banking.

For all other activities, end users should be instructed to log into their usual accounts. Since most security experts recommend that online banking only be conducted on special hardened PCs reserved for such use, this approach represents a reasonable compromise that enables users to stay on their familiar equipment, and switch over to a special account for as long as they’re engaged in online banking or financial activity.

Ref.: http://searchenterprisedesktop.tech...nts-online-bank-fraud-blocks-phishing-attacks
​

 

Some HIPS, as Defense+, has the feature " protected objects ": even only it should protect explorer.exe. And his rulesets can be setted to protect interprocess memory accesses and phisical memory access and other.

 

I have never tested Defense+ against reflective memory injection. So I can't vouch for it.

Again, I posted previously detailed instructions in this thread on a reflective .dll injection test tool that can be used to test your security solution capability against RMI. Again, you have to allow this test tool to run. What you are testing is a HIPS protected process's capability of detecting the memory to memory dll injection from any unknown source process.

 

Came across an excellent Blackhat presentation on WMI attacks plus defense and mitigation strategies: https://www.blackhat.com/docs/us-15...ent Asynchronous-And-Fileless-Backdoor-wp.pdf

For a quick read, you can scroll down to the WMI Defense section. Guess what? Another recommendation that the "old eyeball technique" is still a vey effective method.

 

Please, would you tell me the n.of this post ?

 

See reply #430: https://www.wilderssecurity.com/thre...d-hips-discussion.372859/page-18#post-2571243

Best to inject your browser. That way you can just shut down the browser to remove the injected reflective dll if Defense+ does not block it.

 

The question is can we safely disable the WMI service on Windows? I did disable it on Win XP, but I have this feeling it's not a good idea to do this on Win 8. Also, it seems that in order to exploit the WMI service, you need to run other system processes, so I hope you can blacklist them without causing any problems.

Yes you need Flash, and you didn't post these links, I just did a search. Here is some more info:

http://www.techrepublic.com/article...-software-targets-bad-guys-not-their-malware/

 

Thank you. I tried and Defense+ - configured in customized mode, not in default mode - don't see them. May be I have to modify or add some settings in Defense+ : I believe that the feature " protected objects failed, but I could change the group policy for the browser...

 

I have similar feeling. Here are services dependent on WMI (on Windows 7):



Nothing important but I still wouldn't feel good disabling WMI. IMO there are higher chances to get some problems from disabling it than getting malware that would use this techniques.

 

ICS most people don't use. IP Helper is used by IPv6 over IPv4 tunneling; I have all those disabled. That leaves Security Center which you do need if you want to receive any Win diagnostic alerts and the like.

I believe the primary purpose for WMI is monitoring things like stand-by mode, power management, etc. Might also be used by the gadgets.

 

Yes I have first two disabled anyway, but still have "a feeling" that other software or system might need it.

 

Ref.: https://github.com/stephenfewer/ReflectiveDLLInjection

First and I assume you know this but will state anyway, you have to inject reflective_dll.x64 dll into x64 process using inject.x64.exe.

For 32 bit process, you inject reflective_dll.dll into 32 bit process using inject.exe.

Next make sure the following all in the same directory:

inject.exe
inject.x64.exe
reflective_dll.dll
reflective_dll.x64.dll

Finally, you have to run this from the; Start Menu -> enter "Run" in the search box -> select "Runas" Then enter the following assuming you are injecting a x64 process:

C:\download directory\inject.x64.exe 1234 C:\download directory\reflective_dll.x64.dll

where 1234 is the process id from Process Explorer of the process which you wish to inject the .dll into.​

Note the space between the above inject.x64..exe and 1234 and between 1234 and C:\download directory\reflective_dll.x64.dll.

Also make sure you downloaded the binaries from Github unless you have a compiler.

In any case if this runs correctly, you should either get an alert or a blocked logged entry from Defense+ -or- you should see:



Note that all code directly injected into the process's memory without a trace that such activity occurred.

-EDIT-

Emsisoft's behavior blocker detects the reflective loader as noted below:



Eset's HIPS will detect it two ways assuming you have like rules created for the targeted process:

4/12/2016 2:02:25 PM C:\Users\Don\Downloads\inject.x64.exe
Get access to another application C:\Program Files\Internet Explorer\iexplore.exe
User rule: block changes to Internet facing apps

4/12/2016 2:02:26 PM C:\Users\Don\Downloads\inject.x64.exe
Modify state of another application C:\Program Files\Internet Explorer\iexplore.exe
User rule: block changes to Internet facing apps

 

So I made the first time. But I'm doing something wrong, because Defense+ don't see, but the process don't run.

 

Oops - forgot to mention you need to specify the full path name for the reflective dll. See my previous revised instructions. Also you will not see any ref. to the .dll in the injected process using a viewer like Process Explorer.

I really don't know what you're doing wrong. Test worked fine for me on x64 Win 7. PM me your e-mail address and I will send you a zipped folder containing the reflective x64 .exe and .dll.

Also Comodo's sandbox might be affecting process execution. You might have to disable that for testing. Like I said, you have to allow the .exe to run initially. Could be Comodo is blocking .exe based on reputation also.

-EDIT-

Check all your Comodo logs to determine is the .exe is being blocked. If there are no log entries, I have to assume you perhaps didn't download the correct .exe binaries. Again the process being injected must be a 64 bit process if you are using inject.x64.exe to perform the injection.