 Thanks so much Martin. I run a class for my plan. It's true. It starts to be way back, right? Since we know each other, it's pretty crazy. Anyway. All right, so originally today, I planned to talk about the risks of RDP and how to mitigate them, but then I realized I only have half an hour, so I needed to adjust. So this is some risks of RDP and how to mitigate them. But then I found some problems and it became some risks of RDP, how to mitigate them, and a villain reported to Microsoft. So we're gonna go through this. It's heavily edited, the edition of the talk I gave a month ago at ETSCon, which was 45 minutes. So I switched a bunch of things and some of it might not be super coherent because I was doing CTF 101 yesterday and I had a hacker jeopardy tomorrow. So I didn't have as much time as I wished I had to prepare. But you'll have a great ride, I'm sure. All right, so about us, no time for that. No, actually, I should say. So I was supposed to present with Lissandro, but Lissandro, his visa didn't get approved in time. So apparently when Immigration Canada says it's gonna take 23 days, well, they don't mean 23 days for real. And it's not even 23 business days. It's like 23 days of Jupiter or I don't know what. But one day you'll see Lissandro, I'm sure you'll have a visa. They are good for five years. So once you have it, you'll present here, either here or at GoSec. We'll see. All right, so it's just by myself. So RDP. RDP, as many of you know, is the remote desktop protocol. It allows you to connect to a remote system and have graphical mouse and different kinds of IO forwarded in a secure fashion. And it is basically like for geeks, it's like SSH with more features and or problems. So the RDP layers. So this is why this needs time. But you know what? Let's forget about most of it. It's not that interesting. And it's been already hammered on a lot of time before. So we're going to focus on IO clipboard and drives. And by IO, we mean display keyboard and mouse. So these are the areas of focus of RDP today. So RDP security. What happens with RDP? You have at the beginning like ancient history of RDP. You had RC4 and graphical login. So why I precise graphical login? This is pretty important in the design of the RDP protocol and its early flexibility, but was also a mistake. So we're going to spend some time on that. But so RC4 was a custom, I think semi hard coded key. Anyway, right now, almost nothing supports it. And if you do that, people can hone you in like fractions of seconds. Cain Enable supported breaking the RC4 connection mechanism like 15 years ago, I think. So what most people doing non-NLA, which is the modern one that we're going to get into, uses right now its TLS plus graphical login. And yes, this is the TLS like transport layer security. But then everything like all the channels, IO channels are set up. And then you authenticate via the keyboard and mouse and graphical, which is a lot of code and surface. What happened after is TLS plus network level authentication, so NLA, which relies on credits SP. And we're going to talk about that. And I had planned on talking about remote credential guard and restricted admin, but these are not enabled by default, either on the server or the client. So unfortunately, they didn't make the cut for the 30 minute version. So risk of RDP, well, of course, the biggest risk is a monster in the middle attacks or Mallory in the middle or Medler in the middle. I don't know what to say anymore, but I don't want to say man. So it's going to be monster in the middle for me. All right. So what are the risks? Well, the risks are of a security downgrade attack. So NLA goes down to TLS and this works by default. What happens also is that user can click through warnings, although you'll see later that it might not be relevant anymore. And the impact of that monster in the middle attack is access to display, access to keyboard, access to clipboard, server side takeover, client side file stealing, and client side takeover, implementation pending. We'll have that one day. So why am I talking about RDP? Well, I have a shout out slide way later, but I need to address that two of the guys who worked on PyRDP are back there in the corner, Emilio and Maxime. Round of applause for these guys. And Emilio presented about PyRDP here. So this talk is basically the brother protocol, look into the protocol instead of look at the tool of it. But so all these references, which you'll have available as clickable links in the slides are to the stuff where we presented PyRDP and how to use it. So we're not gonna spend time on that. Just gonna focus on the risks and impact. But without these guys, none of this would be possible. So what does a protocol downgrade looks like so you can identify that risk? So the normal flow for a modern RDP connection with NLA is you get a dialogue, a native on the client side dialogue that where you input your credentials and then you get the certificate error if any. If you don't have certificate error, you don't get any. If you map a drive, you'll get an additional warning because mapping a drive has security implications, which we'll see. Now what does the degraded flow looks like? So if someone has PyRDP in front of you somehow. What you'll have is you'll have the certificate error first and then a graphical login. So on any system that you connect, that then you get to a graphical login, there's something fishy going on because in most cases, even if RDP is not RDP, even if NLA is not enforced on the server, if your client supports it, they will be upgraded to NLA automatically. So having the graphical login shows you that something's really trying to negotiate at the lower security level of RDP. So this is basically, one of them is the graphical and the other is the Windows native. And so why the Microsoft did graphical login? Well, I assume that it's for flexibility reasons because everything is delegated to the graphical pipeline. So no matter how you want to authenticate now or later, you can do it as long as it relies on keyboard and mouse and graphical interactions. Whereas when you implement this like the right hand side, then it's at the protocol level. So if you want to change anything, it needs a change in the protocol which means a change in the client and the server. So they kind of thought they were smart, but they weren't. So NLA, so it's as I just said, authentication before the session establishment. What are the security advantages? Attack surface reduction. Think of all the code displays and stuff. We'll I'll show a list later. Also DOS resistance. So if you send one packet to connect to RDP and then the server replies with like virtual channels and display bitmaps and stuff like that, then you can do potentially use that as a denial of service and also a lot of resources on the server side are allocated to set that up, right? Oh, I have a client. I need to set up a whole virtual desktop shell and allocate like at least 60 megs of RAM maybe more. And so if you do that consecutively, then you have a DOS on the server side. Also allows a single sign-on. It was introduced in RDP 6 by default since server 2012 and Windows 8. And it's the famous tick box, usually in a lot of legacy system or the shady deployment things, you'll see like, oh, go un-tick that, you know? Then you shouldn't do it. So I mentioned the attack surface reduction. Imagine all of this needs to happen at the server side and on the client side, even before authentication is done. So the untrusted user has access to all that surface. And this is why they got rid of it by using NLA. Now, what does the authentication part of NLA looks like? So it's called credit SSP. And inside the SPNGO, you can do either NTLM or Kerberos. I'm not super good with the AD stuff. I'll need help and some further research is related to that. But what's interesting that I want you to get out of this diagram is that the crypto prevents monster in the middle attack because it mixes the stuff, the fingerprint of the public key with the challenge, which means that you cannot monster in the middle it in the TLS sense, like negotiate on the one hand and then fake a new negotiation to the victim. This doesn't work because of that mixing the challenge. So how do we attack NLA? What are the risks? So the first one that was obvious because I mentioned it earlier is the downgrade attack. So that works. How do you prevent the downgrade attack? Well, you enforce NLA at the server side, obviously. And you can also enforce it with PowerShell with group policies which are listed here. And one of the group policy way prevents users from disabling it later even administrators, which is good. Now, we were like, okay, that's not cool, but how do we attack these environments? So we thought, well, if the server decides, what if, and we are in the network path, how about we redirect it to a machine we control? Well, it works. So we detect that NLA is enforced on the server side. We decide, okay, we forward the packet to a different destination, to an attacker control non-NLA system. And if the user is curious and clicks through the warnings, he'll get in and we'll have him. So this non-NLA redirection, unfortunately, is as designed. So we had an exchange on Twitter. I asked the Marc-André Morro, a very prominent expert on RDP, like, what can be done about it? Isn't there a way to enforce NLA in the client? And basically, it was like, not really. And unfortunately, the more mitigation advice, the good news that I had, is the stuff I cut from the deck. So I'm gonna tell you right now, if you wanna mitigate this attack, you need to look at restricted admin or remote credential guard. Why are there two different features? Because one of them works for AD and Kerberos environment, and the other one works for when stuff is not domain joined. So they cannot overlap, the technologies are just incompatible. And this is why it's not enabled by default, and this is why this whole thing is a mess. So the third attack, Alex Beaulieu, who is probably, or maybe not, but he is at NordSec, did implement that attack. And so we whiteboarded this with Emilio way back, and we were like, they got the crypto right, unless we found an implementation error, there's no way we're gonna attack that. And then Alex, one day working on PireDP said, well, this blue part, you're right, we can't attack it. But I realized after it's done, we fall back to TLS. There's no keying material derived from that used after, which means that if we have the server's private key, which works in forensics context or honeypot contexts, well, we can just pass the encrypted blob, don't look at it, don't understand it, and then we fall back to TLS, and so the attack works. So we are able to attack, well, the whole world is able to attack RDP, NLA, if, and it's a big if, you have access to the target's private key. So I'm gonna demonstrate the NLA attack, the NLA bypass attack, and for this specific case, we decided to try if we use Let's Encrypt Certificate. Does it work? Do we get warnings, certificate warnings or not? Can we use pretty much any cert to authenticate RDP? And look at this, gonna pause it a couple of times. So we are connecting, so on the left-hand side is the victim, on the right-hand side, the shell is a private key running, and we are opening the player. So the player is the interactive attack tool where you can take control of the RDP session. So now we set all that up. So the victim connects, first warning, okay, first warning, I'm mapping a drive. So this is expected unless someone clicked, don't ask me again, I never do that because I always want this to be in my demos because it's important caveat to understand. So if the users are properly trained, this doesn't happen. Well, I'm clicking through anyway here, but then no certificate demonstrated. I'm authenticating, the victim is authenticating regularly, we have control, and this is an NLA system, and you can see on the top the padlock, right? So no certificate error whatsoever, nothing was, no warnings, and the padlock is there, and then access is granted. And so this now will become a generic short video of the risks of all the stuff that we can do once we convey the user to get in like that. But think about one scenario. So manage them and link someone where you have access, the private key can be a relatively rare occurrence. But so one way this was weaponized in red teams is that you send a .rdp file as an email attachment, almost no provider blocks it. Credentials are pre-populated, we see, so right now I am capturing all key strokes, I am saving files from the client at the attack level without the client knowing that files are being looked at. Then you can save them interactively. This can also all be automated to be done automatically because it doesn't scale in a pen test to be looking at people's screens like that. So now we're looking at the secret and it was collected and it's a video from ATS account, fortunately. But so the red team technique that I just mentioned is called Rogue RDP. There was a nice blog post by ready-to-day guides and my notes don't have access to them. But Mike Feltcher, a red team guy from the US and he's very good and very solid and it works, right? Because all of the IOCs, all of the stuff generated is coming from legitimate processes of the Windows stuff that works on the server and the MSTSC on the client side. So it's kind of something that is flying under the radar right now from a lot of the EDR's perspective. So now we're taking control. So this is another feature that I wanted you to realize. So you can see that on the right-hand side stuff is happening because we took control. What we do on the client side is we just block it so we don't see anything and then you can run a payload. This was an example and then we can give back control to the client and then the client will have access to the system again. Last is the clipboard stealer. So an interesting thing about the clipboard stealer right now is that I use the clipboard on my host but it is automatically shared to my client VM and this is automatically shared to the server and the server always says I want it. So boom, clipboard stolen. We are collecting stuff from bad guys right now using this clipboard feature and it's pretty interesting. Chat messages, IP addresses. So what's the villain I mentioned at the top of the presentation? Well, it's a net NTLM hash capture. It's a feature Lisandro added back in November, November, December. I reviewed it for a long time. It was complicated. So we figured the NTLM exchange, okay, we need the private key for the NLA stuff if we want to do the NLA bypass attack but the handshake is still happening. Can we fake our own challenge? Instead of using the server's challenge we can never do anything with it. Can we generate our own challenge and then whatever the client sends back to us we're gonna use it to crack the hash so we can crack that net NTLM V2 hash and we knew it was gonna work because Responder implemented it but it was super badly documented and Responder is not a comprehensive RDP system so they really did what they needed to do in order to do the attack but we wanted to support all RDP versions and integrated this in our toolkit. So we thanked them and we give them credit for how it come up with the attack but we implemented it in our own tool. And so what does this looks like is that we basically in the monster in the middle layer send a challenge dimension, we steal the hash and then you send this to John the Ripper or hash cap. And so it looks like this and when you crack it with John for example with the work list you do then crack them. So again, this is a hash cracking attack so depending on the complexity of the user's password it might not yield to automatic results but as Pentester will tell you the more you collect eventually you'll crack one. So how can you prevent this hash capture attack? You verify the connection to the RDP server so server address domain name you always look for valid certificates but as I've shown you can get a let's encrypt one and turns out that you don't even need to respond to the HTTP challenge of let's encrypt in order to get one. Someone after seeing my talk sent me a resource on how you can generate let's encrypt certificate for your LAN. So there is a way with the EFF to do that. So if attackers would be doing this it could get nasty but what I wanted to get at is how bad really is it? And this is where we needed to report something to Microsoft. So we have our victim on the left attack tool on the right and we're connecting. We're sending a password. So okay I did a failed login attempt just now. I know it's super small trust me we have the hash at the right hand side. It doesn't really matter just trust me here but so I did a login attempt failed but we did collect a hash but where was the certificate error? We didn't get it. Is it possible that it happens after? So this was for a login failed. Even if the login is failing we could still crack that hash by the way and get the password that the person did input. So now at the second time I put in the right password whoops missed it from a split second. So if the user correctly attends gate you will get the hash that you could crack and this puts the client in just a weird state and so it happens to do an RDP connection internal error occurred. And I played with it with this for a long time and the internal error is so deep that all subsequent connection even good ones are gonna fail. I don't know what's changing in the state of the client. Something is getting really weird here. But so this mean that we can collect legit hash of a user that successfully attends gate and the error message is kind of not obvious. Not something you're gonna report to if you're being attacked to your IT and you had no certificate error. So this means, let's just finish, is it long? I think, okay, so yeah, the video ends with we're gonna take the hash and we're gonna crack it and John. I have time because I cut so much content so I'll let it go to the end. We'll see. And the password is a bit, it's purple, I think. But so use John on the hash. So PireDP features can attack a whole LAN, by the way. So if you are in the middle on the network path, you could just monster in the middle a whole slash 24 and then just collect these hashes and try to make sure that when the user gets pissed off you just shut down the thing so that they can work. It's pretty destructive attack, I have to admit. But so imagine in an internet cafe or something like that. So here, the video finishes with we crack that hash. But so what does that mean, okay? It means that pretty much you must never use RDP on untrusted networks because everything by default that could be done, was done, was enabled but still we collect the hashes. So without VPN, RDP thrown in the garbage. Or when you're at your home, maybe you trust your network, that's fine. We're not even in internet cafe as much anymore anyway. But so the other thing we can recommend is avoid NTLM use Kerberos and audit NTLM usage. I was told this is possible but I would need someone with better knowledge of AD to help me in that research. I just don't have the lab or the capacity and or the enterprise network to validate that. And I don't know how practical this is anyway. So wrapping up, attacks on the client. What can we do? What are the risks? So we can steal files, clipboard, keystroke, record the screen, steal hash or plain text credentials. So if we can perform the darn great attack we steal plain text, if we can't we can steal hash passwords. We can do code execution via DLL side loading, implementation pending. But this is what the red teamers are doing with the Rogue RDP system and they are using PyRDP by the way. But so the way I say implementation pending is that we have access to the file IO channel. We just created it to steal stuff right now but probably before the next NortSec will have a path to write files. And so the right now trendy attack is you put a DLL in the team's very popular teams chat client and teams is vulnerable to DLL side loading so you implant a DLL with the good hijack stuff in it. And so if you generated the DLL specifically for the target so it's not, the hash is not known then what TTP can the blue team really get, right? Because this is coming from RDP, stuff that no one's looking at right now. So I think this is probably a very effective red team technique to use but I'm only a researcher so maybe the practicality is not there. If anyone is really trying to use it go look at the Rogue RDP stuff and if you want help or feedback I would be interested. But we need to talk about the blue stuff too, right? We need to fix this. So attack that can be done with a server well credential brute forcing sessions take over common injection as we demonstrated. Now the future we're just opened up so much. So, RD gateway I'm not looking at remote desktop gateways at all apparently I can probably support them and attack them. I would like to see do we have any options for I want the TLS certificate to come from a specific CA otherwise I don't allow the connection. This would get rid of the whole let's encrypt can sign any cert and this makes the user think he's safe. I want to look at anti-unmanned restriction shadow framework which is both on the defensive and offensive and I want to start documenting some of this stuff inside in blog posts. Now what are the red team takeaways? I'm wrapping this up. So RDP is often misconfigured and under the radar and you can do more than credential brute forcing with it I think so it should become part of your attack toolkit and again this is niche corner try your regular stuff first but think about it once you are against walls. The blue team takeaways now are never allow your employees to use RDP on protected networks and I know this is completely opposite of the zero trust people who are trying to get rid of the VPN but you'll have to encapsulate this in a web somehow to remove all of these attacks. So if you're like oh yeah we're zero trust but RDP is still going on its own without the VPN doesn't work. Train your users not to click through certificate errors. Now make sure NLA is enforced by default and I gave the group policy to do that in the talk and long term we'll have to think about and you didn't have the research unfortunately but you'll have to think about rolling out either remote credential guard or restricted admin for client side enforcement but since I've written these lines Microsoft patched last patch Tuesday maybe not this month but the one before it was critical vulnerability in enterprise network having either of these activated. So some people are still finding problems around those security technologies. I want to give a big special shout out to Marc-André Moreau, a weight coding. He works for Devolution and he is really helping me validate like when I'm like is this a vulnerability or does the Microsoft people are really aware of this and he's like no I think they're not aware of that. I think they haven't looked at it that way because they're not attacking it like you are. So he helps me a lot and together well he's like really connected with the Microsoft guys and he's like on Twitter like tagging them and saying like you should look at this and reply to this. So Devolution are really trying to fix the problems of RDP that even Microsoft is in denial of it. I opened a case with them regarding the NetNTLM attack and they said it's as design. They closed it two weeks ago as design. I don't know what I'm gonna do with it but I mean he so while I'm looking at attacking RDP more he's looking at like okay how can we completely ignore it? He works for Devolution who are providers of remote access security and stuff and they had a booth here at Nordsec but they are really trying to do the right thing and have the problem fixed in Microsoft's product. So I'm gonna finish with the thank you. Special thanks to those that made RDP possible. So Citronor, the RDP guy, Emilio Gonzalez in the back, Francis Labelle, I haven't seen him but he might be here. Maxim Carbono in the back, Alexandre Beaulieu and Cool Acid and so I had the question but it's more see you at the panel. Thank you for being here.