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
- 469 Views
- Last Post 29 December 2018
barkills
posted this
30 November 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.
alexbarth
posted this
30 November 2018
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
pbbergs
posted this
30 November 2018
https://blogs.technet.microsoft.com/askpfeplat/2017/10/31/protecting-domain-administrative-credentials/
Thank You
Paul Bergson
pbbergs@xxxxxxxxxxxxxxxx
kurtbuff
posted this
30 November 2018
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
administrative privs.
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.
Kurt
aakash
posted this
01 December 2018
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.
-Aakash Shah
kurtbuff
posted this
01 December 2018
I haven't looked into Protected Users. Must do so soonest.
Thanks for the tip.
Kurt
cjdavis
posted this
05 December 2018
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?
aakash
posted this
05 December 2018
Correct, Protected Users only applies to domain accounts on a domain computer. In the case of a workgroup computer, the credentials are already saved locally and hence the local credentials can be discovered from a workgroup computer in any case.
-Aakash Shah
cjdavis
posted this
05 December 2018
Clarification: I was referring to the use of domain credentials on a workgroup computer.
kurtbuff
posted this
05 December 2018
Here's my thought: Someone with a domain account that's nominated as a workstation admin across the domain logs in, which leaves a set of credentials that are cached. These credentials can be mined and the password exposed with, for instance, john the Ripper, Ophcrack, etc. and they're off to the races. Deleting the profile of these powerful users often/quickly enough, and you can mitigate that, at least somewhat. Not perfect, but it would make it more difficult for the attacker.
However, if Protected Users can prevent credentials from landing on disk, then my approach wouldn't be necessary.
Kurt
kurtbuff
posted this
05 December 2018
No such thing.
While the ID and password used when logging into a workgroup computer might match the domain credentials, the logon is still authenticating against the local computer SAM database with a local user account, not against AD.
kurtbuff
posted this
05 December 2018
Protected Users has some requirements that we can't meet at this time
- namely, it doesn't work to prevent credential caching on OSes prior
to Win8.1, and Win7 machines make up a substantial fraction of our
installed base.
Dang it.
But, I've been wanting get off Win7 for a while now, and this might
provide the last bit of impetus to help force the issue.
Kurt
cjdavis
posted this
05 December 2018
Unfortunately there is.
You can use runas /netonly /user:DOMAIN\privilegedaccount powershell.exe…where ‘privilegedaccount’ is a DA/EA account…and get a powershell shell that has DA/EA access over the network.
michael1
posted this
05 December 2018
cjdavis
posted this
05 December 2018
That works from a workgroup computer as well as the command I mentioned in my previous email.
kurtbuff
posted this
05 December 2018
When you look at the target machine that isn't joined to the domain, I
believe there's going to be an account that has the same ID/Password
as exists in the domain. The local account, local to the workgroup SAM
database, but which has the same samaccountname/password combination
as the domain account, might or might not not be privileged on the
local machine, depending on local group membership.
To my understanding, a machine in a workgroup doesn't have a trust
relationship with the domain, and therefore can't authenticate the
logon with the DC.
If I'm wrong in that understanding, then I've missed a major evolution
of AD in the past few years, and I really need to learn about that..
Kurt
michael1
posted this
05 December 2018
barkills
posted this
05 December 2018
Michael’s question goes to where I was thinking, but didn’t say in my prior response, namely:
How much work do you put into preventing or mitigating every possible misuse of admin credentials? How much effort do you put into discovering misuse?
That’s primarily a risk management decision, about how many resources are justified given the perceived cost of risk. At some point, you realize that it is not cost-effective
to scan every possible computer that an admin might cache their admin credentials on. But where do you draw the line as to how much effort you put into this?
One of the reasons bloodhound (and maybe azure atp) look appealing to me is that there is a limited investment needed, and a broad set of possible mitigations to be discovered
via that investment. Via BI analysis add-ons, it also may provide an objective security analysis of proposed design changes in our environment, e.g. via the existing design 42 domain users have a path to domain admin escalation, but via the proposed design
420 users would. That makes the proposed design undesirable from an objective security point of view. And you can show a picture that illustrates that.
kurtbuff
posted this
05 December 2018
From my experience, this doesn't create a local profile on the target
machine. Otherwise there would be a profile for everyone who ever
mapped a drive, and that doesn't happen.
I do not know how the credential is stored in memory during
authentication, or if it lasts in the memory of the fileserver longer
than the time it takes to generate a token for the session - that's
certainly worthy of investigation - but I'd be surprised if those
creds are kept around for very long. It would be a major design flaw,
IMHO.
OTOH, RDP/VNC/etc. certainly does create a local profile on the target machine,
cjdavis
posted this
05 December 2018
When you look at the target machine that isn't joined to the domain, I believe there's going to be an account that has the same ID/Password as exists in the domain. The local account, local to the workgroup SAM database, but which has the same samaccountname/password
combination as the domain account, might or might not not be privileged on the local machine, depending on local group membership.
Currently using a workgroup computer and a local account with a samaccountname and password that is different than the domain account samaccountname and password
To my understanding, a machine in a workgroup doesn't have a trust relationship with the domain, and therefore can't authenticate the logon with the DC.
It absolutely can, given the right command.
