When the manual is not enough - runas /netonly, Unexpected Credential Exposure and the Need for Reality Based Holistic Threat Models

One of the things I always advocate for IT Professionals/Defenders is that versus letting Penetration Testers and Real Attackers figure out the holes in their systems, is a serious contemplation of how you would bypass your own defenses. Your adversaries are more than willing to spend time learning the apps and defenses you have in place and who knows better how those defenses work than those that built them? This post is less about a particular bypass or technology (as all sets of controls will have workarounds) and more about thinking like an attacker. Try to bypass your own systems - before someone else succeeds.

This exercise proved especially fruitful at a recent super smart and awesome customer, as within minutes of putting Privileged Admin Workstations and Credential Theft Mitigation GPOs in place in their domain, the Domain Admins found a way to bypass the mitigations and do Domain Admin work from their regular workstations and the internal Red Team found that this bypass left High Value Credentials behind for easy harvesting.

What happened? Well, it all revolves around the runas /netonly command and the Logon Type 9.

Let's do a run through of how this looks. This is my lab, and spoiler alert, we know credentials are getting exposed here so let's start off by mimicking real attacker behavior - capturing credentials in a persistent manner. This could be done via an implant, or Mimikatz, keylogging, or LSA Keychaining but in this instance I'm going to use Windows Credential Editor. Here you can see that at startup/initial logon by Bob, we just have credentials for Bob's account and that of Bob's computer (cleverly also named Bob.)

Bob is our Tier 0/Domain Admin. Let's pretend Bob is new to the job, and while he's been given a PAW, nobody has shown him any scary videos or trained him on how and why to use it yet. Bob also is the only Domain Admin available on the weekend at 1AM when a Priority 1 ticket comes in for an account to be removed from the Domain Admins.

We can see from a gpresult /h output on Bob's regular workstation, all the Pass the Hash mitigation GPOs are in place :

Bob knows he also can't RDP to the Domain Controller since Windows Firewall rules are in place preventing access over TCP 3389 from anything other than the Privileged Admin Workstations. Bob's got A Very Important Security Task to do however, and therefore he tries a trick that always worked at his old job, which is Run as a Different User - Bob holds down the shift key on his keyboard and right clicks on cmd.exe, intending to run it as his Domain Admin account to launch Active Directory Users and Computers.

But alas for Bob - this is denied by the Deny Log on Locally GPO setting - a Run as a Different user is a full interactive logon after all, and should rightly be prevented for Domain Admins on lower trust systems such as workstations.

We can also see what that looks like in the Event Log, and it might be something you want to monitor as it might indicate either untrained admin or malicious activity.

Bob however is very clever and not one to be deterred - after all he's got a Priority 1 ticket to remove an account from the Domain Admins, which is a Very Important Security Task!

So Bob tries something he found in a search engine - which is to use the /netonly switch on Run As. This is a different type of Logon, Logon Type 9, and Bob thinks this might work on his laptop.

Bob crafts the following command :

runas /netonly /user:contoso\bob-da "mmc.exe c:\windows\system32\dsa.msc" and enters his Domain Admin Password (already exposing himself to any Keylogging malware on the system.)

Not only does Bob get his Active Directory Users and Computers MMC without having to use his Privileged Admin Workstation in spite of all of those lockdowns, his credentials are left behind in memory.

Well, Bob gets his ticket closed - but this is very bad. Because Bob is an efficient admin who wants to do things quickly, he's likely to never open his Privileged Admin Workstation, which means that in spite of all of the great work Bob's company has gone to they are still only a few steps away from total domain compromise.

This particular set of circumstances described in this did require Bob to be an admin on his workstation to run the commands with UAC Elevation - which is another great reason to fight the usually tough political fight of removing local administrator rights from IT staff - but the principle could work with other apps without elevation.

Imagine if instead of Paint that was an Identity Management System front end GUI - that might make it a bit more realistic to imagine a use for Bob using his Domain Admin account to launch it. : )

So what can be done to stop this?

The easy option would be to create an Applocker Rule to Prevent RunAs from being executed (since it's actually an executable.)

I'd recommend applying it to a group of "People with Tier 0 Access" (as well as targeting to other privileged accounts like server admins) that way help desk and other support staff can still elevate/runas local admin accounts as needed.

This has the desired effect of stopping the runas /netonly behavior :

But it's still moot if you let Bob keep Local Administrator access - because if you stop the Application Identity Service, Applocker Rules no longer work. Bob might just be determined enough to do that, or an attacker who has Bob's access might be.

The harder option is Authentication Silos. These should, in theory, prevent the logon from occurring on the lower level workstation and block the auth - however myself and a coworker haven't been able to make them block the logon reliably yet.

While this story might appear to be about a particular admin behavior that could be solved by some "staffing decisions" it's really a bigger concept. Any security control you put in is simply a Turing Test. If there is a Human Adversary on the other end, chances are high they will find a bypass. Don't delegate the discovery of flaws in your systems to adversaries - create realistic threat models. Don't just assume admins are going to follow the rules, as the adversaries trying to get into your network certainly aren't. I hope this relatively simple real world example will help you to think outside the box and beyond manuals and guidance on other systems in your environment.

-Jessica @jepayneMSFT

Comments

• Anonymous
  May 13, 2016
  @JepayneMSFTIn an attempt to stop RunAs /Netonly from working for specific accounts i’ve tried the following so far.I’ve tried blocking RunAs executable using AppLocker:I am able to block DomainAdmin1 from running RunAs /User:Whoever on Server1 but i couldn’t block ServerAdmin1 from running RunAs /Netonly /User:DomainAdmin1 on Server2I also tried Logonto tab in AD to limit DomainAdmin1 to logon only onto Server1 but on Server2 the RunAs /Netonly /User:Admin2 switch still works even though RunAs /User:Admin2 is denied.I am out of ideas at this point. Any suggestions? Thanks in advance
• Anonymous
  September 28, 2016
  C:> C:\SYSINTERNALSUITE\accesschk.exe -s -w users C:\Windows\Accesschk v6.02 - Reports effective permissions for securable objectsCopyright (C) 2006-2016 Mark RussinovichSysinternals - www.sysinternals.comRW C:\Windows\TempRW C:\Windows\tracingRW C:\Windows\Registration\CRMLogRW C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Dlna\DeviceIconsRW C:\Windows\servicing\PackagesRW C:\Windows\servicing\Sessions W C:\Windows\System32\Com\dmp.....................a lot of user writable folder below C:\Windows, so AppLocker rules "All files located in the Windows folder" is also... useless?you can copy runas.exe to myrunas.exe -> AppLocker rules do not prevent itetc.........
• Anonymous
  November 04, 2016
  FYI, the way your example Credential Hygiene GPO is configured here breaks failover clusters. This is mentioned in a blog post titled "Blocking Remote Use of Local Accounts" by your colleague Aaron Margosis: https://blogs.technet.microsoft.com/secguide/2014/09/02/blocking-remote-use-of-local-accounts/
  • Anonymous
    December 13, 2016
    Aaron's post is correct on that, this should be applied with a caveat that certain systems will not like the local account restrictions. -Jessica