HitmanPro.ALERT Support and Discussion Thread

Nope, I also think that prevention is better than treating the symptoms. Having multiple layers to guard just in case however is not.
Peters repeated use of 'keylogger' rather than 'keystroke encryption' or 'anti keylogger' is rather baffling though as he knows better! but obviously everyone knew what he meant so no biggie.

 

afaik the last time that zero-days were used in a blind mass attack was in 2013 when BlackHole included a Java 0day (http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html ?).

Zero-days are normally only used in targeted attacks against for example governments, research institutions and other 'high value targets'.
But we have seen that Flash Player patches can be reverse engineered within just a few days. So if you've not yet installed an update at that moment and you're not running any mitigation software, then you're still toast.
And do not forget the use of malicious macro's in mass spam runs. The dropped executable should still be prevented from running with MBAE/HMPA.

 

Thanks for your valuable contribution, I'm very interested in what you posted in this thread.
It' good HMPA's HW assisted CFI can block call-proceeded ROP which of course will bypass EMET caller, but I wonder whether this also can block some ROP-like attack such as Jump-oriented Programming and Call-oriented Programming which can bypass many known defenses.

 

HitmanPro.Alert currently does not block JOP-attacks. Also if an attack would entirely consist of CALL-preceding gadgets it would not be detected either. Though such attacks are very difficult to make, though not impossible.

Check out this paper that discusses this:
http://www.cs.columbia.edu/~mikepo/papers/chainlength.sec14.pdf

The paper extracts address from the IAT of loaded modules.
Therefore HitmanPro.Alert includes IAT filtering to counter this.

From a recent real world scenario:
http://researchcenter.paloaltonetworks.com/2014/11/addressing-cve-2014-6332-swf-exploit/

We do not claim to block 100%. But HitmanPro.Alert does raise the bar for exploit creators significantly.

 

Thanks for explanation, I now understand the value of IAF though haven't read the paper (I'll do, but maybe can't understand).
It's great that HMPA expand many feature of EMET, heap spray protection to dynamic heap spray, caller to HW assisted CFI, and EAF to IAF + EAF?
How about Stack Pivot protection? AFAIK, this is another widely used technique.

 

StackPivot are of course mitigated as well. You can test using our Exploit Test Tool.

 

Of course I have also looked at JOP and COP (if you can call it that way), but you'll have a hard time finding the right gadgets. A single RET only takes up 1 byte (c3), whether a CALL of JMP instruction takes up at least 2 or 3 bytes. And even with very large libraries like mshtml.dll it will cost you hours of searching in order to find the right gadgets.

I completely agree, chaining 40 gadgets is not very good for reliability. Moreover searching memory for the correct gadgets or hardcoding the offsets for dozens of possible configurations is nearly impossible (Okay CVE-2014-0497 used 34 hardcoded configurations). Combined with up-to-date 64-bit IE11 with EPM or 64-bit Chrome it basically renders memory corruption dead.
Sending an executable in an encrypted ZIP file would be a better 'solution' in that case.

 

Usually happens for me on Chrome and IE 11 as well, but not all the time. I have to disable either Keystroke Encryption or Safe browsing to make it work...

 

Please allow me to comment.

Yes, in theory computer users would hardly need an anti-exploit product when they keep all their applications up-to-date by installing updates as soon as they appear. And, indeed, there are two types of attacks:

1. (nation-state) hackers exploiting unknown software vulnerabilities (zero-days) to infect computers that run up-to-date software
2. cybercriminals that use exploit kits that abuse known software vulnerabilities to infect computers that do not run up-to-date software

In the real-world many computers (often deliberately) run outdated software for many, sometimes legit, reasons:

• Computers run an outdated operating system that doesn’t receive updates because:
  • users don’t have the money to upgrade their computer, or
  • IT management is behind schedule upgrading company computers to a newer operating system, or
  • computer is part of a medical or industrial system and there is no support from OEM, or
  • computer has no internet connection to download updates, or
  • operating system is a patched pirated copy which does not receive updates, or
  • malware prevents or disabled automatic updates.

• Computers run outdated software because:
  • software update requires user interaction and user does not know what to do, or
  • software has no built-in updater, or
  • software requires a paid upgrade and users are not informed or willing to pay, or
  • custom company business software is not compatible with the newer software (like browser or platform runtime) and requires a paid adjustment from OEM, or
  • IT administrators need to coordinate and test updates to prevent business disruption, or
  • software is a patched pirated copy which does not receive updates, or
  • computer has no internet connection to download updates, or
    
  • user is fooled to install older vulnerable software version, or
  • malware prevents or disabled automatic updates.

Everyday a huge amount of computers become infected because they run outdated software. Not to discredit any antivirus vendor (you cannot judge a fish by its ability to climb a tree), in most cases antivirus software is unable to help because it's designed to focus on the specific payload or attack URI – not the exploit itself.
Attackers have infinite possibilities to obfuscate the payload or create a new attack URI to deliver the malware, unknown to antivirus software. Attacks aimed at both home and business users are tailored to antivirus software – attackers test their stuff against antivirus software for guaranteed results (that's also the reason why there are many forums that help victims to get rid of malware).
Some real-world examples:

• Dutch hacker uses Metasploit to infiltrate 2000 computers, spies on victims in their homes via their own webcam: http://www.politie.nl/gezocht/dossiers/2013/07-onderzoek-hacking.html?dt=true
• Malware in ad networks infects visitors with CryptoWall 2.0: http://www.proofpoint.com/threatins...s-infects-visitors-and-jeopardizes-brands.php
• RIG Exploit Kit pushes CryptoWall ransomware: http://threatpost.com/rig-exploit-kit-pushing-cryptowall-ransomware/106540
• FlashPack Exploit Kit uses ad networks to deliver CryptoWall, Zeus and Dofoil malware, success rate 17 to 41%: http://www.securityweek.com/flashpack-exploit-kit-uses-ad-networks-deliver-cryptowall-dofoil-malware
• Malicious advertisements served via Yahoo, success rate 9%: http://blog.fox-it.com/2014/01/03/malicious-advertisements-served-via-yahoo/
• Magnitude Exploit Kit success rate 5 to 20%: http://blog.spiderlabs.com/2014/08/...den-the-magnitude-aka-popads-exploit-kit.html
• Sweet Orange Exploit Kit success rate 10 to 15%: https://www.bluecoat.com/security-blog/2012-12-17/forbidden-fruit-sweet-orange-exploit-kit

The majority of the victims were running up-to-date antivirus software while the attackers were exploiting known vulnerabilities. Some exploits are years old:

• Overview exploit kits and their exploits (December 2014): http://contagiodump.blogspot.nl/2010/06/overview-of-exploit-packs-update.html

So even though antivirus vendors are writing blogs about exploits and exploit kits, it does not mean their software offers solid protection against them. If an antivirus does offer some protection against certain exploits, they are often based on byte ranges or strings found in an existing attack. If another attacker alters or obfuscates e.g. the shellcode of the same exploit, the signature does not trigger and the exploit succeeds.

Bottom line: Attackers can tailor and create infinite unknown payloads and attack sites but there are only two dozen techniques to exploit a software vulnerability. Being able to detect and block the core techniques of an exploit attack means stopping the infinite amount of malware payloads.

Hope this helps.

 

So, it's not different from EMET? I found one writer says StackPivot can be bypassed as EMET only monitor critical functions such as CreatProcess, and he provided PoC (actually it's PoC of COP, but he says you can understand how he bypassed StackPivot in this PoC).

The term JOP and COP seems to be already accepted in industry. Okay, so those technique are currently less reliable than ROP as JMP or CALL takes up more bytes, forces more effort for attacker to find useful gadgets. Then, though this might be naive question to you, can you think of any possibility to increase those attack's reliability? I ask because, use-after-free was firstly thought as not reliable but it became reliable when combined with other technique, especially heap spraying. And maybe you remember when DEP is introduced, some experts thought RCE by memory corruption had ended, but actually attacker developed many ways to circumvent DEP.

 

Quite persuasive explanation, though known old exploit and corporate user are out of scope for the original discussion. Especially I like the first 2 or 3 sentences, it shows your honesty.

I know there're huge differences among AV/IS products when the exploit is obfuscated, so in that case anti-exploit is big plus, but at the same time the first principle is keep up-to-date as long as possible. You shouldn't use anti-exploit as excuse for not updating, but I know there're sometimes valid reason not to update.

 

Our StackPivot mitigation is very similar to EMET's implementation. Many other mitigations are very different, like (obviously) the CFI branch trace facility (hardware-assisted ROP detection), Application Lockdown, IAF mitigation and all the stuff on the green and orange tiles.

You can bypass StackPivot mitigation by unpivoting before CALLing a critical function (a function that is hooked to perform exploit mitigations; e.g. CreateProcess, VirtualProtect, etc.).

See page 15 of this bypass paper:
http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf

 

Very annoying thing happened tonight with HMP.Alert. I woke my computer up from sleep mode, and got a banner from HMP.Alert saying a new USB device was detected that has keyboard functionality. The name of the device was the Cooler Master Storm Sentinel mouse. It asked if I wanted to allow or block, but since my mouse was disabled, I could do nothing. I tried using Tab on my keyboard to select "Allow," but could not find a way to select it. Eventually I Ctrl+Alt+Deleted and killed both HMP.Alert processes, and now I can use my mouse. However, I don't want to turn HMP.Alert back on until I know how to resolve this issue.

 

Some mouse devices act as a keyboard as they have back/forward buttons (for example). I reckon you did not connect the mouse while the computer was in sleep mode (perhaps connect to different port)?

For the time being you can disable the BadUSB feature on the orange tile (Advanced Interface).

Sorry for the mishap.

 

Will 129 auto-update to 131? I haven't updated manually to see if the autoupdate works properly.

 

First of all: in 'normal' exploits it would we sufficient to perform a stack pivot (XCHG EAX, ESP) after which you can directly run VirtualProtect().
Furthermore I haven't figured out a way of protecting against JOP/COP, I started looking at exploits deployed in the wild and exploitation techniques in October 2013 and it took me quite some time before I was able learn the basics. I think that Erik and Mark have gained more knowledge than I have

That's exactly the technique I use in one of my PoC's. 9 unique gadgets should be enough for that part. But even when you've landed on the stack you still have to create a fairly complex ROP chain to bypass ROP and CallerCheck with hardware assisted CFI.

 

I am back into the HMPA testing snapshot, and keystroke encryption was working.

Spoiler: screenshot

Then I got this darn message...

Spoiler: screenshot

 

...and guess what, keystroke encryption has now gone missing.

 

If the service dies, encryption fails to recover.

Can you run AppCrashView from NirSoft en send me the details of the crash. Thanks!

 

We havent updated the update servers yet. Will happen after X-mas.

 

Particulars for this app from the Nirsoft site:

"For now, this utility only works on Windows Vista, Windows 7, and Windows Server 2008, simply because the earlier versions of Windows don't save the crash information into .wer files."

I am running XP.

 

I just ran it, and it comes up with nothing.

 

HMP.A 3 RC Build 131 is showing that I have had one alert today, how do I find out what that alert was for? Apparently I missed it. Is there a 'History' feature planned?

Thanks.

 

A history of alerts can be found in the event log of Windows iirc