Ransomware: Quis custodiet ipsos custodes

Many claim that “ransomware” is due to cybersecurity failures. It’s not really true. We are adequately protecting users and computers. The failure is in the inability of cybersecurity guardians to protect themselves. Ransomware doesn’t make the news when it only accesses the files normal users have access to. The big ransomware news events happened because ransomware elevated itself to that of an “administrator” over the network, giving it access to all files, including online backups.

Generic improvements in cybersecurity will help only a little, because they don’t specifically address this problem. Likewise, blaming ransomware on how it breached perimeter defenses (phishing, patches, password reuse) will only produce marginal improvements. Ransomware solutions need to instead focus on looking at the typical human-operated ransomware killchain, identify how they typically achieve “administrator” credentials, and fix those problems. In particular, large organizations need to redesign how they handle Windows “domains” and “segment” networks.

I read a lot of lazy op-eds on ransomware. Most of them claim that the problem is due to some sort of moral weakness (laziness, stupidity, greed, slovenliness, lust). They suggest things like “taking cybersecurity more seriously” or “do better at basic cyber hygiene”. These are “unfalsifiable” — things that nobody would disagree with, meaning they are things the speaker doesn’t really have to defend. They don’t rest upon technical authority but moral authority: anybody, regardless of technical qualifications, can have an opinion on ransomware as long as they phrase it in such terms.

Another flaw of these “unfalsifiable” solutions is that they are not measurable. There’s no standard definition for “best practices” or “basic cyber hygiene”, so there no way to tell if you aren’t already doing such things, or the gap you need to overcome to reach this standard. Worse, some people point to the “NIST Cybersecurity Framework” as the “basics” — but that’s a framework for all cybersecurity practices. In other words, anything short of doing everything possible is considered a failure to follow the basics.

In this post, I try to focus on specifics, while at the same time, making sure things are broadly applicable. It’s detailed enough that people will disagree with my solutions.

The thesis of this blogpost is that we are failing to protect “administrative” accounts. The big ransomware attacks happen because the hackers got administrative control over the network, usually the Windows domain admin. It’s with administrative control that they are able to cause such devastation, able to reach all the files in the network, while also being able to delete backups.

The Kaseya attacks highlight this particularly well. The company produces a product that is in turn used by “Managed Security Providers” (MSPs) to administer the security of small and medium sized businesses. Hackers found and exploited a vulnerability in the product, which gave them administrative control of over 1000 small and medium sized businesses around the world.

The underlying problems start with the way their software gives indiscriminate administrative access over computers. Then, this software was written using standard software techniques, meaning, with the standard vulnerabilities that most software has (such as “SQL injection”). It wasn’t written in a paranoid, careful way that you’d hope for software that poses this much danger.

A good analogy is airplanes. A common joke refers to the “black box” flight-recorders that survive airplane crashes, that maybe we should make the entire airplane out of that material. The reason we can’t do this is that airplanes would be too heavy to fly. The same is true of software: airplane software is written with extreme paranoia knowing that bugs can lead to airplanes falling out of the sky. You wouldn’t want to write all software to that standard, because it’d be too costly.

This analogy tells us we can’t write all software to the highest possible standard. However, we should write administrative software (like Kaseya) to this sort of standard. Anything less invites something like the massive attack we saw in the last couple weeks.

Another illustrative example is the “PrinterNightmare” bug. The federal government issued a directive telling everyone under it’s authority (executive branch, military) to disable the Printer Spooler on “domain controllers”. The issue here is that this service should never have been enabled on “domain controllers” in the first place.

Windows security works by putting all the security eggs into a single basket known as “Active Directory”, which is managed by several “Domain Controller” (AD DC) servers. Hacking a key DC gives the ransomware hacker full control over the network. Thus, we should be paranoid about protecting DCs. They should not be running any service other than those needed to fulfill their mission. The more additional services they provide, like “printing”, the larger the attack surface, the more likely they can get hacked, allowing hackers full control over the network. 

Yet, I rarely see Domain Controllers with this level of paranoid security. Instead, when an organization has a server, they load it up with lots of services, including those for managing domains. Microsoft’s advice securing domain controllers “recommends” a more paranoid attitude, but only as one of the many other things it “recommends”.

When you look at detailed analysis of ransomware killchains, you’ll find the most frequently used technique is “domain admin account hijacking“. Once a hacker controls a desktop computer, they wait for an administrator to login, then steal the administrators credentials. There are various ways this happens, the most famous being “pass-the-hash” (which itself is outdated, but good analogy for still-current techniques). Hijacking even restricted administrator accounts can lead to elevation to unrestricted administrator privileges over the entire network.

If you had to fix only one thing in your network, it would be this specific problem.

Unfortunately, I only know how to attack this problem as a pentester, I don’t know how to defend against it. I feel that separating desktop admins and server/domain admins into separate, non-overlapping groups is the answer, but I don’t know how to achieve this in practice. I don’t have enough experience as a defender to know how to make reasonable tradeoffs.

In addition to attacking servers and accounts, ransomware attackers also target networks. Organizations focus on “perimeter security”, where the major security controls are between the public Internet and the internal organization. They also need an internal perimeter, between the organization’s network and the core servers.

There are lots of tools for doing this: VLANs, port-isolation, network segmentation, read-only Domain Controllers, and the like.

As an attacker, I see the lack of these techniques. I don’t know why defenders doin’t use them more. There might be good reasons. I suspect the biggest problem is inertia: networks were designed back when these solutions were hard, and change would break things.

In summary, I see the major problem exploited by ransomware is that we don’t protect “administrators” enough. We don’t do enough to protect administrative software, servers, accounts, or network segments. When we look at ransomware, the big cases that get splashed across the news, its not because they compromised a single desktop, but because they got administrative control over the entire network and thus were able to encrypt everything.

Sadly, as a person experience in attack (red-team) and exploiting these problems, I can see the problem. However, I have little experience as a defender (blue-team), and while solutions look easy in theory, I’m not sure what can be done in practice to mitigate these threats.

I do know that general hand-waving, exhorting people to “take security seriously” and perform “cyber hygiene” is the least helpful answer to the problem.

*** This is a Security Bloggers Network syndicated blog from Errata Security authored by Robert Graham. Read the original post at: https://blog.erratasec.com/2021/07/ransomware-quis-custodiet-ipsos-custodes.html