Security for Active Directory environment has been under review and one of the items of concern is the ability for a user with DA/EA credentials and access to a domain or non-domain joined workstation on the organizational network to use runas with the /netonly switch and target the domain controllers. This type of access was covered in a blog post about two years ago (link: 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/). Has there been any updates on methods to prevent and/or detect this attack vector, or if this is just a “known issue?”
RunAs /netonly Issue
- 322 Views
- Last Post 29 December 2018
I don’t know anything further on the potential solution discussed at the end of that post (auth silos), but a mitigation you could apply would be to use Bloodhound or possibly the new Azure ATP Lateral Movement Paths (don’t yet have much
info about this) to detect when it happened.
This would be a monitor & mitigate solution, i.e. you wouldn’t be preventing it, but you’d identify when it happened, and have a talk with the person about why they should never do that, while also deleting any cached creds on the computer.
I’ve mentioned bloodhound recently here, so I won’t repost the links I already shared, but you might want to check out that prior post.
You can also look into PAWs (https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations)
and authentication silos. You can build a silo that contains your DA/EA/SA accounts, domain controllers, and PAWs which would prevent the accounts from logging in elsewhere. If you need to use the accounts on other systems, you can leverage remoteguard to
remote desktop to the systems outside of the silo from a PAW or domain controller.
ALEX BARTH | ITS Systems - Shared Infrastructure
The University of Texas at Austin
alexbarth@xxxxxxxxxxxxxxxx | utexas.edu
Something I've thought about, not as a preventive measure but as a
post-hoc measure, is to set up a scheduled task that would run every
couple of hours and delete local profiles of all accounts that have
This wouldn't take care of credentials left in memory from, e.g. RDP
and runas, but would lessen the impact of local admin compromise and
rummaging around in c:\users for cached creds, and when coupled with
LAPS should be a useful mitigation.
Thoughts on my thought appreciate.
Protected Users by default disables credential caching, and it also expires its ticket after 4 hours. We've started using Protected Users as a way to minimize domain accounts for admins remaining on systems (and it also helps disable NTLM).
I haven't checked to see how Protected Users would be affected by the runas netonly workaround shown below though.
I haven't looked into Protected Users. Must do so soonest.
Thanks for the tip.
Thanks for all of the suggestions. I suspected that there wasn't a surefire method to prevent this but wanted to make absolutely sure I hadn't overlooked anything.
Aakash: I don't think Protected Users would be applicable for a workgroup computer; I'll have to dig into the documentation to verify.
Kurt: How would removing the profiles of local admins lessen the impact of compromise? Is it related to the warning displayed when a password for a local account is changed via methods other than CTRL+ALT+DEL?
Brian: Someone from our Security team mentioned Bloodhound; I'll see if deployment can be moved up. We have ATA in place on-prem and it does display lateral path info in the console...are there features for lateral path detection in ATP (notification/alerting) that aren't available in ATA?