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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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).
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.
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.
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.
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 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.
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.
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.
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).
Which scripts? Malicious scripts...yeah. But you can stop using wscript,mshta,bat,etc... and only allow powershell signed scripts with JEA restriction.
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 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.
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.
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.
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.
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.
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?
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.
> 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?
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.
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.
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.
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.
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.