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".
I don't think I understand you. The RC4 encryption type is msDs-supportedEncryptionTypes 4 (i.e. 0b0100). DES_CBC_CRC is 1, DES_CBC_MD5 is 2. They do not "correlate".
And regarding the NT hash: the NT hash is named after NTLM, not Kerberos. NTLM is a completely different (and much less secure) authentication mechanism. And the NT hash is not DES at all, it's MD4. You may be confusing it with the LM hash, which is indeed DES, but does not support unicode and is not common anymore.
The LM hash is disabled on domains with an LmCompatibilityLevel of 4 or above. (It's accepted, but clients shouldn't send it, on the default LmCompatibilityLevel of 3, which, by the way, unless your domain has devices from the stone age, you can safely set to 5, disabling LM and NTLMv1.) Although, if you can, you should disable NTLM on the domain altogether, because it's a much more vulnerable protocol than Kerberos.
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.
Since the user's eyeballs don't have builtin decryption there is a window of opportunity to steal information after encrypted at rest and encrypted transport. Hopefully vendors will be able to fix this defect by using Neuralink.
If it’s at rest encrypted you generally do not manage to get 4TB of data before anyone notices.
If you're talking about your own personal hard drive in your home, yes.
But in this case, we're talking about a huge company conducting literally billions of database queries for tens of thousands of clients an hour.
You only have to have a listening post in one small part of the system that can see things in plaintext for a short time in order to accumulate 4TB in a matter of days.
Looks like the issue has to do with claims processing between pharmacies and UHG, effectively data in flight not at rest.
"We estimate more than 90% of the nation’s 70,000+ pharmacies have modified electronic claim processing to mitigate impacts from the Change Healthcare cyber security issue; the remainder have offline processing workarounds," Mason said.
The pharmacy network, which connects pharmacies and PBMs, is in final end-to-end testing with our partners. We anticipate that our Change Healthcare Pharmacy network will be back online for the vast majority of submitters as soon as Thursday.
How many organizations have their "encrypted at rest" data in a cloud provider account that's set up to give all developers (or at least all production support engineers) access to decrypt the data, maybe even transparently?
How many have the "encrypted at rest" data on servers that are set up to give all administrators transparent access to the data?
How many only allow application service accounts access to decrypt the data directly, but the credentials for those service accounts are stored as Kubernetes secrets that anyone in IT can read?
I can guarantee you that UnitedHealth Group (Change Healthcare) doesn't give regular developers the credentials to decrypt production data, or access production environments at all.
probably not "developers," probably "data scientists"
Executives at UnitedHealth Group told workers to mine old medical records for more illnesses, to identify diagnoses of serious diseases that might have never existed, inflating bills paid by the federal government's Medicare Advantage program.
Presumably they did not break into the data center and lift a bunch of hard drives. Instead they compromised a server which had credentials to read the data in a clear format.
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".