Pass the Hash Mitigations

Over the last couple years, I’ve seen countless articles explaining Pass the Hash, and there are even a few high-level whitepapers about what to do about it. Here’s some of the best of those:

There’s also a good paper covering the Kerberos equivalent:

Awareness and understanding is all good, but there isn’t enough thinking and public discussion about the specific ways to mitigate the risk.

In many ways, it feels like folks are holding their breath and hoping Microsoft will fix it all.

And of course, in the meantime more places are getting compromised. I have little doubt that yesterday’s announcement of the Premera compromise will turn out to be yet another PtH story.

We’ve closely looked at the Protected Users & Authentication Policies stuff. Like several notable 3rd parties, we’re not convinced they are especially effective given the design. I have high hopes for the Aorato Directory App Firewall (or whatever Microsoft chooses to call it after it re-releases it) and its ability to detect PtH. Likewise, I’m hopeful about the Next Generation Credentials that Joe Belfiore publicly revealed more about recently (but it isn’t yet clear that NGCs help with PtH). And there is the Just in Time administration capabilities that should be released soon with MIM, which would limit how long a given account has privs, instead of it always having privs. There’s also the recent guidance on how to reset the KRBTGT account password. Those are the major things Microsoft has cooking/available for this problem. But those are just part of a strategy, most aren’t available yet, and in some cases require major changes that aren’t realistic to expect anytime soon.

Don’t get me wrong, I’m totally impressed with how much investment Microsoft has poured into this, it’s just that I don’t want to sit around idly any more and I don’t think anyone else should either.

We’ve been talking a bit here about potential ways to mitigate risk that don’t require some new thing and wouldn’t necessarily be a major impact to implement. Not eliminate the risk, but limit it. Here’s some ideas we’ve been tossing around:

  • Automatic user profile deletion after X days via group policy setting. Eliminates cached creds laying idly around. Definitely a good idea for servers, maybe not so much for workstations given the roaming scenario. 
  • Develop strategy to block ‘logon over the network’ user right. Idea here is to inhibit the lateral movement. Still struggling with whether this should leverage the block setting or reduce who has the allow, and beginning to lean toward the latter. Things that need more thought are how to break your sets of computers into logical groupings of levels of trust where you’d apply this–put another way, what are the trust boundaries for this idea? Also needing thought are which accounts would lose logon over the network–seems like you’d want to target accounts that have any sensitive permissions.This idea seems to have lots of promise, but the details are a bog.
  • Push Group Managed Service Accounts more heavily. Perhaps to the point of eliminating “normal” user accounts for services, scheduled tasks, etc.
  • Have better education/practices for which admin accounts should be used in which scenarios. “workstation admin” account only used to log into workstations. “server admin” account only used to log into servers. “domain admin” account only used to log into DCs. Never use these on the same computer, because then you’ve created an escalation bridge. If possible detect when a type of admin account has been used improperly, and alert to take actions to eliminate risk from that.

We’re open to hearing other’s ideas, hearing critiques, or collaboration on these ideas.

Leave a Reply

Your email address will not be published. Required fields are marked *

Required
Required