HitmanPro.ALERT Support and Discussion Thread

Thanks for the feedback, I always wondered about how CryptoGuard worked, and it seems to take a quite interesting approach, haven´t seen this in any other HIPS so far.

 

Thanks for the info, I´m afraid that at the moment I don´t have the skills to test these tools, but nice to know that HMP.A could also stop these exploits. It all sounds very exciting. By the way, what do you think about MBAE´s three layer protection approach, does HMP.A has something similar? I´m mainly talking about the third layer (application behavior protection).

https://www.malwarebytes.org/business/antiexploit/

 

Copy on open, compare on write-back for each document. Even AV's limit their on-access checks to executable formats. So this has to be done in a smart way (filtering on originating process etc, optimising disk access) to offer such a feature without noticeable performance delay.

See https://www.wilderssecurity.com/thre...discussion-thread.324841/page-76#post-2391836

Loman brothers also managed to fitt in a disassembler (for x64) support in a very small RAM footprint (before Microsoft did), so their products are remarkeable technically. Also the feature I did not grasp initially (using CPU-features for ROP protection) is an example of out-of-the-box thinking.

 

Yes, I did. I tested MBAE, EMET and HMPA. EMET does not protect against Java-based exploits in exploit kits, so you might want to take this into account if you want to protect your organization against exploit kits but are bound to running outdated version of Java (e.g. because of custom company applications).

 

TH.

Gerardo di Giacomo wrote (Please use the translation):

 

@markloman and/or @erikloman

When "deep hooks" are activated in EMET 5 i get app crashes for every emet-enabled application. This occurs when Alert 3 is installed (even in freeware mode, without mitigations)

Only solutions I found:
- Disable deep hooks
or
- Disable all of the following EMET mitigations: LoadLib, MemoryProtection, Caller, SlimExecFlow, StackPivot

Operating System:
Win 8.1x64, german | security applications: Sandboxie, AppGuard, EMET 5, HMPAlert
(reproduceable even with Sandboxie and AppGuard deactivated)

If you need any crash informations or dumps - please let me know.

 

That's correct. My statement was about the Java-based attacks currently carried out by the many exploit kits. None of them are blocked by EMET since the used exploits do not revolve around memory corruption vulnerabilities.

 

Did you receive my PM? If you have the time, please respond (via PM).

About post #2027, the reason why I asked is because MBAE can stop exploits/payloads even when "exploit mitigations" are bypassed. I´m not really sure if that also applies to HMP.A, because it´s already using more advanced techniques than MBAE, at least if I understood it correctly.

https://www.wilderssecurity.com/thre...discussion-thread.324841/page-82#post-2396303

 

I received your PM but we're very busy working on Alert 3.
The following post provides some insight regarding stopping exploits/payloads when mitigations are bypassed: https://www.wilderssecurity.com/thre...discussion-thread.324841/page-74#post-2390685

 

@ markloman

I can understand that, but if you have some spare time (when HMP.A v3 is finished) you might still want to check it out.

Also, I think I'm misunderstanding something, but the test in post #1827 shows if mitigations are working or not, am I correct? But if those mitigations are bypassed, is it then automatically game over? Perhaps a silly question, or perhaps I´m misunderstanding what MBAE´s "layer 3" protection is all about, see link.

https://forums.malwarebytes.org/index.php?/topic/136424-frequently-asked-questions/#entry846361

 

There are several exploit techniques and variants in our Exploit Test Tool, currently a total of 15 exploit tests. Post #1827 is an overview which of the tests are successfully blocked (“passed” in that post means blocked as mentioned in the subsequent posts #1828 and #1829). If a test is not blocked then the anti-exploit / exploit mitigations are bypassed, meaning that if it was a real-world attack, the computer would have been infected. Most tests in our Exploit Test Tool try to start the Windows Calculator (calc.exe), but the URLMon tests try to download a benign payload which shows the message “This is a test file that could have been malware when not blocked”.

Regarding your layer 3 question, if you think about it, the answer is in plain sight on the linked page you provided:

"If an exploit manages to bypass EMET's memory protections, the computer will be compromised. MBAE incorporates a Layer 3 Application Behavior protection which prevents compromise even in the case where memory protections have been bypassed."
​

For outsiders I can imagine that it sounds like magic, but it simply means that when exploit mitigations are bypassed ('layer 1' and 'layer 2') MBAE filters the processes that spawn from the protected application. This is also the reason why there are profiles or templates. Because contrary to a browser, for a PDF application/document it is very uncommon to download binaries from the internet and/or start a new process. So *not* every application should receive the same exploit mitigations or things will break, as mentioned by Malwarebytes on your link as well: “The profile tells Malwarebytes Anti-Exploit how to adapt its exploit mitigation techniques to the newly protected application. It is important that the correct profile is applied.”

To keep things easy-to-use, HitmanPro.Alert offers automatic protections, as well as built-in templates to set the recommended exploit mitigation settings for custom applications. If a user wishes to deviate from the template/recommended settings, they can even use our fine grain settings to enable or disable this ‘third layer’ for any application they like – we call it “Deny New Process”, which filters new processes.

 

I've just run the "Run Windows Calculator" hmpalert64 exploit test and Windows Calculator started. Does that mean hmp.a failed? Did I test incorrectly?

Yes I did configure the exploit tool to be protected by emet 4.1 update 1.

Thanks.

Oops, never mind. I realised now that I didn't read the pdf properly.

 

As mentioned in the user interface, the 'Run Windows Calculator' is not an exploit test, but a test to verify if the tool is able to start the Windows Calculator (%systemroot%\system32\calc.exe). So it should not be blocked. If 'Run Windows Calculator' is blocked, no fair test can be conducted.
Also check out the Exploit Test Tool Manual, as it provides lots of information regarding each test.

 

OK. Got it.

Two that did fail were Load Library and URLMon exploit tests.

 

Are you testing HitmanPro.Alert 3 or EMET 4.1 U1? In the lower left corner of our Exploit Test Tool you can see if EMET64 or Alert is protecting the tool.

 

I was testing HitmanPro.Alert 3. There must be a conflict as the GUI detects both.

 

That's OK, HitmanPro.Alert 3 and EMET 4.1 are compatible with each other. You've correctly configured EMET to protect our Exploit Test Tool.
But the Load Library and URLMon should be blocked, an 'Attack Intercepted' alert should appear, before EMET detects it.
The message 'Load Library exploit/test failed' should only appear when you close the alert. This is OK. It means the exploit technique was successfully blocked.
Do you get an 'Attack Intercepted' alert on both exploit tests?

 

"Do you get an 'Attack Intercepted' alert on both exploit tests?"

The "Test Failed" popup appears briefly before 'Attack Intercepted' appears on the Load Library test, but the is no notification from hmp.a when I run the URLMon test - Windows Calculator opens straight up.

 

Load Library is correctly blocked but there seems to be something going on with the URLMon exploit test on your machine. Is it consistently reproducible? And could you try the 32-bit version of our Exploit Test Tool as well?

 

Yes, running the x64 URLMon test is consistently reproducible.

The three 32-bit URLMon test were all blocked.

 

Ha, we got a bug on our hands. We'll investigate, thanks!

 

The three 32-bit URLMon test were all blocked. However, I've just run the Stac Exec test and the ROP – NtProtectVirtualMemory test with HMP.A-Test crashing the test tool. VirtualProtect via CALL gadget test opened Windows Calculator. SEHOP test crashed the test tool. Heap Spray 2 test crashed the tool. Load Library test had the same result as the x64 tool.

 

Could you also test without EMET?

Note: if you are testing HMPA in a virtual environment, the fourth ROP exploit test in our 32-bit tool (ROP - VirtualProtect via CALL gadget) will not be blocked by HMPA or EMET, since it requires special processor hardware registers which are not translated from the host to the guest environment.

 

OK.

It's getting a little late here in Oz, but I'll uninstall EMET and test again tomorrow.

By the way, no virtual environment.

Cheers!