Bouncer (previously Tuersteher Light)

Discussion in 'other anti-malware software' started by MrBrian, Jan 25, 2014.

  1. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,792
    Location:
    .
    Thank you once again @WildByDesign, amazing explanation indeed. Got to go now but reading your post as soon as I get back.
     
  2. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I don't have SOB installed right now since I just rolled back my machine. If I remember correctly the most notable difference to me is that SOB has a user-mode processes running which delivers the policy to it's kernel mode driver. My question would be if that user-mode process gets terminated will SOB continue to enforce it's policy. I think the user-mode application has to be running for the KMD to enforce it's policy, but I could be wrong. I have not had a chance to use SOB much yet. SOB is in early testing phase right now so that could change. I will have to ask Andreas if the policy continues to be enforced once the user-mode application is terminated, but I don't think it does for now.

    Edited 8/20 @2:34: Bouncer does not have anything running in user-mode other than a very simple policy editing tool. If that tool is terminated then Bouncer's KMD continues to enforce it's policy. It's not dependent on the policy editor at all. The user can manually edit the policy with notepad if they like. Sometimes it's faster using notepad.
     
    Last edited: Aug 20, 2015
  3. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    After extensive testing with Process Explorer (even as Admin), I can conclude that Process Explorer is not able to manipulate processes that are protected with MemProtect at all. Not only that, but Process Explorer cannot even terminate/kill these protected processes nor access process/thread permissions nor change permissions. Color me impressed at the moment.

    @Cutting_Edgetech DLL injections from those three tools were blocked as well. Although that is an area that I am still learning.
     
  4. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    Another good test would be if it returns that same result with PC Hunter and Process Hacker. It might prove interesting to see just how deep low level MemProtect will be effective with those too.

    Regards EASTER
     
  5. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    @EASTER I just tried PC Hunter (1.33) right now, but unfortunately it does not seem to run on my Windows 10 systems at all. I did try Process Hacker last night briefly. Process Hacker was able to manipulate/control these protected processes, however, I wasn't very confident with my configuration for that. It's possible that I whitelisted part of the system that Process Hacker utilized and therefore might not have set it up correctly. I will give that one another try later today.
     
  6. 4Shizzle

    4Shizzle Registered Member

    Joined:
    May 27, 2015
    Posts:
    179
    Location:
    Europe
    @Cutting_Edgetech is correct: Bouncer does not have something running in user-mode. You can install and use driver without programs. just set up .ini file with notepad and install driver using .inf file and command line. Admin Tool and Tray Tool are devinitely not needed, they are additional. Driver fully works in kernel-mode and before any service or most others drivers are running on system.

    The developer told me that most other solutions obligatory need service or normal program to run properly and to enforce it's policy. He also said that nobody seriously want to implement regular expression system in kernel-mode, nor full support of digital signatures check for executables completely in kernel (he said somthing about .x509 etc, do not understand what it means). So I assume that all that feature are implemented in user-mode part of the competitiors. So, the key difference between Bouncer and other solutions is that Bouncer is truly kernel-mode, the competitors are !NOT!

    @WildByDesign said: at the end it is not easy to assess/evaluate what is better. I am not a expert in this field, so I can't say if kernel-only or hybrid (kernel and user-mode) is better, I think both are good at their level/target.

    I also confirm that MemProtect can protect processes from Process Explorer. I tried crypto lockers and banking trojans known to inject their code in explorer.exe. Did not works with MemProtect enabled :) they failed to allocate or open memory in exploer.exe to write code. But with Bouncer (or other anti-exe), the init malware will not be executed, so MemProtect is additional layer of security.

    Additional: so there is more you can do with MemProtect. restrict rules can also prohibit process start other process. I was able to prohibit chrome.exe to start cmd.exe and other processes (and dll of plugins). looks like MemProtect can also be used as some kind of anti-exe, but I think this is not intesion of driver (just creative re-use).

    @EASTER: thanks for hint, I have tested with Process Hacker. Depends on the rules, must be very careful but with correct rules set, Process Hacker was not able to do access other processes.

    I used:

    [BLACKLIST]
    C:\Users\User001\*>*


    and have installed Process Hacker (portable) to my Desktop at:

    C:\Users\User001\Desktop\ProcessHacker\


    Terminating Process/Thread, editing, extracting strings, looking on memory locations was all blocked.

    It was only possible to kill process/thread with kernel module driver additionally loaded but this is in my opinion out of scope, because if someone is able to go into kernel he already owns the system. So nothing to worry I think.
     
    Last edited: Aug 21, 2015
  7. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    @EASTER After some fiddling to configure MemProtect correctly, I was able to keep Process Hacker from manipulating the protected processes that I was testing. It looks like @4Shizzle has already achieved that as well, although my config was slightly different, both seemed to successfully protect the process from manipulation which is fantastic.

    Code:
    [BLACKLIST]
    D:\test2protected\*>D:\test1protected\*
     
  8. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Beta drivers are available now for Bouncer, MemProtect, and MZWriteScanner.

    Latest features in beta testing

    Bouncer: Parent process checking and SHA256 hashing
    MemProtect: Protected Processes feature
    MZWriteScanner: Any new executables written to disk are hashed (SHA256), logged, and blocked if executed based on hash

    For more details and configuration information, see Readme(s) below or also review the information on the beta site.

    Downloads: http://excubits.com/content/en/products_beta.html

    Drivers are digitally signed. Executables are not signed at the moment, but will be signed once out of beta.

    I would strongly recommend running these drivers in [#LETHAL] mode initially and ensure that your configuration is proper and working as intended.

    Beta Readme Files:

    Code:
     ______                _     _ _         ____                                 
    |  ____|              | |   (_) |       |  _ \                                
    | |__  __  _____ _   _| |__  _| |_ ___  | |_) | ___  _   _ _ __   ___ ___ _ __
    |  __| \ \/ / __| | | | '_ \| | __/ __| |  _ < / _ \| | | | '_ \ / __/ _ \ '__|
    | |____ >  < (__| |_| | |_) | | |_\__ \ | |_) | (_) | |_| | | | | (_|  __/ |  
    |______/_/\_\___|\__,_|_.__/|_|\__|___/ |____/ \___/ \__,_|_| |_|\___\___|_|  
    
    LEGAL
    ~~~~~

    Bouncer, a path-based anti-exe kernel driver that assists you in monitoring, tracking and blocking malicious executables on Microsoft Windows.

    Copyright (c) 2015 by Florian Rienhardt. All rights reserved. Distributed and licensed by Excubits UG (haftungsbeschränkt).
    Web: www.excubits.com
    E-Mail: info@excubits.com

    NOTICE
    ~~~~~~

    The driver is for educational and test purposes only. It might contain bugs that lead to system crashes and other damages to your system. Use the driver by and on your own risk. Only try it on a non production environment. We are not responsible nor liable for any damages caused by using the driver. The target audience for MemProtect are Windows enthusiasts (IT forensic guys and hackers). Meaning persons who know what they do. It is not a tool for the ordinary user!

    How to start up
    ~~~~~~~~~~~~~~~

    Bouncer is best described as a path-based anti-exe kernel driver that assists you in monitoring, tracking and blocking malicious executables on Microsoft Windows. Bouncer is some kind of security software supplement, it is designed to prevent infections from executable malware binaries.

    Set up Bouncer with its ini file (bouncer.ini). You shall at least specify:

    [#LETHAL]
    [LOGGING]
    [SHA256]
    [PARENTCHECK]
    [WHITELIST]
    C:\Windows\*
    C:\Program Files\*
    C:\Program Files (x86)\*
    C:\ProgramData\Microsoft\*
    [BLACKLIST]
    [PARENTWHITELIST]
    [PARENTBLACKLIST]
    [EOF]

    At the blacklist you can block specific executables. With hashing enabled you can also specify executables in [WHITELIST] and [BLACKLIST] through their SHA256 value instead of the path and filename. Please note, that the demo-beta has a limit of ~20 for the .ini file, so you can just test the feature but can not hash the entire system.

    The new version of Bouncer will support parent checking, this feature enables you to specify which parent process is allowed to start another executable, this includes all executables like exe, dll, ocx, sys, etc. Specify the parent (by path and exe or with wildcards), followed by the character > (no spaces between!!!) and then specify the child by its path and exe or wildcard.

    You could do something like:

    parent_exe_path>child_exe_path

    where parent_exe_path is the path to the parent's executable and child_exe_path the child's executable. For example you can blacklist Chrome Browser to start any scripting host or the cmd.exe shell like this:

    ...
    [PARENTBLACKLIST]
    *chrome.exe>*cmd.exe
    *chrome.exe>*script.exe
    *chorme.exe>*powershell*
    ...

    What is parent checking good for?
    =================================

    In our internal analysis systems we currently see a lot of malicious document files such as doc, xls, ppt, or pdf. Most of these files contain some kind of malicious macro that initiates the final attack. Some other malicious document files make use of exploits, but at the end the result is the same:

    the malicious file starts the phase 1 (initial) threat's code (or script)
    it downloads malware or extracts malware out of the document (or macro) itself
    it makes the malware persistant and hides its traces in some way:

    * copy it to a %temp% folder or into the registry
    * ensure the threat's code survives a re-boot (auto start)
    * ensure that threat cannot be catched (install rootkit, inject dll, in-memory attack...)
    * it performs some malicious action
    - captures screen, key strokes, manipulate/spy on browser)
    - performs evil actions (send spam, ddos a target)
    - sends captured information to a drop zone
    * optionally: update the threat's binary or receive commands for further actions

    So what happens first, are steps 1 to 3. They ensure that the intended malware finds its way to your machine and gets started. To start the malware the attackers often use API calls to e.g. Run, Exec, LoadLibrary or CreateProcess etc. These calls can easily be avoided with classic Bouncer if they target a blacklisted path (%temp%). But attackers do not just use win32-API functions, we also see malicious document files that start some scripting host first, to download, save, and make the final malware executable persistant. For example they open up a command line shell, start a batch file. Then the batch file calls a vbs/js script to download a file, etc. With bouncer's new parent feature you are able to limit the initial steps of such threats.

    Take MS Word as an example: For most all day, every day work, your winword.exe shall never ever run cmd.exe, bitsadmin.exe or *script.exe, nor powershell.exe. Hence you can set a parent rule saying that winword.exe is not allowed to run these executables. Just enforcing such rules helps a lot to mitigate against a whole bunch of threats that are currently in the wild. The same is true for browsers. Just think about cmd.exe again: Why should any browser start up cmd.exe, powershell.exe, *script.exe, bitsadmin.exe etc.? Thus it makes sense to have parent rules to mitigate against some threat vectors. Well, it will not catch all and everything, but no security solution will - period -.

    Besides parent checking the driver also supports sha256 in its [WHITELIST] and [BLACKLIST] definition parts, so you are able to protect from drives and paths where you do not have any access control. This should help some users to enhance security, but consider that the configuration is a bit messy. From a security perspective it is more secure but as we said in our Excubits statement: You should balance between comfort, usability and security, thus we still believe that path rules are secure, reliable and comfy.

    Be careful with your initial rules and start the driver in [#LETHAL] mode for the very first time. Please note: The maximum size of the ini is ~20KBs.

    To install the driver just go into the binaries path regarding your architecture of Windows. Then right-select the .inf and hit "install".

    You can use one of the cmd-scripts to start, stop, restart and uninstall the driver, or just use the tools (Tray Application and Admin Tool) provided in the package.
    Code:
     __  __                _____           _            _
    |  \/  |              |  __ \         | |          | | 
    | \  / | ___ _ __ ___ | |__) | __ ___ | |_ ___  ___| |_
    | |\/| |/ _ \ '_ ` _ \|  ___/ '__/ _ \| __/ _ \/ __| __|
    | |  | |  __/ | | | | | |   | | | (_) | ||  __/ (__| |_
    |_|  |_|\___|_| |_| |_|_|   |_|  \___/ \__\___|\___|\__|
                                                  
    LEGAL
    ~~~~~

    MemProtect
    A Windows minifilter driver that protects processes from in-memory code injections
    Copyright (c) 2015 by Florian Rienhardt. All rights reserved. Distributed and licensed by Excubits UG (haftungsbeschränkt).
    Web: www.excubits.com
    E-Mail: info@excubits.com

    NOTICE
    ~~~~~~

    The driver is for educational and test purposes only. It might contain bugs that lead to system crashes and other damages to your system. Use the driver by and on your own risk. Only try it on a non production environment. We are not responsible nor liable for any damages caused by using the driver. The target audience for MemProtect are Windows enthusiasts (IT forensic guys and hackers). Meaning persons who know what they do. It is not a tool for the ordinary user!

    How to start up
    ~~~~~~~~~~~~~~~

    MemProtect is memory protection driver that can mitigate against in-memory attacks. The driver ensures that any encaged process is not able to operate on memory locations registered to another process. Hence it is not possible to inject code or an executable/library. It even works if the source application was fully exploited, achieved system level privileges. MemProtect driver tries to protect all running processes, not just the ones you think of to be protected. You can specify critical process locations (like the path to your browser, e-mail client, office suite, or pdf-reader) that are not allowed to open, read, write, and inject code into processes from another path’s location. Thus you protect trustworthy applications from ones that are often subject to attacks implicitly. Again, with the right rules you can protect your legit applications from browsers, media players, office suits, pdf-viewers.

    MemProtect works and configures a bit like parent checking in Bouncer. You vcan enable [LETHAL], [LOGGING]. The [WHITELIST] and [BLACKLIST] contains parent processes that are allowed or not allowed to open other processes. For example a rule shall look like

    access_from>access_to

    where access_from is the path to the executable that wants access to access_to. This values can also contain wildcard characters. Please ensure that the character ">" does not contain any blank symbols. For example you can limit memory opartions of your beloved browser like chorme:

    A real example here:

    [WHITELIST]
    C:\Windows\*>*
    C:\Program Files\*>*
    C:\Program Files (x86)\*>*

    Any process from these paths is allowed to open, read and write into processes from all other paths.

    [BLACKLIST]
    C:\Program Files\Google\*>C:\Windows\*.exe
    C:\Program Files\Google\*> C:\Users\*temp*>*
    C:\Users\*temp*>*

    Google’s Chrome is then not able to open (and inject) code into other processes. It can only open another chrome.exe. Additionally the blacklist rule “C:\Users\*temp*>*” ensures that processes from the user’s folder are not able to inject code into other processes. This rule is important because if an exploit manages to start an exe, this often happens from a %temp% location at the user’s profile. Normally Bouncer can avoid such attacks, but if users just want to use MemProtect without Bouncer or CommandLineScanner, this can provide additional protection here.

    Be careful with your initial rules and start the driver in [#LETHAL] mode for the very first time. Please note: The maximum size of the ini is ~10KBs.

    To install the driver just go into the binaries path regarding your architecture of Windows. Then right-select the .inf and hit "install".

    You can use one of the cmd-scripts to start, stop, restart and uninstall the driver.

    What is MemProtect all about?
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Having analyzed current malware threats and trends we stumbled across many malware samples tending to inject their code into legit processes instead of running the evil code in the attacker's own (executable) context. The reason for this is simple:

    (1) Most malware binaries are still executables (or scripts) located in the user's folder or one of the well known temp directories. So even ordinary users are able to detect such a malicious script/process in the task manager or system service overview. To avoid getting catched by quick forensics it is hence good practice to inject the evil executable into a legitimate process like a hidden notepad.exe, cmd.exe etc.

    (2) If some initial malware gets started through an exploit, the targeted application usually crashes at some point: Not good for the bad guys as they want their code running to spy on you, steal your passwords and credit card number, etc. So again, injecting malicious code/software into another process is the only option to survive, if the attackers do not want to drop and execute malware directly, but then see (1) again.

    So this is why attackers tend to use in-memory attacks nowadays. They inject code into another process or even better, they manage to load a dynamic link library into another process or overwrite a suspended executable with their own executable and resume the process. Additionally, to avoid getting catched by anti-executable tools, attackers often implement some kind of reflective loading technique, avoiding to make use of the Windows' build in executable loader. Detecting such threats is very difficult. At Excubits we thought about this problem for a while and came across some state of the art in-memory attack protection approaches that are well known and already used for self-defense or as application protection tools. The problem is, that they only protect individual processes that must be specified by the user. Such solutions just encapsulate a specific application that shall be protected. Thus every application that is not registered (encapsulated) though, will not be protected.

    We think it shall be turned around: Every running process should be protected from potentially dangerous applications injecting something into their memory locations. Hence, exclude potentially insecure, e.a. often exploited, applications from this list and ensure that they cannot harm all the other processes. We have implemented a kernel driver that is able to encage such potentially dangerous applications. A potentially dangerous application is for example a web-browser, audio/video player, PDF viewer, MS Office etc. Because such applications are often targeted by exploits and (mis-)used as a vehicle to start-up malicious code, it seems to be a good idea to encage them, and to block any attempt from their binary to inject code into another processes' binary.

    What the driver actually does is, to ensure that any encaged process is not able to operate on memory locations registered to another process. Hence it is not possible to inject code or an executable/library. It even works if the source application was fully exploited, achieved admin/system level privileges etc. What we have currently implemented is a PoC, but we look forward to turn it into some kind of convenience product. We think that together with other mitigation techniques like anti-executable, shell and integrity scanners it can help a lot to mitigate against sophisticated attacks.

    If you have any comments or questions feel free and contact us, we are still working on this project and will follow up with new versions. So, if there is anything missing let us know.

    The driver shall work on all major versions of Microsoft Windows (32-bit and 64-bit). It is free for private non-commercial use, but we are also happy if you support us and give a donation. If you would like to license it for use in any commercial environment contact us, thank you.
    Code:
     __  __ ________          __   _ _        _____                              
    |  \/  |___  /\ \        / /  (_) |      / ____|                               
    | \  / |  / /  \ \  /\  / / __ _| |_ ___| (___   ___ __ _ _ __  _ __   ___ _ __
    | |\/| | / /    \ \/  \/ / '__| | __/ _ \\___ \ / __/ _` | '_ \| '_ \ / _ \ '__|
    | |  | |/ /__    \  /\  /| |  | | ||  __/____) | (_| (_| | | | | | | |  __/ |  
    |_|  |_/_____|    \/  \/ |_|  |_|\__\___|_____/ \___\__,_|_| |_|_| |_|\___|_|  
      
    LEGAL
    ~~~~~

    MZWriteScanner
    A minifilter that monitors executables (MZ-files) being written to your disk
    Copyright (c) 2012 - 2015 by Florian Rienhardt. All rights reserved. Distributed by Excubits UG (haftungsbeschränkt).
    Web: www.excubits.com
    E-Mail: info@excubits.com

    NOTICE
    ~~~~~~

    The driver is for educational and test purposes only. It might contain bugs that lead to system crashes and other damages to your system. Use the driver by and on your own risk. Only try it on a non production environment. We are not responsible nor liable for any damages caused by using the driver. The target audience for MZWriteScanner are Windows enthusiasts (IT forensic guys and hackers). Meaning persons who know what they do. It is not a tool for the ordinary user!

    How to start up
    ~~~~~~~~~~~~~~~

    To install the driver just go into the binaries path regarding your architecture of Windows. Then right-select the .inf and hit "install". You can use one of the cmd-scripts to start, stop, restart and uninstall the driver. Please ensure that you have set up a proper MzWriteScanner.ini in your windows system folder (C:\Windows\).

    Monitor and keep track of Windows executable files (MZ files) which are dropped onto the hard disk. MZWriteScanner is a forensic analysis driver that detects when executable files (containing a MZ header) are written to your hard disk. The new version of MZWriteScanner also supports blocking of newly written executables. MZWriteScanner is now able to track new executables by their SHA256 hash. If you enable [SHA256] and [LETHAL], MZWriteScanner will detect and hash any newly written executable. You can set paths and files onto the [WHITELIST] and [BLACKLIST] section. It behaves like in Bouncer, because the engines are the same. Whitelisted files/paths will not be logged whereas blacklisted ones will be loggend and tracked, thus any executable written to such a location will also be hashed and blocked if the user tries to start them. Please note, that MZWriteScanner is still a forensics tool, the list of hashes is limited to ~2MB, to avoid problems in the kernel - it is also just session based, hence the calculated hashes are not remembered after re-starting the driver (or computer). Additionally: If there are more then 2MBs of hashes in the internal list, any new written file will not be put onto the list and such an executable could pass. The driver will not avoid writing any executable file, it just monitors and logs any attempt for further investigation.

    Be careful with your initial rules and start the driver in [#LETHAL] mode for the very first time. Please note: The maximum size of the ini is ~10KBs.


    What is MZWriteScanner all about?
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Looking at (0-day) malware infections of today you will often see that attackers use some kind of executable file (exe, src, ocx, dll, sys, ...) dropped to the victim's machine. The executable is then loaded through the Windows loader, injected into another process or initialized and started by the attacker's own loader code. Nevertheless in most cases there is always some kind of initial executable that is written to the machine. Additionally these executables are in typical MZ/PE-format used by Microsoft Windows.

    Well, this is where we started to think about a forensics tool that can help you in identifying newly written executables right after they hit your (forensics) machine. We ended up in a tiny monitoring minifilter driver that can help you analyzing potential zero-days and other executable malicious stuff on your machine.

    MZWriteScanner is a simple minifilter that intercepts IRP_MJ_* callbacks to track what files should (and will) be written onto your disk. The driver checks if a file contains the well known magic bytes of an executable, namely the string 'MZ' at offset (0). If this is the case, MZWriteScanner outputs the filename to a log file located at %SystemRoot%\mzwritescanner.log.

    We have also created a tiny tool with tray icon integration that notifies you, if a new executable was written to your disk, so you can identify the executable in a timely manner. It is very interesting to see what executables are written to the system - not just to find malicious files.

    MZWriteScanner can also help you to identify downloads faking you, for example, by stating they are image files, video files or PDFs. Thus, if you download a file and hold up for a minute before opening, MZWriteScanner can lightly help you to avoid getting faked.

    We used a modified version of MZWriteScanner in an research project for some time and were very pleased with its results. We used it to catch malicious web sites just by using the driver, no additional forensic tools, special exploit (memory) detection etc. Result: By just identifying written executables we were able to catch the majority of bad web sites spreading malware through automatic (or fake) downloads, exploit kits etc. Hence we believe that MZWriteScanner will definitely help you in daily forensic scenarios and operation - especially if you run crawling and automated analyzing systems.

    Please note: The driver does currently not block any attempt to write an executable, it only identifies such events so your system can still be infected. Consider yourself informed and warned! We will include this feature in future release. If you are interested in the blocking version, contact us.

    Also consider that there are still executables written to your system that are entitled to be written onto your disk. For example the Microsoft System Updating Service shall write executables to update and patch your system, most anti virus engines update their application files etc. Hence, a newly written (or modified) file is not always malware and thus a notification is not an alert. We are currently working on a whitelisting engine for the next version, so you can exclude files and paths that will not cause a notification for entitled executables.

    If you have any comments or questions feel free and contact us, we are still working on this project and will follow up with new versions. So, if there is anything missing let us know.

    The driver shall work on all major versions of Microsoft Windows (32-bit and 64-bit). It is free for private non-commercial use. If you would like to license it for use in any commercial environment contact us, thank you.
     
  9. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    @WildByDesign

    Drivers are digitally signed

    ^ This is a big plus! Thanks for the notice.
     
  10. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    WildbyDesign, thank you for the update! I just finished testing the Memory Protection on my test machine, and found the memory protection to be quite impressive. I just sent my results to Florian. I did not realize the drivers had just been signed. I guess it's better to join the party late than not at all. I spent about 5 hours trying different memory injection techniques with various tools I have, but was unsuccessful. I tried injecting into IE 64bit, and Firefox 32bit. I also tried surfright's exploit test tool, and excubit's memory protection mitigated all of the memory based methods of exploit. I really did not expect the memory protection to mitigate all of surfright's memory payloads. I just need to see if excubits memory protection is compatible with the rest of my layered security, and make sure it does not cause any problems with my applications. If it will work with AppGuard's memory protection then I should be ok. It will take further testing, but I intend to add excubits memory protection to my layered security setup.

    I'm still testing Bouncer. At the moment I am having problems allowing single executables by path. I'm not sure what I am doing wrong. The executable that is currently giving me problems is the one Process Explorer spawns in the Appdata folder. I had no problem allowing it with previous builds of Bouncer. Could someone inform me how to allow C:\Users\achilles\AppData\Local\Temp\procexp64.exe for Process Explorer. I'm trying to allow it by path, but that is not working. I just started playing around with this new build of Bouncer, and it may take some getting use to. I don't know how to whitelist it by hash either at the moment.
     
  11. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    @Cutting_Edgetech For Process Explorer, here is what I use:
    Code:
    [WHITELIST]
    C:\Users\*\AppData\Local\Temp\procexp64.exe
    Or you could do:
    Code:
    [WHITELIST]
    *procexp64.exe
    If that spawned process within user directory is still being blocked by Bouncer in particular, have a look and see if your blacklist contains something that might be blocking Users directories since blacklist takes priority.

    Regarding MemProtect. I have been equally as impressed. I also played around more today and was able to make some configs which made MemProtect do most of what Bouncer does, meaning you could just use MemProtect and be just as safe without Bouncer.
     
  12. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I just discovered that some of my test results using Surfright's exploit test tool were false. I discovered that I had several instances of calc.exe running in task manager. Excubits memory protection was only blocking calculator's UI from displaying on the screen, and allowing calc.exe to spawn for some of the test. Sorry for the false results earlier. I will have to redo the test to see which test excubits is failing, but it appears to be failing many of them. I sent Florian an email informing him of the false results, and asked if he could figure out a way to mitigate the memory payloads in the kernel.
     
  13. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Thank you! I will try both methods, and see if they work for me.
     
  14. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I think this is the method I was trying by path. It did not work for me. What do you mean by, "[/CODE]" after procexp64.exe? What does "[/CODE]" mean? Do I need to put anything after procexp64.exe since I only need to allow that single process?

    Edited 8/30 @10:18
     
    Last edited: Aug 30, 2015
  15. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    The [/CODE] must have somehow copy/pasted from forum, that is just related to Wilders BB Code, not Bouncer related. Nothing needs to go after procexp64.exe since it is single executable. You can feel free, anytime you need, PM me with your config with brief description of whatever you are trying to achieve at the time and I am always happy to look or correct something if need be. But for now I've got to get some sleep. I will catch up tomorrow.
     
  16. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Hmm.. that's what I already tried doing, and it did not work. I will try again tomorrow. I'm worn out also, and need to rest as well. Thank you for your help!
     
  17. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    We can now add SHA256 hashes through Admin Tool interface to Allow or Deny execution. You can select an executable through the tool and Admin Tool will hash it for you and add the hash to your config. For those who downloaded the beta version of Bouncer yesterday, you will need to download updated Bouncer beta package again which contains updated Admin Tool. http://excubits.com/content/en/products_beta.html
     
  18. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Thanks for the update WildByDesign! I will have to switch over to my test machine in a little while, and try her out. I need to try some rules with the parent check feature also.
     
  19. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Florian got back with me about Surfright's exploit test tool. He said the calc.exe processes that were showing up in task manger were actually zombie process. They were empty processes that attempted to start, and that's whey the Calculator UI was not successful in launching. He said he will do further testing within the next 8-10 days. Hes quite busy right now.
     
  20. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    Convenience and simplicity for rock solid prevention. Just can't go wrong with this combo. Thanks for the updated Admin Tool news n linkie.

    It's so overwhelming right now but once things settle down enough to dive into creating all these rules, the control will be so very strong. Thanks

    Regards EASTER
     
  21. ParaXY

    ParaXY Registered Member

    Joined:
    Sep 2, 2015
    Posts:
    70
    Hi All

    This is my first post :)

    I discovered Bouncer/MZWriteScanner by accident on the weekend and am so glad I did. What an amazing piece of software.

    I have some questions I hope someone can answer:

    1. When will the new versions on Bouncer.MZWriteScanner/MemProtect with hashing be released?
    2. Lets assume I run bouncer with the default rules and am running it in LETHAL mode. What is the best approach to use when it comes to installing new software or updating existing software? I have thought of two options: a) Disable Bouncer for duration of install/upgrade (not ideal I thinks) OR b) Whitelist a specific folder in Bouncer that I could use for software installs/updates.
    Thanks for any help and thanks for a great forum!
     
  22. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    First are foremost, welcome to Wilders! :thumb:

    You can use the public beta versions: http://excubits.com/content/en/products_beta.html

    Of those beta versions, Bouncer contains the SHA256 hashing and parent process checking features. MZWriteScanner contains the SHA256 hashing of any newly written executable and will block from execution based on hash. There is also MemProtect which utilizes Microsoft's Protected Processes, allowing the user to configure any processes they wish as protected processes.

    I would not worry too much about the beta status. The developer is just holding off because he wont release something as stable unless he has completed documentation. In this case, he just wont have time to complete documentation for a few weeks.

    Personally, for Windows Updates, I disable Bouncer just to be on the safe side. I would also disable MemProtect and MZWriteScanner to be on the safe side. For individual program updates, I create rules to allow updating of Google Chrome, Firefox, Thunderbird, etc. So I do not need to disable Bouncer for individual program updates. I am sure that we could likely create/share rules to allow Windows Updates as well, but for the time being I just disable it to be on the safe side.

    We can always feel free to share rules here in this thread (contained with code tags). And if you have any questions in general or questions about specific rules, feel free to ask.
     
  23. ParaXY

    ParaXY Registered Member

    Joined:
    Sep 2, 2015
    Posts:
    70
    Thanks for the reply!

    I tried the beta in a VM but didn't have much luck with it (the stable version worked fine) so I thought I would wait until the final/stable version is released with the hashing. I don't mind waiting as I am learning loads about this amazing tool still.

    So it sounds like there are two scenarios here: Installing new software (fresh install) and upgrading (existing) software.

    Lets use an example:

    1) Lets say I want to install Firefox and the install file I have downloaded is in D:\Installs. What do I do now (assuming I DON'T want to disable Bouncer)? Do I temporarily whitelist D:\Installs and then after the install is complete do I remove this whitelist rule? Is it ok (safe) to leave the whitelist rule for D:\Installs to be used for future installs?

    2) Now lets say I already have Firefox installed and have the default rules enabled for Bouncer and theres an update/upgrade for Firefox. Will the upgrade just work because Firefox is already installed in a whitelisted folder (Program Files)?

    Also, I assumed Windows Updates would just work since C:\Windows is whitelisted?

    I guess I am trying to understand how people use Bouncer on a day to day basis and how updates/upgrades are managed.

    I was always wondering about how safe the whitelisted locations are. In other words, can malware/virus/etc be installed/run/copied to these whitelisted locations and run? I ask this as a someone who logs in with a standard NON-admin account.

    Thanks so much. I look forward to learning more about this amazing tools.
     
  24. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    @ParaXY One of the best ways to determine which directories to create rules for during upgrades/installs would be to run Bouncer with logging enabled and lethal (blocking) mode disabled. That way your installations/upgrades go through safely and also create a nice log file which shows some of the temporary directories used. And with that, you can create rules with direct paths or also with wild cards.

    You can use Admin Tool to enabled logging and disable Lethal mode, or even use Notepad or Notepad++ but you would have to run those as Admin since the Windows directory is protected. The config would look like this:
    Code:
    [#LETHAL]
    [LOGGING]
    Number sign # in front means disabled, no number sign means enabled. The driver needs to be restarted after rule changes are made, either with Admin Tool or manually.

    You can control the Bouncer driver from an elevated command prompt:
    Code:
    net stop bouncer
    net start bouncer
    sc query bouncer
    1) You can whitelist a safe install directory like D:\Install, or in my case I use D:\Tools. That is relatively safe. But I would not, for example, give permission to something like C:\Users\*\Downloads\ or something within User directories like that which would be a more common entry point for malware.

    So you could have something like this:
    Code:
    [WHITELIST]
    C:\Windows\*
    C:\Program Files\*
    C:\Program Files (x86)\*
    D:\Install\*
    D:\Tools\*
    2) Part of the problem here with updates//upgrades for Firefox, Chrome, etc. is that they also utilize Temp folder locations for some parts of their setup. So your install location has permission, good, and your Program Files and so on, good. But you will still need certain areas within Temp folders. But I would not open up the entire Temp directories to execution.

    Some examples below. Some of these are Mozilla Firefox/Thunderbird related, some are Chrome related.
    Code:
    [WHITELIST]
    C:\Users\*\AppData\Local\Mozilla\updates\*
    C:\Users\*\AppData\Local\Temp\???????.tmp\*
    C:\Users\*\AppData\Local\Thunderbird\updates\*
    C:\Users\*\AppData\Local\Temp\MozUpdater\bgupdate\*
    C:\Users\*\AppData\Local\Temp\??_?????.tmp\setup.exe
    C:\Windows\Temp\??_?????.tmp\setup.exe
    C:\Windows\Temp\???????.tmp\*
    So from those examples, as you can see, I was specific as possible and careful with wild cards as I could be without opening up large holes in the Temp areas. Some portable apps also make use of Temp folders as well, and in those cases rules can be created to allow that as well. The detailed logging provided by Bouncer will be your best friend when it comes to knowing which rules to create.

    Windows Uppdates should work, yes. Although there are sometimes odd folders/directories used temporarily. Sometimes they follow a pattern in which we could create rules for, and sometimes they are out of the ordinary. But this is something that I would like to look into more myself. But again, this is something best to run the driver in logging enabled, lethal disabled mode and then use the log file created and that will do wonders. And we can share those types of rulesets here. I have always had a habit of disabling any type of anti-exec program for Windows Updates. But we should be able to figure out some rules to prevent that.

    "I was always wondering about how safe the whitelisted locations are. In other words, can malware/virus/etc be installed/run/copied to these whitelisted locations and run? I ask this as a someone who logs in with a standard NON-admin account."
    Yes, in theory that is possible. Although technically, it would have to execute in the first place. So not very likely. That would be something more likely to occur with a specific exploit. In that case, it's always good to combine an anti-exec like Bouncer (or others) with an anti-exploit tool like EMET or MBAE Free.

    I will have to answer anything that I missed later tonight.
     
  25. ParaXY

    ParaXY Registered Member

    Joined:
    Sep 2, 2015
    Posts:
    70
    Call me ultra paranoid but this is what worries me. If I have to have a whole bunch of whitelisted temp folder locations, doesn't this put my machine at risk? ie: attacker creates some malware and assumes you run Firefox with Bouncer so targets some temp folder locations that may be whitelisted

    What I was thinking was to have a download folder that ISN'T whitelisted. Lets say D:\Downloads for arguments sake. Then, if I want to install (say) Firefox that I have just downloaded into D:\Downloads I would then COPY the install file from D:\Downloads TO D:\SafeInstalls. So I would whitelist D:\SafeInstalls. That way if I download anything malicous into D:\Downloads I would be proteceted but if I trust the file after downloading it I could copy it to D:\SafeInstalls and install from there. How does this sounds?

    This brings me back to my earlier point: Allowing these temp folder locations. Even if you whitelist the specific folders as you have mentioned above, doesn't that still leave your system vulnerable? Which got me thinking about this. What if there was an option in the Bouncer admin tool to TEMPORARILY enable temp folder locations (for example) for the duration of the install of the program you are installing? (rather than disabling Bouncer altogether for installs)

    This is what I worry about. I know I am being hyper paranoid here but I think we have to be considering what we are up against and the risk we face online nowadays. These hackers are smart and will look for ANY opportunity to exploit a system.

    When I run the newly released version of Bouncer, it will be with Malwarebytes Anti-malware, Malware bytes Anti-Exploit and Sandboxie as well as Avira AV. I run as a non-admin (standard) user account and always keep my system fully patched.

    Which brings me to another question:

    I use Sandboxie for ALL my internet browsing. Would it be wise to whitelist the entire C:\Sandboxie directory?

    I've also thought of another scenario: I have a collection of software I keep on my data drive. Lets say its in D:\SoftwareLibrary. In this folder is dozens and dozens of folders of software that I use on a regular basis. The easy (but risky) thing to do would be to whitelist D:\SoftwareLibrary but this puts the system at risk. So without disabling Bouncer is there a preferable way to install software from this folder? This is why I *think* (I should emphasise the think but as I could be 100% wrong) Bouncer should have a temporary install mode or something similar that would enable someone to install (and update) their software. Good idea? Bad? Just thinking out loud here!

    Thanks for all the input. I ask these difficult questions not to be akward but to try and create a truly hardened secure system that is safe to use in everything online!
     
    Last edited: Sep 2, 2015
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.