One-Click to OWA
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Martin, William
With the presense of 2FA/MFA solutions growing, the attack surface for external attackers that have successfully phished/captured/cracked credentials is shrinking. However, many 2FA/MFA solutions leave gaps in their coverage which can allow attackers to leverage those credentials. For example, while OWA may be protected with 2FA, the Exchange Web Services Management API (EWS) offers many of the same features and functionalities without the same protections. In this talk, I will introduce ExchangeRelayX, an NTLM relay tool that provides attackers with access to an interface that resembles a victim's OWA UI and has many of its functionalities - without ever cracking the relayed credentials. ExchangeRelayX takes advantage of the gap in some 2FA/MFA solutions protecting Exchange, potentially resulting in a single-click phishing scheme enabling an attacker to exfiltrate sensitive data, perform limited active-directory enumeration, and execute further internal phishing attacks.
 I'd like to introduce first time speaker William Martin in his talk, One Click, Codelia. Thank you, Kars. Let's see if I can maximize them. Cool. So, as Kars said, my name is William Martin and 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. If you can't see me back there, I'm the one on the right. And we only got 20 minutes, so we're going to kind of blow through this. We're going to talk about basics on exchange and the various endpoints on exchange. We're going to go through a little bit of a multifactor authentication crash course on how it's typically set up, which will kind of emphasize some gaps that some organizations face. Then we're going to talk about my favorite tag, which is the NTLM relay attack. We're going to do a demo and a tool release, and then we're going to talk about how to fix the things that will be just broke. So, overall, organizations have been doing a pretty kick-ass job in terms of implementing multifactor authentication across the board for their externally-facing services. It's like VPNs, definitely, our remote desktop services, Citrix, Web Apps, and email. With an asterisk on email, we're going to get to that one. 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 multifactor authentication on OWA. I don't know about most of you, but I have emails synced to my phone. I have a particular gamble at least 60%, 70% of this room also have that scenario for themselves. But when I was working in an organization, I found that I was using multifactor authentication on our OWA portal, but my phone was syncing just fine with just my username and password with no other factor, no certification. No code, nothing. So that was a bit weird. It seemed like it was counterintuitive for the point of multifactor 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 going to talk about. So, for those who haven't set up an Exchange server themselves, Exchange has multiple roles in which it can be installed. There's a mailbox server role, there's an edge transport role, 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 Autodeskver, for telling us how to connect to our email, Mappy, which is how Outlook connects in, and OWA, and ECP, which are pretty much the focus of this. 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, 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. Autodeskver tells your client how to connect to Exchange, Mappy is used by Outlook, RPC is used by Old School Outlook, Active Sync is used by your phone, typically. OAB provides your client a way to download the global address book, so it kind of eases the burden on Exchange. ECP is an 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 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 task, manage your calendar, and whatnot from the web without having to 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 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, Active Sync, 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 and 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 Blackhill Information Security, that have found this kind of gap, this inconsistency on the implementation of multi-factor authentication protecting Exchange. And in 2016, they reported this to Microsoft and say, hey, this is a gap, are you guys going to 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, 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 pervasive human error. Why it cost all these organizations, do we see this gap consistently? And the answer is, there really isn't a mention of these other endpoints in those two-factor authentication protocol implementations. So things like Symantec, RSA, a little bit of duo, and 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, 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 protected OWA, you're technically talking to 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 whole Exchange happens over HTTP, happens over that web app-based protocol. But EWS, 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. 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 give me 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, like Symantec, and say, hey, does 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. They're not oblivious to this. 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, which, if you've got an exchange environment on-premises, takes a bit of an 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 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. 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 then vulnerable to this kind of 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 provisioning. With Pure Office 365, guys, when you're using Exchange online, you already support modern auth because it's all going through Office 365 anyways. 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 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 on 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. So NTLM Relay is my favorite attack and it's how I pop maybe 80 to 90% of my internal pen tests. It's a tail... It's attack is all this time itself. The Cult of the Dead clown. The Cult of the Dead cow were exploring 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, all right, 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, OK, 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. 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, ah, sorry, NetBios and LLM and R Poisoning, which, anyone here use responders show hands? Yeah, a fair number of us. So, never fails to get a hash. 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 in to you. And I'll get the NTLM hash. Recently, I've seen some really cool ways to trigger NTLM authentication that I think are worth mentioning. So, recently there was a CV pushed out by Will Dorman, which he found that Outlook, you could send an RTF or a rich text 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 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. And this is all without user intervening and there's no any kind of warnings. So essentially you send an email, they open it, and you already get their hash. Microsoft patched that one, but we all know that everyone patches everything appropriately so we have nothing to worry about there. So, 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, launch, write, and attacker can modify the details of a Microsoft document and embed a 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. 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 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 these are protected by NTLM and we can relay to NTLM, which one do we want to attack? Well, a couple years ago, a 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 upon receiving an email, sending an email, upon a certain event happening. And so, a 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 Outrule would run upon the event happening. So, 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 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've already, Christ! All right. So, which I had never heard of until I built this, until I ran this attack. So, in a nutshell, Exchange Web Services is just a way to access Exchange through an API. And the thing 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 and to one and done. So, I built a tool called Exchange Relay X, which has these goals in mind. If we pop a user, we want to be able to read, send, delete, you know, manage their inbox as they would. We want to be able to download their attachments, add forwarding rules to kind of backdoor their email, scrape as much data as we can from Active Directory, and launch spearfishing from inside the organization. Typically, orgs have great attachment filtering on the 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 malicious attachments without being filtered through. All right. 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's your usual Outlook web app interface. You've got emails. You can see that the user that we're on is William Martin, that's me. 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. All right, cool. So, now we're going to 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 turns out, we do. So, let's build a relay to that NTLM interface. Let's build a relay to exchange web services. All right. This is showing sending a sample UNC link to a victim. We're masking it as a YouTube link. I'm skipping through some of the loading times of the demo because we're tight on time. The user gets 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 hackers. So, now you see we can open up their email. We still got the same 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 going to 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 add forwarding rules as well as you can automatically download all of their attachments. So, it just like 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... APPLAUSE Stop applauding, we have to move through. So, how do we fix this? You have to implement modern authentication across your organization. Oh, man. All right. Modern authentication everywhere. You have to implement Azure with that. RPC won't be able to support that. Same thing with Pop3 and IMAP. If you have any 2010s anywhere, this will not work for you. You can't get modern auth with 20 20s in the environment. So, yeah. Implement MFA everywhere. Filter on 139, 405, and remember that split tunnel VPNs and IPv6 are typically a gap. All right. Here are the contributors. Sorry for the rust-through. APPLAUSE
 I'd like to introduce first time speaker William Martin in his talk, One Click, Codelia.  Thank you, Kars.  Let's see if I can maximize them.  Cool. So, as Kars said, my name is William Martin and 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. If you can't see me back there, I'm the one on the right.  And we only got 20 minutes, so we're going to kind of blow through this. We're going to talk about basics on exchange  and the various endpoints on exchange. We're going to go through a little bit of a multifactor authentication crash course  on how it's typically set up, which will kind of emphasize some gaps that some organizations face.  Then we're going to talk about my favorite tag, which is the NTLM relay attack. We're going to do a demo and a tool release,  and then we're going to talk about how to fix the things that will be just broke.  So, overall, organizations have been doing a pretty kick-ass job in terms of implementing multifactor authentication  across the board for their externally-facing services. It's like VPNs, definitely, our remote desktop services,  Citrix, Web Apps, and email. With an asterisk on email, we're going to get to that one.  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 multifactor authentication on OWA.  I don't know about most of you, but I have emails synced to my phone. I have a particular gamble at least 60%,  70% of this room also have that scenario for themselves.  But when I was working in an organization, I found that I was using multifactor authentication on our OWA portal,  but my phone was syncing just fine with just my username and password with no other factor, no certification.  No code, nothing. So that was a bit weird. It seemed like it was counterintuitive for the point of multifactor 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 going to talk about.  So, for those who haven't set up an Exchange server themselves, Exchange has multiple roles in which it can be installed.  There's a mailbox server role, there's an edge transport role, 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 Autodeskver,  for telling us how to connect to our email, Mappy, which is how Outlook connects in, and OWA, and ECP,  which are pretty much the focus of this.  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, 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.  Autodeskver tells your client how to connect to Exchange, Mappy is used by Outlook,  RPC is used by Old School Outlook, Active Sync is used by your phone, typically.  OAB provides your client a way to download the global address book, so it kind of eases the burden on Exchange.  ECP is an 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 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 task, manage your calendar, and whatnot from the web without having to 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 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, Active Sync, 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 and 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 Blackhill Information Security, that have found this kind of gap,  this inconsistency on the implementation of multi-factor authentication protecting Exchange.  And in 2016, they reported this to Microsoft and say, hey, this is a gap, are you guys going to 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,  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 pervasive human error.  Why it cost all these organizations, do we see this gap consistently?  And the answer is, there really isn't a mention of these other endpoints in those two-factor authentication protocol implementations.  So things like Symantec, RSA, a little bit of duo, and 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, 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 protected OWA, you're technically talking to 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 whole Exchange happens over HTTP, happens over that web app-based protocol.  But EWS, 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.  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 give me 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,  like Symantec, and say, hey, does 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.  They're not oblivious to this.  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,  which, if you've got an exchange environment on-premises, takes a bit of an 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 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.  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 then vulnerable to this kind of 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 provisioning.  With Pure Office 365, guys, when you're using Exchange online,  you already support modern auth because it's all going through Office 365 anyways.  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 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 on 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.  So NTLM Relay is my favorite attack and it's how I pop maybe 80 to 90% of my internal pen tests.  It's a tail...  It's attack is all this time itself.  The Cult of the Dead clown.  The Cult of the Dead cow were exploring 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, all right, 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, OK, 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.  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, ah, sorry, NetBios and LLM and R Poisoning,  which, anyone here use responders show hands?  Yeah, a fair number of us.  So, never fails to get a hash.  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 in to you.  And I'll get the NTLM hash.  Recently, I've seen some really cool ways to trigger NTLM authentication  that I think are worth mentioning.  So, recently there was a CV pushed out by Will Dorman,  which he found that Outlook, you could send an RTF or a rich text 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 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.  And this is all without user intervening and there's no any kind of warnings.  So essentially you send an email, they open it, and you already get their hash.  Microsoft patched that one, but we all know that everyone patches everything appropriately  so we have nothing to worry about there.  So, 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, launch, write, and attacker can modify the details of a Microsoft document  and embed a 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.  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 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 these are protected by NTLM and we can relay to NTLM,  which one do we want to attack?  Well, a couple years ago, a 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  upon receiving an email, sending an email, upon a certain event happening.  And so, a 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 Outrule would run upon the event happening.  So, 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 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've already, Christ!  All right. So, which I had never heard of until I built this, until I ran this attack.  So, in a nutshell, Exchange Web Services is just a way to access Exchange through an API.  And the thing 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 and to one and done.  So, I built a tool called Exchange Relay X, which has these goals in mind.  If we pop a user, we want to be able to read, send, delete, you know,  manage their inbox as they would.  We want to be able to download their attachments, add forwarding rules to kind of backdoor their email,  scrape as much data as we can from Active Directory, and launch spearfishing from inside the organization.  Typically, orgs have great attachment filtering on the 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 malicious  attachments without being filtered through.  All right. 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's your usual Outlook web app interface.  You've got emails. You can see that the user that we're on is William Martin, that's me.  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.  All right, cool. So, now we're going to 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 turns out, we do.  So, let's build a relay to that NTLM interface. Let's build a relay to exchange web services.  All right.  This is showing sending a sample UNC link to a victim.  We're masking it as a YouTube link.  I'm skipping through some of the loading times of the demo because we're tight on time.  The user gets 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 hackers.  So, now you see we can open up their email. We still got the same 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 going to 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 add forwarding rules as well as you can  automatically download all of their attachments.  So, it just like 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...  APPLAUSE  Stop applauding, we have to move through.  So, how do we fix this?  You have to implement modern authentication across your organization.  Oh, man. All right.  Modern authentication everywhere.  You have to implement Azure with that.  RPC won't be able to support that.  Same thing with Pop3 and IMAP.  If you have any 2010s anywhere, this will not work for you.  You can't get modern auth with 20 20s in the environment.  So, yeah.  Implement MFA everywhere.  Filter on 139, 405, and remember that split tunnel VPNs and IPv6 are typically a gap.  All right. Here are the contributors.  Sorry for the rust-through.  APPLAUSE
DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_0_383.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_384_1919.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_1920_2231.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_2232_3299.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_3300_6311.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_6312_16259.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_16260_17459.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_17460_19379.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_19380_20447.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_20448_25331.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_25332_25415.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_25416_25475.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_25476_25667.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_25668_26447.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_26448_26615.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_26616_26771.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_26772_27491.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_27492_28199.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28200_28391.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28392_28439.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28440_28511.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28512_28655.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28656_28955.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_28956_29435.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_29436_29483.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_29484_29555.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_29556_29603.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_29604_29723.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_29724_31163.png DEF_CON_26_-_William_Martin_-_One_Click_to_OWA_Flx5KdHOhqc_31164_31410.png