@Windows_Security, would you be able to share your Exploit guard settings for MS Word, Excel and Powerpoint?Windows 10 has so many great build in features. Bu some are hidden or not easy to find. Also with WD exploit protection, every update overwrites the programs alread set by Windows back to its default. When you want to add stuf (e.g. PowerPoint below), you need to ad a full path name rule to make your additions stick/permanent.
View attachment 193519
That should work well for printing one or two documents, because printing has to be done with external PDF application. There is another trick for printing many documents directly from the protected MS Office.
@Andy Ful: so bottom line, what do you say are the recommended WDEG rules for a typical user to enable for Word/Excel/Powerpoint, on Windows 10 1803?Access, Excel, Outlook, PowerPoint, Word
Windows default system-wide mitigations: Control Flow Guard (CFG), DEP (for 64-bit apps), Randomize memory allocations (Bottom-Up ASLR), High entropy ASLR, Validate exception chains (SEHOP), Validate heap integrity.
Microsoft Security BaseLine Windows ver. 1803 (the below per-application mitigations are activated alongside system-wide): DEP (for 32-bit apps), Export address filtering (EAF), Force randomization for images (Mandatory ASLR), Import address filtering (IAF), Simulate Execution (SimExec), Validate API Invocation (CallerCheck), Validate Stack Integrity (StackPivot).
Do not allow child processes is not required (for MS Office) if one uses ASR, although this mitigation is stronger, because the user cannot start printing session (printing is still possible with some trick) and cannot open any other applications from the protected one (Word cannot open an embedded spreadsheet in Excel etc.).
Block untrusted fonts mitigation is not required for most users, because in Windows 10, the GDI font parsing is no longer performed in kernel mode but via fontdrvhost.exe, which is running in AppContainer (user mode). Blocking untrusted fonts is the system-wide mitigation, so the fonts are blocked everywhere (PDF viewers, 3rd party web browsers, etc.) - sometimes this can be not convenient (not readable text).
Other mitigations are also possible, but should be tested on the concrete machine, because some apps integrated with MS Office applications may work improperly.
That is simple. Do not touch anything & use default settings.:emoji_disappointed:
Well, I am not a big fan of the theory of evolution, but if I was to craft a WDEG policy for Office apps, I would enable the following. I created this tentative list based on @Windows_Security's policy, subtracting the mitigations about which you said that they are already activated by default on Windows 10 1803. Please comment, especially if I misunderstood something. (I can't claim that I really know what all these mitigations are actually doing...)That is simple. Do not touch anything & use default settings.:emoji_disappointed:
Microsoft always "knew better" what is good for the customers. Home users were usually the 'guinea pigs' for them. Many security features were (and still are) poorly documented. Microsoft introduced many different command interpreters, programming interfaces, and software components (CMD Shell, Windows Script Host, PowerShell, VBA, .NET Framework, COM Objects, WMI, ActiveX, OLE, Application Shim, etc.). The same can be said for managing the networks. Almost any file can be dangerous and can support exploits. Executable code can be run/injected/hooked in many different ways. MS Office can be abused easily and the new versions can introduce the new attack vectors. Windows 10 is a nightmare for security software developers. I could complain and complain about how bad Microsoft is from the security point of view.
My personal opinion is that Microsoft equally contributed to the development of society computerization and to the development of computer malware.
Should we blame Microsoft for this? Maybe, so. Unfortunately, evolution did the same for all living organisms.
Yes. I think that my post could be misunderstood, so I edited the phrase "are activated" to 'should be activated".Well, I am not a big fan of the theory of evolution, but if I was to craft a WDEG policy for Office apps, I would enable the following. I created this tentative list based on @Windows_Security's policy, subtracting the mitigations about which you said that they are already activated by default on Windows 10 1803. Please comment, especially if I misunderstood something. (I can't claim that I really know what all these mitigations are actually doing...)
Block remote images
Code integrity guard
Disable extension points
Force randomization for images
Validate image dependency integrity
I would not enable "Do not allow child processes" because of printing issues and other usability issues. This mitigation is covered sufficiently well by ASR.
Okay, that takes the mystery out of it. It makes a lot more sense now.Yes. I think that my post could be misunderstood, so I edited the phrase "are activated" to 'should be activated".
I meant that all blue mitigations in my post:
Windows 10 - Use Windows 10 build-in (anti)execution options
are activated in Microsoft Security BaseLine Windows ver. 1803. It means that they should be activated by the user via Exploit Guard panel.
Windows_Security mitigations are (mostly) beyond Microsoft Security BaseLine for Windows ver. 1803 . If they work on his computer, then probably can work on many other computers.
I would recommend to start with Security BaseLine first, and after some time (if all works well) apply the rest proposed mitigations.
Wow, I am impressed to see such restricted & secure setup.My Windows 10 Security using internal mechanisms only
So IMO opinion on Windows 10 Home edition security is a non-issue thanks to this forum (to use ideas), Andy and Andreas
- Andy's Configure (Windows) Defender (to easily enable Attack Surface Reduction, Smartscreen and other stuff)
- Andy's Hard Configurator to block execution of removable disks and run as basic user (allow run as admin)
- Andreas' NVT (Windows) SysHardener (to disable all the home user obsolete stuff and set UAC to deny elevation of unsigned)
- Eenabled Windows Defender protected folders feature for Ransonware protection
- Allow user to only install apps from store
- Added a few extra WD Anti Exploit Protection settings (e.g. Edge, Office2013 and Powershell)
- Added a Deny Execute Access Control List for internet facing folders and User startup folders (last one also with deny create/write)
- Removed basic user rights from HKCU startup entries with regedit
- Added MalwareBytes extension for Chrome with some about:flags hardening and Adguard to Edge (with optimized filters and browser security enabled), using Norton Safebrowsing as DNS (set in hardware properties of wireless card)
- Using Kaspersky free Secure Connection VPN on ad-hoc basis (only when abroad for online banking & booking)
P.S. maybe Andy could add 7 and 8 to Hard Configrator (with seperate option to set ACL deny execute file/traverse on download folders, becauise that is the only one with functional impact.) Setting this ACL on public folders or User/Appdata/Temp temporaray Internet folders, etc. has zero functional impact). So many hurdles and tripwires for malware makes me smile and security a non-issue.
Understand. My point is that some updates use this key also as standard user (no admin rights) - the Windows OneDrive is an example. That is also common for most updates for applications that are installed in the Userspace, because they do not need admin rights to update.Andy,
only install. also' regular' programs which use the HKLM run keys (elevated). Because ransomware likes to misuses the HKCU keys to survive re-boot, I don't set a deny, but remove the rights of standard user, so in order to change them you need to be admin or higher.
Yes, that could be an advantage over blocking those folders by the WD Ransomware protection. The installations in the Userspace will not be a problem (mostly), except OneDrive and other installers that cannot be run as administrator.Same trick with windows startfolders for users, don't set a deny, but remove the create/write rights for current user. this still allow updates invoked by Windows itself (as admin, system or trusted installer).
You have the special setup that does not allow elevation of unsigned executables, so you cannot use directly the "Run As SmartScreen" option (RunAsSmartscreen executable is not digitally signed and requires elevation). That is OK, for the users which know the limitations of Windows SmartScreen. Your setup is still default-deny for files running as standard user (SRP 'Default Security Level' = Disallowed or Basic User) and additionally restricted on the elevation of unsigned programs.I use basic user as default level with run MSI as admin reg tweak, So right click run as admin allows to install everything. I know this is not as secure as Default deny., I like to have the option to right click run as admin to install stuff.I accept the down side that basic user has holes compared to default deny. but I trust ASR and Smartscreen to block execution (by myself) of untrusted/poor reputation programs.
The mitigation 'Disabling child processes in PowerShell' + Constrained Language mode (applied by SRP) is a pretty good protection. Anyway, I think that you can disable PowerShell executables via Hard_Configurator (<Block Sponsors>). Windows Updates use directly System.Management.Automation.dll to retrieve PowerShell functions. System scheduled tasks and other processes will bypass this protection when running with admin or higher rights.It is my experience that you don't need a watertight block, just adding several hurdles and tripwires from different angles, makes it very dificult for exploits to succeed (e.g. add a WD exploit rule for powershell to disable launching child processes, I don't need NVT OS armor for that).
Yes, except maybe a few updates for 3rd party vendors (AMD, Intel, NVIDIA, etc.). I am not sure about updates from Microsoft Store, but this should not be the issue.So if you block powershell.exe with an anti-exe software, Windows Updates will bypass it?