Kinda wish legacy protocols made an appearance. plaintext ldap, unsigned SMB, SMBv1 still being enabled somehow, DHCPv6 poisoning, llmnr, netbios, kerberoast.
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.
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.
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.
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.
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.
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.
> 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 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.
>> 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.
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.
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.
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.
> 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).
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.
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.
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.
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.
> 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.
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.
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 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 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.
- 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.
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.
> 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.
> 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).
Which scripts? Malicious scripts...yeah. But you can stop using wscript,mshta,bat,etc... and only allow powershell signed scripts with JEA restriction.
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 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.
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.
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.
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.
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.
Readit News
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.
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.
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.
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.
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.
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.
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.
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).
It seems that browsers and extensions handle a huge part of the global security for users, maybe even more than the OSes.
Regular Windows usage back around y2k was just insecure, compared to then MS has really made strides.
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.
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.
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".
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.
Deleted Comment
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 Comment
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.
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.
Have you got any evidence of that? Also, if you really care about security, you should consider using Qubes OS.
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.
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.
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.
In which direction?
- 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.
From my experience, this is literally par for the course - describe a mitigation without actually providing any useful advice whatsoever.
Dead Comment