Windows OS Security
github.com
github.com
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.
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.
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.
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.
Caedite eos. Novit enim Dominus qui sunt eius.
Even smbv2 is often only enabled because not-so-old printer don't support anything more recent.
In recent years they have been switching over from self service checklist audits to full spectrum pentest assessments and finding a lot of bugbears.
Good point. I tried to highlight that (not relying on default policies).
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.
yes - because back then, NAT'ing / putting a machine behind a router wasn't commonplace yet.
UAC forced developers to make the software work no matter what.
So you can throw the best security at users for free. Some dud will disable it because his powershell script is not working anymore.
This obsession with not running as root/using UAC is just cargo cult security for single user systems.
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.
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.
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).
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.
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 developers were and are already doing app distribution. 30% for something dev's were already doing...
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.
Regular Windows usage back around y2k was just insecure, compared to then MS has really made strides.
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.
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.
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.
But whether you have an elevated token or not won’t make a difference in almost all cases.
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.
It seems that browsers and extensions handle a huge part of the global security for users, maybe even more than the OSes.
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.
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.
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.
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".
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.
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.
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.
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.
Have you got any evidence of that? Also, if you really care about security, you should consider using Qubes OS.
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.
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.
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.
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.
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).
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.
In which direction?
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.
To install programs on my work PC i need admin account. Except for (rolling drums) Teams.
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.
- 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.
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.
It's just that privesc and kernel exploits is possible under some conditions on Linux.
From my experience, this is literally par for the course - describe a mitigation without actually providing any useful advice whatsoever.
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?
It seems like you need a Microsoft Account otherwise.
https://support.microsoft.com/en-us/windows/sign-in-to-your-...
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?
You lose on both sides.
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.
guys pls put your paths in quotes. all of them all the time.
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.
And then reverted back. “Documents and Settings” now links to "Users", and new directories were given names like "ProgramData". or "WindowsApps".