In a recent conversation with a Microsoft Security Architect, the topic of using “Run As” came up:
“Short version is, in a credential theft world the Microsoft guidance from 10+ years ago no longer applies, because every instance of using Run As exposes your credentials on a system. If an attacker is already a local admin on the system they can then pass those credentials and act as that user. If such a user is a domain admin, game over.” Run As doesn’t provide any protection against “pass the hash.” And it’s still a consideration in Windows 10, even with the new version of SMB.
In other words - we need to stop using “Run As.” Especially in Windows 7 - which is only marginally more secure than Windows XP.
What to do?
Microsoft offers this blog post for more detail on simply disabling it:
https://blogs.technet.microsoft.com/jepayne/2016/04/04/when-the-manual-is-not-enough-runas-netonly-unexpected-credential-exposure-and-the-need-for-reality-based-holistic-threat-models/
but that’s not practical for most of us. I imagine practically all of us use separate ADM accounts to do “Run As” on a user’s (hopefully white-listed) machine when needed to install specific one-off applications or do tasks that require admin privileges.
Note: we’re already a fully white-listed environment (AppLocker/GPO for apps, ActiveX controls and Chrome extensions.) I’ve been promoting/running/supporting white-listed PC law firm environments since 2008 and am happy to talk offline about how I think they actually result in less work for IT over time, not more. And they reduce your attack surface to an individual machine level … if you’re trying to get your partnership to buy in on white-listing, call me ...
Here’s how we plan to get around using Run As:
- Stop using Run As on our own IT machines for temporary escalations and isolate our administrative tasks to a VM running Device Guard (consider Device Guard for anything you want to have “bastion host” - level protection on. DCs, kiosk machines, etc. Isn’t practical for PC environments though, unless forced reboots are your thing…)
- Implement LAPS (already done.) Good practice regardless to reduce “pass the hash” vulnerability but we may leverage this to replace “Run As” too.
- Use a purpose-specific domain-based account with local admin rights on each PC with the /restrictedadmin mode switch for installations
AND
Replace AppLocker with a third-party solution for application management that can be engineered so that is not susceptible to pass the hash/doesn’t use “Run As” (Carbon Black, Avecto, BeyondTrust, Thawte all have client-based solutions for this.) We plan to move to one of those solutions next year, though we are in the early stages of engineering this.
Please reach out to me offline with any questions.