BSides Buffalo 2026: It Wasn’t Spoofed: Investigating Authenticated Email Abuse in Real Environments

Um, just a couple pieces of housekeeping. Uh, just make sure your phones are on silent. If you're using the bathroom, use the side rooms. But unless we're call

um her uh presentation of it wasn't spooked. Um,

Sit down first. >> Welcome back.

>> Yeah.

>> All right. Hello everyone. Thank you for coming to my talk. My name is Kelsey. My handle haven't heard a lot of people use handles here, but my handle is wombat. Um and

>> and today I'm going to walk you through an investigation. That's Oh my goodness. Here we go. And today I'm going to walk you through an investigation that started like a normal spooking case and turned into something very different. A little about me. I am a senior detection and response analyst at Beasley Security mentor and most importantly a purveyor of only the finest news. So a client reported a spoofed email targeting their internal users. When this case first came in, the immediate assumption was that this was a spoof email. Spoiler. It wasn't.

And these are all the alerts we received. Nothing. Uh because there weren't any. uh not email, not identity, nothing. At this point, the assumption was spoofing as per the client. Thank you, client. Um, not off the table was fishing. And of course in either case an external center with the typical off as anonymous but the reality was very different. You see what happened? It was an internal email. All routing was via a known trusted path. How is this possible? You may ask. >> Well, it's easy. When you have valid credentials,

and this is where things start to get dangerous. The emails, by all accounts, appeared legitimate. Nothing about them appeared suspicious. The recipients, and there were a lot.

Oh, sorry. Nothing about them appeared suspicious to the recipients. Um, this was an environment where timely communication was critical. A sense of urgency was vital. People were conditioned to trust and act quickly. Most users aren't security practitioners. If you are currently in the field, you have very much grown to know this. fans and feel this every day. Um, but that's why these security controls exist in the first place. They're there to catch the things the average user wouldn't. But this breaks all of that because all of those controls they were bypassed.

Simply put, this model equates internal with safe and authenticated with safe. >> Good question. >> Yes. Did the apparent sender of the malicious email match the person who actually sent it using their credential or was it the person with a credential was able to simulate someone else as present? >> Was it spooked? >> So Bob sent the email and the email said it was from Bob. >> Correct. >> Okay. We're showing the Bob's credentials. >> Yeah. It was out of credentials. >> You'll learn more. >> Okay. >> Stay tuned. >> Yeah. So, coming back to this this incident, it abused both of these things. At this point, we had the client crying spoof. But what we needed

was evidence, which means this is why I break all of your expectations and maybe some trust models, too. As with any email investigation, our first step was to ask for the email. But not just the email. We needed the original unforwarded file because forwarded emails lie to you headers >> and lies. Well, they're only reserved for free birthday desserts. If any uh waiter asks, "Today is my birthday. Happy birthday. >> Happy birthday. >> Thank you.

>> Um, now unfortunately this investigation came with a few small constraints. We didn't have a nice VM ready to just spin up. No detonation environment, no sandbox. Instead, this became one of those investigations where we had to fall back on the fundamentals, working directly from the raw EML, extracting the encoded contents, decoding base 64. Thank you, Cyershe. Um, oh, and by the way, if you're new to this, you're using a tool like Cyershe, download it locally. Please don't don't don't go on to the internet and like expose your client's information. That's a bad move. So, yes, >> I have a question. How would you uh download it locally? >> So, when you go to their website, there

is an option that says download Cyershop. click that option. I'm down. Make sure you're on the correct website. Okay? Like actually their website because there will be repos. So carefully you get the right one. Um just download that. Make sure you use that. Keep it updated because once you have it on your local computer, it's not just going to automatically update. So keep that in mind as well. Uh it's a great tool. And if you ever participate in CTFs like the one here, it is a great tool because there'll be some like crypto challenges and stuff like that. So keep that in mind as well. So that decoding the basics before there is also URL decoding.

Then reconstructing the redirect chain from EDR telemetry with the email header. Finally, human readable. I noticed something.

Uh, you know what? I'm noticing something even more interesting right now. That I have more than one version of this presentation. And this is not the most polished version. But that is okay because I worked through this case so I already know what's happening. So we're doing this live. Um okay. So you might be wondering at this point uh how I did this. Well, I started talking about the cyership, right? Uh yeah. Um, so in here I'm showing you the steps of how I work through this. So we're not sure what's in that file. So that's a little scary, right? I don't have a place to put this maybe malicious, maybe okay file in. So I just

kind of have to work around that. What do I do with that? I rename with the EML file to a text file to .txt. That way you don't have anything that can you know go and that makes it plain text. I don't know everybody's level here. So I'm just going to kind of walk through this and that way there's nothing that will try to render and nothing that's going to you know go ahead and uh work its badness if it's bad in there. And but then that's that's all plain text. And that's why I then have to use things like cyersh because then you've got your base 64 encoded text which unless you're a computer which I don't know I don't

know your I don't know who you are. Um you're not going to just be able to read that. That's why I had to decode it. But then there's the fun part of where once you decode that then sometimes they like to have more B 64 encoded stuff after you've decoded the B 64 you so you have to decode that B 64 again and then that's how you get the URL but URL has its own encoding so then in Cyershe's bunch of different things you can use one of those is the URL decoding I also like to use the uh the null. There's a there's another option for null bites. So you can remove those null

bites so you don't have a bunch of weird encoding and like weird characters that make it more difficult to read what exactly the email is. So that's another option you put in there so that you can actually see what you're working with with that. I found the URL. See this this this version that I did is a lot messier. So let me give me a little bit to work through what the heck I did. Um, all right. So, when I found that URL, I'm like, something about this does not look okay. Um

so with that malicious URL um because I had that I didn't have that enterprise tooling um

sorry Um ah so once I had all that I was able to see this in the email header. This is the part that made me realize that uh something's up here. This is not what the client said it was because what I had talked about earlier was the email email header would have said something like anonymous. It wouldn't have said this internal. What does internal mean? Well, it means internal. That means inside of your organization. That means it came from inside the house.

This is what made those alarm bells go off. And when you're inside an investigation and a client tells you one thing, you cannot take it at face value. Yeah, of course you want to trust the client, but as an investigator, you have to use your own analysis and the evidence has to speak for itself. It will not always say what the client says. It will not always prove what you think it should be. And that is where you have to be able to pivot quickly. Your hypothesis that you may have started with will have to change and you will have to change with it. you will have to readjust that hypothesis and follow those strings. You have to

follow the evidence. This is me having to completely change my train of thoughts. My investigation posture had to change because now we're no longer dealing with those traditional sleeping indicators. Now, this is where we're evaluating inherited trust. And then there was the off mechanism. So this is type four. And for those unfamiliar with Microsoft Exchange and their authentication types, 4 04 indicates SMTP off. And this is what helped put a lot of those puzzle pieces together. Now, before we go any further down the header rabbit hole, I want to take a step back because to understand why this email slipped through, you have to understand what email authentication is actually telling you. And spoiler number two,

it's not what most people think. There are three checks doing the heavy lifting on every email you receive. SPF ask one question. Is this server allowed to send for this domain? That's it. It checks the sending IP against a published list. It says absolutely nothing about who logged in. Dcam asks, "Was this message signed and did it arrive unaltered?" It's a cryptographic signature. Great for integrity, but a valid signature is not valid intent. And Demark Demark is the interesting one. Demar asks, "If SPF or DKM fail, what should the receiver actually do about it?" And here's the catch. The answer is set by the domain owner. That's where you get human in this which means it can be set

to do nothing.

Demark gives you three options and they live on a spectrum. On the strict end, P equals reject. Block it. Refuse delivery. The message never lands. In the middle, you have P equals quarantine. Treat it as suspicious. Send it to the spam folder. And then there's P equals none. Do nothing. Deliver the message anyway. just write it down in a report somebody may or probably most likely won't read. Now, remember way back at the start when I showed you all the alerts we got? This is why >> whoopsies. >> We did. Whoopsies. With P equals none, there was nothing to alert on. The system did exactly what it was told. Good system.

So, let's put it together. The email authenticated. SPF passed. It came from a legitimate server. It was perfectly signed. and demark nothing failed. So nothing fired which completely changes the question we should be asking. It was never was this spoofed. The real question is how did they authenticate as a real user in the first place?

Well, to get to that, let's let's learn a little bit more about this thing called SMTP authentication. Cuz remember that was SMTP off. So why was that SMTP authentication such a revelation? It's considered a legacy authentication. I don't mean like their parents went to college so they're going to totally get in now. I mean it's like old like you y'all shouldn't be using this anymore. You only need a username and a password. There's no multiffactor authentication challenge. You may think for those that you of you that are practitioners, but MFA is mandated to watch. But even if MFA is enabled, SMTP off using basic authentication simply doesn't support it. So go ahead, have your MFA

It's not going to work. Now, why in the world would any environment in 2026 still allow this? >> Laser printers, >> eences. I love opinions over here. >> The biggest reason is almost always the same one. Compatibility, legacy applications, multi-function printers, scan to email devices, older scripts and service accounts. A lot of them only speak with basic off over SMTP. So rather than break all of that, organizations, well, they decide to leave that door wide open. And an attacker with valid credentials, well, they just was right on through it.

So let's actually decode that off mechanism value because this is the piece that ties all of it together. Exchange logs how a message was authenticated as a number. So here's going to be your little exchange primer, y'all. Oh yeah. Uh I live in this house so just forgive that. Um so that double zero that o that is unknown or none 02 or just two is in TLM. your normal Windows integrated on. Six is an internal trusted relay. And then there's four. That's SMTP on authenticated submission with that just username and password. >> How can I help you today? Well, I can teach you about SATV and it only requiring a username and password sir. >> Yeah, get that knowledge down.

And that's the smoking gun in this whole thing because type four doesn't mean a server got spooked. It means someone logged in with credentials. The message was authenticated, just not by who you'd hoped. Here's

a question. Do we have any pin testers or red teamers in here? Raise your hands. Don't be afraid. Blue team. Oh, don't worry. We won't jump you. We'll just meet in the the parking lot after this. I'm just kidding. Uh, so how much would it brighten your day if you know your target just so happened to have a path that bypassed MFA? >> We find it all the time that it is glorious. >> There we go. There's your answer. Don't worry. The uh pin testers and red teamers at Volicon firmly agree with you. There might have been a little cheer or two. I can't I can neither confirm nor deny. So for pretty much everyone else. You hear

that? They find it glorious. What do we find it? Well, we don't find it glorious. We find that scary. We should find it scary. And that is why we should not let that happen in the first place. We should catch it, but we should actually make it not happen. We shouldn't have to catch it. We should stop it before it happens. That's that's the that's the key guys. No unfortunately. It didn't stop there. >> The email contained a malicious link. >> How malicious was it? >> Well, there was no there was no Zelda to to save.

We get to it. believe me. Uh so once that user clicked the email link, and boy, people sure do like to click things, let me tell you. Um they were redirected through multiple URLs. And here's the fun part. In the original in the original email, that URL, it was fully visible. There was no attempted obuscation. They didn't try to hide it. They didn't even like put a picture and like just make it clickable and you couldn't see what it was. It was there in its full glory. Oh jeez. You could see that like plain text. It was all written out. That link, it ended inhal. And while that doesn't mean it's inherently malicious, uh, for someone that's like me, a

technical investigator, and probably the last good portion of you, or some maybe some of you are aspirational to be, um, it definitely raised some red flags. the redirect chain. Uh well, that ultimately resulted in the automatic download of an unauthorized remote manage unauthorized remote management tooling. Uh so how dangerous was it? Well, it certainly wasn't good, sir. Leaving no doubt that this was indeed malicious. And every time we thought we'd reached the end of the investigation, we uncovered something new. It basically became Mr. Bone's wild ride. This is a very This is a very early cult. This is called back to uh early internet meme named D. Hopefully you all know this. If you don't look it up, it's fun.

Roller coaster tycoon. Fun fun. All right. So, since we thought it happened, we're actually considering at one point. So this splendor is so she says we thought at one point um because uh the client believed they've been compromised again because another user one we've never even heard of some holy third party that we'd never heard of before was like hey uh let me report something uh I have malicious email you know that same one that you already were talking about before. Um so we were thinking, okay, persistence because that's what you would think. All right, this is popping back up again. What What's going on here? Only it wasn't persistence. That would have been the easy That would

have been the easy answer, right? Um, and would have made way more sense. And it wasn't a reinfection if that's where your minds went.

>> A user had configured a mailb forwarding rule.

>> Nice. that forwarded business email to a personal email account that they accessed from home. >> Nothing wrong with that at all, >> you know. So, the malicious email had just, you know, literally followed them home. We said, why not try puppies? But no, malicious emails, that was that was what they went with. Um, so learning about the forwarding rule did more than just explain the second report. Uh, it broke the original threat model which necessitate ne necessitated that quick pivot and to immediately shut down one line of investigative thinking and opened up another. So, for those wanting to become thread hunters, this is some of the stuff you'll run into. Those quick pivots, those I came

up with this really cool hypothesis. It's like intel facts. I got like all this stuff lined up. I got all this data like lined up. It's all making sense. And then bam, you get this and you're like, what good is that? Uh, so this is what you'll have to do. Learn to quickly pivot, come up with a new hypothesis, get that intelligence to back all that up. Okay. So once we learned about that porting rule, uh that's when we had to ask that obvious question uh what's stopping this? Uh and here's the gap on the preventative side. The the side that would have stopped that rule from from been having been created in the first place.

Well, um, there was nothing. There's that word again. Dang it, there's a lot of nothing going on. Uh, empty. No policy blocking, enduser forwarding. Instead, all the work was being done over here by a compensating control. a weekly script that cleans up newly created mailbox rules only. It runs once a week. So that's a fixed cadence. So if one even just one of those new rules just so happens to be malicious, you have now just given it a whole week to play before wipe day. It's a constant game of cat and mouse. Oh, and here's here's an even more fun part. Uh leadership. They had no idea. So in that call where we go over this

and the forwarding rule comes up, the compensating control comes up. What is said? I thought we blocked that. That's organizational blindness right there. So we have to keep everyone in the loop.

So ultimately it wasn't any single technical finding that made this investigation memorable. It was made memorable by every player, revealing an assumption, an assumption about trust, an assumption about visibility to people like you know kind of important people like leadership. An assumption about authentication. an assumption about operational controls. And eventually those assumptions started colliding with reality because you know what they say about assumptions.

The biggest operational lessons came down to four things. SMTP off usage, mailbox forwarding rules and allowing in users create privileges, browser hardening posture. So with that I didn't speak directly about it so I'm going to talk about this now. What do I mean by browser hardening posture? So when they clicked on that link it opened up the browser and automatically started downloading that RM tool. What should be happening? It should automatically be downloading that. Your browser should not just say, "All right, cool. You clicked on something. Let me download that sucker for you because I am so nice." >> There are >> What's that? >> Just helping you out. >> I know. What a butt. What a pal. What a

meme. >> There are different layers you can do with browser hardening. So, you can if I guess if you trust your users, which >> hey, that's on you. That's I'm just saying that's on you. That's It depends on your uh you know that's you man. Um you can have it to where it pops up a little notification like hey you're you're going to download something. You sure you want to do that? And they're like I don't even want to read you so I'm just going to go ahead and download it. And it can do that. You can do it to where it doesn't even pop that sucker up and just is like no. And honestly, most

organizations that's what I would I would do that for things when you want to download that should go through an approval process. I mean that may just be me and my uh my my level of uh how much I would uh trust and you know threat posture and all that stuff. But those are some of the options. Look in the look in the thinner docs. So the the browser not only downloaded the tool, it executed it, right? Because if it doesn't, then it just sits there in the downloads folder. >> Yes. >> Okay. >> The ride never ends, man. >> Wow. All right. And finally, compensating controls violently becoming the primary control. Uh because let's just say don't have something

that's trying to clean up afterwards. You want to stop that before it happens. That's the big That's a big point right there. Okay. So, if you take four things out of this room with you. One, authentication success is not a trust signal. It proves a login worked, not that the sender is who you want them to be. Two, internal does not mean safe. Legacy paths like SMTP basically bypass MFA and inherent trust. Nobody goes back and rechecks. Three, you can run a real investigation without direct platform access. Because I'm not an MSP, we don't get to actually go in and touch all the tools and and like all the settings. The raw EML plus EDR telemetry, XDR

telemetry uh reconstructed this entire chain. And four, watch for the moment when a compensating control quietly becomes your primary control. Find that gap and make sure leadership knows it's there. It should not come as a surprise because I will just warn you that will not make for happy leadership. And unhappy leadership makes for an unhappy you.

On the surface, very beginning, this was a relatively easy and straightforward spooping investigation. What a gift. Unfortunately, it was less a gift box and more a Pandora's box internal email because it wasn't spoofing that authenticated with valid credentials made possible courtesy of SMTP off using basic authentication which allow for MFA bypass. That same email contained a malicious link and redirected through multiple URLs which made for fun when threat hunting. It actually the thread hunting part is really fun for me. So that part was

ending in the download of unauthorized RMM tooling. Then we come to the let's see mailbox for wording rules that allow end users to forward business emails to personal accounts. But don't worry, there's a weekly script to clean up those pesky new rules. Assumption failures. Wait, what? I I thought we had that lost. >> Browser heart. Turns out this one simple trick could have been in a lot of headaches. Like you alluded to the browser part um if it hadn't have even uh deployed like nothing would have happened. It if it hadn't even downloaded you wouldn't have had that problem in the first place. because it wasn't spoofed. It didn't need to be. So, if you take nothing from this,

attackers don't always need to earn trust. Sometimes they inherit it. >> Any questions? >> Yes. Was it ever determined how the original credentials were stolen? >> Excellent question. >> And maybe I set you up to have someone ask this question. Maybe not. Can either confirm nor deny? >> Yes. Yes. Um, so what did what did I suggest to the client? I suggested using something like if you've never heard of it, have I been pawned? Because I can't do it because it says write their terms. Don't just do that because it's not my email. It is the organization's email. So, don't just go ahead willy-nilly put in your or like some other organizations email in there. And uh let's just say

there were hits there. There were there was a hit. So, so um yeah. Yeah. So, there we go. >> Yes. >> Um so, you mentioned that because of where you work, you were not able to access all the tools. So did you have the ability to do things for revoking session tokens, doing uh KQL hunts, uh running any sort of uh scans for persistence, any leftovers? >> Uh EDR, I had EDL. >> So did you do like if it's if it's like a crowd for example, did you do any sort of uh checks for any persistence through RTR, you know, did you do anything on on side of that for any artifacts? I mean I

tried to look for things like uh well firstly if there were any of the network connections none of that tried to look registry keys created any startup like files like that different things like that yes I did look for that luckily and this is this is like the only silver well I guess there's a few silver linings we caught this before it actually did anything So that was the good part and leadership became aware of those forwarding rules. So that part is you know they can fix that. They uh obviously the suggestions for go ahead like those user accounts that we know are affected like lock those suckers out like don't let don't let this continue

to persist. Um, it's a suggestion of check for any applications that are new and weird. Uh, any new permissions that were created, revoke that stuff, reset all MFA, revoke, um, any active sessions, all that kind of normal cleanup stuff for accounts, >> browser uh, caching temp file cleanup. >> Exactly. Exactly. because we don't know exactly how far things got cuz I can't I can't go right in there and look for you. So I can give you a big old list of things for you to check. >> One drive clean up too. >> Yeah, exactly. Because it'll sync to it >> and then Yeah, it'll sync and then Hey, there's >> then you're talking. >> Yes.

>> I keep coming back to this browser that immediately downloaded and executed a file. I mean, I I've been using browsers back to links and I don't remember a browser with that as a default behavior. What the heck is going on? >> Isn't that fun? >> I am not their admin. >> But do are you aware? >> I I don't think it would give away the identity of the client to tell us what browser they were using. That's the thing is that that I only get to know what they tell me. >> Yeah, that's the crux of it that when you're when you are in the role that I am in, we get to know what they tell us.

We can ask questions. We can make suggestions. In the end, what we know is what we can find on our own and what they tell us. So we have to work with a lot of ambiguity and do the best we can. >> Well, and at least in the past I've seen, you know, you can set uh like Chrome up to download like an Acrobat Adobe Acrobat file and load it in Adobe Acrobat, right? So I have seen things like that where it's like you automatically load, >> right? But executable. >> Well, also you you download a PDF that's gotten delicious content crashes and Adobe Acrobat because you gives you the way to so that that's

probably becomes a dropper. >> Yeah. >> Yes. >> What was the time frame when the client contacted you to when you actually got delivered cause? >> That was about a day. >> Actually pretty good. >> Yeah. And also the attacker was not on it with like making use of that. >> Well, we didn't know exactly what was happening at first. So at first we only knew it was spoofing. So before we really knew what was happening, my first I I air on the side of concrete. So I said, I don't know quite what's going on yet. So let's just lock this down. I just connected the end points. >> So I'm like it's it's it's not a DC. It's okay.

>> Yeah. >> But like host continue. >> Yeah. Exactly. Yeah. Network disconnect. Like stop the bleed. That's okay. When it's like an incident or you think it's going to become one, first thing you want to do, stop the bleed. Like you don't know if it's an ephemeral artery or whether you know someone just their finger. So you just got to stop it first. >> Anything else? >> So So like how was this originally reported? Was like a user who received the email said something's awful off of this. You know, they tal they called the person, you know, whose credentials were and said, "Did you really send this to me? What's going on? Is that does that

help?" >> The user was like, "I didn't send this." And that's why they thought it was spooky. And so I asked the person who was their security person, why do you think it's spooky? So, you always want to ask questions, the client. Ask the questions, follow questions. Uh can't just take them out face off, right? And they said they said they didn't send it. I'm like, "All right, fair enough." You know what they said? And that's why I had to go for the actual evidence. That is where the evidence comes from.