Bouncer (previously Tuersteher Light)

Microsoft has already fixed these.
The Enigma0x3 UAC bypasses are already fixed as of build 15031.
(All credits to hfiref0x / EP_X0FF for tracking and testing all the UAC improvements Microsoft are implementing)

 

On what operating system? On Windows 8.1 (fully patched) it is not. I can execute sample exploit using EVENTVWR.EXE and it still works. I added blacklist rule to my configuration until it is clear under what conditions it wont be possible to misuse EVENTVWR.EXE (I dont need this executable).

 

Good, they have fixed it with the newest build

 

Blacklisting event viewer instead of using a standard user account. Gotta love those security tweakers. Always priceless.

 

"(All credits to hfiref0x / EP_X0FF for tracking and testing all the UAC improvements Microsoft are implementing)"

" Gotta love those security tweakers. Always priceless."

Wow I haven't seen that name in a while.
I just remember him saying he went to work for MS a few years ago.
Like cruelsister says. those old hackers ( famous rootkit writers)get hired really fast by companies. more so if they are young.

 

Of Rootkit Unhooker Fame for 32bit mainly XP systems. Remember that tool of his and MP_ART very well.

They also did a POC named Unreal that was a hidden RK. Interesting that EP_X0FF is still heavily involved in Windows. KOOL

 

Exactly, we all know we should, but reality proofs that in many cases people do (or can)not

 

Ah yeah, it was somewhere arounds 2006 if I remember right. But there was also some controversys around that Rootkit Unhooker if I remember right?!

 

So due for release (to non-Insiders) from April 2017?

 

The only controversy I remember is that it worked! It was the snappiest and most instant eviction tool of pulling out rootkit (other malware) code lodged in the SDDT Table and other areas, at least on XP. Never seen anything perform as fast since. Don't know much about anything like it when x64 and Ring0 with patchguard plus signing of MS drivers made it obsolete.

 

Yes.
Easy mitigation (and a great general mitigation against a 1001 other unpleasant experiences) are to use SUA, as @FleischmannTV mentioned in post #1659
(I should probably say that this is a great solution to users that don't mind using SUA. Users that really don't want to, will of course do something else )

 

ha, ha great!

have you guys seen this:

https://securelist.com/blog/researc...networks/#appendix-i-indicators-of-compromise

sounds interesting. something for Bouncer or Memprotect I guess... Need to read more.

 

Good read. All MS needs to do now is pull a fast one and drop out the conveyor line yet another O/S fresh off the heels of Windows 10.

Maybe backtracking to a Windows 9? Nah, too complicated and the PR would be another firestorm for them.

Or perhaps a Windows 11 in keeping with something like a forward order of progression?

On Topic, Bouncer seems it is just enough to yet could be improved on as new problems surface to cover.

 

ProcessHacker show *.xpi (i know its not executable and just zip) loaded under firefox
no way to block it
i know there is no way in kernal for it but hope somehow manage to restrict it also.

 

I saw something like below in the log file.

LSTCHECK > C:\Windows\System32\wbem\WMIADAP.exe > C:\Windows\System32\loadperf.dll

Can anyone here teach me to write a rule to get rid of it from logging? Thanks.

 

@kakaka If you want this action blocked but with silence from logging, try the following rule:

Code:

[PARENTBLACKLIST]
#    Example parentblacklist block with silence rule
$C:\Windows\System32\wbem\WMIADAP.exe>C:\Windows\System32\loadperf.dll

Similar silent blocking rules can be done with [BLACKLIST], [PARENTBLACKLIST] and [CMDBLACKLIST] sections.

 

Thanks, WildByDesign. Will try that soon. And what actually does "LSTCHECK" mean in this case?

 

You're welcome. Once Florian added more features to Bouncer it became more difficult to determine which type of rule triggered a specific blockage, so I suggested to add within the log which rule section triggered the blockage. So in this case LSTCHECK is referring to the parentcheck feature. If a blockage was triggered by command line rule, it would show CMDCHECK in the log.

 

Thanks again, @WildByDesign. I followed your instruction and worked like a charm.

 

I can see how CMD relates to Command in CMDCHECK, but how does LST relate to Parent in LSTCHECK (ie. what does LST mean)?

 

This is something that one of us would have to specifically ask Florian. I assume that he's abbreviated the wording to a certain extent so that each is down to 3 characters to remain consistent which would also allow malware/security researchers to run custom scripts/regex against log files. But I must admit, I am curious as well to the exact meaning to LST. If someone reaches out to Florian and finds out, please do let us know.

 

LST == LIST
LSTCHECK == ParentListCheck

 

The website of Excubits is using Cloudflare, but they were not affected from the "Cloudflare-bug"

 

I've been paying attention more lately to some of these fileless attacks which often use Microsoft signed built-in binaries to bypass application whitelisting and therefore also playing around with command line scanner functionality which helps to mitigate these attacks.

For testing, I have been using Casey Smith (@subTee) "AllTheThings" application whitelisting bypass tool: https://github.com/subTee/AllTheThings


For Bouncer's [CMDCHECK] scanning:

Code:

[CMDBLACKLIST]
#    [AllTheThings]
*>*C:\Windows\Microsoft.NET\Framework*\*\InstallUtil.exe*/U*.dll*
*>*C:\Windows\Microsoft.NET\Framework*\*\regsvcs.exe*.dll*
*>*C:\Windows\Microsoft.NET\Framework*\*\regasm.exe*/U*.dll*
*>*regsvr32*/s*.dll*
*>*rundll32*.dll,EntryPoint*

For those using Florian's other driver cmdScanner (aka CommandlineScanner), that code above would simply go into the [BLACKLIST] section. I have tested those command line blacklist rules quite thoroughly by disabling the rest of Bouncer's protection mechanisms so that nothing else interfered and I ensured that blockages in the log file showed up triggered by [CMDCHECK] specifically.


So those rules above are thoroughly tested. The rules below, however, are not quite as thoroughly tested. The rules below are based on application bypass techniques listed at (https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET).

Code:

[CMDBLACKLIST]
#    [Event Viewer]
*eventvwr.exe*>*
*>*eventvwr.exe*
#    [PowerShell]
*System.Management.Automation.dll*>*
*>*System.Management.Automation.dll*
#    [Blocking the regsvr32 application whitelisting bypass technique]
*cmd.exe*>*regsvr32*scrobj.dll*
*cmd.exe*>*regsvr32*scrrun.dll*
#    [Blocking one rundll32 application whitelisting bypass technique]
*rundll32*>*mshtml.dll*
#    [Blocking rundll32 from loading PowerShell]
*rundll32*>*System.Management.Automation.dll*
#    [Blocking malicious OLE packages in Microsoft Office products]
*\OFFICE1*\*>*flash*.ocx*
*\OFFICE1*\*>*packager.dll*

At the moment, what I am doing is allowing all command line functionality with *>* in the [CMDWHITELIST] section and targeting specific command lines in the [CMDBLACKLIST] section. Somewhat of a Default Allow setup, I suppose. But for the most part I am exploring and trying to learn more regarding command line scanning for my own testing purposes and thought that I would share my results so far.