 Gabriel gave a workshop a couple days ago. You gave it yesterday and you'll also be, you'll be on the big stage tomorrow, right? Tomorrow afternoon. Tomorrow afternoon. And, you know, it's a very good one to start off the Saturday at the speaker workshops. And it is, give me the, actually I'm not sure. I'm just going to wait for it, wait for it, wait for it and mute the mic. I mean, don't worry about it. This is pretty common. We are really right on schedule, like on the dot, which is excellent. The story yesterday, I don't know if anyone caught it yesterday. We had a, we had a plenty of AV issues, but one of the more, the worse one was, imagine if you bring in a work laptop from, I'm not going to name who the company is. And imagine that the company laptop you're trying to use for the presentation got everything locked down. All no devices, like no ethernet, no USB, and you can't even get your, you can't even get your laptop working on one of these things. So how in the world are you ever going to be able to, I mean it was like one of the most locked down machines. Basically it's normal to a point where it's useless and we had a 15 minute delay, nothing could be worse than that. I think we're, but I think we're ready, but without much to do, it is absolutely my pleasure to introduce you to Gabriel Ryan. Hi doing everyone. You guys recovered from last night? No. Not yet, still working on it? No. It's all right. Wait, wait a minute. I have to do some slide shenanigans. This might be the wrong slide deck, but it's okay. I have the other one like right here. Uh oh. It's okay. This actually isn't the demo gods, it's the slide gods. So I mean, I mean if I can just settle for the slide gods, that's, I mean I can deal with that. But as long as this, does this have everything that we need? Yes it does. Okay. Next year I think we're going to have a, but now you know what it does remind me, I think next year we're going to have bingo cards. Like, you know, if people have AV issues, if speakers have AV issues, you know, say, if someone brings alcohol and says, press this, we get off it. Here we go. I mean, we could just do like the DEF CON AV issues drinking game. So I don't think any of us would make it out of this room. So, uh, all right. So, uh, so my name is Gabriel Ryan. I'm a security engineer at Gotham Digital Science. We're a New York and London based security consulting company. Uh, just do infrastructure testing, red teaming. Um, I'm not going to drive this far out too long because time. So, new stuff in this presentation. Uh, so we're going to be looking at a couple of new attacks today. Uh, which I mean really are just kind of like building off of like the previous, you know, 15 years of rogue Axis one attacks. And just kind of adding a little bit to the top of that. Um, and just doing some new stuff. So we're going to be talking about hostile portal attacks. Uh, in which you can actually steal Active Directory credentials without actually being associated with the network which is pretty cool. And we're going to look at indirect wireless pivots which is, uh, it's a way of bypassing port based access control mechanisms on wireless networks. Uh, but before we talk about any of this stuff, we need to talk about WPA2 EAP. Uh, reason being it's kind of the background, um, info that we need to understand everything that we're going to be doing later in this talk. So, um, anybody here familiar with rogue Axis one attacks? Okay, about 50, 50. Um, so rogue Axis one attacks, I mean, they're the bread and butter of modern wireless penetration tests. Uh, you can use it for all kinds of cool stuff including stealing radius credentials, uh, performing, uh, really, really stealthy man in the middle attacks. Uh, you know, uh, making like little fake phishing, logging portal things, et cetera. You can use a pineapple, that's the kind of attack they use. Um, there, there are a lot of different kinds of rogue AP attacks, but I mean, uh, the most basic one is the evil twin attack. Uh, so let's say that we are, we have this access point, uh, DEF CON open. It's operating on channel six. We have these four clients that are associated with it. Um, so the, let's say that we were to, an attacker were to create, can you guys hear? Can you guys hear now? Oh, this is really directional. I'm like, okay, so I gotta hold it like this the whole time. Cool. Awesome. So I'm gonna walk around and just kind of like, all right. All right, so, uh, uh, I'll just pick up, okay. So the first thing we're gonna talk about are like rogue access point attacks. Just gonna repeat in that section because I wasn't, yeah. Um, so let's say that we have this, uh, this access point here. DEF CON open. It's operating on channel six. And we have these, these four, uh, clients associated with it. Um, and you know, let, let's say that an attacker were to create, um, an access point. There was an exact duplicate of that. So same ESSID, same channel. Um, do you guys know how, uh, show of hands? Do you guys know how these clients would be able to distinguish between the two access points? Signal strength. Uh, yeah. So like if the attacker just creates, um, another access point that is, that is these exact same attributes, uh, but is able to amplify the, the, the gain on that, um, uh, ever so slightly stronger than, than the target access point. All of these clients will actually draw their attention, uh, connect to the, to the attacker. So of course from here, uh, you have a bunch of stuff connected to you and you are a router and you can do man in the middle to actually all this really, really bullish, just awesome stuff. And these have been around for like a really long time. Um, actually the first, uh, document case that I could find was in 2002. Um, you know, this FAQ on how to make wireless, uh, uh, LAN security, uh, more secure. And, and that was my CW class. Uh, of course in 2003 we had the classic ASleep tool by Josh Wright, uh, moving forward a bit. We have karma attacks which are a more sophisticated attack, uh, which we're not actually going to talk about today, but we're looking into, uh, by Dino Diazovi and Shane McCauley in 2004. Uh, and then of course in 2008, we have, uh, and this is where we actually start building off of, uh, free radius WPE by Josh Wright and Brad Antonowitz. Very classic tool. And then of course back in, uh, at DEF CON 2022, uh, you know, 2014, this was actually the talk that got me into Wi-Fi. Um, we have improved karma attacks, uh, by Don White and Ian DeVilliers because, you know, at this point, uh, karma had actually broken for a while and they managed to fix it. And they also did some EAP stuff that we're going to be building off of as well. And then in 2017, very recently, we had Lure 10, uh, by the guy who wrote, uh, Wi-Fi Fisher. And this was, this is actually a way of like, uh, exploiting Wi-Fi sense, uh, in Windows 10 to get stuff to connect to you. So as you can see, these attacks have been on-round for a really, really long time. And they, you know, they haven't really found a way of fixing this with open networks. So pretty much the thing that you use to, to prevent, uh, these attacks is your WPA. Um, further today. So traditionally rogue AP attacks have been used to fill two basic roles. Uh, you know, man in the middle attacks, which is stealing creds and also, and also, uh, gaining access to the wireless network. But in this talk, we're going to look into rogue AP attacks as a means of lateral movement, uh, which is kind of newish, new, yeah. So, I mean, let's talk about evil twin attacks against WPA2, EAP. And to do this, uh, we first actually have to cover EAP. Anybody know what EAP is? Or how it works? Okay. So EAP is the, and for those of you who do know how this works, yes, I'm going to oversimplify this for like two minutes, but I'm going to actually go into the full definition later, uh, so bear with me. Logically EAP, um, it's authentication process that occurs between the supplicant and the authentication server. What is the supplicant? The supplicant is just a fancy way of talking about your wireless client. And the authentication server is like your radius server running and focusing on today. Um, the first stage of this is that the client makes an authentication request to the authentication server. And at this point, uh, the authentication server responds to an X509 certificate. And the goal of, you know, the reason why it responds to this X509 certificate is the authentication server needs to be able to prove to the client that it is who it says it is, right? Otherwise you don't know what you're actually connecting to your authenticating with. So at this point, if the client accepts the authentication server, the, we've moved from, uh, we were just at the outer, uh, what we call the outer layer of, uh, of EAP authentication to the inter-authentication protocol. Uh, and what that is essentially we set up a secure tunnel between the client and the authentication server and, uh, all authentication process happens through there. So, um, you know, the reason why, by the way, we use a secure tunnel is that without it, this entire authentication process can be sniffed. You know, uh, regardless of the fact that this is WPA2 EAP, uh, the EAP is actually what we're using as the authentication mechanism. That means that the WPA, um, the encryption from that doesn't actually kick in until after authentication finishes. So up until this entire process finishes right here, uh, what we're actually looking at is an open access point. So this is, this is all like open. And, and, and without that secure tunnel, you can just sniff the credentials, right? So in fact legacy implementations of EAP were very important to this. Um, you know, EAPMD5 is a really good example that comes to mind. So I, when I mentioned that there were like two components to the EAP authentication process, um, I, I, I kind of, uh, that, that was, that was a bit of a simplification. There are actually three, right? There are the, there is a supplicant in the authentication server, or that is the, the wireless client and the radius server in the background. But there's this intermediary, uh, that has to be between the two of them in order to get to that end. You have a, a radius server and, and, and at the very, you know, front of it, you have the, uh, the supplicant or the, or the wireless client that's trying to authenticate with the radius server. But all this communication has to go through the, through the access point. Um, you know, and in fact the communication between the supplicant and the access point is going over layer two. And of course the, uh, the access point is communicating with the authentication server, uh, using radius, which is kind of what AP works kind of looks more like this, right? So you have the, um, the initial, um, the client is sending the authentication request to the authenticator. And then, you know, once again you're getting this response, this X519 certificate. And that's coming from the authentication server, but it's being sent to the client by this AP. And at this point, you know, once again the client, uh, has to accept the certificate. And, you know, if the client accepts the certificate, your AP challenge and response, uh, go through that, that secure tunnel. Um, so remember that this, this authenticator is an open access point. Does anybody see a problem with this yet? Whoops. No one? Okay. So remember that, um, remember that, uh, you know, we were talking about earlier how open access points are susceptible to these evil twin attacks. Well, and up until this whole process finishes, this is an open access point. So what an attacker can do is actually, you know, using the evil twin attack to force the client to, um, associate with the attacker and begin, begin this authentication process. And then the attacker just runs a rogue radio server in the background and, you know, goes through this entire authentication process. The first thing that happens is the victim is upsetting the author quest to the attacker. The attacker responds to the forged X519 certificate. At this point, the onus is on the user to reject the certificate. You know, barring X519 certificate, just blindly accepts invalid search, which that actually does happen quite a lot. Um, but leaving aside that scenario, um, it basically the responsibility is completely placed on the user to identify this as an invalid certificate that they should not accept and to reject it. If that does not happen, um, this, this inter-authentication process, uh, with the, that goes to the secure tunnel actually happens with the attacker, then the attacker receives both the challenge and response from the attacker. So, so I mean, I'm going to do two kinds of demos in this. Like, if it's just like a, like one background demo, um, I'm not going to bother with the live stuff because why attempt to demo gods. So this is going to be a video. We'll just get later on in this presentation. We're going to do more live stuff. But for the sake of time, uh, this is what this attack would look like from the perspective of the attacker. So as you see here, the attacker is creating, um, um, a forged and it's kind of filling in focus values here. I'm going to kind of skip through this. Bless you. And at this point, the, um, the attacker is actually, um, going to start up this, uh, rogue access point. And as you can see, at this point we have this, uh, we have a client, you know, where it says, um, if you see, I don't know if it's, it's probably pretty small from the back. I apologize for that, but, uh, you have a client that's associating with the credentials, or not the credentials, but the challenge and response that can be used to obtain credentials. And then of course from there, you can crack this challenge and response using, uh, ASleep, which by the way, as we mentioned was, you know, came out like well over ten years ago. Um, and, uh, and there you go, you have plain text credentials. So, that's pretty cool. Um, you know, about the same time that this, this attack came out, uh, have you guys heard of EAP TLS? Or have you seen that form of EAP, or, uh, WPA2 EAP where, uh, um, you have to put like a cert on every single machine? Have you, have you heard of that? Yeah, so that was, that, um, protocol actually came out, I believe in response to these attacks, um, around the same time in 2008. Um, and, you know, the idea is that, uh, because you're using mutual authentication, using X5-9 certificates, uh, you know, from the, from the get-go, uh, none of this would work, right, because the client would identify, it just, it wouldn't even answer the, you know, application. So the strength really lies in these client-side certificates. Um, any network administrators out there? Anybody, like, I mean, raise your hand if you, if you, like, think that, you know, putting a client-side certificate on every single device or network sounds fun. Is this something that you'd like to do? Okay, we have one guy. But, I mean, so EAP TLS, although it protects against this, it's wildly unpopular. I mean, it's, it's really arduous you have to put, um, one of these certs on every single device or network. And not only that, it's possible that you may have devices that aren't even compatible with this. I mean, especially, like, if you work, like, in healthcare or, you know, industrial control system, stuff like that, they may not even support client-side certs. So, I mean, you, you run into this classic security versus convenience scenario where you're, you're, you're forced to choose between, um, an authentication mechanism with a known weakness or a highly secure, um, authentication mechanism that is just really difficult to implement. So, of course, you know, anyone, anyone go to, uh, certain other security conference that has lots of vendors and flashing lights earlier? Yeah, so, like, of course, this creates a market gap. Uh, you know, someone is going to come in and, and try to, uh, create a product, uh, that can be used to compensate for these security issues while still being easy to use. So, um, and the current trend, actually, is to focus on breach containment, rather than prevention. Uh, so the idea is that, you know, yes, you acknowledge the risk associated with, um, using, um, EAP PEEP or EAP TLS, and that this network, you know, is vulnerable to it. Um, the idea is that, you know, once the attacker gets on your wireless network, you immediately contain them, and, and you know, prevent them from accessing anything important. So, what we're going to explore today is whether this actually works. So, um, the, uh, I guess the most common way of approaching this scenario is to use a network access control mechanism. Uh, I'm just going to present to you guys this little, this little cartoon before we continue. So, um, network access control mechanisms. They're all popular ways of containing wireless breaches, and the idea is that, you know, when a new device is added to the network, you immediately, you know, flag it as either authorized or unauthorized. If it's authorized, you let it continue, uh, and, and access stuff, and if it's unauthorized, you place it on a quarantine VLAN or, or, or flat out, um, you know, block the port and, and not, and, you know, disconnected entirely. Um, and, and it's not allowed to do anything. Um, so, I mean, there's two, two ways of doing this. You know, there are two ways of doing this later. Uh, but traditionally we've had two different kinds of network access control mechanism. We've had agent-based and agentless. So, um, with an agent-based NAC, uh, you actually have a software component that's installed on every single authorized endpoint. You know, this, this agent, um, the job of this agent is to communicate with the brain of the NAC, and, and pretty much, you know, I, I allow the brain of the NAC to perform deep interrogations on the endpoint. Um, you know, it, it's really effective, but, you know, once again, you run into a kind of like EAPTLS. Um, you also have agentless NACs, which it just uses passive fingerprinting and also does like external scans to try to identify what's authorized and what's not. Um, you know, as you can imagine, this is pretty easy to, to deploy, but you know, you can't examine the internals of the devices, so, uh, it can be bypassed pretty easily by, by masquerading as, as something valid. So, you know, once again, you run into this recurring dilemma where, you know, you have a, a, a, a more insecure solution but, that, that's pretty practical. And it's very impractical. So, we're kind of, you know, back to square one here. And of course, this creates yet another market gap. Um, you know, where this, there's this high demand for a solution that, you know, offers the deep interrogation capabilities of an agent based NAC, uh, but it has the convenience of an agentless NAC. So, you know, this, this leads, this led to the rise of something called the next generation NAC. And there's a, there's a lot of different, um, there's a lot, a lot of different, uh, uh, approaches that people have taken. Uh, we're just kind of, um, so there's a particular NAC that I wanted to bring in here and do a demo with. So, uh, I actually tried to get approved to bring one here. So I put, I put in a ticket to, to, to my company's, um, IT department. Um, of course these things cause $10,000, $10,000 a pop. As you can imagine, uh, yeah, that, that, that didn't go very well. But not only that, you know, our legal department just kind of said, uh, yeah, you, you shouldn't go up, keep this vendor neutral. So, um, the, the vendor that we're going to talk about, uh, is going to be referred to as vendor A. And if you're really curious and want to know, you know, who or what I'm talking about, do some research, you can probably figure it out, but I know nothing. So, you know, vendor A uses, you know, a good example of a next generation NAC, um, and, and, and approached to kind of like, you know, bridge this, uh, you know, gap between agentless and agentless, agent based and agentless solutions. Um, it's vendor A. And vendor A uses without using an agent. And to do this, it authenticates over S and B using a single administrative service account. And this single administrative service account runs with, you know, pretty high privileges. I think it actually runs as DA, if I remember correctly. And this allows it to reform deep interrogations without the use of a, use of a network. Unfortunately, uh, does anyone see a problem with this? Yeah, you have this single point of failure. You have this device that, you know, you have a single point of failure. So, background info. Raise your hand if you do not know what an S and B relay attack is. Okay. What about those who do know what an S and B relay attack is? Raise your hand. There are a lot of undecided people here. Great. Um, it's okay. It's early. Um, so, you know, S and B relays, you know, pretty much they take advantage of the NTLM protocol. You guys from NTLM and all, it's a simple challenge response mechanism. Very similar to PEEP, which is what we talked about earlier. And the way that this works, um, actually I need two volunteers. You serve the tattoos. Okay. So you want to authenticate with that guy on the computer, right? Um, so what you're going to do is you're going to send him a plain text string, right? Uh, or, actually no, you're going to say, I want to authenticate with you. You're going to say, okay, uh, that's great, right? Um, here's a plain text string, okay? You encrypt it using password hash, send it back to him. And then at that point, uh, you know, he's going to say, he's going to decrypt the encrypted string using your password hash. And if, um, the decrypted string matches the original string, um, then, then, then the authentication attempt succeeds, right? Does everyone kind of get how that works? All right, that's NTLM guys. Um, so, no need to over complicate it. Um, so with an S and B relay function, um, actually tell you what, can you guys like pass it? I don't know what this is, but I'm going to borrow it. All right, can you head it to that? Yeah. So now you are going to attempt to authenticate with this dude. But the thing is, you think that, you think that he is him, right? So you're going to, you're going to pass your authentication, um, attempt to him, right? And you're going to just pass it directly onto this dude. No, you're not going to decrypt it and pass it back to this dude. Yes, exactly. And now, now you're going to just, you know, relay it back to, uh, to the server and you're going to decrypt it and is it, is it good? It's good. Okay, so you're going to pass it to this dude and oh shoot, he's authenticated with him instead of him. And that's an S and B relay attack. And you know, you can, you can kind of explain this using diagrams too, but I mean, does everyone get S and B relay now? You know, of course, if you, if you have everything authenticating, you know, using NTLM, um, then, and, and you're sending, you know, hashes to every new thing on the network, um, at this point you have the risk of S and B relay attacks, uh, where you can just, you know, um, authenticate with the network and, uh, and, and wait for the hash to be sent to you and then relayed them to anything that you want to authenticate with. Um, so that's bad. Uh, but you could also, you know, of course authenticity. Um, you know, but, but by default this is actually disabled on, um, on Windows machines except domain controllers. Uh, and that's because group policy is actually downloaded over S and B. So, you know, and the, and the cool thing is in this case you don't actually need a man-in-the-middle attack because the NAC appliance is trying to authenticate with you. Of course, you know, if you do turn it on, it'll, S and B is signing on, it will, it will mitigate, um, this untrusted endpoints. So, um, I, I guess, you know, that, that wasn't just a tangent for a reason. I mean, this tangent actually serves a purpose and that's to show that, you know, there really is no magic bullet. I mean, here's actually a really solid attempt to, to kind of bridge these gaps between security and convenience, but unfortunately the problem is that security with convenience is often a paradox. And, and, you know, that, that goes right back to the issue of EAPTLS, which we're going to look at, um, uh, later on. So, um, are any of you familiar with it? Have any of you tried to get on like a, like a hotel network or something recently and tried to ping something and you couldn't? That's because client isolation is enabled. So, the way that 8, um, 802.11 is supposed to work is that the AP is supposed to mediate all traffic, uh, between, you know, the, the client associated with the AP, um, and, you know, other endpoints on the network. So for example, you have these two clients associated with this access point and, and in theory, the AP is supposed to mediate all traffic. So, to enable client isolation, um, you know, you basically just prevent, you know, if you see a packet that's, that's going from one of these client devices and, and instead of going upstream, it's going to another, uh, device associated with the access point, you just deny it and don't let it, don't let it through, right? And on a wired network, this is actually, this is actually possible to physical level. But the problem is that on a wireless network, client isolation is a logical control. It's not a physical control. It's a way to communicate with one another. And this awesome research, fortunately, researcher, unfortunately he's no longer with us, but this awesome researcher named Cedric Blanchter in 2005, his answer was you can't. And, you know he introduced this tool called Wi-FiTab. And this was first released by Cedric Blanchter, as we mentioned in 2005. So once again quite a long time ago, and it was revived more recently by Oliver Lavery of Gothen Digital Science way before my time. Um, and you know the idea here is interface that's attached to a monitor mode interface. This monitor mode interface just listens for packets coming, coming from, to and from the AP, right? And you know, when you see it, when you see a packet being sent from the client to the AP, you inject the response as if it came from the access point. And this actually allows you to bypass client isolation. And, you know, of course there were, there are some later tools that built off of this, AirTun NG, it supports WPA1, these are both part of the air crack suite if you were here earlier this morning. And actually there is one that apparently you theoretically could use it against WPA2, although I don't believe it, called whole 196. You know, it's worth mentioning just because it's been talked about, but it's also considerably debatable whether it actually works. So to kind of demonstrate how this does its thing, let me just check the time really fast. Okay, we're doing decently, we've got to hurry. So over here, we have, you know, the bottom right, we have one terminal, right? And this terminal is the host operating system. In the top right, we're going to create an access point. And this is going to be the access point that we're going to be, you know, the network that we're going to be attacking. And then on the left here, we have an attacker machine. This is an SSH2, an attacking machine. So what we're first going to do is we're going to send five ping packets, you know, to the AP on this target network. And that's happening on the bottom right here. And as you see, we sent five ping packets and we have five responses. So, and then, why did that do that? Okay. There you go. Okay. So, and then on the left, we're going to, in this terminal here, we're going to run a tool called Wi-Fi Ping. And it's essentially a modified version of Wi-Fi tab that just sent any ICMP request that it sees, it'll send an ICMP response. So it's a pretty good way to do a constant of this. So now, you know, on the bottom right, now that we're running this Wi-Fi Ping tool, you'll notice that we're doing the ping again. But this time, this time you can see all, you know, although we sent five ICMP packets, we've received 10. And that's because, and you see all these warnings saying they're duplicate ICMP packets. And that's because we're actually sending packets to this device without even being associated to the network. So that just kind of shows you how Wi-Fi client isolation can be bypassed. So, yeah, anyways, back to, back to NACs, right? You know, some food for thought. You know, we've been focusing on whether or not, you know, you know, NACs in general are effective against, you know, stopping direct attacks, right? But I mean, what if we're missing the point? And not approaching this, this is the right way at all. The role of a NAC in containing a wireless breach is to prevent an attacker from accessing sensitive resources after the breach occurs. And, you know, unauthorized endpoints detected, it's either placed in quarantine or the port is blocked. When this happens on a physical, on a wired network, this is actually a physical restriction. So it's pretty solid. But on a wireless network, this can only be a logical restriction. And more on this later. So, you know, I think to understand the implications of this, it's best to use an example scenario. You know, we're attacking a wireless network and it's used to access sensitive resources. And we've already breached the perimeter using the attack we did in the first part of this talk. This is us on the left, you know, we're an attacker on this quarantine VLAN. And on the right, we have the victim that's on this restricted VLAN. And we obviously, you know, we don't want to be on this quarantine VLAN. We want to be able to get over to this restricted VLAN and access, you know, the sensitive resources and stuff. Unfortunately, we've been flagged by this, by this network access control mechanism as unauthorized. So, you know, we're kind of, you know, we've been jailed. We can't really do much. So the question is how do we get out? Well, let's talk about some more stuff. Anybody here use a responder before? Okay, cool. So, I mean, some of you probably are familiar with LM and R or MBTNS poisoning. Once again, quick review. Who here knows how NetBiles name resolution works? Okay, a couple of people. All right, so, you know, quick refresher, the way NetBiles name resolution works, you know, basically there's a cycle that goes through. The first thing that happens is that the Windows host checks the local cache of stuff that's previously sent information to. It'll also check the LM host file, which it's a hard-coded file that resolves host names to IP addresses. If that fails, it'll use local DNS to attempt to resolve these names. And finally, if all those options are exhausted, it will fall back to two protocols that, although under the hood, work a bit differently from a higher-level logical perspective and also in terms of the security implications associated with them, can be thought of as logically equivalent. And that's LM and R and MBTNS. And these protocols are best understood through example. Let's say that you have two NetBiles machines on the network named Alice and Leroy. Alice wants to get a file from Leroy, but Alice does not know Leroy's IP. So Alice is first going to exhaust those three options, right? Attempt local resolution also try local DNS. And if that fails, Alice is going to make a broadcast request across the entire subnet using LM and R and MBTNS. So at this point, every computer on Alice's subnet is going to receive this request. And the idea here is that despite all of them receiving it, only Leroy will respond. Does anyone see a problem with this? Yeah. So it's kind of an honor system. It's very similar to ARP in fact. Although it came out like 10 years later, so I don't get it exactly. But the problem is like if Alice receives two responses, only the first one is considered valid. This creates a race condition where an attacker can just wait on the network for LM and R and MBTNS queries and respond to all of them. At that point, the victim will end up sending traffic to the attacker instead, creating a man in the middle. So a quick demo on how that works. We have the attacker on the right or on the left, I say, and a victim on the right. And the attacker is going to run a tool by Lawrence Jaffee called Responder. That's going to do this. As you can see, we're poisoning element R and MBTNS, and we have these rogue servers here that are going to wait for the authentication attempts. And on the right, we're going to attempt to access a non-existent SMB share. And the reason why we're doing a non-existent SMB share is because it's guaranteed, you know, the host is going to see that and it's guaranteed not to be able to be resolved locally or using local DNS. So it's going to automatically, we know that it's going to fall back to LM and R and MBTNS. So we're going to do this. As you can see here, we end up with hashes very quickly. So we're about 5% through a little escape attempt from that thing. But I mean, this is, all right. The other thing we need to understand in order to figure out, you know, understand how we can get out of this is another attack that we'll briefly cover called Redirect SMB. So anyone know what Redirect SMB is? All right, it's pretty straightforward, right? You trick the victim into accessing a URL that takes them to a server and all this server does is redirects them to an SMB share on the attacker's network or SMB server. So they get redirected to this SMB server and at this point, IE or whatever it is they're using is forced to do NTLM authentication with the attacker and you get hashes as much as we previously saw. Requires a bit of social engineering. Okay, back to wireless. And this is where we go into new stuff, which is cool. Let's talk about hostile portal attacks. Hostile portal attacks are a way of stealing Active Directory credentials without direct network access. So how many of you guys seen something like this recently? Yeah, so that's a captive portal. And the way a captive portal works is that all DNS queries are resolved to the captive portal. The DNS server is pushed out through a DHCP option and then the DNS server then sends everything to the captive portal. Of course, you can also redirect DNS traffic in case they're manually specifying a DNS server and of course, if that fails, they're trying to access stuff directly using IP address, you can actually redirect HTTP traffic to the portal as well. So a hostile portal attack is very similar to this. It's based on, you know, the redirect to SMB attack. But, you know, instead of being forced to, the victim being forced to visit this captive portal login page, they're actually just forced to access an SMB share. So you redirect to an SMB share instead of the login page. Very simple, but very effective. You force the, if you look at this, oh, in the background, by the way, you poison all L, M and R and MBTNS in case they're just completely idle. But, you know, this is how it works. You have an SMB on the target network. Use a rogue access point attack to force the victim to associate with you and then you immediately redirect them to this SMB share using the same technique we used for a captive portal. And this results in lots and lots of hashes. And, you know, we're first going to show you a demo and I actually have, it looks like 15 minutes left, so I'm just going to fly through this video because, so here on the top right, we have a, you know, we're going to create our, we're going to create our legitimate access point. This is our target network and we're going to connect to it from our victim machine that's on the bottom right. And, you know, as I said, we're going to do this with an open network first because there are a couple more steps that we have to do in order to get this to work with EAP or WPA2 AAP, should I say. But, yeah, we'll get to that in a second. So, and I just got prompted to update when I recorded this. But, so we're going to associate it with this target network at some point here. Okay, there we go. Yeah, so our client device is now connected with the network. Then on the left here, we're going to launch the rogue access point attacks. The first thing that's going to happen is, we're going to start our rogue access point and then we're going to send some DL packets to kind of force it to roam from the target BS society to our rogue access point. So as you can see here, we have an interesting enough as soon as the victim opens IE, which we're going to do in a second, we have hashes. So if they're, you know, previously doing anything that requires HTTP, it'll just send hashes to the attacker. At this point, the attacker, and actually, thing to know, look how many times it's actually sending us authentication and that's because every time we type in a new character into the address bar there, that's actually sending out an HTTP request to us, we're just redirecting that. So every time you type in a character, we're trying to authenticate with the attacker. So, all right, so, you know, if we're doing this with WPA EAP networks, it's going to require a little more work and this is because, you know, in most cases we're going to be talking about EAP TTLS and EAP PEEP. Both use MSG CHAPI 2 as the inter-authentication method although it's, you can kind of, you can often get EAP, you know to agree to something a little less secure than that. But, especially with EAP PEEP, you're stuck with MSG CHAPI 2. So what this means is that with MSG CHAPI 2, it's actually a mutual authentication protocol. So this means that the server, the radio server must prove knowledge of the subsequent password in order for the inter-authentication attempt to succeed. So, this means that although, you know, you can force a device to connect to you and do that authentication process back offline, you know, there's still that very, very, very final step, that final stage of the inter-authentication process in which the client will actually not be able to fully associate with the attacker because it's going to, you know, the radio server is going to fail that final stage of the authentication process. So the solution to this is, well, we have a couple of them depending on the strength of the radio's passwords in use. We can use something that, this came out in the guy's from SensPost, Don White and Ian DeVilliers, they came up with a method called autocrack and add where you perform that first attack that we saw in the very beginning where we capture the challenge response, but then we immediately append it to the kind of the database file that our radio server reads from and we'll talk about that in a second. But if the creds are stronger, you actually have to, you know, crack them offline and finish the attack later. And that's actually pretty good. Talking about the first method, the way the autocrack and add thing works is that you take the challenge, you receive the challenge response, that's the thing that you're cracking to obtain creds. At this point, what is supposed to happen at the very end of the MS Chaffee 2 authentication protocol is that the radio server, or host APD in this case, loads the password from a file called the EAP user file. It's basically a very simple database that's implemented using a text file and it has information like that which is allowed to associate with the network. So it loads this password and it uses that to forge the authentication response, which is sent with a success message to the victim. And, you know, of course, you know, if it was able to load that file and it's able to provide a valid authentication response, the association attempt succeeds, or authentication attempt succeeds, I say. So with the autocrack and add technique that we talked about, what's going to happen is that the attacker, instead of immediately loading that password from the EAP user file, the password actually the attacker is going to take that challenge and response and then immediately send them off to a cracking rig. And the idea is that, especially if you're using a remote cracking rig, like, you know, cloud crack or something like that, that has a significant amount of horsepower behind it, you should be able to, or at least within a couple of attempts, crack that in time to then add it to the EAP user file, just kind of append it to the end of the file and then send the, you know, use that to create the authentication response. So it's almost like this race condition. And if that doesn't work the first time, you just try it immediately again, this time you already have it, and as the client tries to re-associate with you, you pull off the attack. So, of course that works with weaker credentials, but our second option is, you know, the offline crack. And, you know, you may be thinking, this is going to take a little more time, but remember that, you know, it actually isn't as bad as you think, you know, rather than the attack taking, you know, minutes to an hour, it's not going to take a few hours to maybe a week. And of course, you know, real attackers aren't time box, even if you have a really, really long radius password, you still have your APTs out there, like the guy on the right. But, so, one more thing to consider is the fact that you already have the credentials if you're on the network in the first place, which is pretty cool. But yeah, here we are once again. We're going to use the auto-crack and add technique to perform the previous attack against this time using a WPA2 EAP. I'm going to fast forward again because we have 10 minutes. So, we're going to connect the victim device to the legitimate access point on the top right. And then we're going to start the rogue access point attack. And that's going to happen right here. So, we're now on the left. And then we're going to lob D-auth packets at the legitimate access point and the client associate with the legitimate access point. And that's going to cause it to roam over to our rogue access point. As you can see, we've roamed over. And, you know, it's tried to authenticate. It's kicked us off because we failed the initial, the very last phase of the inner authentication. But, you know, at this point, we've also just cracked the, we've performed the auto-crack and add, which you can see on the left here. And it's going, you know, at this point, we just relaunch the attack, you know, restart the access point and do it again. And we'll notice that the victim associates with us. So, hit connect. And at this point we're actually associating once again with the target access point so we can rinse and repeat. And here we go. Bear with me. It'll happen like this. I'll just show you. Okay. Yeah. So, okay. So, where is it? Yeah. Okay. So we're getting a weird, like, start warning thing. But there we go. Okay. So, you know, at this point, the victim has just associated with the rogue access point. As you can see, we have hashes on the left. And, you know, as we type stuff in the address bar, you know, we're sending out these HTTP requests and it's just forcing more authentication attempts with the attacker. So what does this get us? I mean, it gets similar results to L and R and MBTNs poisoning. There are a few key advantages here. One, no network access required. And we're also not limited to a local subnet because you get everything that's connected to wireless. It's also not a passive attack, which is pretty cool. You know, we're not waiting for an L and R MBTNs lookup request. You're actually, you know, forcing stuff to authenticate with you. So back to our scenario. You know, called an indirect wireless pivot and this is how you use rogue AP attacks to bypass NAC mechanisms. So here we are. We're back at our scenario again. And we have the attacker, which is us, and we're on this quarantine VLAN over here. And of course we want to get over to this restrictive VLAN and access these sensitive resources. Unfortunately, you know, as we mentioned earlier, we've been jailed by this NAC and we're kind of stuck over here. Well, this is the second wireless interface to perform a rogue AP attack and then just force that authorized device to connect to our rogue access point. You know, at that point, you know, we could just use the hostile portal attack, which we just talked about, to get this device to send us NTLM hashes. Crack those hashes offline. At this point, you have the capability to authenticate with the victim and place a payload on the victim. You know, you might have to come back, but whatever. You know, so at this point, you know, we send this payload to the victim, you know, and what if we use, like, a scheduled task or something like that? For a second example, forget about being stealthy for a second, but just for the second example, we use a scheduled task, a time payload, and then we just allow the victim device, which is authorized, remember, to re-associate with the wireless network that it was originally associated to, that we're attacking. Well, at this point, it's still authorized, so it just gets moved over to the restricted VLAN, and now in the middle, this could have been the most effective knack in the world. It wouldn't matter, because we're still able to remove this device from its habitat, from its target network, onto a network that we completely control, and we can attack it. So a better approach, a faster approach for doing this, is to use an SMB relay attack, right? So, you know, we talked about that earlier, but let's say we have two devices now, and you have to use two devices, because unfortunately, since 2008, you do a service patch by Microsoft, MS 08068, I believe. You can't actually just do an SMB relay attack from one device and then back to it. That's an SMB reflection. You need at least two devices in order to make it work. Let's say we have a couple devices on the network, right? Once again, you force them to associate with you, and assuming that you have an account that can authenticate with both, you perform the SMB relay attack. Well, you do the hostile portal attack, and then you're receiving NTLN hashes at that point, so you can perform an SMB relay attack, and then, you know, once again, we place a time payload on the victim, on one of the victims. You allow the devices to re-associate with the target network by killing your rogue AP, and then once again, just wait for the reverse shell. And let's do this last, let's show you guys this last attack in action, and then we'll wrap this up. So now we have two victim devices on the top left and right. We have Lee Roy and Jenkins, and then on the bottom left, we have our legitimate access point, and then on the right, we have the attacker. So the first thing we do is we're going to connect both of these devices to the network. And we're going to start a rogue access point attack, like so, on the right. And so our rogue access point is now live, so we're going to send DLF packets to force it to roam. They're the client devices to roam. All right, one of them is authenticated, as you can see right here. And we're going to do this again, but this time for the second client device, and there we have this second authentication. So both devices are now associated with our rogue access point attack, or our rogue access point. So now we're going to create a Stager, we're using the Empire PowerShell framework, if you guys are familiar with it, but if not, it's kind of like Metasploit, but using PowerShell, so the easiest way to describe it. So we're going to use our Stager. And we're going to, at this point, we're going to find an IP address of one of our associated clients. So we're going to settle for Jenkins here, and we're going to use Jenkins IP address. And then we're going to take our Stager and use it as the payload for SMB Relay X, which is a SMB Relay tool, right? And, you know, as you can see, we interacted with IE that they gave us HTTP traffic, which is enough to set up the SMB Relay. And if we go back, there's a bit of a delay on the reverse shell here. We're going to receive our first reverse connection, which is going to allow us to place that time payload on the victim. There we go. If you can see that little green text, it says initial agent, blah, blah, blah, connected to 10.0.0.184. Now active, that's our payload. And we are now actually executing commands on the victim machine. So, now we're going to use a module, we're going to use a schedule tasks module to place a schedule task on this machine. Now that we're authenticated with it. Before we do that, we're going to run Who Am I and also just to see we have our privilege right now, our anti-authority system. And we're also going to just check the host name and figure out which one we're connected to. We're going to use the host name command. So we're going to do shell host name. And yeah, we're connected, we're currently, you know, have a shell on Jenkins. We're this guy on the left right there. And, you know, we're going to create that schedule task. And what's going to happen here is that we're going to set the time for execution. It's a couple minutes in the future, right? So, interesting thing happened when I was, like, recording this, which was that I actually forgot to attach the virtual device that was associated with the first wireless interface to the virtual machine, right? And I was originally going to just, like, re-record it, right? But then, like, I did set 160 retries for that second payload, the time payload. So what I ended up doing is, like, you know, I reattached the, what you're going to see me do is you're going to see me reattach the first device, you know, that I forgot to attach. And then, you know, a couple seconds later, I'm still going to receive the reverse shell, because this thing is still consistently trying to connect over and over again to this device that wasn't there. So I thought that was kind of cool. So I kind of left it in there. I'm going to actually kill our rogue accident attack and allow everything to reconnect. And you'll notice on the left here, we have one association right there, and our second association should have happened as well. At this point, you know, I'm going to skip through waiting through two minutes of this. Two minutes. Just enough time we need. Okay, cool. So I'm going to skip through this, and you see here, you should see me reattach the network after, because I'm trying to figure out what's going on. And I'm like, oh, yeah, time to redo everything. And then I start clearing everything, right? And I start clearing everything. And I hit the back button on this, because I'm about to clear everything and start from scratch. And then I receive the initial agent. So it actually did work, as soon as I plugged in the network adapter again. So that's an indirect wireless pivot. So the equivalent technique of doing this in a wired network would be literally unplugging an authorized device from the wall and then connecting it to a hostile network on which you can actually attack it. The reason why we're able to do that is because port-based access controls rely on the assumption that the physical layer can be trusted. In a wireless network, WPA2 EAP is the means through which the integrity of the physical layer is actually assured. And if you can't trust your EAP implementation and you have a weak form of it, the attacker can freely control your physical layer and it basically renders port-based access controls irrelevant. So what this demonstrates is that port-based NAC mechanisms, they don't really effectively mitigate the risk of WPA2 implementations or EAP implementations. And that adding port-based NAC mechanisms to a wireless network, it doesn't really make the use of EAP-TTLS or EAPP, any less inappropriate if the network in question is used to grant access to sets of information. And by sense of information, we're usually talking about something like PCI or HIPAA data. Remember that compliance doesn't necessarily mean security. So I'm just going to make one last case for EAP-TLS. It's not as bad as it used to be. You can use group policy to push out the search to the various network endpoints. And your best option, I think, is to mitigate this kind of attack is to use a private CA within your network and then leverage Active Directory to deploy EAP-TLS. And of course, if you have like a, bring your own devices, like a BYOD policy and people can bring their device on the network, at this point you could use a solid MDM to get those search on there or just have a really streamlined BYOD onboarding solution. And you could actually use Let's Encrypt as well to roll out EAP-TLS. Although even the people who make Let's Encrypt are like, this is probably not the best way to do it. Yeah, but just some closing thoughts. Just because wireless and wired networks operate similarly at a logical level and they're designed to do that, so it should be transparent when you're looking at higher levels of abstraction. On a physical level, in terms of the physics behind it, they work in a completely different way. So you have to keep that in mind when designing security mechanisms to protect them. And of course, as a community, I really question whether it's a sound decision to neglect EAP-TLS completely in favor of more reactive approaches that focus on access control rather than threat containment. And of course, I think most importantly, the needs for convenience and security, they're usually at odds with one another. So I think we should just be really honest with ourselves and maintain a very healthy skepticism toward proposed solutions that promise both. And if you want to look at the tool that I've been using to do this stuff throughout the demo, you can go to gethub.com slash Stolzys slash ePammer and check it out. It's open source. Thank you.