Another recent case: https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
How can Windows, which is used all over the government, have a policy that admin users can do whatever they want with the kernel without it being a security vulnerability?
As for groups, Windows has a variety of groups with a range of permissions (both local and over network shares). On home installs, the default user will have all of the permissions, kind of like on how most Linux installs have a single sudo/wheel user. Every kernel object has a different ACL that can be altered down to the user level. Furthermore, Windows differentiates between various permission levels ("browser content rendering process" vs "normal process" vs "admin process"), doing things like preventing keystroke insertion into higher privileged processes running under the same user account.
In office/corporate environments, the person interacting with the computer never gets admin permissions at all, so the admin/kernel boundary isn't relevant until a privilege escalation exploit is involved. Even IT administrators should almost never use real admin accounts; almost everything from changing passwords to reconfiguring permissions and settings can be done with assigning users to lower privilege groups or the right ACLs, not entirely unlike how Linux capabilities can be used to grant relatively low-power users permissions that normally only root can use.
Windows's security problem isn't unlike Linux's: it can be locked down securely, but you'll break tons of applications and you'll need to read through tons of obscure documentation before you can pull it off. Out-of-the-box Windows has a lot of security features that Linux lacks, but when it comes to unmanaged home computers owned and used by normal people, neither has any real protection boundary preventing kernel access in practice.