afaik the majority of ransomware does manage to use cryptography securely, so we only hear about decrypting like this when they fuck up. I don't think there's any good reason beyond the fact that they evidently don't know what they're doing.

My unqualified hunch: if they did that, then a mitigation against such malware could be for the OS to serve completely deterministic data from /dev/random for all but a select few processes which are a priori defined.

You can do the same with time though, just return a predefined sequence of timestamps.

And from a "defensive" perspective, if you don't trust any single entropy source, the paranoid solution is to combine multiple sources together rather than to switch to another source.

If it were me, I'd combine urandom (or equivalent), high-res timestamps, and clock jitter (sample the LSB of a fast clock at "fixed" intervals where the interval is a few orders of magnitude slower than the clock resolution), and hash them all together.

Even if the attackers used a fully broken since 1980s encryption-how many organizations have the expertise to dissect it?

I assume that threat detection maintains a big fingerprint databases of tools associated with malware. Rolling your own tooling, rather than importing a known library, gives one less heuristic to trip detection.

They used this with the IVs mucked with: https://www.gnupg.org/software/libgcrypt/index.html

Charitable, use of system level randomness primitives can be audited by antivirus/EDR.

I wonder at what point would the antivirus kick in. It doesn't require reading /dev/urandom for too long.

Rolling your own crypto is still a thing.

If it works (reasonably) it works, and it throws wrenches into the gears of security researchers when the code isn't the usual, immediately recognizable S boxes and other patterns or library calls.

Might be a bit a paranoia about official crypto libs backdoors, too.

In case the tool is used against them.