 So my name is Gabriel Ryan. I'm a security engineer at, let me just adjust this. Okay, in the back, can you hear me? Okay, good stuff. My name is Gabriel Ryan. I'm a security engineer at Gotham Digital Science. Also known as Solstice. We primarily do like app sec, infrastructure testing, red teaming, research, et cetera. So new things in this presentation. We're going to be talking about hostile portal attacks. That's a method of stealing active director credentials from WPA to EAP networks without network access. And we're also going to be talking about indirect wireless pivots, which is a way of using rogue AP attacks to bypass the port-based access control mechanism by controlling the physical layer of the network. So before we move on into that stuff, a little background info. We're going to talk about WPA2 EAP and the vulnerabilities that affect them. So historically WPA2 EAP, at least the weaker forms of it, have been susceptible to evil twin attacks, or rogue access points in general, actually. So rogue AP attacks, you can consider them the bread and butter of the modern wireless pen test. You can use them for stealthy man in the middle attacks, stealing credentials, all kinds of cool stuff. And the way that they work, the simplest form of rogue AP attack is the evil twin attack. The way that it works is that you have an access point, like the one that we see here, and then you have a bunch of clients to it. So let's say that these four clients are connected to DEF CON open on channel 6. So if an attacker creates an identical access point to this one, but with a stronger signal strength, so a stronger signal strength but also has DEF CON open channel 6, what will happen is this will cause the clients to drop their associations to the valid access point and then connect to the rogue access point, which you see down here. And at this point, the attacker has a man in the middle that he or she can use to do all kinds of crazy stuff like, whoa, I almost dropped the shot glass. Like stealing creds and the attacks that we're going to see today. So I mean, these are not new attacks. They've been around for a really long time. In fact, the first mention I could find that was in 2002 in this wireless LAN security fact by CW Clouds. It talks about evil twin attacks. Fast forward a bit. You have 2003 of ASleep by Joshua Wright. 2004, we started seeing karma attacks. We're not going to go into those today, but if you don't know what they are, check them out. They're pretty cool. That was Dino D'Azovi and Shane McCauley. In 2008, you have Josh Wright and Brandon Tonowitz. Comes out with attacks. This is where you start to see attacks against WPA2 EAP using rogue AP attacks, and that's free radius WPE. 2014, by that point, karma attacks that stopped working as well. So two researchers, Dominic White and Ian DeVilliers, came up with, they essentially fixed karma and then also added a bunch of cool techniques for attacking EAP, one of which we're going to talk about. And also in 2017, very, very recently, you have the guy who wrote Wi-Fi Fisher implemented the bluer 10 attack, which you can use against Windows 10's Wi-Fi sense. So what's common, the common theme here is that rogue AP attacks have been primarily used to build one of two roles, stealing creds using man-middle attacks or breaching WPA2 networks. In this talk, we're going to do something a little different. We're going to talk about using rogue AP attacks as a means of lateral movement. So before we continue, we should probably talk about how you can use the evil twin attack against WPA2 EAP. And to do that, we have to understand how EAP or the extensive authentication protocol works. So logically, for those of you who are familiar with EAP, I'm going to leave out the authenticator for now, just to make this, just to address this from like a high-level perspective first. But logically, authentication in EAP occurs between the supplicant and the authentication server. So the supplicant is just a fancy way of saying the wireless client. And the authentication server is the radio server that's sitting in the background, you know, deeper in the network. So the first thing that happens is the client sends an authentication request to the authentication server. At that point, the authentication server responds with an X519 certificate. And the role of this X519 certificate is to verify the identity of the authentication server. And if the client accepts the certificate, it's saying that it trusts the authentication server. And from that point forward, we move from the outer authentication, which is what we're seeing here, to what we're seeing at the bottom of this diagram here. And that's your inner authentication. The inner authentication occurs through a secure tunnel that's established at that point. Now, the reason why we need the secure tunnel is that because it's being used for, although it's being used as an authentication mechanism for WPA, that WPA is not actually kick in until this entire process is complete. So essentially, this is all happening over open Wi-Fi. So without that secure tunnel that's established, this authentication process can be sniffed. And in fact, legacy implementations of EAP were susceptible to this, specifically EAP MD5. So when I said there were two components to EAP authentication, I actually thought that was entirely accurate. There's a third component involved as well. That's the authenticator. The authenticator, at least when you're dealing with wireless, is the access point. And the job of the access point, in this case, is to act as an intermediary between the wireless client and the authentication server. Typically, there's like a wired connection between the access point and the authentication server, and then all the communication there is happening over layer seven, radius. And then on layer two, we have the supplicant and the AP, and that's communicating over wireless. So at this point, in order for this communication to, in order for this to work, two things have to happen for this to be secure. The client has to be able to trust the authentication server, and the client also has to be able to trust the access point. And as we mentioned, this is all happening over an open Wi-Fi, and as we also mentioned earlier, open Wi-Fi networks are susceptible to evil twin attacks. So likewise, this whole process can actually be emittled using the evil twin attack. What you do is you create a rogue access point, and you force the client to connect to you, and at that point, you run your own radius server in the background. And so long as the client accepts your FORGE certificate, your X509 certificate, and by doing that, it's saying that it trusts you. At that point, it will establish a secure tunnel with you, and then it will perform the authentication process with you, and that allows you to crack the AP challenge or response offline, giving you credentials. So this attack, first talked about by Brad and Tony Woods in 2008, as well as Josh Wright in their Shmucon presentation, and it's been around for a while. So for the new stuff, we're going to do live demos, but just for the sake of time, and also not pissing off the demo gods. If it's just like review stuff, videos, because it also exists Sunday, whatever. So in the first stage of this attack, what's going to happen, what you're seeing here is the attacker is actually creating a FORGE certificate, a self-signed certificate, and that's what's going to be sent to the client. Fast forward a bit, and you know that the attacker is starting the AP. As you see here, the AP is enabled, and what's going to happen shortly is that you're going to get a client associating, see that the client is now associating with the access point, and shortly thereafter, you should see right there, we have the username, challenge, and response. So at this point, you have the user name, challenge, and response, and you can, at this point, you crack it to obtain either the plain text credentials or the NT hash, which is equivalent to the plain text credentials in terms of what you can use it for. So there are two ways of doing this. The oldest way of doing it is with a dictionary attack, and the success rate of this is inversely proportional to the strength of the password. Say for a really strong password, it's actually like a pretty bad attack. In Marlon's Blake and David Holton, you know, they actually did a talk where they did, at Defcon, where they did a divide and conquer attack. So MS Chaffee 2, which is the inner authentication protocol used by EAPP, actually uses the same 56 DES encryption as NTL MV1. So the security of this protocol is actually reducible to the strength of a single DES encryption. So instead of, you know, with a dictionary attack, we're trying to recover plain text password. For this, you attempt to recover an NT hash, and actually with a powerful FPGA based cracking rig, such as Crack.sh, which you can go look that up, it's pretty cool, which is previously Cloud Cracker, you can actually achieve a 100% success rate in less than 24 hours for recovering that NT hash. So as you can see, it's pretty vulnerable. So the solution that was introduced to kind of mitigate this issue was EAPTLS. And this was introduced in 2008, probably in response to the attacks that came out around the same time period. And the cool thing about this is that it uses mutual authentication using X5 and 9 certificates right off the bat. So the strength lies in using these client side certificates because with those, you can't really do the evil twin attacks that we showed you in the beginning. Unfortunately, how many network admins are out there right now? Sort of hands. Alright, so how many people out there think that putting a client on every device on your network is like a good time? Yeah, yeah, yeah. So I mean, this is why it never really took off, because it's like, oh yeah, just put a sur on everything, and it's actually not that simple. And it's even more difficult if you have existing network infrastructure to integrate this stuff into, or if you're in a special scenario like you're dealing with industrial control systems, or medical equipment, or something like that, that might not even support client-based certificates. So, you know, you run into this classic security versus convenience scenario. And this kind of network administrators are forced to choose between two really kind of like poor choices. You know, authentication mechanisms with no weaknesses. Or you can use APTLS, which is highly secure, but it's also very impractical. So what this does is it actually creates a market gap. And you know, there are all kinds of products that have tried to address this over the years, and try to compensate for the security issues found in EAPP and EAPTLS, but are also kind of easy to use. So the current trend that we tend to see over and over and over again is a focus on breach containment rather than breach prevention. So the idea is you acknowledge that, the wireless perimeter is weak, but you try to stop the threat once it gets in that inner layer, the first layer of defense. So what we're going to talk about today is whether or not this actually works. So I guess the most common way of approaching this containment problem is using a network access control mechanism to attempt to stop threats as they occur. So before that, I'm going to present you with this awesome little cartoon. Yeah. Okay. So yeah, the most common way that this is usually implemented is to use a knack to, you know, once the attacker gets on the network, you identify them as an untrusted endpoint and you quarantine them. Either you know, completely block the port or you place them in a quarantine VLAN. You know, and there are two varieties of knack out there. There's an agent-based knack and an agent-less knack. And agent-based knacks, you know, what that involves is it's a software component on every authorized endpoint on the network. And this software component is called an agent. And this agent communicates with the brain of the knack and that's how the brain of the knack distinguishes, that will tell that a particular endpoint is allowed to be there. And this is highly effective, but once again, you have something you have to put on every authorized endpoint, so it's nearly as impractical as EAPTLS. So then on the other side of the spectrum, you have agent-less knacks. And agent-less knacks, they're purely external. They use passive fingerprint printing, active scanning, and they're much easier to deploy than agent-based knacks. But unfortunately, they're also unable to examine the internals of the network components, so you can bypass them simply by masquerading as a valid host on the network. So once again, you know, even by using a knack, we run into the same recurring dilemma, which is, you know, insecurity versus impracticality. So this creates yet another market cap, you know, where you have high demand for a solution that offers the deep interrogation capabilities of an agent-based knack, but without the additional overhead. So, you know, there's a third category. There are all kinds of really interesting solutions that have once again tried to bridge this gap. And we usually refer to those next generation knacks. You have kind of like AI-based solutions that kind of, you know, establish a base on the network and try to figure out, look for anomalies. You have, we're going to talk about one in particular, just because it's a pretty good example of an interesting attempt at doing this. I tried to borrow this particular network appliance from my T department. I opened up a help desk ticket. It's a $10,000 piece of equipment, though, and yeah, I could have seen that coming, right? But interesting, though, if I also got like a warning from legal not to name-drop these people, so we're going to refer to this as vendor A. But, you know, this one really interesting piece of equipment, it uses WMI to interrogate new devices. And, you know, this is really cool because it's capable of performing internal checks without using an agent. With that said, I mean, the way it does this is it authenticates over SNB using a single administrative service account. This service account, you know, it's given remote login privileges to all authorized devices at the group policy level. And this allows it to perform deep interrogations without using an agent. Pretty cool, except it also provides a single point of failure where you have this device that's sending God mode hashes to every new device that's added to the network. So, you know, what happens here is we end up in a situation where the first potential threat here is to introduce the risk of SNB relay attacks. In case you're unfamiliar, NTLM is a simple authentication protocol. The way that it works is that, you know, the client first attempts to authenticate with the server. The server issues a plain text string of characters as a challenge to the client. The client that has to encrypt that string of characters using this password hash and then send the encrypted hash back to the server as a response. The server then decrypts it and compares it with the original string that it's sent. And if they're the same, the authentication attempt succeeds. So, with an SNB relay attack, you literally just put yourself in the middle of that process using a man in the middle attack. The victim sends you the authentication request. You forward that to the target. The target then sends you the plain text string, the challenge. You forward that to the victim. And you keep forwarding stuff back and forth until what ends up happening is you end up authenticated with the target instead of the victim. So, you know, once again, we have the system, but, you know, we've introduced the risk of SNB relay attacks because, you know, it's sending you NTLM hashes and trying to authenticate with you over NTLM. But at the same time, you could mitigate this potentially by using SNB signing, which interestingly enough, it's actually disabled by default on everything but the main controller in Windows. So, and the reason for this is the main controller downloads group policy over SNB. But even if you enable SNB signing, which is what you do with SNB signing is you digitally sign packets to confirm their authenticity, even if you enable SNB signing, you still have the issue of hashes being sent directly to untrusted endpoints. So, interestingly enough, there is like a piece of software that you can put on every single network endpoint that's provided by this vendor, but essentially then you're back to using the agent again, so you're kind of back to square one. So, I mean, I guess the point I'm trying to make is that, you know, no matter how it's thought into this, there's really no magic bullet here. I mean, you have this security with convenience statement, but the problem with security with convenience is another technology that's often used as a wireless security mechanism that's worth looking at is client isolation. So, the way that what client isolation is supposed to do is it's supposed to prevent wireless clients from talking to one another on the network. And, you know, a typical use case is an open network. If you go on your hotel Wi-Fi, you may notice you cannot ping one another. That's because they probably have client isolation enabled. And, you know, the way that, you know, 2.11 is supposed to work in theory is that the AP mediates all communication between the clients. So, if this guy here wants to send a package to this guy over here, the client can just stop it and say, no, you can't do that. The problem is that client isolation, at least on a wireless network, is a logical control. It's not a physical control. So, you know, the problem is how do you prevent radio transceivers from communicating with one another? So, a really awesome researcher who unfortunately is no longer with us, named Cedric Lancer, back in 2005, his response to this was, you can. And he released a tool called Wi-FiTab. And this was later revived in 2013 by Oliver Lavery of Gotham Digital Science way before my time. But the way Wi-FiTab is it reads packets from the victim to the AP using a Wi-Fi interface in monitoring mode. And then, you know, every time it receives one of those packets, it's going out to the distribution system, it injects a response as if it's coming from the AP. So, this allows it to actually communicate with the various devices on the network without actually being associated with the network at all. And it provides a neat little tap device that you can use to bridge over to the monitor mode interface to do this. So, I mean, there are some later tools that let you do even more stuff. The Air Crack Suite has Air Ton and G, which you can do this with Web. And there's also T-Kick Ton and G, which you can do this with WPA1. There's also this theoretical attack that has been talked about called Whole 196 where I guess the idea is that you might be able to do this with WPA2. It's really, really, really debatable whether this actually works. I've never seen it pulled off before, but it's worth mentioning just to be thorough. So, here's an example of Wi-Fi tap doing its thing. In the top right, we're going to create an open access point. And then we're going to connect to this open access point from our host operating system. This terminal is associated into a VM, by the way. And then we're going to start sending ICMP packets to this AP. And what you're going to notice is we're going to have five ICMP packets sent, and there are going to be five responses. So, now what we're going to do is we're going to, in this terminal to the left, we're going to start up Wi-Fi ping. And Wi-Fi ping is a modified version of Wi-Fi tap that essentially all it does is every time it sees an ICMP packet and SNFs one, it injects a response to that ICMP packet in the form of an ICMP reply. So, we're going to run that as well and repeat what we did in the last process, sending five ICMP packets. And notice now that instead of receiving five ICMP replies, we receive ten of them. And we also get little warnings that we're receiving duplicates. So, what we've just done is we've sent packets to a network endpoint without actually being associated with that network. So, you know, food for thought, you know, going back to the whole issue of NAC, right? You know, what if we're missing the point? You know, what we've been talking to you up until this point is whether or not NACs are able of stopping a direct attack. But, you know, when we're talking about wireless, NAC is the only problem. You know, the role NAC is to prevent attackers from accessing sensitive resources after the breach has occurred. You know, and they do this by when an authorized endpoint is detected. They take one of two actions, either the endpoint is placed in quarantine or the port is blocked. But, you know, violating access control policies, what this does is it causes the NAC to impose a restriction. And in a wired network, this is a physical restriction, but in a wireless network, this can only be a logical restriction. More on this later. So, I want you to think of a scenario that's pretty common in, you know, if you're doing pen testing or anything that's dealing with this kind of infrastructure testing. So, you know, we've already breached the perimeter using the attack that we described in the first section of this talk. And this is us, we're over on the left. We've been quarantined and we want to get over here. We want to pivot further into the network where we can actually do some damage. Unfortunately, we've been quarantined by this NAC here. But, fortunately for us, there's this victim over here that we could potentially do something with and also as a wireless client. So, more on that later. But the question is how do we get out of this situation? So, I mean to understand this, we need to look at something called LMNR and MBTNES poisoning. And LMNR and MBTNES poisoning, it basically takes advantage of a flaw that exists within NET BIOS name resolution. So, the way NET BIOS name resolution works is that the first thing that will happen is that a Windows host, when it's trying to resolve a NET BIOS name, it will check internally its local cache and also its LM host file. If that fails, it will then attempt to attempt DNS resolution using local name servers. And at that point, if that fails as well, it will fall back to LMNR and MBTNES and send broadcast requests to the entire subnet. So, LMNR and MBTNES, they're actually different mechanisms, but they serve the same logical functionality. And this is best understood through example. Let's say we have two computers named Alice and Leroy. Alice wants to request a file from Leroy, but doesn't know Leroy's IP. All that Alice knows is Leroy's NET BIOS name. So, Alice will attempt to resolve Leroy's name locally and also using local DNS, but let's say this attempt fails. Alice will then make a broadcast request using LMNR and MBTNES. At this point, every single computer on Alice's subnet will receive this request. And the idea here is that only Leroy should respond to this, but this is based on honor system. Does anyone see a problem with this yet? Yeah, yeah. So, I mean, it's a lot like art where, you know, there's no honor among fees. Alice receives two of these responses, only the first one is going to be considered valid, and this is going to create a race condition. The attacker can simply wait for LMNR and MBTNES queries and respond to all of them. And this will cause the victims of this attack to send their traffic to the attacker. So, there's the most, I guess like the most popular tool for doing this and really the pioneer in doing this was a responder by Lawrence Jaffee, or Lawrence Jaffee, should I say. And we're going to start this up on the left. We're going to run this. And you can see here that we're poisoning LMNR and MBTNES, and we also have auth servers that are waiting for us when this thing tries to connect to us and authenticate. So, a writing responder, and then we're going to do over here on the right, we have a victim computer named Jenkins. We attacked Leroy earlier. Jenkins is going to try to connect to a non-existent file server. And the reason why we're using a host name that isn't valid is because it will force Jenkins to fall back to LMNR and MBTNES, because it obviously won't be resolvable using the first three methods. And then when this happens, the responder tool that we're running on the left is going to poison those, send poison answers to Jenkins, and oh, we have the user's hash right there. So, we're about 5%, you know, finished with our escape attempt. I'm just going to check the time really fast. Okay, we're doing great. Awesome. So, the next thing we need to go over in order to understand how we can get out of this is something called redirect SMB. Now, the idea behind redirect SMB is that you force the victim to visit an HTTP endpoint that redirects to an SMB share on the attacker's machine. So, you send them a URL, they click the URL, and this takes them to a specially configured HTTP server. And the only thing this HTTP server does is one thing and one thing only, and it redirects all HTTP requests to a rogue SMB server that's sitting there waiting to accept NTLM authentication. And what this does is it causes the victim's browser to attempt NTLM authentication with the attacker. There's a variation of this, you know, where you simply redirect to a non-existing SMB share, and this triggers LMNR and MBTNES. But it's a really fast way to get hashes. It does require social engineering, though, or some way of getting them to access that server. So, now this is where we get into new stuff. It looks like we have lots of time to go over it, too, so demo guys will probably be someone happy about this. So, now we're going to talk about hostile portal attacks. So, the hostile portal attack is a way of stealing active directory credentials from a wireless network without direct network access. And the way that you do this is you essentially make a modified captive portal. So, a captive portal, how many of you have seen something like this recently? Yeah. So, if you're sitting in a hotel, you run into this, it's a captive portal. And the idea here is that you restrict Wi-Fi access by forcing users to visit this page first. And, you know, at that point you can do anything you want. It's most commonly used to either prompt them to authenticate or provide credit card information or something like that. So, the way this works is that all DNS queries are resolved to the captive portal. And this is usually specified using that HTTP option. But also, you know, in case that they are manually setting their, the victim is manually setting their DNS server, you can also redirect DNS traffic to your own DNS server so that they're forced to use yours. And then if you really want to be nasty, you just redirect HTTP traffic to your captive portal as well so that even if they're not using DNS at all, you still have them trapped. So, what a hostile portal attack is that you kind of modify this so that it performs a redirect S and B attack. The victim is forced to connect to the attack or using a rogue AP attack, kind of like that, right? And the next thing that happens is that you, instead of redirecting everything to a captive portal, you perform a redirect S and B. And what happens is that the victim is then forced to, if they're using HTTP traffic at all, they'll be forced to authenticate with the attacker and that gives you NCLM credits. So, and on the background also to make this more effective, we can run Responder to Poison Element R and request so that even if they're just kind of idle, we can still get them that way. So, now we're going to do a live demo. So, I'm going to have to switch screens here. All right, so in the bottom left here, we're going to create, we're going to do this on the open access point first because there's another couple steps that we have to do to get this to work with a not so open access point, a WPA2 EAP access point. Oh, it's on the screen. Uh-oh. All right, do you see one thing now? All right, I'm just going to, still not on the screen. Oh, whatever. Okay, I'm going to just use the video then because it looks like, well, I have 35 minutes. Here, check this out. Command F1. Do I have a command? No, this is max. I'm not sure. All right, can you, can you see stuff now? All right, cool. Nothing like system preferences to the rescue. Thanks, Steve Jobs. So, if your Mac breaks, you just pray to Steve Jobs and then everything works again. So, now my stuff's on two different desktops because I tried to fix it that way. All right, back to the first desktop. And I'm going to put a two-minute curfew on this demo or a one-minute curfew on this demo, should I say? Yeah, give it to you. And if I encounter two minutes with the problems, just so we can squeeze everything in, I'm going to just move on. But hopefully, the way things are going, you know, knock on wood, this shouldn't, this should work. All right, so the first thing I'm going to do is I'm going to create a, oh, these are backwards. I move this here. Okay, so we've created the open access point. This is not looking at an open access point. All right, so we tried to create an open access point. Now, we're killing the peep. Okay. All right, here we go. So we're going to create an open access point using E-Pammer. I'm actually going to use the same attack tool that we used for attacking this thing to create our valid access point because why not? And then we're going to have Leroy up here in the top left. Can you guys see this? Okay, good stuff. And okay, it looks like we're already connected. Excellent. We're now going to create our rogue access point over here. And then we're going to launch this attack. And then we're going to get ready to de-authenticate Leroy to get it to roam from one BSSID to another, which will make this attack affected with all these network interfaces really close together. So we're doing this. And okay, so we've gotten it to associate. And notice that when we open up IE, okay, now we have hashes. Now I have to get everything to stop. Okay. There we go. Cool stuff. So that's a hostile portal attack against an open network. It's somewhat impressive. We're going to get more impressive ratings against WPA2 in a second once I clear this previous hash that we just captured so we can do it twice. Okay. I feel like we've been here before for some reason. Okay. Magic. Okay, so now let's talk about how to do this with WPA EAP networks. So in most cases WPA EAP means EAPTTLS or EPP. Both of these use MSChap E2 as the inter-authentication protocol. Interesting thing about MSChap E2. It uses mutual authentication which means that at the very end of the authentication process, the radio servers must actually do prove a knowledge of the user's password to the client for the entire authentication process to succeed. So what this means is that although the attacker can force the victim to authenticate with an evil twin to steal the hashes, the radio server will still fail the final stage of the authentication process and the client will not associate with the attacker. So the way that you get around this, because in order to do the hostile portal attack, you do need to get it to completely associate with you, there are a couple options. So for weak radius passwords, you can use a technique that Don White and the developers came out with in DEF CON 22 called auto-crack and add and we'll talk about that in a second. And the second solution that we can use is simply to crack them offline and finish the attack later. So the way that at the very end of the MSChap E2 authentication process, the victim here is going to send the challenge responses which is part of what we're cracking offline to obtain the credentials to the radio server, which in this case, with the tools that we're using for the attack is hostAPD. At that point, hostAPD is going to load the password from this file called the EAP user file, which is just like a special text file that's used as a database that contains that information. So at that point, the attacker or the radio server in this case is going to attempt to construct an authentication response that proves knowledge of the user's password and then that will be sent with the all success message back to the victim. So when you use an auto-crack and add technique, what you're doing is instead of immediately loading that password from the EAP user file, you instead take the challenge response and send it to a cracking rig. And this can be like a remote cracking rig that's very powerful, doesn't have to be something that's on your laptop. And then you send that off and then the idea is that hopefully you'll get the results of that back in time where you can actually just append it to the end of that user file in real time and then use that to construct the authentication response. This may not work the first time, but it may be in like a few seconds or even a few minutes when the victim tries to re-associate that this will work and the full association will happen. And the second option of course for all his other passwords is simply to crack offline and finish it later. Without even going into the discussion that advanced persistence threats like this guy on the right are really limited by time boxing, remember that we talked about how the divide and conquer technique with sufficiently powerful hardware can crack FV2 within 24 hours with a 100% success rate. So you can just go with that and just do the cracking and then come back the next day and do it. So for demo purposes I'm obviously not going to connect to the Defcon Wi-Fi and send stuff over there so we're going to go with the first option. Alright so here we are, this is a very similar, can you guys see the okay yeah I can see that, so that's working. So we're going to first create a peep access point this time using PA2PAP. And this wireless client here Leroy is going to attempt to connect to it. And it did, okay so we have the connection, now we're going to start our rogue. And actually before I do that I'm going to go in here and actually because I did this earlier to practice and the credentials are already there so I'm going to get rid of them. Okay and we're going to do a local auto crack so we're just going to do this internally. And finally to get this thing to roam D-Auth as before hopefully this works. Alright so what are we running here? No? Okay. Maybe I'm D-Authing the wrong thing if that would be bad. No I'm still connected to that so okay. Authenticated. I'm actually just going to copy, I'm going to copy and paste this MAC address from here and see if I can try it again. Try number two. Oh you know what this is? I'm clicking this thing right here over and over again. It's not bringing up the network manager. That's because I'm using a virtual machine and the virtual interface has cooked itself and it's not doing anything. But luckily I came prepared because I seem to be on the demo god's bad side recently so we'll just go with that route. Okay so back to where we were. In the top right we have the legitimate access point and we're going to create a Wi-Fi network called example Wi-Fi. It's going to be a peep network. In the bottom right we're going to have Jenkins this time and Jenkins is going to attempt to authenticate with this and this is the valid access point so we're just going to go ahead and connect them. And then the left hand on the side of the screen here this is where we're going to launch the rogue access point attack. So we're going to create that, we've created the rogue AP and started it and then in this tab right here we're going to perform the de-auth attack to get it to run over to us. Sometimes what happens with... Yeah so sometimes what happens here is that when certain clients they'll actually just pop off the network completely but then when they try to re-associate they'll end up on the rogue AP. So a little user inconvenience there but we don't really care about them anyways. So we see here that we've captured the credentials. They've been written to the end of the... They've now been written to the end of the AP user file. So we're going to just cap the contents of that file really fast. Here we go. You can see the end they've been added. So now we're going to repeat the attack. And notice that when we do that we go ahead and accept that that cert warning that's popping up. So now we do that. Interesting thing sometimes for some reasons when you connect to a network IE just manages to open itself by itself and of course when that happens you're going to send HTTP traffic to check this out. This is going to be pretty cool. Every time you type in a character in the IE address bar it tries to do a Bing search. So we're doing this and it's making HTTP requests so every time you type in a character we're just getting that hash over and over and over again. In fact it looks like the EPAM over here is trying to complain that we're doing it so often. And then also IE is like what's going on? We can't request anything. So yeah, that's a hostile portal attack. It can still be up to AP. And what this gets you is lots and lots of NTLM hashes. You get similar results to L and R and MBT but there are a few key advantages here. No direct network access is required and you're not limited to a local subnet. You get everything that's connected to wireless. And it's also not a passive attack. You're not waiting for L and R to show up on your local subnet. You're actually forcing things to happen. So back to our scenario. Here we are. We're going to do a new technique that builds off of the hostile portal attack and it's the technique for using ROGAP attacks to bypass port-based access control mechanisms. So here we are with the attacker. We're back on this quarantine VLAN and we're actually going to do our escape attempt now. We've been quarantined here by the NAC and over here we have the victim that's been placed on this restricted VLAN and obviously we want to get over here and access these sensitive resources. So what if we first, let's say that we have one network adapter that's being used to access this VLAN. What if we first take a second network adapter and then force this victim to connect to that second network adapter using an evil twin attack? Well, at that point, we take them off the restricted, the network that we're attacking and we force them to associate with us. We then attack them using a hostile portal attack to obtain their NTLM hashes. Crack the hashes offline, come back later, pick up where we left off. We might have to repeat the first step to make this work but at that point we can place a time payload on the victim, right? Like a scheduled task or something. At that point we kill our ROGAP that's operating on our second network interface. We allow the victim to re-associate with the target network. We place the victim back to the restricted VLAN because it's not authorized at that point. At that point we just wait for the reverse shell and this could be the best knack in the world and it would not even matter. So that was cool but it requires some offline cracking of NTLM. We obviously don't want to do that. Well, I mean, it'll work but it would be cooler if we could speed that process up a bit. So to do this we can use the NSMB relay attack. We talked about this earlier. So with the NSMB relay attack what we're going to do is we're going to use the ROGAP attack as before to force the victims to associate with our hostile portal and then when that happens we then initiate the hostile portal attack but instead of just capturing those NTLM hashes we instead perform an NSMB relay attack to obtain a shell on one of these victims and we use that shell to place a time payload on that victim. So that happens much more sustainably so you don't have to crack those NTLM hashes offline. At this point we kill our ROGAP as before. This allows the victims to re-associate with the target network, wait for the reverse shell and we bypass the knack. And as I said my USB interface is dead so I have a backup. So here, show of hands. How many people have used Empire before? All right, cool. For those of you who haven't, check it out. It's really easy to use and it's really, really fun. It actually has a module called Trollsploit which you can use to just send your victims or send little prompts to say stuff like you've been disconnected from the domain controller, all kinds of funny stuff. So we're going to connect these two these two VMs, these two victim VMs we're going to use two of them this time to our our legitimate access point over here in the bottom left and on the right here we're setting up Empire to perform this attack we're going to create two listeners that's what our victims are going to connect back to we've also created a payload of Base64 as a PowerShell command that's going to give us a reverse shell and we're going to tell our SMB Relay script and we're using SMB Relay X although you can use anything for this really to execute that on the target machine we've then launched the Rogue API attack and as before once the Rogue API is running we use AirReplay to force these devices to associate with us by the authenticating them to roam over to us and you can see that happening here alright so we have one associated we're going to have to force the other one to associate as well so we're going to repeat that and it's waiting for beacon frames so I'm going to fast forward through that so we've we've de-off the second victim the second victim is now going to roam over to us and you can see that there's some that IE weirdness happening in the background when you first connect but now we're going to take that payload and we're also going to grab the IP address of one of these victims and then feed it to our SMB Relay script so we're just going to copy and paste that over to our SMB Relay script which we've done here and then we're going to start it and at this point we're going to generate some HTTP traffic on one of these machines just to make sure the SMB Relay attack happens so we're doing that here and notice there that you see a lot of activity from the SMB Relay terminal and that's why that's because the attack is actually executing and now we just wait for the reverse shell there's a 45 second delay on the payload so I'm going to skip a little bit but I want to see you guys I want you guys to see payload connecting there it is, that green text, that's our initial payload so now what the scenario that we have is that we have two two devices that are associated with our rogue access point attack and we've used an SMB Relay to gain a shell on one so now that we've pivoted into one of them we're going to use a persistent smodule from Empire for illustrator purposes, schedule tasks works really nicely for this so in a real scenario you'd want to use something that is purely in memory but I like schedule tasks because it's like easy to explain for doing like a talk so and you can see now we've executed the command hostname and the command whomi we have NT authority privileges on Jenkins up here in the top left so we're going to execute the schedule task and we're going to set the timer for two minutes in the future and something really interesting happened when I was recording this I actually forgot to connect the the virtual interface that was attached to my USB Wi-Fi adapter for the the NIC that was connected to the target network so I was going to start clearing this and start the recording over and over again but something really interesting happened I actually had set 160 retries on that reverse shell for some reason I don't know why I did that so the second I reattached it the reverse shell just suddenly appeared and suddenly worked so I thought that was kind of cool so I left it in there and it kind of proves an interesting point about good implants is that they'll kind of doggily try to get back to the attack or even if they can't immediately do so but yeah, we're going to fast forward a little bit and you see here that we've executed the schedule task and I'm sure you don't want to sit here you can see me wiggling my mouse because I was really bored waiting for this task to execute you guys as well so I'm going to try to loop through that as much as I can alright at some point this is when I realized that oh yeah I didn't connect this thing so I fixed the problem by attaching the network adapter it's a very, very dirt moment there and then I start getting ready to start this recording all over again so I start clearing the terminals and then I go back to Empire here and I start to go back to the main menu and oh wait there's the reverse shell alright so now we've received the second reverse shell this time on the target network and we now can use this we're going to interact with that agent that's now living on the target machine and we've just pivoted into from one VLAN to the other so that's an indirect wireless pivot and the equivalent technique, I mean it's actually really straightforward, it's not very complicated the equivalent technique in a wired network would be to unplug an authorized device from the wall and just connect it to a hostile network on which you can actually attack it and the reason you can do this is because port-based access controls, they rely on the assumption that the physical layer can be trusted in a wireless network, WPA is the means through which the integrity of the physical layer is protected so if you're using a weak form of WPA to EAP the attacker can actually freely control the physical layer using road access point attacks and this renders port-based knack mechanisms useless so what this demonstrates is that port-based knack mechanisms do not effectively mitigate the risk presented by weak EAP implementations furthermore, it demonstrates that adding port-based knack mechanisms to a wireless network does not make the use of EAP TTLS or EAPP any listen inappropriate if the networking question is used to grant access to sensitive information and finally yeah, oh well, finally okay, I guess there's another I thought there's another slide there, whatever okay, so by the way when we're talking about sensitive information it's Sunday, when we talk about sensitive information, we're usually referring to PCI or HIPAA data, but you know it's important to remember that compliance doesn't necessarily mean security so I'm going to make one last case for EAPTLS it still is pretty painful but it's not as bad as it used to be, you can use group policy to configure 802.1x clients I think that's pretty cool, I think your best option is to use a private CA you can leverage Active Directory to deploy EAPTLS and if you have a BYOD process that you have to worry about for that you can just use a solid NDM solution or even just really streamline your BYOD onboarding solution to make that work you can even use less encrypt to deploy EAPTLS, although to be honest, even the folks at less encrypt say this is far from the best solution out there as I'm like, you can technically do this but so it's just some closing thoughts just because wireless and wired networks, they operate similarly at a logical level and that's by design you don't want to have to fundamentally think about your networks differently depending on what physical medium you're working with that does not mean they work the same way at the physical level and you have to remember that when we're designing security mechanisms that are designed to protect these things and also as a community we should really question whether or not it's a sound business decision to neglect EAPTLS in favor of a more reactive approach that focus on access control or threat containment and finally, if there's one thing to take away from this and other convenience and security are often at odds with one another, be honest with yourselves maintain a healthy skepticism toward proposed solutions that promise both and if you want to check out the attacks and try to implement them yourself, the tool in question is github.com slash solstice slash ephamer and that's it, thank you