 Hey, guys. As you already said, I'm Zach Faisal. I may talk a little fast, so if I get way too fast, slow me down. So I'm a pen tester by day, DJ and photographer by night. You can find me on Twitter at ZFaisal. People always ask me what are your credentials, and well, there they are. I think it's bullshit when people list a shit ton of certs, but that's just me. So, yeah, I mean, judge me based on the quality of this talk, not based on a list of certs. So, quick shameless plugs. We have a little competition going on right now. There's another talk in track 4 going on from people from Chicago too, and we're all from Chicago, so I need a quick show of hands. How many people here are from Chicago? I think I lost the bet. Damn it. Also, poolside tonight, I'll be DJing in a battle against Keith Myers, so if you're around here tonight, come on by. ThoughtCon's a conference I run in Chicago, another hacking conference. We had about 500 people last year. We're looking to grow a little bit this year. More info at thoughtcon.org, and my local homeboys are the 312 crew. So, TLDR, what does this talk about? So you don't spend the next hour here listening to me ramble. We're going to be talking about NTLM relaying. Not past the hash, but NTLM relaying. I'll touch on the difference in a second. And really in the end, a new tool set to do cross protocol relaying of NTLM authentication requests, as well as new methods to go ahead and get clients to automatically authenticate to us, and new targets we can relay these hashes to when we do the cross protocol relaying. So let's talk about NTLM. We're going to do a quick refresher for those of you who don't know what NTLM is, hopefully in less than 10 minutes, any longer, well, it'll be a talk about NTLM 101. So, what the hell is LM and NTLM? It's Windows password storage and network authentication protocol used in Windows, obviously. So, like I said, it was used for password storage and for authentication. So, goddamn, my slides are out of order. For past the hash, basically, oh, God, I need to jump around. So, hopefully you've seen this. These are the hashes for LM and NTLM. The LM is split into two 7-character chunks, all capitalized. So, we all know LM's bad, LM's weak. I'm not going to spend hours talking about why LM is bad. You all know it by now, hopefully. If not, Google. And then NTLM hash, obviously, is case sensitive, unlimited length. It's not 7-character chunks. It's a little stronger, but still has its problems. So, there's a few problems against it already. With LM and NTLM network hashes, there's a weakness we know as past the hash. This talk isn't about past the hash. Oh, wait, this is really out. Sorry, I'm sorry, guys. I just did these like five minutes ago. So, LM sucks. We've been over this. So, what the hell is NTLM auth? Not just the password hashes, but the authentication going across the network. It's used for remote authentication requests against varying services. And we'll touch on those services in a minute. And it comes in a bunch of different flavors. And we can all get confused when we start talking about NTLM versus NTLM auth, V1, V2, NTLM2. It gets really confusing whether there's signing or no signing. So, we'll kind of go over that real quick. So, when we do NTLM authentication, there's three messages that are sent. The type one, type two, and type three. Type one message is the client goes to the service as I'd like to authenticate, and here's what I support. So, as you can see, this is just a wire shark capture, chunked out a little bit. And it puts in there what the supported flags are as to how we can communicate for authentication, as well as the work station's name and the domain it belongs to. The server then responds with a type two message. Now, if you notice in the type one message, we don't know who this user is yet. They just ask to connect and want to know what's supported. So, in the server response, it uses the NTLM challenge versus the server response challenge. This changes every time. And here in the screenshot, you'll see the static challenge that's used mostly for rainbow tables. So, server response with the type two message saying, all right, here's what I support. Here's my domain name. Here's my host name. And here's a challenge. Use this challenge to salt your password hash with so it's unique every time and you can't replay it back over and over and over in the same request. So then the client authenticates with the type three message. The type three message is basically the server challenge hashed with the password hash for the NTLM hash along with the username, work station name and domain it belongs to. Session key if it's using session signing. And other flags to state what the session is going to be supported for the authentication. So, that's NTLM version one. NTLM version two is pretty much the same except it adds additional parameters into the password response as well as a client challenge. So, as a prevention against rainbow tables, the client uses randomness to break the rainbow tables. So, we went over that. So, this is all great and dandy but we've got one more thing we need to talk about which is Windows integrated authentication. So, Windows integrated authentication is what's used in Windows in order to make sure that you don't have to keep logging in over and over with your password to connect to various services. So, if you think of every time you're on a domain, you connect to a network share or an internal web server, it doesn't ask you for your password over and over. It just queries the API and gets the information back from it as to what I should use to authenticate. So, for HTTP, it obviously protects against that using trusted security zones. Has to be within the trusted sites or an internal site which is checked by only having a one word name, not a full domain name. Now, the interesting thing about this though with the one world domain name and again this has all been covered before I'm just doing a quick refresher is that the one word domain name does a search. It first looks for the DNS name from the DNS server, then tries it with the host or the DNS host name and works its way back. So, if your domain is domain dot domain or domain server dot domain dot net. It checks, you know, word dot domain server dot domain dot net, word dot domain dot net net and then does an NBNS which is a broadcast request for that domain name look up. And basically as the network, hey, I'm looking for htb colon slash slash name. Do you know who name is? And broadcast across the local network, it's known as NBNS. As well as SMB everywhere as I was saying, there's no restrictions where it automatically authenticates with SMB. It just automatically authenticates. And so we can see there's some problems with this if we're able to take a real in this. So there's some known issues like I said already about this, the hash stuff. Passive hash uses the edtlm hash. As we look at the protocols for ntlm, the ntlm hash is not the original password. So all we need is the ntlm hash. Now we can access the ntlm hash using various tools and windows to gain access to the local system, password store as well as memory and access these password hashes from there. This is all covered in various other talks but just a quick refresher to kind of show the differences. But the thing with this is it requires local admin access typically on the system. With this, when it gets to local admin, you need to have existing access obviously, you're not starting as a guest in order to access the local memory store or the local password store. So what is ntlm relaying? How is it different from pass the hash? Everyone was asking me this over and over and over. Oh, you're talking about pass the hash? No. We're talking about ntlm relaying. So ntlm relaying requires no existing access on the network or on the system. Basically you get network connectivity either internally or externally and you start as a guest. No credentials, no access to no systems. And it basically relays those authentication requests. Now if we step back to where we talked about the type one, type two, type three message, there's no kind of verification that the host calling or the destination host is the one you meant to talk to. And the host just kind of authenticates to it. So what we do then is we set up a rogue server to take these authentication requests in and relay them to another target server. So this has been around for a while, the ntlm relaying. It's nothing new. All of you are probably like, okay, we've heard about this, it's great. Why are you different? So let's tell a little story. So back in 96 was when it first kind of came out in this paper called Weakness and SIFS Authentication by Dominique. That's kind of where they first talked about ntlm relaying as a possibility. In 2001 it really got traction with Dill Dog. Actually it was in 2000 with Dill Dog's ntlm replay and Certistics SMB relay, in which it did relaying back to ntlm or telnet relaying the authentication back. And you use the weakness in IE where you could say telnet colon slash slash the IP and automatically authenticate. And then SMB relay took advantage of bouncing SMB request to other hosts as well as back to itself. It finally took until 2008 that Windows patched the weakness where you could bounce a ntlm authentication request back to itself. And that was in MS08068. And so we couldn't bounce ntlm request, network request back to itself, but we could bounce them to other hosts still because of the way the protocol is designed. So in 2008 a guy who goes by the handle of Kurt did his talk at Defcon about ntlm is dead. And I thought that was one of the best talks that year because its impact on corporate environments is great. We could talk about mobile phones and how it affects everyone, but really the core data in corporate environments, it hurts. So he talked about writing this tool, does ntlm relaying over HTTP. And he talked about the potential of doing it with, you know, as an SMB server as well to get these authentication requests. And so this was actually screen-shotted two days ago. It's still an open case on his squirtle application. And I don't think he really has any intention of maintaining it. So I decided, you know, these weaknesses sound familiar over and over. We keep talking about there's problems over and over and over and over and they're not getting fixed. Every environment still has pretty much ntlm enabled in corporate environments. So what does it sound like to me? Well, it kind of sounded like the problem we complained over and over and over about websites not doing SSL encryption for their authentication requests as well as managing their cookies. So in 2010 fire sheep came out. Most of you probably familiar with this. It was a way of capturing cookies and using the sessions I was able to capture over wifi or sniffing of the network and impersonate these users. And I asked myself, why did this have so much traction? Why did this all of a sudden make everyone change? Well, because it was so easy to use. It was so easy for just anyone to start up the application and impersonate someone. So I kind of decided to start on this goal. Make an application that you could do ntlm relaying and show the impact of people that's as easy as fire sheep. We're getting there. So basically I started working on a lot of proof of concepts to see what extent does ntlm relaying support across multiple protocols. Like I said, a lot of people talked about it in theory, but no one actually implemented it. So the goal, like I said, is fire sheep for ntlm. So I decided to start learning Ruby because I was going to originally integrate into Metasploit and that didn't happen and it went still Ruby. So my talk got rejected when I first submitted both to Black and Defconn. But not just to get rejected, but I got a fake acceptance email. A friend thought it would be funny to troll me. What a douche. He had a friend who actually took and had his talk accepted and sent the actual content of the email and forged the, you know, headers to be from Nikita. And I thought for an hour and a half I was speaking at Defconn and then I got the email saying I was rejected. And that's the story. All right, thanks for coming, guys. But no, three weeks later Nikita gets back to me and says, hey, we have nobody on Sunday, somebody dropped out. Do you want to speak? Awesome. Wait, how, I have three weeks till Defconn? Shit. So keep that in mind as this tool is coming along, I kind of put it on the back burner and didn't work on it for quite a while between the submission and now. But we've got something working and we'll talk more about that. So what's the problem? Why do we need this another tool to do this? Why do we need another thing to do ntlm relaying? Well, the problem is other tools just didn't do what we need to do as a penetration tester. They really lacked the number of different protocols you could relay these authentication requests to. You know, a lot of them were SMB to SMB, HTTB to SMB and no one was really branching out of that HTTP and SMB world. No one was going to LDAP, MSSQL, or even testing remote desktop or other stuff or VPNs. And I really, I thought, you know what, the other big problem is that all of them send it to one place and we'll talk about why in a second. But they all forwarded every single request to one destination. That's noisy as all heck. We're getting users, we're getting machine accounts and we're just sending all the authentication to one target. And I realized the reason why is we didn't know who the users were before the Type 3 message. And if you remember the Type 1, Type 2, Type 3 message, the Type 2 message is what specifies the challenge. The challenge is unique to every session. Now I don't know who that user is until they send their Type 3, the last message. So I don't know what response from what server to relay on to them. Well, why aren't any other tools doing this? And so I looked more into the protocols of SMB and HTTP. And, well, we'll talk about that in a second. Oh, and it's not going away. Windows 8 and Windows 2012 still supports NTLM by default. And that's kind of scary that we know these protocol weaknesses are there, but NTLM is not going away. So we really need something to say, hey, as an organization you need to, under your own accord, start protecting yourself against these attacks. So I wanted to be a problem solver. So here's a tool. It's called Zac Attack. Now, I know the name is so freaking lame, but we went through a list of different names. My favorite is the last one. So what's in this tool? And I'm blowing through these slides fast, so hopefully I have enough to keep you guys entertained for a while. So really, in this tool, there's a few different components. And we'll talk about all these components separately and how they integrate. So, first of all, there's an HTTP and SMB server. Those are the servers that basically accept the authentication requests. So as clients get targeted to connect to this rogue server, they authenticate and they keep them authenticating. We have a set of rules for automated exploitation. We have clients for these automated exploits, as well as an API that we can tie into any other application we want to to do NTLM relaying. And finally, a generation of payloads to get these clients to automatically authenticate to us. So first off, these rogue servers. We want to get people and we want to get them authenticating to us and we'll talk about how we're going to get them in a second, but we've got to have them authenticate to something, right? So the first thing is we need to keep these users authenticating. A lot of the existing tools will disconnect after the first successful authentication. So what this tool, Zac Attack, finally does is it keeps them authenticating as much as possible. Now on Windows land for SMB, I think that's about 30 times before the connection terminates. So we need to figure out who this user is, too, when we're keeping them authenticating. So the first authentication request is with a static challenge. That 1-1-2-2-3-3, for those of you who pen tests, you know that's kind of the rainbow table challenge. And we need to figure out who this user is. Like I said, we don't know until type 3. So we send a static challenge. So with this, I like to call this the Alzheimer's feature. It basically forgets who the user is and asks them to re-authenticate every time they connect without closing the session. And the reason we do this is because, you know, an HTTP, WPAD, and other requests don't always support cookies, as well as identifying them over SMB using an IP and source doesn't work if you're doing it across the internet behind a net. So for the HTTP server, the way we coded this out was doing a 302 redirect with Keep Alive. Now Keep Alive will keep the session open so the socket's not closing. After we authenticate them, we know who they are and we know who they are for the rest of that session. For SMB, it was a little more rough. I had to write a custom SMB server. Now that's not any easy task and it's a little buggy still, but it works. So after they authenticate and it does a setup in X connection, for those of you who aren't familiar with it, I'm not going to go too in-depth into the SMB protocol. That would be a whole another two hours. But after it gets the authentication request, it kind of forgets who they are and says, oh, hey, great. Nice to meet you again. Cool. Oh, I want to connect. Wait, who are you again? And starts the authentication request over. So we need to get these authentication requests coming to that HTTP and SMB server, right? And a lot of people will have asked, you know, how do you do man the middle? What do you do? Well, there's a few different ways we can get people authenticating to our server to then bounce them to other stuff. So what payloads do we're going to have in this tool? Well, first off, there's obviously WPAD. Now WPAD, I didn't want to write a whole another NBNS spoofer for those of you who are familiar with it. But WPAD is the web proxy auto detect. In Windows, when you try to connect, you know, with that little check mark, automatically find my connection settings. It sends a request out looking for the name WPAD. Checks DNS, and then checks broadcasting to the network. Now you can spoof these requests and respond to them. By default in Windows, the machine will automatically authenticate to the WPAD server over HTTP with the currently logged in user's credentials. So that's great. You got to be internal to the network typically or, you know, spoof NBNS or spoof the DNS. Wasn't me. But what about social engineering people? Now for a while, pentesters have known about using Internet Explorer and putting in image tags for a UNC network path. And then Internet Explorer would pass that back to Windows and automatically connect to that network server and attempt to get that image or whatever it may be. It could be JavaScript, it could be an iframe, et cetera. Now in IE, it automatically authenticates. But for a while everyone's solution was Firefox and Chrome. And you'll see kind of the reoccurring theme here is people have had kind of half hazard solutions for this because we didn't fully understand all the remediations for it. So what about Firefox and Chrome? We could do, oh, well Firefox and Chrome are protected. And you'll see a screen shot here. This is actually Firefox's error console saying, sorry, can't load, you know, that network share, you know, it's not in my security contacts, it's in file security contacts. So that's been the case until now. So that's one of the cool new things about this tool is that for Firefox and Chrome we found out that you can force downloads, obviously sending headers for force download and all of a sudden you open it from your temp folder or you open it from your desktop and you're now in the file security contacts. And voila, it automatically authenticates the SMB share. And you've got them authenticating to your rogue server. But what about, you know, if they won't click just download or open from temp? Well, could we get it so when they just view a page they automatically authenticate? You bet you. So it turns out there's these things called plugins for Firefox and Chrome. And these plugins phone back to other applications so on and so forth. And it turns out that Quick Time is the one that I kind of came across as most often installed by users by default. You know, there's probably dozens of other extensions but most commonly you'll see people with iTunes, with their iPhones and all, and Quick Time installed with it. So as I went through the list of different applications and Quick Time kind of popped up I thought, well how do I get Quick Time to connect to a rogue network server to get the user's username and password? And so after a little tinkering we found out that you can put a playlist together with a UNC network path and they'll automatically authenticate and they'll bypass the local security contacts. So we need to do a little more work into other plugins. But for now, really Quick Time I think is one of the bigger impacts for that. So another way we can get people to automatically authenticate to our rogue servers over emails. Some people may already know about this, others not so much, but in Outlook if you have an HTML email and inside of it's a network share, it'll automatically connect and authenticate. That's pretty cool. What about .docs? The whole Office Suite is actually like this. Embed an image or an HTML file, open it up, it'll automatically connect to that network share. One of the other things is the desktop.ini files. Now this again wasn't made as well known, but it's been out there. You can generate desktop.ini files to say that the icon resource or the wallpaper for that folder is a network share. And again, the system will automatically connect, attempt to get that icon and log in with the currently used credentials. And LNK network shortcut files, you can set other parameters in there to automatically connect. So the tool set automatically creates these desktop.ini files, automatically creates the HTML file. It's really quick, really easy. And obviously the last one is man the middle. You can redirect NTLM authentication requests or inject HTML accounts in the page. While the tool doesn't do this, it helps with it. But that's the ways you can get clients connecting to these rogue servers to do the relaying. So the existing tool sets out there that do NTLM relaying over SMB or HTTP, you can use all of these today to go ahead and use other tools to get them authenticated to you. So one of the cool things that I thought about Squirtle, the tool I kind of used as a starting point for this was that it did API requests where you could use any tool you wrote to get these type 2 and type 3 messages. And so with the type 3 messages, that's the final authentication request. You need to pass the type 2 to the API and you get the type 3 back. So I wrote up an API quick so you can use any tool set you want, any tool you can modify the source code of, and use the rogue servers to connect. Well, that's great. But that requires you to have some interaction when you're a pen tester or you're testing people. So what I wrote together that's new for any other tool is a set of rules. All the other relay tools, like I said, forward everything to one source. Now we're identifying who these users are. So to really show the impact, I wanted to have it so with one click, like I said, in 60 seconds, you could get domain admin. So with that, you know, we write these rules out then in the new application to say when we figure out this user belongs to a group and they may have access over here, do something automatically when they connect. No longer do we have to try to get them to connect and wait and hope they come back around, but as soon as you see the user, do this. So the real set's pretty simple and I'll show it in the UI in a little bit. If a user is in a certain group, then use this module whether it be whatever the client is, SMB, SGB, et cetera. We good? I just hear fuzz. I didn't touch anything I swear. Okay. So we're not so good. Better? Okay. Swear I didn't touch it. So we write these rule sets basically to say if a user is in this group and they're in this module to perform this action against these targets and should we do it just once or per every user but I'll show that in a second. So the rule sets kind of go through this sequence of automatically looking for these API requests, looking for these under rules and keep doing it. Keep going through this until it times out. And if it times out, keep the user authenticating by not letting them time out and disconnect him but doing a stack challenge. So the things we can connect to, we've always had this kind of grid showing that you can use SMB to connect to SMB, HTTB to connect to HTTB, HTTB, SMB, so on and so forth doing the NTLM relaying. So the problem was that people didn't touch a lot of other protocols. And so I decided to take a look at other protocols. LDAP, MSSQL. Now I'll touch on why LDAP is kind of awesome in a minute but MSSQL, cool. We can get databases, we can get access to the data. Awesome. So SMB with the clients, we wanted to do some actions automatically as soon as we connected. So one of the big things is there's no tool out there to enumerate users and groups. Well, sorry, I take the back. There was no tool. There is now through Metasploit, which was released at BlackHap this year. Two of us were working on kind of separate projects and weren't talking and didn't know about each other either. But so you can enumerate users and groups. Now you may be like, why does it matter? I can enumerate stuff, whatever. Well, as a penetration tester it's one of those things you can figure out the administrators and the local administrators group as well as further information about what groups and what users you need to target. Cool, great. We can do NTLM relaying and do enumeration. We can also access file shares. We can execute commands. But this is great and all, but we can't connect to domain controllers. And the reason being is that most domain controllers by default have SMB signing. Now for those of you who aren't familiar with SMB signing, SMB signing basically uses the original NTLM hash to sign the session. And so every packet is signed. If there's a signature is off, it takes and disconnects you. So by default, domain controllers have SMB signing by default, so by default you can't do SMB relaying to a domain controller. Now this pissed me off. I had to figure it out there had to be some way we could get there really fast, really easy. So I'll come back to that. Turned out LDAP is enabled by default in domain controllers, yes? And uses NTLM authentication and turns out. And that's cool. That's great. But we couldn't change passwords because it typically requires SSL and SSL is enabled in LDAP unless there's a certificate of authority set up for the domain. So great. We can also do this what's written in the tool that you can change user passwords, reset users, add users, enumerate the domain, all that cool stuff. But the really cool thing is without SSL, without any of this using NTLM relaying, we can add users to groups. So if it has a tester, you're able to take and connect and get another user's account. We can take and add them to a domain administrator's group if we get a domain admin and so on and so forth. But going back to SMB real quick, one of the other cool things about this tool that kind of bugged me was that we always had to use certain tools to do this. So on the play write down here, I decided ham and tinker with some stuff. It's four hours from Chicago. Give or take. It's united. So it'll take a little time. So took and wrote a SOX proxy. So for those of you who aren't familiar with SOX, a proxy that sends raw data back and forth doesn't re-parse it. So on the way down, wrote a SOX proxy that does replacing the NTLM packets with the relayed data. That's pretty cool. It's unique new. Again, HTTP, we can relay it to SharePoint. Some internal website is great. All of this is kind of, you know, that's cool. But, you know, you have to be inside the network. And a lot of people think that NTLM relaying is not a problem because you have to be internal to the network. But what about externally? You know, sometimes there's a SharePoint, but typically not too often. And so I thought about what's one thing that is most organizations have open externally that supports NTLM. And it turns out exchange web services. For those of you who are not familiar with exchange web services, it's kind of an HTTP API that's usually on the same server as Outlook Web Access, your web mail and all. And by default, it uses HTTP Negotiate which supports NTLM. So with that, we're able to relaying externally to an HTTP service, which is exchange web services. So this becomes a little more scary as people have been talking about how you have to be internal to an organization to do relaying. We can now take and target mobile workforce users who are at a mobile hotspot or target people over the internet if they don't have outbound firewall rules to connect back to a rogue SMB server as we talked about the rogue server and get them to auto authenticate to this exchange web services. And with this, we can pull all their emails, all their contacts or calendar, anything you can do through exchange web services. And why? Because everyone's got a mobile phone connecting back to exchange web services in ActiveSync. I wish I had a drink because I would drink right now. The demo got fucked. And I'm going to get booed like no other. But oh, thank you, sir. You're a gentleman and a scholar. Fuck. No, honestly, I had a demo set up to do exchange web service, show NTLM relaying to exchange web services as well as doing other stuff. So the problem is all my VMs got fucked. So instead, I'll show just the GUI on it. That's a code. Here we go. So this is the GUI to it. I'll run through this real quick so you can kind of get an idea of its functionality and how powerful it can be as you grow. So right now what's running is the rogue HTTP server, the rogue SMB server and an HTTP management server. With this, we define what users are and what groups. Cool. So it keeps track of what users connected at what time. I hope that's big enough on this. Can people read that or no? Back row? Sort of? Good. So keep track of the users that are connecting back. Now you can keep having users connected back and it has who are the users connected back right now. Now you'll see there's some system accounts, there's some actual user accounts. And with this, we can just in one click say enumerated target over SMB, get their emails from exchange web services, execute a shell to a session if they're an admin, access a file share as them, access their share point, et cetera. Again, the VM got fucked so we can't really show all that much. But we can then create rules, like I said. We can add users to groups. We can do this automatically through enumeration or we can manually add them to a group and create a group called, say, Moo. Cool. Great. We have now a user. Oh, crap. There it goes. Like I said, the ads do not like me. Three, two, one. Done. So it's very much alpha. I'm sorry, guys, but I had three weeks to code this all out. So we can add a user to, again, to a group. And so we've got this user in this group, YAR. We can also, like I said, enumerate from the domain controller all the different user groups. So then we can create these rules to automatically authenticate. So in this case, I already have a rule in here. So if you see a user in group, users, YAR, then connect over exchange web services to targets and target groups right now there are any. But we can easily add one, say, ten, one, ten, two, fifteen, two target group. Now as soon as it sees an authentication request from someone who's in that user group, it'll automatically connect to there and pull all the emails from folder inbox, folder drafts. We can easily add saying, here's another folder. Let's pull their sent items. And voila, it adds that rule. Now what's cool about this tool is that as it does this authentication request, a lot of tools keep having you re-authenticate. What it does is keeps the session open when it connects to this rogue and perform this action. So instead of re-authenticating every time it tries to get the inbox, it keeps the session alive so you don't have to re-authenticate. So we have about 30 requests coming in from the system. So we can set about probably 30 rules in the first try. And then in that one connection we can repeat it for all the users and all the targets that connect or just certain targets. Now at the same time, we can generate the payloads, like I said, generating the HTML, the desktop.ini, the doc, LNK file, zip file, the LNK file doesn't work, it just says how to do it as well as generate the HTML email automatically. So I'm trying to make it as simple as possible, like I said, the fire sheep of NTLM relaying. And finally, it keeps track of the passwords. And so you can try to crack the passwords as well. So since the demo is fucked, that's about the best I can show right now for a demo. And I'm sorry, I'm really sorry guys, I'm so pissed that I went to shit on the plane. So how do we protect ourselves against this? Really, everyone's had varying solutions for how to protect against it. And I lost this slide. People have said use NTLM version 2. The tool supports NTLM version 2. There's nothing different about NTLM version 2 than NTLM version 1 that we can't relay. So really the thing you need to do right now, if your assist admin is go home and firewall outbound 445, this will prevent anyone from sending you any of these rogue payloads and getting you to automatically authenticate the environment. But that doesn't protect against mobile workforce, et cetera. So in this case, it's Kerberos, Kerberos, Kerberos, it is. But the problem is telling an organization you have to switch everything to Kerberos today is not going to work. The problem is there's a lot of stuff that doesn't support Kerberos. The other thing is that if you enable Kerberos, you have to force Kerberos, you can't support NTLM at all. Same thing with signing. For those who don't know signing, every packet is signed then by the authentication. It all has to be forced, not just supported. That's a big misconception that people have is that I enable signing, that should be fine. You have to force it, which in turn breaks a lot of stuff. So before you go out there trying to fix NTLM relaying and NTLM issues in the organization, test, test, test, test, test, because it will break a lot of legacy stuff. So really, there's a lot of balance you have to take when you're a corporate sysadmium. The big issue is that you need to move away from NTLM. It's really something it's going to take time, but Windows 8 and Windows 2012 still supports it and still hasn't enabled by default. So we need to go out there and start moving away to Kerberos, and hopefully this tool will be the one that kicks that off. So the code will be posted on Tuesday when I get back home to this website URL, in case you don't want to take a photo or write it down, is on the DEF CON DVD as my slides. Check it out if you haven't looked at it yet. Otherwise, if you have any questions or want to tell me how shitty my talk is and how shitty the demo was, there's my email and you can bitch at me on Twitter. So...