We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

One-Click to OWA

00:00

Formal Metadata

Title
One-Click to OWA
Title of Series
Number of Parts
322
Author
License
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.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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.
TrailSuite (music)Differentiated servicesRouter (computing)TwitterSoftware testingMultiplication signSoftware testingPressureSource code
Covering spaceDemo (music)Crash (computing)AuthenticationSelf-organizationRight angleBitDemo (music)Source code
InternetworkingVirtuelles privates NetzwerkEmailVirtuelles privates NetzwerkWeb applicationWhiteboardTerm (mathematics)Service (economics)Process (computing)Remote procedure callAuthenticationDivisorComputer animation
CodeBitDivisorAuthenticationControl flowPoint (geometry)Public key certificatePasswordCodeSelf-organizationEmailComputer animation
Server (computing)IBM Client AccessLevel (video gaming)Control flowService (economics)View (database)Address spaceCommutative propertyConnected spaceModemEmailTask (computing)Video game consoleData managementConfiguration spaceBitFocus (optics)Web applicationPolar coordinate systemServer (computing)Web 2.0Client (computing)System administratorCasting (performing arts)EmailLevel (video gaming)Standard deviation2 (number)Gastropod shellPower (physics)SynchronizationSystem callSource code
Service (economics)View (database)Server (computing)Address spaceControl flowLevel (video gaming)Client (computing)UsabilityTask (computing)EmailData managementVideo game consoleConfiguration spaceModemDefault (computer science)Mobile WebElectronic signatureTask (computing)AdditionMathematicsSynchronizationMobile appSet (mathematics)Hacker (term)Client (computing)Web 2.0Address spaceSystem callWeb serviceData managementEmailRule of inferenceWeb application1 (number)
EmailControl flowServer (computing)View (database)Service (economics)1 (number)Level (video gaming)CodeAuthenticationPseudopotenzialSoftware testingDivisorGame controllerEmailComputer animation
Sanitary sewerService (economics)ImplementationHill differential equationArithmetic meanInformation securityConsistencyAuthenticationDivisorMultiplicationComputer animation
Error messageSelf-organizationRoutingSystem administratorCuboidPhysical systemSource code
Level (video gaming)CausalityPseudopotenzialActive DirectoryService (economics)AuthenticationCommunications protocolCovering spaceSingle sign-onImplementationLevel (video gaming)AuthenticationBitServer (computing)Communications protocolInteractive televisionService (economics)Electronic program guideOSI modelDirectory serviceWeb applicationHTTP cookieDivisorSource code
Validity (statistics)Internet service providerSanitary sewerFormal verificationServer (computing)Token ringHTTP cookieCodeGoodness of fitPublic key certificateMessage passingHTTP cookieLoginAuthenticationInternet service providerCommunications protocol
Client (computing)Communications protocolIntegrated development environmentAuthenticationCausalityMechanism designProduct (business)DisintegrationCommunications protocolIntegrated development environmentBitAuthenticationOverhead (computing)Source codeComputer animation
ImplementationLevel (video gaming)AuthenticationActive DirectoryClient (computing)Token ringProcess (computing)Type theoryOffice suiteHybrid computerAuthorizationServer (computing)Office suiteShape (magazine)Form (programming)AuthenticationAuthorizationCommunications protocolDivisorToken ringSingle sign-onPhase transitionImplementationMappingInternet service providerSelf-organization
AuthenticationDefault (computer science)Mechanism designServer (computing)Service (economics)Kerberos <Kryptologie>View (database)Pointer (computer programming)Covering spaceAuthenticationCausalityBookmark (World Wide Web)Mechanism designPoint (geometry)Source codeComputer animation
Software testingAuthenticationProcess (computing)Point (geometry)Message passingSoftware testingComputer clusterMultiplication sign
Computer virusServer (computing)PasswordDomain nameMessage passingDependent and independent variablesComputer animation
AuthenticationLink (knot theory)EmailZeitdilatationFormal languageVideoconferencingAuthenticationLink (knot theory)Bookmark (World Wide Web)SoftwareShared memoryWindowEmailWeightComputer animation
Shared memoryHash functionBroadcasting (networking)Event horizonWindowDirect numerical simulationDependent and independent variablesNumberLocal area networkSource codeComputer animation
AuthenticationInclusion mapElectronic meeting systemServer (computing)VolumenvisualisierungEmailMessage passingAnnulus (mathematics)Rule of inferenceFiber bundleAuthenticationWindowEmailHash functionComputer animation
Normed vector spaceSet (mathematics)Office suiteWordAuthenticationWechselseitige InformationDefault (computer science)Kerberos <Kryptologie>View (database)Mechanism designRule of inferenceEmailEvent horizonMacro (computer science)Interactive televisionLink (knot theory)Client (computing)BitAuthenticationSynchronizationWindowWeb pageWeb 2.0Set (mathematics)Metropolitan area networkServer (computing)
Rule of inferenceMultiplication signAuthenticationSource code
View (database)Kerberos <Kryptologie>Service (economics)Mechanism designDefault (computer science)Server (computing)Office <Programm>Client (computing)Function (mathematics)MathematicsWeb serviceRight angleWeb 2.0Computer animationSource code
AuthenticationServer (computing)Default (computer science)IBM Client AccessDigital filterRule of inferenceEmailSelf-organizationRule of inferenceEmailDefault (computer science)AuthenticationPay televisionDirectory servicePerimeterLevel (video gaming)Self-organizationMultiplicationPower (physics)Right angleDemo (music)
Power (physics)Demo (music)AuthenticationDivisorCovering spaceCodeComputer animation
Projective planeInterface (computing)EmailClient (computing)Web applicationRight angleAuthorization
Interface (computing)Web serviceEmailSampling (statistics)
YouTubeDemo (music)Sampling (statistics)Link (knot theory)Multiplication sign
Online helpIdentity managementLink (knot theory)EmailConnected spaceServer (computing)Source codeComputer animation
Execution unitStructural loadEmailConvex hullEmailReading (process)Metropolitan area networkHacker (term)Computer animation
Rule of inferenceEmailComputer animation
AuthenticationIntegrated development environmentBlogRight angleCase moddingMetropolitan area networkAuthorizationIntegrated development environmentSelf-organizationAuthenticationImplementationEndliche ModelltheorieComputer animationSource code
Firewall (computing)UDP <Protokoll>PerimeterVirtuelles privates NetzwerkLocal GroupPrincipal idealVirtuelles privates NetzwerkHeegaard splitting
Transcript: English(auto-generated)
like to introduce first time speaker William Martin in his talk One Click. Go Davey. Thank you Kars. So as Kars said my name is William Martin and uh I'm an OSCP I'm a pen
tester uh for RSMUS 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 kinda 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 kinda emphasize some gaps that some organizations face. Uh then we're gonna talk about my favorite attack 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 or remote desktop services, Citrix, um web apps and email uh with an asterisk on email and we're gonna get to that one. Um OWA is typically where we see a lot of two factor uh 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 emails synced to 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 mapi which is how outlook connects in, uh and 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 HPS, 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 power shell which is used by administrators to kind of administer the server itself. Autodiscover tells your client how to connect to exchange. Mapi 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 uh 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 beat a dead horse, OWA itself, the web app lets you access your email, access your tasks, 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 old school apps or uh the outlook client for Mac is based on EWS. So the endpoints because we're hackers that we care about are the ones that allow us to access the email. So that would be MAPI, 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 your email and whatnot without that
code. So to find out why, I mean, don'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 Black Hill 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 said hey, this is a gap, you guys are going to issue on properly configured systems. So I took that as okay, it's the admin's fault, a checkbox wasn't checked, they didn't add a route, it was just a human error causing this
thing, it wasn't a technological failure. But because it was so prevalent, I wanted to find out what was causing such a pervasive human error. Why across all these organizations do we see this gap consistently? And the answer is, there really isn't a
mention of these other end points in those two factor authentication protocol implementations. So things like Symantec, RSA, 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, 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 to Exchange, and I'm able to log in to 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 that web app based protocol. 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. 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 will pass that code off and
say to its multi-factor authentication provider, again like Symantec, and say, hey, business 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. 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
overhead to implement. So, modern authentication in a nutshell is Microsoft's implementation of the OAuth protocol. And it allows Outlook, EWS mapping 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 to a token and says, cool, you're good to go. The OAuth provider is the one that really implements those two-factor solutions or whatever else it 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
vulnerable to this kind of a 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. 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 end points 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 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 attack is old as time itself. The cult of the dead clown. The cult of the dead cow
were exploiting 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
user name. The attacker redirects that and says, hey, I want to log in. Here's my domain and my user name. 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 promptly 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. Some of the common ways, my favorite ways are UNC links and e mails, which if you're opening an e mail in Outlook and you click a UNC link, Outlook treats that, it really passes it on to Windows. And Windows treats that like 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, sorry, net bios and LLM and R poisoning, which anyone here use responder, show of 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 send a broadcast to the local network saying, hey, has anyone seen, I don't know, William's share? And typically there will be radio silence. But an attacker will say,
yeah, I'm William's share. And then the victim will say, oh, cool, all right, let me log into you. And that's how you 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 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 pass it to Windows and then Windows would authenticate to it if it's a UNC path. And this is all without user
intervening and this is without any kind of warnings. So, essentially you send an email, they open it, and you already got 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. All right. So, launch an attacker can modify the details of a Microsoft document and embed UNC path in the web settings. So, when 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 email and you can't get like a macro through, you
won't 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, SensePost 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 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, 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 MAPI or RPC, which is what ruler is based on. So, that just left this guy.
Exchange web services, which I five 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 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. If we pop a user, we want to be able to read, send, delete, manage their inboxes as they would.
We want to be able to download their attachments, add forwarding rules to kind of back door their email, scrape as much data as we can from active directory and launch spear phishing 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. 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. 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. 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. 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 relay 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 can have a lot of fun with it, but we're going to 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 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
little more technical. So, 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. Mod 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 2020s in the environment. Yeah. Implement MFA everywhere. Filter on 139445 and remember that split tunnel VPNs and IPv6 are
typically a gap. All right. Here are the contributors. Sorry about the rush through.