Security News Windows 10 Ransomware Protection Bypassed Using DLL Injection

LASER_oneXM

Level 37
Thread author
Verified
Top Poster
Well-known
Feb 4, 2016
2,520
In Windows 10, Microsoft added a new ransomware protection feature called Controlled Folder Access that can be used to prevent modifications to files in protected folders by unknown programs.
At the DerbyCon security conference last week, a security researcher showed how DLL injection can be used by ransomware to bypass the Controlled Folder Access ransomware protection feature.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
The same with MS Office applications and any application that is allowed by Controlled Folder Access. That is a well known vector of attack. But, the boot sector protection cannot be bypassed in this way.
The Microsoft answer that this is not a big deal because the vulnerability is related only to the infected account and that the infection cannot expand to other accounts is slightly ridiculous for the home users.
 

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150
The same with MS Office applications and any application that is allowed by Controlled Folder Access. That is a well known vector of attack. But, the boot sector protection cannot be bypassed in this way.
The Microsoft answer that this is not a big deal because the vulnerability is related only to the infected account and that the infection cannot expand to other accounts is slightly ridiculous for the home users.
But ASR can block dll injection, correct?
If so, Windows Defender at max settings will defeat this exploit.
 
  • Like
Reactions: oldschool
E

Eddie Morra

But ASR can block dll injection, correct?
If so, Windows Defender at max settings will defeat this exploit.
Not just "DLL injection". ASR can block at-least virtual memory operations targeting another process from kernel-level if it is configured to do so.

I tested this with NtAllocateVirtualMemory and NtWriteVirtualMemory in an Office VBA Macro. I then set a break-point in NTDLL to determine if the system calls were actually being executed, followed by using a kernel debugger to test whether the system calls were being completed by reaching NtAllocateVirtualMemory and NtWriteVirtualMemory under NTOSKRNL. Sure enough, they were. The operations were still being blocked though.

I wonder how ASR deals with section mapping against another process. That is another one for me to test in the future.

If you really want to be on the safe side but keep Office VBA Macro's enabled, be sure to configure ASR to block all Win32 API calls completely. I have also tested this thoroughly for things like local memory management, process management and even file system management. I can confirm that the ASR rule for this really does work - at-least it has always held it down during my own testing of it.
 
5

509322

Not just "DLL injection". ASR can block at-least virtual memory operations targeting another process from kernel-level if it is configured to do so.

I tested this with NtAllocateVirtualMemory and NtWriteVirtualMemory in an Office VBA Macro. I then set a break-point in NTDLL to determine if the system calls were actually being executed, followed by using a kernel debugger to test whether the system calls were being completed by reaching NtAllocateVirtualMemory and NtWriteVirtualMemory under NTOSKRNL. Sure enough, they were. The operations were still being blocked though.

I wonder how ASR deals with section mapping against another process. That is another one for me to test in the future.

If you really want to be on the safe side but keep Office VBA Macro's enabled, be sure to configure ASR to block all Win32 API calls completely. I have also tested this thoroughly for things like local memory management, process management and even file system management. I can confirm that the ASR rule for this really does work - at-least it has always held it down during my own testing of it.

WMI Win32_Process
 
5

509322

@Vendula Kubová

How are you setting ASR rules ? Are you using rule GUIDs along with InTune ? InTune has ASR rule options in it that are not documented (no surprise there).

I tried setting them using PowerShell but the switch needed to set them isn't present on default Windows 10 Pro. So I'm assuming the rules have to be created in Windows Enterprise\WADC and pushed to endpoints via InTune or equivalent.
 
E

Eddie Morra

WMI Win32_Process
WMI. Another thing I completely despise. I hate how Microsoft hard-wired it into Windows.

It doesn't look like there is an ASR rule for WMI either (unless I am blind) and I really doubt the Win32 API calls rule will cover it... if anyone can confirm if it does/doesn't, would be appreciated.

@Andy Ful by any chance... do you know?

How are you setting ASR rules ?
When I tested out the code injection and Win32 API call prevention, I was setting the rules through using the GUIDs with Group Policy Editor.

I was following this as a guide to do it: Use attack surface reduction rules to prevent malware infection
  1. Block Office applications from injecting code into other processes -> 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84
  2. Block Win32 API calls from Office macro -> 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B
Those are the only rules I've tested.

The documentation doesn't actually tell you how to enable those ASR rules through Group Policies AFAIK, you can find the location under Computer Configuration -> Administrative Templates -> Windows Components -> Windows Defender Antivirus -> Windows Defender Exploit Guard -> Attack Surface Reduction -> Configure Attack Surface Reduction Rules.

My environment during testing was Windows 10 Professional but I do not remember the build number, it was a few months ago.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
Not just "DLL injection". ASR can block at-least virtual memory operations targeting another process from kernel-level if it is configured to do so.

I tested this with NtAllocateVirtualMemory and NtWriteVirtualMemory in an Office VBA Macro. I then set a break-point in NTDLL to determine if the system calls were actually being executed, followed by using a kernel debugger to test whether the system calls were being completed by reaching NtAllocateVirtualMemory and NtWriteVirtualMemory under NTOSKRNL. Sure enough, they were. The operations were still being blocked though.

I wonder how ASR deals with section mapping against another process. That is another one for me to test in the future.

If you really want to be on the safe side but keep Office VBA Macro's enabled, be sure to configure ASR to block all Win32 API calls completely. I have also tested this thoroughly for things like local memory management, process management and even file system management. I can confirm that the ASR rule for this really does work - at-least it has always held it down during my own testing of it.
Great job.(y)
 
5

509322

WMI. Another thing I completely despise. I hate how Microsoft hard-wired it into Windows.

It doesn't look like there is an ASR rule for WMI either (unless I am blind) and I really doubt the Win32 API calls rule will cover it... if anyone can confirm if it does/doesn't, would be appreciated.

@Andy Ful by any chance... do you know?


When I tested out the code injection and Win32 API call prevention, I was setting the rules through using the GUIDs with Group Policy Editor.

I was following this as a guide to do it: Use attack surface reduction rules to prevent malware infection
  1. Block Office applications from injecting code into other processes -> 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84
  2. Block Win32 API calls from Office macro -> 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B
Those are the only rules I've tested.

The documentation doesn't actually tell you how to enable those ASR rules through Group Policies AFAIK, you can find the location under Computer Configuration -> Administrative Templates -> Windows Components -> Windows Defender Antivirus -> Windows Defender Exploit Guard -> Attack Surface Reduction -> Configure Attack Surface Reduction Rules.

My environment during testing was Windows 10 Professional but I do not remember the build number, it was a few months ago.

1. If you disable PowerShell, then you've cutoff the most direct path to WMI.
2. Win32 API call prevention does not block WMI Win32_PROCESS, that's why I listed it. (no servicing by Microsoft)
3. I am able to set those rules using PowerShell, but there is a particular switch I am searching for.

PS - I'm pretty sure the ASR rules do not prevent Office Application COM bypass either - unless Microsoft serviced it.

PowerShell servicing is good, but they're trying to whitelist\blacklist scripts via AMSI. It's ludicrous. Matt Graeber and those guys are telling other people to send Microsoft malicious PowerShell scripts that they find.

Dude... wut ? :unsure:

If you want to turn off the lights, you flip a switch... you don't use a rheostat. Rheostats are, like, so 1890s. What year is this ? 2018 ? Really ? We would never know that with the offensive PowerShell experts telling people to send malicious scripts to M$haft for blacklisting. That's like... snail mail problem solving. Are we sure it isn't 1849 ?
 
Last edited by a moderator:

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
WMI. Another thing I completely despise. I hate how Microsoft hard-wired it into Windows.

It doesn't look like there is an ASR rule for WMI either (unless I am blind) and I really doubt the Win32 API calls rule will cover it... if anyone can confirm if it does/doesn't, would be appreciated.

@Andy Ful by any chance... do you know?
...
I tested the file execution via WMI form VBS script :
Code:
set process = GetObject("winmgmts:Win32_Process")
set startup = GetObject("winmgmts:Win32_ProcessStartup")
startup.ShowWindow = 0
process.Create "path_to_exe_file",null,startup,processid
WScript.Quit
The execution was blocked by the rule "Block process creations originating from PSExec and WMI commands". This rule was introduced in April 2018.
 
5

509322

I tested the file execution via WMI form VBS script :
Code:
set process = GetObject("winmgmts:Win32_Process")
set startup = GetObject("winmgmts:Win32_ProcessStartup")
startup.ShowWindow = 0
process.Create "path_to_exe_file",null,startup,processid
WScript.Quit
The execution was blocked by the rule "Block process creations originating from PSExec and WMI commands". This rule was introduced in April 2018.

It's in InTune, but not documented. The Win32 rules don't cover it. Microsoft documentation... :X3:
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
The ASR rule "Block Office applications from creating child processes" is also interesting in the context of WMI. It can block the file execution via similar commands from VBA macro when the macro is executed by MS Office applications. (see EDIT). I was not sure about it because when you execute the file in this way, then the process is usually not visible as a child process of MS Office application. WMI is known from fooling many security applications based on monitoring child processes.

EDIT
I did the false memory mistake. In fact, several months ago I tested Exploit Protection mitigation "Do not allow child processes" for winword.exe . Indeed, this mitigation blocked macros that tried to execute files via WMI objetct.
So, I repeated today the similar test on Word 2016, for the ASR rule "Block Office applications from creating child processes". It failed - the document with macro could execute the file via WMI. But, it was stopped by another ASR rule "Block process creations originating from PSExec and WMI commands".

EDIT1
I also tested the ASR rule "Block Office applications from creating child processes" against DDE and executables embedded as OLE in documents. This time the rule was successful.
 
Last edited:
5

509322

The ASR rule "Block Office applications from creating child processes" is also interesting in the context of WMI. It can block the file execution via similar commands from VBA macro when the macro is executed by MS Office applications. I was not sure about it because when you execute the file in this way, then the process is usually not visible as a child process of MS Office application. WMI is known from fooling many security applications based on monitoring child processes.

Direct system calls. Game Over.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
@Lockdown,
I edited my previous post, because blocking execution via WMI was related to Exploit Protection mitigation "Do not allow child processes", but not to the ASR rule "Block Office applications from creating child processes" (false memory). So, probably your note about direct system calls is also related to this Exploit Protection mitigation.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top