 So uh you're here to listen to a talk about uh Microsoft Secure Channel and uh 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 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 a 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 team viewer don't get tracked. So you're probably wondering well what does? Well again Internet Explorer, Skype, everything that you saw in the um in the uh intro there, LDAPS um and then 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 into 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 cypress suite. So you have an example cypress suite at the bottom, TLS is the protocol, ECDHE is the key exchange, it's not actually a key exchange 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 becomes the pre-master key uh encrypts that and ships it back to the server. The server then uses the private key to encrypt 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 a type of key exchange we use so if we're not using RSA it's going to be 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 who 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 if we 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 high high 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 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 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 Diffy Helm uh Whitfield Diffy of the Diffy Helm and Key Exchange back when DEF CON started put out a paper that said RSA is probably not perfect forward secret and what is 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 there was a secret over the wire they actually just use public values in the communicative properties of exponents to actually exchange only public values and derive a shared secret so there's not actually key exchange just sort of 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 it's over an unsecured channel and we shouldn't be um reusing keys especially not something that we store on disk right and to take that to a lot it's logical conclusion we should actually use a key once and then throw it away never never use it again so that we insulate all those connections so if you're truly perfect for a 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 we're using like an ephemeral diffie helmet 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 that session 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 talked about RSA but there's this extension called session tickets which you've probably heard of as well and the basic principle is uh I as a server don't have to deal with all your client crap I don't want to store your master secrets so I'm just going to encrypt it and send it back to you well just like sending the pre-master secret if we're sending 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 the benefit of it is essentially that now server you can have multiple servers that you load balance and they can resume each other's sessions if they just share that one session ticket key that's in memory so 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 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 for a secret or is it mostly perfect for a secret so the talk the title is S-channel uh whatever soliciting S-channel soliciting secrets from S-channel um so what is S-channel what is C and G so secure channel is again Microsoft 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 use their private keys so they maintain 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 gonna be it's it's LSAS um and so S-channel itself again gets loaded into both of those 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 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 manage that tunnel um but it doesn't actually handle any of the encryption itself or any of the the ciphers itself that's all handled through the C-N-G which is the crypto API next generation so C-N-G again next generation is all the best generation um it was introduced in Vista so believe it or not there's there's a use there's a use to all those years of blue screening that you had to deal with um it it brought around things like AES um and uh elliptic crypto to Microsoft and really modernize their capabilities as far as cipher suites go um and C-N-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 was it 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'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 after the introduction of C-N-G so again we talked about how they introduced C-C-C so what you see in Vista uh they're preferred cipher suites they don't prefer uh a thermal suites they don't prefer elliptic curved 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 the symmetric suite that we prefer the symmetric 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 wanted to encrypt things and that's why uh that's part of the reason that Contexus I think open sourced their 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 RSA private key to encrypt things anymore for the most part with Microsoft and we know that um there that in theory TLS allows you to cache things so it does ask 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 the 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 as channel or yeah LSAS is gonna store um 20,000 uh entries so that's maybe not a lot for a server but it's a lot for a client um and a reasonable amount for a server so how does that 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 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 uh some symmetric keys LSAS is the 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 wanna look and where we might find things so CNG how does that work essentially everything gets routed through Encrypt the Encrypt DLL that's kinda really useful for the for the reversing aspect because that kinda told you told me where to look um and then there there's this whole key isolation service and we have these key storage providers again that then manage those secrets and memory and on disk so just as a quick summary 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 again why do we wanna do this what's the value well we wanna be able to subvert perfect forward secrecy that's the point like now that we know that channel braces that we wanna get around that we also even if we can't do that we wanna see is there any forensic context to be had is there anything we can do with that it would be a value and how long does that live um and then finally again from a bad guy's perspective it's kinda 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 for just using RSA we'll have a persistent private key and if we're using session tickets there's gonna be this session ticket key right so that's all the possible secrets we could have uh for a 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 gonna get us much you're gonna get a single connection uh the master key and the pre master key are gonna get us a single session uh and then the ephemeral key and the uh the pre master uh 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 they're sitting in memory inside LSS memory um and they're named based on either 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 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 gonna 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 we'll explain that too so how do we get 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 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 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 scan 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 indian and it's SSL three and I was like aha Eureka SSL three this is you know this is cool uh maybe but I was weird because I was the 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 B-crypt key structure and if you've ever played around in the back in a Mimikatz you know that B-crypt keys are used everywhere in LSAS they're superfluous uh and that's superfluous they're they're just everywhere um and Benjamin Delphi did a lot of research on reversing those I actually then did it myself because I didn't actually source code until after I kind of 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 B-crypt key and I think he calls the other one a B-crypt 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 uh and then the thing highlighted in red is the actual key itself cool so I mentioned these these these magic values this 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 what 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 three 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 a size values and function names that are very descriptive uh for specific structures so we kind of know now that that that this SSL five magic value is going to be tied to a master key and we know that SSL four is going to be tied to a key pair whatever that is um which turns out to be the private key and then uh SSL six is for the ephemeral key. Now SSL three didn't actually have one of these uh I just happened to come across one of those 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 seven and that is the pre-master secret so pre-master secret we don't actually really need because it it literally is per connection and gets used only to generate that that's master secret that's always going to be the same length because the pre-master secrets variable based on um again what key change we're using using ECC it's going to be the x coordinate of the shared secret that we derived um so basically it's vestigial we don't really need it we have if we can get the master key which we can get uh so so SSL seven is only used uh for the RSA pre-master secret and on top of that 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 will you'll never see it in memory it's kind of too beautiful to live or whatever so master secret uh basically this is this is the goalie lock 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 cipher 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 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 wind debug and the reason that I did that is I had the full commands there so once you have the slides you can actually go through and validate my work yourself um or you can 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 cipher 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 unique value what you do well you scan scan for pointers to the structure right in memory and what I was able to find is kind of similar to how the be crypt keys work and crypt keys which I'm guessing means network uh 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 kind of found it because I was able to to see uh session IDs directly below and you might be wondering how do you see session IDs 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 belongs to and we can do that by just the quickest way to do it is really just to dump it out in wire shark format and open up a wire shark and 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 the master secret sorry we could really stop there at this point because I mean we we can decrypt sessions this that's great but why do you that when there's other things to be had so there's this ephemeral key right in this persistent private key and depending again on the key strings that we use um they're going to be uh one may exist or one may uh may not exist um but they share the same structure because they perform the same function so uh there's this SSL key pair structure that again 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 got a different magic value and slightly different structure and that points to this KSPK structure um and you're like that's not how you spell key storage provider like but it's because it's backwards and again because it's a little endian so this case 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 little endian nothing else for Microsoft is stored 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 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 use later on in in the talk and um and basically uh once we have this what can we do with it right? A wire shark 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 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 it's kind of great so 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 DP API well if you've ever done anything with DP API 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 DP API 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 because we want to be able to get this trade out of memory well up there you see highlighted in red is the key good out of the DP API 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 DP API 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 decrypt the blob trade out of memory and when you do that you get this so on the one side we have the RSA 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 RSA 2 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 kind of 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 widespread use it seems like the support for it's a little bit um 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 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 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 instead of two set it to one 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 friends with guy um now 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 uncrypted 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 that the Microsoft approved way to do it which I can't say that it is um the administrator managed session key gets stored 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 and windows not just for IAS it happens for IAS 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 command lit 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 which gets stored in the uh the session ticket key session ticket that gets sent across the wire then we can actually just uh reference that because we know um because I know what the structure looks like and I know the offset so what do their session tickets look like? The session tickets are actually they're cool 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 IV in there which is that they're supposed to have and because they have key guru and because we can pull that key out of memory we can then go directly from having something on the wire to what the 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've 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 why we have the context so core TLS is self functionality that provides metadata that we can use while time stamps typically get uh are the first 4 bytes of a uh of a 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 performs an operation as uh said by these these uh people that wrote the dual e-c paper so that the 2 bytes um the second 2 the first 2 bytes are random the second 2 bytes are zero and then the rest of its 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 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 it goes 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 you were talking to um not just the IP that you were talking to so how does it how long does this whole thing actually get cached we talk about what the spec allows what is 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 memory the client lifespan server lifespan and the session ticket lifespan and those are all 10 hours by default so what that is is the maximum time that you have one of these in memory so you don't get the full 24 like you well 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 and if you don't have to pack it 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 override it in memory or you can override it in the registry um and that's set to 20,000 entries entries by the fault um and then the other thing is enable session tickets uh is is a 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 cleanup interval which is how often uh this this cleanup uh thing runs so if you as the process decommission or uh purge your cache then there's a possibility it might stay around for a tiny little while before that 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 kind of depends and the other kind of unfortunate thing is that um because we're centralizing this 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 IAS things like uh most of the sort of services that we're interested in even 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 purchase 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 uh a lot of these symbols have a C pretty fixing them that's because they're a 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 the very first thing that gets stored is that VF table the next thing is 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 the things I know about um you also have uh the process ID and then that that log on session ID 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 there will be the uh actual uh session ID itself stored as a as an array directly in that structure if that's what's used and then on the server side it's again it's a lot smaller you're not gonna have session ticket pointer because they don't get stored on the server um but you'll have think 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 seems so it uses uh just a list structure so once you find one cash item you just loop through the the list entry and you can find all the other ones which is nice um so yeah so how do that's cool on all the how do we automate that how do we actually make that useful so what I'm providing is a volatility plugin and I'm providing a recall plugin as well to automate that and by the fall it's just gonna dump out the uh that wire strike 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 power shell module that will 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 and 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 hosted or updated some that aren't and the cache is gonna 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 ID it does affect how session tickets get parsed you can still do it um it's just harder 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 do some of this pretty easily they can also take them away which is totally there right um but realistically that probably isn't gonna have that much of an impact because most probably can do all this stuff still uh just a little bit less efficiently um and then you need to be able to read LSAS 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 you're moving through something but the reality is that like in 2016 again everybody runs many many many cats and things like that getting access to LSAS 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 gonna simulate again capturing RAM and then um after we get that uh I'm gonna run the recall plug in so there's a there's a screenshot there with a volatility plug in and then I'm gonna basically just to show you both I'll go through recall as well and hopefully that will work okay cool so we see that it dumped out this 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 gonna be there is from the RDP session I made um so we're just gonna copy that into this demo file and read it out of the file hopefully don't tell me copy paste failed sorry live troubleshooting what's that restart what okay I got yeah yeah yeah 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 okay okay okay hold up a sec let me just see if what do I have mounted actually how much time do I have I know see I shouldn't 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 calorie really quick and just see how that goes the extended demo just because you're my favorite audience and in the meantime if anybody has questions about anything um please feel free to come up and ask the microphones up front in windows 10 microsoft started doing virtual virtualization based security to grab some of the L SAS decryption put them off like by the hypervisor the worst place for that to happen sorry go ahead have you looked to see if that affects any of the day you were able to pull yeah so uh I guess what I should say is I tested this with windows 7 and I tested with windows 8.1 but I mostly was working on windows 10 in the server 2016 preview and the hardest part was really the session tickets because I don't really know I wish that if there's a I just 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 everything was done on windows 10 was hyper V enabled what's that was hyper V enabled uh no I don't know I just probably probably not no okay cool okay well apparently I'm not going to get that functionality so uh I'm not gonna I'm gonna 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 okay so uh yeah anyway that's basically this is you can also see 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 that's on twitter and then thanks to these people for all their help I really appreciate it so that's it