Have you ever tried to access an admin SMB share on your local machine (\\localname\c$) only to find out you don't have admin perms despite being a local administrator? Why is that? Here's something you maybe didn't know: It's by design -- it's a way of preventing UAC bypass. pic.twitter.com/1SwNrWn4j8

— Steve Syfuhs (@SteveSyfuhs) January 19, 2021

Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.

You might be saying "well duh! That's what UAC does!" 

But we're talking SMB, so it's over the network, therefore it's Kerberos, and Kerberos can't doesn't do UAC over the network because Kerberos doesn't contain local authz information, and UAC is all about local authz.

Note: SMB loopback actually uses NTLM. But let's not let details get in the way of a good explainer. (NTLM does work similarly though)

What's the difference between \\localmachine\c$ and \\othermachine\c$ then? Actually, nothing.

Some background: when a client needs a kerb ticket to something it asks Windows. Windows creates an AP-REQ, which is the requested ticket plus authenticator.

The ticket is created by the KDC. The client can't see inside it, and can't manipulate it. It's opaque. However, the client can ask the KDC to include extra bits in the ticket. See here for fiddly details: A bit about Kerberos (syfuhs.net)

These extra bits are just a way to carry information from the client to the target service during authentication. As it happens one of the things the client always asks to include is a machine nonce.

See, when the client asks the client Kerberos stack for a ticket, the stack creates a random bit of data and stashes it in LSA and associates it to the currently logged on user. This is the nonce. This nonce is also stuck in the ticket, and then received by the target service.

The target service, i.e. the same Windows Kerberos stack, knows about this nonce and asks LSA if it happens to have this nonce stashed somewhere. If it doesn't, well, then it's another machine and just carry on as usual.

However, if it does have this nonce, LSA will inform the Kerberos stack that it originally came from user so and so, and most importantly that the user was *not* elevated at the time.

What does that mean? Not elevated?

This is UAC -- User Account Control. UAC is the thing that *tries* to prevent you from doing something stupid with admin privileges.

EsH59mLVEAAso1i.png

See, when you log onto Windows you're granted a set of local privileges. Some of these give you lots of control over the system, like local administrator. UAC is a way of preventing you from doing silly things as administrator unless you reeeeeeally want to.

The way it works is conceptually simple. During login you're given two NT tokens. The first is your high privilege token. It contains all those special privileges. The second is your low privilege token. Everything you do uses your low privilege token by default.

So when you do need to do something with higher privileges you need to ask Windows "Hey! I need the high privilege token, pleeeeeeeeeeeeease".

Anyway, LSA knows all about these tokens, so when it receives this Kerberos ticket and contains that nonce and finds the user, voila it has a low privilege token.

Now the Kerberos stack makes a copy of the ticket contents for it's own SSO session and whenever you do anything in that session, say try write to c$\windows\system32, the authorization system checks the privileges and in this case says nooooope. How Windows Single Sign-On Works (syfuhs.net)

So as a result you don't get to bypass UAC by going through the network. /fin