How to Strengthen M365 Exchange Online Configurations with Kevin Klingbile
Good morning, good evening, or good afternoon, and welcome to today's anticast with Kevin Klingbile, how to strengthen m three sixty five exchange online configurations. I'm very excited to get started today with you, Kevin. I'm gonna head to the backstage so you can go ahead and get kicked off. When there's about ten minutes or so left, we'll come back and go over some questions if there is any. And, yeah, that's it.
Zach Hill:Good luck and have fun.
Kevin Klingbile:Thank you. Yeah. Good luck. Good luck. We'll need a lot of luck.
Kevin Klingbile:So the the name came out a bit long, how to strengthen m three sixty five exchange online configurations. And really, what I was trying to focus on is a couple things within exchange online, and, I mean, we'll go through those. And we're gonna look at it from both a defender's perspective and an attacker's perspective. So the the fortunate thing that I always found in defensive type classes is you still have to cover the offense. So even though it's not strictly offense, you still gotta know what is going on with those.
Kevin Klingbile:So when we're looking at configurations in Exchange Online, some of the security considerations we might have would be like mail flow rules, transport rules, direct send, which has been a massive one. I mean, we've got people at BHIS that have covered this in-depth in blogs and kind of all over the place. So love that. And then I I mentioned here sending directly, like just no configuration because we actually run-in instances where there is no configuration at all in Exchange Online. And that's not necessarily intentional.
Kevin Klingbile:So there's a couple reasons why that might happen. Now, I did do an asterisk on the sum here because there's obviously other things. In fact, if if we look, there was just an article put out by Microsoft a couple days ago here, I wanna say a week ago, where the legacy authentication, the basic auth is is getting the hang around for even longer. It was supposed to be end of life a couple years ago, and it just got another another extension. And that that's one of the things that we common commonly see, especially with cloud.
Kevin Klingbile:And as it relates to Exchange Online is, you know, that that legacy authentication is still around, still exists. You know, if you're wondering Exchange Online, where are we? I haven't actually worked in the cloud before. Maybe we're looking at doing this, but we haven't done anything. There is a separate administration site for Exchange Online.
Kevin Klingbile:So everything that we're really looking at here in this cast is gonna be through the admin.exchange.microsoft.com. Now, I don't have a demo of this right here, but if you're not licensed to be an admin in Exchange and you go to this site, the page will continually reload over and over and over again, least last time I tried with a unlicensed user. It just means, like, your account doesn't have permission to come here, so the page will continually reload until you close this browser tab, or the browser crashes because you opened in another tab, forgot about it, not speaking from experience, and it just kind of ruins everything for you. So that's where we're gonna be living in. Besides the basic auth, I mean, we we do have things like forwarding rules.
Kevin Klingbile:Right? Admins can put in forwarding rules and in Exchange Online specifically. Users kind of in their inboxes, we're not getting to that user phase. We're sticking in in Exchange Online and what what admins have. Those transport rules as they relate to to third party, you know, providers, I'm thinking like Proofpoint, Barracuda, whoever third party spam providers, and we'll dig into some of those examples as well.
Kevin Klingbile:So when we get to the exchange admin center, we can actually drop down to mail flow rules, and there's lots of different options here for mail rules. We have things like create a new rule or apply disclaimers. We're really living around these for for purposes of what we talk about here. Just kind of these two, but there's a lot of other rules you could add in there as well. We also have connectors for the transport connectors themselves as well.
Kevin Klingbile:So Now, requirements. So if we look at a mail flow rule, there's gonna be two items that are required and then optional. And before I really even jump into mail rules, I should probably discuss the reason why we're gonna dive deep into mail flow rules is and I kinda mentioned this on the pre show, But I I I'm constantly doing different checks for companies where I'm looking at their Azure configuration, their m three sixty five configuration, whatever it might be. And I'm even in companies that have matured pretty far, they've maybe lived in this environment for five, six years. They still tend to have very, very poor mail rules in Exchange Online configuration.
Kevin Klingbile:Outside of maybe the third party spam protection, that's locked down. Maybe they've disabled Direct Send. That's great. That's disabled, which we'll cover later. But if we actually go in and we look at these mail flow rules, we tend to find issues.
Kevin Klingbile:And that's really why I've I've delved into this topic along with Direxa, which is probably the most abundantly identified issue in environments because we don't even have to have access to Azure to send a test message or to Exchange, to send a test message and say, hey. Is this open? Are you allowing direct send in your environment? So that's kinda why we're here. Now, as far as the rule requirements, we're gonna cover kinda what a rule is, how they can be configured, and move on from there.
Kevin Klingbile:So the I say two things. We're probably there's actually three. There is a name. So technically, you have to have a name. But really, it's this apply this rule if.
Kevin Klingbile:And this is gonna be one or more conditions. Now, if we were in the console, we click this drop down, there's a very long list. There there's easily, you know well, realistically, with some of these, there's an infinite number of ways you could clear this because some of these could be free form text. But as far as the drop downs go, there's there's, you know, thousands of ways to configure this. Right?
Kevin Klingbile:Besides this one being required, we can also add more conditions. So we could add apply this rule if multiple conditions exist. Then we could say, the following. We could do one instance where apply this rule if I've got an example coming up here. In the example, we're gonna say, apply this rule if the message is received from outside the organization.
Kevin Klingbile:So if from outside of our organization, a message is coming in, this rule is going to trigger and go on and do the following, do something with it. The the common thing we might see here is we will prepend to the subject an external message. Right? So we get the little bracket, external, close bracket, something like that. Some of the other common ones we'll see is from a a a, you know, mail routing, mail flow perspective.
Kevin Klingbile:Some some some of the bad ones we may see is, hey, if this message came from at some third party domain, allow this message through. Right? That might be a bad example, but something that we we do see. So we do the following might be just allow it, it might be check an IP address, did it come from this source, It might be you know, it is this free form text in the message at all? Lots of different conditions there.
Kevin Klingbile:And then, optionally, we have this except if. Now, this except if is gonna be some exception to the rule. And as we know in kind of anything security related, the exceptions are kind of kind of where we find a lot of the the dirt, right, in the company potentially. If we go through the acceptives, and if that acceptive is not built in a very, very constrained way, that can open up this rule to not apply or to be over applied or do something that we wouldn't want it to necessarily do in in a production environment. So if you were to go into a change of line, you just hit create new rule.
Kevin Klingbile:In fact, I'll go back one slide here. So if we come in here, we just do this create new rule right here. The very first screen when we get that create new rule is we're gonna exceed this with these set rule conditions, and this is just the the first screen that we're we loaded. This is a snippet. It's a little bit longer than this.
Kevin Klingbile:We also have rule settings. So we can see conditions here, and then you can also see settings kind of to the the right hand side. I mean, I've got a rule name. In this case, I'm just I'm looking at the rule that's named test. So these don't really when I was first getting into Exchange Online and I started going through a bunch of these configurations for environments, it took a minute to realize that these are actually two different buttons we have to click here.
Kevin Klingbile:Right? Conditions is the default loaded, so by default, we see conditions. And then it's just kind of a free form settings. So if conditions are selected, the little blue line is underneath conditions. Otherwise, we've got the the settings.
Kevin Klingbile:Now, from a mail flow rule perspective, there is a priority queue. So we start with priority zero, and it works down the list. Now, if we had, say, 20 different mail flow rules in this in this environment, we're gonna start at priority zero and work our way down. There is an option to stop processing more rules on that. So maybe we apply an external header, and somebody accidentally clicked the stop processing more rules.
Kevin Klingbile:The only rule that will ever be processed for anything coming from outside in the the scenario that we've got set up here is gonna be add this external header and kick that message off. We don't care about anything else. Could that be valid? It certainly could be valid in an in an organization. Doesn't make it secure or something that you should be doing, but it is technically a valid configuration, just not the best configuration, probably.
Kevin Klingbile:So along with that, we do have enforce for rule mode in in this example. You can, you know, enable a rule without fully being enforced. You could do, like, test with policy tips or test without policy tips. It's just kind of a a rule builder here. Fortunately, we do have activation and deactivation times.
Kevin Klingbile:And I've only seen activation and deactivation rules used in probably, you know, two or three taps. So this is an underutilized feature. One company I saw used it. It was very great idea. They actually ended up using it for their third party phishing provider.
Kevin Klingbile:So anytime the internal team was sending, you know, phishing messages to users, the internal security team this is my assumption here, but what would make sense. The internal team had to reach out to the admins to say, hey. We're sending phishing from this date to this date. Allow our phishing domain. Allow our phishing IP and allow this to go through.
Kevin Klingbile:It actually would end up deactivating that rule when that engagement was over, which would look great use, I thought, for that company to have inside of their mail rules. But outside of that, underutilized feature is probably this one. The stop processing mail rules, we we do see that relatively common. In some cases, it makes sense where it's where it's laid out. Like, the message where, you know, came from internal, and we just wanted to add something because it was an internal communication going going out somewhere, and they couldn't check done.
Kevin Klingbile:Right? Maybe that was like applying the the legal footer to that message, for example, or something. But do do be careful with that that stop processing more rules. Flow, especially considering the priority, you know. Have we processed enough rules before this one that we're gonna stop processing and we're covered, or the additional rules should should also apply there?
Kevin Klingbile:We did mention rule flow. I see CJ Poppy and Sammy, we got a question.
CJ Cox:Yeah, man. I don't know if Blueshore said, any advice on on microsoft.com aliases? No. That is On
Kevin Klingbile:the on the aliases? Not directly. No. So with the aliases themselves, you could block them. You you could just flat out block them, but the issue becomes and I kinda get to this a little bit later.
Kevin Klingbile:If you don't configure anything, those can be used to bypass, like, third party protections if those third party protections aren't set up properly. That'd be the bit of advice right now. But without more context, I'm not sure specifically. Cool.
CJ Cox:Yeah. And the monkey j said, currently struggling with mail flow roles where an email is redirected to another mailbox is forwarded even if Microsoft classifies it as spam and or quarantines. Any suggestions on stopping that?
Kevin Klingbile:No. If it's classified as spam and it's redirecting so there are a couple there there are a couple, like, nuances here we can look at. So depending on the client that's being used, Microsoft will actually respond differently. So, like, if if the client's using a web version verse of the Exchange client you know, reader versus using Outlook versus using actually, like, an on prem exchange. If they're connecting to on prem exchange, they've received that mail from 365 or from Exchange Online versus connecting directly to Exchange Online.
Kevin Klingbile:All of those can provide different scenarios. And this this drift that we see kind of creates a lot of interesting scenarios for attackers, I would say, because there are some scenarios where I've sent a direct send message into an organization. And within Outlook, they get this little warning banner, warning, we can't validate the authenticity of this message. And as you you're shaking your head because you've probably seen that before, CJ. Right?
Kevin Klingbile:I've Where if if you're actually in a in connected to an on prem exchange that's received that message from the cloud, you don't get that warning banner, that little and and that's built into the client itself. So I didn't have this planned on the slides, but we we used to do this thing at FHIS where we would we would attach some HTML code to a direct send message when we sent it. So we'd remove, like, the the warning banners that that you would get within the organization. Right? And the way Exchange Microsoft solved that was they changed it to an application level.
Kevin Klingbile:Like, the application itself is the warning. It's not HTML based on the email for that warning anymore. So kinda like a a legacy attack that was interesting at the time, but isn't valid now. So I would say look at the specific location where that's coming from, and is it to all like, from the standpoint of is it all users are getting the exact same scenario, or is it based on the type of client or browser or whatever they're accessing the messages with? Excellent.
Kevin Klingbile:Thanks. Yeah. Alright. So rule flow, and we talked a little bit about this, but alright. So we we started top priority zero, work our way down through the last rule.
Kevin Klingbile:Rules can be disabled. As far as rule count and how flow works and processing wise, probably the most rules I've ever seen in an organization was right around, like, three or 400, which is absurd in in my view. You the they're kind of going beyond probably what you should with nail fill rules. On average, most companies have somewhere around 20, maybe 30. 20 to 30 rules would be relatively common.
Kevin Klingbile:A little bit past that would be up to 50. Anytime I see over 50, it is extremely uncommon, and and even 50 seems a a touch high. But some of those rules can be disabled. Right? So when you're looking at mail flow rules, if it's disabled, you could just skip past it.
Kevin Klingbile:Like, let's just say you're a internal auditor or a sys admin. This mail flow rule is disabled. It's not actually being used. You could skip past that because it's not being flow in the workflow, but you could also ask yourself, is this a cleanup that needs to be done? Why why is this rule disabled?
Kevin Klingbile:If this rule were to become enabled, would that have an adverse effect on what we see with our within our environment? I would say it's not uncommon to see, you know, disabled rules in the rule set either, especially those rules that disabled automatically. Again, that hygiene cleanup piece just never tends to occur from the environments that I've looked at. So rules will be applied in order and are additive. Meaning, let's just say we we hit that priority zero rule.
Kevin Klingbile:Priority zero was, hey. We're if the message received from external, we're gonna add that bracket, you know, external message header. And then rule priority one might be, hey. If the message also came from external, let's apply a warning banner at the top of the message saying, warning, this message came from outside of our organization. Please consider who it's coming from before you click on links or something, whatever that, you know, common header is.
Kevin Klingbile:And then maybe there's a footer or something else. Maybe you add x headers. Maybe you you know, as we're going through the rule flow, could be all kinds of things that that happen in there. So in in the serial user, we applied an external header, and we applied a warning banner, and then we continue working down that rule flow. I have seen cases in companies where within that rule flow, that external header didn't get applied until maybe, like, the fifth or sixth or seventh rule.
Kevin Klingbile:So if you met any of the conditions above that, you could actually bypass those rule headers or those, you know, rule conditions because at at that point, it was above that, and it would stop processing more rules. So consider where those those exist as it relates to things that should be attaching to messages. Right? One case where, hey, bypassing all remaining rules absolutely makes sense is a block. We're gonna block whatever this is?
Kevin Klingbile:Yeah. Stop processing rules. There's no point in continuing continuing on. Right. Creating good rules.
Kevin Klingbile:Just just a couple high level examples. Now, Microsoft has documentation on rules, how you can configure rules, what Microsoft considers good ways to to apply these rules. Right? This documentation exists, so we're not gonna go into depth on the specifics of those. I'm just gonna give examples that I have seen in practice that companies have been using that have worked well for for them, and from me coming in as a a third party looking at those rules, you know, made sense.
Kevin Klingbile:Right? Anytime I see rules that are very, specific, so it's not just an IP address, not just a domain name. It's a domain name with an IP address, meaning there's been thought that came in where they know the mail servers for that specific domain, and they know the IP that that should be coming from. If it doesn't match that, it doesn't go through. I know we haven't covered Direct Send yet, but if I were to spoof a domain, and I'm coming from the wrong IP address because direct send I I don't control necessarily the IP address that the rule would match, it's gonna get blocked.
Kevin Klingbile:Right? Then we can go and look at I've seen things with IP address and x headers. This is extremely common with phishing products like KnowBe4, Proofpoint, some of those third party phishing scenarios, vendors. Extremely common. In fact, their documentation and we'll cover this in a couple slides here.
Kevin Klingbile:But their documentation will say, include the IPs, include this X header, and go on from there. Right? Where we really see the issues is where we get generic items, and and generic being only one condition must exist for this rule to apply. Something like if you send a message to a specific user, this happens. Well, anytime any message goes to that specific user, you might be bypassing things, missing things, doing something else.
Kevin Klingbile:Or in the scenario that you said, CJ, hey, if this anytime this message goes to this specific box, we've seen scenarios where the like, the specific mail group has been bypassing spam filters. Like, some of those scenarios I can think of that kind of makes sense but don't is, like, investor relations boards. Right? So anytime that there's, like, an investor relations, they want all of those messages. You should filter on spam, but investor relations is concerned if we're missing messages coming from our stockholders or people interested in, you know, investing in our company, that can be a a big deal.
Kevin Klingbile:Those can be abused at that point by an attacker to say, let's you know, maybe in your head, you're an attacker. You're thinking, oh, I should try, you know, sending additional spam to investor relations because they might be bypassed. Some of those scenarios or sales I've seen in other companies. Right? So those kinds of things can happen as well with that generic.
Kevin Klingbile:Now, along with that generic, like I just said, don't reduce the spam, the SCL level, and only with that one point of identification. So if a message is going to investor relations, then a rule could say, if a message is going to investor relations, then we apply the spam rule of the SCL, set it to level minus one, which minus one means bypass. Right? So let's bypass the the spam protections because this message is going through to investor relations. Like, never do that on that one point of of, you know, the genericness, we'll say.
Kevin Klingbile:And then follow the logic flow. Right? So when I'm going into a client and I look at these rules, I'm literally getting down into the logic. In my head, imagine, okay, rule or a a message is sent to Exchange. It hits your priority zero, doesn't do anything for it.
Kevin Klingbile:And and as I go through those rule sets, I'm imagining a message flowing through. And when I see that, you know, oh, if it goes to investor relations, allow it. And set SCL to minus one. Well, that's a condition now where it's, okay, this message now has no spam filters applied to it. That's not to say that that's a permanent condition.
Kevin Klingbile:We could go further down the rules, let's see where maybe for some sort of fuzzy logic, they they've sent it that way, and now it's a different lower. Not necessarily a good configuration, but it's a configuration that could be applied. You know, so consider that whole logic flow tree of of going down through the entire area, and then the the edge cases. We we've seen some very interesting very interesting configurations of these rules, and and part of that can be, if you've been in Azure or Exchange Online for, like, six years, six years ago, back in 2020, and I'm I'm actually thinking seven years ago now, I'm getting old, back in in 2019, the the flow rules were not as granular or complex as they are today. So the flow rules back in in 2019 could be configured very differently.
Kevin Klingbile:And it's not uncommon for those organizations that have been in here for quite a while to have a lot of old rules that have just never been, you know, reset up, never been modified from their original 2019 states. So one one additional item there to think of. The the other thing that I like to call out, especially if we're doing a test on a client and they have some some rules that are are, you know, off or what we wouldn't think is, you know, you may want to have multiple admins whores and or security personnel that could include audit personnel, maybe change control, if you were thinking that way, to actually review mail rules before they go into force. Definitely a a consideration there.
CJ Cox:Good to have. Yeah. Mark asked, if you have 300 to 400 rules, is that gonna cause a performance hit, or is there some limit, or does Microsoft publicize that? Like, don't do more than this, or you will break it.
Kevin Klingbile:Yeah. So if if you're in the edge scenario, there's there's no, like, hard limit that I've seen Microsoft publish. There could be one out there. Just haven't read it. I've seen clients with over 400, right, or at least 300 to 400.
Kevin Klingbile:The biggest thing, like, was mentioned, I I think you said Mark. Right? That Mark mentioned was the overhead. So, yes, there there can be overhead in that. And if if you're in in this scenario where it's taking, you know, a minute or two to receive a message, it could be caused by that rule overhead.
Kevin Klingbile:And I I haven't sat down and timed it out. Like, if we if we create a really, really bad rule, does that perform slowly compared to to something else? I haven't tested that. So we've been using the example of an external header. So let's just look at how that would would appear inside of a a new mail rule, and and if we're in here looking at the rules, how that looks.
Kevin Klingbile:So in this case, I'm just gonna name this rule external header. You can see it's called external header. We're going to apply this rule if the sender is external or internal. Now when I pick this condition, it is you know, the sender is external or internal. We actually there's gonna be like a little a drop down menu, which isn't on here, but you see it when you pick it.
Kevin Klingbile:And I picked not in the organization for that scenario. So in this case, the sender is not in our organization. Right. We can do the following, like pre pen subject. And in this case, we're gonna pre pen the specified prefix of external, the bracket, all caps, external.
Kevin Klingbile:Now, that's if we're building the rule. So if we're building the rule, we may see something like that. Now, if we actually step out of building the rule, and we're in the screen where we're looking at all the different rules, and we just click on the rule itself, and we scroll down, we say, what's this rule doing? It's actually going to look like this on the right here. Apply this rule if it's received from outside the organization.
Kevin Klingbile:So we actually have, like, differences in language from what we would select if we're building the rule to what we're gonna read inside of the actual text of the rule description. So it could make sense if you're reading that rule description and you're used to building rules. Right? That might make sense to you. But it could also be the case that you're reading this and it's a little bit confusing.
Kevin Klingbile:Like, maybe you don't know what this rule is doing, or you're building the rule and you thought it did x, and then you go and you look at, you know, the actual rule description, and it does y. So there is kind of a a converter here. Now, if you open up the rule, you're looking at that rule description. You can hit, like, edit rule, and you can see the original kind of rule text of if this rule applies to this. Right?
Kevin Klingbile:What's also missing from this screenshot on the right here is I only have apply this rule if and do the following. I don't have the except if. If there's exceptions, they will show at this screen when you just click on that rule at first. Right? But we can see by by looking at the left here, let's do the following prepend, specify sub prefix, and external.
Kevin Klingbile:Under the do the following, we also see stop processing more rules. Right? And that's that's a different view from where it is the description to where it is inside of the GUI when we're clicking through and actually configuring a mail rule. So we do get to see within that description, are we processing the like, if if it doesn't say stop processing, we're just moving on down the flow versus stop processing more rules. So there can be differences in that language.
Kevin Klingbile:So if you're confused, look at the other. Right? Definitely between between the two is it gives you a a more full picture. So those conditions and descriptions can be can look different. Now, I applied this this rule to a a test tenant.
Kevin Klingbile:Right? And I have Lily out here. Lily is Lily Johnson is in a Gmail account, and Lily sends this this message. The subject, will you be at the webcast? And it says, it starts in another six days.
Kevin Klingbile:It's getting close. Good. And then Adele, over here, will see inside of her Outlook, the external has been added to that. Right? So we've got that external essentially added to the subject there.
Kevin Klingbile:Now if Adele replies, yep, I plan to be there. So Adele replies with this back to to Lily, You know, we can see in, hey, the subject had an external. So from from Lily's perspective, Lily is aware when that message came through and they got the response that there was an external header added to it. This can be helpful for recon if you're able to have a message that that organization, you know, would get. You can sometimes use that.
Kevin Klingbile:So let's keep playing through this scenario here. Now, Billy replies, hey, what time does that webinar start? I don't wanna miss it. And Adele suddenly gets to two external headers. So we get this external reply, external.
Kevin Klingbile:Right? Can you run into these scenarios with mail flow rules where it's doing something you don't want it to do. In fact, this happens with not just the headers. This can happen with the, you know, hey, this message was received from an outside party. That's not such a big deal because at the top of the message, it's just in every single reply, it's, you know, lower in the message.
Kevin Klingbile:But the footer. So it it's kinda funny. Right? You'll you'll be emailing a client back and forth or some, you know, coworker back and forth all day long, and you get, like, 50 illegal notices at the bottom of that message. This message is only intended for the, you know, participants included on this whatever email, forgetting all of those footers over and over and over again.
Kevin Klingbile:So this can be problematic from a standpoint of somebody who has configured a mail flow rule, and and you might be thinking to your head, hey, Kevin, you shouldn't be doing a mail flow rule. We'll get to that. So from a mail flow rule perspective, you're getting these multiple external external external external. Okay. There is a solution to this, because there has to be.
Kevin Klingbile:Right? You probably don't see that. And Microsoft has a solution, and I say sort of. So Microsoft is gonna say this should probably be a disclaimer, not a mail flow rule. And if you actually were to configure this as a disclaimer and the and the testing I've done, it doesn't do the repeating external external external headers, right, if it's a disclaimer.
Kevin Klingbile:But if it's configured as a mail flow rule, it does do the repeat, repeat, repeat. So you might have an admin who doesn't know necessarily that you can add a disclaimer to a message. It doesn't have to be a mail flow rule. It still is, like, in the mail float. It's it's considered a mail float rule, but it's applied differently.
Kevin Klingbile:Right? And they go to Microsoft's documentation. They say, I keep getting these repeated headers or these repeated footers or whatever it might be. How do I solve this? And Microsoft has this excellent article out here for disclaimers, signatures, footers, or headers.
Kevin Klingbile:You should add an except if. And you should say, add an exception that prevents multiple disclaimers, trigger word, there are disclaimers, right, from being added in an email conversation. Configure the following settings. Select the subject or body if it matches these text patterns, these phrases, whatever. Disclaimer adds, select save, and next when you finish.
Kevin Klingbile:Let let's see what this looks like. So I've configured a mail rule to do this external header over and over and over again. And if I go back to and I just have this in here. You can see the create rule versus apply disclaimer is is on Exchange admin center here. So if I add the exceptif and I say the subject or body includes.
Kevin Klingbile:So this is exactly what Microsoft told me to do for disclaimers. K? But this is a, you know, standard mail flow rule. And I say, if the subject or body includes any of these words external. Now, you might think, well, you just said subject or body.
Kevin Klingbile:We're only looking at subject here, not body. But the the little drop down doesn't let me pick subject, body. It picks subject or body. K? This is not an uncommon misconfiguration to see.
Kevin Klingbile:This is something that, you know, I see not all the time, but occasionally. So if it includes these words external, we're going to exclude adding that external header. And now what happens is when Lily sends a message to Adele, this message just says, does this bypass your subject message? And there's no external header added to this message because the mail flow logically said, except if the subject or body contains external. So inside of the body itself, Lily said, hey, by the way, you know, I'll make this visible, but we could make this invisible and throws in a little external message right there.
Kevin Klingbile:Now, we can make this invisible if we, for example, included this HTML text within that HTML code within that message, that journal would now be hidden. You could use your mouse. You could highlight it, and it looked blue, but it's now hidden within that message. K? And this can actually apply to both the warning banners at the top and to the subject.
Kevin Klingbile:Right? So if I get a hold of your your little warning banner that you use, warning, this is an external message. You know, please consider links that you click on this message. When you go through here and I get a capture of that, I might add your subject, you know, actual banner inside the body, and then your warning banner inside the body, and it actually bypasses both of those scenarios where it's an outside message. So it's it's possible.
Kevin Klingbile:Again, it depends on the configuration. In fact, one of the most configurable places that we have in m three sixty five is exchange rules, and obviously conditional access policies is a massive whole separate other body where we have lots of configuration where we can do. Right? Exchange Online is definitely up there in the amount of configuration that could be changed within there. So one example here of how issue that says, do we add this except if?
Kevin Klingbile:Yes. Microsoft talking about a disclaimer, but maybe if it's configured as a a standard mail rule, not a disclaimer or something else. Here's one scenario where it bypasses. If we look at other common rule issues here, let's just cover a lot of the different bypasses that we find. So some of them were going to be too specific user.
Kevin Klingbile:And I've kind of mentioned this, like, maybe to that, you know, investor relations. The the attacker doesn't have knowledge of what this is, but the attacker can kind of, you know, blast things. And that's why sometimes, hey, this message was detected as spam on all 50 users he sent it to, except this, like, one user or these two users, it made it through their inbox. There's kinda two scenarios I can think of where that happens. The first one is Microsoft's, you know, spam assuming we're using Microsoft Spam Protection Defender and stuff.
Kevin Klingbile:Microsoft has not detected that as being malicious yet. So the first two or three or four messages might get through, and then the remaining are blocked, and then it can opt you to go in and rip out all the user's inbox. Right? The other one is there was some sort of a mail rule set up to allow messages to that user with the spam SCL set to minus one that we kinda covered earlier. So to specific user is is a common rule issue that we find.
Kevin Klingbile:And it doesn't have to be user. Right? So think think of a scenario where you have a specific workflow, and messages that are sent to maybe a ticketing inbox are going to bypass a couple rules because it's not intended to be a mailbox. It actually gets sent to a ticket system. So if it's getting sent to a ticket system, we can abuse that flow rule to send to the ticket system.
Kevin Klingbile:And if we actually add, like, direct send on top of that, it gets even worse. We could, you know, maybe spoof a message that makes it look like user a is talking to user b within the the other things as the the next line says, let me send let me put in a ticket for this. And then you send that spoof flow into the ticket system that makes a whole, like, line chat history of, you know, communication between internal users. And, yes, this person needs these permissions, and then the ticket flow actually gets processed to navigate that end. That could be done from an external perspective.
Kevin Klingbile:It's just like only to specific user. We've seen scenarios where that can happen as well. So even stepping beyond just two users, what about two ticket flows to Jira flows to other flows? Right? From user is is a fairly significant one.
Kevin Klingbile:Now, we don't have a way as an attacker to look at these mail rules. Right? In fact, even as a low privileged user, you can't go in and look at Exchange Mailflow rules. So you're not worried about this, you know, support users account getting compromised. Now they can go look at my mail rules.
Kevin Klingbile:These are these are hidden. Right? These are behind some sort of block that normal users can't see. So from this perspective, we get credentials to go into the environment and look at these, which is why we've seen so many of these. Right?
Kevin Klingbile:But what we can tell is there's certainly patterns that occur between companies. And so the from user patterns that we see are commonly things like help desk support or no reply are commonly things that bypass mail flow rules to some degree, whether that be handlers that get applied, footers that get applied, spam levels that get applied, tends to be these types of addresses that, you know, whatever the company name is. K? Others that we see that are commonly within rule sets that just bypass everything is gonna be a a maybe familiar one here. No reply email dot teams dot Microsoft dot com.
Kevin Klingbile:So that's the I have my Teams closed. People are sending me messages. I mentioned in chats, whatever occurs. And I get a Microsoft email that says, you've missed messages from your your coworkers. Right?
Kevin Klingbile:And it it goes through and it drops down that list of messages that I've I've missed. We've seen cases frequently more than others where that is just flat out allowed through to bypass the spam confidence level. And then we've seen things like support@companyname.elastic.net or notification at Slack, the same as the noreply@email.teams, but with Slack. Right? So these kinds of common from users are repeated over and over and over again and make great targets for phishing scenarios.
Kevin Klingbile:Right? Phishing users. Now, you might be thinking, that's great and all, but you don't really necessarily have a way to spoof messages from those accounts, and and you would be correct. In these scenarios where these these bypasses occur from specific user, that's taking in direct send into account, and we'll we'll look at direct send next year. But if we take mail flow rules and we additionally apply DirectSend being an issue within the environment, it makes DirectSend that much worse in the environment.
Kevin Klingbile:K? Now some of the other things are known third party phishing sites. So maybe I go out and I I think I have a an example slide, but now I've worked on the slides. Think I put one in. But we might go on to, like, you know, know before what are all the sites know before you use?
Kevin Klingbile:What are all the sites Proofpoint use? What are all the sites that these third party phishing companies use and the domains that they own? And if we have ability to use direct send, we could also use those third party sites potentially with that as well. I mean, that kinda comes down to there's some very specific rules that have to be met for that to be misconfigured, and we'll we'll cover what those are and and why we see those those issues coming up here. From domain, so subsidiaries, third parties, etcetera, we've we've seen those bypassed.
Kevin Klingbile:Some exempt some some really interesting ones here are actually x header values. So if certain x header values are configured on a message, we might be allowed to to bypass that. Right? For warning banners and disclaimers, we we did have that previous example where we can take the the headers, the footers, all of that, add them into a message with hidden text, hidden HTML, send it off to a company, and see if that bypasses those filters. Other things we've seen is, like, the subject contains.
Kevin Klingbile:So subject contains Jira. They didn't want any tickets to be blocked, so if it contained that, it was allowed to bypass spam levels. Right? Bad rule configuration, but an issue that we've seen. So consider those common common phrases that might be used within the company, within projects, within external third party sites they might be using, you know, maybe Box, Dropbox, Jira, whatever those things might be that are commonly out there.
Kevin Klingbile:Definitely common common issues that we see. And and here's the slide I was talking about with the phishing product. So I just went out and I when I was getting ready for this about a week ago, I googled really quick, hey, What are some phishing product domains? Right? And this was an example of a potential proof point domains that that there was essentially a a third party site of proof point who uses proof point to do phishing on their their clients.
Kevin Klingbile:And they said, hey. If you're a client of ours using our product, make sure you have these Proofpoint domains allowed. Right? So if we had access to Direct Send, we could potentially use this list of Proofpoint domains, and this is just a snippet. There were, you know, like a 100 domains in there that we might be able to use with Direct Send.
Kevin Klingbile:And that's provided they're blocking other things with Direct Send, and we need to hit a rule that is actually allowed through. That would be one thing I would look at. Noble four examples, we got a couple there as well. And then the common common axe header bypass examples that we've got, axe fish test, Salesforce, etcetera. These are just the common headers.
Kevin Klingbile:I'll leave these here kind of for your your own knowledge on that. And we'll dig into one of them. So I I'm I'm not picking on no before. I have no dog know, bone in the fight. Right?
Kevin Klingbile:But if you go off to their site, and you go to how do I configure m three sixty five? They they have a really great guide, and it's configuring it how it should be configured. But if I'm an admin and I just hit their guide, I might just be looking at the screenshots, because let's face it, we're all lazy. Part of the the requirement to be to be to be an admin. Right?
Kevin Klingbile:Gotta be lazy. And if I look at this screenshot, it says x fish test header, message includes no before. And that's it. If an admin goes through and they do this and they ignore, allow these IPs, allow this everything else, this rule will now, just by adding an xFist test header, bypass the rule filters. And we have seen this in production multiple times.
Kevin Klingbile:Right? So do do be careful on the configuration of that itself. Direct send. I'm not gonna dig into direct send too much. There are blogs out here that we have on direct send.
Kevin Klingbile:So these are Steve's blogs out here that I have linked to kind of some things with direct send. Essentially, it's an open endpoint with an exchange online that allows attackers to spoof messages. And if we can spoof those messages and we can duplicate those, you know, from fields to fields, etcetera, it becomes a lot more powerful to abuse or your your mail flow rules suddenly become that much worse with only one designation. And I will warn you if you're testing Direct Send yourself, I commonly use like a a Cloud Shell, so like an Azure Cloud Shell. I'll just pop up in a Cloud Shell and test it.
Kevin Klingbile:If you get this little warning message, you know, error five fifty service unavailable, it means somebody else was using that Cloud Shell IP address, and they've already burnt it. Right? Spam House thinks it's being used for sending spam. That's not a direct indication that, hey, we've blocked DirectSend, and it doesn't work because we got this service unavailable. You may actually have to try to rotate a few different cloud shells to make sure you're doing a valid test against the organization, assuming you're authorized, right, to do that.
Kevin Klingbile:Now where DirectSend comes into play and doesn't come into play as far as mail flow rules are concerned. Right? So we've got this there's several spoofing, minimal issues where if DirectSend is in play, it's bad. That could be from user, known third party phishing sites, because now we can spoof those known third party phishing sites, or from domains. DirectSend can do those.
Kevin Klingbile:Now we don't require DirectSend to abuse those mail rules, to actually bypass those mail rules if they're to a specific user to if if we include a specific x header value and then those warning banners for the subject's body contains, all of those kinds of things that we described earlier. Right? So scenarios where I have direct send disabled, this doesn't matter to me because he guessed with messages, this is where we can hit that. With direct send, if you're testing direct send and it's set up properly, you'll see this bottom message here, the send mail message, mailbox unavailable. There is a partner connector configured that matched the message's recipient domain.
Kevin Klingbile:That means that those transport rules to a third party spam protector is set up properly. K. And every vendor has a guide on how to do this. And if when I go in and read those guides, they do it correctly. K?
Kevin Klingbile:However, I've worked with I've had students and I've worked with people who have said, well, we have the company just do a webinar, set it up, and we find out they actually forgot to put in those transport rules when they set it up. Right? That could be an error of an admin going through the the help guide, they just skipped that accident. Or it could be, you know, they set up, and the vendor forgot to do it. I don't wanna lay any blame on vendors.
Kevin Klingbile:I've just heard rumors from other people hearsay that they went through the vendor to set it up, and and it was missed, a missed step when they were setting that up. There is this getting towards the end here. There is this capability to disable direct send. I have heard numerous clients of ours and numerous people I've worked with through classes that I teach and stuff, that this does not fully work. So there's cases where, yes, you disable direct send, and it works for maybe sending between spoofing, like, your user's domain, So, like, your domain to your domain, like, those are blocked.
Kevin Klingbile:But spoofing third parties tends to not be blocked, or something else, it tends to not work. I've also heard some people say that there's issues with, oh, when they enable this, it it prevents messages from actually going through that they would have expected to work. And I don't have, like, the the back end ability to see how these are all configured, so I don't know the reason behind that. But just a warning, even if you do this, you still need to consider things like DMARC, which is not configured obviously by default in Exchange Online. Right?
Kevin Klingbile:So DMARC we have seen DMARC be a great solution for blocking or preventing that direct send issue. However, again, it does not apply to those mail rule issues that we outlined before. So from that perspective, definitely something you need to to look at and see depending on your your environment. So kind of in in closing, because I there there could be questions here. We'll see.
Kevin Klingbile:But mail rules are typically, you know, latent. We we don't see them updated frequently. They're left behind from years ago. They're not looked through. They're not configured properly.
Kevin Klingbile:One of those high hitting items on on tests that I've I've done, the direct send, we're talking Exchange Online. We gotta talk about direct send. It should should be absolutely disabled. It should and then make sure DMARC is on there. Yeah.
Kevin Klingbile:So kind of in closing, look through those rules till you probably find some stuff you did not did not expect in there. Nice.
CJ Cox:You have a ton of questions. Mean, of course, some people helping us out out there though. Saw some snakes for the hell. And another guy on Discord providing good support. C y says, should we consider placing block rules at the lowest priority first, zero, etcetera, for performance reasons with stop processing more rules option?
Kevin Klingbile:So if there's no reason to have a message go through 50 steps before you're going to do that, that that could make sense. Yeah. But again, because it's at a high priority, none of those following rules are going to apply. So it is, are you allowing something that should be above it, like an external header or something else, or does it make sense to have it at the top? Yeah.
CJ Cox:Finnish chef says, possibly configure warning message if there is white text for parameters for warning prompt inject or blocking rules.
Kevin Klingbile:What was that? Is that just a comment? I don't I wasn't sure. Nice. Nah, we'll skip
CJ Cox:it then. If wants to elaborate, put it in Discord, I'll try to grab it. Nick said, do exchange rules for regex, and there was some commentary around that. But do you have
Kevin Klingbile:a Yeah. Yeah. I I there's I don't know about reject specifically, but there are multiple options besides just the text that you could do. So
CJ Cox:Peoria person says, for Direct Send enabling the reject Direct Send option seems to only restrict unauthenticated spoofing from internal domains.
Kevin Klingbile:Is there a way to prevent spoofing over direct send from third party domains without using a third party service? The the DMARC? DMARC protection on the domain should take care of that. Cool. At least everything we've seen, it it it blocks our it blocks our directs on attempt.
Kevin Klingbile:We we get a little stab when we see that configured. Alright. And and just an idea, like, I'll throw this out there too. Like, direct send, I'm just gonna ballpark it here. That's probably still working in, I would say, 80 to 90% of organizations that we test still have direct send enabled.
Kevin Klingbile:Like, it just flat out works for us to spoof stuff. Microsoft has done a couple things to to work on, like that header I talked about earlier, CJ, that we can't validate that this message comes from the source we expect. And we're starting to see it go into spam a little bit more than it used to, but there's still it's still out there. It's still heavily used. So cool.
CJ Cox:From anonymous attendee, in exchange online, what residual objects, such as hidden rules, tokens, or cache data, could cause endpoint security to flag a previous phishing incident when a user signs in on a new device? Even though no email reappeared and no user action was taken, and what is the best practice for me to that's in the question section if you wanna try to look at these, Kevin.
Kevin Klingbile:Yeah. That one's a little bit longer. I kinda need to see can can you like paste that
Zach Hill:to to Yeah. Put it on the the chat for you.
CJ Cox:There you go. Use the technology. That'd be great.
Kevin Klingbile:Yeah. I I don't have Discord pulled up, unfortunately. I tried to dig around.
CJ Cox:No. These are these are actually on Oh, okay. Our questions or some q and a. Okay.
Zach Hill:Yeah. It should be in the Zoom panelists area there. Chat.
Kevin Klingbile:Hitting the rules, tokens are cached in, it could cause an endpoint security of flag Things will make you go, so so yeah, I'm I'm trying to I'm trying to follow this one. So I can't think of, like, residual objects in Exchange Online itself. Like, hidden rules, like, there there aren't really hidden rules in Exchange. Right? There in Exchange Online, you see what the rules are.
Kevin Klingbile:And and now we're talking endpoint security, so outside of Exchange Online with the the endpoint itself. But we're looking at no user action was taken. And so the the only thing I can think of is maybe they had if we go back, like I think it was a year or two ago, there was an an issue in, specifically, Outlook, where if we sent a malformed message, we could get that user's hash. Right? It would do the connect out to SMB type style exploit, and the user didn't have to interact with it.
Kevin Klingbile:They just had to open the message itself. So if we're looking from that standpoint, yeah, the, you know, agent that's being used to to check email could have its own vulnerabilities. But in Exchange Online itself, there's nothing nothing there that we would do any of that. Now, far as, like, phishing incident, it it really depends because if you're using Defender, like Microsoft's built in protections versus third party, there's cases where third parties aren't configured properly like we talked about before. And if we do a direct send message, it doesn't even go out to the spam filter.
Kevin Klingbile:It just goes directly in. So you might wanna look at, is that configured properly? Is the message running through a third party provider like it should, or is it just dropping directly your sandbox because it's misconfigured on the transport rule side? Some scenarios, get to get I don't know if that quite lines up with the question, but
CJ Cox:Good as we can get. FinishSup sent me some elaboration here nicely. Exchange rule are there exchange rules to block or filter out white on white text emails, or block prompt injections for AI abuse? Are there filtering rules?
Kevin Klingbile:I'm trying to go through the list of ones that I know about. There there certainly could be something in there. Like, I've seen rules that are similar to that. You might be able to say, if email contains HTML that is this, it's certainly something you could look at. But off the top of my head, I'm not not aware of one.
Kevin Klingbile:But I'm not aware of the roughly, you know, a couple 100 different configurations that are are in there for selections. Interesting. Yeah. Lion shares. How about orgs who also change the color of
CJ Cox:the subject to show it as an external email? Now, what about it? I don't know. He's put a coin on. Okay.
Kevin Klingbile:If if if they're if they're injecting it with like HTML probably at that point because they're changing the the color of it. And I didn't hear if that was body or subject. But if if you're changing the color, there's a couple different ways you could do that. Right? It depends if that mail rule is saying, if this text contains bypass.
Kevin Klingbile:I don't care what you're doing with that text, I'm including that text in this bypassing. I see. So it comes down
CJ Cox:to the configuration of the rule itself. Got it. Urtis asks, are there products like Huntress curricula that let on curricula that let you do direct m three sixty five integrations? No need to add potentially exploitable mail flow.
Kevin Klingbile:It's so you're you're gonna be required still to do a transport to a third party if you're if it's if Exchange Online is being used to still sit in that processing flow. So anytime it's used in the process flow now, if if you're not using Exchange Online at all, right, you just everything that you have goes directly out through them, the one consideration becomes that on Microsoft account that was brought up way earlier. Right? If you need to still consider flow for that on Microsoft stuff if it's being used in the environment. And I'm not familiar with that product specifically, the details on on how that works.
Kevin Klingbile:But the flow is the the consideration there. Cool. And there was a question Zach posted in here. What is the best alternative to direct send an SMTP off? HVPE still uses SMTP off, SMTP relatable.
Kevin Klingbile:I'm gonna ask if it's you said printers, so I'm assuming it's inside the organization. You can have those printers bounce off of an internal flow rather than using Exchange Online. Like, when it comes to Direct Send, it's such a large risk. And I I know that's that's a purpose why Direct Send exists, but it's a whole different purpose, like an internal mail server with Direct Send where you have to be internal to send it versus a public Internet facing mail server with Direct Send available to connect to. So I would definitely look at possibly an internal mail server that's doing that relay, maybe that's bouncing and authenticating to your exchange to then go through and send that message.
Kevin Klingbile:Just some thoughts there for for that perspective. And I I've heard from other people who have done that exact scenario. Right? Other students I've thought to have done that.
CJ Cox:Well, that's time, dude. We can stay after hours to look at a couple
Kevin Klingbile:of more
CJ Cox:of these questions.
Zach Hill:Yeah. Yeah. Yeah. Thank you so much, Kevin, for sharing your knowledge with us today. Greatly appreciate it.
Zach Hill:If you all wanna check out more from Kevin, I will put the link to his class that'll be coming up next week at Wild West Hackenfest. If you can't make it in person, you can still sign up virtually and join us from the comfort of your own home if you would like. So check out the link in the Discord. I'll throw it in the Zoom as well. And couple reminders, we have our SOC Summit coming up March 25.
Zach Hill:Grabbing a link for that right now. And today, we also have a CTF. So if you guys aren't aware, every single time you do a webcast or an anti cast now, we have a CTF attached to it. So this week's CTF is ready to go. I'll put the link into the chat.
Zach Hill:And just head over to our CTF page, and there'll be a Monday forum, which will give you a link to our GitHub, so you can download the files and go ahead and tackle that challenge. We'll be giving away a one year subscription to Antisyphon Training on demand, so you get access to the entire platform. And we'll also be giving away one class of your choice. So go ahead and check out the CTF, submit your answers, and hope you win. But for now, we are going to do a few questions.
Zach Hill:So if you guys have any other questions you have for Kevin, we have a couple minutes here where we could ask him. But if you have to leave and depart for the day, we appreciate you being here with us, and hope you have a great day, great week, and we will not be back next week for another webcast because we will be at Wild West Hackenfest. So we hope to see you there or hope to see you virtually there. Yeah. If you have questions for Kevin, go ahead and drop them into the chat, Kim.
Zach Hill:And thank you again, Kevin.
CJ Cox:You have the q and a button. Right, Kevin? Because some these are
Kevin Klingbile:I I I just pulled that up. Yeah. So there was one just a little bit earlier. Are there any tools provided by MS to help audit bad old rules? None that I'm aware of.
Kevin Klingbile:I'm not even aware of any non Microsoft ones. They're they could be there, but I don't I'm not aware of it. There was a tool I can think of as it's it was called Orca. It was developed by a individual engineer at Microsoft. I don't know if it's built into that.
Kevin Klingbile:That'd be the only thing I could point you to look at for if it if there is a chance it would be in there from from it.
CJ Cox:Cool. Raj was a beast helping out on there. He answered a bunch of questions. He was awesome. Awesome.
CJ Cox:Thank you. What else is in there that I thought was interesting? Jeremy Dalton, do you
Kevin Klingbile:see his? Jeremy. What is
CJ Cox:the best alternative direct send an SMT off?
Kevin Klingbile:Oh, yeah. We we we did that one. You got that one? Mark Yep. Multifunction program.
Kevin Klingbile:Actually, yeah. Long Joe Boyd's. I don't know. I think that got it. Yeah.
Kevin Klingbile:Think we we did we did Joe Boyd's. We did yeah. Hold on.
CJ Cox:And Aaron edit any question a bit earlier. Aaron, pop it back in here. Let's see it. We got a little time.
Kevin Klingbile:I know. I I was supposed to be on, like, an ROE, like, right now. And fortunately, before I was able to get it rescheduled thirty minutes later, I'm like, oh, I might have to stay over.
CJ Cox:Can you see Aaron's question in Discord there, Kev? I don't have Discord pulled up. Oh, I'll paste it over. Here it comes. Thank you.
CJ Cox:Put me in chat. Did it
Kevin Klingbile:did it I I should've I should've pulled up Discord, but I have like 50 other tabs open right now, and I didn't get it pulled up in time.
Zach Hill:Oh. I'll read it out loud for you too, just so everybody can know what the question is. Why are you calling emails from outside the domain as direct send? It was my understanding that direct send was specifically and only for internal domains to internal domains. You're just dealing with general spoofing when they are sending from outside domains.
Zach Hill:So saying, setting reject direct send to true should only block internal to internal authenticated direct send.
Kevin Klingbile:And so I I think this is referencing, so in the slides here, and are they still on the screen? I'm not sure, but on the slide that has this disabled direct send, and I I have two asterisks on the slide there. It's slide 23 if you're looking at the PDF. So within this message itself, there is another link that followed or another blog post, I guess, tech community article from Microsoft that followed this, where they specified sending directly to to Exchange as a clarification for a direct send. I I would definitely have questions for Microsoft on on I don't have a a link out to to is there somebody at Microsoft to talk to?
Kevin Klingbile:But so they came up with another article because everybody was doing this disable direct send, and it wasn't working. And they came up to specify if you're sending directly to Exchange. Well, it pops in some questions. Why would Exchange by default allow spoofing into the organization from outside to inside? Right?
Kevin Klingbile:So I I get the comment where you're saying, isn't DirectSense specifically only for internal domains to internal domains? I don't know the specifics of tech you know, but technically, Direct Send is only that user, only this other use. I just know it works. And when they enable DMARC, it's gonna stop the spoofing. Right?
Kevin Klingbile:And when they do the traditional third party because if if you talk to Microsoft and you say, hey. Have a problem with Direct Send, Microsoft is gonna tell you, well, make sure you're going through your your third party spam provider or your your spam provider. And the issue became actually if you were running on Exchange Online only with Defender, there wasn't a way to disable direct send. And I'll put that in quotes since we're trying to get technical with the language. Right?
Kevin Klingbile:There was no way to disable direct send if you were using Microsoft solutions until this came out, which this was almost a year ago. This, I think, was March 2025. So this has a follow-up article on sending directly to Exchange Online. And whichever language we want to use there, I I don't know. But I know everyone I talk to calls it direct send.
Kevin Klingbile:Everyone in this community calls it direct send. And when that's enabled, we're we're spoofing that. So it it could technically be just spoofing, I guess. But if it's just spoofing, it can certainly do that. Microsoft is less spoofing open by default.
CJ Cox:Lot of interaction. I knew it was gonna be a good topic, so I came.
Zach Hill:Gary in Zoom says, for SaaS apps sending on our behalf, better to add them to DMARC subdomain per SaaS vendor?
Kevin Klingbile:Well, so is like, you do you already have DMARC configured?
Zach Hill:That'll be a question back to Gary. Uh-oh. Did we lose Kevin? Kevin froze.
Kevin Klingbile:They're sending out on behalf of And is your mail flow rules for that vendor itself? Because you're you're I assume bypassing spam at that point is probably why you're asking the question. If you specify their IP addresses and their domain, right, at that point, direct send would work to spoof it or the spoofing messages would work to spoof it because you've got their specific IP and domain combined. And that direct send it lets take over that company, but then it's still a risk no matter how you have configured. Right?
Kevin Klingbile:So as good as you can do.
Zach Hill:Thank you, sir. It looks like that's all the questions that we have queued up. So appreciate everyone being here. Thank you so much CJ for tagging along. And thank you Kevin, of course, for sharing your knowledge.
Zach Hill:Any parting words from you gentlemen before we depart for the day? No. Nothing awesome.
CJ Cox:Okay. My phone Looks complicated. I'm glad that I have smart people around me to do this stuff. That's all I know.
Zach Hill:Right? I feel the same way. I I always feel like the the dumbest person in the room, and I love that because it allows me an opportunity to just continuously learn from everybody. I I hope more people feel that way and feel comfortable feeling that way because it's great. But anyway, thank you all for signing up today, joining us.
Zach Hill:Be sure to check out the CTF, And, of course, you can check out Kevin's class coming up at Mile High HackinFest next week. Links are in the Discord. We will not be here next week, so we'll see you in two weeks. Or we'll see you at in Denver, hopefully. Anyway, otherwise, have a great day.
Zach Hill:Great week, everybody. Bye bye. Take it easy. Kill it with fire.
Creators and Guests
