Senator blasts Microsoft for 'dangerous, insecure software' that helped pwn US hospitals Microsoft is back in the firing line after US Senator Ron Wyden accused Redmond of shipping "dangerous, insecure software" that helped cybercrooks cripple one of America's largest hospital networks. Cartoonish composition of a crook shrugging in front of the Microsoft Office icons Microsoft rewarded for security failures with …
It’s incredible that it has taken until the 2020’s for some people in governments around the world to finally wake up to the fact that MS software is utterly shite. And most businesses STILL don’t seem to think anything of it
Human stupidity really has no limit
As Micros~1 set 34.000 full time engineers to work on the Secure Future Initiative back in Sep 2024 Senator Wyden will surely praise them for the great results that Micros~1 will publish any moment now.
Is that thirty four thousand or thirty four point zero to three decimal places?
I always find it mildly concerning that some locales use a decimal point as the thousands separator ;-) It must cause some pretty spectacular mistakes between countries.
If you read deeper into the topic, you will find that Microsoft has been reluctant to depreciate RC4 because doing so 'outright' will break systems immediately after said update if they aren't properly configured. Ars seems to state (erroneously) that AES is default for AD authentication
https://arstechnica.com/security/2025/09/senator-blasts-microsoft-for-making-default-windows-vulnerable-to-kerberoasting/
but it seems that you must turn on AES authentication support options. So, without defending MS, they are placing backward compatibility first, lest older or misconfigured systems break. This has been acknowledged by MS and a quick search shows that they have addressed this topic for a while now:
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965
So, from here, it seems that MS is stuck (as they often are) in a "Damned if you do, Damned if you don't" scenario: if they fully depreciate RS4 on AS then unknown systems will break but you'll get better security, if they keep RS4 for compatibility then their systems are vulnerable and they are cursed out for doing so (but this is due to RS4 weakness, not an inherent flaw in MS's implementation of same).
I am not sure how to solve this inherent dilemma; I guess they could push out an update to force RS4 to be disabled but then pop-up an admin dialog to not only warn of this but give the admin a chance to manually override the update, taking responsibility for doing it. Even doing a voluntary patch will allow some admins to block said update, only to blame MS if/when they are Kerberoasted some time in the future. Again, Damned if you do / Damned if you don't.
That's easy to say, but practically impossible to do.
Unless you accept that Government takes a decade to to redo all of its tools in Linux.
Which I would personnaly like, but I'm not concerned here.
In any case, this is a gold-plated arrow against Redmond and I hope that some good will come of it.
Even if there was a viable alternative OS that supported pretty much the same set of applications (which isn't the case with Windows vs Mac/Linux but for example would be the case with Android vs iOS) the cost of switching - even if they could use the same PCs/servers - in terms of licensing, training, and just general chaos would be insane. No doubt there would be some deaths that could be directly tied to the switchover - someone's reinstalled PC doesn't work right, some application not configured correctly, whatever causing something critical to be missed.
I think this begs for tighter integration with Copoolot. Hackers would think twice if suddenly they heard "Watcha doing here, comrade? Are you trying to hack this system?"
Basically, Microshaft needs to double down on adding more AI and push developers to adopt more secure vibes. Even telling them to add "Pls make it secure, this time for real." at the end of the prompts would substantially increase security of the products. When developers finally return to offices, they could employ chaperones doing vibe checks, to ensure right prompts are always used.
I'd say its still another old fuck who doesn't understand tech. We all like Linux but if you don't have the funding and knowledge someone will get in. We don't want MS to lock down like Apple otherwise we're stuck using their shitty app store. I dislike Apple massively due to its walled garden. The TPM chip came about due to MS claiming it would make systems more secure when in fact it just benefited MS, abusing it now with the Windows 11 requirement requiring it.
I'd rather have a locked down desktop a la MacOS with a UI that has remained fairly consistent over the years and far better security than the shoddy crud that is Windows.
Let's face it, the only thing Windows is good at is gaming, which gives you an idea of Microsoft's focus.
Windows is sold because companies keep OPEX and CAPEX budgets separate, encouraged by MS. If you were to take OPEX into account when costing out solutions, MS would not even get a look in due to the vast amount of manhours wasted on keeping it alive, the constant interruptions for updates and a time wasting UX that they then keep changing so people have to keep hunting where the functionality is they need. Add to that the extremely wasteful use of resources, and it's a set of products that can only be sold through lobbying of decisionmakers who don't have a clue.
That's why many private banks (and IBM) switched to MacOS for desktops. Safer, simpler and effectively cheaper if you start adding it all up.
This post has been deleted by its author
Yeah MS is not secure by default but lets be honest customers don't want it.
Plus if the customers actually cared about being secure they could have taken steps to mitigate all these issues. But they don't.
When CEOs are looking at jail time for supplying junk, or installing junk THEN it'll get taken seriously. Until then the fine is just another expense. And usually an acceptable one.
It doesn't need CEO jail time, Insurance audit questions similar to the ones that are asking "Do you use Exchange On-Premise" make a difference to IT directors and Finance directors.
I'm not sure that it's accurate to say customers don't want a secure by default windows. Microsoft claim this of Windows 11 in places...
https://www.microsoft.com/insidetrack/blog/hardware-backed-windows-11-empowers-microsoft-with-secure-by-default-baseline/
But in actuality, for a few quid, windows 11 with the usual trash apps, unnecessarily large attack surface by default, weak protections between what could be "system", "user", "app", "browser session data" partitions in files and memory.
The windows 11 setup asks enough dumb questions about what type of apps the user wants to use.
Why not have a "New install which implements M365 Compliance Manager choices", the hundreds of entries that are listed in M365 Compliance Manager, but require E3 licenses to use get access to a nice implementation UI?
The majority avoid want complex and expensive add ons that cause a new set of problems.
e.g. mac, linux configured on Azure active directory, or on-prem AD, with minimal guidance and tooling.
When CEOs are looking at jail time for supplying junk, or installing junk THEN it'll get taken seriously.
Funnily, that's exactly what some implementations of NIS2 and DORA legislation are doing. For instance, the way the German government has implemented it up has caused a massive panic in their financial world as it introduced personal responsibility - no more hiding behind corporate constructions. It was very amusing to watch that one land :)
Yes was going to mention the NIS2 and exactly that element. It'll be interesting to watch over the next few years if there are prosecutions and if the overall level of security increases.
I think it'll take a while, a bit like with Health and Safety where the instances of bosses being dragged to court for failings are rare but they do happen and subsequently H&S is generally taken very seriously
“The Comes v. Microsoft Corp. class-action lawsuit, filed in Iowa in 2000, alleged that Microsoft unlawfully monopolized the markets for Intel-compatible PC operating systems and software, resulting in higher prices for consumers. After extensive litigation, including appeals to the Iowa Supreme Court affirming that indirect purchasers could sue, the parties reached a settlement in 2007 valued at approximately $180 million.”
“The case involved massive document discovery efforts, with Microsoft producing over 25 million pages of documents. Paper documents were required to be destroyed or returned under court orders, leaving digital records as the primary archive. The litigation was notable for its scale, the affirmation of consumers’ rights under Iowa competition law, and the significant settlement that followed after a protracted trial process.”
$180 Million Microsoft Iowa Antitrust Settlement Results in Cash Benefits to Consumers
What's surprising is that AFAIK Iowa was the only state to do that. Why wasn't it like the tobacco lawsuits where many and eventually all states took part? Other than maybe Washington I can't think of any reason why other states wouldn't have filed similar lawsuits. But they didn't. Makes you wonder how large of bribes Microsoft lobbyists were tossing around to state AGs to tamp that down.
“Wyden's call for an FTC investigation is an attempt to force accountability. He wants regulators to compel Microsoft to ship secure defaults, deliver the long-delayed RC4 update,”
RC4 shouldn’t be default. But if the default is changed, there will be a lót of admins that change it back if it’s still available, because of legacy stuff. It took us a decade to even get rid of Win7, and I still have an XP running somewhere. Firewalled, no Internet access, separate VLAN. And hopefully gone before the end of the year.
MS should definitely take a lot of the blame here. But the (large) organisation that used defaults is not without blame either.
Agreed. While Microsoft can and should be held accountable for insecure software, many businesses also have a chain of dependencies which make them vulnerable. At $ork[-2], we had a core application which was vital to the business. Management had made the decision not to upgrade for many years, and the application was falling further and further behind on versions of Tomcat, Struts, etc., as well as being limited in which versions of TLS it could support. Upgrading would have been a major expense in terms of business user, professional services, and development time, and it was judged to be high risk, as well. For as long as I was there, the upgrade therefore never happened, but that application and many others were begging for some sort of compromise.
Honestly, this does seem like an area where agentic AI could be of value, figuring out a dependency tree and action plan to get legacy systems upgraded and then performing those actions in a test environment to see what breaks.
Yeah, we have some legacy here with Java 9 components. Why? Because backwards compatibility between Java versions was apparently considered, well, backwards.
We're thankfully phasing this out, but after discovering this I'm hoping to put at least a decent moat around the whole thing so it doesn't become a petri dish for anything that makes it past the front door, and we use *way* too much Microsoft for that not to be a real risk.
Step 1: Ignore security by design.
Step 2: Release critical patches, keep everyone scared.
Step 3: Shorten the lifecycle. Release new versions and quickly drop general support for the old version.
Step 4: Charge money for extended security fix support because it takes customers too long to upgrade.
Here is what MIT (source of the reference implementation) has to say:
Version 5 of Kerberos, however, does not predetermine the number or type of encryption methodologies supported. It is the task of each specific implementation to support and best negotiate the various types of encryption. However, this flexibility and expandability of the protocol has accentuated interoperability problems between the various implementations of Kerberos 5. In order for clients and application and authentication servers using different implementations to interoperate, they must have at least one encryption type in common. The difficulty related to the interoperability between Unix implementations of Kerberos 5 and the one present in the Active Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a limited number of encryptions and only had DES at 56 bits in common with Unix. This required keeping the latter enabled, despite the risks being well known, if interoperability had to be guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is also present in Windows and is more secure than DES
I'm old enough to remember that MS has faced a lot of criticism for not maintaining compatibility with unix servers that support only a limited number of older security protocols and common encryption types.
In detail it is RC4-HMAC, so it is not as insecure as he claims, why why still used??? But on everything else he is right.
New Server 2025 AD, and we still have no default policy to only allow AES128/AES256 hashes and deny everything older. Has to be set manually via GPO.
Upon account creation, no matter whether user or computer, none have the checkmarks at "can do AES128" and "can do AES256". I've asked and there is no template or similar to adjust that new accounts do have those two options set, so far no answer, or "no". So for important accounts, like domain admin, I create it, set that mark, set the password again and check the AD attribute whether it REALLY is using AES256, 'cause else it will use the old RC4-HMAC instead of the GPO dictating higher encryption until the next regular password change. The "solution" to use a manually created template account to copy from does not work in way too many scenarios.
And I create on most ADs in my hands, a script-task which check all account for that AES256 option, and if not set the way I want I set that mark and disable all older hashes for that account, so after a while most of them are AES256. (Yeah, but what about service accounts and so on? Yeah, damn right!)
And we have AES256 SINCE WINDOWS VISTA !!!! Nearly 20 years... With the AD-schema update to 2016, about nine years ago, they should have changed those defaults.
Same for the default security settings on a lot of OUs. One tiny tiny thing they did improve: Only a domain admin can check whether the guest account is activated or not. Without you get the answer "0" if you query "userAccountControl", which you may not be allowed to read, which means the deactivated bit cannot be checked, and therefore say "account is active, insecure!!!" (pointing to Microsoft Sentinel or the other security check tool which fails on that specific point).
Oh, and I just remembered: DES is still a valid allowed PW hash if you don't deny it in the AD. Quite a few storage solutions (Including netapp) still use, by default, DES for their computer account in the AD unless you specify it in the shell that it should use AES256. Most of them, luckily, update their computer-account PW straight away and we can check instantly whether it worked instead of waiting for 30 days...
For Microsoft, "backwards compatibility" is literally THE thing that keeps Windows in the dominant market position it is in.
WIthout that, the platform would be vulnerable to - SHOCK - competitors impinging on its formidable grip on the desktop computing industry.
So I suspect that is actually "Job #1" at Microsoft.
Which is also why there is little to no significant OS innovation any more on any of the entrenched major OS platforms: as "mass consumer products" these days, any major architectural changes would be like swapping the places of the brake and accelerator pedals in a motor vehicle: the masses would revolt and the platform vendors would have to immediately switch them back.
The Senator is an idiot and so is the author of this article!
"Microsoft continues to use RC4 as its default encryption algorithm"
Browsers and Azure: Microsoft completely removed RC4 support from its modern web browsers (Microsoft Edge and Internet Explorer 11) in 2016. The company also removed it from Azure services in 2016.
So, how can this be blamed on RC4, it cannot! Now if the contractor was using an old, unsupported Windows version with Internet Explorer How the hell is that MS fault!
Which is probably most likely the case! Yes, browsers are not safe! Windows PC that are not secured properly are dangerous in the hands of morons!
But seriously, how does an infected contractor PC disable an entire organization? It does it by the organization's network, computers, and systems being insecure! By having certain users with credential owning the "keys to the kingdom!"
MS Still supports RC4 in Active Directory, the problem is in many organizations, many things will break if you disable it! There are certain large enterprise applications (who will rename nameless) that will cease to function if you shut this off. Just like if you require LDAPS!
> So, how can this be blamed on RC4, it cannot! Now if the contractor was using an old, unsupported Windows version with Internet Explorer How the hell is that MS fault!
How, THE HELL, did you not check which hash your AD accounts, even on a fresh set up Server 2025 AD, use? And activate the kerberos ticketing audit options, check the logs which hash they use. You would be surprised, 'cause it is RC4_HMAC.
Check dis! So, you think you’re ready for enforcing AES for Kerberos? THOUGH I recommend checking for events with TicketEncryptionType = 0x1 or 0x3 or 0x17 or 0x18, else you might miss the accounts which use DES/3DES...
And dis! ecrypting the Selection of Supported Kerberos Encryption Types
and a few more "dis"...
> Microsoft completely removed RC4 support from its modern web browsers
Yeah, 'cause MS does not use pure RC4, never did in AD, it is RC4_HMAC as per kerberos standard from over two decades ago. Does it make it better? Hell no! But you mix a few things which SEEM like they are the same, but they are not. RC4_HMAC is still considered secure in some way, but it is TIME to push that out.
> But seriously, how does an infected contractor PC disable an entire organization?
You don't read TheRegister, hm? A lot of security incidents start that way.
> MS Still supports RC4 in Active Directory, the problem is in many organizations, many things will break if you disable it!
No, disable RC4_HMAC does not break many things. I started automatically force-correct the account options to AES256 on every account several month ago on serveral bigger ADs, and once the logs calmed down (i.e. new PCs were set for alle users/computer since they time out) you can "deny RC4" even on old long running ADs. For fresh ADs you deny it right away, which is sadly not the default setting.
This news from the senator does not change what I do, but it helps a lot to get customers moving, with "what, a politician? THIS politician?" as argument how important that part is.
