RunAs /netonly Issue

  • 59 Views
  • Last Post 2 weeks ago
cjdavis posted this 3 weeks ago

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?”  

Order By: Standard | Newest | Votes
barkills posted this 3 weeks ago

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.

 

show

alexbarth posted this 2 weeks ago

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



 

show

pbbergs posted this 2 weeks ago

https://blogs.technet.microsoft.com/askpfeplat/2017/10/31/protecting-domain-administrative-credentials/

 



Thank You

 

Paul Bergson

pbbergs@xxxxxxxxxxxxxxxx



 

show

kurtbuff posted this 2 weeks ago

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

show

aakash posted this 2 weeks ago

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

show

kurtbuff posted this 2 weeks ago

I haven't looked into Protected Users. Must do so soonest.

Thanks for the tip.

Kurt

show

cjdavis posted this 2 weeks ago

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?

show

aakash posted this 2 weeks ago

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

show

cjdavis posted this 2 weeks ago

Clarification: I was referring to the use of domain credentials on a workgroup computer.

show

kurtbuff posted this 2 weeks ago

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


show

kurtbuff posted this 2 weeks ago

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.


show

kurtbuff posted this 2 weeks ago

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

show

cjdavis posted this 2 weeks ago

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.

 

show

michael1 posted this 2 weeks ago

Reading this popped up a question in my mind. I really don’t know the answer and I don’t have time to test right now.

J

 

So Devil’s Advocate: what about domain credentials stored with “net use * \domain-file-share-server\sharename /user:domain\username /persistent:yes” ??

 

show

cjdavis posted this 2 weeks ago

That works from a workgroup computer as well as the command I mentioned in my previous email.

 

show

kurtbuff posted this 2 weeks ago

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

show

michael1 posted this 2 weeks ago

Oh, I’m aware it works. I’m not aware of where the credentials are stored.

 

show

barkills posted this 2 weeks ago

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.

 

show

kurtbuff posted this 2 weeks ago

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,

show

cjdavis posted this 2 weeks ago

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.

 

show

AnthonyP posted this 2 weeks ago

They are stored in Credential Manager. 
Anthony Petito


show

cjdavis posted this 2 weeks ago

Which credentials?



 

If you try to run net use

\domainmachine\domainshare /user:domain\username /persistent:yes it won’t work. 



 

If, however, you first run

runas /netonly /user:domain\username cmd.exe

then run

net use

\domainmachine\domainshare /persistent:yes

it will work, and it will use the credentials provided when running runas to connect to the share.

 

show

kurtbuff posted this 2 weeks ago

Wait - am I misunderstanding the direction of your command line?

I was thinking of issuing your command on a domain-joined computer
with the target being a workgroup computer. I'll stand by that.

If on the other hand you meant that the command is issued on a
workgroup computer against a domain-joined computer, then yes, that
will works as you described. The credentials in that case, will exist
on the workgroup computer only exist in memory, not on disk.

Kurt

show

barkills posted this 2 weeks ago

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..
[BA] You know that the Kerberos protocol doesn't require a Kerberos realm join of the computer one is requesting a TGT from, right? That's been true for a really long time. In fact, Microsoft took advantage of it back in 2000, when it provided cross-realm Kerberos interoperability (although there are details to that example which don't exactly align with this use case). Microsoft has recently taken advantage of this fact to allow Azure AD joined computers to get a Kerberos TGT (and subsequent TGS tickets) from an on-premises AD which is federated with the AAD the device is joined to. There's more to how Microsoft made that work, but it works.

The same thing is true for NTLM too.

Many students here never join their computers to our university AD (or any AD). And yet, they regularly connect & interact with file services which require an AD authentication.

This works and has worked for as long as I can remember.

One thing that is harder to make work is if a computer is joined to an AD which has no trust relationship with the AD it needs a token from.

Brian
��)ߢm������+�v*�롹^�˧���r���x���i٢�f���-�����+

michael1 posted this 2 weeks ago

Has to last longer than that. "/persistent:yes" lasts across reboots. I would surmise that a NTLM hash of the password is stored.

show

michael1 posted this 2 weeks ago

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.

The machine does not have a trust relationship with the domain.

That does not mean that a user logon cannot be authenticated via NTLM.

show

kurtbuff posted this 2 weeks ago

Ouch. my response reads nearly incoherently. I hope it's understandable.

Kurt

show

dloder posted this 2 weeks ago

That's what the /netonly switch does.  It does not require a matching account to be present in any database.  ANY credentials, even invalid ones, can be provided and the runas command will complete successfully.  It's not until you try to use them to hit a resource that any validation is performed.
Fortunately PUG/AuthSilos will still be effective in this scenario as the DCs won't provide a Kerb ticket or validate a chained NTLM auth when it originates from outside an accepted silo.  It won't prevent the use of the runas command but renders it ineffective.
But ultimately this is user education as you cannot prevent an admin from typing their credentials into any system, domain joined or not and they need to be disciplined enough to not enter them into a system that isn't in the appropriate tier.
You mitigate this by moving to smart cards so admins do not have passwords to type.
-- dloder.blogspot.com --


show

aakash posted this 2 weeks ago

Note that Protected Users has 2 sides to it: the server side domain protections and the client side protections. While this initially required Win 8.1+, MS backported the client side protections to Win7 with an update in 2014. More information at this and how we can see Protected Users client side protection in action (the Win7 piece is at the end of the article):
https://blogs.technet.microsoft.com/askpfeplat/2016/04/04/reading-the-fine-print-on-the-protected-users-group

We have used this to help add protection to our Win7 environment too.

-Aakash Shah

show

AnthonyP posted this 2 weeks ago

The existence of a profile on a system, doesn't necessarily mean that the credential for that account is still available--either in memory or as a cached credential on the local system. The default behavior starting in Windows 8.1/Server 2012 and later has been to clear credentials from memory (lsass) immediately after log off.  These options were backported to Windows 7 and Server 2008 as well through KB2871997.  Cached credentials is a completely different beast and the availability of them depends on how many different people log on to the system and how many credentials you're configured to save (default is 10).  It's FIFO and only Interactive/Remote Interactive credentials are cached.  Other logon types are not. 
Anthony Petito


show

barkills posted this 2 weeks ago

I think you’ve missed Michael’s point.

 

How do you identify the non-domain joined computers where these possibly cached domain admin credentials are?

 

Do you go to all the domain admin’s homes with a search warrant? Make them sign something that allows you to inspect all their personal computers?

 

At what point does this become a wild goose chase?

😊

 

Brian

 

show

kurtbuff posted this 2 weeks ago

That makes sense.

And again I mistook the target of the query - Sigh.

Sorry, MBS.

Kurt

show

cjdavis posted this 2 weeks ago

With my initial question I was looking to mitigate/prevent a specific vulnerability…that being ‘runas /netonly’ using privileged credentials… since I prevented the use and

caching of privileged credentials on workstations/servers within the scope of the pentest performed against our directory.

 

Going forward, any work spent would be restricted to that scenario.

 

 

show

aakash posted this 2 weeks ago

That’s my understanding too assuming you choose to make the connection persistent.

 

One way to help with that a little is to prevent Domain Admin accounts from authenticating on regular workstations.  One way to accomplish this is to use the Logon Workstations AD attribute but

a better way would probably be Authentication Silos (haven’t had a chance to play with that yet). 



 

However, I haven’t had a chance to test how the /netonly switch works with this.

 

While it takes some time, setting up a 3 tier architecture helps with this scenario since it attempts to limit the blast radius of credential compromise/abuse.

 

-Aakash Shah

 

show

cjdavis posted this 2 weeks ago

I believe you have misunderstood.
I am talking about running runas /netonly /user:DOMAIN\privilegedaccount on a workgroup computer, which will keep credentials in memory until the computer is rebooted.

show

cjdavis posted this 2 weeks ago

See my response to your original query about net use /persistent:yes

show

kurtbuff posted this 2 weeks ago

Yes, I was, as I said in an earlier reply, thinking in the wrong
direction. Silly mistake on my part.

Kurt

show

kurtbuff posted this 2 weeks ago

Right. As I mentioned in a reply to someone else, i was thinking in
the wrong direction.

show

kurtbuff posted this 2 weeks ago

Agreed. Not my best day on this list.

Sorry for the noise.

Kurt

show

aakash posted this 2 weeks ago

My understanding is that this saved credential is not stored as the NTLM hash, but rather the actual password is stored and protected by DPAPI:
https://security.stackexchange.com/questions/93437/how-to-read-password-from-windows-credentials

-Aakash Shah

show

bdesmond posted this 2 weeks ago

Reading through this thread, it seems like the fundamental question is whether or not there's a technical control for bad human behavior. It seems to me that if this is a legitimate concern that you can't train/direct your people not to do you have bigger problems...


Thanks,
Brian

show

cjdavis posted this 2 weeks ago

Since our domain controllers are not accessible off-campus, and DA/EA access is limited to our team, identifying non-domain joined computers with possibly cached credentials won’t be difficult.

 

Although I still may have missed Michael’s point; I assumed that he was asking a question with zero subtext or ulterior motive.



 

show

aakash posted this 2 weeks ago

I attempted the test from the



originally referenced page
and if the DA account is restricted in terms of where it is allowed to login, then it doesn’t appear that the /netonly switch works.  I just tested this and was unable to open ADUC or access the DC when attempting these steps

from a regular workstation (not on the list of logon workstations).  So assuming I ran this correctly, this may be one way to help mitigate this relatively quickly. 



 

If



 



-Aakash Shah



 

show

kurtbuff posted this 2 weeks ago

Right. my mistake and apologies.

Kurt

show

kurtbuff posted this 2 weeks ago

Outstanding.

I'll bet that backport was included in released cumulative security
updates, too. I'll research to make sure, and then plan the
implementation.

All of our DCs are 2012 or 2016, so that part should be no problem.

Thank you again for this info.

Kurt

show

kurtbuff posted this 2 weeks ago

I believe that Protected Users will do the work I need.

JFTR, though, our environment has 99+% single-user machines, so that
helpdesk staff cached credentials aren't normally purged out the back
end of the FIFO queue. Any number of times I've been able to rectify
problems with machines by disconnecting them from the network and
using a cached credential to log in.

Kurt

show

AnthonyP posted this 2 weeks ago

> I think you’ve missed Michael’s point.  How do you identify the non-domain joined computers where these possibly cached domain admin credentials are?
Maybe I should have expanded a bit further.  I think the identification of this behavior is misplaced.  Jessica's blog tells you what to look for: Logon Type 9.  Should your DCs get that alert, get it to the SOC to investigate--disable the account, reach out to the user, and find out wtf they're doing.  I'd also pull any other corresponding events to determine where else the account may have authN between receiving the alert and when the account was able to get disabled.  The better news in this particular scenario is that with the new protections in lsass, the runas /netonly credential will be removed from memory as soon as the process that spawned that DA/EA identity is closed.  
Whether stored in Cred. Manager or in memory--it makes no difference because as an attacker who potentially owns the box already, I can likely get the plain text password as it's typed into the keyboard, or better, if CredSSP is still allowed.  I'd argue that putting more time and effort into monitoring, detection, and alerting is far more cost beneficial than attempting (and re-attempting) to block an Administrator from doing Administrative things.  There's often never a technical control for an Administrator's 'lazy' behavior, but finding the lazy admin and their behaviors... :)
Anthony Petito


show

kool posted this 2 weeks ago

I agree that having a tool like Bloodhound or ATP is ideal, however there is a mitigation that hasn’t been discussed. There is a group policy setting that can be used to limit the number of cached credentials.

 

The registry location for this setting is HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon:CachedLogonsCount. It defaults to 10.

 

The corresponding group policy setting is discussed in

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available. The advice given by this article is to set it to 2 so that “A configuration

value of 2 means that the user's logon information is still in the cache, even if a member of the IT department has recently logged on to the device to perform system maintenance.” Well, that rather defeats the purpose of reducing credential exposure. The

article doesn’t discuss the importance of knowing the local admin password as a work-around if the domain creds aren’t cached. Of course the group policy setting isn’t of much use with non-joined computers but the reduced registry setting could be baked into

the setup image if the machines are centrally set up.

 

    Eric

 

show

AnthonyP posted this 2 weeks ago

Curious... why not use the built-in Administrator account? You could use LAPS to keep the account password unique and grab the password directly from AD. Seems a bit easier than having to disjoin and rejoin the domain, but I understand logistics often times don’t make the obvious path the easiest. 


show

michael1 posted this 2 weeks ago

Huh. Interesting. Thanks for that.

show

kurtbuff posted this 2 weeks ago

Fair point.

We do use LAPS - I just have to remember to use it, and sometimes (as
when I don't have my laptop with me, so it's hard to look it up) it's
just plain easier to disconnect, type in the known cached password and
move on.

And using the cached password doesn't mean having to unjoin/rejoin -
sometimes it's just a driver issue, or a certificate problem, or,
recently, someone turning on protocol inspection in the ESET client
which fubared lots of things...

Kurt

show

cjdavis posted this 2 weeks ago

Quick Note: I was able to use runas /netonly on a workgroup computer with a privileged user in the Protected Users group.

show

alexbarth posted this 2 weeks ago

We’re in a somewhat similar situation and went with Authentication Silos for our DA/EA accounts. I’m going to test your scenario when I have some time this afternoon. I’m under the impression that I won’t be

able to authenticate as the non-domain joined computer isn’t in the silo.

 



ALEX BARTH | ITS Systems - Shared Infrastructure

The University of Texas at Austin

|

alexbarth@xxxxxxxxxxxxxxxx
| utexas.edu



 

show

cjdavis posted this 2 weeks ago

The problem with this approach is that the Logon Type 9 event is not logged to the domain controller.  It is logged on the client; the domain controller only shows a standard logon event.

It may be possible to create an alert or rule that fired when the logon event happened on a non-domain controller, assuming that the domain controller event contained the necessary information (IP address, workstation name).

 

show

cjdavis posted this 2 weeks ago

I’m currently testing the use of Authentication Policy to restrict privileged accounts and have found that authentication is not possible from a workgroup computer when it is applied.

Are you using both silos and policies?

 

show

moter posted this 2 weeks ago

We are. Domain admin creds are only allowed to be used on PAWs and Domain Controllers.  Those are the only accounts in the Silo, the user accounts, the Privileged Access Workstations, and Domain Controllers.  It restricts the devices where DA creds can be used.  Our policy shortens the TGT lifetime to 2 hours and is applied to the silo. Todd Todd MoteITS Systems - Enterprise Systems ManagementThe University of Texas at Austinmoter@xxxxxxxxxxxxxxxx   

show

moter posted this 2 weeks ago

I should also mention that our Domain Admins are also in Protected Users. Todd 

show

cjdavis posted this 2 weeks ago

Good to know.

For how long did you have the authentication policy in audit mode before moving to enforcement?

 

I’d also be interested in knowing who else is using Authentication Policy/Silos to prevent this issue.  The article I included in my original email mentioned Authentication Silos but only to say that they had not reliably blocked the runas

/netonly workaround.

 

show

moter posted this 2 weeks ago

I did Alex’s test and tried this on a non-domain joined Windows 10 vm with privileged credentials.   runas /netonly /user:DOMAIN\privileged-user-account powershell.exe to my surprise a powershell window opened and even said in the title bar “Administrator:powershell.exe (running as DOMAIN\ privileged -user-acount) but running whoami at the prompt revealed <Computername>\administrator as the context, and I cannot browse anything domain joined from the window. It appears that the context used is whatever the context of the original cmd or powershell was.  Further, the same behavior happens when I put in a bogus password.  I also tried from a domain joined computer and it “failed” in the same way.  Though nothing was output from either about success or failure to authenticate as the supplied user.  I suspect authenticating is never successful, and it just runs the requested command, in whatever context it’s got, anyway. When you try to log on to windows when an account is in a silo on a computer that is not, it tells you that you aren’t allowed to. I did all of our testing on our test domain with policies and silos and worked out how they worked and the rules around them before I implemented them in prod, but when I did implement them, we started out at enforcing.  There are some things that you have to have in place to get them to work, but they do work as advertised. Todd  

show

cjdavis posted this 2 weeks ago

This is a change in the behavior of previous Windows versions; prior to Windows 10 if you ran runas /netonly /user:DOMAIN\privilegedaccount program.exe and entered an incorrect password, program.exe would fail.

 

And, to clarify, even though the title bar will say that it is running as DOMAIN\privilegedaccount, said account is only used for network connections.

 

show

Close