Can confirm. Matching decompilation in particular (where you match the compiler along with your guess at source, compile, then compare assembly, repeating if it doesn't match) is very token-intensive, but it's now very viable: https://news.ycombinator.com/item?id=46080498
Of course LLMs see a lot more source-assembly pairs than even skilled reverse engineers, so this makes sense. Any area where you can get unlimited training data is one we expect to see top-tier performance from LLMs.
I absolutely agree that Microsoft could do better, but they are making progress in removing support entirely for broken (from a security perspective) older protocols such as NTLMv1 (which uses DES as well: more here -- https://bit.ly/crackingntlmv1) and SMB1.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
KeySavvy is the normal workaround for this. $99 extra cost to both sides for them to handle the title verification and shipping, and to act as the dealer to make it qualify for EV credits.
We don't advance as a society unless people ask new questions. Having folk willing to spend some time answering those questions (in public, no less!) helps others. It's really, really damn hard to predict how advancements in one area can help another.
All that said, thanks for your interesting new question, and thanks for spending time on it :D
Title needs a small fix, it should be `ping ff02::1` (with two colons) to be a valid IPv6 address, match the actual command, and match the original title.
FWIW I've heard the term "dark fiber" used in both ways as well. Whenever there's ambiguity in jargon, I just avoid that jargon and use more words to describe the actual concept.
That helps with "we've encrypted your data; pay us for the key" but doesn't help you with "we've made copies of your patient records, leadership's emails; pay us or we publish it all".
The phrase to describe this is double extortion.
As for your question, https://www.cisa.gov/stopransomware is a decent start, but it's a complicated issue. In short, if a pentester can get inside your environment and gain privileges, so can an attacker. You want to slow down attackers enough to buy time for detection and response capabilities.
For whatever reason, Domain Fronting is considered more of an attack behavior, used by red teamers and penetration testers. Doubling down on that behavior likely didn't seem as appealing from a PR perspective.
Nearly 100% have on-prem AD (full name: "Active Directory: Domain Services"). Azure AD is a separate identity provider -- to a first approximation it's HTTPS and cookies, not Kerberos, LDAP, and Ticket-Granting Tickets that we see on-prem.
In contrast, the vast majority of companies with Azure AD also have on-prem AD (full name: "Active Directory: Domain Services") with some type of synchronization between them. Usually this amounts to having an on-prem service that shleps password hashes (technically salted, stretched hashed versions of the on-prem hashes) to Azure.
Smart cards are essentially a big Secure Enclave themselves.
The whole point of a smart card (same as a military CAC, and almost the same as a TPM chip on computers) is to sign operations using the private key, without allowing export of that private key. They're still made of atoms, like all objects, and susceptible to physical key extraction attacks.