Windows Defender Antivirus can now run in a sandbox

[imuade]

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]

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.

 

[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.

 

[Local Host]

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.

 

[ForgottenSeer 72227]

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.

 

[Deleted member 178]

@Raiden the feature is still experimental so I won't mind too much

 

[ForgottenSeer 72227]

@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.

 

[Mikesierra]

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

 

[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:

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]

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

Any malware that has gained elevated privileges can disable the sandbox, just like you can.

 

[blueblackwow65]

Anyone test this out with wd and its sandbox?