Not many.

Typically, these attacks start by compromising a regular workstation by some office drone via Office macro. Then they start escalating privileges by exploiting Kerberoast, RCEs (think BlueKeep, Eternal Blue, Tomcat servers with the default password, etc.) and other quick wins. When they get a clear text password, password hash or kerberos ticket of a privileged account, there is nothing to stop them. Windows doesn't care if you have MFA at the workstations or at your VPN interface. With the hash or a ticket you can perform network logons to any system where you have local admin permissions. Otherwise, this would destroy the entire single sign on feature that Windows and its users love - logon once, access everything. Kerberos is deeply built into the Active Directory.

Backups are fine, sure, but typically you want to figure out what exactly the attackers did and at what point they started doing it, so you know how far back you have to go with your backups, because you want a backup without back doors. So you need to hire special consultants and they take at least a few days, maybe a few weeks to figure this out.

If you don't have offline backups or took some other special precautions, the attackers might have deleted your backups.

After all that, you still need to apply the backups. A process that probably varies widely in length depending on the quality of the admin team and the size of the organisation.

Sometimes simple preventative measures aren't as simple as they might sound. How would you go about integrating yubikeys for login into multi-decade-old SCADA hardware systems?

I'm a security specialist and I honestly wouldn't know where to begin.

Is that the case with all of these hacks? How many would be prevented, is what I'm wondering? My mother's hospital was hacked this week and now they can't even clock in but they're not running SCADA

SCADA's a good example of systems that are difficult to secure for complex reasons. There are many others.

You ask a very wise question. Unfortunately, I think it's unknownable. The best we know is that the answer is more than none and less than all. The more you get towards "all" the more prevention measures cost to implement. For instance, managing a mature backup and imaging operation at scale may be conceptually simple but is both complex in practice and far from free.

Hospitals in particular are the scene of some interesting conflicts between security and usability. There are a lot of stories about health staff doing things like jamming open medication dispensing machines so that they could get on with the job instead of dealing with security measures they experienced largely as obstacles.

Can you imagine throwing yubikeys into a scenario like that, where people already have an adversarial relationship with IT and security measures? What do you think is going to happen when someone forgets their key and can't send an x-ray to the remote radiology center? I have my guesses.

Adversarial relationship with security are very often created by very annoying security requirements which do very little to improve security. Like requiring users to change all passwords ever 2 or 3 months and requiring a new password to have characters from every class (see also [1]). While all you need in the most cases is just minimum length requirement and some guidance how to choose a good password.

If user will have to enter 16 charter password each time after HW key (like Yubikey) will be connected to a computer to unlock it, then users will leave it always inserted. Or password will be saved in a text file. If HW key will just work once inserted (or will require 4 digit pin) most users will comply. It is already 2nd factor in addition to some other password, it doesn't necessary need a strong password to use it.

[1] https://passwordfromhell.com/

Leaving a key inserted is still a vast improvement over the current situation. Yubikeys have to be pressed to generate a new code each time (as they expire after each use) and the situation you avoid is remote hacking especially via social engineering.

Not all u2f keys require being touched. That's an optional hardware implementation detail, rather than a mandatory trait across all u2f devices. Yubikey sells keys that are commonly used by plugging them in, leaving them, and never again touching them. This effectively turns the computer itself into the second factor.

Depending on the precise scenario, that may or may not represent an improvement. If the key is used as a second factor to authenticate to the network, then an infected Excel document will trivially ignore the involvement of a Yubikey as it uses the logged-in user's Kerberos ticket to spread.

You're completely right, though. Even this would definitely cut down on phishing attacks that send users to fake websites pretending to be internal systems.

We first start by moving all the non legacy stuff to MFA. There are so many easy targets in security that we can look in to first before declaring it impossible because of a handful of legacy apps.

You're absolutely right. There's often no shortage of low hanging fruit.

I'm not suggesting we should declare anything impossible. Far from it! I'm merely trying to suggest that we should appreciate that not all things as easily fixed as they may seem at first blush.

As all of us in software know, complexity can lurk in unexpected places.