With the Fall Creators Update 1709 Microsoft has included an enhanced version of their own Windows Defender product. This apparently has an option to turn on anti-ransomware protection using a feature called "controlled folder access". See this link: -us/windows/threat-protection/windows-defender-exploit-guard/enable-controlled-folders-exploit-guard
This seems to be a simple feature that enables only allowed applications to make modifications to selected folders. The same can be accomplished with a HIPS rule. My understanding is that the feature would not protect folders from ransomware that injects into or is run by allowed applications, such as VB scripts.
Appears the default setting is to deny any access to any controlled folder. [See below Edit] You can add allowed apps but of course if those were hijacked, you could get nailed. If this is true, it should detect any script engine access.
As previously stated, you can easily do the same by creating a HIPS "ask" rule for My Documents, etc. to detect any write or delete access and the more apps you create "allow" rules for, the higher the likelihood of getting nailed by ransomware. For example, malware could deliver ransomware using the explorer.exe shell.
!Important
By default, Windows adds apps that it considers friendly to the allowed list - apps added automatically by Windows are not recorded in the list shown in the Windows Defender Security Center app or by using the associated PowerShell cmdlets.
Thanks for the comments and advice. However, I expect any AV product that I choose to pay for to provide the best possible protection by default rather than expecting the user to have knowledge and understanding of how to create advance settings. If Microsoft is deeming some form of access control as important and Eset is not then I need to ask why? I have no wish to start using Defender and am happy to pay for Eset to help keep my family computers safe but I am looking for reassurance that it will do so by default without me or my wife having any specialist knowledge. I don't mind being asked questions when first installing or updating on an interactive basis but I don't expect to have to be proactive in order to feel secure.
Windows Defender ransomware protection is abysmal as noted in AV Lab tests that specifically tested for ransomware protection effectiveness. This is why MS added the controlled folders protection; a typical Band-Aid security approach they are noted for.
Because we don't want to give users a false sense of security by providing a solution that can be relatively easily circumvented and cause issues for some users at the same time. We use several advanced smart techniques to prevent new borne malware from running in the first place.
Many thanks for all the feedback. I don't pretend to understand all the technicalities other than to realise that most users will not delve in any detail into all the complexities of the subject. I started off this thread wanting some assurance that I was doing the right thing in sticking with ESET and not considering the "free" option and I am comfortable that I have achieved that. I fully recognise that no solution can ever give a 100% guarantee and the user must always take some responsibility as to what they do on their computers. It is, however, important that products that are considerably customizable, such as the various flavours of ESET, default to a high degree of security as many users will never venture beyond the default settings, let alone understand some of the configuration options offered.
If you are totally unfamiliar with Windows Defender Exploit Guard, I suggest you read Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware first and then continue reading here.
You see, enabling and deploying these features is pretty straight forward. But depending on your environment enabling some of these features can negatively impact users, so what you want to do is monitor the possible impact and deploy these settings in a controlled manner.
With the exception of certain exploit protection rules, most of the features and rules can be configured to run in audit or in block mode. But regardless of the mode used, all results are always written into the Windows Event log.
If you start experimenting with the various Windows Exploit Guard features on your own computer, you will want to examine the exploit guard event logs. For this I wrote a PowerShell cmdlet that helps you to easily retrieve these logs. When interested read: Retrieving Windows Defender Exploit Guard Windows Event logs with PowerShell.
And here we see the result when auditing controlled folder access. Exploit Guard CFA File creator.exe was detected as it writes to a user protected folder. When deploying this in production, you will first want to identify these events and add any legitimate software to the CFA allowed applications configuration.
Anyway, apologies for the detour but it was great to learn that defender is getting sharper on payloads delivered into a process; even without any extra configuration or help from the new exploit controls.
An attacker eventually needs the addresses of specific system functions(e.g. kernel32!VirtualProtect) to be able to perform malicious activities.These addresses can be retrieved from different sources, one of which is the importaddress table (IAT) of a loaded module. The IAT is used as a lookup table when an application calls a function in a different module. Because a compiled programcannot know the memory location of the libraries it depends upon, an indirect jumpis required whenever an API call is made. As the dynamic linker loads modulesand joins them together, it writes actual addresses into the IAT slots so that they pointto the memory locations of the corresponding library functions.
LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, LdrLoadDll, VirtualAlloc, VirtualAllocEx, NtAllocateVirtualMemory, VirtualProtect, VirtualProtectEx, NtProtectVirtualMemory, HeapCreate, RtlCreateHeap, CreateProcessA, CreateProcessW, CreateProcessInternalA, CreateProcessInternalW, NtCreateUserProcess, NtCreateProcess, NtCreateProcessEx, CreateRemoteThread, CreateRemoteThreadEx, NtCreateThreadEx, WriteProcessMemory, NtWriteVirtualMemory, WinExec, LdrGetProcedureAddressForCaller, GetProcAddress, GetProcAddressForCaller, LdrGetProcedureAddress, LdrGetProcedureAddressEx, CreateProcessAsUserA, CreateProcessAsUserW, GetModuleHandleA, GetModuleHandleW, RtlDecodePointer, DecodePointer
c80f0f1006