Bouncer (previously Tuersteher Light)

I'm trying to test MemProtect, but can't get it to work. Since there is no installer, I'm not sure where the files are supposed to go. Please help me figure this out....

 

Please mention that the next time. That's gonna be a nice protection, if it can be done.
Then we have read + write-protection.

 

The memprotect_beta.exe that is downloaded from the Beta Camp page is not an installer like the stable Bouncer release has. It's simply a self-extracting executable. So you can either run it and allow it to self extract or alternatively use something like 7-Zip to right-click and extract. Once extracted:

• The MemProtect.ini config file needs to be copied to the C:\Windows directory prior to installing the driver. However, with this particular release I believe the base config provided comes as [LETHAL] at the top of the config file, meaning that blocking would potentially occur. Prior to copying to Windows directory and prior to installing driver, I would highly recommend to switch [LETHAL] to [#LETHAL] which is more appropriate and safer for initial testing purposes. So use Notepad or Notepad++ to open MemProtect.ini and switch [LETHAL] to [#LETHAL], save it, then you can copy it over to C:\Windows directory. (I will have to mention to Florian to have lethal disabled initially as he typically does with the other drivers)
• Go to either the x64 or x86 depending on your system architecture. Right-click on the MemProtect setup file, choose Install.
• You can either use the cmd batch files (right-click, run as Admin) provided to start, stop, restart the driver, etc.
• Or alternatively, you can open an elevated command prompt and control memprotect with net stop memprotect, net start memprotect, sc query memprotect

With any of Florian's drivers, I always highly recommend to run in non-lethal mode [#LETHAL] first so that no blocking is actually performed, but utilize the [LOGGING] feature which will write to C:\Windows\MemProtect.log as entries are logged (which would normally be blocked if it were in lethal mode). That way you can create your own custom rules as you go, based on what is logged on your system and based on your own preferences. I would suggest to run in that way for a few hours at least, perform a reboot, etc. to simulate your typical use case experience and adjust your rules accordingly. Once you are comfortable with nothing critical being logged anymore, you can at that point change MemProtect into lethal mode by removing the # symbol. If you have any questions along the way, please feel free to ask. You can always feel free to share your rule sets (if you wish) or your logged entries to help diagnose any issues.

 

So uninstalling is as simple as stopping the driver and deleting the driver as well as the ini.

 

@FleischmannTV That's correct. sc delete memprotect (or whatever the driver name may be) will unregister the driver within Windows correctly, then simply delete .ini and .log files. The unregistered .sys file(s) stay dormant in System32\Drivers and can also be deleted for clean removal purposes, though they would not be running once unregistered.

 

@WildByDesign, Thanks for the help. I've got it working now. I wasn't clicking on the memprotect.inf file to install the driver. Here's my config file, based off the one Kees posted in #981.

Code:

[LETHAL]
[#LOGGING]
[WHITELIST]
!C:\Windows\explorer.exe>*chrome.exe
!C:\Windows\System32\audiodg.exe>*chrome.exe
!C:\Windows\System32\csrss.exe>*chrome.exe
!C:\Windows\System32\lsass.exe>*chrome.exe
!C:\Windows\System32\svchost.exe>*chrome.exe
!C:\Program Files\ProcessExplorer\procexp.exe>*chrome.exe
!C:\Users\Kris\AppData\Local\Temp\procexp64.exe>*chrome.exe
!C:\Program Files (x86)\Google\Chrome\Application\chrome.exe>*chrome.exe
!C:\Program Files (x86)\Google\Chrome\Application\chrome.exe>C:\Windows\splwow64.exe
!C:\Program Files\Windows Defender\MsMpEng.exe>*chrome.exe
!C:\Program Files (x86)\Zemana AntiMalware\ZAM.exe>*chrome.exe
!C:\Program Files (x86)\Adguard\AdguardSvc.exe>*chrome.exe
!C:\Program Files (x86)\Blue Ridge Networks\AppGuard\AppGuardAgent.exe>*chrome.exe
!C:\Program Files\VoodooShield\VoodooShieldService.exe>*chrome.exe
!C:\Program Files\Ruiware\WinAntiRansom\WARgk.exe>*chrome.exe
*>*
[BLACKLIST]
*chrome.exe>*
*>*chrome.exe
[EOF]

Everything seems to be working ok so far...

 

@Windows_Security and others,

Florian's follow up regarding MemProtect (and possibly other drivers) - Environment Variables:

Florian's follow up regarding MemProtect - Default-Deny vs. Default-Allow:

My questions:

- With MemProtect, what was your reasons and design goals to go with
Default-Deny?

- At this stage of MemProtect's development, hypothetically speaking let's
assume for a moment that you would consider changing MemProtect from
Default-Deny to a Default-Allow config/setup, would this be possible for
your to achieve in MemProtect development?

- Or let's assume for a moment that you can see benefits to Default-Deny
and also with Default-Allow, would it be possible to make MemProtect so
that the user, within their config, can choose between Default-Deny and
Default-Allow, and have their rules based on either scenario?

I will tidy this post up a bit later, just in a hurry at the moment.

 

If the focus is on vulnerable apps, Default-Allow is a better choice. Only rules for these apps has to be written, and nothing else is blocked.
But we'll see what else is changed in the next version.

 

That may be really good news for me. I want know until I test, but maybe that will fix the problem I have with Windows freezing to an unrecoverable state. It would be awesome if I could finally add MemProtect to my layered security setup.

 

Has anyone tried writing a rule for Windows temp folder so that Bouncer covers that folder? I think maybe it would be safe if only .exe's, and .dll's were blocked in Window temp folder. I wish .tmp could be blocked also, but AFAIK all files used by applications in Windows temp folder are .tmp so they can't be blocked. Maybe Windows spawns some .exe's in Windows temp folder when updating Windows, but it would not matter since I always disable Bouncer when updating Windows.

 

I will share an example that I am currently using regarding Windows Temp directory. I will cut out all else just to focus more on Windows Temp in this example. The priority rules are very beneficial in dealing with this folder.

Code:

[WHITELIST]
!C:\Windows\Temp\{????????-????-????-????-????????????}\.ba1\mbahost.dll
!C:\Windows\Temp\??_?????.tmp\setup.exe
!C:\Windows\Temp\???????.tmp\*.dll
!C:\Windows\Temp\????????-????-????-????-????????????\DismHost.exe
!C:\Windows\Temp\????????-????-????-????-????????????\*.dll
!C:\Windows\Temp\DPTF\*
!C:\Windows\Temp\MP*.DLL
C:\Windows\*
[BLACKLIST]
C:\Windows\Temp\*

In this example, everything is blocked from executing in Windows/Temp, with the exception of priority rules within the whitelist. Some of my priority rules are for Adguard, Firefox, Chrome, DISM, Intel's Dynamic Platform and Thermal Framework (DPTF) drivers, and Microsoft's Malicious Software Removal Tool. Those all contain a variety of executables and DLLs that show up in Windows/Temp during program updates or other scheduled servicing.

So you are referring to individual files within Windows/Temp which has .tmp as their file extension? I am not familiar with that on my systems. I suppose it may depend on which program is creating and utilizing these .tmp files or possibly a Windows feature, not sure. However, Bouncer does not necessarily filter based on file extension. What I mean is, these files with a .tmp extension could very well be legit PE files with MZ header, in which case Bouncer will filter and therefore you would have control with your rules to block or allow. Although if these .tmp files are not PE/MZ executables, Bouncer cannot filter in that case. Before you consider blocking these .tmp files, I think that it would be important to determine which program is creating and using these files to understand what consequences could happen if you were to block them. Let me know if you find out more and I can help create some example rules. Also, if you wanted to prevent those .tmp files from being written to disk in the first place, Pumpernickel driver can do that. But I am still curious to know more about these .tmp files since I am unfamiliar with their purpose and use at the moment.

For certain things like Windows Updates, the upcoming Install Mode in Bouncer will be beneficial because Install Mode can persist across reboots and also temporarily disables logging. Quite handy.

 

On my system I looked through all C:\Windows\Temp\*.tmp-files, but these files were no executable files.
It looks like these files are just normal temporary files. Theoretically blocking these files couldn't do any harm.

But i don't know what kind of temporary files you have on your system.

 

@WildByDesign

Great news. Memprotect is a mitigation option. Let's assume people keep UAC enabled, then Lower Integrity Levels, can't infect/exploit higher Integrity Levels. This means we only have to worry about processes running medium IL: your Browser broker, Media Files (including Flash) Player, Email, PDF-reader and Office apps.

Florian could supply basic templates (for Mail, Office, WMP, etc) to be tested and developed by the Wilders Community. We could develop a community based set (like we used to share firewall rules in the old days) for vulnabrable processes (applications hosting an execution environment like javascript, pythonscript, visualbasic-script/et cetera). Mitigating these programs with a kernel based mechanism, would practically end zero day and exploit bases threats.

Regards Kees

 

One little question: To lower the Integrity Level, is it better to use ICACLS.exe or can 3rd-party tools be used for this? For example MicEnum which can set Programs/Directories to different Integrity Levels with a simple mouseclick.
I'm only unsure. Microsoft or 3rd-party-tool ...

 

@mood,

Thx I used icacls, but for handling folders MicEnum is great

 

Ok. I think i'll wait for the next MemProtect-Release, after that i can begin a little hardening-session.

 

I was not wanting to block those .TMP files. Those files are being used by applications, but I don't know exactly which applications are using these files. What I was trying to say is that I think I could safely block by file extension except for .TMP files which are always in my Windows Temp Folder. These files are being used by applications I have installed, or by some Windows processes. I listed them as .tmp in my initial post thinking they were the same file type, but I guess they are not. I don't think these .TMP files are executable, but I could be wrong. I will look into them more in a moment. If .tmp files are not the same as .TMP then it may be possible to safely block .tmp. I definitely would not want to block .TMP files even if I could. Below is an image of what my Windows temp folder always looks like.

 

I listed them as .tmp files in my initial post, but I meant to say .TMP. At first look I thought they were the same file type. Applications are using information stored in these files from what I read. I will have to look more into .TMP files now that I know they are not the same as .tmp. I should have payed closer attention to detail.

 

@Windows_Security @WildByDesign

Links to Windows security mechanism infos utilized by MemProtect ?

I know @WildByDesign posted a link to the Vista integration, but are there any others available ?

I really would like to read-up on it further...

 

@hjlbx I will try to dig up some of the more technical docs I've read previously on protected processes. I will update this post as I find more.

Link: https://www.nsa.gov/ia/_files/app/Reducing_the_Effectiveness_of_Pass-the-Hash.pdf

 

@WildByDesign - Pass-the-Hash protection concepts are part of MemProtect implementation ?

LOL... Look what NSA did... they ripped-off F-Secure logo... LOL.

 

I really don't know, to be quite honest. I've seen and played with the power of MemProtect to see what it is capable of. But as far as the underlying functionality, a lot of this memory protection (and in-memory attack) stuff is beyond my knowledge at the moment as I've never really had much interest in that area. Although with modern day attacks, it has got my curiosity now.

Here is another good series on Protected Processes:

http://www.alex-ionescu.com/?p=97
http://www.alex-ionescu.com/?p=116
http://www.alex-ionescu.com/?p=146

EDIT:

One more good read here: http://debugandconquer.blogspot.ca/2014/11/taking-memory-dump-of-protected-process.html

 

@Cutting_Edgetech @Windows_Security

I've got a question regarding testing MemProtect's protected processes against HMPA's Exploit Test Tool. I understand that both of you, at one point or another, did a similar test in which MemProtect did it's job to protect again those exploit tests. I was curious and also decided to do similar tests and also with good results from MemProtect.

But what I was wondering is, what makes more sense for the testing. Using MemProtect to make hmpalert-test.exe a protected process? Or make calc.exe a protected process?

I actually ended up trying both methods and both had great results. But I just didn't know which was more appropriate. Regardless, it was rather interesting to gather up the detailed logs created by the memory protection and to see what was occurring during that time.

 

What this test does is to simulate a "remote code execution" exploit. So it will basically modify memory of the attacked process with the end goal to run calc.exe. May I ask, what happens when you make hmpalert-test.exe a protected process? Does it fail to load calc.exe? I don't believe you should protect calc.exe, since this is the "malicious" payload. BTW, EXE Radar will also stop all of these execution tests, and Bouncer should also block it.

 

I isolated chrome and selected Chrome as program to be exploited. BTtW when would Florian be able to recompile MemProtect to be default allow.