Bouncer (previously Tuersteher Light)

@WildByDesign and @Online_Sword

Re: updates of different drivers with seemingly overlapping functionality

Don't think of general purpose expert tool, but imagine application isolation for a specific program working out of the box with presets
a) no write to UAC protected locations (pumpernickel)
b) no memory access outside allocated bounderies (memprotect)
c) no program launch except specified/preset executables (bouncer)
d) no executable writes except specified/preset executables (MZ write Scanner)

This isolation layer would be easier to install (set and forget) and tightly configured since the settings would be for a specific (pre-configured) program, it would be like having a combination of SBIE and MBAE/HPMA working out of the box (no power user knowledge required) for a specific program (e.g. Firefox since it lacks a sandbox). Look at the number of posts mentioning SBIE + MBAE or SBIE + HMPA and the questions/problems on configuring it correctly.

So this program would have "business rules" designed and maintained by Florian. This would also justify a lisence fee for maintaining this set of business rules. With a freemium formula (e.g. the first year free license of SecureAplus) or a report only trial (basically like HitmanPro and Prevx's CSI), the user data base could grow rapidly. Look at uBlock Origin, it is downloaded over a million times, how much would have had the developer earned when he would have charged a dollar for each install (after one year usage like whatsapp).

Think of the phases of a exploit/malware and how these individual drivers fit in:
1. Memory exception which changes the execution flow (the exploited bug)
2. Execution of a piece of code (already in memory on a different location) [memprotect]
3. Downloading additional code (writing to disk) [MZ write scanner], executing this [bouncer] and survive re-boot (writing to UAC protected file location) [pumpernickel]


Regards Kees

 

At the moment with Pumpernickel driver, I've got Chrome entirely contained/restricted to what is shown in the code box below (and still experimenting). I have also allowed for a Downloads folder, however, that can be restricted as well.

Code:

[#LETHAL]
[LOGGING]
[SANDBOX]
# this rule allows notepad.exe to write only on files having ~~ in their path/file name..
#*notepad.exe>C:\Users\*\allowed.txt
#*notepad.exe>*~~*
#*notepad.exe>C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\iconcache_*.db
#*notepad.exe>C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db
#*notepad.exe>C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\IconCacheToDelete
#*notepad.exe>C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations
# some test rules for google chrome. works well in Windows 8.1 (32-bit)
*chrome.exe>C:\Users\*\AppData\Local\Google\Chrome\User Data\*
*chrome.exe>C:\Users\*\AppData\Local\Temp\etilqs_*
*chrome.exe>C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\*
*chrome.exe>C:\Users\*\AppData\Local\Google\Chrome\User Data
*chrome.exe>C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\iconcache_*.db
*chrome.exe>C:\Users\*\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db
*chrome.exe>C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations
*chrome.exe>C:\Users\*\AppData\Local\Microsoft\Windows\INetCache\counters.dat
*chrome.exe>C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*.automaticDestinations-ms
*chrome.exe>D:\Downloads\*
*chrome.exe>D:\Downloads
[EOF]

As with any of Florian's kernel drivers, I always highly recommend running initially in non-lethal [#LETHAL] mode with [LOGGING] enabled, run your programs as per your usual daily habits, and the logs will provide nearly everything that you need to get started with your rules as far as what is necessary.


@EASTER You're welcome. Yes, I figured that once I realized that the drivers were not signed that it would be a good idea to give everyone a heads up. I would certainly rather that the drivers be signed, however, I assume that he's got reasons for doing that with the Beta Camp drivers. I will post here when these drivers pass through Beta Camp and go stable in which they will then be signed drivers and programs. Also, I absolutely respect and appreciate that you would not want to circumvent those security mechanisms on your current rig.

@Windows_Security You've always got such great insight, imagination, and the creativity to better understand and visualize the many possibilities that can be achieved with various low level software. Thank you for taking your time to share your ideas and opinions for which I've got such great respect for.

 

@Windows_Security : Thank you for your reply. The business model that you described is reasonable.

@WildByDesign : Thank you for sharing your rules. According to your rules, I think Pumpernickel allows the user to specify which files/folders can be accessed by a specific program. That is good...But...what I expected in the past was a tool that can allow us to specify "which programs can write to a specific folder"...It would be different.

I mean, what I expected in the past was a tool that can:

• Prevent any programs except windows updaters from dropping executable files into the windows folder
• Prevent any programs except program updaters from dropping to the folder of program files,
• Prevent any programs except specified document editors from writing to the document folder (against ransomware).

To achieve this, we need a tool that allows us to specify "which programs can write to a specific folder".

The current version of Pumpernickel could be used as a sandbox, but a real sandbox, like sandboxie, could monitor not only the writing operation to file systems, but also the writing operation to registry items. I am not sure whether Pumpernickel could do this.

I am sorry for complaining so much here...

 

I am curious how Bouncer would handle fileless (in-memory-only) malware?

It piques my interest since fileless malware has been an on-going discussion elsewhere on Wilders.

 

This is something that piques my interest as well and much of that on-going discussion here on Wilders has been rather interesting. And it's quite possible that we will see more fileless malware in the future.

We would really need a kernel level developer to join in on those conversations to give a more realistic idea. A lot of it would depend on the calls made within the kernel (process creation, etc.) as to whether or not traditional application whitelisting / anti-executables would pick them up or not.

There is also the entry point to discuss. While traditional anti-exec may or may not pick up calls within the kernel, they would definitely intercept most common entry points. However, the area in which they would most likely fail is exploits. Real, legitimate exploits. That is why, Florian in particular, recommends using an anti-exploit (EMET, MBAE, etc.) along with Bouncer. Also, that is why he has developed some other drivers for Administrators to control write access, control over interpreters, and so on.

The exploit weakness in traditional anti-exec is also where MemProtect driver comes into play: (from bottom of Beta Camp page at https://excubits.com/content/en/products_beta.html) That is what Florian is working on to fortify Bouncer more, anyway. Hopefully that will works its way into the main Bouncer driver at some point down the road.

A while back, Florian had mentioned about following some of security researcher Casey Smith's work (http://subt0x10.blogspot.com/) which is pretty interesting as well. I only recently had a chance to read it all and it's quite good information about using different components of .NET to bypass traditional anti-exec, bypassing typical process calls within the kernel. Casey's Twitter (https://twitter.com/subtee) and Github has some good stuff as well.

I would definitely like to see Bouncer integrate some more of the individual driver features so that we have even more control and also have the ability to enable/disable whichever components we need. Florian has also mentioned that he may actually pay someone to design a new GUI for Bouncer as long as Bouncer continues to be profitable, he will consider hiring a GUI designer. So let's hope that everything continues to progress well.

 

That's all good stuff @WildByDesign .

The only security soft that I know for sure that detects fileless malware is COMODO. COMODO's HIPS module detects and alerts to all actions on the system, but only in Paranoid Mode.

It's a bit convoluted, has limitations, and just isn't a satisfactory solution at this point in time against in-memory-only malware.

There really is no definitive evidence with regards to HMP.A, NVT ERP, VoodooShield, AppGuard, Bouncer and fileless malware. Lots of discussion and speculation, but no proof-positive confirmation one way or the other (unless I missed something somewhere out there in the ether... LOL).

Oh well... that's just how it goes sometimes.

Anyhow, it is all a worthwhile subject for the security geek.

 

Anyone experience this when creating rules - after restarting driver ?

I just purge the cache. All gone. Startled me for a moment...

Harmless, but still a quirk...

 

@hjlbx

I think your problem is that BouncerTray has too many children processes?

At the moment I have no virtual machine running win8.1, and I cannot reproduce this problem in my physical system that is running win7...

Spoiler: screenshot

https://i.imgur.com/a9CZfCE.jpg

 

Yes. I think it is cache issue. Clear cache. All excess entries gone.

 

Anyone run into this issue with CommandLine Scanner ?

Execute CLS driver using Admin cmd.exe.

Returns:

Error 1275
The driver has been blocked from loading.

Driver is digitally signed...

 

Never mind. 64 bit version is paid only. I didn't see that anywhere... although I might have missed it.

 

No, I don't think Pumpernickel driver monitors writing to the registry. Although Florian, at one point, did create a kernel-mode driver specifically monitoring the registry. See: http://bitnuts.de/ and search for either "A kernel based Registry Scanner" or "2015/04/04" which was the date of that blog post, closer to the bottom of the 2015 blog postings. This was more for security researchers and general forensics work, but I don't believe that there was much demand for this and therefore I don't think that he has done much more programming of that driver. He went on to continue more work on Bouncer, MZWriteScanner, MemProtect and so on. But if there becomes enough demand for kernel-mode registry protection, I am sure he would be able to pick up where he left off with the development.

I see what you mean there. I imagine that there are many different approaches and methods, so hopefully this Pumpernickel driver can evolve well and have a more broad way of configuring it to include the way that you are mentioning. I think that your idea is very good as well. I would suggest that you have a conversation with Florian some time and express those suggestions and see what can be done.

Yes, actually I have seen that several times in the past. Although I never really understood the reasoning behind that. I haven't seen it recently though, but my usage of Bouncer may have changed over time as well. Since you understand the techinical aspect of that issue, and if you know of a method that can prevent that from happening or resolve the issue, please do feel free to mention that to Florian so that he is aware of it and can implement whatever fix is necessary. BTW, how do you go about purging the cache when that happens? Thank you for your time, much appreciated.

Yes, unfortunately the 64-bit version of the CommandLineScanner kernel driver is paid while the 32-bit remains free. If I remember correctly, he was charging something like $5 for the lifetime licence. However, Florian is aware of the power and importance of the CLS functionality and that is why he is planning on integrating that feature into the main Bouncer driver. I believe that is his next step after playing around with the Pumpernickel driver concept. But as far as testing and trying out the CLS driver right now for curiosity sake, you could always run a 32-bit VM on your 64-bit host machine. That is what I did on a few occasions.

 

@WildByDesign

I just ran CCleaner with CCEnhancer @ default settings and the Start-Up Task Manager list was cleared of the extra entries.

I sent a screenshot to Florian. They stated that they thought it was a problem with the Bouncer.ini and Bouncer.log files. Both were submitted.

There has been no reply.

The Bouncer.ini file only had the default rules plus a few additional ones. The Bouncer.log was empty.

I do not think the issue has anything to do with either of those files.

However, I suppose we must await an official answer.

 

Well, fileless (in-memory) malware is hyped a bit. If you do some research and in-depth reading of articles you will find that most fileless malware is not so fileless as statet. I have read many news and blog articles headlining that there is *the brand new* in-memory-only malware, but at the end it became clear that these guys had to save something somewhere. In most cases hacker use registry to store the malware that will be started as a wscript script or batch. others still use exe/dlls and inject them into other processes. In all cases I hav seen there was some trace left. So in my opinion there is no big shift to fileless, because hackers want to infect target for long time. fileless only makes sense for exploits and if attacker is able to attack you every time you boot up your machine again. i have read about an attack (supposedly it was an "agency") that infected politicians though web browser each and every day with in-memory malware because they knwe that the people were opening the same web site every day. So they 1. hacked the web-site and placed a very special targeted exploit there to attack their victims (and only them, they limited infection to special browsers and IP address range).

What I wanted to say is: I think fileless in-memory attacks are very special and nothing the ordinary user currently should fear. Perosnally I think that all that blinky and shiny new-threat/anti in-memory attack protections tools did not proof if they are really ready to fight. I think that they do not and will not, because in-memory attacks are hard to defeat, its like with exploits. A lot of companies claim that their solution is super-dooper cool and is able to fight this and that exploit. Well, until the hackers get around. It is an endless story. So I would not go for extra fileless/in-memory protection because I think it is (currently) useless, becasuse there is not the amount of attacks out there. Better set up a good baseline...

 

Maybe it is caused by CCleaner?! I never had such issues and I use Windows 8.1 32-/64-bit machines. Bouncer works smooth and without any problems here.

 

Nice post. Protection against this kind of attack with dedicated tools is usually only one layer in securing computers. But same as you, I believe it's not necessary for regular users.

 

As 4Shizzle mentions, most fileless malware is based on an exploit to change the flow of execution, often to a piece of code they planted on a predictable memory location. That planted 'egg' needs access to some scripting engine and or command shell (that is part of the trick of fileless malware using features already installed on your computer)

I don't think the sandbox as described in post 776 could protect you against the actual exploit (first stage). Memprotect could make it harder to execute the planted code (second stage) and Bouncer could block all sorts of scripting/shell features already installed on your computer (third stage). MZwriteScanner could block the actual writing of executables (fourth stage), as 4Shizzle tells even fileless malware needs to write to disk and survive reboot (stage 5) for which pumpernickel could add some barriers (because it blocks writes to UAC protected folders).

 

@Windows_Security ... I am not at your level of knowledge in terms of all the fine details, but I generally understand.

 

Florian and staff cannot account for multiple entries in Task Manager Startup under BouncerTray.exe.

It is indeterminate quirk at this point.

 

LOL, thanks other find me a stray man, because I am good in buzz-word bingo. I also lost a bet (hence the patch over the stray-man's mouth), because I was wrong. so take the level of knowledge with a large grain of salt.

 

@Windows_Security - still, you know more than I do...

 

Good News from Florain regarding Pumpernickel

Several days ago, I wrote an email to Florain on Pumpernickel. In my letter, I mentioned that the function of allowing users to specify "which applications can access a specific folder" could be implemented in Pumpernickel without influencing the grammar and semantic of Pumpernickel. In my opinion, this could be achieved by splitting the rules in Pumpernickel into two sections, WHITELIST and BLACKLIST, and allowing the user to use the priority symbol "!" in the WHITELIST.

In such case, when an application A.exe tries to write to a file B.txt, it will:

• First, looking up the whitelist rules with priority symbols. If there is a rule that can match A.exe>B.txt, then this writing operation should be allowed. Otherwise, taking the next step.
• Second, looking up the blacklist rules. If there is a rule that can match A.exe>B.txt, then this writing operation should be blocked. Otherwise, taking the next step.
• Finally, checking the whitelist rules without priority symbols. Now we can take the same action of the current version of Pumpernickel. In such case, this writing operation will be allowed if there is a rule can match this operation, or there is no rule whose left side can match A.exe. Otherwise, this writing operation will be rejected.

If these changes could be implemented, then we can have the following rules (please note that this is just an imaginary example to illustrate the difference):

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
!*\notepad.exe>D:\Documents\*.txt
!*\winword.exe>D:\Documents\*.doc
!*\winword.exe>D:\Documents\*.docx
*\notepad.exe>*.txt
*\winword.exe>*.doc
*\winword.exe>*.docx
[BLACKLIST]
*>D:\Documents\*
[EOF]

Please note the priority symbols in the first three lines. With the rules above, we actually specify:

• Office Word can only write to doc and docx documents.
• Notepad can only write to txt files.
• Only Office Word and Notepad are allowed to write to D:\Documents, other processes cannot write to that folder.
• Other processes will not be prevented if they want to write to the folders other than D:\Documents\, so the system processes will not be influenced here.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A good news here is that Florain gave me a positive response yesterday. The following two paragraph is his reply:

Thanks for comments on Pumpernickel. Well, it was our first release for that Project and we are still developing behind the scenes so this is an ongoing process. Thanks for your ideas and remarks. We are already considering white- and blacklisting as it seems to be more powerful. On the other hand it is a bit more complicated to configure, and this is why we started with the version that is currently online. From what I know regarding our othe drivers I suspect that people will have problems with a split configuration in form of a [WHITELIST] and [BLACKLIST], but it seems that there is demand, so we can switch to that format. Personally I like the format, but as I said, there seem to numerous people having issues. Well...

From the programming point of view it should not be a problem because I think we can re-use a lot of code from Bouncer and/or MZWriteScanner I will let you know if we have finished the next step and released a new version of Pumpernickel.​

Now I am looking forward to see the next version of Pumpernickel.

 

@Online_Sword That is absolutely exciting news! Also, I understand now what you mean exactly with how your imaginary example config looks, that makes good sense to me and I agree with you 100%. With your concept, we can get very creative with our configuration and quite a bit more powerful as well. I am glad that Florian is open to technical suggestions like that. He's a great guy to have technical conversations with.

 

Issue above re-surfaced on W8.1.

Submitted infos to Florian.

They cannot replicate so no fix...

 

@hjlbx Since I had seen this issue before in the past, I decided to try to replicate it today to help track down the problem. I tried creating rules, restarting driver, deleting rules, restarting driver, etc. all through Admin Tool. But unfortunately, I was not able to replicate it anymore.

Which version of Admin Tool do you have? Mine shows as 1.6.3

When you replicate this issue, do you do everything through Admin Tool? Including stopping/starting the driver?
Or do you use BouncerTray to start/stop the driver?

Just trying to help narrow this down.