Windows OS Security(github.com)
github.com
Windows OS Security
https://github.com/jmau111-org/windows_security
119 comments
It's not that disabling any of that on Windows is hard.
It is what MIGHT happen after.
That critical ERP/Invoice/Fileshare Server 2003 and the business critical printer from 2001 might still need SMBv1.
NETBIOS is still used in modern stuff, no?
We can't really just disable it willy-nilly.
>Everything I listed above can be solved by a single sysadmin with group policy and 30 minutes to kill, and they wont reoccur.
Yes, every L2 IT helpdesk can push a GPO out. It's what the GPO does that is the issue.
It is what MIGHT happen after.
That critical ERP/Invoice/Fileshare Server 2003 and the business critical printer from 2001 might still need SMBv1.
NETBIOS is still used in modern stuff, no?
We can't really just disable it willy-nilly.
>Everything I listed above can be solved by a single sysadmin with group policy and 30 minutes to kill, and they wont reoccur.
Yes, every L2 IT helpdesk can push a GPO out. It's what the GPO does that is the issue.
> NETBIOS is still used in modern stuff, no?
Even as a Linux guy I like to have netbios enabled since it gives you automatic DNS entries for all the hostnames on your network. I love being able to `ssh me@my-nas` without having to deal with hosts files and static IPs.
Even as a Linux guy I like to have netbios enabled since it gives you automatic DNS entries for all the hostnames on your network. I love being able to `ssh me@my-nas` without having to deal with hosts files and static IPs.
Netbios is off by default in Windows; technically it is auto, but auto only turns it on if it sees a request from another machine on the LAN, or the network's DHCP passes a special field (no Linux dhcpd impl does this by default, or even has that functionality other than a manual custom field; you only see this if Windows Server is fulfilling the AD role and your AD is also your dhcpd, which is rare nowadays).
Windows, since Vista, prefers to use LLMNR/RFC 4795 (as Vista was designed to be an IPv6-first OS; Netbios and SMB for the purposes of legacy interop is purely a IPv4 concept), and as of Windows 10, also supports mDNS/RFC 6763.
LLMNR + WS-Discovery is the Vista and up solution for the entire Zeroconf stack, mDNS + DNS-SD over mDNS is Apple's solution for Zeroconf (and is also implemented via Avahi; Apple's Bonjour is open source and was chosen by Android before being replaced with yet another impl). Netbios + SSDP is this solution (and kinda disjointed, tbh) for pre-Vista.
Edit: My own personal network doesn't use any of these, and I use a local dnsmasq install to do be dns and the dhcpd, serving static assignments via /etc/ethers + /etc/hosts. All machines support DNS, support for the various discovery mechanisms suck in random ways across vendors.
Windows, since Vista, prefers to use LLMNR/RFC 4795 (as Vista was designed to be an IPv6-first OS; Netbios and SMB for the purposes of legacy interop is purely a IPv4 concept), and as of Windows 10, also supports mDNS/RFC 6763.
LLMNR + WS-Discovery is the Vista and up solution for the entire Zeroconf stack, mDNS + DNS-SD over mDNS is Apple's solution for Zeroconf (and is also implemented via Avahi; Apple's Bonjour is open source and was chosen by Android before being replaced with yet another impl). Netbios + SSDP is this solution (and kinda disjointed, tbh) for pre-Vista.
Edit: My own personal network doesn't use any of these, and I use a local dnsmasq install to do be dns and the dhcpd, serving static assignments via /etc/ethers + /etc/hosts. All machines support DNS, support for the various discovery mechanisms suck in random ways across vendors.
DNS/DHCP configuration can add a domain suffix to use... You can use something like myoffice.lan or myoffice.localdomain ... Then when you use ssh me@some-box it will use some-box.myoffice.localdomain and you just have to make sure that resolves in your assigned DNS host/forwarder.
How about mDNS and / or a DHCP-server?
ah but you see, using authentication on a business network is very difficult and we must allow rando anonymous devices to do whatever they want, apparently.
Last I checked, mDNS didn't support Windows (requirement for our household) but it looks like it does now. I'll play with it next time I set up a new machine.
>We can't really just disable it willy-nilly.
Caedite eos. Novit enim Dominus qui sunt eius.
Caedite eos. Novit enim Dominus qui sunt eius.
You really need to go out of your way to use smbv1 or unsigned smb, which usually means "in big slow entreprise setting", aka juicy targets ...
Even smbv2 is often only enabled because not-so-old printer don't support anything more recent.
Even smbv2 is often only enabled because not-so-old printer don't support anything more recent.
Not even "big slow", just "slow and underserved". My clients are banks with 25-100 employees and under 10 branches. Their IT guy is usually a banker who got stuck with the role because somebody /has/ to be the IT officer.
In recent years they have been switching over from self service checklist audits to full spectrum pentest assessments and finding a lot of bugbears.
In recent years they have been switching over from self service checklist audits to full spectrum pentest assessments and finding a lot of bugbears.
SMB signing is only on by default for servers. I've done quite a few pentests where that's been leveraged to dump the SAM hashes of workstations that happen to have the Domain admin stored.
Microsoft azhci will drop data and corrupt file systems if the servers attached have smb signing enforced. Good trap to keep in mind when a pentester says "just turn it on everywhere".
I worked previously with a security solution from $bigcorp, it ran on linux. If you wanted to do a backup to a Windows server, your only option, for a very long time, was to use SMBv1 only.
> Everything I listed above can be solved by a single sysadmin with group policy and 30 minutes to kill, and they wont reoccur.
Good point. I tried to highlight that (not relying on default policies).
Good point. I tried to highlight that (not relying on default policies).
Ever since UAC was introduced Windows has been pretty secure. Having provided IT support for over a decade, I went from seeing viruses/worms infect fresh install Windows machines a few minutes after they were connected to the internet, without any user input at all, just a connection to the internet was enough (I'm talking around the XP/2000 days).
Now 99% of infections are from users being tricked and downloading and installing the malware themselves. The biggest help with that has been uBlock origin. The next biggest risk I have encountered is phishing emails and that is 90% user education, filters can only do so much.
Now 99% of infections are from users being tricked and downloading and installing the malware themselves. The biggest help with that has been uBlock origin. The next biggest risk I have encountered is phishing emails and that is 90% user education, filters can only do so much.
> The next biggest risk I have encountered is phishing emails and that is 90% user education
I would bet that ~90% of all major breaches today are pure user engineering or user error related. Maybe 95%.
Every item on the list means nothing if a CSR (for example) uses the same passwords for their work accounts as they use on sketchy games from the app store or if they leave your hardware unattended. Boom, breach or even installs of spyware on company systems, good luck finding who screwed up. Many companies are guilty of giving way too many people access to way too much data because 'Business said they MUST have access'. And that is before you even consider the number of people who use work emails as if they are personal emails.
I would bet that ~90% of all major breaches today are pure user engineering or user error related. Maybe 95%.
Every item on the list means nothing if a CSR (for example) uses the same passwords for their work accounts as they use on sketchy games from the app store or if they leave your hardware unattended. Boom, breach or even installs of spyware on company systems, good luck finding who screwed up. Many companies are guilty of giving way too many people access to way too much data because 'Business said they MUST have access'. And that is before you even consider the number of people who use work emails as if they are personal emails.
I would argue that UAC is a much more polished solution compared to solutions available on Linux like PolKit and its UIs.
Maybe the reason is that Microsoft was under a lot more pressure to solve this and once solved had a lot more power to enforce the rules on 3rd party software.
Maybe the reason is that Microsoft was under a lot more pressure to solve this and once solved had a lot more power to enforce the rules on 3rd party software.
>> The next biggest risk I have encountered is phishing emails
I describe that threat much differently. I don't blame users. I blame windows for allowing a link clicked in an email to install software, to alter system files, to upload PII to Nigerian servers. Users should not be trusted. Just because a macro in an excel doc inside an email CAN do something clever doesn't mean that windows should allow that to happen so easily.
I describe that threat much differently. I don't blame users. I blame windows for allowing a link clicked in an email to install software, to alter system files, to upload PII to Nigerian servers. Users should not be trusted. Just because a macro in an excel doc inside an email CAN do something clever doesn't mean that windows should allow that to happen so easily.
Email Software like Outlook is largely responsible for a lot of phishing problems. E.g. email addresses are usually hidden and only visible after a lot of fiddling. Bad UI such as Outlook's makes most users powerless to recognize phishing. The blame should be put where it belongs: with the people responsible for deciding on the fatal Outlook/Exchange combination.
Outlook is not alone. Some email programs also hide the address or headers.
Windows does what it can with SmartGuard. Users just click through it. You can enforce signed software plus whitelist if you want in a system policy. Just entertain the thought that now you will have to curate a lot of software on the machines.
You can disable execute for download directories too.
These are not the default because it annoys everyone to no end. Likewise installing applications just from Microsoft Store. (Where badness has slipped in too.)
And finally, people still get caught with an MS Office document which will be opened from a download just fine and with a fake website.
You can disable execute for download directories too.
These are not the default because it annoys everyone to no end. Likewise installing applications just from Microsoft Store. (Where badness has slipped in too.)
And finally, people still get caught with an MS Office document which will be opened from a download just fine and with a fake website.
yep this problem has been solved on Android and iOS where the only place to install software is the App Store.
Windows did try to incite devs to use the windows store but it did not catch on. Restraining third-party installation only from the Store is a good way to remove adwares and co.
Honestly Microsoft did shat the bed with their app store, it has no right to be as difficult to use (both as user and developer) as it is.
Windows did try to incite devs to use the windows store but it did not catch on. Restraining third-party installation only from the Store is a good way to remove adwares and co.
Honestly Microsoft did shat the bed with their app store, it has no right to be as difficult to use (both as user and developer) as it is.
One of the big reasons that the Microsoft store failed so hard was the absurd cut Microsoft wanted (30%).
Windows developers were and are already doing app distribution. 30% for something dev's were already doing...
Windows developers were and are already doing app distribution. 30% for something dev's were already doing...
Numerous android apps were found to be doing dodgy things after the fact. Probably ios ones too. It's not foolproof.
Would also like to see block mounting of ISOs by default.
> infect fresh install Windows machines a few minutes after they were connected to the internet
yes - because back then, NAT'ing / putting a machine behind a router wasn't commonplace yet.
yes - because back then, NAT'ing / putting a machine behind a router wasn't commonplace yet.
That is true and on that point, Windows didn't have an integrated firewall until the XP Service Pack 2 release.
The default user being administrator did not help. I would get most of that effect by just adding a second standard user to peoples machines. "use this user for everything but installing things". That cut down on the calls a lot. UAC just put a spot in place for the user to go 'oh im doing something adminy' which helped so much.
Back then, a ton of software would complain or not work if it wasn’t running under an account with admin privileges.
UAC forced developers to make the software work no matter what.
UAC forced developers to make the software work no matter what.
Surprisingly a lot of it was usually just a misplaced registry entry or one with the wrong ACL on it.
The first we did with UAC was disabling it. Because nobody did care.
So you can throw the best security at users for free. Some dud will disable it because his powershell script is not working anymore.
So you can throw the best security at users for free. Some dud will disable it because his powershell script is not working anymore.
People that were technical sometimes did that, or re-enabled administrator, or both. Because it 'got in the way'. But for the vast majority of people UAC worked as it should.
Almost all the bad things you’re worried about don’t require an elevated token. I’m much more worried about someone stealing my data, installing a trojan, etc. (none of which require elevation) than installing a device driver (which does).
This obsession with not running as root/using UAC is just cargo cult security for single user systems.
This obsession with not running as root/using UAC is just cargo cult security for single user systems.
Having seen the horror shows that some people did to their computers. It is much better. Least priv is a decent thing to strive for. You want to reduce the attack surface. By giving people root you basically make the attack surface your entire computer. I am not going to make the trojan writers job easier.
Also as I have gotten older I also realized that I make mistakes too. Running as least privs reduces the fallout to 'i have to restore a few files' from 'i get to reinstall the whole computer again'. UAC/notroot are tools to help you. You can discard them. That is fine. Not going to judge. I am saying most people it helps them. Not that it matters much anymore anyway. Most of the people who did these silly things to their own computers have moved onto tablets.
Also as I have gotten older I also realized that I make mistakes too. Running as least privs reduces the fallout to 'i have to restore a few files' from 'i get to reinstall the whole computer again'. UAC/notroot are tools to help you. You can discard them. That is fine. Not going to judge. I am saying most people it helps them. Not that it matters much anymore anyway. Most of the people who did these silly things to their own computers have moved onto tablets.
>I am not going to make the trojan writers job easier.
The Trojan writer now targets systems with UAC, since it’s the default and the vast majority of systems, so you’re not gaining anything. And he never needed an elevated token in the first place.
The Trojan writer now targets systems with UAC, since it’s the default and the vast majority of systems, so you’re not gaining anything. And he never needed an elevated token in the first place.
UAC offers almost no additional security for single user systems. You’re trying to protect your data and passwords and stuff, not the ability to install device drivers.
> yes - because back then, NAT'ing / putting a machine behind a router wasn't commonplace yet.
Back then, even putting the machine behind a firewall (which is what you really meant, since being a router does not necessarily mean it has a firewall enabled) wouldn't have been enough; it was not that uncommon to already have infected machines on the local network (because they had earlier been connected without being behind a firewall).
Back then, even putting the machine behind a firewall (which is what you really meant, since being a router does not necessarily mean it has a firewall enabled) wouldn't have been enough; it was not that uncommon to already have infected machines on the local network (because they had earlier been connected without being behind a firewall).
> The biggest help with that has been uBlock origin
It seems that browsers and extensions handle a huge part of the global security for users, maybe even more than the OSes.
It seems that browsers and extensions handle a huge part of the global security for users, maybe even more than the OSes.
That might've helped with maybe 30% of the issues, even behind firewalls and w/o UAC you also had all the early IE fault (Let's make ActiveX run x86 code from untrusted sources... facepalm) that let adversaries get an initial foothold on computers.
Regular Windows usage back around y2k was just insecure, compared to then MS has really made strides.
Regular Windows usage back around y2k was just insecure, compared to then MS has really made strides.
Windows Vista was introduced in January 2007, and was the first version of Windows to include User Account Control (UAC).
First, a bit of pedantry: UAC is not a security feature. https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94... . It just works to encourage developers to make their software work without an elevated token. The security feature is Windows administrator accounts running apps with non-elevated tokens by default.
Protecting local administrator tokens is also kind of a useless security feature these days. What are you worried about? Data theft? Ransomware? Trojans? Credentials theft? All of those can be done just fine with only standard user permissions, without an administrator token. OTOH, you need an elevated token to install device drivers or whatever.
Protecting local administrator tokens is also kind of a useless security feature these days. What are you worried about? Data theft? Ransomware? Trojans? Credentials theft? All of those can be done just fine with only standard user permissions, without an administrator token. OTOH, you need an elevated token to install device drivers or whatever.
You need an elevated token to inject code into (well written) protected applications as well, and sometimes even that might not be enough.
Generally admins tend to be most worried about central databases or user visible services being compromised. Compromising an user account is a necessary step to get there, often enough.
Generally admins tend to be most worried about central databases or user visible services being compromised. Compromising an user account is a necessary step to get there, often enough.
>Compromising an user account is a necessary step to get there, often enough.
But whether you have an elevated token or not won’t make a difference in almost all cases.
But whether you have an elevated token or not won’t make a difference in almost all cases.
Hear me out, the biggest most fundamental flaw with Windows security is the lack of an executable bit combined with icons being embedded in the executable. Making it even worse, Windows hides file extensions by default.
Executability being based entirely on filename makes it way too easy to create a .exe with the icon of a familiar file type like a Word Document. Then and unsuspecting layman who has no way of knowing it's an executable because the file extension is hidden sees no reason not to open it.
This is much less of a probably in Unix based operating systems because permissions needed for executability don't come with raw files over the network or through email, unlike extensions. Moreover icons aren't embedded in binaries, and depending on your environment, you're probably shown the file extension.
Executability being based entirely on filename makes it way too easy to create a .exe with the icon of a familiar file type like a Word Document. Then and unsuspecting layman who has no way of knowing it's an executable because the file extension is hidden sees no reason not to open it.
This is much less of a probably in Unix based operating systems because permissions needed for executability don't come with raw files over the network or through email, unlike extensions. Moreover icons aren't embedded in binaries, and depending on your environment, you're probably shown the file extension.
> create a .exe with the icon of a familiar file type like a Word Document
But this kind of confusion attack is not really used anymore.
Now it's about convincing the user to intentionally run a binary. If the user wants to run a binary, they will do it, regardless if it means double-clicking an .exe or typing "curl | sh" in the terminal.
But this kind of confusion attack is not really used anymore.
Now it's about convincing the user to intentionally run a binary. If the user wants to run a binary, they will do it, regardless if it means double-clicking an .exe or typing "curl | sh" in the terminal.
Windows really ought to just hash every executable file, and then whitelist good files.
Perhaps 1 million exe files are in widespread use in the world. Anything that isn't on that list, I don't want running on my corporate network.
Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".
Perhaps 1 million exe files are in widespread use in the world. Anything that isn't on that list, I don't want running on my corporate network.
Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".
> Perhaps 1 million exe files are in widespread use in the world.
They already do that. It's called SmartScreen.
> Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".
I don't think you thought this through. Because then malware will either call that new API, or ship with their own compiler.
They already do that. It's called SmartScreen.
> Compilers that make an exe file can have some new windows API that says "I just compiled this file, so it's fine to run".
I don't think you thought this through. Because then malware will either call that new API, or ship with their own compiler.
> Because then malware will either call that new API,
As soon as malware is running, you have already lost.
This is for when the user has downloaded TotallyNotAVirus.exe from a dodgy website and tries to double click it.
As soon as malware is running, you have already lost.
This is for when the user has downloaded TotallyNotAVirus.exe from a dodgy website and tries to double click it.
> the lack of an executable bit
NTFS does support an execute bit (Traverse Folder / Execute File). For some reason, it's just not used in any way that would provide a security benefit by default, instead basically just being set on everything.
NTFS does support an execute bit (Traverse Folder / Execute File). For some reason, it's just not used in any way that would provide a security benefit by default, instead basically just being set on everything.
A related odd quirk I ran into once: if you use an Amazon S3 Storage Gateway as an SMB share, the Execute File permission suddenly matters. I don't fully understand why, but Windows won't run an .EXE file off the share without setting that security bit. It caused us quite a bit of pain. Normally it doesn't matter at all.
Different subsystems, layers and libraries in Windows do have different interpretations of what characters to allow in a filename, what permission bits to obey, how to behave on different filesystems, etc. It's a huge mess. You can e.g. create invisible, undeleteable files by using characters the explorer doesn't like.
What's funny is when the Mac guy names a file on a network share that nobody else in the office can access or rename.
[deleted]
I think Windows has some kind of source flag, where if it’s from an online source, you have to opt-in into running it.
zone.identifier aka "Mark of the Web" and it is responsible for triggering a Smartscreen scan of that file.
You get an 'are you sure you want to run this' and also the Office Protected View, both of which users will reflexively click via muscle memory at this point.
You also get the download and referrer URL attached to every file that came from the internet which is nice for forensics stuff.
You get an 'are you sure you want to run this' and also the Office Protected View, both of which users will reflexively click via muscle memory at this point.
You also get the download and referrer URL attached to every file that came from the internet which is nice for forensics stuff.
[deleted]
It's a filesystem fork on the file triggering a UAC style warning. Laypeople are imho generally pretty blasé about accepting those.
People have been trained to ignore such popup warnings by common superfluous popup warnings like "are you sure you want to quit?", and nowadays ads and newsletter sign up bullshit.
You can set a bit like that on directories in NTFS, and clear/inherit to all child directories. Such as setting it to no-execute for all user directories except those expected to host user instances of applications.
This is at best a very basic list. Securing windows against targeted attacks are far harder than securing Linux.
For people that are interested about more advanced ways to secure Windows:
https://github.com/scipag/HardeningKitty
https://github.com/sandboxie-plus/Sandboxie
HardeningKitty is a good start but truly securing Windows is actually super complicated.
For people that are interested about more advanced ways to secure Windows:
https://github.com/scipag/HardeningKitty
https://github.com/sandboxie-plus/Sandboxie
HardeningKitty is a good start but truly securing Windows is actually super complicated.
This tool looks sharp, but why do you say "HardeningKitty is a good start." It seems to be an all-in-one solution to harden your system, and not an introduction, like my guide.
I think your guide and HardeningKitty type solutions are good for non-targeted attacks and for your average user.
Main problem is that targeted attacks are rife in the software industry. Even small startups get frequently targeted by competitors.
In order to defend against the targeted attacks you need to plug hundreds of holes in the Windows, some of these can be plugged by HardeningKitty but to truly secure it:
- You need to figure out which services you can disable without crashing the OS and keep them at a minimum. This entirely depends on how you use OS and which type of software is installed at the endpoints.
- Use stuff like Windows Application Guard, disable lolbas as much as possible (https://lolbas-project.github.io/).
- Secure the WSL itself.
- Windows opens ports according to it's own mind. Only way to unplug these open ports is to add another hardware firewall separate from the endpoint itself. So you can't even trust the inbuilt firewall of Windows.
- Windows is a very dynamic OS and each update can result in more open holes or might just automatically discard previously applied settings. Thus, you need to keep monitoring this 24/7.
- Windows registry has a very large amount of paths for malware persistence. This amount is far beyond malware persistence paths on Linux. Unfortunately, Windows Defender doesn't care much about this, so you need to monitor this yourself.
And this is just the beginning, even if you plug all this stuff, you might get attacked by zero days. Monitoring all that will also require SIEM solutions on top of it. Most of the SIEM solutions are just focused on compliance. Building a SIEM solution for real security instead of compliance is also a very hard task.
Main problem is that targeted attacks are rife in the software industry. Even small startups get frequently targeted by competitors.
In order to defend against the targeted attacks you need to plug hundreds of holes in the Windows, some of these can be plugged by HardeningKitty but to truly secure it:
- You need to figure out which services you can disable without crashing the OS and keep them at a minimum. This entirely depends on how you use OS and which type of software is installed at the endpoints.
- Use stuff like Windows Application Guard, disable lolbas as much as possible (https://lolbas-project.github.io/).
- Secure the WSL itself.
- Windows opens ports according to it's own mind. Only way to unplug these open ports is to add another hardware firewall separate from the endpoint itself. So you can't even trust the inbuilt firewall of Windows.
- Windows is a very dynamic OS and each update can result in more open holes or might just automatically discard previously applied settings. Thus, you need to keep monitoring this 24/7.
- Windows registry has a very large amount of paths for malware persistence. This amount is far beyond malware persistence paths on Linux. Unfortunately, Windows Defender doesn't care much about this, so you need to monitor this yourself.
And this is just the beginning, even if you plug all this stuff, you might get attacked by zero days. Monitoring all that will also require SIEM solutions on top of it. Most of the SIEM solutions are just focused on compliance. Building a SIEM solution for real security instead of compliance is also a very hard task.
You clearly made your point but comparing this tool with my introduction seems a bit unfair ^^.
Indeed, I was not thinking about that level of attacks. However, if individuals and organizations do not understand the minimum required to secure their instances, they can't stand a chance against advanced threat actors and skilled adversaries.
Thanks for your detailed explanations.
Indeed, I was not thinking about that level of attacks. However, if individuals and organizations do not understand the minimum required to secure their instances, they can't stand a chance against advanced threat actors and skilled adversaries.
Thanks for your detailed explanations.
> Securing windows against targeted attacks are far harder than securing Linux.
Have you got any evidence of that? Also, if you really care about security, you should consider using Qubes OS.
Have you got any evidence of that? Also, if you really care about security, you should consider using Qubes OS.
It's a bit of an unfavorable comparison, a more apt comparison would be Ubuntu/Fedora/ElementaryOS hardening vs Windows 11. The desktop versions have much larger attack surfaces than just "Linux", and it is honestly quite abysmal compared to Windows desktop, mostly because there are nobody looking for those kinds of bugs.
I'd severely doubt some key recommendations of this guide to the point where it may be useless and dangerous as a whole, because the recommendations are misleading into a false sense of security.
Applications' updates are a huge factor in the security of any endpoint, however the guide recommends application updates only for enterprise users, for normal users that recommendation is missing. But a lot of the attack surface of any system is in applications like the email client, PDF viewer, office suite, etc. While this is acknowledged by mentioning phishing, none of the recommedations mitigate that risk properly. And while the guide lauds Windows as well as MacOS (imho improperly) for their mitigations and sandboxing, it entirely skips over the extremely important field of application update management, which is properly solved by package managers and distributions in Linux. Neither Windows nor MacOS offer any builtin solution, and the guide neglects to mention any third-party solutions or services that are available.
Some recommendations like enabling "strong" password policies are, in the way Windows implements them, counter to NIST and other accepted guidelines. This leads to the usual problems of passwords on stickers on the keyboard, monthly incremented weak passwords and password reuse.
Advice on backups improperly mentions "sync to the cloud". This is not backup, because an attacker can overwrite any file that will later be synced to the cloud, making your "backup" useless. Proper backups must not be overwriteable from the machine that is to be backuped. Anything else will let your data fall prey to the usual encryption trojans without any way of recovery.
And last, not strictly an operating system problem but an environment problem: It should be mentioned that common Windows antivirus and endpoint security software is in itself a security risk. Similarly, phishing attacks are enabled by common Windows-based applications such as Outlook, MS Office and Acrobat. Avoiding those applications if possible goes a long way towards securing a Windows system.
Applications' updates are a huge factor in the security of any endpoint, however the guide recommends application updates only for enterprise users, for normal users that recommendation is missing. But a lot of the attack surface of any system is in applications like the email client, PDF viewer, office suite, etc. While this is acknowledged by mentioning phishing, none of the recommedations mitigate that risk properly. And while the guide lauds Windows as well as MacOS (imho improperly) for their mitigations and sandboxing, it entirely skips over the extremely important field of application update management, which is properly solved by package managers and distributions in Linux. Neither Windows nor MacOS offer any builtin solution, and the guide neglects to mention any third-party solutions or services that are available.
Some recommendations like enabling "strong" password policies are, in the way Windows implements them, counter to NIST and other accepted guidelines. This leads to the usual problems of passwords on stickers on the keyboard, monthly incremented weak passwords and password reuse.
Advice on backups improperly mentions "sync to the cloud". This is not backup, because an attacker can overwrite any file that will later be synced to the cloud, making your "backup" useless. Proper backups must not be overwriteable from the machine that is to be backuped. Anything else will let your data fall prey to the usual encryption trojans without any way of recovery.
And last, not strictly an operating system problem but an environment problem: It should be mentioned that common Windows antivirus and endpoint security software is in itself a security risk. Similarly, phishing attacks are enabled by common Windows-based applications such as Outlook, MS Office and Acrobat. Avoiding those applications if possible goes a long way towards securing a Windows system.
> the guide recommends application updates only for enterprise users
No. Maybe read this part https://github.com/jmau111-org/windows_security#7-recommenta...
> strong passwords [...] counter to NIST and other accepted guidelines
I don't think it's the case. Even if it is, I would disagree with that point of view.
> It should be mentioned that common Windows antivirus and endpoint security software is in itself a security risk [...] Similarly, phishing attacks are enabled by common Windows-based applications such as Outlook
Lots of confusions here, to me, but thanks for your comment overall. In fact, the guide tries to keep things simple but could certainly be improved on some points.
No. Maybe read this part https://github.com/jmau111-org/windows_security#7-recommenta...
> strong passwords [...] counter to NIST and other accepted guidelines
I don't think it's the case. Even if it is, I would disagree with that point of view.
> It should be mentioned that common Windows antivirus and endpoint security software is in itself a security risk [...] Similarly, phishing attacks are enabled by common Windows-based applications such as Outlook
Lots of confusions here, to me, but thanks for your comment overall. In fact, the guide tries to keep things simple but could certainly be improved on some points.
That part says "Keep the system up-to-date (Windows update): download and install all patches.". But Windows Update doesn't update any applications for third parties and not even all Microsoft applications. So the recommendations for individuals are problematic as described. Only the section for "admins (businesses, organizations)" mentioning "e.g. Windows Server" mentions application updates.
erf, that's what I mean by "download and install all patches," but I'll try to write that better if it's confusing.
I'd suggest something like "Keep the system and applications up to date. Install all patches from Windows Update immediately and preferrably automatically. Use applications' automatic updates or package managers such as chocolatey.
> It shifts the responsibility to the end-users, exposing beginners and non-technical users to various risks, especially if you install alternative distros.
Thank you! I've been saying that for ages. It's very easy to get hacked on Linux. It's my personal main daily driver but I am fully aware that evem after taking a lot of measures to lock things down, there is probably someone who knows the system better than me who can identify a weak config or exposure and exploit it. Even when doing offensive labs, Linux privesc is always easier for me.
That said, I would like to disagree with the author about windows not being able to prevent users from installing appications or that being the leading cause of a compromise. The leading cause is users running code (scripts,documents,,etc...) which the directly or after a download stage run the attacker's code. WDAC and JEA can prevent any new scripts or apps from running. Some just allow an approved list of signed apps and scripts. There is no easy way to do this in Linux. Can't sign scripts and elf signing hasn't taken off but at least module signing with secureboot is there (I use it).
Thank you! I've been saying that for ages. It's very easy to get hacked on Linux. It's my personal main daily driver but I am fully aware that evem after taking a lot of measures to lock things down, there is probably someone who knows the system better than me who can identify a weak config or exposure and exploit it. Even when doing offensive labs, Linux privesc is always easier for me.
That said, I would like to disagree with the author about windows not being able to prevent users from installing appications or that being the leading cause of a compromise. The leading cause is users running code (scripts,documents,,etc...) which the directly or after a download stage run the attacker's code. WDAC and JEA can prevent any new scripts or apps from running. Some just allow an approved list of signed apps and scripts. There is no easy way to do this in Linux. Can't sign scripts and elf signing hasn't taken off but at least module signing with secureboot is there (I use it).
While it's true, such scripts usually install crap using the victim's privileges behind the scene.
Which scripts? Malicious scripts...yeah. But you can stop using wscript,mshta,bat,etc... and only allow powershell signed scripts with JEA restriction.
indeed, but the point was this malicious scripts usually try to install programs, like droppers.
Running and installing are different things. A popular dropper I frequently run into for example never drops an executable to disk, it loads base64 from registry, decodes/decrypts it and reflectively executes the .NET assembly which in turn decodes and executes shell code from registry.
Windows has a lot of legacy code, it is backwards compatible and has many more installs on-prem than Linux or MacOS. Thus, there is a larger incentive to find exploits. Look at Android, a Linux kernel based OS that has as much malicious code running on it as Windows, if not more. It is harder to secure it than it is windows.
Microsoft's refusal to deprecate old APIs is definitely a reason for many of their security problems. However, the old theory that "windows has a bigger install base, therefore it's a bigger target" seems logical but is disproven with several other popular examples- Apache vs. IIS was a common counter-argument in the early 2000s.
I've worked at companies with 100s of thousands of Linux servers, and only 10s of thousands of Windows desktops and servers. The quantity of security problems these companies had with their Windows systems compared to their Linux systems was astounding.
I've worked at companies with 100s of thousands of Linux servers, and only 10s of thousands of Windows desktops and servers. The quantity of security problems these companies had with their Windows systems compared to their Linux systems was astounding.
I don't think you can compare metrics of Linux servers against Windows Servers AND Desktops.
At least on Windows Desktops I'd say most of security incidents today are initiated by the end-user in front of that Desktop, which creates an entirely different attack-surface than a unattended server maintained by someone working almost always in the field of IT.
At least on Windows Desktops I'd say most of security incidents today are initiated by the end-user in front of that Desktop, which creates an entirely different attack-surface than a unattended server maintained by someone working almost always in the field of IT.
> At least on Windows Desktops I'd say most of security incidents today are initiated by the end-user in front of that Desktop
To install programs on my work PC i need admin account. Except for (rolling drums) Teams.
To install programs on my work PC i need admin account. Except for (rolling drums) Teams.
You need an admin account to install programs for "all users" odds are the teams install (and others) are local-account installs. Not that it's much better. You can disable execution on user profiles from the directory level.
Have you looked into using scoop? It installs everything into the user profile and won’t require elevation.
I've tried to analyze the situation with objective arguments, but it seems to make me appear as a Windows/Microsoft advocate or fan boy, which is a bit ironic.
Many security news worried about actively exploited 0-days, but many of these vulnerabilities are addressed or mitigated. It's not perfect at all but talented people have budgets to work on it.
I wonder if the figures you mentioned are that relevant. Cybercriminals usually attack juicy flaws, and windows systems might be more attractive.
Many security news worried about actively exploited 0-days, but many of these vulnerabilities are addressed or mitigated. It's not perfect at all but talented people have budgets to work on it.
I wonder if the figures you mentioned are that relevant. Cybercriminals usually attack juicy flaws, and windows systems might be more attractive.
>The quantity of security problems these companies had with their Windows systems compared to their Linux systems was astounding.
In which direction?
In which direction?
Additionally, you have the value perspective. Get into a Windows machine and you might get some info about a person. Break into a Linux server and you might get an entire DB.
The article fails to demonstrate why Linux is less secure than Windows.
This is not what I mean actually. Windows simplifies some procedures, which can be beneficial for most users. I'm a big Linux fan boy, but it's easy to mess up your config and get a false impression of security, especially with some distros.
To add examples: i have seen bad posture from otherwise good systems, e.g.:
- not having MAC (apparmor or, preferably, SELinux) implemented
- not managing user permissions per least permissions principle
- not restricting access to bashrc
- not using Wayland opportunistically for a key app, e.g. emacs
- not LVM encrypting during the initial install
- not enabling memory and CPU protections in kernel (Ubuntu, Fedora, etc get most of this right ootb)
There are more examples, and I'm not a security professional, but it's enough to give the flavour of the kinds of problems in defensive Linux security.
- not managing user permissions per least permissions principle
- not restricting access to bashrc
- not using Wayland opportunistically for a key app, e.g. emacs
- not LVM encrypting during the initial install
- not enabling memory and CPU protections in kernel (Ubuntu, Fedora, etc get most of this right ootb)
There are more examples, and I'm not a security professional, but it's enough to give the flavour of the kinds of problems in defensive Linux security.
Not to mention kernel exploits, local privesc, unmaintained or abandoned distros, and many other issues.
I've seen so many people relying on the OS and thinking themselves as power users just by using it with default settings. I think it's a mistake, hence my comparison.
Attacking a secured Windows system is not at everybody's reach. Doesn't mean it can't be done, but it's something I don't like to read in security news, like finding and exploiting 0days will be easy for attackers.
It's not and can take some time. There's even a huge market for initial access. In contrast, exploiting a vulnerable Linux system (e.g., unpatched) is documented everywhere.
I've seen so many people relying on the OS and thinking themselves as power users just by using it with default settings. I think it's a mistake, hence my comparison.
Attacking a secured Windows system is not at everybody's reach. Doesn't mean it can't be done, but it's something I don't like to read in security news, like finding and exploiting 0days will be easy for attackers.
It's not and can take some time. There's even a huge market for initial access. In contrast, exploiting a vulnerable Linux system (e.g., unpatched) is documented everywhere.
Would you say kernel and privesc are worse or better on Linux? All else being "correct" I always had the feeling that this was handled well on mainline distros (Fedora, Ubuntu, Debian, OpenSuse) and some BSD distros (OpenBSD), maybe even better than Windows depending on what you're looking at.
To me, the comparison does not make sense and was definitely not my intention when I mentioned Linux in the guide.
It's just that privesc and kernel exploits is possible under some conditions on Linux.
It's just that privesc and kernel exploits is possible under some conditions on Linux.
It also really fails to provide practical solutions to the recommendations. Like the recommendation "monitor registry editing". There is nothing describing a tool or method to do anything like this. And I feel like the entire article follows that pattern.
From my experience, this is literally par for the course - describe a mitigation without actually providing any useful advice whatsoever.
From my experience, this is literally par for the course - describe a mitigation without actually providing any useful advice whatsoever.
Thoughts on Windows Security, misknown mitigations, and solutions to keep the system safe.
> Connecting with Microsoft accounts is only useful to enable Windows Hello. Otherwise, use local accounts only.
I have a Surface Pro 4 with Windows 10 and a local-only account, and I log in with Windows Hello. Is that unusual or deprecated in Windows 11 or something?
I have a Surface Pro 4 with Windows 10 and a local-only account, and I log in with Windows Hello. Is that unusual or deprecated in Windows 11 or something?
Do you use a security key?
It seems like you need a Microsoft Account otherwise.
https://support.microsoft.com/en-us/windows/sign-in-to-your-...
It seems like you need a Microsoft Account otherwise.
https://support.microsoft.com/en-us/windows/sign-in-to-your-...
For Windows 10 that’s absolutely not the case, you can use any Windows Hello method you want with a local account. Most of that article is talking about security keys because they are more involved than Hello.
No security key, just my face. That link also seems to say it can be used without an online account. Hence my question.
> A big caveat is that many people will attempt to bypass system requirements, trying to upgrade old machines to Windows 11, which is a very bad move, as it's not meant for that by definition, and you may lose both the security benefits and the usability (e.g., hardware performances). Many advanced security features, like VBS are available on Windows 10 too.
Is that right? I can believe forcing an upgrade to 11 on unsupported hardware will prevent some features from working... but does that make 11 worse than 10? How?
Is that right? I can believe forcing an upgrade to 11 on unsupported hardware will prevent some features from working... but does that make 11 worse than 10? How?
Users have reported various performance issues. It does not make 11 worse than 10. It's more secure to keep windows 10 if your hardware is too old.
I'm asking about security, not performance or anything else. How does 11 make old hardware less secure than 10, assuming it's only new features that cannot work?
Performance is important, as you don't want to have a dysfunctional system, but, typically, you have to disable important security mechanisms to force the install.
You lose on both sides.
You lose on both sides.
Do you lose any security benefits (of Windows 10) by updating your system to Windows 11, or just "new" Windows 11 security mechanisms?
The same security mechanisms are available in new Windows 10 builds, but it does not enable them automatically because of said ancient machines.
In particular certain security issue mitigations are terrible performance on older CPUs (think easily up to 20% performance loss). If your machine is ancient enough, it won't even get Core Security.
In particular certain security issue mitigations are terrible performance on older CPUs (think easily up to 20% performance loss). If your machine is ancient enough, it won't even get Core Security.
Just Windows Defender alone has had a couple exploits the last years just by scanning files. It scans and evaluates files withe highest privilidges
No mention of AppLocker and SRP surprised me. Aren't they effective anymore?
Nope. It's not a statement, it's just not in the guide.
The more time I spend in windowsland the more I am convinced that allowing spaces in file/directory names is a mistake.
guys pls put your paths in quotes. all of them all the time.
guys pls put your paths in quotes. all of them all the time.
Windows did it (“Program Files”, “Documents and Settings”, etc) specifically because they wanted typical developers to be forced to deal with it.
A typical user who is not a developer and has no idea about the semantics around quoting for shell arguments, etc, should absolutely be allowed to put spaces in their filenames. Imagine telling your grandma that she can’t call her word document “Cookie Recipe”… Heck, macOS allows slashes in filenames (at least in Finder… although they turn into `:`s in the actual filesystem), because a lot of people type dates into their document names, using e.g. `1/11/23` notation.
Putting spaces the system directories made it more likely that developers would find these bugs sooner, which IMO isn’t an entirely bad idea.
A typical user who is not a developer and has no idea about the semantics around quoting for shell arguments, etc, should absolutely be allowed to put spaces in their filenames. Imagine telling your grandma that she can’t call her word document “Cookie Recipe”… Heck, macOS allows slashes in filenames (at least in Finder… although they turn into `:`s in the actual filesystem), because a lot of people type dates into their document names, using e.g. `1/11/23` notation.
Putting spaces the system directories made it more likely that developers would find these bugs sooner, which IMO isn’t an entirely bad idea.
It should force devs to do that, but at some point the service runner got some smarts put into it and you do not need to quote the path to your service's executable. You can drop your own exe at the substring location and leverage it for persistence or privilege escalation to SYSTEM if that location happened to be writable for non-admins.
> Windows did it (“Program Files”, “Documents and Settings”, etc)
And then reverted back. “Documents and Settings” now links to "Users", and new directories were given names like "ProgramData". or "WindowsApps".
And then reverted back. “Documents and Settings” now links to "Users", and new directories were given names like "ProgramData". or "WindowsApps".
Correct, although “Program Files” and “Program Files (x86)” are still primary paths IIRC. (“Documents and Settings” is an alias to “Users” now, but I don’t think they did a similar thing to “Program Files”, although I could be wrong, I don’t have a windows system handy.)
You're correct. And they didn't "revert", as GP is saying, but rather added junction points such that "C:\Documents and Settings\All Users\Application Data" is the same as C:\ProgramData, and that junction point was, at least based on my contacts at Microsoft at the time, more added because Microsoft devs were getting annoyed trying to `cd` there than anything else (i.e., explicitly not a repudiation of forcing devs to deal with spaces). The fact it was introduced only in Windows Vista, after everyone'd been forced to deal with it, was intentional.
Arguably they didn't force anything on developers, I wrote scripts for work for a good while and could use PROGRA~1 or DOCUME~1 to access the files in personal folders since the spaces gave me a headache and I switched between my computer (English locale) and work's computer (Spanish locale), this little word hit both computers.
These are the responsible party for like 90% of pentest reports that I have personally seen.
Also while I am soapboxing I just wanna say that nearly all corporate security issues are actually just operations issues, like patch management and config management. Everything I listed above can be solved by a single sysadmin with group policy and 30 minutes to kill, and they wont reoccur.
In the sysadmin sphere there is a tendancy to treat security concerns as their own industry. You don't need your kitchen staff to be microbiologists to know that they should wash their hands and you don't need your sysadmin to be a CISSP to know to disable protocols that you arent using. Just IMO as a consultant who straddles the fence.