Will C - Stop H i t t i n g Emailing Yourself Microsoft Direct Send and You

Um I'm going to run through a sort of generic overview very very high level um on the current state of email security. Uh we're going to look at a Microsoft specific component um called direct send um primarily from the attackers perspective. So why they like it so much. Um we're also going to look at a sort of new edge case um we accidentally ran into um that made what we thought at the time a fixed environment um vulnerable to this direct send bug. Um it's sort of around the questions of sort of I want to fix exploit or watch out for this direct send thing. Uh what can I do? Um so at a very very super high level um

what is email? Um so basically we've got our Gandalf guy here. He's got an email. He really wants to send it to his friends um the Eagles. Um so he just sort of shoots that across. Everyone's happy. In reality though, um it's extremely unlikely on a network um that these two guys are going to be right next to each other. They're not going to have a direct connection. Um there's going to be something sitting in between them, so they can't talk. So instead, Gandalf has this fantastic idea. Um he'll have a chat to his little moth friend and say, "I've got this email I got to send. Uh the moth's a bit of an idiot, so he just flies off to the

nearest flower he can find." Gives the flower the email. Um the flower finds a bunch of rocks, shoots the email across to that. Um, thankfully one of the rocks sort of waddles over to our eagle friend. Um, he's all happy. He's got the email. We're cool. This is basically how email works. Um, in my head at least. Um, unfortunately when they were inventing email, um, none of these movies were made. Um, so they couldn't use them as a reference. Um, they had to rely on these things called words. And they basically took all these words, uh, and they put them into these things called RFC's, um, requests for comments. Um, these basically dictate how email will work, how certain things

on the internet will work, how computers should be communicating with each other. If you want to get involved in sort of that email process, you have to follow these RFC's. Um, these things aren't sort of private. They're all public. Um, you can go on the internet, search for them, read them if you really hate yourself for some reason. Um, but if we have a look at the one for SMTP, um, so like back in the day, I think the 1980s this one came out. um they had no concept of the passwords. Passwords were not included in this RFC. Um there was also no concept of authentication, authorization, nothing like that. Um obviously looking back now, there's a

massive security issue with this. But you have to remember back in the day, sort of 1980s, these things were just being invented. the people and the places that were playing with these things, things like universities, people just playing around. It's not that they didn't consider these things, they just didn't consider them to be super important um at the time they being developed. Um thankfully though, they did manage to squeeze in the word blah blah blah at least 10 times um within this one. Um so kudos I suppose. So if we jump back to our really clear example, um this lack of authentication, lack of password, those sorts of things, um opens up a massive security gap. So,

if we just sort of jump to a single communication stream, what's to stop these guys from pretending to be Gandalf? From the eagle side, he has no idea. It's not being checked. There's no passwords, no authentication. He's like, "Yep, cool. Sounds great." Um, and then we can start to sort of inject malicious things inside those communication streams. And the Eagle has no idea. Um, so you've got these RFC's and your job as an SMTP server is to follow these. You don't want to follow them badly. you don't want to introduce these security vulnerabilities. So, we basically tacked on a whole bunch of changes and updates and external parts to sort of cover those gaps. Um, one of

the sort of most basic examples is this concept of authentication. This is technically an extension of the original protocol because it wasn't included originally. So, we've got our Gandalf and he's like, "Yeah, you know, I totally want to send an email. You can totally trust me." Um, but what if it's not Gandalf? What if it's some sort of golemlike creature that's pretending to be Gandalf? Oh lord. >> Oh, I'm totally not getting invited back next year. Okay, very basic example. Um, but then it's up to the SMP p SMTP server to say, "Hey, you're Gandalf. Prove it. You know, where's my passwords? Who are you? I need to know this." Um, and then he's all sad because he obviously can't do

that. One of these sort of more complicated sort of stop gaps or security controls um is this concept of SPF send a policy framework. So let's say you've got someone else you say I'm not Gandalf at Mordor. I want to send an email but I want that email to come from the address of Gandalf@ middleearth.com. This might seem a bit weird um but it is a legitimate use case in SMTP. Uh and it does happen. Um so you kind of need to have a security control to stop the abuse of this one. So in this case, the SN2P server shoots its lasers um and it pulls out the domain that you want to send the email from. So in this case,

middleear.com. Um so we'll chuck that to one side. Um it'll use a second set of lasers to then also pull out the IP address that this person is coming from. It will do a very specific type of DNS lookup um looking for a record related to SPF. The owners or whoever controls Middleear.com, they can set this record. So they get to decide what goes in it. Um, the SMTP server then checks and says, "Hey, you're coming from this IP address. I've checked that record. Is your IP address allowed to send email from that domain?" Uh, in this case, it's no, there's no match. I'm sorry. I'm not going to let you send that thing. Blocks it off

there. Um, there's a sort of another category of controls um more at that transport layer. So, in this case, you've got your Gandalf. He wants to send his email. Um, we'll also do things like um, spam checking, very common. Um, looking for sort of malicious software, again, very common, sort of happening during the email transport process. Um, you guys would have run into this one a bunch if you work at a corporate organization. Um, they love chucking these on the external emails. Um, some SMTP servers will have these built in. Uh, more traditionally, it's actually external to those. Cool. Um, now for something not that completely different. Um, sort of pivoting slightly to this concept of

direct send. Um, it's mostly built for sort of legacy or weird devices back in the day. Um, if you think about it from when you had those sort of printers or scanners, you'd go up there, but you want them to email it to you. Um, you don't want these credentials. So, you don't want these old devices handling credentials. They don't understand it. They don't know how to use it. And so, Microsoft sort of built this for them. Um, so if you sort of concentrated from that perspective, um, kind of helps. Um, this is basically how Microsoft define it. um you have your sort of um on-prem network. Um there's something old or think think like your printer who wants

to send an email. Um it will actually chat to the cloud and it will send it out um on a specific port on a specific endpoint. Um this can't be used to send email outside the organization. This is only for internal use. Um you usually need to specify a from address um from that organization from a trusted domain. Um and you don't need any authentication to do this. Um, and from an attacker's perspective, that's a really interesting choice by Microsoft. Um, considering if you can hit this endpoint, you can then basically send email within the organization from anyone you want and impersonate anyone you want. Um, you can also bypass third party gateways depending on how the configuration has

been made for this particular thing. Uh, it's extremely to easy to exploit um with a simple oneliner. Oh god, what have I done? Uh it is also enabled by default and can't be disabled uh within Microsoft 365 environments. I put a little asterisk there um because that is changing more recently. We'll get into that later. So you know how do I exploit this thing, you know, for science. Um I am a massive fan of science. Um and so this is how you do it. Obligatory. Please don't go off and do this without permission. Um there is a very strong chance you'll go to the jails. Um, they'll probably ask you where you figured this out and then sort

of accuse me and then I'll go to the jails. I don't want to go to the jails. Um, this information is extremely easy to find. This was me googling how to exploit direct send. Um, the main purpose of this is to sort of demonstrate how easy it is to do. That little send-mail message part um is a PowerShell script that is built into any Windows modern Windows client system. You don't even need to download this tool. Um, you can just do it. Um, and when you do it, it will print out an email that looks completely legitimate to the end user. Um, so just going through a brief history uh of direct send exploits. So

there was this blog post from I think 2022 um was where I first sort of ran into it. Um when I was sort of reading up on this stuff at the time I remember reading this thinking, "Oh yeah, that's not that important. That's not that cool." But it's kind of cool, but not that interesting. Completely missed out on it. uh 2023 um these guys sort of produced an endpoint that you go to to test whether your organization was vulnerable. Uh I never saw this at the time. I only found this when I was researching this talk. Um but they made the really clear point that direct cannot be disabled. You cannot turn this thing off. There are workarounds which

we'll get into later. Um but the main thing is it is on by default and can't be switched off. Um more recently there's been a massive uptick um in people or bad actors actually exploiting this thing. Um so it is becoming significantly more prevalent. Um and just anecdotally towards the end of my pentesty sort of consulting space um we were seeing this stuff all the time. Um so probably 50/50 chance during an external pentest um that a client was vulnerable to this thing. Um it's not all doom and gloom. U Microsoft have these things or this concept of something they call connectors. Um I've tried reading up on them in my head it just does not click.

Um but basically you can control certain transport mail flows to sort of say if something is coming in via direct send I just want you to drop it. We don't need it. Um the concept of exchange online protection. Um so if you remember back to that sort of transport layer security if you're sending an email via direct send it doesn't bypass this stuff. Um so the spam filters the malware filters it'll still kick in. Um and it can still protect it that way. Um so I know what you're thinking. Uh, but William, I live in all land, not some mythical mortal land. And we fixed direct send issues. So why are you telling me all this? Uh,

three points. Don't call me William. Um, that's kind of reserved for my mother when I've done something really bad. Uh, you spelled Mordor wrong. Um, and we found this really weird edge case. Um, where we thought direct was fixed. Um, but it actually wasn't. Yay. Um, so jumping into that sort of weird edge case, um, we had basically been asked to do a mostly red teaming sort of engagement, but with the blue team very fully aware of it, it's what we'd call a purple team engagement where you have that sort of cross communication collaboration. Um, and one of the things they asked us to do was specifically check for this bug. Um, because they thought they'd fix it, they pretty sure

they'd fix it, but they just wanted that extra validation. Um, so I chose a random CIS admin. Um, put him as the target and then basically just spanned him. Um, and I just tried all these variations and slight tweaks and things like that. For context, this was me launching this script from my attackers machine. I had absolutely no authentication to the network. I wasn't connected in any way. Straight across the internet. U, and what we found was, you know, failed, failed, failed, didn't make it, didn't make it, and then it did. Um, and for some reason, most of them seem to fail and not make it through. And then the last one did. Um, which was super confusing for me.

God, that's a big Geralta. Um, basically up until this point, my understanding of direct send was it either worked or it didn't. You know, you could either spam them with lots of emails or you couldn't. Um, so we basically dug into the logs. Um, very fortunate that we had that communication. Um, so we could have a chat and basically say, "Hey, some of them are making it through, most of them aren't. What's the difference between the two?" So we sort of dig into it and we find that the ones that are sort of failing are having an SPF error of soft fail but the ones that are making it through um have this weird SPF of temp

error um which I had not run into before. So if you think back to my extremely clear clear understanding talk of what SPF is and what it's for um it was sort of around that process of checking that the source IP that is trying to send the email is allowed to they're legitimate. They're expected. So, we dig into it and we find the different types of SPF errors. Um, there's an error of none, which is basically that person doesn't have an SPF record, so we're not really sure what to do. Um, there's that concept of failing. So, it does the comparison. It checks the IPs and says, "No, I'm sorry. You're not allowed to send it. You

fail." Um, there's soft and hard fail, but that doesn't matter too much. Um, and then we have this temp error. Um, there's a bunch of other errors, but we don't really care because that's not what we're looking for. Um, so we basically do a bit of research on what this temp error is. Um, and it basically comes down to DNS, shockingly. Um, it's basically saying, "We've tried to look up your record, um, but for some reason that DNS process is failing." Um, one of the other data points we sort of looked at was on the receiving side of the email. So, these are the spam emails that managed to make it through. Um, we looked at these email headers. Uh if

you're not super familiar with email headers or emails in general, um essentially during the entire transport process of an email, every server or service or thing will actually leave a little metadata note about what they had, what they did with it, where they process it, where they sent it to. Um you can dig into these. Any email you've got will have these. Um they're semi-interesting. We basically jump into that and find we do have a DNS related error and it's basically saying protection outlook tried to do a lookup for a specific domain. It timed out. we couldn't do that specific lookup for SPF, which sort of matches what we were seeing in the DNS side. So, we have our theory about

what's going to happen, what's happening. So, we've got our SMTP server, we've got us trying to spoof this email, uses its lasers, um, pulls out the domain and the IP address that it's coming from. Sort of tries to do that DNS lookup. Um, but for some reason that lookup is failing. It's timing out. It's just not working. Not sure why. Doesn't matter too much. So from an SMTP server side, it doesn't know what IP addresses are allowed to send emails from this domain. So it gets down to this process where it wants to do this check and it's basically well, I'm not really sure what to do now cuz we don't know what's happening. When you

hit situations like this, um it's up to the SMTP server to decide what it wants to do. So it's not necessarily defined by an RFC. Um in this case, Exchange um does some exchange magic. we don't really know. And then it basically decides, you know what, yep, that's cool. We'll send that through. You look good. Um, if you actually look at the RFC um, regarding what to do with this temp error, um, it specifically states that it's up to the SMPP server to decide what it wants to do. So, technically, Microsoft are RFC compliant here. It's just questionable whether they did the right thing. >> Um, super weird coincidence. Um, after we'd sort of theorized what this process

was and what was causing it and we could replicate it, um, my contact at the time got an email from his CEO, um, basically talking about how amazing I was. I may have used direct send to send this and spoof it on behalf of the CEO. Hard to say. Um, but this is exactly what those sort of emails look like from the receiving side. So in this case, you can spoof whoever you want from inside that organizational domain to whoever you want inside that organizational domain. Um if that user exists um and if they have chosen to upload sort of their own profile picture within the Microsoft ecosystem, um Outlook will actually pull that picture in for you. I didn't

specify this picture. Um I had to swap it out obviously, but if that person had a picture, it would automatically be included inside that. Um, on top of that, there's no big warning scary banner saying this is an external email. Be super super careful from Microsoft's perspective. This was an internal email. It doesn't need that big banner. It's totally legit. You're fine. Um, so we thought of theorized. We figured out what had happened and then we decided, you know what, let's, you know, run back into the logs and see if this had been exploited before because we're kind of curious about that sort of stuff. Um, so this was an actual example of where this had been successfully

exploited. Um, if we look here, we're hitting a couple of temp errors. Um, compared to all of the ones where it failed. Um, and the ones that hit that temp error made it through to that end users inbox. Um, there is a semi-common pattern for when the spoofing is happening for the attacker to specify the same account for the sender and the receiver. So, from a users perspective, if you receive this email, it looks like it comes from yourself, which is a bit of an odd choice, but I suppose if you're spamming things at scale, >> um, cool. Now, what? Um, it's still not all gloom and doom and gloom. Um, we got some specific feedback from Microsoft

um, during this process. They were already aware of this DNS timeout issue. Um, I don't think they had quite connected it to the ability to exploit direct send via this sort of process. Um, but they were um, they said it was related to this concept of SPF macros, uh, which is a choice you have when you're configuring an SPF record. Um, they commented that temporary SPF timeout's likely the reason the emails were not rejected and they fixed the DNS timeout issues for this specific environment. What that basically meant was probably one in every 10 emails we were sending were hitting this timeout error and so it was really easy to exploit this bug. They basically fixed that timeout part.

So theoretically, if we still managed to somehow induce a DNS timeout issue, we'd probably still exploit this thing. Uh, it just makes it a lot harder. Um they also suggested to build some custom rules to quarantine any temp error emails that come through um just to sort of stop them being exploitable. Um if you are blue teaming um check the logs um especially if you see like a high spike in temp error sort of timeout things. Um you can consider doing what Microsoft said and having manual rules to quarantine temp errors. this won't be a useful approach if you have a high number of temp errors because then you're going to sort of blacklist or

deny a whole bunch of legitimate emails. Um it really emphasizes that sort of multi-layered approach to security. So fishing awareness training, not relying on a single technical control to completely protect you. Um and you should hopefully be able to disable direct send uh soon. So Microsoft have basically figured out that yes, most customers don't need this functionality and they don't. it's kind of legacy but sort of got merged into the cloud. Um they're working on ways to disable it. Um the they published a sort of update to this in I think around June basically saying that around September um this particular feature would be ready to be sort of pushed out more globally available. Um it is in preview still at

the moment. Um as of the last update I think I checked four or five days ago. Um it's still not um actually in general release or general availability. Um so I suppose watch this space. Um, you can considering enabling it now because it is available. Um, if you go just looking at random Reddit posts though, um, there's a whole bunch of people basically screaming into the void saying, "We switched this thing on and it broke a whole bunch of stuff that it shouldn't have." Um, so hey, you know, your mess might vary. Give it a shot. Um, if you're red teaming, this is the attacker's perspective. Um, it can be a really awesome bug to exploit. um you

can cut through a whole bunch of sort of fishing controls or fishing awareness. Um if you manage to find an environment that is vulnerable to this um talking about that specific sort of edge case, uh it's not as useful from a red teamer's perspective. Um it's really hard to confirm exploitability for this DNS sort of temp timeout error thing. Um it's really hard to exploit it consistently on demand. You could theoretically try and maybe doss your client's DNS, but I wouldn't recommend doing that unless you want an unhappy client. Um, it's also going to be very environment specific, so they need to have these DNS timeout errors for this to be exploitable. You can try maybe

shortgunning things. Um, so if you spam enough people, maybe one or two of those emails you send will hit this DNS timeout. Um, on the plus side, um, getting sort of outbound port 25 is about the only thing you need to be able to exploit this bug, um, if it's actually exploitable. Um, if you're purple teaming, um, don't underestimate synchronous communication. If I hadn't have had that communication stream with the blue team to be able to dive into these logs, to be able to say, "Hey, we've done this. What do you see?" There is no way I would have figured out what this bug was. Absolutely none. Um, if you're colorlind teaming, um, maybe just do all of these things or none of

these things. Take your pick. Cool. Um, I am finished. That is the end of my talk. If anyone has any questions,

Oh yep.

>> What does Microsoft check the email again with the DNS update? >> Um, not at that level. Um, it will do certain checks where if it finds a malicious email from a certain source, it'll sort of backdate that and say, "Look, we now know this is probably a bit dodgy. We better go out do some additional checking, additional controls." But not at that specific app. Not that I'm aware of. No. >> Cool. >> Did you notice any difference between the hosting of your third party service? >> Um, no. No. There was something about this client's specific SPF records that they could tweak. They could make some adjustments around timeouts that did improve things, but that wouldn't have

been sort of related to where their SPF records were. Yeah. >> Any other questions? Having worked with Will many years ago, it's good to see a sense of hum and his names haven't changed. I'll never present here again. >> That's all. Good. Cheers. Ah, thank you. >> Prestigious CL. >> Right. Uh, give us two seconds. We will just swap laptops.