SHvFl

Level 35
Verified
Trusted
Content Creator
This is what this thread is about :) a default allow SRP that constrains certain apps and also apply WDAC to them ( though WDAC probably merits a separate thread )

If you don’t run malware on purpose and open untrusted docs inside the browser, then browser & email client are the two delivery mechanisms left ( excluding some sort of supply chain malware that I haven’t quite figured out how to prevent )
Your argument doesn't make much sense though as already chrome and maybe whatever email client you use takes into consideration the ability of windows to protect themselves. So you trying to add extra protection from windows without other tools is rather a weak way to go about even if it actually works. Your method puts all your apples in the same basket and someone hungry enough can eat them.
Sure we are talking about a hypothetical scenario but you asked for it. In reality, if you worry you will get infected by visiting sites and your email i would say you are safe and don't need to do anything.
 

notabot

Level 12
Your argument doesn't make much sense though as already chrome and maybe whatever email client you use takes into consideration the ability of windows to protect themselves. So you trying to add extra protection from windows without other tools is rather a weak way to go about even if it actually works. Your method puts all your apples in the same basket and someone hungry enough can eat them.
Sure we are talking about a hypothetical scenario but you asked for it. In reality, if you worry you will get infected by visiting sites and your email i would say you are safe and don't need to do anything.
SRP + WDAC are on top of existing protection, these layers are not there out of the box

I don’t understand what you mean with the basket, why would adding a protection layer to eg visual studio that Never fetches anything but MS signed binaries be useful
 
  • Like
Reactions: shmu26

SHvFl

Level 35
Verified
Trusted
Content Creator
SRP + WDAC are on top of existing protection, these layers are not there out of the box

I don’t understand what you mean with the basket, why would adding a protection layer to eg visual studio that Never fetches anything but MS signed binaries be useful
Chrome is already in appcontainer. Things will not magically start running on your system because you visited a site and in the scenario, an exploit manages to pass chrome it will probably be reported to chrome before it reaches your pc.
Same assuming you have outlook you can change 2 settings and nothing actually loads.
So at the end you are worried if something extreme remotely exploits your browser and email client. So both Srp and wdac are probably not good methods to solve that as you don't know how the exploit will work.
Anw you do you if you think that is the correct approach.
 

notabot

Level 12
Chrome is already in appcontainer. Things will not magically start running on your system because you visited a site and in the scenario, an exploit manages to pass chrome it will probably be reported to chrome before it reaches your pc.
Same assuming you have outlook you can change 2 settings and nothing actually loads.
So at the end you are worried if something extreme remotely exploits your browser and email client. So both Srp and wdac are probably not good methods to solve that as you don't know how the exploit will work.
Anw you do you if you think that is the correct approach.
What you say is correct, effectively it’s about post exploit mitigation - I don’t agree though, restricting what can run & chroot’ing (via SRP) are the two techniques used to avoid privilege escalation, of course nothing is guaranteed to offer 100% protection but I don’t see why not to use the only existing post exploit mechanisms
 
  • Like
Reactions: shmu26 and Andy Ful

Andy Ful

Level 48
Verified
Trusted
Content Creator
notabot,
The default-allow setup from the post Q&A - SRP - A practical default allow?, is OK. But, SHvFl is right that your concern about Chrome is unnecessary. You will probably never see something escaping the Chrome Sandbox. You can get the malware contained in the sandbox, but this usually cannot be stopped by SRP or WDAC. Furthermore, Chrome works best when left alone.
 

notabot

Level 12
notabot,
The default-allow setup from the post Q&A - SRP - A practical default allow?, is OK. But, SHvFl is right that your concern about Chrome is unnecessary. You will probably never see something escaping the Chrome Sandbox. You can get the malware contained in the sandbox, but this usually cannot be stopped by SRP or WDAC. Furthermore, Chrome works best when left alone.
Neither interferes with Chrome (unlike eg a 3rd party AV), they’re mechanisms provided by the OS, not a hack with callbacks. and both provide different protections to the sandbox.
 
  • Like
Reactions: shmu26 and Andy Ful

Windows_Security

Level 23
Verified
Trusted
Content Creator
:) I would suggest adding a basic user SRP (all executables except DLL and all users except Admin). Make sure to use the updated list of SRP enforces file extensions (e.g.Andy's Hard Configurator), but . . . . remove EXE. MSI and LNK from file extensions which SRP enforces. This is a ' hardened' default allow :)
 

Andy Ful

Level 48
Verified
Trusted
Content Creator
:) I would suggest adding a basic user SRP (all executables except DLL and all users except Admin). Make sure to use the updated list of SRP enforces file extensions (e.g.Andy's Hard Configurator), but . . . . remove EXE. MSI and LNK from file extensions which SRP enforces. This is a ' hardened' default allow :)
I think that removing shortcuts (LNK) from file extensions can be OK for @notabot, but generally it opens a very dangerous vector of attack through sponsors. For example, the shortcut can use CMD and Bitsadmin.exe to download/run the malware. It is also easy to make the shortcut with any kind of malware (EXE, DLL, etc.) added to it via Alternate Data Stream (ADS). If the user will run such a shortcut, then the commandline (with sponsor) in the shortcut can run the malware from ADS.
 

Andy Ful

Level 48
Verified
Trusted
Content Creator
The average user can ask a reasonable question. Why one should bother about the EXE or DLL malware executed via shortcuts, when EXE and DLL files are already allowed by SRP (in default-allow setup)?
  1. The malware run via shortcuts will be ignored by SmartScreen.
  2. The malware run via shortcuts will be usually the 0-day (fresh sample).
Such malware files are much more dangerous than the files downloaded by the user from the Internet.
 

notabot

Level 12
The average user can ask a reasonable question. Why one should bother about the EXE or DLL malware executed via shortcuts, when EXE and DLL files are already allowed by SRP (in default-allow setup)?
  1. The malware run via shortcuts will be ignored by SmartScreen.
  2. The malware run via shortcuts will be usually the 0-day (fresh sample).
Such malware files are much more dangerous than the files downloaded by the user from the Internet.
You’re correct however to be clear, the proposed default allow here is about hampering the delivery mechanisms, hence their very tight control with 4 layers of defense (SRP+GPO+Exploit Guard+WDAC).

If despite the multiple layers of protection for the delivery mechanisms the malware gets in, then indeed it’s only the AV+Windows native protections left, there’s no further whitelisting that would block the malware.
 
  • Like
Reactions: shmu26 and Andy Ful

Andy Ful

Level 48
Verified
Trusted
Content Creator
You’re correct however to be clear, the proposed default allow here is about hampering the delivery mechanisms...
Yes, that is why such files like shortcuts & scripts & sponsors & documents & files with dangerous extensions, should be properly blocked/restricted. But, doing this properly for shortcuts via SRP, without losing much usability, requires advanced knowledge about SRP.
 
  • Like
Reactions: shmu26 and upnorth

notabot

Level 12
Yes, that is why such files like shortcuts & scripts & sponsors & documents & files with dangerous extensions, should be properly blocked/restricted. But, doing this properly for shortcuts via SRP, without losing much usability, requires advanced knowledge about SRP.
I don’t see an attack vector with shortcuts.

shortcuts become relevant only when malware has reached the PC and executes, the whole point of the setup is that it doesn’t, Chrome is restricted by GPO (google offers templates) to download only to a specific folder and that’s set to non executable, with WDAC it won’t be able to spawn child processes so even if it’s hijacted to bypass the GPO it won’t be able to execute. In this setup SRP is there for the tail risk that chrome itself becomes the malicious actor and tries eg to delete or upload something (though that’s partly covered by Windows 10’s protected folders as well)

It would be needed without WDAC probably but with WDAC I feel it’s redundant
 
  • Like
Reactions: shmu26

Andy Ful

Level 48
Verified
Trusted
Content Creator
I don’t see an attack vector with shortcuts.
...
It would be needed without WDAC probably but with WDAC I feel it’s redundant
As I said before, you will not probably need it, because you will not execute the malicious shortcut by yourself. That will not be true for most people.

But, it does not matter, because you apply SRP and WDAC only to protect Chrome.
There is nothing wrong with it. But, such protection does not fit to the tile of this thread - it would be far from the practical solution for most users.:giggle:(y)
 
  • Like
Reactions: shmu26 and notabot

notabot

Level 12
As I said before, you will not probably need it, because you will not execute the malicious shortcut by yourself. That will not be true for most people.

But, it does not matter, because you apply SRP and WDAC only to protect Chrome.
There is nothing wrong with it. But, such protection does not fit to the tile of this thread - it would be far from the practical solution for most users.:giggle:(y)
To go off topic slightly, with Chrome GPO you can block “potentially harmful downloads”, which is different to “harmful downloads”, potentially harmful is whitelisting of downloads.

It’s quite strict, eg it won’t let me download PDFs from my insurer while it will let me download PDFs from gmail (I assume due to scans in gmail) but for executables, this makes more sense, unless an executable is whitelisted (I presume by ESET?), it won’t download at all.

So a 2 browser setup, chrome with this policy on for browsing and eg FF exclusively for insurance , banking etc is probably the safest for home users as this way they won’t download malware exes while browsing unless their insurer pushes malware. Ofc there’s weaponised docs to worry about too but using web viewers from gmail should again suffice.
 
  • Like
Reactions: shmu26 and Andy Ful

Andy Ful

Level 48
Verified
Trusted
Content Creator
To go off topic slightly, with Chrome GPO you can block “potentially harmful downloads”, which is different to “harmful downloads”, potentially harmful is whitelisting of downloads.

It’s quite strict, eg it won’t let me download PDFs from my insurer while it will let me download PDFs from gmail (I assume due to scans in gmail) but for executables, this makes more sense, unless an executable is whitelisted (I presume by ESET?), it won’t download at all.

So a 2 browser setup, chrome with this policy on for browsing and eg FF exclusively for insurance , banking etc is probably the safest for home users as this way they won’t download malware exes while browsing unless their insurer pushes malware. Ofc there’s weaponised docs to worry about too but using web viewers from gmail should again suffice.
Two-account setup is much safer: daily work + web browsing on SUA, banking only (no surfing) on Admin.
 
  • Like
Reactions: notabot and shmu26

shmu26

Level 83
Verified
Trusted
Content Creator
To my way of thinking, the thing that is really missing from native Windows security policies is proper control of rundll32.exe. It can be used for a lot of mischief.
 

notabot

Level 12
To my way of thinking, the thing that is really missing from native Windows security policies is proper control of rundll32.exe. It can be used for a lot of mischief.
Once stuff is in it’s such a mess to contain it, you need complex policies that’s why with this setup I try to harden delivery mechanisms. I’ve setup Exploit Guard and GPO, SRP and WDAC to follow

After that (in the abscence of complete whitelisting) though far from perfect, there’s AV, UAC, Smartscreen - in my view these if any of these flags/asks something unexpected reinstall the OS, it’s too late
 
  • Like
Reactions: shmu26