You're here to listen to a talk about Microsoft secure channel and you might be wondering
what RDP has to do with secure channel. Well secure channel is the TLS library for Windows
and RDP uses that. So that connection that we just saw uses an ephemeral key exchange and at
the very end of the talk the demo is we're going to decrypt that. So in the meantime the VM
that I just logged into is just going to sit there running and uh again we'll explain how
that all works. So uh very quickly uh what do you get out of the talk? Well I just told
you uh we're going to be able to decrypt uh sessions that use uh TLS sessions that use
ephemeral key exchanges and we're going to be able to pull the private certificate and the
session ticket key directly out of memory as well. Uh and then from a forensics perspective
it's kind of cool we can map uh public certificates slash server name indicators um both of
those to a process ID and a logon ID and I'm not talking about like a user ID I'm talking
about the logon session ID which is unique for each login. So let's talk about how we get
there. Um very quickly we're going to talk about how we get there. Um very quickly we're
going to go over TLS and SSL I know you all know what that is you've seen it a billion times
but it's Saturday at DEF CON so few brain cells lost. Um we're then going to go through S
channel and C and G and what those actually are what those words mean and how they relate to
what we're going to be doing and then we'll talk about the secret data uh and all the things
we're going to pull out and the forensic context and then finally that demo. So quick disclaimer
it's not an exploit and actually Microsoft hasn't done anything wrong despite what we're
going to be able to do for the most part there's one kind of exception to that that we'll talk
about which is a little like eh. Um but mainly just implementation specific oddities. Um and
then Windows isn't going to track uh sessions for processes that don't use their TLS library
which should kind of go without saying but just full disclosure. Um and also things that aren't
TLS aren't going to be tracked either so things like TeamViewer don't get tracked. So you're
probably wondering well what does? Well again Internet Explorer, Skype, everything that you saw
on the um in the uh intro there LDAP S um and then you're probably wondering well what does?
Uh third party products as well anything dot net and then third party products like um uh go to
meeting and things like that. So cool. Background. What is this TLS thing that we all know what
it is? Um so I'm not going to walk you through the handshake but uh the thing that we need to
pay attention to for the purposes of the talk are there's a uh there's a key exchange that
happens right? That key exchange gets dictated in the cypher suite. So you have an example
cypher suite at the bottom, TLS is the protocol, ECDHE is the key exchange and then there's a
key exchange it's not actually a key exchange it's just an exchange um and uh no matter what
we're going to have a client key exchange that happens uh as part of whatever key exchange we
have whether it's RSA or Diffie-Hellman or whatever. Um but how that what that looks like
is going to change so and it's going to and it's also going to change what's in memory. Um so
we're going to focus on RSA for just a second and then we'll move into the rest and there's a
reason for that. Uh but basically if we're doing an RSA key exchange server in the hello says
proof of who I am here's your public certificate client yanks the key the public key out of that
certificate uh generates random data uh that's becomes the pre-master key uh encrypts that and
ships it back to the server. The server then uses the private key to decrypt that and uh
voila we have a shared secret over an insecure channel. Very cool. Except uh the shared secret
is going to be different depending on the type of key exchange we use. If we're not using RSA
it's going to be a different length because it's derived differently. So then we turn that into a
master secret. And the master secret um is actually our shared secret that we're going to use to
derive session keys each time. We're just going to mix in some public values and stamp out some
session keys and start doing our symmetric crypto. So that's all good and well but it kind of
takes a long time. Um especially if you know you've got those clients that are just pinging you
constantly and it's the same client over and over. So the guys that wrote SSL thought of that
and they decided that well let's do this let's implement something called session resumption
where if we since we've already done it once and done this the the full key exchange once at least if we
store that for just a tiny period of time just a little bit then we can actually resume that we
can see a huge performance benefit. So uh how that works is basically the TLDR handshake is uh
hi hi uh the client comes up and says hey remember me I you gave me the session ID we met at
that party it was awesome uh you've got that secret that I also have can we talk. And server
says uh fine okay. And then they they mint out those session keys again using that shared secret
plus client random to uh.
To then uh um speak via an encrypted tunnel. So that's all good and well but you kind of
remember uh we we we mentioned RSA well there's this whole problem with we're sending that uh
we're sending that private key or that that pre-master key over the wire. That's not good
right? Because in theory because that the private key itself is sitting on disk we can then
decrypt that later and everybody's known about this for a while. So long in fact that uh Diffie
Helm uh Whitfield Diffie of the Diffie-Hellman Key Exchange back when
Defcon started put out a paper that said RSA is probably not perfect forward secret. And what
does perfect forward secret mean? Well what it means is uh if you and I are able to the property
of perfect forward secrecy is essentially if you and I are able to successfully exchange
secret material once um and it's secret at that time at no point in the future should anything
compromise the security of that uh exchange. So if a bad guy captures us is listening and uh
later on he gets the private key and can decrypt that which is how it's historically been
done um that that's bad that shouldn't be able to that shouldn't be able to happen. So they
actually instead of exchanging something um private uh that was a secret over the wire they
actually just use public values and the communicative properties of exponents to actually
exchange only public values and derive a shared secret. So there's not actually a key exchange
it's just sort of a a derivation process. Um but that's all magic that we don't need to talk
about. What we care about is the basic principle is we shouldn't be sending anything over the
wire that's secret um that's over an unsecured channel. Um so we don't need to talk about that.
And we shouldn't be um reusing keys especially not something that we store on disk right? And to
take that to it's logical conclusion we should actually use a key once and then throw it away
and never never use it again so that we insulate all those connections. So if you're truly
perfect port of secret that's what you'd have to do. Uh that's not actually what happens of
course. Uh the TLS spec allows for session resumption which is what we talked about. So it's
not storing something on disk most of the time uh but uh it is you know we're not talking about
the private key anymore if we're using a
like an ephemeral Diffie-Hellman exchange. But we are still caching those master secrets and
because we do that and in fact the spec allows you to do that for 24 hours um then we can still
within that time period go back and decrypt that section re- that session re- retroactively.
Or uh if we grab that out of memory before that time whatever that cache timer is expires we can
then decrypt future sessions as well because we now have that shared secret and in fact
potentially do bad things with them. So uh so that's one of the problems with TLS the other
one is obviously we talked about RSS. So uh so that's one of the problems with TLS the other
one is obviously we talked about RSS. So now I'm going to say, but there's this extension called
session ticket which you probably heard of as well. A basic principle is uh I as the
server don't have to deal with all your client crap. I don't want to store your master
secret so I'm just going to encrypt it and send it back to you. Well just like sending a
pre-master secret if perspective the encrypted master secret back and for the client to store
and then pass back to us when it wants to resume. That's kind of a problem but the benefit of
it is essentially that now server, you can have multiple servers that you load balance and
they can resume each others session if they just share that one session ticker key to 10
memory. So we're we're back to the problem with RSA but we're just using a more ephemeral key
basically. Um and then on top of that so that's just what TLS allows and just kind of the
normal normal go through but there's also implementation specific oddities and we're
going to get into that today specifically with Microsoft like storing symmetric keys uh
well symmetric key schedules. So the key itself is random but the the key schedule isn't and
also we talked about how you should really just reuse you should just use that ephemeral key
once uh but there's a little bit of reuse that happens and we'll see if that's you know is
that perfect forward secret or is it mostly perfect forward secret? So the talk the title is
S-channel uh whatever soliciting S-channel soliciting secrets from S-channel. Um so what
are what is S-channel what is C and G? So secure channel is again Microsoft's TLS library and
it gets loaded into the client process that actually wants to do the TLS exchange but
Microsoft doesn't really trust you and your little C sharp web server to uh use their
private keys.
So they maintain and and encapsulate all these keys in a security process called the key
isolation process. So if you've ever worked with Windows security uh you know what that's
going to be it's it's LSAS. Um and so S- that S-channel itself again gets loaded into both of
those and and then once the uh once the key change happens inside of LSAS it passes back the
security context for the connection that has all the the parameters and it passes back a um uh a
handle to the uh the AES keys well the symmetric keys so that you can actually do the
actually manage that tunnel. Um but it doesn't actually handle any of the encryption itself or
any of the the the ciphers itself that's all handled through the C and G which is the crypto API
next generation. So C and G again next generation is always the best generation. Um it was
introduced in Vista so believe it or not there's there's a there's a use to all those years of
blue screening that you had to deal with. Um it it brought a lot or brought around things like
AES um and uh elliptic curve crypto to Microsoft and really modernized their capabilities as far as
cipher suites go. Um and C and G basically has two functions. It stores things and then it
encrypts and decrypts things. So the encrypting and decrypting is done via DP API. Um again
Ellie Burstein who is was in Vegas recently uh he's the guy who did all the seminal research on
that so talk to him. Um and then uh but we we'll go over it as well. And then the key storage
providers actually handle the storing of those secrets. So what does that look like? Uh oh and
quickly okay so that's all good and well. Does S-channel actually embrace perfect forward
secrecy? And the answer is yes. Um Microsoft has embraced it one after the introduction of C and
G. So again we talked about how they introduced CCC. So you see in Vista uh their preferred
cipher suites. They don't prefer uh ephemeral suites. They don't prefer uh elliptic curve
suites because it was just introduced and Vista was broken enough. Um and then in Windows 7 and
Windows 10 they actually switched to just preferring those. And you also see that this metric
suite that we prefer this metric cipher that we prefer becomes almost exclusively AES. Um so
that's all good and well.
Um and basically what that means is that uh we can't do that we can't use that old RSA trick of
just grabbing the private key off disk anymore if we want to decrypt things. And that's why uh
that's part of the reason that Contexas I think open sourced their free their uh RDP replay tool
that we're gonna be modifying and using later. So we know that we can't use RSA any the the RSA
private key to decrypt things anymore for the most part with Microsoft. And we know that um
there that in theory TLS allows you to cache things. So does S-channel cache things? Well their
documents say yes it does. Uh there's a master secret um the cipher suite and certificates all
get stored uh after the first connection. After the first handshake between a client and a
server. And additionally you see in their documentation references to the fact that
LSAS consumes more memory. They tell us roughly how much it consumes. So we get an idea for what
this cache might look like. How big it might be. And uh and then they mention that by default
S-channel or yeah S- LSAS is gonna store um 20,000 uh uh entries. So that's maybe not a lot for a
server but it's not a lot for a server. And uh and then they mention that by default S-channel or
a server. But it's a lot for a client. Um and a reasonable amount for a server. So how does
S-channel actually operate? This is a very complicated looking Microsoft diagram that I made
pretty. Oh no. Oh no we're good. Uh and it's it hides a very simple truth. Which is
essentially that regardless of whether you're a client or a server it happens exactly like I
explained before. Uh client wants to make a connection uh says hey LSAS please give me uh a
security context and and uh some symmetric keys. LSAS says okay I'm gonna give you a security
context key exchange and on both sides that exact same process happens if they're both Windows
servers. So uh that kind of gives us an idea again of where we want to look and where we might
find things. So C and G how does that work? Essentially everything gets routed through
encrypt the encrypt DLL. That's kind of really useful for the for the reversing aspect
because that kind of told you told me where to look. Um and then there there's this whole key
isolation service and then we have these key storage providers again that then manage those
secrets in memory and on disk. So just as a quick summary. Uh we've got a lot of key storage
in memory. Uh we're looking at we're looking in LSAS we're looking for secrets and keys and
we're doing that because that's where the handshake happens and because uh uh S-channel prefers
ephemeral cipher suites in the handshake. Cool. So we'll again why do we want to do this?
What's the value? Well we want to be able to subvert perfect forward secrecy. That's the
point. Like now that we know that S-channel embraces it we want to get around that. We also
even if we can't do that we want to see is there any forensic context to be had and is there
anything we can do with that that would be of value and how long does that live? Um and then
finally as again from a bad guys perspective it's kind of cool if we could just get access to a
single process and dump out things we need to decrypt things in the future and in the past and
be able to impersonate the server if we can pull out the private key maybe. Um uh without
touching disk. So what do the secrets look like? So again based on what we've all talked about
right now we basically have a session we have session keys we have a pre a master key pre
master key those all exist on the client and the host after that initial exchange key exchange.
Um well through the process that we talked about. Um and then on the server there also could be
an ephemeral private key for using the ephemeral suite if we're just using RSA we'll have a
persistent private key and if we're using session tickets there's going to be this session
ticket key right? So that's all the possible secrets we could have uh for TLS connection. And
what do each of those get us? Well again we talked about the fact that uh session keys are
short lived they're not going to get us much you're going to get a single connection uh the
master key and the pre master key are going to get us a single session uh and then the ephemeral key and the
uh the pre master or the ephemeral key the private key persistent private key and the session
ticket key will all get us multiple sessions depending on what we what we're using and then on
top of that there's a that that persistent private key usually gets used for signing as well
so that'll get us identity for the server. So what do we get? We we got them all. We got
everything. So what you see up there is the pass to the keys uh that are sitting in memory inside
LSS memory um and they're named based on either uh the uh the password or the password of the
uh the name I gave the structure that I reversed or on the uh symbol name that Microsoft has
for for the uh the respective um structures. So anytime you see an uh an unlock symbol that
means that the that secret is sitting uh unencrypted in memory and obviously I know everybody
goes straight to the one that's got the lock sign and they're like what about that guy? Well
we're going to get to that that's actually not a problem either. Uh and then the one other thing
obviously is we see the pre master key down in the corner pre master secret sorry and uh you're
probably saying well you're cheating you said everything what about that guy and what about
that guy? And we'll explain that too. So how do we get fro to that point where we have
everything and and we know exactly how to get to it? Well I started with the session keys
because it's closest to the data, it's most ephemeral, it's not going to be encrypted because
it's a symmetric key that would be kind of not wouldn't make a lot of sense at least not in
software. Um so I started with AES because as we saw S-channel prefers AES for everything. Uh
but AES keys are small and random so I mean that's kind of a non-starter right? Well not
exactly. Uh so smart guys over at Princeton a while ago wrote a paper on uh called cold boot
attacks and they talked about the fact that a lot of implementations store uh this key
schedule. So AES gets expanded into round keys and that process is deterministic hence why it's
called a schedule. Um and because of that we can actually take that otherwise random data we can
calculate what the next item of based on that random chunk that we're looking at would be if it
if it would be part of the schedule and if it is then we have a really good chance that we have an
AES key. Uh so.
I basically just scanned the client server process and uh what you see there is matching AES keys
on each. So what does that give me? Well that allowed me then to go look at those offsets in
memory and start figuring out what the context of those were and how those were stored. You see
that there's four keys stored there uh that was actually two separate connections and remember
that when we're talking about TLS we have a server key right key and we have a client right key.
Uh so there's gonna be two AES keys for each. Uh but yeah so one thing that I noticed when I was
doing this and this is what the this is what the data structure looks like. So one thing that I
noticed when I was doing this.
Was that there is this magic value three LSS which is actually stored as a D word so flip that
around and that's uh little endian and it's SSL three. And I was like aha! Eureka! SSL three this
is you know this is cool. Uh maybe but it was weird because I was using it was a TLS 1.2
connection so I was like uh maybe they're just terrible at their naming conventions or
something. Um but I started scanning for SSL 2 and SSL 1 and everything else and what I was
actually able to find was that there's a there's SSL 1 through 7 so it's not the TLS version it's
something else entirely. Um but before we get to that.
Just quickly to go over this structure. Uh the session key structure itself has this magic
value. Right above it has a length value. It's got the protocol version which is the TLS
version. Um and then it's got a pointer to the cypher suite list so we know what kind of key
we're looking at basically. Um and then at the very end there's a there's a Boolean flag to say
whether or not it's the right key for client or server basically. Um and at the very end uh
there's a pointer to a bcrypt key structure. And if you've ever played around in the back end
of Mimikatz you know that bcrypt keys are used everywhere in LSAS. They're superfluous,
uh not superfluous they're just everywhere. Um and Benjamin Delphi did a lot of research on
reversing those. I actually then did it myself cause I didn't actually look at the source code
until after I had kinda gotten into it. But um but yeah so these things are kind of uh
consistent. And then on top of that he calls this MS symmetric key uh he calls it like a bcrypt
key and I think he calls the other one a bcrypt key handle. But the reason I call it that is
because of the symbols and memory. There's actually a validation function that says for this
magic value MSSK um validate mass uh symmetric key. So it's Microsoft symmetric key. Um so
then the thing highlighted in red is the actual key itself. Cool, so I mentioned these magic
values, these SSL values. How do these come into play? Well when I started looking at the
modules for these magic values just to see if I could pull apart the functions where they were
stored uh or that generated them. Um what I noticed was there's a few really really quick
validation functions that literally just do three things. They accept a pointer, they check the
size value of the structure at that pointer, and then they uh check the second value for
uh a magic value which is that SSL. Uh 3 or whatever the number is. So um so by looking by
dumping out the rest of those and then kind of looking at them they're all the same. And what
that gets us is it gets us size values and function names that are very descriptive uh for
specific structures. So we kind of know now that that that this SSL 5 magic value is going to be
tied to a master key. And we know that SSL 4 is going to be tied to a key pair or whatever that
is. Um which turns out to be the private key. And then uh SSL 6 is for the ephemeral key.
Now SSL 3 didn't actually have one of these. Uh it was I just happened to come across one I was
looking at other functions. But we we do see that it gets used in decrypt, encrypt, generate
session keys, and also I've just traced through and I know that those are the session keys. So
um the only other one up there that doesn't have uh anything is the SSL 7. And that is the
premaster secret. So premaster secret we don't actually really need because it it literally is
per connection and gets used only to generate that that master secret that's always gonna be the
same length because of the premaster secret's variable based on the size of that key. So it's
based on um again what key change we're using. We're using ECC it's gonna be the X coordinate of
the shared secret that we derived. Um so basically it's a sigil we don't really need it we have the
if we can get the master key which we can get. Uh so so SSL 7 is only used uh for the RSA
premaster secret. And on top of that it it gets destroyed very quickly. So uh they actually
follow the spec on this as soon as you've got the master secret you destroy it so you'll you'll
never see it in memory. It's kind of too beautiful to live with. So uh SSL 7 is basically a
password whatever. So master secret. Uh basically this is this is the Goldilocks secret. This
will get you multiple connections. It'll get you the whole length of the session. This is what
get cached, gets cached. Microsoft told us that in their documentation. And the it's it's
delightfully simplistic. Basically it just stores the master key directly in a um in an array
as part of the structure. Uh it it tells you the um the protocol version and it tells you the
cypher suite that you chose because obviously we need to take that master key, mix in some stuff
and mint out some session keys. Um but yeah so incredibly simple but the problem is and and if
we just have this right now we could actually then uh brute force a given session ID with that
master key uh with all the master keys in memory and potentially uh be able to decrypt it. But
it would be a lot more elegant if we could map it back to a unique value which is what we really
want to do. So this is what that looks like in memory. And what you're gonna see as we go
through is there's gonna be a lot of uh WinDebug and the reason that I did that is I have the full
commands there. So once you have the slides you can actually go through and validate my work
yourself. Uh so I'm gonna show you what that looks like in memory. Uh so I'm gonna show you
what that looks like in memory. Um or you could do it as you go along if you want. Uh but
yeah so that pointer again points to unicode string and points to a the uh identifier for
this the cypher suite version. Um but there's no other pointers out of the structure so we
have to figure out how we can map this to a unique value. What do you do? Well you scan scan
for pointers to the structure right? In memory. And what I was able to find is kinda similar to
how the vcrypt keys work. Ncrypt keys which I'm guessing means network uh crypt keys. Um
have a handle that then points to that secret. And if you go back from that you actually get to
the session key structure and I kinda found it because I was able to to see uh session ID's
directly below and you might be wondering how did you see session ID's? Uh they're supposed to
be random. Well they're not always random actually they're just arbitrary and we'll get into
that too. But basically what we have at this point in time is we have plain text. We can go from
a given session ID all the way through to a master key and uh we can then decrypt the session
that that belongs to. And we can do that by just using the key structure. So we can go from a given
session ID to a master key. And uh just the quickest way to do it is really just to dump it
out in wireshark format and open it up in wireshark and then it's instant. Instant gratification.
So which is exactly what we like. Um so yeah. So now we have master key and we could really
stop there. Master secret sorry. We could really stop there at this point because I mean we can
decrypt sessions that's great. But why do that when there's other things to be had? So there's
this ephemeral key right? And this persistent private key and depending again on the key
strings that we use. Um they're gonna be uh one may exist or one may uh one may not exist.
May not exist. Um but they share the same structure cause they perform the same function.
So uh there's this SSL key pair structure that again is is has a magic value of SSL4 or SSL6.
That points to an encrypt key handle which is not really the same as that encrypt SSL key that
we saw. It's it's got a different magic value and slightly different structure. And that points
to this KSPK structure. Um and you you're like that's not how you spell key storage provider.
Like but it's because it's backwards and again cause it's a little endian. So this KS or KPSK
structure is uh is the instantiation of the key from disk or the uh ephemeral key itself.
Um and it has all the values we need to really to do anything interesting with them. So that is
the key storage provider key. And uh and it's kind of the the thing that we're shooting for.
So the ephemeral private key itself uh that's what it looks like dumped out. It's stored a
little endian. Nothing else from Microsoft is stored a little endian uh for for the keys and
the secrets. So it kind of threw me off at first.
But I what I did there is I dumped out based on this uh this ephemeral key data class. I dumped
out the public key and then the generator values from the KSPK structure. So from that key
provider key storage provider structure. And then I dumped out the private key. So you could
basically then um assuming you knew the the large prime value. You could um take that private
key there and then uh generate that public key to verify that it is in fact a private key. So um
it's stored in this MSKY structure which you could see later on in in the talk. And uh uh it's uh
basically uh once we have this what can we do with it right? Wireshark doesn't support ECC keys
right now by default just to decrypt things like it does with with RSA private keys. But it
doesn't there's no reason that it can't. Um once we have this we can drop it into a pen
structure and we can kind of use it as we want. And because it gets reused and it gets stored in
memory um this gets us multiple sessions and it's kind of a it's kind of great. So it it's the
equivalent of what we would have had before with the RSA key if we were using an RSA key
exchange. So then the persistent private key itself. So now at this point we have all the ephemeral
things in theory. Other than that whole session key thing that we'll get to. Uh so but what
about impersonation of the server? What about that thing that little lock symbol that wasn't
unlocked that you guys are like yeah yeah yeah he's cheating. Well the uh the RSA key gets
pointed to you directly out of one of those KSPK structures the key storage provider and it's
encrypted in memory. So it's encrypted with DPAPI. Well if you've ever done anything with
DPAPI or if you've ever read any of again Ellie's work you'll you'll know that um there's
because it's encrypted as a system secret we can actually just grab
that uh system secret decrypt the DPAPI master key and use that to then decrypt this blob. So
you could go back to disk you could grab that and you could then just decrypt this but what's the
fun in that right? Cause we want to be able to get this straight out of memory. Well up there
you see highlighted in red is the key good out of the DPAPI blob. So what I did here was I scanned
the um I just scanned memory for the uh master key list which uh basically the master keys for
DPAPI get cached in memory um but they're encrypted. So Benjamin Delphi did a lot of work on
this and again this is one of those things where I looked into it and he beat me to it and he's he's
just a badass. Um so basically what you can do is you can take the uh there's there's there's uh
symbols that point to the uh initialization vector and the the symmetric key that then encrypt
these master keys. You can encrypt those and then use that to encrypt the blob straight out of
memory. And when you do that you get this. So on the one side we have the RSA and then we have the
uh key from disk itself. On the other hand we have what we decrypted out of memory and you
you'll know you've done it right if it's an RSA key because the uh the Microsoft structure
actually has this RSA2 magic value that you can just see. So um so at that point now we could we
can directly impersonate the server without our having to touch disk which is kinda cool. So
what about that session ticket thing? That's like the last thing that uh last secret that we have
to go over that we haven't really talked about yet. Um so it's not really seemingly in widespread
use. It's it seems like the support for it's a little bit um
well a little bit lacking. But uh well at least the documentation is for sure. So uh sometime
around Windows 8 and Server 2012 R2 Microsoft basically uh enabled the capability to uh to use
uh RFC 5077 which is the session keys. But they didn't actually provide any documentation with
how to use that. They did push out these PowerShell functions that you can uh you can use.
And what I've done there in that example is I've enabled those PowerShell functions or I've ran
those PowerShell commands that they give you as examples to create a session key. And I've
created a administrator managed session key. Ticket key. And then um uh and then enable it for
the for the account. But that doesn't actually enable it for the system. And they don't tell you
how to do that. But what they do tell you in the Windows 8.1 release uh preview release notes
is set this value to disable session tickets it's screwing things up. So taking the opposite of
that um I set it and set it to 2 set it to 1 and then next thing you know I'm able to actually
use uh session ticket keys. So up to this point even though things have been unencrypted in memory
and even though we can do bad things with them and that's cool or great things if you're a
forensic guy um Microsoft hasn't done anything wrong. I mean realistically those are short lived
uh short lived keys so in theory like it's fine to keep them unencrypted in memory and then the
one thing that does get stored on disk that they pull into memory they then encrypt even though
they store the keys to decrypt it. But the session ticket key is kind of that thing where
they they kind of mess up a little bit in my mind. But um if this is in fact the way the Microsoft
approved way to do it which I I can't say that it is um the administrator managed session key gets store to the session ticket key. The
on disk and it gets DP API protected right? Just like any other key that gets stored on disk. So we
can then pull that out and that key then gets derived or gets turned into an AES key through a
key derivation process. Um but that AES key is actually the same AES key across reboots which
basically means that if you enable session tickets and it happens at the S channel layer which
means that it happens for all services in Windows not just for IIS it happens for IIS and RDP and
everything else we talked about. Um then you if you can pull this key off disk via
I don't know the export TLS session ticket key function uh uh commandlet from PowerShell you
can then decrypt these just like it was an RSA key you can then decrypt those sessions which is
kind of crazy. So um so yeah uh they don't they they do cache this key in memory as well so we
don't have to go to disk to get it once we export it um but what we can do is we can pull it um we
can pull it out of the cache and uh there's no symbols for the cache but if we have the key
good which gets stored in the pa in the uh the session ticket key session ticket that gets sent
across the wire then we can actually just uh ref reference that because we know um because I
I know what the structure looks like and I know the offset. So what do the session tickets look
like? The session tickets are actually they're cool they're they flip the MAC above the
encrypted state so they don't have to change a bunch of things if they change the size of the
encrypted state which is great um and otherwise they follow the spec. But because they have the
ID in there which is what they're supposed to have and because they have key good and because
we can pull that key out of memory we can then go directly from having something on the wire to a
what this slide shows which is decrypting that uh session ticket and seeing what that value is and
as you'd expect it's just got that master key structure stored inside of it along with um things
like a time stamp and TLS protocol version and things like that. So um so yeah so at this point
we basically decrypted all the possible secrets that we need um out of memory. So secrets are
cool and all but what if you don't actually have a packet capture what if you don't want to
decrypt things in the future what if you don't care about any of that uh you just want to know
how this relates to forensics. Um well that's pretty much it. Thank you.
That's why we have the context. So core TLS SSL functionality that provides metadata that we can
use. Well time stamps typically get uh are are the first four bytes of a uh of a the random values
that get generated if you're following the spec. Um and then there are other things like
obviously the public key can be used for fingerprinting the server but the session ID can
also be used for fingerprinting the server because S-channel uniquely um creates these uh takes
the first D word and then does performs an operation on it as
uh said by these these uh people that wrote the dual EC paper so that the sec- the two bytes um
the second two the first two bytes are random the second two bytes are zero and then the rest of
it's random. So you get a very visually recognizable pattern um for the session uh session
IDs. And then uh on top of that obviously we have what TLS extensions offer themselves so we
have this concept of server name indicator and the cool thing about that is if we just run
something like con scan with volatility we we only get the IP address and we get the um the port that
we're talking to. But because we have the SNI if it's a virtual host and because we have the
public key we can then say okay well this is exactly who you're talking to or who who you were
talking to um not just the IP that you're talking to. So how does it how long does this
whole thing actually get cached? We talked about what the spec allows what is it what is it how
does it actually work what is it what what are the actual values? Um so there's these values get
stored in memory the client life span, server life span and the session ticket life span and
those are all 10 hours by default. So what that is is the maximum time that you'll have one of
these in memory. So you don't get the full amount of time that you'll have in memory so you don't get the full
24 like you well that you could get in theory for session ID lifetimes in the spec but you do get
10 hours which is still a lot especially if you're a guy doing IR and I don't know somebody RDPs
into your machine and then you get an alert on it and you want to go back and potentially pull the
memory from that machine um if you jumped to packet capture. Um so the other thing is uh the
maximum number of entries. So again this is uh this is hard coded into the S channel binary just
like that value above but you can overwrite it in memory or you can overwrite it in the
registry. Um and that's set to 20,000 entries. Entries that are set to 20,000 entries. So
that's set to 20,000 entries by default. Um and then the other thing is enable session tickets
uh is is uh in theory it's one two or zero presumably zero is undefined that's what it is by
default uh hard coded into the S channel binary. Um and if you don't change that to one then
session tickets don't seem to work. Um and then the uh there's a clean up interval which is how
often uh this this clean up uh thing runs. So if you as the process decommission or purge your
cache then there's a possibility it might stay around for a tiny little while. Um and then
that timer expires. Uh so as the process you have full control. S channel is still just the
library. So the processes can purge uh the cache whenever they want. So you might not get a full
10 hours it kinda depends. The other kind of unfortunate thing is that um because we're
centralizing this and because we track the processes themselves if the process uh dies it
seems that the cache gets completely cleared for that process. Uh but things like RDP things
like IIS things like uh most of the sort of services that we're interested in even you
know even something like Outlook runs as a service. So you uh you aren't gonna have that
problem basically. Um but they might also decide to purge the cache periodically at their
discretion. So what does the cache actually look like? Well as you see like it's as you saw
when I was talking about the keys um there's a lot of these symbols have a C prefix in them
that's because they're C++ class. Um and so the virtual function table gets stored at the top
and what that enables us to do is if we can use symbols we can actually just scan for instances
of that function in memory which is kind of cool. So that's a really cool feature. Um and
cool. So the very first thing that gets stored is that VF table. The next thing is a uh is a pointer
to the master key and again I haven't got the whole structure there which is why this is like a V
type a volatility V type so it just shows you the offsets to the things I know about. Um you
also have uh the process ID and then that that log on session ID UID that I was talking about
earlier which is kind of cool. And then the session ticket or the um the session there will be a
pointer to the session ticket if session tickets are used or they will be the uh actual uh session
ID itself stored as a as an array directly in that structure. So that's kind of what we're
going to do with the list structure if that's what's used. And then on the server side it's
again it's a lot smaller you're not going to have session ticket pointer because they don't get
stored on the server. Um but you'll have thing you'll still have that process ID and those
other kind of useful things. And then just because I had time, well didn't really have time
but just because I felt like I wanted to be thorough uh I also went and looked at Vista um and
basically Vista's kind of proto it's before it really becomes more object oriented so it it it
seems. So it uses uh just a list structure so once you find one cache item you just loop
through the the list.
And you can find all the other ones which is nice. Um so yeah so how do that's cool and all but
how do we automate that? How do we actually make that useful? So what I'm providing is a is a
volatility plugin and I'm providing a recall plugin as well to automate that and by default it's
just going to dump out the uh that wirestrike format we showed earlier. Um and then what I'd
like to do too is hopefully uh talk to Benjamin Delphi and see if he's interested or uh maybe
create a PowerShell module that'll do it live so you can actually just do it live as well. Um but
yeah. So limitations.
We're working with internal undocumented data structures for the most part which means that
they're subject to change. Um sometime in like I think it was March or April there was something
that was inserted midway through the cache and so you get to this position where you have you
know maybe some uh hosts that are updated and some that aren't and the cache is going to look
different which is kind of annoying. But it happens below the uh or I suppose after the session ID
so you don't really have to worry about it for session IDs it does affect how session tickets
get parsed. You can still do it um it's just harder to to detect that in an automated fashion it'll take
a little bit more it'll be a little less clean. Um and then we're relying on symbols so
Microsoft gave us symbols to to to do some of this pretty easily they can also take them away which
is totally their right. Um but realistically that probably isn't going to have that much of an
impact because in most part we can do all this stuff still uh just a little bit less efficiently.
Um and then you need to be able to read LSAT's memory which is kind of a big caveat when you're
talking about being able to exploit things right? So um well not exploit sorry just just when
you're pen testing or moving through something. But the reality is that like in 2016 again everybody
was using the memory card and things like that. Getting access to LSAT's isn't that hard if you
have administrative access to the box. But it does mean that this is probably a little bit more
useful in a forensic context than it is anything else. So and with that let's get back to the demo.
So I'm going to simulate again capturing RAM and then um when we after we get that uh I'm going to
run the recall plugin so there's a there's a screenshot there of the volatility plugin and
then I'm going to basically just to show you both I'll go through recall and then I'll run the
recall plugin as well. And hopefully that will work.
Okay cool so we see that it dumped out this uh single session ID and again the reason that this
is uh there's only one is because I'm not connected to the internet intentionally. Um so that's
the only the only one that that's going to be there is from the RDP session I made. Um so we're
just going to copy that into this demo file and read it out of the file. Uh hopefully. No.
Don't tell me copy paste failed.
Oh you gotta be kidding me. Okay. Hold on.
Sorry. A lot of troubleshooting.
What's that?
Restart what?
Okay. I got it. I got it. Okay cool. Oh the joys of open source software.
Oh we're so close and it's not even the hard part of the demo. This is like literally the
basics. No. Okay. Okay. Okay. Hold up a sec. Let me just see if. Uh. Okay. Okay. Okay. Okay.
What do I have mounted actually? No. No. How much time do I have? I know. See I shouldn't
have, I shouldn't have antagonized them. That was my own fault. Okay so. Tell you what since we
already have it let's just, do you guys mind if I reboot, reboot Kali really quick and just see
how that goes?
Okay.
Alright so I've got, uh. I've got the remote. I'll take a look at the extended demo just
because you're my favorite audience. In the meantime if anybody has questions about anything
um. Please feel free to come up and ask. The microphone is up front.
In Windows 10 Microsoft started doing virtualization based security to grab some of the
LSAS secrets and put them off like protected by the hypervisor. Worst place for that to
happen. Sorry go ahead. Uh have you looked to see if that affects any of the data you were
able to pull? Yeah so uh I guess what I should say is I I've tested this with Windows 7 and I've
tested it with Windows 8.1 but I mostly was working on Windows 10 and Server 2016 preview and
the hardest part was really the session tickets because I don't really know I wish that if
there was a I just want to make sure that I'm doing it right so I wish that there was a way
that said this is exactly how it should be done. Um but yeah no I I everything was done on
Windows 10. Was Hyper-V enabled? What's that? Was Hyper-V enabled? Uh no I I don't know I
just probably probably not no. Okay cool. Oh yeah correct correct yep. Okay. God. Okay
well apparently I'm not going to get that functionality so uh I'm not going to
I'm going to spare you me standing up here and typing it by hand uh but if you want to see the
demo I guess come to me afterwards and uh and I'll show you. Bullshit. Okay. So uh yeah
anyway that's basically this is you can also see it in Wireshark and just see the keystrokes
going across uh which is what that is um and that's the that's it so you can find me on
TinRabbit uh underscore at um at on Twitter and then thanks to these people for all their help I
really appreciate it. So that's it.