 I'd like to introduce first time speaker William Martin in his talk, One Click, Co-Deviant. Thank you, Kars. As Kars said, my name is William Martin, and uh, I'm an OSCP, I'm a pen tester for RSM US, and I'm based out of Charlotte, and you know, first time presenting at DEF CON, so no pressure. Thank you. Uh, if you can't see me back there, I'm the one on the right. And we only got 20 minutes, so we're gonna kind of blow through this. Uh, we're gonna talk about, uh, basics on exchange and the various endpoints on exchange. Uh, we're gonna go through a little bit of a multi-factor authentication crash course on how it's typically set up, uh, which will kind of emphasize some gaps that some organizations face. Uh, then we're gonna talk about my favorite tag, which is the NTLM relay attack. Uh, we're gonna do a demo and a tool release, and then we're gonna talk about how to fix the things that we just broke. So, overall, organizations have been doing a pretty kick-ass job in terms of implementing multi-factor authentication across the board for their externally-facing services. Like VPNs, definitely, our remote desktop services, Citrix, um, web apps, and email. Uh, with an asterisk on email, we're gonna get to that one. Um, OWA is typically where we see a lot of two-factor being implemented. But there's a little bit of a break in mentality on the goal for multi-factor authentication on OWA. Um, I don't know about most of you, but I have email synced on my phone. I take a gamble at least 60%, 70% of this room also have that scenario, uh, for themselves. Um, but when I was working in an organization, I found that I was using multi-factor authentication on our OWA portal, but my phone was syncing just fine with just my username and password with no other, no other factor, no certification, um, no code, nothing. So that was a bit weird. That seemed like it was counterintuitive for the point of multi-factor authentication. So, to find out why that gap exists, I realized I had to learn a little bit more about how my phone and my outlook were connecting to Exchange, and that's what we're gonna talk about. So, for those who haven't set up an Exchange server themselves, Exchange, uh, has multiple roles in which it can be installed. There's a mailbox server role, there's an edge transport role, um, and all of these kind of dictate how the server is going to operate. The role that we care about is called the client access server role. It's the one that we interact with when we're talking to our email. That's things like, uh, Autodiscover for telling us how to connect our email, uh, Mappy which is how Outlook connects in, uh, an OWA and ECP, um, which are pretty much the focus of this. So, Exchange Cast Servers run essentially on top of an IIS server. There's one large web app, and accessing them looks a bit like this. So, all over HTTPS, all over HTTP, uh, just your standard web calls. Now, to break down what these little endpoints do and the various ways you can talk to Exchange, there is PowerShell, which is used by administrators to kind of administer the server itself. Autodiscover tells your client how to connect to Exchange, Mappy is used by Outlook, RPC is used by Old School Outlook, Active Sync, used by your phone typically, uh, OAB provides your client a way to download the global address book. So, it takes, it kind of eases the burden on Exchange. ECP is, uh, in addition to OWA, which allows a user to kind of change their settings. This is where you go into when you're changing your signature, adding forwarding rules and whatnot, um, on your OWA. And then, not to be a dead horse, OWA itself, the web app that lets you access your email, kind of get access to your tasks, manage your calendar, um, and whatnot from the web without having to, like, run a thick client. And then finally, EWS or Exchange web services. It's a SOAP-based API that allows you to interact with Exchange and make API-based calls to your mailbox. So a lot of, like, old school apps or, uh, the Outlook client from Mac is based on EWS. So, the endpoints because we're hackers that we care about are the ones that have access to the email. So that would be Mappy, RPC, uh, ActiveSync, ECP, OWA, and EWS. Now, as a pen tester, interestingly enough, the ones that I find covered by two-factor authentication most often, are only these two. OWA and Exchange Control Panel, which leaves at least four other ways we can access or email whatnot without that code. So, to find out why, I mean, doesn't get ahead of myself. I'm by far not the first one to find this gap. There have been other security researchers, like notably, uh, Blackhill Information Security that have found this kind of gap, this inconsistency on the implementation of multi-factor authentication protecting Exchange. And, like, 2016, 2016, they reported this to Microsoft and say, hey, this is a gap, are you guys gonna fix it? Microsoft replied saying, no, because this is not an issue on properly configured systems. So I took that as, okay, it's the admins fault, a checkbox was in check, they didn't add a route, um, something, you know, it was just a human error causing this thing, it wasn't a technological failure. So, but because it was so prevalent, I wanted to find out what was causing such a, a pervasive human error. Um, why would, why would, why across all these organizations do we see this gap consistently? An answer is, there really isn't a mention of these other endpoints in those two-factor authentication, uh, protocol implementations. So things like Symantec, RSA, um, a little bit of duo, in their basic implementation guides, they would cover OWA and ECP, both of which are the only two web app-based protocols. And the reason that is, is because a lot of these protocols are authenticating through something called ADFS, or Active Directory Federation Services. Without derailing the talk to talk about what that is, um, in a nutshell, it provides a way for users to authenticate to this one server, through whatever means they choose, like multi-factor, and this server will provide that user a cookie which will vouch to other single sign-on services. So when you go to a, a protected OWA, you're technically talking to other server, this other server, it says, you know, William logged in, he's cool, just trust me. That trust gets passed through exchange, and I'm able to log into OWA, even though exchange didn't handle most of the authentication. So, the issue lies in that, that whole exchange, happens over HTTP, happens over like that web app based, um, protocol. Uh, but EWS and MAPI and RPC and those lower layer protocols can't handle that kind of interaction. So, that causes a bit of an issue. This is what it kind of looks like when you log into OWA through an ADFS protected setup. Um, you try to access OWA, you get that redirect saying no contact ADFS first. ADFS is the one that actually authenticates you. It says, hey, log in, maybe use your two-factor code or maybe, uh, give me your, your certificate to prove who you are. If you're using multi-factor, it'll pass that code off and say to its multi-factor authentication provider, again, like Symantec and say, hey, is this code good? And it will say yes or no. Anyways, after that's done, ADFS will pass you back your token or your cookie. You then take that over to OWA and you're good to go. So, vendors know that their solutions aren't covering these underlying protocols. This is not, they're not oblivious to this. Uh, but the issue is not so much on the vendors themselves as they've stated. It lies on the environment that they're implementing their solution on. And to implement their solution properly, they need something called modern authentication. Uh, which, if you've got an exchange environment on premises, takes a bit of a, uh, overhead to implement. So, modern authentication in a nutshell is Microsoft's implementation of the OAuth protocol. And it allows Outlook, EWS mappy and other protocols to handle, um, OAuth tokens. Now, with OAuth, exchange is no longer handling the actual authentication phase of it, even through single sign on like through ADFS. OAuth just passes exchange in a token and it says cool, you're good to go. The OAuth provider is the one that really implements those two factor solutions or whatever else may be. Um, but the catch is with modern authentication, you need to implement Azure in some way, shape, or form. You can't just spin up a DC on-prem, spin up an exchange server on-prem, spin up an ADFS server on-prem and be good to go. You have to interact with Office 365 somehow. And it's that catch that leaves a lot of organizations in the dark and, uh, vulnerable to this kind of, um, lack of coverage. So, when you implement it with exchange on-prem, you need to use something called hybrid modern authentication. It requires an on-prem ADFS and it requires you to use Outlook 2013 or later and you're using Azure to perform all of the token, uh, provisioning. Uh, with Pure Office 365 guys, when you're, when you're using exchange online, you already support modern auth because it's all going through, uh, Office 365 anyways. Um, it just comes down to what kind of multi-factor authentication you want to implement through this now supported protocol. And this is what it looks like when you have a hybrid setup. So, anyways, now we know that the gap that these two factor solutions cause is not a quick, easy fix. And I love that because it makes it a pain in the ass for my targets to cover, you know, cover theirs. So, while we can, how can we take advantage of this gap? How can we take advantage of this oversight? Well, looking back at those other endpoints that you can talk to that are typically unprotected, there's a common theme amongst three of them. Before doing this research, I didn't know that three of them use NTLM, which is my favorite authentication mechanism. So, that's my point. So, also the first meme I've ever made. Um, so NTLM relay is my favorite attack and it's how I pop maybe 80 to 90% of my internal pen tests. Um, it's a tail, it's attack is all this time itself. Um, the cult of the dead clown, the cult of the dead cow where I explained this as early as 2001. So, for those who don't know, the NTLM relay attack happens through three messages. Works like this. The victim is somehow tricked to connect to an attacker and we'll talk about how they're tricked in a second. But they connect to an attacker and say, hey, I want to log in, here's my domain, here's my username. The attacker that redirects that says, hey, I want to log in, here's my domain and my username. The target server will reply saying, alright, cool, if you're really so and so, take this challenge and hash your password with it. We don't know the password as an attacker, so we'll pass that right back to the victim. The victim will happily oblige and pass that back. So now the attacker has the response, we pass that on to our target server. Target server probably says, okay cool, you've now authenticated, you are so and so. The attacker gets the session and we kill our victim. We just say, no, you weren't able to log in. So, the ways to trigger NTLM authentication are vast. Um, some of the common ways, and my favorite ways are UNC links and emails, which if you're opening an email in Outlook and you click a UNC link, Outlook treats that, it really passes on to Windows and Windows treats that like a, you're trying to access a network share and per network shares it will try to authenticate to it, try to log in, try to open that folder for you. Well, if the attacker is on the other end of that UNC path, it will authenticate to them and that triggers the NTLM relay attack. My other favorite way is NTLM, uh, sorry, NetBios and LLM and R Poisoning, which, anyone here use responder show hands? Yeah, fair number of us. So, uh, never fails to get a hash. Um, for those who don't use responder, it's a tool that hackers use to abuse how Windows works. When Windows asks for a resource that isn't available through DNS, it will then send a broadcast to the local network saying, hey, has anyone seen, I don't know, William share? And typically there will be radio silence. But an attacker will say, yeah, I'm William share. And then the victim will say, oh cool, all right, let me log into you. And then that's how you get the NTLM hash. Recently, I've seen some really cool, well, ways to trigger NTLM authentication that I think are worth mentioning. So, uh, recently there was a CVE pushed out by Will Dorman, which he found that Outlook, you could send an RTF or a rich checks formatted email. And when Outlook received that email, it would parse it. And if that RTF email had a, I know I'm getting really technical, but if, uh, that RTF email had a remote resource embedded in it, Outlook would try to automatically load that and it would parse it to Windows, and then Windows would authenticate to it if it's a UNC path. Um, and this is all without user, um, intervening. And this is without any kind of warnings. So essentially you send an email, they open it, and they are, you already get their hash. Um, Microsoft patched that one, but, uh, we all know that everyone patches everything appropriately, so we have nothing to worry about there. So, um, the other way that is not patched, because it's a bit more difficult to patch, is by Mike Felch. Mike, you in the room? Oh man, he said he was coming. Alright. So, long story short, an attacker can modify the details of a Microsoft document and embed, uh, UNC path in the web settings. So, when a Microsoft Word opens up that document, it will see a little UNC path in the web settings, and it treats that as an external HTML page that you want to embed in your document. And so, as always, it will try to reach out and get that, and if it's on a share, it passes it to windows, and windows will authenticate. This one, there's no user interaction whatsoever outside of opening a document. So if you find that UNC links are filtered in K-mail, and you can't get like a macro through, you might be able to get just a benign document through their email system and get them to trigger an NTLM authentication that way. So, now that we know that we can, these are protected by NTLM, and we can relay to NTLM, which is what we want to attack. Well, a couple years ago, uh, Sense Post came out with an attack called the Ruler Attack, which took advantage of Outlook rules. In a nutshell, the Outlook thick client on a desktop could be configured to run certain commands, uh, upon receiving an email, sending an email, upon a certain event happening. And so, Ruler found out that if you compromise the user credentials, if you're on the outside, you could create a new Outlook rule, sync it up with their server, that rule will then be pushed down to the exchange of Outlook clients, and then that rule would run upon the event happening. So, um, naturally I thought, great, I could get RCE with a relay, let's use that. That's what Ruler looks like. Unfortunately, one of the creators of Ruler already had this idea, and it turns out, to perform the true, uh, the true authentic ruler attack, you need to authenticate to exchange more than a few times. And the NTLM relay attack is pretty much a one and done. So, you're not going to really get that far with using a mappy or RPC, which what Ruler is based on. So, I just left this guy, exchange web services, which I, five already, Christ! Alright, so which I had never heard of until I built this, uh, until I ran this attack. So, in a nutshell exchange web services is just a way to access exchange through an API. And, the things we care about is that it's enabled by default. And by on premise exchange, it supports NTLM by default. And it provides access to most things Outlook has access to. And we don't have to go through multiple stages of authentication with NTLM on EWS, it's one and done. So, I built a tool called exchange relay X, which has these goals in mind. Uh, if we pop a user, we want them, we want to be able to read, send, delete, you know, manage their inbox as they would. We will download their attachments, uh, add forwarding rules to kind of backdoor their email, uh, scrape as much data as we can from Active Directory and launch spear phishing from inside the organization. Typically orgs have great, uh, attachment filtering on their prim, on the, uh, perimeter. But from user to user from inside the organization, they have that gap. So, if you compromise the exchange of one user, you might be able to send users B, C and D, uh, malicious attachments without being filtered through. Alright, so now let's try to power through a demo. This demo is going to show an OWA that's protected with two-factor authentication, but is vulnerable to the same gaps that we've covered. Now being prompted for the code, enter it through and there, and there's your usual, uh, outlook web app interface. You've got emails, you can see that the user that we're on is, uh, William Martin, that's me. Uh, we've got a folder over there on the left called modern auth project. We're going to open the user's outlook thick client just to demonstrate the same thing. So, now we're going to actually launch the attack. The tool is called exchange relay X, and right now we're just going to check if the victim is vulnerable. Right now it just reaches out to the mail and says, hey, do you support NTLM? And it turns out, we do. So let's build a relay to that NTLM interface. Let's build a relay to exchange web services. This is showing, sending a sample UNC link to a victim. And we're masking it as a YouTube link. And I'm skipping through some of the loading times of the demo because we're tight on time. The user gets the, uh, the phishing email with that malicious link in there. They click it, and that's it. That's all the user has to do. The attack is now done on their end. Over here we receive the connection, we've relayed it back to their exchange server, and we see them popped right there. So, what can we do with this? I tried to build a similar looking OWA for, for hackers. So, now you see we can open up their email. We've still got the same, uh, little folder on the left that they do. And by the way, as we're reading email and as we're sending email, we're not showing up in their sent folder. Man, you're killing me, Kars. So, I'm gonna release this tool and you guys have a lot of fun with it, but we kind of have to blow through what you can do. One of the features is that you can, uh, add forwarding rules as well as you can, uh, automatically download all of their attachments. So, it just goes through inbox, sent folder, everything, and just as quickly as it can downloads every attachment they've ever sent or received. So, if you have a user that's not super technical, maybe they're a CFO, and they get popped, that's a really bad day. So, stop applauding, we have to move through. So, uh, how do we fix this? You have to implement modern authentication across your application. Ah, man. Alright, modern authentication everywhere. Uh, you're gonna have to implement Azure with that. RPC won't be able to support that. Uh, same thing with pop 3 and IMAP. If you have any 2010s anywhere, this will not work for you. You can't get modern auth with 2010s in the environment. Um, yeah, implement MFA everywhere, filter on 139, 445, and, uh, remember that split tunnel VPNs and IPv6 are typically a gap. Alright, here are the contributors. Sorry for the rush through.