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.
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.
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.
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'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.
> 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).
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.
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.
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.
Maybe it is a good safety measure, but there is nothing more annoying than asking users to renew passwords and blocking access to windows components... I wonder if the benifits justify the drawbacks...
> 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?
> 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?
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.
[+] [-] jabroni_salad|3 years ago|reply
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.
[+] [-] rejectfinite|3 years ago|reply
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.
[+] [-] nolok|3 years ago|reply
Even smbv2 is often only enabled because not-so-old printer don't support anything more recent.
[+] [-] jmau111|3 years ago|reply
Good point. I tried to highlight that (not relying on default policies).
[+] [-] joenathanone|3 years ago|reply
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.
[+] [-] agloeregrets|3 years ago|reply
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.
[+] [-] alexvoda|3 years ago|reply
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.
[+] [-] donatj|3 years ago|reply
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.
[+] [-] 323|3 years ago|reply
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.
[+] [-] josephcsible|3 years ago|reply
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.
[+] [-] Semaphor|3 years ago|reply
[+] [-] tracker1|3 years ago|reply
[+] [-] DethNinja|3 years ago|reply
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.
[+] [-] jmau111|3 years ago|reply
[+] [-] fsflover|3 years ago|reply
Have you got any evidence of that? Also, if you really care about security, you should consider using Qubes OS.
[+] [-] cirthaya|3 years ago|reply
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.
[+] [-] jmau111|3 years ago|reply
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.
[+] [-] badrabbit|3 years ago|reply
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).
[+] [-] jmau111|3 years ago|reply
[+] [-] sirjaz|3 years ago|reply
[+] [-] whydid|3 years ago|reply
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.
[+] [-] claudiojulio|3 years ago|reply
[+] [-] jmau111|3 years ago|reply
[+] [-] sixothree|3 years ago|reply
From my experience, this is literally par for the course - describe a mitigation without actually providing any useful advice whatsoever.
[+] [-] microtheo|3 years ago|reply
[+] [-] jmau111|3 years ago|reply
[+] [-] jmau111|3 years ago|reply
[+] [-] britneybitch|3 years ago|reply
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?
[+] [-] neogodless|3 years ago|reply
It seems like you need a Microsoft Account otherwise.
https://support.microsoft.com/en-us/windows/sign-in-to-your-...
[+] [-] jmmv|3 years ago|reply
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?
[+] [-] jmau111|3 years ago|reply
[+] [-] ikekkdcjkfke|3 years ago|reply
[+] [-] ComodoHacker|3 years ago|reply
[+] [-] jmau111|3 years ago|reply
[+] [-] jabroni_salad|3 years ago|reply
guys pls put your paths in quotes. all of them all the time.
[+] [-] ninkendo|3 years ago|reply
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.
[+] [-] konradx|3 years ago|reply
[+] [-] nikanj|3 years ago|reply
[+] [-] jmau111|3 years ago|reply