Bouncer (previously Tuersteher Light)

Yes, this should be the case. It blocks the exploit from injecting into other processes. That's why HMPA Test Tool is unable to launch calc.exe, etc.. I think containment like this will severely limit what an exploit can do.

 

Yes but you can also use a HIPS or sandbox for this. If you want to truly block exploits, you still need tools like MBAE and HMPA.

 

There's no HIPS left I like, and too many other security apps don't work well with Sandboxie. I don't like Comodo so it's sandbox is not an option either. There's not many sandbox options left.

Edited 3/11 @ 8:23

 

I have Bouncer and Pumpernickel installed, but the tray icon will only show for Bouncer. I installed Bouncer first. Also, if I disable Bouncer the tray icon will change to red, but if I check the log by the tray icon it will turn back to green again even though Bouncer is still disabled.

 

No that is not the case it works differenty it uses a windows mechanism introduced with Vista to protect system processes and made avaliable through an execution flag with Windows 8 at boot or at run time (intended to protect AV's processes).

It totally blocks memory read write execute (RWX) access. So with Windows 8.1 Microsoft introduced a sandbox (AppContainer) and a protection mechanism for User Mode processes. As shown with HPMAlerrt test tool it protects against side by side infections (like reflective DLL injection, see post #982) and as shown with ProcessExplorer against objects with higher IL (see post #984).

Having read more about it, I am strengthened in my opinion that the default should be allow and not on deny (Microsoft intended and designed this as an OPT-IN). But it is really a brliliant piece of software.

 

I have to admit that I'm confused. Where can I find more info about the MemProtect driver? I have searched for info on the excubits.com site, but I only found an article named "Mitigating against in-memory attacks". This article describes a tool that is designed to block an exploited process from injecting code into other processes, just like member Cutting_Edgetech described.

But you're saying that the MemProtect driver will protect against remote code execution exploits, simply by using a native Windows security feature? This is a bit hard to believe. I'm sure you know that MBAE and HMPA are using quite advanced techniques which gives them the ability to block exploits in an early stage. BTW, I also found this article about IE’s mitigation technology called MEMPROTECT, is this related?

https://threatpost.com/older-keen-team-use-after-free-ie-exploit-added-to-angler-exploit-kit/111350/

 

AppGuard totally blocks read write execute, but only from Guarded Applications. Until a few years ago AG blocked all processes from reading, and writing to the memory of other processes. It caused too many problems so now the memory protection only covers Guarded Apps.

AppGuard also uses internal Window's mechanisms from within the kernel according to BRN so why is it that MemProtect can pass HMPA Test Tool, but AppGuard can't? Do you have any ideal why? I guarded the HMPA Test Tool when I tested it against AppGuard, but the Test Tool was still able to read/write to the memory of other applications anyway. Guarded Applications are not suppose to be able to read, and write to the memory of other applications according to AppGuard documentation.

Edited 3/12 @ 6:19

 

HPMAlert test tool is just a POIOC (Proof Of Its Own Concept), not a validated test mechanism (look I just launched calculator, now I own your PC). Maybe AppGuard applies filters to vulnarable programs and whitelists harmless programs like calculator to increase useability. Remember its sole purpose is for marketing HPMAlert.

When you remove the battery or the plugs or the tires or the wheel it is hard to steal a car. HMPAlert's logic is look I have got the most anti-theft features (and got the most compatibility problems also), so I am the best. I would not worry about it.

 

(I think) the "less strict" memory protection was introduced with AG 4.0.

some lines of the changelog from AG 4.0 (v4.0.8.0beta - Sep/October 2013):
3. Improved MemoryGuard policy
4. Eliminates the need to configure MemoryGuard exceptions.
5. Reduces the need to configure Power Applications.

 

AFAIK, AppGuard does not use whitelisting to allow Guarded Apps to read, or write to the memory of any safe applications. There's really no reason to ever allow a Guarded Application (Vulnerable Application) to read, or write to the memory of other applications. That would provide a door to infect the System. I honestly don't think that is the reason. I already reported my findings to BRN twice, and they never got back with me. In theory AG should be able to pass most test from HMPA Test Tool because the Test Tool should never be allowed to read, or write to the memory of clac.exe if the Test Tool is added to the Guarded Apps list.

 

@Cutting_Edgetech I just wanted to follow up with you regarding my testing of MemProtect and ESET. I ran the virtual machine last night for a few hours and an additional few hours today as well. In this testing, I decided to use a trial for ESET Smart Security version 8.0.319.0 and ensure that all definitions and product updates were applied along with the typical default settings. For some reason, my Windows 7 SP1 (32-bit) VM failed to initialize the x86 version of the latest MemProtect (Beta Camp) driver. Even though it is digitally signed correctly, for whatever reason, Windows 7 32-bit could not check on the signature, so that is something that I will follow up with Florian on. So I decided to use a VM for Windows 8.1 (32-bit) and this had no issues for MemProtect running and initializing. Now, I understand that your setup was a 64-bit Windows 7 machine, so this isn't a 100% perfect reproduction, but I did my best to check on MemProtect rules and such. I ran several hours in non-lethal and also several hours in lethal mode and didn't experience any lockups or crashes. I also followed your suggestion to fiddle with and modify some rules and such within ESET Smart Security during this testing period.

Anyway, so I will share the rules that I used during testing.

Spoiler: MemProtect.ini

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
C:\Windows\*>*
C:\Program Files\*>*
C:\Program Files (x86)\*>*
C:\ProgramData\Microsoft\*>*
C:\ProgramData\ESET\*>*
C:\Users\*\AppData\Roaming\ESET\*>*
C:\Users\*\AppData\Local\ESET\*>*
C:\wallpaper\*>*
E:\PortableApps\*>*
E:\Downloads\*>*
[BLACKLIST]
[EOF]

So there are a few different possibilities here. I believe that this Beta Camp release is a bit newer of a release from the MemProtect that you tested previously, so that could be one factor. It could be that the issue is resolved in the newer release. Another factor is that it could potentially be an issue on 64-bit platform while not being an issue on 32-bit, but I am not entirely sure on that. My assumption is that is may have come down to rules, where one minor thing could potentially be catastrophic when it comes to blocking memory access to kernel drivers such as in ESET, if one of those were to be blocked it could be cause system instability. In such cases of a system freeze, it might not even be able to have a chance to write to the log file to give us any clues either. But anyway, it is difficult to determine exactly what went wrong and where the specific problem was. I would like to try setting up a Windows 7 SP1 (64-bit) VM later if I have time to see if I can better match your scenario and will let you know if I come up with anything.

 

Thank you for trying to reproduce my problem! It's most likely a difference in our hardware that's keeping you from reproducing the problem. I will try MemProtect again soon on a different machine.

 

According to Microsoft, this feature (protecting anti-virus services) has been changed with win8.1 So would not it be better to use MemProtect on Win8.1 or higher?

 

You're welcome. I always enjoy a good challenge or even just from a learning perspective, good times to be had. Anyway, I was able to locate my backup which contained my massive stash of Windows ISOs from over the years. So I gave Windows 7 Ultimate SP1 (64-bit) a try last night as well. But unfortunately, similar to the 32-bit Windows 7 situation I had previously, the digital signature of MemProtect failed to validate for me. I was able to validate the signature under Windows 8.1 and 10, but not 7 for some reason. So it is quite possible that it might fail for you as well if you try again on Windows 7 with the latest Beta Camp release of MemProtect. I'm going to talk to Florian about this Windows 7 signature issue with MemProtect and see what the problem is there and I will get back to you when I find out more.

Yes, absolutely. Although I suppose it is difficult to determine just how strong the protection is across platforms. But yes, the underlying memory protections evolved significantly with Windows 8.1 and then again with Windows 10. It would actually be interesting to have a comparable setup to test these protections across Windows platforms for comparisons sake, although that would take quite a bit of time and, while I have some available time, I don't think that I have the skills to determine what is actually happening under the surface on a technical level.

You know, it is quite interesting how many strong protections that Microsoft has actually built into the Windows kernel. If they truly wanted, surely Microsoft could create some of the most secure of security software tools and secure platform in general.

 

That's why there's only a veritable handful of users...

 

I tried it yesterday in a Windows7 32bit-VM and there was no error.
SHA-1 MemProtect.sys (32-bit): C6C690212BC16477AC92A241C14A73B7140D69CD

 

Like build in Firewall, Memory protection (DEP, SEHOP, ALSR, Heap Termination on Corruption, Flow Control Guard), UAC (with elevation block for unsigned), SRP (deny execute for basic users), ACL (deny execute for Everyone in internet facing folders), Smartscreen (reputation service on internet downloads), build-in sandbox (AppContainer for internet facing aps), and Memprotect's ELAM/PPL, guess your talking about my setup

 

Thank you for confirming and also for the SHA-1 hash. That hash matches up with my latest x86 copy from Beta Camp.

I tried a Windows 7 SP1 32-bit VM and also a Windows 7 SP1 64-bit VM in my testing. I was able to install MemProtect in both, but I was receiving an invalid/broken digital signature upon starting the driver. I even attempted starting Windows 7 in Test Mode and it still complained about the signature in both 32-bit and 64-bit which I thought was very strange. All attempts failed for me when starting the driver and the error was all related to invalid/broken signature.

So just to confirm, you used a Windows 7 32-bit VM and you were able to successfully start the MemProtect driver as well?
Which virtualization program were you using?

My testing was all done in VirtualBox. So I'm wondering if there may be some differences on kernel level between virtualization software, possibly.

 

Absolutely. As a matter of fact, I have always had great respect for your use of built-in OS mechanisms for security. I think that, whether somebody is using Windows or Linux or whichever operating system, it is important to utilize as many built-in security functions as possible. Use what is provided by the OS, essentially. It's a great strategy which keeps things light and efficient while at the same time reducing attack surface significantly.

By the way, the other day regarding your "Titanium Hardened Chrome" post (which I know has been edited since) was truly a work of art. I definitely appreciate it that you take time to share your different setups and strategies here. It is beneficial for myself and others to learn from and open up the mind as well.

 

@WildByDesign

Thanks. Reason for editing the Titanium hardened Chrome
a) Chromium is harder than titanium in fact chromium is the hardest metal on earth
b) After doing some testing with malware and PoC's and POIOC's I decided to skip the Pumpernickel write sandbox, not because it was not working correctly, but

Memprotect isolation made it redundant nothing could break out (I used a two year old Chromium threw some exploits at it, but Memprotect blocked them all), so when nothing can break out, the OS protections Chrome uses (even better with AppContainer) can't be bypassed.So a simple deny execute ACL on the download folder is sufficient.

 

The interesting thing there is that, after that initial Titanium Chrome post, I found myself researching different metals such as Titanium, Platinum, Chromium, etc. to see which was the hardest metal. It exercised my brain that evening.

Actually, I agree there as well. I recall Florian feeling so strongly of MemProtect and being so passionate behind that driver in particular that Florian said that, if configured appropriately, you could use MemProtect alone to protect your entire system from malware (meaning, not even needing for Bouncer, anti-executable at all). Although I have to admit that I personally have a lot more learning to do before I feel that confident and comfortable about it myself.

 

Well it is brilliant out-of-the-box thinking by Florian. He could have a real winner in his software portfolio.

 

Sounds great. Will also try to dig deeper into the MemProtect drivers, seems to be worth to spend more time on. I just tried it quick and dirty, but I guess there is more.

Well @WildByDesign I also had such an issue on a Windows 7 machine (fresh installation w/o any patch, or service pack). I tried to find what was going on. I think there is an issue with Windows 7 and checking digital signatures made with newer algorithms (as far as I understood by googleing). There were some reports on such issues, it seems that MS fixed that in some SP. The question is where and when... I'll try to find more.

Off topic: I've also tested Pumpernickel for some days now and can say: Wow, this one is really brilliant. Again - like with all Excubit's stuff - it is hard to find a starting, but after a while you get comfortable and enjoy the freedom Florian give with his drivers (one can really do what he wants, no blackbox design). I tried (on a VM) to start up a cryptolocker just to see what happens. I made a huge list of extensions that are typically used by the cryptolockers to encrypt and only made them accessable from C:\Windows\ and C:\Program Files\ (used an Windows 8.1 32-bit). Well, what to say: Pumpernickel sucessfully blocked any attempt made by the cryptolocker to excrypt (or delete) the protected files. It was also great fun to see how this beast gone through the folders and tried to (unsucessfully) encrypt files Just for analysis this is really fun, but I could also think of setting it up to protect.

 

Yes, sure. To my understanding the drivers cannot detect an exploit, they "just" block attempts. Using a HIPS/Sandbox would provide you such information and may block an exploit in an early stage. On the other side such tools eat performace, because in some way they need to do real-time analysis on a watched process or they do API hooking. I know of exploits that check exactly for typical HIPS/Sandboxes, especially for API hooks. If the encounter such, they quit or go to sleep. Targeted exploits also check for VMs, etc. So I thinks you will never have and find a 100% solution that will catch or early-detect all exploits, because there are ways around. I know of static/hybrid analysis frameworks that try to go deeper without getting tricked by the exploit (or malware) but this is out of scope for a normal PC user and - as far as I know - will also not be installed on user PCs, instead such tools are running on analysis systems that do automatic malware/exploit exfiltration...

Hmm, I think the typical Anti-EXE (and Florian's or NVT-Andrea's) tools are great mitigation for normal and more advanced users.
When you are scared of more sophisticated attacks I think you should use a completely different approach for protection. I would go for a dedicated Raspi just for the single risky online job I need to do. I would also reflash the Raspi's SD-Card recently. So, one Raspi SD-card just for surfing the web, the other one just for e-mail, maybe another one for online-banking. And for the important - not to steal, spy on etc. work I would use my normal Windows PC. To switch between the machines there are great port-multiplexers availabe, so you can easily switch between the different machines with just hitting a simple knob. Another solution is to use diffenrent VMs and never working on the VM's host. There are also professional solutions on the market that have NATO Secret or other high security level certification. They also base on VMs and split different security levels into several VM machines, like in the Qubes OS.

I often have the feeling that people mix things. On one hand they want a fancy OS with all features, but want to be ultra secure. Then they install this and that security tool to mitigate. Then some complain about complexity, of loss of performance or that the solution is not 100%. Well, first of all there is no absoulte security and there is no solution that fits all. First you should check your own risk then find adequate mitigation for YOUR specific problem. This will of course differ from the solution your friend might need. But this is okay. It is like with cars, as a family father you may wish to have this GT xyz, but to carry your wife, kids and stuff, a SUV might suit your needs better. And to keep the car example: Even if you have a supreme car with 16 airbags, high class seats and a super belt you can still die in an accident because there is no absolute security and if you drive against a wall with 300 km/h, you well even die in a S-class Mercedes. So is with IT Security Solutions... I often see/hear people complaining about AVs, Firewalls and other IT Security Tools, but at the end it has also something to do with the user: If you use warez, surf on the dark net, watch illegal porn stuff etc, it is like driving with 300 km/h into a wall. You then cannot blame on Mercedes, so you cannot blaim against your AV, Firewall and Security tool, it is you - and YOU also have a responsibility for your own security.

 

Me too. Windows 7 32-bit VM with VirtualBox.
And yes, the driver was 100% loaded
Proof: