Status
Not open for further replies.

imuade

Level 12
Verified
Top poster
Well-known
Jul 29, 2018
563
It's for me a bit hard to imagine how security app will work properly when is sandboxed (what means restricted also)...how it can properly interfere with vital parts of system that have to be protected and by this sometime supervised/modified? Is it special trick in such technology that could resolve such doubts?
I think, the app running inside AppContainer (i. e. WD) can interact with the system, but other apps can't interact with it.
I figure it out as a bubble that lets stuffs going from inside to outside and blocks stuffs from outside to inside
 

shmu26

Level 85
Verified
Helper
Top poster
Content Creator
Well-known
Jul 3, 2015
8,121
It's for me a bit hard to imagine how security app will work properly when is sandboxed (what means restricted also)...how it can properly interfere with vital parts of system that have to be protected and by this sometime supervised/modified? Is it special trick in such technology that could resolve such doubts?
I'm worried about that, too.
 
  • Like
Reactions: Raiden
D

Deleted member 178

Appcontainer concept is based on "capabilities", means the contained app is only allowed to access certains specified areas of the system.

I posted an article in the MS section for those interested.
 
Last edited by a moderator:

Local Host

Level 25
Verified
Top poster
Well-known
Sep 26, 2017
1,406
It's for me a bit hard to imagine how security app will work properly when is sandboxed (what means restricted also)...how it can properly interfere with vital parts of system that have to be protected and by this sometime supervised/modified? Is it special trick in such technology that could resolve such doubts?
Cause it's hybrid, WD is not entirely in a sandbox environment, only the processes that need to be protected.
 

Raiden

Level 19
Verified
Top poster
Content Creator
Well-known
May 7, 2018
900
Finally Microsoft is trying to make it not to simple to disable WD.

I have enabled this feature and I think it may be impacting some of WD's detections. I've run some very basic tests using ATMSO and WD demo page and some of the features are not working properly with sandboxing enabled compared to when its off. For example, if one tries the PUA test on ATSMO, WD fails the test with the sandboxing enabled, but passes the test with it disabled. Also if one tests the Block at first site test page from Microsoft, WD fails the test when sandboxing enabled, but passes it when its disabled. Granted these are basic test, but it may have an impact on its capabilities. So far it passes the other tests fine with sandboxing enabled.

One point I want to mention is that I've run these tests with Chrome, so I am not sure if this is solely isolated when running Chrome and having sandboxing enabled, but I will try these same tests tomorrow through Edge to see if it still occurs. I would be interested in seeing if others notice the same thing.
 
Last edited:

Raiden

Level 19
Verified
Top poster
Content Creator
Well-known
May 7, 2018
900
@Raiden the feature is still experimental so I won't mind too much

Thanks @Umbra,

Yes I'm not going to stress over it too much because like you said its still experimental. I'm probably going to leave it off for now until Microsoft officially releases it. I did happen to run the same tests with Edge and the issue still occurs, so as of right now it doesn't matter which browser you use.
 
E

Eddie Morra

Let´s see how long it takes until someone presents a technique to bypass this sandbox feature. AMSI can already be bypassed to execute malicious Powershell scripts:

How to bypass AMSI and execute ANY malicious Powershell code
From the article:
Code:
if (!VirtualProtect(AmsiScanBufferPtr, dwSize, 0x40, out Zero))
            {
                Console.WriteLine("ERROR: Could not change AmsiScanBuffer memory permissions!");
                return 1;
            }

Patch NtProtectVirtualMemory (NTDLL) and block if the targeted base address is => base address of amsi.dll or < base address of next loaded module after amsi.dll in virtual address space of current process (or you can do <= (base address of amsi.dll + size of module in-memory)). Now the bypass demonstrated in the article will fail.

It works by patching AMSI API routines in-memory to prevent them from working. The memory where targeted API/s are located under amsi.dll in virtual memory of current process will not be with write permissions by default so you won't be able to patch it without being able to change the memory access protection to permit the write access.

Easy to prevent if you're willing to patch NtProtectVirtualMemory (NTDLL).
 

shmu26

Level 85
Verified
Helper
Top poster
Content Creator
Well-known
Jul 3, 2015
8,121
Status
Not open for further replies.
Top