Classical HIPS and policy based HIPS discussion

Actually, what you see as a weakness, as "the (theoretical) Achilles" heel of Sandboxie is what makes Sandboxie great. Being able to run comfortably all programs that we (Sandboxie users) run in a daily basis under Sandboxie and still be very secure is what is all about, Kees.

What good is it to install a program that is so tight that you cant really use it, to me, none. The Sandboxie developers could easily make SBIE even more restricted that it is, but no, what they done is implement the perfect balance between security and convenience. It takes hard work to develop that and is not easy to achieve, and they done it while other, like the guy from ReHips, can not (read the complains about ReHips in its thread).

Bo

 

Here's an interesting find: http://www.gironsec.com/blog/2015/12/joecrypter-finally-released . Developed by someone that shares my like opinion that security vendors protection claims are marketing propaganda until proven otherwise.

Note: I have not tried this one yet, so proceed with caution.

Tool can employ up to 10 AV/Sandbox evasion techniques:

The crypter I made modifies exes, packs them, and adds AV / VM / Sandbox / debugging evasions inside of a wrapper. I’m employing a basic process hollowing technique for the payload that is only run after all evasions are satisfied. The anti-debug modules include anti-single stepping as well as anti-tracing. I can even detect procmon without checking the process list.
​

Appears this crypter is an upgrade from his earlier developed AV test tool:

AV testing tool

People often wonder “Joe, how the heck do you know if an AV is worth its weight in sand?” and to them I answer “I have to test it first”.

morph1

This is one of my tools I coded up. Presently I have to do AV evasions with a debugger, modifying the entry point and looking for a ‘code cave’ to place the fine tuned opcodes. It’s not exactly automated – YET. The other settings though work just fine. The concept is this – take a known sample, mess with it, then send it back to the AV to see if its found out.
​

A good use of this crypter tool would be to apply it to the Reflective Dll test tool inject.x64.exe I previous gave detailed use instructions on. Run the "crypted" inject.x64.exe version in the sandbox against a process outside of Sandboxie's sandbox.

​

 

Bo, I explicitly mentioned both sides. SBIE-fanboys and SBIE-critics. No reason to hijack this thread and make it a SBIE-fanboy thread

 

It's actually you who needs to proof that a process with integrity level untrusted can alter the memory of a process with a higher integrity level, since you are the one who is arguing bypass.

No, it doesn't have to detect anything because these things should be blocked by default by Windows itself due to integrity level difference.

 

Kees, for the last two days all the talk in this tread has been about sandboxing. I replied to this particular post below, thats how Sandboxie came in this thread.

And two, you mentioned my name in your post from early morning today. Why did you do that if you don't want a response from me. And I responded because your post is clearly written by someone who doesn't use SBIE or understand that the point of using Sandboxie is to be able to run most programs that you run in a daily basis under its supervision, do it comfortably, with no inconvenience, and all done very secure.

I am sorry you and the developer of ReHips don't like the way Sandboxie is designed, but I do. The way Sandboxie is designed is what allows me to use Sandboxie at all times when I am using the computer. And all done naturally. Since you are not a Sandboxie user, I don't expect you to understand what I am saying. And Kees, from now on, if you really really don't want a response from me, remember, don't write my name in your post when there is absolutely no reason for you do it, like here. Happy, Sunday.

Bo

 

Agree, I should have said it more explicitly: Bo please don't turn this in a sandboxie fanboy thread, I edit-ed the post.

The design of SBIE is not something I do like or not, it is how SBIE works, it lowers integrity level and (file) access rights so that regular windows mechanism do the blocking, next it allows things to make SBIE a general purpose sandbox. For SBIE-fans I said that to debate/deny this (what you are doing right now) is as irrelevant as denying that the earth is round. For SBIE-critics I said that the increased attack surface discussion is also irrelevant, since running a process with medium level integrity with LOW IL/Anonymous is huge reduction of the attack surface (so don't complain about the fact the Sandboxie adds code to allows things).

 

Kees, you are the one who is turning this into a Sandboxie thread. After all, you wrote that below (To recap Sandboxies mechanism). Is funny how you think is OK for you to give your opinion on Sandboxie and at the same time, you try to intimidate me from doing the same.



If you write something on SBIE, and I dont agree with it, you ll hear from me. I know you ll be back, see you next week . Signed....yours truly, your SBIE Cop.

Bo

 

@bo elam the problem is, that when Sandboxie is mentioned (and sometimes even if not mentioned , like i did when i talk of SD) , you instantly jump in the topic promoting Sbie's invincibility, and if you believe something said was negative to Sbie, you start to prove that the member did something wrong or didn't understand Sbie. Same kind of behavior you can see on Comodo forums, the "you don't understand how it works and how to use it" attitude.

latest example was with @hjlbx 's posts. he said he encountered a bypass and needed to clean install. Then you keep asking him if he rebooted even after he said yes, you surely expected a NO to prove your point... hjlbx isn't a beginner with Sbie.

Not saying that you will never find any bypass of Sandboxie for the simple reason that you never test anything, rarely install new softs and customized Sbie settings to the max. following this, any security softs is invincible then. You could even run your OS without Sbie , you would never get infected. You are a special case Bo, but you are not the majority.
Most users of sandboxie i encountered don't have the skill to setup Sbie tightly and most will run infected keygens & cracks, inside Sbie default box believing they are uber-safe, which isn't the case (most restrictions aren't inplemented)

About the Rehips' dev, he said he doesn't like much the way Sbie function but still agree on its efficiency; then you start criticizing his product without surely even testing it. Things that you just complains about Kees (who , btw, was giving neutral opinion). Funny isn't it?

finally about convenience, i'm sorry, but Sandboxie is not as convenient as you think because of those reasons:

- a beginner will have hard time to set it properly, i spent lot of time to setup different sandboxes for various programs. Why the devs don't create pre-made sandboxes for several kind of programs.
- Sbie needs lots of updates/fixes to keep up with OS/softwares changes, best example was the MS Office's Fix.

convenience is about less user interaction, Webroot is convenient but not Sandboxie, however Sbie is surely more convenient than any HIPS.

Don't think im a Sbie hater, i love it , it belongs in my "must-install-first" apps list. my problem is the way you constantly try to promote it and "bully" members that dare to say something negative (proven or not).

sincerely, guest

 

sorry didn't saw your post, was writing mine, but some things have to be said.

 

Peter could you clarify whether you mean personally directed posts or mention of sandboxie or both?

 

both are offtopic anyways

 

Here's a nifty AppLocker bypass tool: http://www.kitploit.com/2016/01/p0wnedshell-powershell-runspace-post.html

What I like this tool is it graphically illustrates that blocking powershell.exe will not prevent powershell based malware.

What we tried was to build an “all in one” Post Exploitation tool which we could use to bypass all mitigations solutions (or at least some off), and that has all relevant tooling included. You can use it to perform modern attacks within Active Directory environments and create awareness within your Blue team so they can build the right defense strategies. ​

 

Hello Itman. Fleishmann asked about RMI at the Sandboxie forum, here is the answer.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=22809&p=120329#p120329

Bo

 

@itman

Am I missing something ?

The authors coded powershell scripts, compiled them into binaries and then ran them using NET Framework ?

 

Then csc.exe and Installutil.exe has to be blocked in addition to powershell.exe
And it can't be compiled & started anymore.

It looks like a "best of" of several exploits/tools that are compiled into one application - "that does not rely on powershell.exe"

 

Thanks @mood. In my config all the abusable NET Framework stuff is blocked so I don't fret about it. If I fret over every single potentiality then I might as well have a nuclear meltdown.

 

To clear up a few misconceptions.

P0wnedShell is not a "hack." It is penetration test tool. The components included within make it for all practical purposes unstoppable.

Blocking of csc.exe and installutil.exe will render and break .Net in your OS. Both are necessary components. Installuntil.exe runs at Win update time and is used to install new or updated .Net components. Csc.exe is used to dynamically build .Net assemblies on the fly. For example on my Win 7 build, there is a OS installed scheduled task that runs csc.exe on a weekly basis. The only reason csc.exe was referenced in this article was to compile and create the p0wnedShell executable if you didn't have Visual Studio installed.

Neither csc.exe nor installutil.exe are .Net directories exe's that have been targeted by malware creators for abuse; other .Net directories exe's have been. Monitoring of .Net exe's is extremely complicated and is not recommended unless you absolutely know what you are doing.

Finally, a C# exe is a standalone executable. It does not need any .Net directory based .exe to run it in any capacity. An example a lot of people use is Process Explorer which is .Net based. The only reason the author is using installutil.exe to run p0wnedShell.exe is to log and monitor it's activities for analysis purposes.

 

It depends.
In my logfiles i see, that Installutil.exe was never executed (within the last 12 months).
If it was running before i logged in, then my security apps aren't running and can't block it and therefore can't "render and break .Net"
And Csc.exe was only executed several times for compiling plugins from the .NET-based Password Manager "Keepass".
(Ok, then the blocking of csc.exe should be temporarily disabled)
But in my case it's fine to block them.

But in general these two executables can be abused and are being abused. It exists malware that is based on this "technique":
Drop the payload in a temporary directory (\temp\script.cs)
+ use csc.exe for compiling it (csc.exe = Whitelisted, because it's in Program Files)
+ use Installutil.exe for running it (InstallUtil.exe = Whitelisted, because it's in Program Files)
= Bingo...

One example for the abuse of csc.exe and InstallUtil.exe:
https://gist.github.com/subTee/408d980d88515a539672
Look at the 2 steps at the beginning of the script. They look familiar (csc.exe for compiling + InstallUtil.exe for running it)

...for analysis purposes? I think, that's not the reason. Bypassing Applocker (or other whitelisting-Apps) is the reason.
He mentions: "To run as x64 binary and bypass Applocker"
InstallUtil.exe /logfile= /LogToConsole=false /U C:\p0wnedShell\p0wnedShellx64.exe

If the file p0wnedShellx64.exe is executed alone, AppLocker is definitely blocking it.
But with using of InstallUtil.exe it can run. I see this as an abuse of InstallUtil.exe

--------
Maybe in general these two executables shouldn't be blocked, if these files are executed several times a day, windowsupdate is running, .NET is updated, etc.
But the rest of the time, why not block it?
There is potential abuse of these files.

 

Correction - Installutil.exe is the command line version of AddinUtil.exe. Both are functionally equal except how they are run. AddinUtil.exe is the processes activated through Win updating to update .Net components.

If you want to block Installutil.exe that is your prerogative. Again, this .exe is far from the only .Net based executable that can be abused.

So why would any hacker in their right mind disclose the details of their bypass? Again, the purpose of this tool is for penetration testing. Additional purpose is to show that whitelisting per se is inadequate against today's APT threats.

 

This AppLocker Powershell bypass is the "latest and greatest" bypass by the author. It is not his only authored whitelisting bypass. Last year, he published the following that also used InstallUtil.exe coupled with csc.exe:

You would then first, compile the binary.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /outELoader.exe PELoader.cs

This can get caught by systems if you try to outright execute the new file. Notice the 'Access Denied'. However, if I invoke the same file like this:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U PELoader.exe​

Ref.: http://subt0x10.blogspot.com/2015/08/application-whitelisting-bypasses-101.htmlhttp://subt0x10.blogspot.com/2015/08/application-whitelisting-bypasses-101.html​

For the record, I also monitor i.e. HIPS alert on InstallUtil.exe execution along with a "whole bunch" of .Net processes using custom Eset HIPS rules. Note the word "monitor." There are very few things I outright block from execution.

The following are my custom HIPS rules for monitoring csc.exe execution. These rules took a great deal of time to research and testing to perfect. They work on my particular Win 7 x64 build.

Note: I give absolutely no guaranty these restrictions will work on your build and/or not break your .Net installation by improperly monitoring or wrong decision in the monitoring process. Ditto for any resultant malware infection that could occur from the preceding.

HIPS rule No. 1 - allow the following process to start csc.exe.

Source applications:
C:\Windows\System32\sdiagnhost.exe

Target applications:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe​

HIPS rule No. 2 - allow csc.exe to create files in the following directories. Additionally, I log all executions of this rule and check those log entries regularly.

Source applications:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe

Target files:
C:\Users\Don\AppData\Local\Temp\*.*
C:\Documents and Settings\temp\*.*
C:\Windows\Temp\*.*​

HIPS rule No. 3 - monitor and log all other instances of css.exe execution

Source applications:
for all

Target applications:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe​

Finally and most importantly, this is what is required just to control and monitor one .Net process.

 

Sure, a lot more has to be blocked (or monitored).

Correct.
And he's circumventing the whitelisting = bypass. It can be called that way too.

Edit:

For whatever reason this tool is made for ...
The point is that .NET-executables can be used to circumvent whitelisting-applications.
Not only in this "penetration testing tool", but also in general.

You yourself are posting "bypasses" with csc.exe + InstallUtil.exe
#776
So i think i can't be completely wrong with my last long post.