In the spirit of distracting myself from Doom Scrolling, let's talk about a feature that is super useful that many folks don't really know a lot about: Remote Credential Guard.

I've gone into relatively great detail about all the different stages of Windows auth and I encourage everyone to read through the posts because there's literally centuries of dev hours put into building all of this and it's complex.

The first thing is how does basic sign on work? What Happens When you Type Your Password into Windows? (syfuhs.net)

The second is how does basic RDP authentication work? How Authentication Works when you use Remote Desktop (syfuhs.net)

The third one is how does Credential Guard work? How Windows Defender Credential Guard Works (syfuhs.net)

The fourth one is What is the LSA? A Bit About the Local Security Authority (syfuhs.net)

Now, since I don't expect everyone to go off and read those let's summarize a bit.

In a normal world you type your password into Windows and that kicks off a bunch of machinery that verifies the credential, sets up your logon session, creates your desktop, etc.

RDP does the exact same thing, except it has a precursor step that makes sure you're sending the password to the right computer called NLA. After, the RDP client literally sends the password you typed in across the network to the remote machine.

The remote machine effectively does the equivalent of typing that password into a credential provider for you, kicking off all the logon machinery. This is super important because the password unlocks all sorts of important systems within your logon session.

There are things like DPAPI that are bound to your credential. SSO using Kerberos or NTLM require the password to get a TGT or challenge. It's a fairly important prerequisite. How Windows Single Sign-On Works (syfuhs.net)

It turns out this is really rather dangerous if you don't trust that remote machine, because it has your password now whether you like it or not. Incidentally this is why keeping NLA on all the time is important.

So, what do we do about it? Well, if we go back to how Credential Guard works, we have this concept of a tiny locked down VM running beside your regular session where you can periodically ask it certain specific questions.

1. Can you encrypt/decrypt this for me? (Yes)
2. Can you give me my password to send to this other machine (NO!)
3. Can you store this session key so attackers can't steal it? (Yes)

Yadda yadda yadda.

Coding-wise it was implemented [more or less] as an interface of questions you can ask. We have two implementations: the first is the one LSA uses when CG is off. Things just stay in LSA memory. The second lives in LsaIso, where LSA interacts with it over Hyper-V-provided RPC.

When CG is on, LSA knows to call the RPC version, otherwise it calls the normal-world version. Most important secret-y things travel through this interface.

Only LSA can call the interface implementations, so at worst you're still protected from normal attacks because you must first breach LSA before doing anything interesting. 

Which, by the way go turn on LSA PPL please.

The engineering value behind this design is also super high because it makes it clear who is responsible for what security decisions. I'm very proud of the devs that designed and built this because it was a monumental engineering task.

Anyway. 

So, you have:
Password => LSA => Cred Guard

Cred Guard <=interface=> LSA <=> Apps

Now we introduce RDP. On the target machine it works exactly the same way, except that password came from a remote machine.

What if we did this?

Client:

Password => LSA => Cred Guard [client machine]

RDP Server:

Cred Guard [client machine] <=RDP interface=> LSA <=> Apps

[thinking.gif]

Remember that interface thingy that LSA calls? What if we built a 3rd interface that instead of doing things in memory, or RPC over Hyper-V, it does it with RPC over the RDP transport whatsits (I can't remember what they're called).

Now your creds stay on the client, and whenever the RDP target needs to use those secrets for whatever reason it asks LSA as usual, LSA asks the interface, and it just happens that the interface implementation lives on the other side of the world in your client machine.

[mindblown.gif]

And so we have Remote Credential Guard.

Now, obviously this is not a fool-proof solution to all security problems. You have full SSO to all things on the remote machine just as if you typed in your password. That means something on that machine can do something malicious as you via SSO.

But they can only do it for as long as your session is active. Once you disconnect, the connection to the client LSA is dead. Requesting new tickets fails. The target machine's ticket cache is also useless because it requires Cred Guard to function. NTLM has no ntowf.