Classical HIPS and policy based HIPS discussion

Thanks for your input here. Hope you are talking about this post of yours, if not please point me to.

 

All is well, Kees . Enjoy your Friday.

Bo

 

The following assumes the Kovter dropper has somehow be able to avoid detection, run, and install its crapware.

Referring back to the previous link I posted on Kovter which also applies to Poweliks and like fileless malware is the following article excerpt:

As demonstrated in these graphs this results in The Microsoft Scripting Engine (mshta.exe) is invoked through WMI, which in turn uses Powershell to start the previously observed regsvr32.exe, with the injected Kovter payload.
​

Kovter runs at startup from the registry and launches a dual attack. It first will do a hollow process routine on a suspended state regsvc32.exe process and later use this modified process as noted above.

Note that the malware will use WMI to launch the scripting host, mshta.exe. Mshta.exe in turns launches powershell.exe to run a script hidden in the environment variables area.

My contention is that Kovter is using WMI for a reason. The reason being to avoid detection by conventional methods of the startup of powershell.exe. So until proven otherwise by specific testing, I would assume that no anti-exec or HIPS rule is going to block any powershell.exe startup done this way.

Now I have a HIPS rule that prevents any processing modification, i.e. RMI, against Windows processes. So that will alert me when Kovter attempts to modify regsvc32.exe in memory which is done during the initial phase of the infection.

​

 

But not for all system processes, I believe. Only predefined ones, if I am correct? For example, anyone tried defining svchost.exe and determining what the results would be?

 

HMPA caused some issues on my system, and therefore i had a look with Processhacker earlier this day.
I have seen it injected in nearly all system processes that were running. And even in processes, that were not in the list of "protected applications".
But i deinstalled it, and can't verify it at the moment.
But I'm sure (not 100%)

 

Just because a hook is being set does not necessary imply that your protected against RMI. You really have to test with a tool that does RMI such as the reflective dll test tool I described previously in this thread. Test has to be performed against both active and suspended processes.

HMPA was developed as an anti-exploit with logic to detect memory mod. techniques used by exploits; notably memory heapspraying. RMI uses different techniques to modify a processes memory. I am not saying that HPMA cannot detect RMI, it might. I have never tested it for RMI, so I cannot vouch for it

 

Another issue is the distinction between process hollowing and RMI.

Process hollowing occurs when malware starts a legit process in a suspended mode for the purpose of gaining access privileges that are assigned to that process. The suspended process's memory and control areas are then directly modified by the malware.

RMI occurs when a target process's memory is directed injected with code, usually a .dll, from the memory of a malware process. RMI can be performed against both active or suspended target processes in a hollowed or non-hollowed status. Hollow processing does not have to occur for RMI to succeed.

 

Those are the policies i'm using with Bouncer, and it has worked with AppGuard without any problems. I'm not sure about other HIPS applications. Classical HIPS has almost gone extinct so I have not used many lately. I was a dedicated user of Online Armor, and when it was abandoned I stopped using HIPS. I have Eset Smart Security, but I don't like it's HIPS. You have to configure it if you want to get much benefit out of it, and it has never worked well for me so I use it in Automatic Mode.

 

http://blog.jpcert.or.jp/.s/2016/01/windows-commands-abused-by-attackers.html

https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/Limits.txt

https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/TheList.txt

I have black-listed all without any ill effect on my system.

* * * * *

NVT ERP in Lock Down Mode will auto-block execution of all built-in and user-defined vulnerable processes.

Not absolutely 100 % perfect security against vulnerable process abuse, but pretty darn close.

Blackhats are always finding new ways to abuse processes shipped with Windows; just add them to the vulnerable process list if possible.

The 1 % of most sophisticated attacks require 90 % of user effort to protect against them.

Adopt sound protection strategy - and don't worry about it...................

 

In another thread @hjlbx had posted this info before: https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/Limits.txt
See also 'Limits of Application Whitelisting' here: http://bitnuts.de/index.html
I have added all the .exe's to ERP>Advanced>Vulnerable Processes with no issues so far (running in Alert Mode).
Some processes had to be repeated for each .Net framework/framework64 in which they occur.

 

When you have not disabled UAC, you only need to protect system processes running at MEDIUM integrity level. Explorer and SVCHOST (and RUNTIME BROKER for win 8.1 and higher) are the ones which are tied to the system and therefor offer the best chance of finding a useable memory location after control flow breach or shoot in the foot error by the user.

On most Windows 8.1 and Windows 10 instances, svchost only runs as HIGH or SYSTEM integrity level. This would leave EXPLORER (and RUNTIME BROKER) the best candidate(s) to be protected by an anti-exploit like HPMAlert. For the record @Peter2150 I just defended HPMAlert

 

@hjlbx, @paulderdash

Great please post this in NVT ERP thread (wth a screenprint f your settings), Let's not hijack this HIPS thread of ITman.

 

Indeed. It had already been posted there.

 

In regards to application whitelisting, here is a recent test of McAfee Application Control, a commercial product use in enterprise environments that concluded:

Conclusion

As shown, it’s easily possible to bypass the protections provided by McAfee Application Control.

Ref.: https://www.sec-consult.com/fxdata/..._for_critical_infrastructure_systems_v1 0.pdf
​

 

@Rasheed187, in regards to your favorite topic of banking Trojans; namely a nasty one - Dridex.

Let's look at its main hijack mechanism:

Dridex now uses DNS poisoning on the local endpoint to redirect the victim to pages it controls.

In DNS cache poisoning, an attacker inserts a fake address record for an Internet domain into the endpoint’s cache DNS. As a result, the cache will use the fake address in subsequent browsing requests and route traffic to the address of the attacker’s server. For as long as the fake entry is cached by the server, browsers or email servers will automatically send victims to the address provided by the compromised DNS server.

Ref.: https://securityintelligence.com/dr...in-uk-intensifies-focus-on-business-accounts/
​

Now I guess you could "do a cartwheel" routine in trying to stop this at the browser level, etc.. I prefer to "nip things in the bud"; namely a comprehensive solution directed at the source of the attack. That source in this case is DNS poisoning. The solution is employing a firewall that has a strong IPS component such as Eset's Smart Security as noted below:

 

I haven't done any testing, but I believe that ERP should always alert when certain system processes are being started, no matter if it's started by a system process or not. It doesn't care about the parent process, if it's launched it will be auto-blocked when in "Lockdown-Mode".

No, I don't think so. I believe it watches for process hollowing of any process.

Perhaps it's a slight obsession, but detection by AV is boring. It's a lot sexier when HIPS/BB can block it.

That's why MRG developed financial malware simulators, because most AV's can easily detect popular banking trojans, but what if they fail? Then you need HIPS/BB, and they even made those simulators nastier than real life banking trojans, when it came to the techniques that were used.

 

Keep in mind that HMPA is meant to block exploits (or the goal of exploits). So this means that if RMI is used in an exploit attack, it will most likely be blocked because HMPA/MBAE will simply block the payload from running, no matter if it's in-memory or disk based. If malware is already running on the system, then of course HMPA will not block RMI, because it's outside of its scope, you need HIPS for that.

Yes it's a cool list, that's why I posted this earlier, good to know that you haven't run into any trouble, I still need to add a couple of them.

 

And most important, you must test the HIPS to ensure that it does indeed detect resident malware based RMI. Many classical HIPS's do not detect RMI.

 

Interesting, so hijacking DNS settings is enough for this attack to succeed? I will need to read a bit more about this. The thing about banking trojans is that they rely on code injection in order to perform API hooking. That is the most important method to bypass HIPS and AV's.

So normally speaking, if you can block either of those, you should have already won the battle. Banking trojans use code injection/API hooking to communicate with the C&C server, and to monitor and manipulate browser traffic and banking websites.

http://www.pcworld.com/article/3024247/dridex-banking-malware-adds-a-new-trick.html

 

Yes correct, some even fail to block process hollowing so there is quite a lot of room for improvement. As already been mentioned, SS and probably also Zemana both fail to protect against RMI and process hollowing, at least on Win 64 bit. I'm not sure about Comodo.

 

What is going on is the redirect is to a HTTP site. So the traffic is being received unencrypted.

If the redirect was done to a HTTPS site, Dridex would still have had to install a root CA cert. on the source PC to perform a MITM to decrypt the SSL traffic.

What is not explained is how Dridex is overridden the browser display of a green status that is given for sites using EV certs. I suspect Dridex displays its web site w/o any of the browser visual clues given for a EV SSL web site; lock icon, green bar, etc. and just relies on most uneducated users never noticing they have been redirected to a HTTP site instead of a HTTPS site.

 

OK I see, but I wonder if code injection is still needed in order for such an attack to succeed? I suppose they still need to be able to somehow control the browser? That's what not clear to me yet. I do know that Zemana will block installation of Root Certificates. Normally speaking, HIPS should also monitor the modification of DNS settings in Windows itself. I did read about malware that try to change the DNS settings in routers.

 

Read a bit more on Dyre and Dridex. Both are performing an external MITM utilizing bot networks. The initial HTTP request is routed to their C&C servers which take over the rest of the attack. And for the end user, it does indeed look like a valid HTTPS connection to their bank since they are capturing and unencrypting the traffic on their external servers.

Again both attacks are initiated though bogus e-mail. So that is where you stop them. If they get further than that detecting the initial HTTP outgoing request via DNS poisoning methods is crucial. Finally, both Dyre and Dridex will download a .exe dropper file which is the guy that will do the redirect via HTTP to the botnet. So the attack can be stopped by detecting the dropper execution.

Also note that these Trojans are directed at corps. and financial based orgs.. These bad guys are after the "big bucks!"

 

The malware is doing the redirect at the network level so HIPS will not detect this. You need a good firewall with IPS protection that has DNS poisoning protection to detect this.