00:00:00.234,00:00:05.138 > You are here to listen to a talk about Microsoft Secure Channel and you might be 00:00:05.138,00:00:09.676 wondering what RDP has to do with secure channel, well secure channel is the TLS library for 00:00:09.676,00:00:14.414 Windows and RDP uses that. So that connection that we just saw, uses an Ephemeral key 00:00:14.414,00:00:18.252 exchange and at the very end of the talk the demo is, we are going to decrypt that. So in the 00:00:18.252,00:00:22.322 meantime the VM I just logged into is just gonna sit there running, and again we will 00:00:22.322,00:00:28.128 explain how that all works. So uhh very quickly. What do you get out of the talk? Well I just 00:00:28.128,00:00:32.366 told you. We are going to be able to decrypt uhh sessions that use..TLS sessions that use 00:00:32.366,00:00:37.070 Ephemeral key exchanges, and we are going to be able to pull the private certificate and the 00:00:37.070,00:00:41.675 session ticket key directly out of memory as well. Uhhh and then from a forensics perspective 00:00:41.675,00:00:46.546 it's kinda cool, we can map public certificates slash server name indicators, um both of 00:00:46.546,00:00:50.550 those to; a process ID and a logon ID. And I'm not talking about not talking about like a 00:00:50.550,00:00:54.955 user ID, I'm talking about the logon session ID which is unique per each login. So let's talk 00:00:54.955,00:01:00.027 about how we get there. Umm very quickly we are going to go over TLS and SSL, I know you all know 00:01:00.027,00:01:05.732 what that is, you've seen it a billion times, but it's Saturday at Defcon, so few brain cells 00:01:05.732,00:01:10.537 lost. So then we are going to go through s-channels and CNG and what those actually are, what 00:01:10.537,00:01:13.373 those words mean, how they relate to what we are going to be doing. And then we'll talk 00:01:13.373,00:01:18.378 about secret data and all the things we are gonna pull out in the forensic context. And then 00:01:18.378,00:01:23.283 finally that demo. Okay. So quick disclaimer, it's not an exploit, and actually Microsoft 00:01:23.283,00:01:26.420 hasn't done anything wrong, despite what we are going to be able to do, for the most part. 00:01:26.420,00:01:29.623 Theres one kinda exception to that and we'll talk about it because it's a little like 00:01:29.623,00:01:34.795 uhhhhhg. Um but mainly implementation specific oddities. Umm and then Windows 00:01:34.795,00:01:39.199 isn't going to track uhhh sessions for processes that don't use they're TLS library, 00:01:39.199,00:01:43.737 which kind of goes without saying, but just full disclosure. And also things that 00:01:43.737,00:01:47.741 aren't TLS aren't going to be tracked either so, things like Teamviewer don't get tracked. So 00:01:47.741,00:01:52.012 you are probably wondering what does? Well again, Internet Explorer, Skype, everything you 00:01:52.012,00:01:57.017 that you saw in the uhhh...ummm...in the intro there, LDAPS. And then uhhhh 00:01:59.286,00:02:03.123 third party products as well, anything dot net. And then third party products like gotomeeting 00:02:03.123,00:02:09.896 and things like that, so. Cool background. What is this TLS thing that we all know what it 00:02:09.896,00:02:15.268 is. Um so I'm not gonna walk you through the handshake, but uhhh the thing we need to pay 00:02:15.268,00:02:20.874 attention to for the purposes of the talk are: there's a uhhhh key exchange that happens right? 00:02:20.874,00:02:24.945 THe key exchange gets dictated in the cipher suite. You have an example cipher suite at the 00:02:24.945,00:02:29.516 bottom, TLS is the protocol, ECDHE is the key exchange, it's not exactly the key exchange, 00:02:29.516,00:02:35.355 its just and exchange. Uhhhh no matter what, we are going to have a client key exchange that 00:02:35.355,00:02:39.960 happens, as part of whatever key exchange we have. Whether its RSA, or diffie hellman or 00:02:39.960,00:02:44.965 whatever. Ummm but how that...what that looks like is gonna change, so...and it's 00:02:44.965,00:02:50.103 gonna dic..its also gonna change what's in memory. Umm so we are gonna focus on RSA for just a 00:02:50.103,00:02:53.273 second and then we are gonna move onto the rest, there is a reason for that. But basically 00:02:53.273,00:02:59.012 if we are doing a RSA key exchange, the server in the hello says proof of who I am 00:02:59.012,00:03:02.482 here is your public certificate, client yanks the key...the public key out of that 00:03:02.482,00:03:07.754 certificate, uhhh generates random data, that becomes the pre-master key. Encrypts that 00:03:07.754,00:03:13.994 and ships it back to the server. The server then uses the private key to decrypt that and ummm 00:03:13.994,00:03:19.366 well uhh we have a shared secret over an insecure channel. Except the shared secret is gonna be 00:03:19.366,00:03:24.738 different depending on the kind of key exchange we use. If we don't use RSA it will be 00:03:24.738,00:03:28.809 different length, because it's derived differently. So we turn that into a master secret, and 00:03:28.809,00:03:32.479 the master secret is actually our shared secret that we are going to use to derive sessions 00:03:32.479,00:03:36.049 keys each time. We are just gonna mix in some public values and stamp out some session keys 00:03:36.049,00:03:40.854 and stamp out our symmetric crypto. So that's all good and well, but it kind of takes a 00:03:40.854,00:03:45.425 long time. Umm especially if you have those clients that are just pinging you constantly and it's 00:03:45.425,00:03:49.563 the same client over and over. Well the guys at wrote SSL thought of that and they decided 00:03:49.563,00:03:53.533 that well let's do this, let's implement something called session resumption, where if 00:03:53.533,00:03:57.671 we...since we've already done it once, and we've done this full key exchange once, and if we 00:03:57.671,00:04:02.175 store that for just a tiny period of time, just a little bit, then we can actually resume 00:04:02.175,00:04:08.582 that and see huge performance benefit. So ummm how thats works, the TL DR handshake is 00:04:08.582,00:04:14.688 uhh hi hi, the client says hey remember me, I...you gave me that session ID, we met at that 00:04:14.688,00:04:19.693 party, it was awesome, you have that secret that I also have can we talk? And server says, meh 00:04:22.129,00:04:25.966 fine okay. And then they mint out that session keys again, using that shared secret plus 00:04:25.966,00:04:30.971 client random to ummm...uhhh...ummm speak the encrypted tunnel. That's all 00:04:34.441,00:04:38.645 good and well but you've got to remember, uhhh we mentioned RSA. There's this whole problem we 00:04:38.645,00:04:45.352 are sending that...uhh..that private key...or that pre-master key over the wire. That's not 00:04:45.352,00:04:49.990 good cause in theory, because that private key is stored on disk, we can decrypt that then 00:04:49.990,00:04:52.726 later. And everybody has know about this for a while, so long in fact that Diffe 00:04:52.726,00:04:59.032 Hell...Whitfield Diffie of the Diffie Hellman key exchange, back when Defcon started put out 00:04:59.032,00:05:05.205 a paper said RSA is probably not, perfect forward secret. And what does perfect forward secret 00:05:05.205,00:05:10.277 mean? Well what it means is uhhh if you and I are able to...the property of perfect forward 00:05:10.277,00:05:15.382 secrecy is essentially if you and I are successfully able to share secret material once, ummm 00:05:15.382,00:05:19.386 and its secret at that time, in no point in the future should anything compromise the security 00:05:19.386,00:05:25.192 of that exchange. So uhh if a bad guy captures us and is listening, and later on he gets 00:05:25.192,00:05:30.096 the private key and can decrypt that, which historically is how it's been done, thats bad. That 00:05:30.096,00:05:35.936 shouldn't be able to happen. SO they actually instead of exchanging something private, 00:05:35.936,00:05:40.307 uhhh there was a secret over the wire, they actually use public values in the commutative 00:05:40.307,00:05:44.144 properties of the exponents to actually change exchange only public values and derive a 00:05:44.144,00:05:47.847 shared secret. So there's not actually key exchange, it's just sort of a derivation process. 00:05:47.847,00:05:51.318 Ummm but thats all magic we don't need to talk about. What we care about is the basic 00:05:51.318,00:05:53.320 principle is, we shouldn't be sending anything over the wire thats secret, ummm over an 00:05:53.320,00:05:58.325 unsecure channel and we shouldn't be, ummm reusing keys, especially not something we 00:06:01.828,00:06:06.933 store on disk right? And to take that to its logical conclusion we should actually use a key 00:06:06.933,00:06:11.371 once and throw it away, never never use it again, so we insulate all those connections. 00:06:11.371,00:06:15.008 So if you are truly perfect forward secret that's what you would have to do. That's not 00:06:15.008,00:06:18.345 actually what happens of course. Uhhh the TLS spec allows for session resumption, which is 00:06:18.345,00:06:23.350 what we talked about, so it's not storing something on disk most of the time, but it is you 00:06:25.785,00:06:29.456 know, we aren't talking about the private key anymore for using like a Ephemeral Diffie 00:06:29.456,00:06:32.459 Hellman exchange, but we are still catching those master secrets. And because we do that 00:06:32.459,00:06:38.732 and in fact the spec allows you to do that for 24 hours, ummm then we can still in that time 00:06:38.732,00:06:43.970 period go back and decrypt that section...that session retroactively. Or if we grab 00:06:43.970,00:06:49.075 that out of memory before that time, whatever that cache timer is, expired we can decrypt 00:06:49.075,00:06:52.912 future sessions as well, because we now have that shared secret. And in fact do potentially bad 00:06:52.912,00:06:57.250 things with them. So umm that's one of the problems with TLS, the other one is obviously we 00:06:57.250,00:07:00.320 talked about RSA, but there is this extension called session tickets which you probably heard 00:07:00.320,00:07:04.491 of as well. And the basic principle is, uhh I as the server don't have to deal with 00:07:04.491,00:07:07.861 all of your client crap, I don't want to store your master secret, so I'm just going to 00:07:07.861,00:07:12.532 encrypt it and send it back to you. Well, umm just like sending the pre-master secret if we are 00:07:12.532,00:07:16.870 sending the encrypted master secret back and for the client to store, and then pass it back 00:07:16.870,00:07:20.774 to us when it wants to resume, that's kind of a problem. The benefit of it is essentially 00:07:20.774,00:07:23.944 that now server..you can have multiple servers that load balance and it can reuse each 00:07:23.944,00:07:28.815 other's sessions if they just share that one session ticket key that's in memory. So we are 00:07:28.815,00:07:33.687 back to the problem with RSA, but we are just using a more Ephemeral key basically. Ummm 00:07:33.687,00:07:37.824 and then on top of that, that's just what TLS allows and just kinda the normal, the normal go 00:07:37.824,00:07:41.294 through, but there is also implementation specific oddities and we are going to get into 00:07:41.294,00:07:45.432 that today, specifically with Microsoft. Like storing symmetric keys, or well 00:07:45.432,00:07:51.504 symmetric key schedules. So the key is random, but the key schedule isn't. And also we 00:07:51.504,00:07:55.141 talked about, how you should really just re-use...just use the Ephemeral key once, and 00:07:55.141,00:07:59.412 there's some re-use and that happens, and we will see if...you know is that perfect 00:07:59.412,00:08:04.751 forward secrecy or is that mostly perfect forward secret. So the talk...the title is 00:08:04.751,00:08:06.753 S-channel....uhh whatever...soliciting s-channel...uhh...soliciting 00:08:06.753,00:08:08.755 secrets from s-channel. Ummm so what is s-channel, what is CNG? So secure channel is again, 00:08:08.755,00:08:12.625 Microsoft's TLS library, and it gets loaded into the client process that want to do the key 00:08:12.625,00:08:17.630 exchange, but Microsoft doesn't really trust you and your little C# web server to, use their 00:08:22.635,00:08:28.208 private keys. So they maintain and encapsulate all these keys in a security process called the 00:08:28.208,00:08:33.546 key isolation process. So if you have ever worked with Windows security, you know what that's 00:08:33.546,00:08:39.219 gonna be, it's...its LSAS. Ummm and so, s-chan....s-channel itself get loaded into both of 00:08:39.219,00:08:44.290 those and then, then once the, once the key change happens inside of LSAS, it passes back 00:08:44.290,00:08:47.694 the security context for the connection, it has all of the parameters, and it passes back 00:08:47.694,00:08:49.696 a,uhh handle to the, uhhh, the as-keys...uhh well the symmetric keys so that you can actually 00:08:49.696,00:08:51.698 handle that tunnel. But it doesn't actually handle any of the encryption itself, or any of 00:08:51.698,00:08:56.703 the..the...the ciphers itself. That's all handled through the CNG, which is the crypto API 00:09:00.607,00:09:05.612 next generation. So CNG again, next generation is always the best generation. Ummm it was 00:09:10.016,00:09:14.120 introduced into Vista, so believe it or not theres,theres a use to all of those years of 00:09:14.120,00:09:19.526 bluescreening that you had to deal with. Umm it, it brou...it brought around things like AES, 00:09:19.526,00:09:23.730 ummm and elliptic curve crypto to Microsoft and really modernized their capabilities 00:09:23.730,00:09:29.102 really as far as cipher suites go. Ummm and CNG basically has two functions. It stores things 00:09:29.102,00:09:32.405 and then it encrypts and decrypts things. So the encrypting and decrypting is 00:09:32.405,00:09:39.145 done via DPAPI, umm again Ellie Bernstein who is...who was in Vegas recently, he did all the 00:09:39.145,00:09:44.517 seminal research on that so talk to him. Ummm and then we will go over it as well. And then the 00:09:44.517,00:09:47.887 key storage providers actually handle storing of those secrets. So what does that look like? 00:09:47.887,00:09:53.426 Uhhh and oh quickly..so that's all good and well, does s-channel actually embrace 00:09:53.426,00:09:59.132 perfect forward secrecy? And the answer is yes. Microsoft has embraced it, after the 00:09:59.132,00:10:05.305 introduction CNG, so again we talked about how they introduced CCC. So what you see in Vista 00:10:05.305,00:10:09.042 they prefered cipher suites, they don't prefer Ephemeral suites, they don't prefer 00:10:09.042,00:10:12.312 elliptic curve suite because it was just introduced and Vista was broken enough. Umm and then 00:10:12.312,00:10:15.815 in Windows 7 and in Windows 10 they actually switched to just preferring those and you also 00:10:15.815,00:10:21.754 see that this metric suite..this metric cipher that we prefer become almost exclusively AES. 00:10:21.754,00:10:26.726 Ummm so that's all good and well. And so basically what that means is, that uh that can't do 00:10:26.726,00:10:31.397 that...we can't use that old RSA trick of just grabbing the private key off disk anymore of 00:10:31.397,00:10:35.568 we want to decrypt things, and thats why...that's part of the reason why context is I think 00:10:35.568,00:10:39.873 open sourced their free..their RDP replay tool that we are going to be modifying and using 00:10:39.873,00:10:46.079 later. Huh so we know that we can't use RSA...the RSA private key to decrypt things anymore, 00:10:46.079,00:10:50.984 for the most part with Microsoft. And we know that ummm that in theory that TLS allows 00:10:50.984,00:10:55.154 you to cache things, so does that channel cache things? Well their documents say yes it does. 00:10:55.154,00:11:00.693 There's a master secret ummm the cipher suite and certificates all get stored after the first 00:11:00.693,00:11:05.732 connection, after the first handshake between a client and a server. Additionally you see in 00:11:05.732,00:11:08.568 their documentation references to the fact that LSAS consumes more memory, they tell us 00:11:08.568,00:11:11.905 roughly how much it consumes, so we get an idea of for what this cache might look like, how big 00:11:11.905,00:11:18.745 it might be. And uhh they mention that by default that s-channel or yeahh LSAS is gonna 00:11:18.745,00:11:24.017 store...ummmm 20000 uhh entries. So that's not maybe a lot for a server, but it's a lot for a 00:11:24.017,00:11:30.423 client, and ummmm a reasonable amount for a server. So how does s-channel actually operate? This 00:11:30.423,00:11:34.827 is a very complicated looking Microsoft diagram that I made pretty. Ohhh no, oh no we're 00:11:34.827,00:11:41.200 good. uhhh and it hides a very simple truth that is regardless whether you are a client or a 00:11:41.200,00:11:47.040 server, it happens exactly like I explained it before. Uhhh client wants to make a 00:11:47.040,00:11:52.979 connection. Says hey LSAS please give me a uhhhhh security context and some symmetric keys, 00:11:52.979,00:11:57.917 LSAS is the key exchange, and on both sides the same process happens if they are both windows 00:11:57.917,00:12:01.354 servers. So uhhh that kinda gives an idea of where we want to look and where we might find 00:12:01.354,00:12:07.226 things. So CNG how does that work? So essentially everything gets routed through Ncrypt, the 00:12:07.226,00:12:10.897 Ncrypt.dll. Thats really useful for the, for the reversing aspect, because that kinda told 00:12:10.897,00:12:16.202 you, told me where to look. Ummm and then there is this whole key isolation service and then we 00:12:16.202,00:12:19.706 have these key storage providers again, that then manage those secrets in memory and on disk. 00:12:22.208,00:12:27.580 So just as a quick summary, we are looking in LSAS, we are looking for secrets in keys, and 00:12:27.580,00:12:32.318 we are doing that because that's where the handshake happens and because uhh s-chanell prefers 00:12:32.318,00:12:37.223 Ephemeral cipher suites in the handshake. Cool. Well.. again why do we want to do this, what 00:12:37.223,00:12:42.328 is the value? Well we want to subvert perfect forward secrecy, that's the point. Now that we 00:12:42.328,00:12:45.698 know s-channel embraces it we want to get around that. We also, even if we can't do that, 00:12:45.698,00:12:48.701 we want to see is there any forensic context to be had and is there anything that we can do 00:12:48.701,00:12:53.873 that would be of value, and how long does that live? And finally, again bad guys 00:12:53.873,00:12:57.844 perspective it's kinda cool if we can just get access to a single process and dump out 00:12:57.844,00:13:01.481 things we need to decrypt, things in the future, and in the past, and be able to impersonate 00:13:01.481,00:13:08.121 the server if we can pull out the private key, maybe. Ummm without touching disk. So what 00:13:08.121,00:13:12.158 do the secrets look like? Again based on what we all talked about right now, we basically 00:13:12.158,00:13:17.730 have a sessi...uh session keys, we have a pre-...a master key, a pre-master key. Those all exist 00:13:17.730,00:13:23.369 on the client and the host after that initial exchange, key exchange. Ummm well, through the 00:13:23.369,00:13:28.274 process we talked about. And also on the server there could be an Ephemeral private key for 00:13:28.274,00:13:31.644 using an Ephemeral suite, if we are just using RSA, we will have a persistent private key, and if 00:13:31.644,00:13:36.115 we are using session tickets there's gonna be this session ticket key, right? That's all 00:13:36.115,00:13:39.986 the possible secrets we could have for a TLS connection.Umm and what do each of those get 00:13:39.986,00:13:44.991 us? Well again we talked about the fact that session keys are short lived, they are not gonna 00:13:44.991,00:13:47.460 give us much, they are gonna give us a single connection. Uhh the master key and pre-master 00:13:47.460,00:13:53.232 key are gonna give us single session. And then the ephemeral key and the uhhh..the 00:13:53.232,00:13:57.970 pre-master...uhhh the ephemeral key, the private key and the persistent private key and the 00:13:57.970,00:14:02.475 session cookie key will give us multiple sessions depending on what we are using. And on top of 00:14:02.475,00:14:06.679 that there's a....that that persistent private key usually gets used for signing as well, 00:14:06.679,00:14:13.486 which will give us identity for the server. So what did we get? We got them all, we got 00:14:13.486,00:14:17.690 everything. So what you see up there is the pass to the keys, they are sitting in memory, 00:14:17.690,00:14:23.596 sitting in LSAS memory, umm and they are named based on either, ummm the the structure that I 00:14:23.596,00:14:28.601 reverse or the symbol name that Microsoft has for the the respective umm structures. Umm 00:14:30.670,00:14:35.041 so everytime you see ummm uhhh an unlock symbol, that means that secret is sitting 00:14:35.041,00:14:39.645 unencrypted in memory, and obviously everyone goes straight to the one with the locks on and 00:14:39.645,00:14:43.249 go what about that guy? Well we are gonna get to that, that's actually not a problem either. 00:14:43.249,00:14:47.120 Uhhh and then the one other thing we see the pre-master key down in the corner, uhhh 00:14:47.120,00:14:49.122 pre-master secret sorry. And you are probably saying you are cheating, you said everything, 00:14:49.122,00:14:54.127 what about that guy? And we will explain that too. Sooo how do we get to that point where we have 00:14:56.129,00:15:00.233 everything and we know exactly to get to it? Well I started with the session keys because, 00:15:00.233,00:15:04.871 it's closest to the data, its the most ephemeral, it's not going to be encrypted because 00:15:04.871,00:15:11.010 its a symmetric key, that would umm not make a lot of sense. Atleast not in software. Ummm so 00:15:11.010,00:15:15.481 I started with AES, because as we saw s-channels prefers AES for everything. Uhhh but AES 00:15:15.481,00:15:20.186 keys are small and random, so that's kinda a non starter right? Well not exactly, uhh so 00:15:20.186,00:15:25.558 uhh smart guys at Princeton a while ago wrote a paper called cold boot attacks and they 00:15:25.558,00:15:30.663 talked about the fact that a lot of implementations store, uhh this key schedule. So AES gets 00:15:30.663,00:15:36.068 expanded into round keys, and that process is deterministic, thats why its called a schedule. 00:15:36.068,00:15:41.374 And because of that we can take that otherwise set of data, we can calculate what the next item 00:15:41.374,00:15:44.911 based on that random chunk we are looking at would be, if it would be part of the schedule, 00:15:44.911,00:15:50.016 and if it is, then we have a very good chance that we have a AES key. Uhhh so, I basically 00:15:50.016,00:15:53.719 just scanned the client and server process, and what you see there is matching AES keys on 00:15:53.719,00:15:57.790 each. So what does that give me? Well that allows me to then look at those offsets in memory and 00:15:57.790,00:16:01.294 start figuring out what the context of those were and how those were stored. You see that 00:16:01.294,00:16:04.630 there are 4 keys stored there, uhh that was actually two separate connections, and when 00:16:04.630,00:16:09.468 we are talking about TLS, we have a server right key and a client right key, so there is 00:16:09.468,00:16:14.140 gonna be two AES keys for each. But yeah, one thing that I noticed when I was doing this, 00:16:14.140,00:16:18.744 and this is what the data structure looks like. So one thing I noticed when I was doing 00:16:18.744,00:16:23.616 this is there is this magic value 3LSS, which is actually stored as a dword, so I flipped 00:16:23.616,00:16:28.988 that around and that's a little ndn, and that's SSL3. I was like you know aha yeurika! SSL3, this 00:16:28.988,00:16:33.926 is, you know this is cool.But this is weird, because it was a TLS 1.2 connection and I thought 00:16:33.926,00:16:37.396 maybe they are terrible with their naming conventions or something. But then I started 00:16:37.396,00:16:42.034 scanning for SSL 2, SSL 1 and everything else, and what I was actually able to find there was 00:16:42.034,00:16:48.708 SSL1 through to 7. So its not the TLS version, it's something else entirely. But before we get 00:16:48.708,00:16:54.180 to that, just to quickly go over this structure, uhhh, the session key structure itself has 00:16:54.180,00:16:57.917 this magic value, right above it has a length value, it's got the protocol version which is the 00:16:57.917,00:17:02.755 TLS version, and then it's got a pointer to the cipher suite list so we know what kind of keyword 00:17:02.755,00:17:06.559 we are looking at basically. Ummm and then at the very end there is, there is a boolean 00:17:06.559,00:17:10.496 flag to say whether or not it's the right key for client or server basically. And at the 00:17:10.496,00:17:15.368 very end there is a pointer to a bcrypt key structure. And if you have ever played in the back of 00:17:15.368,00:17:19.672 mimikatz, you know that bcrypt keys are used everywhere in LSAS or superfluous....or not 00:17:19.672,00:17:23.609 superfluous but they are everywhere. Umm and Benjamin Delphi did a lot of research on 00:17:23.609,00:17:27.179 reversing those, I actually didn't even do them myself, cause I didn't look at the 00:17:27.179,00:17:32.585 source code until after I kinda got into it, but ummm yes these things are kind of consistent. 00:17:32.585,00:17:37.490 And then on top of that he calls this MS metric key a...uhh he calls it a bcrypt key and I 00:17:37.490,00:17:40.126 think he calls the other one a decryption key handle, but the reason i call it that is because 00:17:40.126,00:17:43.462 of the symbols in memory. There's actually a validation function thats says for this 00:17:43.462,00:17:49.902 magic value mssk, um validate...max...umm symmetric key. So it's Microsoft's metric 00:17:49.902,00:17:56.208 key. And then highlighted in red is the actual key itself. Cool so I mention these magic value, 00:17:56.208,00:18:00.947 these SSl values, so how did these come into play? Well when I started looking at the modules 00:18:00.947,00:18:04.951 for these magic values just to see if I can pull apart the functions where they were 00:18:04.951,00:18:08.154 store...um that generated them, umm what I noticed is that there is a couple of really really 00:18:08.154,00:18:13.793 quick validation functions that literally just do 3 things. They accept a pointer, they check the 00:18:13.793,00:18:20.132 size value of the structure at that pointer, and then they uhh check the second value for a 00:18:20.132,00:18:25.705 magic value , which is that SSL3 or whatever the number is. Umm so by dumping out the rest of 00:18:25.705,00:18:30.509 those and kind of looking at them, they are all the same, and what that gets us is, it gets us 00:18:30.509,00:18:36.983 size values and function names that are very descriptive for specific structures. So we kind 00:18:36.983,00:18:41.854 of know now that, that, that this SSL5 magic values is gonna be tied to a master key, and we 00:18:41.854,00:18:45.758 know that SSL4 is going to be tied to a key-part, whatever that is, which turns out to be 00:18:45.758,00:18:50.963 the private key. And then SSL6 is for the Ephemeral key. Now SSL3 didn't actually have one of 00:18:50.963,00:18:54.400 these, uhh it was uuh I just happened to come across it looking at some other functions, 00:18:54.400,00:18:58.838 but we we do see that it gets used in decrypt, encrypt, generate session keys and also I 00:18:58.838,00:19:03.009 have just traced through and I know those are the session keys. So, ummm the only other one that 00:19:03.009,00:19:08.014 doesn't have anything is the SSL7. And that is the pre-master secret. The pre-master secret we 00:19:10.182,00:19:13.953 don't actually really need, because it, it literally is per connection and gets used only to 00:19:13.953,00:19:18.491 generate that, that master secret that's always gonna be the same length, because the 00:19:18.491,00:19:22.895 pre-master secret variable based on, ummm what key exchange we are using. If we are using ECC, 00:19:22.895,00:19:28.401 it's going to be the S coordinate of the shared secret that we derived. Ummm so, 00:19:28.401,00:19:31.470 basically it vidual, we don't really need it, we have them...if we can get the master 00:19:31.470,00:19:36.475 key, which we can get. So, so uhh SSL7 is only used for uhh the RSA premaster secret. And on 00:19:39.879,00:19:45.051 top of that, it it gets destroyed very quickly, so they actually follow the spec on 00:19:45.051,00:19:47.920 this, as soon as you get the master secret you destroy it, so you will never see it in memory, 00:19:47.920,00:19:52.591 it's kinda too beautiful to live or whatever. So master secret. Uhhh basically this is, this is 00:19:52.591,00:19:57.229 the goldilocks secret, this will get you multiple session, this will get you the whole length of 00:19:57.229,00:20:01.000 a session, this is what get cache, gets cached. Microsoft told us that in their 00:20:01.000,00:20:06.739 documentation and its delightfully simplistic, basically it just stores the 00:20:06.739,00:20:11.744 master key directly in a uhhh um an array, it's part of the structure, it tells you the 00:20:11.744,00:20:16.715 protocol version and it tells you the cipher suite you chose, because obviously we need to 00:20:16.715,00:20:21.520 take that master key, mix in some stuff and mint out some session keys. ummm but yeah, 00:20:21.520,00:20:26.192 incredibly simple but the problem is...and and if we just have this right now, we can 00:20:26.192,00:20:32.031 actually brute force a given session ID, with that master key, with all the master keys in 00:20:32.031,00:20:35.835 memory and be able to decrypt it, but it would be a lot more elegant if we could map it back 00:20:35.835,00:20:39.805 to a unique value, and this is what we are gonna do.This is what that looks like in memory 00:20:39.805,00:20:42.741 and what you are gonna see is that as we go through there is gonna be a lot of windbg, and 00:20:42.741,00:20:46.445 the reason why I did that is I had the full commands there. So once you have the slides you 00:20:46.445,00:20:50.649 actually can go through and validate my work yourself. Ummm or you can do as you go along. 00:20:50.649,00:20:55.654 But yeah, that pointer again points to a unicode string and points to a...the identifier for 00:20:59.925,00:21:02.361 the cipher suite version, ummmm but there is no other pointers in this structure so we have to 00:21:02.361,00:21:06.966 figure out how we can map this to a unique value. What do you do? Well you scan for pointers 00:21:06.966,00:21:10.703 to this structure right, in memory. And what I was able to find ways is kind of similar to 00:21:10.703,00:21:16.542 how the bcrypt keys work, encrypt keys, which I'm guessing means network....umm network 00:21:16.542,00:21:21.680 crypt keys. Ummm have a handle that then points to that secret, and if you go back from that, 00:21:21.680,00:21:25.184 you actually get to the session key structure, and I kind of found it, because I was able to 00:21:25.184,00:21:29.622 see uhhh session IDs directly below. And you might be wondering how did he see session 00:21:29.622,00:21:32.992 IDS, they are supposed to be random? Well they are not always random actually, they are 00:21:32.992,00:21:36.262 actually just arbitrary, and we will get to into that too. But basically what we have in this 00:21:36.262,00:21:40.432 point in time is, we have plain-text. We can go from a given session ID all the way 00:21:40.432,00:21:46.438 though to a master key and we can uhh decrypt the session it belongs to. And we can do that 00:21:46.438,00:21:50.242 by just, the quickest way to do that is to just dump it out in wireshark format and open up in 00:21:50.242,00:21:55.281 wireshark, and then it's instant. Instant gratification, which is exactly what we like. 00:21:55.281,00:21:59.485 Ummm so yeah, so we now have master key, and we could actually stop there and that's 00:21:59.485,00:22:04.323 your secret...sorry. We could really stop there cause we can decrypt sessions, this that's 00:22:04.323,00:22:10.062 great. But why do that when there is other things to be had? So there is this Ephemeral key 00:22:10.062,00:22:14.133 and this persisten private key and depending again on the key exchange that we use, ummm they 00:22:14.133,00:22:19.872 are gonna be...uhh one may exist or one may not exist. Ummm but they share the same structure 00:22:19.872,00:22:22.107 because they share the same function. So uhhh there is this SSL key pair structure that 00:22:22.107,00:22:24.109 again is, is has a magic value of SSL4 SSL6, that points to an encrypted key handle, which is 00:22:24.109,00:22:26.111 not really the same as encrypted ssl key that we saw, it's got a different magic value and 00:22:26.111,00:22:29.782 slightly different structure. And that points to this KSPK structure. Ummm and you are like 00:22:29.782,00:22:34.787 that's not how you spell key storage provider, like, but its because its backwards and again 00:22:43.429,00:22:48.434 because it's little indian. So this KSP...uhh or KPSK, is uhhh, is the instantiation of the key 00:22:51.036,00:22:57.643 from disk or the Ephemeral key itself. Ummm and it has all the values we need to do anything 00:22:57.643,00:23:02.414 interesting with them. So that is the key storage provider key and uhh, and uhh it's kind of 00:23:02.414,00:23:07.519 the thing we are shooting for. So the Ephemeral private key itself, that's what it looks 00:23:07.519,00:23:10.723 like dumped out. It's sort of little indian, nothing else from Microsoft is sorted little 00:23:10.723,00:23:16.729 indian, for the keys and its secrets. So it kinda threw me off at first, but I, what I did 00:23:16.729,00:23:22.001 there, I dumped out based on this, this umm ephemeral key data class, I dumped out the 00:23:22.001,00:23:25.738 public key and then the generator values from the KSPK structure. So from that Key 00:23:25.738,00:23:29.208 provider, that Key storage provider structure and then I dumped out the private key. So 00:23:29.208,00:23:35.514 you could basically then, assuming you know the large prime value, take that private 00:23:35.514,00:23:40.919 key there and then generate that public key to verify that it is infact the private key. So 00:23:40.919,00:23:44.723 umm..it's sorted in this msky structure which gets used later on in this talk, and basically 00:23:44.723,00:23:46.725 once we have this what can we do with it? Wireshark does not support ECC keys right now by 00:23:46.725,00:23:48.727 default, just to decrypt things, like it does with RSA keys. But it doesn't...there is no reason 00:23:48.727,00:23:50.896 that it cannot. Ummm once we have this we can drop it to a pen structure and we can kinda 00:23:50.896,00:23:53.332 use it as we want, and because it gets re-used and it gets stored in memory, it gives us 00:23:53.332,00:23:55.367 multiple session and it's kind of, it's kind of great. So it..it's the equivalent what we 00:23:55.367,00:24:00.306 would have had before with the RSA key, if we were using a RSA key exchange. So then persistent 00:24:12.518,00:24:15.788 private key itself, so now at this point we have all the ephemeral things in theory, 00:24:15.788,00:24:19.658 other than that session key thing that we will get to. Uhhh so, what about impersonation of 00:24:19.658,00:24:24.196 the server? What about that thing, that little lock symbol that wasn't unlocked that you 00:24:24.196,00:24:29.034 guys were like yeah yeah he's cheating? Well, the uhhh RSA key get pointed to you directly at 00:24:29.034,00:24:32.738 your directly out of those KSPK structures, the key storage provider, and its encrypted in 00:24:32.738,00:24:36.275 memory. So it's encrypted with DPAPI. Well if you have done anything with DPAPI or if you 00:24:36.275,00:24:42.581 have ever read any of Ellie's work you will know that ummm, theres, because it's encrypted 00:24:42.581,00:24:47.553 as a system secret we can actually just grab that system secret, decrypt the DPAPI master 00:24:47.553,00:24:53.659 key and use that then to decrypt this blob. So you could go back to disk and you could grab that, 00:24:53.659,00:24:57.296 and you can just decrypt this, but what the fun in that, because we want to get this 00:24:57.296,00:25:02.301 straight out of memory. Well up there you see highlighted in red is the key good, out of the 00:25:02.301,00:25:07.506 DPAPI blob. So what I did here was, I scanned the, I just scanned memory for the master 00:25:07.506,00:25:13.979 key list, which uhhh which basically the master keys for DPAPI get cached in memory, but 00:25:13.979,00:25:18.450 they are encrypted. So Benjamin Delphi did a lot of work on this and again this is one of those 00:25:18.450,00:25:23.322 things where he tends to beat me to it, and ummm he's just a badass. Umm so basically what 00:25:23.322,00:25:30.062 you can do is you can take the, uhhh, theres theres symbols that point to the uhh initialization 00:25:30.062,00:25:34.299 vector and the, the, the symmetric key that then encrypts then encrypt these master keys, 00:25:34.299,00:25:37.603 you can decrypt those and then use that to to decrypt the blob straight out of memory. And when 00:25:37.603,00:25:43.575 you do that, you get this. So on the one side we have the RSA, uhh key from disk itself, and on 00:25:43.575,00:25:46.645 the other hand we have what we decrypted out of memory and you will know if you've done it 00:25:46.645,00:25:51.049 right if its a RSA key, because the Microsoft structure actually has its RSA2 magic value that 00:25:51.049,00:25:55.654 you can just see. So at that point we can directly impersonate the server without 00:25:55.654,00:26:01.527 around...without having to touch disk. So what about that session ticket thing? That's like the 00:26:01.527,00:26:05.197 last thing that, the last secret that we have to go over, that we haven't really talked about yet. 00:26:05.197,00:26:10.369 Umm so it's not really seemingly in widespread use, it seems like the support for it is a little 00:26:10.369,00:26:15.374 bit, uhh a bit lacking. Well at least the documentation is for sure. So uhhh sometime around 00:26:18.477,00:26:23.482 Windows 8 and Server 2012 R2, Microsoft basically, uhhhh enabled the capability to uh use 00:26:26.051,00:26:31.657 to use RFC5077 which is the sessions keys. But they didn't actually provide any 00:26:31.657,00:26:34.293 documentation on how to use that, the did push out these powershell functions that you 00:26:34.293,00:26:37.963 can, uhhh, that you can use. And what i've done there in that example is, I have enabled those 00:26:37.963,00:26:42.034 powershell functions, or ive ran those powershell commands they give you as examples to create 00:26:42.034,00:26:47.039 an administrator managed session key...ticket key, and then ummm, uhhh and then enable it for the 00:26:50.075,00:26:53.178 account. But that doesn't actually enable it for the system and they don't tell you 00:26:53.178,00:26:57.149 how to do that, but what they do tell you in the Windows 8.1 release, preview release notes 00:26:57.149,00:27:02.754 is: set this value to disable session tickets, it's screwing things up. Taking the opposite 00:27:02.754,00:27:06.825 of that I set, I set it to 2, I set it to 1 and then next thing you know i'm able to actually 00:27:06.825,00:27:10.762 use session ticket keys. So up till this point, even though things have been unencrypted in 00:27:10.762,00:27:14.166 memory and even though we can do bad things with them and that's cool, or great things, if you 00:27:14.166,00:27:19.705 are a forensic guy; umm Microsoft hasn't really done anything wrong. Those are short 00:27:19.705,00:27:23.876 lived...its short lived keys so in theory like it's fine to keep them unencrypted in memory and 00:27:23.876,00:27:27.379 then the one thing that does get stored on disk, that they pull into memory they then encrypt, 00:27:27.379,00:27:31.016 even though they stored the keys to decrypt it, but the session ticket key is kinda that thing 00:27:31.016,00:27:35.420 where they...uh they mess up a little bit in my mind. If this is in fact the Microsoft 00:27:35.420,00:27:40.192 approved way to do it, which I can't say that it is, ummm the administrator managed session 00:27:40.192,00:27:44.530 key gets stored on disk and it gets DPAPI protected right? Just like any other key that gets 00:27:44.530,00:27:50.102 stored on disk. So we can then pull that out, and then that key then gets derived, or gets 00:27:50.102,00:27:56.675 turned into a AES key through a key derivation process. But that AES key is actually the same AES 00:27:56.675,00:28:00.479 key across reboots, which basically means if you enable session tickets and it happens 00:28:00.479,00:28:04.583 at the s-channel layer, which means it happens for all service in Windows, not just IIS, it 00:28:04.583,00:28:09.755 happens for IIS, RDP and everything else that we talked about. Then you can...if you can 00:28:09.755,00:28:14.826 pull this key off disk via I don't know the export TLS session ticket key 00:28:14.826,00:28:17.930 function.uhhh..uhhh..command for powershell. You can then decrypt these like it was a RSA key, you 00:28:17.930,00:28:22.935 can then decrypt those sessions. Thats kind of crazy, so ummm, so yeah, uhhhh, they do cash this 00:28:25.604,00:28:29.041 key in memory as well so we don't have to go to disk once we export it, umm but what we can 00:28:29.041,00:28:35.180 do is we can pull it, ummm, we can pull it umm out of the cache and uhh there is no symbols for 00:28:35.180,00:28:38.817 the cache, but if we have the key good, which gets stored in the pat...in the uhh session 00:28:38.817,00:28:42.487 ticket key...uhh the session ticket that gets sent across the wire, then we can actually just 00:28:42.487,00:28:47.926 reference that, because we know...uhh I know what the structure looks like and I know 00:28:47.926,00:28:52.831 the offset. So what do the session tickets look like? The session tickets are actually, 00:28:52.831,00:28:56.101 they are cool, they're...the flip the MAC above the encrypted state, so they don't have to 00:28:56.101,00:29:00.205 change a bunch of things if they change the size of the encrypted state which is great and 00:29:00.205,00:29:05.110 otherwise they follow the spec. But because they have the ID in there, which they are supposed 00:29:05.110,00:29:08.413 to have and because they have key good and we can pull that key out of memory, we can then 00:29:08.413,00:29:11.783 go directly from having something on the wire, to what the slide shows, which is 00:29:11.783,00:29:16.188 decrypting that uhh session ticket and seeing what that value is. And as you'd expect, 00:29:16.188,00:29:20.459 it just has that master key structure stored inside of it, along with things like timestamp 00:29:20.459,00:29:26.365 and TLS protocol version and things like that. So ummm yeah. So at this point we have 00:29:26.365,00:29:30.869 basically decrypted all possible secrets that we need out of memory, so secrets are cool and 00:29:30.869,00:29:34.439 all, but what if you don't actually have a packet capture? What if you don't actually want 00:29:34.439,00:29:36.808 to decrypt things in the future? What if you don't care about any of that? What if you just want 00:29:36.808,00:29:43.582 to know how this relates to forensics. Ummm well that's why we have the context. So, core 00:29:43.582,00:29:48.353 TLS SSL functionality that provides metadata that we can use, well timestamps typically 00:29:48.353,00:29:53.592 are the first 4 bytes of a random value that get generated, if you are following the spec. 00:29:53.592,00:29:58.730 And then there are other things, like the public key can be used to fingerprinting the server, 00:29:58.730,00:30:02.534 but the session ID can also be used for fingerprinting the server, because S-channel 00:30:02.534,00:30:07.539 uniquely, creates these uhhhh...takes the first D-word and does...performs an operation 00:30:09.908,00:30:15.180 on it as, as said by these peo...these people who wrote the [inaudible] paper, so that the 00:30:15.180,00:30:19.284 second...the two bytes, the second two...the first two bytes are random, the second two bytes 00:30:19.284,00:30:22.921 are 0 and the rest of its random, so you get a very visually recognisable pattern 00:30:22.921,00:30:27.926 umm for the session IDS. And uhh on top of that we have what TLS extensions offer themselves, so 00:30:30.429,00:30:34.433 we have this concept of server name indicator. The cool thing about that is if we just run 00:30:34.433,00:30:39.638 something like CON scan with volatility, we not only get the IP address but also the port it 00:30:39.638,00:30:43.942 goes to. But because we have the SNI, if it's a virtual host, and because we have the public key, 00:30:43.942,00:30:48.947 then we can say this is exactly who you are talking to, or who you were talking to, not just 00:30:48.947,00:30:55.087 the IP you are talking to. So how long does this whole thing actually cache? Well we talked 00:30:55.087,00:30:57.589 about what the spec allows, what does...what does..it..how does it actually work...what is it, 00:30:57.589,00:31:03.061 what are the actual values? There are these values that get stored in memory, the client 00:31:03.061,00:31:06.364 lifespan, the server life span and the session ticket lifespan and those are all 10 hours by 00:31:06.364,00:31:10.535 default. So what that is, is the maximum time you will have these in memory, so you won't have the 00:31:10.535,00:31:14.706 full 24 you would...well that you could get in theory for session ID lifetime in the spec, 00:31:14.706,00:31:18.543 but you do get 10 hours which is still a lot. Especially if you are a guy doing IT and I don't 00:31:18.543,00:31:22.047 know someone RDPs into your machine and you get a alert on it, you want to go back and 00:31:22.047,00:31:27.452 potentially pull the memory from that machine, umm and if you want to attack the cacher. Umm 00:31:27.452,00:31:33.458 so, the other thing is, the maximum number of entries, so again this is hardcoded into the 00:31:33.458,00:31:36.795 s-channel binary, just like that value above, but you can override it in memory...or you 00:31:36.795,00:31:42.567 can override it in the registry, and that's set to 20000 entries by default. Umm and then other 00:31:42.567,00:31:49.007 thing is, enable session tickets, uhhh is uh is uh in theory 1,2 or 0, presumably 0 is 00:31:49.007,00:31:53.879 undefined, that's what it is by default hard coded into the s-channel binary. Ummm and if 00:31:53.879,00:31:59.551 you don't change that to 1 then session tickets don't seem to work. Ummm and then the uhhh 00:31:59.551,00:32:04.556 there is a clean up interval, which is how often uhhh this cleanup, uhh thing runs. So if 00:32:04.556,00:32:09.628 you as the process decommission, uhh purge your cache, then there's a possibility it might 00:32:09.628,00:32:14.332 stay around for tiny little while before that,that timer. Uhh so as the process you have 00:32:14.332,00:32:19.538 full control, s-channel is still just the library. So the processes can purge the cache 00:32:19.538,00:32:22.941 whenever they want, you might not get a full 10 hours, it kinda depends. And the other 00:32:22.941,00:32:26.845 kinda unfortunate thing is that ummm because we centralizing this, because we track the 00:32:26.845,00:32:32.984 processes themselves, if a process dies, it seems the cache gets completely cleared for that 00:32:32.984,00:32:39.758 process. Uhh but things like RDP, things like IIS, things like most of the services we are 00:32:39.758,00:32:44.996 interested in even something like Outlook runs as a service. So you uhh you aren't going to 00:32:44.996,00:32:49.201 have that problem basically, um but they might also decide to purge cache periodically at 00:32:49.201,00:32:55.407 their discretion. So what does the cache actually look like? Well as you see, it like..as you 00:32:55.407,00:32:59.945 saw when I was talking about the keys, ummm there's uh a lot of these symbols have a c 00:32:59.945,00:33:04.349 prefixing, and that because they are a C++ class, umm and so they're virtual function table 00:33:04.349,00:33:08.086 gets stored at the top, and what that enables us to do is if we can use symbols, we can actually 00:33:08.086,00:33:11.823 scan for instances of that function in memory. Which is kinda cool. SO the very first 00:33:11.823,00:33:15.894 thing gets stored as that VF table, the next thing is the pointer with the master key and 00:33:15.894,00:33:19.965 again, I haven't got the whole structure there, which is why this is like a V tag, with all 00:33:19.965,00:33:24.803 its V types, so it just shows you the offsets I know about. You also have the process ID, 00:33:24.803,00:33:28.673 and then the logon session UID, which I was talking about earlier, which is kinda cool. 00:33:28.673,00:33:33.445 And then the session ticket or the uhhh, the session. There will be a pointer to the session 00:33:33.445,00:33:39.351 ticket if session tickets are used or there will be the actual session ID itself stored as an 00:33:39.351,00:33:44.522 array directly in that structure, if that what's used. And then on the server side its 00:33:44.522,00:33:47.993 again, it's a lot smaller, you are not gonna have session ticket pointer because they 00:33:47.993,00:33:52.397 don't get stored on the server. But you will have thin...you will still have process ID, and 00:33:52.397,00:33:56.701 those other kinds of useful things. And then because just I had time, well didn't really 00:33:56.701,00:34:00.739 have time, just felt like I wanted to be thorough, uhhh I also went and looked at Vista, 00:34:00.739,00:34:05.143 ummm and basically Vista is kind of proto...it's before it really becomes more object oriented so, 00:34:05.143,00:34:09.180 it uhh, its seems. So it just uses a list structure, so once you find one cache item, you 00:34:09.180,00:34:14.286 just loop through the list entry, and you can find all the other ones, which is nice. Ummm 00:34:14.286,00:34:17.188 so yeah. So uhhh how do, uh that's cool and all but how do we automate that? How do we 00:34:17.188,00:34:20.992 actually make that useful? So what I'm providing is a volatility plugin, and I'm 00:34:20.992,00:34:24.729 providing a recall plugin as well, to automate that. And by default it's just gonna dump 00:34:24.729,00:34:30.902 out, the wireshark format we showed earlier, and then what I'd like to do too, is hopefully 00:34:30.902,00:34:35.073 uhhh talk to Benjamin Delphi and see if he's interested or maybe create a powershell module that 00:34:35.073,00:34:40.011 will do it live, so you can actually just do it live as well. Ummm but yeah. So 00:34:40.011,00:34:43.548 limitations, we are working with internal undocumented data structures for the most part, 00:34:43.548,00:34:48.587 which means they are subject to change. Umm sometime in like, I think it was March or April 00:34:48.587,00:34:53.058 there was something that was inserted midway through the cache and so you get to this 00:34:53.058,00:34:56.795 position where you know you have maybe some hosts that are updated and some that aren't and 00:34:56.795,00:35:01.366 the cache is going to look different, which is annoying. But it happens below the, uhhh, 00:35:01.366,00:35:04.569 or I suppose after the session ID so you don't really have to worry about it for session ID, 00:35:04.569,00:35:09.274 this does affect how sessions get parsed. You can still do it, it's just harder to do that in a 00:35:09.274,00:35:13.878 automated fashion, it will take a little bit more, it will be a little less clean. And then we 00:35:13.878,00:35:18.049 are relying on symbols, so Microsoft gave us symbols to do some of this easily, they can 00:35:18.049,00:35:22.087 also take them away, which is totally their right. Umm but realistically that probably 00:35:22.087,00:35:24.823 isn't gonna have that much of an impact, cause for the most part we can do all of this stuff 00:35:24.823,00:35:29.928 still, just a little less efficiently. And then you need to be able to read LSAS memory, 00:35:29.928,00:35:33.798 which is kind of a big caveat when you are talking about being able to exploit things right? So 00:35:33.798,00:35:38.069 ummm, well no exploit sorry. Just when you are pentesting or moving through something. Well 00:35:38.069,00:35:42.374 the reality is that like in 2016 again everyone runs mimi..mimi katz and things like that. 00:35:42.374,00:35:44.609 Getting access to LSAS is not that hard if you have Administrative access to that 00:35:44.609,00:35:48.213 box, but it does mean it is probably a little more useful in a forensic context than it is 00:35:48.213,00:35:51.282 anything else, so. And with that let's get back to the demo. So I'm going to simulate again 00:35:51.282,00:35:56.287 capturing RAM and then ummm, after we get that we are going to run the recall plugin. So 00:35:59.557,00:36:04.496 there is a screenshot thereof the volatility plugin and then...umm I'll basically just 00:36:08.600,00:36:13.605 to show you both i'll go through recall as well. And hopefully that will work. [Keyboard 00:36:41.666,00:36:44.969 sounds] Okay cool, so we see that it dumped out...uhhh single session ID and again the reason 00:36:44.969,00:36:46.971 why there is only one is because i'm not connected to the internet intentionally, ummmm so 00:36:46.971,00:36:51.976 thats the only one that's going to be there from the RDP session that I made. Ummm. So we are 00:36:56.915,00:37:02.353 just going to copy that into this demo file and read it out of the file. Uhhh. Huhhh 00:37:02.353,00:37:07.358 hopefully. Noooo. Don't tell me copy paste failed. I'm sure....ahh you gotta be kidding 00:37:16.101,00:37:21.106 me. Okay. Hold on.....uhhhh. Sorry. Live troubleshooting. Uhhhh. >>[Inaudible from 00:37:25.910,00:37:30.915 audience] >What's that? Restart what? >>[Inaudible from audience] > Okay, I got it, yeah 00:37:39.657,00:37:44.662 yeah got it. Oh the joys of open source software. No we are so close, and this isn't even the 00:37:59.177,00:38:04.115 hard part of the demo, this is like literally the basics. [Laughter]. Nooo. Okay okay hold 00:38:04.115,00:38:09.120 on a sec. Let me just see. Uhhhhh. Uhhh what do I have now actually. [Clicking]. Noooo. 00:38:16.027,00:38:21.032 Nooo. How much time do I have? I know. See I sh...I shouldn't have antagonized them, it's my 00:38:29.407,00:38:36.381 own fault. Okay so. Uhhh. Tell you what, since we already have it, let's just...do you guys 00:38:36.381,00:38:41.386 mind if I reboot, reboot Kali really quick? And then we see how it goes? [Coughin] 00:38:51.896,00:38:56.901 [Clicking] The extended demo, just because you are my favourite audience. In the 00:39:13.151,00:39:19.791 meantime if anyone has ummmm questions please please feel free to come up and ask. The 00:39:19.791,00:39:24.796 microphone is up front. >> Question: Umm in Windows 10 Microsoft started doing 00:39:35.607,00:39:40.845 virtual...virtualization based security to grab some of the LSAS secrets and put them off, 00:39:40.845,00:39:46.351 protected by the hypervisor... >Huhhh the worst place for that to happen, sorry go ahead 00:39:46.351,00:39:50.788 [Laughter] >> Question:....uhh do..have you looked to see if that affects any of the data you 00:39:50.788,00:39:54.659 are able to pull? >Yeah so uhhhh, I guess what I should say. I tested this with Windows 00:39:54.659,00:39:58.863 7, I have tested this with Windows 8.1, but I was mostly working on WIndows 10 and Server 00:39:58.863,00:40:01.566 2016 preview, and the hardest part really was the session tickets, because I don't really 00:40:01.566,00:40:04.936 know, I wish that...if theres a...I just want to make sure I'm doing it right. So I wish there 00:40:04.936,00:40:08.206 was a way that said this is exactly how it should be done. Umm but yeah I umm umm, 00:40:08.206,00:40:13.478 everything was done on WIndows 10. >> Question: Was hyperV enabled? > What's that? >> Was 00:40:13.478,00:40:18.483 hyperv enabled? > Uhhhh, no. I don't know. Probably not no. >> Okay cool. [Inaudible from 00:40:31.596,00:40:34.565 audience] > Okay. Go....well apparently I'm not gonna get that functionality. Im not 00:40:34.565,00:40:39.537 gonna, I'm going to spare you me typing it by hand. But if you want to see the demo I guess 00:40:39.537,00:40:44.542 come see me afterwards and I'll show you. Okay. So um yeahh. Anyway. That's basically. This 00:40:51.716,00:40:58.089 is. You can also see in Wireshark and see the keystrokes going across, and that's it. You 00:40:58.089,00:41:04.062 can find me at tinrabbit underscore @, at..on Twitter. And thanks to all of these 00:41:04.062,00:41:09.067 people and their help. SO yeah that is it. [Clapping].