
This Anti-Cast was originally aired on January 8, 2025.
In this video, Patterson Cake discusses the critical issue of business email compromise (BEC) and its implications on small to medium businesses. He shares real-life examples of how BEC has led to significant financial losses and the common tactics used by threat actors, such as phishing and identity theft. Patterson also provides insights into detection, prevention, and investigation strategies to help organizations protect themselves from this growing threat.
- Business Email Compromise (BEC) is a growing issue that can have devastating financial impacts on small to medium businesses, often involving phishing attacks that exploit trust in electronic communications.
- The typical BEC attack process involves phishing emails, identity theft through deceptive login pages, and manipulation of email accounts to redirect financial transactions.
- Detection and prevention strategies include monitoring for unusual inbox rules, using multi-factor authentication (MFA), and educating users about the risks of electronic communications.
Highlights
Full Video
Transcript
Patterson Cake
Howdy, all. yeah, thanks. Thanks for being here. We get a short hour together today, and I’m jealous for your time. If you’ve been to any of my webcasts before, you’re probably aware that I’m going to try my best to squeeze two hours of content into one hour.
I’m, going to leave you with some resources, some additional opportunities to review a GitHub repo, et cetera, et cetera. So, let’s dive in and make the most of our time together.
I confessed before we started that in some ways, I don’t want to be here talking about business email compromise today. At the same time, it is such a prevalent and growing issue that I, I, we need to address it, we need to talk about it.
I want to win this one. And as I mentioned moments ago, even if it does sound cliche and trite, it’s accurate, it’s honest. I want to stop the threat actors in their track.
I worked with a, very small startup company, 5, 6 employees, dedicating countless hours. Been in business for just about two years, turning a corner into profitability.
$125,000 was lost directly into Threat Actor bank account because of business email compromise, and it almost destroyed the business. They almost lost that.
Well, to be frank, it pisses me off. And personally, just me not talking even about the overarching BHIS DFIR team.
I have seen over $10 million directly deposited into threat actor bank accounts in the last year or so from BEC cases that I’ve worked. Just me.
And so, sadly, this is important, it’s critical, and it will not surprise any of you that this is just an introductory component to electronic communications.
I mean, the deep fakes, the advancement in, AI, the advancement in deceptive technologies.
This is just the beginning of this conversation, I’m afraid. Not the end. So let’s talk about it today. Let’s talk about, the implications. I want to talk to you about the current state of affairs effectively, and, what we’re seeing in the wild.
Talk about some detection, prevention, investigative opportunities. Give you a few additional resources and cram, that all into an hour. It’ll be fine.
Hi, I’m Patterson Cake. I am a digital forensics and incident response consultant for Black Hills Information Security. I’ve been doing IR focusing on IR for the last several years, and, again, just excited to be here today to talk to you about what we’ve seen specifically as it relates to BEC.
I’m going to focus mostly on M365BEC. But because that’s frankly the most prevalent enterprise mail solution system that we’re encountering at the Moment, the overarching SOPs standard operating procedures will apply whether you’re using Gmail, on site, email, et cetera, et cetera.
I love this quote. this motivates me knowing what I know, knowing what I don’t know. It sounds a lot like humility to me.
And again, I’m humbled and grateful that you’re here today to listen to me rant, and rave about bec.
One of the things that I do, frankly on a continuum is try and take something that’s really complicated and simplify it. And I, I pretend like I’m doing it for your benefit.
To be frank, the fact is I’m doing it for my own benefit because I’m just not that smart. I want things to be simple. I strive for simple, effective and repeatable.
That is my mantra for ir. Simple, effective and repeatable. And this is my view of the world. From my perspective, we can effectively consolidate all threat vectors, all attack vectors, the way the threat actors are going to come at us into these three high level categories.
And yeah, there are a few exceptions, but these are the big ones, the unpatched vulnerabilities, AKA zero days, et cetera, misconfiguration issues and then identity and credential attacks.
And primarily today we’re talking about identity and credential attacks as it pertains to business email compromise. Bec.
It’s a rare moment in history. A lot of the annual reports have come in, the Verizon dbrs, the Ciscos, the IBM, X Force, et cetera, et cetera, et cetera.
And surprisingly, or maybe unsurprisingly, there’s a high degree of agreement in this top line item and that is that in the last year or so, nine out of 10, sometimes slightly more than nine out of 10, which is darn near all of the breaches that occur start with some sort of phishing, they’re starting with some sort of credentialed attack.
And again, that’s why we’re here today talking about this. This is preeminent, it’s not new and sexy. I was talking to a, to a customer yesterday and they’re like, tell me about the cool new things that you’re encountering in incident response this.
And I’m like, I’m not. It’s the same Stuff that we encountered last year, sadly, the year before and the year before. And I, I would love for us to overcome that.
I’d love to be talking about something new and different. Frankly.
I mentioned just a moment ago, if you’ve ever gone in search of truth on the Internet, anyone, it doesn’t matter what the truth is. Best pizza, best mechanic, best wireless router, doesn’t matter.
Finding truth is really hard. And so I tend to fall back in the face of incident response, expose what’s going on in the wild. Again, to be honest, I fall back on what I have experienced firsthand and I don’t know that it’s statistically relevant.
frankly, I know it’s not. At the same time, as mentioned, I have seen $10 million direct deposit into threat hacker bank accounts in the last several months.
And so this is legit. And for better or for worse, I’m seeing this happen largely in the small to medium business market. So this is, these are companies that have 5, 10, 20, 50 employees.
And so we start talking about hundreds of thousands or maybe even millions of dollars. And this is hugely impactful. Hugely impactful. That’s what I mean about the wild. And frankly, again, what I’m saying is what I have experienced, what we have experienced, and I know that it’s true, finite but accurate.
So I want to talk about SOPs, because I’m thankful the threat actors often follow sort of a series of events, a series of chained events, standard operating procedure which helps us to know, identify, investigate, what we’re seeing and what we’re experiencing, talk a little bit about the tactics and techniques.
And then again we’ll transition to opportunities for detect, prevent, and some investigative opportunities along the way.
How does this begin? how does this happen? And this again, this won’t surprise any of you, this is the beginning of the end.
Oftentimes this is actually based on, a true story, if you will, and you’ll recognize immediately common features, functions of a typical phishing email.
The thing that is most crucial about this and what we are seeing recently as the trend is that this message is going to originate from someone that it’s going to originate from someone that you do business with.
We’ll talk about that progression momentarily. But when you get this mail message, the fact is that you recognize this person, at least tangentially. You’re busy.
Part of your job is to open and respond to email, pay invoices, click links. That’s what you do. You’re an accounts receivable accounts payable, HR, et cetera, et cetera. You do this 100, 200 times a day.
You don’t pay attention, you don’t hover over links. That’s ridiculous. Especially when you recognize this is somebody I know. I trust. This project management site, they’ve done work for us in the past, immediately triggers that initial emotional response.
In this case, it’s trust. It’s trust that is the emotional response trigger of the day is I trust this person, this sender, and then we’re done.
That’s it. The brain kicks in, workflow kicks in, and away we go. And frankly, bad things usually happen. Not surprising. We know that phishing is often intended to trigger an emotional response, whether it’s fear, urgency, anger, etc.
Again, what we’re seeing now is, is I, I know this person, I trust this person. This particular example, the it was actually a, a, a ticket warning to an individual.
And it wasn’t City of Bremerton, as this, as this illustrates, it was the Isle of Man. And I’m like, wow, that’s fascinating. This person must be well traveled. And I actually spoke to the individual.
I’m like, go. When did you go to the Isle of Man and then have never been there. So why did you click on a link for a traffic violation to a place you’ve never been?
Again, this won’t shock any of you. The emotional response was triggered. She was fearful, she clicked the link. The rest is history. Again, emotional response. At this point, what we’re seeing is trust.
And this is a hard one. We have been teaching, attempting to teach and educate our users for many, many moons. Now that first question is, do you recognize the sender?
Is this a mail message that you’re expecting that is no longer individually, discreetly a valid criteria, to be honest. Now, as a technician, IT security professional, there are multiple things here you should be worried about.
If we could really teach the individuals to hover over links and look at domains and etc. Frankly, I’ve given up on that. I don’t think it’s fair to them. I don’t think it’s fair to them as IT security professionals, we should stop this stuff from ending up in their inbox in the first place and not blame this for responding to an email that we allowed to get in their inbox.
Entirely different discussion. But, so what happens next? Trigger a trust response. Whatever happens next, I’ve already made a decision.
This is legit. I need to access this for the purpose of doing my Job, whatever comes next, frankly, how many times I have to click, how many times I have to authenticate, how many times I have to go through warnings.
I trust the sender. This is important to me. I will get to the bottom of this message. Click the link on the back end. On the threat actor side. This is just one example.
I’m going to be using evil Jinx in the back end, so to speak to illustrate this. And so user clicks the link. This is step two in typical BEC compromise. Again, not surprising, not revelatory, not new, fancy, exciting.
Evil Jinx has been around for a long time. Evil Jinx is an evil proxy. Effectively man in the middle. Click the link. This. In this scenario and in the most common attack scenarios that we’re seeing right now, this is called a lure.
Appropriately, in this example you can see login haven tag is the lure that I created for this demonstration. We could make that more clever. We could make it look more like the legitimate Microsoft Online URL.
Frankly probably doesn’t matter. We will generally use a relatively long standing URL so that this is not easily triggered, easily blocked, etc.
Click the link. Link directs the user to a fake Outlook M365 login looks a little bit like this, which looks very much like the real login page.
It security professionals were like, look says Haven Tac. that doesn’t look right. I think that’s an unreasonable expectation potentially for our users.
Should we have let them go to this URL in the first place? We’ll talk about that in a minute. The user is convinced this is from a trustworthy sender. They’re going to authenticate.
They’re going to authenticate. Why wouldn’t they? Looks pretty legit. It’s a well crafted page. In fact one of these is real and one of these is not if you’re a typical user, pretty good fake I would say.
The only immediate telltale sign again is the URL and let’s face it, this is a stupid URL. If I were a typical user and I’m like I’m logging into my webmail, does login.Microsoft online.com OAuth that’s definitely the jet.
I mean this is, pick on Microsoft. Maybe there’s a better way. Maybe this could be a little bit more descriptive.
whatever. again this, this is just the point being, this is I think an unreasonable designator, for this typical end user. Not not trying to dissuade you from encouraging your Users to look at the URLs, but.
But that’s extremely challenging. A brief aside, because we’re going to talk about this moving forward. What makes you you in the context of your email solution?
What makes you uniquely identifiable in M M365? And the answer is for identity and access management, your username and your password combination.
As a typical human being, you have a standard device browser configuration. You use a PC, you use a Mac, you use an Android, you use an iPhone, you use Safari, Firefox, Chrome.
You probably don’t switch device platforms and browsers all day, every day, intermittently. Now you’re a bunch of nerds, so maybe you do, but the typical user does not.
They standardize on a platform. Most enterprises standardize on a platform. So that’s the device browser component. We’ll see that represented as the user agent. That’s the actual technical component that the browser sends to the server to say, here I am and here are my capabilities.
The third thing is your mfa. Hopefully you’re using mfa. I’m a huge proponent of mfa. It is not a silver bullet for this solution, but it is a component of your identity.
MFA is tied to a device, typically, again, Android, iPhone, et cetera. The fourth thing is your session cookie. Once you successfully pass I am who I said I am, I’m logging in from an allowed location I have authenticated via MFA.
Then M365 in this case provides you effectively with a representation of your authorization and access in the form of a session cookie. And last and definitely not least is your source ip.
Where do you log in from? This is typically, once again pretty static. I log in from work, I log in from home. The end, potentially I log in from my mobile device.
That is also finite. How often do you switch From Verizon to AT&T to Again, potentially three standardized sources of authentication.
Those things make you you, those things identify Patterson Cake. Those are effectively identity and access and user behavior, which we’ll talk a little bit more about in just a minute.
Back to our expose. What happens next? User clicks the link, presented with a very nice login page based on Allure man in the middle proxy.
Naturally, they put in their credential. Why wouldn’t they? They believe in the validity of this process. They occasionally have to log in in real life for valid reasons. So away we go.
Put in the, email address for the username component. The snippet in the middle is evil jinx. Capturing that process. You will notice this is the beginning of the user agent string you can see that.
Just, Do I have a pen? Right in here. At this point, the threat actors are gathering all the components of my identity.
They are gathering all the components that make me me in M. M365. We’re about to give them my username, they’ve gathered my user agent string, they’ve gathered my source IP address, and sadly, again, the next step of the foray is the user enters their password.
This is all being proxied, meaning that Evil Jinx is receiving this information and then passing it on to the real M365. Looks like this on the back end again for Evil Jinx in particular.
Evil Proxy captures user agent string, which we see here, source ip. Then we have username and we have password in plain text.
So we’ve got three, four of the major components of identity that make me me. Evil Jinx again is receiving that from the end user, passing it to M365 and then relaying the response as appropriate back to the user.
as we’ll momentarily. But we have mfa. I hear this all the time. Almost every time I get a business email.
Compromise inquiry. We need help. I. We can’t imagine how this happened. We have mfa. Sorry, Useful, important.
It is your due diligence. Do not throw MFA out the window. Please. If you’re working on an MFA implementation, continue with that implementation. Not trying to dissuade you from that.
However. However, typical MFA can be easily proxied as per this scenario. And so what happens next is that Evil Jinx, the evil man in the middle, the threat actor, has all the components of my identity, passes those components to Microsoft.
Microsoft says, I’m going to need you to complete an MFA prompt. We dutifully pass that directly back to the end user, as per the screenshot.
End user says, well, yeah, mfa, we’re secure. Put in number, put in code, approve, deny, doesn’t matter, sms, sorry, all the same thing.
This is a legitimate, effectively a legitimate MFA prompt. Evil Proxy then passes that back to M365. M365 says, you are clearly who you said you are.
Here is your session cookie. And then the evil proxy says, says bye and redirects in this scenario to the actual login page. So the end user ends up here ultimately, and they’re probably confused.
They probably log in again. They just access their actual inbox and they’re like, I don’t understand what just happened. If they’re a typical user, they probably going to go through this whole process all over again.
They’re so convinced they needed this message, that this was trusted, it was worthwhile, they’re going to go back and do it all over again. Often I feel their pain, to be frank, on the back end.
Once again I have all the things of all the things, I have all the components A, B, C, D, E of this user’s identity from user agent string, device, browser, OS indicators to username, to password, to MFA session cookie and how long.
Anybody know how long an MFA session cookie lasts? Effectively it has a built in refresh component and the browser.
Once I inject this cookie into my browser, I can refresh this over and over and over and it lasts, I don’t know, it’s hard to specify exactly because Microsoft’s a little coy about it.
But effectively forever, long, long, long, long time. For all intents and purposes it’s, again, this identity is completely owned.
This this is ugly. But this is the actual cookie down here. So if I’m a clever threat actor, I have all the components of the identity for this end user.
Now all of these frankly are really easy to now mimic and manipulate with one exception and that is the, the source ip. And we’re going to come back to that repeatedly because it’s critical.
This may be the most indicator of this process that we that we can drive and, or investigate. because it’s highly unlikely that the threat actor is going to log into M M365 from my house.
I really hope not. My second thought actually that would be kind of refreshing. then we could just duke it out. In any case, if I’m a clever threat actor, and this is a big if, I can mimic the user almost exactly from an M M365 perspective.
Almost exactly. Now it won’t surprise you that this is a game of cat and mouse, right? We see this all the time. The harder we make it for the threat actors the harder they work. And so we’re seeing them work a little harder at this for a while they would get username, M, password, session cookie and they’d log in from the Ukraine and we went oh crud.
We can implement conditional access policies and stop anyone from logging in from the Ukraine or Russia or again depending on where you are geographically located, we can do GEO blocking and stop that from happening.
Well it took the threat actors about three a half minutes to shift all their traffic to US East 1, aka Virginia. they’ve worked their way around that end.
Now we’re seeing them through the use often of VPN solutions to become geographically closely located to the source. So I’m in Colorado, chances are they’re not logging in from my house.
But it would not be inconceivable that they would switch to a source IP somewhere in US west for example, to get around geo blocking.
Step number eight find the threat actor. I got all the things, I got the username, I got the password, user agent, string, etc. Etc. This is me actually just literally copying and pasting the cookie using a Firefox cookie plugin, AKA cookie editor.
And it is this stupid simple copy paste import into session, hit enter and here we go. Threat actor has just become me for all intents and purposes from an M365 perspective.
And I need you to stop and think in the context of your environment. If I have your username, your M365Integrated, your intra integrated, potentially your active directory on prem integrated username and password.
What else can I do with that? What else can I do with that? I don’t know, I don’t know. But client access, VPN critical, other SaaS applications, the list grows on and on and on and absolutely Positively I have SharePoint Access and OneDrive and Teams and the M365 ecosystem.
Bad day, bad day. The next things that happen. If I’m a clever threat actor, this is actual threat actor, hands on keyboard.
At this point they didn’t just automatically acquire the session, they didn’t automatically test authentication. Now we have an actual evil individual interacting generally through web portal through for this M365 account.
And so one of the things that threat actors immediately do is add a sign in method. That way if you find them and, or if the MFA session cookie ultimately expires, which it will someday, I’m going to go ahead and add myself, add my tertiary device, secondary device, whatever so that I can actually MFA directly.
And if you’ve seen the MFA prompt, which you have and you didn’t have your phone with you and you had a secondary or tertiary device, you can click under the MFA prompt. I don’t have my phone with me right now. Can you send it to my email or SMS or whatever?
And this is a persistence mechanism that effectively obviates the MFA session cookie and allows long standing access until we find it and revoke it for the threat actor.
The threat actors are almost done. If you will step number 11. This is where things get interesting and probably expensive. What we see the threat actors doing now is they’re safe, they’re sound.
They have a persistence mechanism. They can spend a little time enumerating the mailbox, SharePoint, OneDrive. They will often do keyword searches, credit cards, passwords, socials, etc.
More often than not. Ultimately, they’re looking for a financial conversation that’s already in existence. They’re looking for an ongoing financial conversation that they can inject themselves into to redirect funds.
Remember, for all intents and purposes, if this was my mailbox, they are me. They are me. So they’re going to pay attention for often a week or two.
Typical frame, time frames are about, two weeks. The next thing they’re going to do is impersonate the user. they are me right now. And so they will then inject themselves into a conversation related to payroll, invoice payments, payroll and invoice payments.
almost invariably they’re going to find a conversation, an ongoing conversation with an external vendor that trusts me. Here we go again. And they’re going to say, shoot, this invoice is outstanding.
We’re reaching into viewer. We need this paid as quickly as possible. And we’ve changed banks. So sorry for the inconvenience. Here’s my new ACH routing information. They are going to create an inbox rule, almost invariably to redirect inbound mail from that external vendor to a hidden directory in the inbox, a directory that already exists.
RSS feeds is a favorite. So, again, I’m going as a threat actor, pretend to be me. I’m going to say, I need you to pay this invoice. I’m going to send it to the vendor.
When the vendor responds with, well, okay, thank you very much. I’m going to hide that mail message via inbox rule in RSS feeds or something similar so the actual me never sees it. And I’m going to have this entire conversation redirecting payment.
1, 2, 3, 1 invoice. 2 invoice. 1.6 million, 4.5 million. The last major case of work, $4.5 million left the organization based on this strategy.
They were doing a big construction project. They impersonated the construction, the general contractor. And four and a half million dollars later, Ouch.
The next thing they’re going to do is pilfer the inbox. They’re going to look for all the trusted relationships they can possibly exploit. Who do you do business with? Who would trust an email from you?
And then this, unfortunately, this cycle propagates, repeats. We’re going to take this mailbox, we’re Going to pivot to three other businesses, 10 other businesses, so on and so on, and we get exponential growth and exponential financial prosperity for the threat actor with very little effort.
Really all they’ve done is manipulate the user at this point. An important option item that we’ll talk just about a, little bit about in a minute, and that’s enterprise application registration.
I don’t really have time to deep dive into this, but I’ll talk to you a little bit about the indicators. If you have the default configuration in Intra Azure Ad User Settings, which I’ll show you at the end of the slides, you allow users to register applications to enhance the functionality of their M365 experience.
What we’re seeing is that the threat actors are now taking advantage of this to use things like Mailbox, search tools or to Again, they register this application, we find them, we evict them, we don’t nuke the application and it remains an alternate persistence mechanism.
Again, last two just described, impersonate you not only to the initial vendor, to every vendor, every person that they can find.
Rinse, wash, repeat, and the cycle, cycle continues. That’s the story, that’s the sop.
That’s what we’re seeing every day. And I never want to minimize the impact. But when I have a customer call and say we’ve had a bec, I want to tell you what happened and I really want to say stop, let me tell you what happened.
And invariably it follows this same sequence of events. Little bit of variation, a little bit of change. Don’t want to become lax, lazy, but that is what’s happening. So I want to talk about detect, prevent opportunities ever so quickly, halfway out of time.
I’m going to correlate these with the previous steps. So when I say number three, this is number three in correlation with what the threat actors have done already. So users click the link. the user is prepared to log into a bogus page.
Here’s a few things that we can do about it. Detect, prevent opportunities. We can and should, if possible, block this URL right login.haventac.com is not legitimate.
It exists, but it is not a valid email. an authentication endpoint for Azure Intra. It is possible and I don’t know how sophisticated your URL filtering is, but it is possible.
Seems really possible and doable to me that if you ever see the remaining URL string. So this right here, if you see this portion of the string associated with any URL with any domain other than Microsoft Online, dot Com, maybe you could block that.
That’s at least an opportunity. If you can’t block that, then this is a tremendous investigative opportunity to go back through end user browser history and look for what, look for that string associated with anything other than login.microsoftonline.com and that’s a pretty, pretty significant indicator.
there’s a question about conditional access. I mentioned, geo blocking. If you’re unfamiliar with conditional access, it is a security component of Entra. You have to have an actual entra license to use conditional access.
But conditional access allows you to define criteria for access. oddly enough, and geo blocking is, is not tremendously valuable, but it is sort of your due diligence.
Again you can stop authentication from occurring from outside of geographical regions in which you don’t do business. So that is, that’s a possibility.
The challenge here, and what I’m trying to illustrate on this slide, is that this is always a problem. The customer wants to know in the midst of active incident response investigation, tell me exactly when this first part happened.
And I say I can’t. First malicious authentication occurred at 7:12pm UTC. Do you see the 7:12 log stamp, date and time stamp for inter sign ins there at 7:12?
You see it? Yeah, me neither, me neither. this is, this is challenging. This is really frustrating honestly. but there you go.
we’ll look at some other mechanisms but that’s why we’re at step number three and unfortunately we’re going to jump to step number nine. A whole bunch of stuff happens in the middle and we have very limited visibility into that process, which is brutal.
And I’ll talk to you about the visibility resources momentarily. But from an M365 perspective we don’t get to see a lot of this, which is too bad. We’ve leaped all the way to step number nine and now we’re beginning to see the actual the actual authentication occurring in the context of the owned account.
Excuse me, clever threat actor. Once again, at this point, how do we identify that this is the real Patterson Cake or the owned Patterson Cake?
And we have limited clue if the threat actor is on top of their game. They have my username and password. They can mimic my device browser. They don’t often do that.
They don’t often do that. They could, but it costs them money. Most threat actors aren’t using a Windows 11 professional enterprise and a defined browser that’s managed, et cetera, that would cost money.
So chances are they’re not going to do that. So that can also be a clue. Thus the blue arrow MFA device. They can mimic that. They just stole a session cookie. They don’t care they had the session cookie.
It’s hard for us to do any identification or control the session cookie, frankly. And of course last but definitely not least, the source IP again in terms of detect prevent opportunities and sincerely stare at this for just a second.
I hope you can read that a little bit. Stare at this for just a second and do you see anything out of the ordinary? And sometimes I feel a little ashamed of the potential ease in which we go m what looks wrong here now?
Yeah, we’re nerds, we’re we’re proud of it. But how often does the average user go I decided to switch to Linux today. Yeah, Scotty Scripps is like I’m on it.
There it is. this is not rocket surgery as I like to say. They switch browser, they switched operating system and bam. And now we have at least three significant indicators.
We have geographical region associated with IP address. We have user agent string which indicates OS and browser. And we’re onto something. This is our first glaring indicator.
Okay, whoa, whoa, whoa. Something is wrong. What you’ll see here, and this is not discrete, this is not discreet. I’m sorry, this happens frequently. But this is a telltale sign of the proxied MFA auth and then session cookie theft.
The interrupted followed by success. That is not Again, if you see that, don’t freak out. That will happen frequently in normal authenticated sessions for a user.
At the same time it is an indicator that something may have happened. And so we’re looking right there for changes in user user behavior analytics effectively.
Excuse me, sort of. Our next major detect prevent opportunity is if you see the threat actor based on the previous indicators we are going to just hone in on these like laser focused.
and I almost forgot, I did forget. this is. This right here, this is potentially the most critical indicator of the entire expose so far.
Date and timestamp because we’re going to need to know when first unauthorized authentication occurred. And then we’re going to need to time box it. And we’re going to focus on these indicators.
The IP address, the user agent string, the geographical region. And we’re going to use those to identify the real me from the fake me. And we’re going to pay particular attention because we now know how the threat actors are going to behave.
Chances are they’re going to pivot to manage my account through my profile and my sign ins. And they’re going to add an additional authentication mechanism. This is me adding my Google voice number as an alternate mechanism for authentication in this account.
We want to find this and of course we want to remove it from the user’s account when we do. Frankly, these are your primary detect prevent opportunities.
I wish the list were a little longer. But the fact is if we can derive this information and if we can drive this information in a date timestamp, sort of a time box window, then we can move from there to identifying all of the behaviors that were not the real Patterson cake.
They were the owned Patterson cake. Once we do this, I strongly suggest that you cast a wider net. Right now we’re focusing on me. I clicked the link, I gave up my creds.
Please don’t fire me. Did anybody else succumb to this? Chances are I’m not the only person who got the initial email message. So once I derive these indicators, I’m going to back up and I’m going to look at our entire M365 environment and make sure that no one else fell prey to this particular campaign.
I want to talk about some investigative components and then tie up really quickly with a couple preventive things. Investigate investigative components, meaning how are we going to dig into this and find out exactly what happened?
And we have effectively a pretty finite list of resources. These are the resources that we have for investigating in the context of M365. It’s possible you have a third party logging solution.
You’re piping your data to SIEM. Doesn’t really matter. These are the sources of truth, even if they exist someplace else. We have inter identity, sign in logs. These are solid gold. These are the first thing that I want to extract.
I want to export these immediately upon any suspicion and that’s because they’re generally short lived. if you have a lower level license you probably only get these for seven days.
If you have a higher level license in E3, E5 you get it for 30 days which is still not very long. So I’m going to go to entra identity sign in logs. I’m going to export all of these. I’m going to export them generally in CSV and JSON format and I am going to be careful to.
Oh, man. I wonder if I can find this really quickly. Should have had this staged. Forgive me. Let’s do it.
Okay, really quickly. This is unplanned, but you need to know. Here I am. Let’s go to all users. Let’s go to sign in logs. Don’t pick this is my family tenant.
So be nice to me. here I am in sign in logs. This is my first stop. I’m going to go here. I’m probably going to start UAL export and then I’m going to go here. Couple really important things I want this but the first thing I want to do is go to columns and you see all the columns that are not selected yet.
Select them all please. I want all this information and I don’t get it by default. So security risky sign ins doesn’t matter. All user sign ins ends up in the same place columns.
Choose all the columns. Download. I want to download all of these. Interactive sign ins are most important to me. Non interactive sign in secondarily can also do audit logs.
Same exact scenario. Make sure you select all the available data. Look, I don’t get user agent by default. Lame. Check all the boxes, download all the files.
Even if you don’t look at these right now, keep them. Because again, you probably have seven to 30 days to accomplish this step. The next piece is M365UAL. I’m going to give you a resource at the end, so don’t panic that actually has more information on how to get to this.
This is theoretically all the logs you’ll ever need except for the ones that aren’t included, and the level of detail. So this is important. This is longer standing. You probably have this for about a year.
The next thing is exchange specific mail message trace, mailbox activities. I care less about these, to be honest. At this moment in history, mostly I want to see sign ins, I want to see ual, I want to see workload, activ access and what I mean by that.
So UAL quantifies all the components of M365 as a workload, SharePoint, OneDrive, Teams Exchange. So I’m going to focus my investigation right here.
Once I get to this point, we are going to probably have to do a deep dive into the mailbox. Message trace will help us. Invariably I want to know who did the threat actor interact with? What did they do from a Linus perspective, what email message it is.
As I mentioned, this is a particularly useful clue and it is almost always a component of BEC at the moment and that is inbox rule creation. The cool thing about this is that if you dig into this, this is a ual export in JSON unified audit log from M365 and it includes mailbox activities.
And the cool thing about this is because we’ve identified some indicators of where this happened, when it happened. Now we have a tremendous CL about the domains, the businesses that the threat actor interacted with in my example here.
Clearly they were trying to hide mail from some domain.com. so this gives me a beautiful pivot to dig deeper into somedomain.com in terms of what did I send?
I, probably need to reach out to them sooner rather than later. Find out if there have been financial transactions, etc. Etc. Significantly important, tremendous clue.
the business wants to know, they will always want to know. Tell me everything that they did, everywhere they went, all the information that they access, and then the UAL is your friend, unified, log is your friend.
We can look at SharePoint, OneDrive, Teams, etc. Etc. Again, no panic. I’ll show you a resource and I’ll walk through at the end. or you can come back on Friday.
It’s my workshop on Friday, I think so. And we’re actually going to step through this process. Enterprise applications. This is a little bit of a new one.
This is. Okay, I got into your mailbox, I’ve pilfered, I made an inbox rule, I’m engaging in transactions, I want some extended functionality and, or I want persistence. So I’m going to install an app in the context of Patterson Cakes account.
This is new and different. You might not notice it. What’s super important about this is that it does not necessarily occur in the context of my user account. Oh, bummer.
We will often see this associated with infrastructure, M365 infrastructure. And if you’re just looking for, if you’re filtering on Patterson Cake activities, you might miss this. You might miss this.
So my suggestion to you is, remember we have a date and time stamp, so I’m going to look at all enterprise application registrations in the context of this tenant. In the context of the date timestamp, there should be very few.
There might be none, but usually this, this is pretty infrequent. And so in this case, you can see I’ve registered the EM client application, which is legitimate. It is an application that allows me to synchronize the entire contents of my mailbox someplace else.
So threat actor effectively got the entire mailbox in this scenario, which is, which is a bummer, especially if you have a typical mailbox which contains 150,000 mail messages like everybody else.
this is, this is the technical term consent to application. This is the technical component that we want to look for in the ual. Did this happen?
Did the threat actor register an application in the context of this unauthorized activity? And this is what I want to see. Well maybe it’s not what I want to see, but this is what I want to ensure happened or didn’t happen.
And technically the log component is consent to application, so you want to pay careful attention to that. Again, within the date and time parameters of this incident, not necessarily focused specifically on my account, but date, timestamp, and then it doesn’t take a, great deal of effort to correlate this back to is this a legitimate application?
Should it have happened? Yes. No. And of course if no, then we’re going to want to nuke it. You’re going to want to remove this, this application impersonating the user.
this is, this is often final stage actions on objective are probably done. They probably already stole some of your money and now they’re going to pivot to sort of the Hail Mary of who else can we fish using your account?
And this once again is more your due diligence to go back to the UAL and to the mailbox audit log to say, but besides some domain, who did the threat actors interact with as Patterson Cake?
And this is, this is tough. This is a hard conversation to reach out to your customers, your business associates, etc. And say we’ve been fished. But it would be my strong admonition to you that if you were in a position to have this conversation, figure out how you’re going to manage this now before it ever happens.
Hopefully it never happens, but at least least have an internal discussion on how are we going to handle notifications, who’s responsible, what kind of phraseology are we going to put in there, etc. Etc. This is it’s a rough one.
Don’t like it. Okay, we’re almost done. deep breath. I’ve got an alerting, I’ve got a hardening, and then I’ve got a couple super useful end user educational slides.
We’ll see. this is huge. This is huge. Hearken to the sound of my voice. You have built in user behavior analytics in Entra.
It’s called risky sign ins, risky user behaviors, etc. As highlighted per this slide. I’m in the Entra admin console here. I’m under protection and security center.
And you’ll see I’m looking at risky users, risky workloads, risky sign inside. This is solid gold. Now it’s intermingled with A bunch of lead and coal.
but there is solid gold in there. And unfortunately what I see in most enterprises is this is noisy and prone to false positive and so everybody ignores it. My secret weapon.
Guess not so secret anymore. You call me tomorrow and you say, business email compromise. And inside I want to say, let me tell you what happened, but I don’t do that because I don’t want to minimize the severity of your situation.
And you say, here’s what happened. We engage, I get into your console, I start exporting ul and then I pivot to interest sign ins and I check risky sign ins. And almost invariably there’s an indication of exactly what happened right here in the logs.
And you didn’t know and you didn’t look and you weren’t paying attention. One additional component M you will notice. This is evil right here.
Do you see the status? This is important. This is super important. What happens is the customer calls, bad things happen.
Bec Patterson K clicked a link. I say often, first and foremost. Did you revoke all authenticated sessions? Yes, we did. Did you reset the password? Yes, we did. Okay, sweet.
Good place to start. Now we can begin our investigation. What happens when they reset the password is that it automatically. Intra automatically adjusts the risky sign in detection to remediate it and or dismiss it.
And so this now vanishes from the default console. When you’re viewing these alerts, these are not displayed by default. You find out something bad happens, you reset the password. You go look at these.
There’s nothing there. Bummer. You can see, you can choose to view. Can I do this really quickly? Sorry.
let’s try security, center, Risky sign inside. Check these out. Risk state. You don’t get to see those.
It’s that simple. Risk state. Check these boxes. Yes. Please sign in, type all checked. That will now display the events that we’re looking at. If you don’t have those by default, you won’t see them.
You won’t even know they’re there. I feel like I’m cheating when I look at those. But there you go, pay attention to these. You can do active alerting. Somebody’s probably receiving these alerts in their inbox. And again, probably 9 out of 10, maybe 19 out of 20 are not useful.
But you, you need to pay attention to these. these can be a tremendous indicator at the near the outset of potential exploitation.
Almost out of time hardening. This is stupid. Simple, stupid, simple. The box on the left, I am in Intra users user settings.
The box on the left represents M365 default. Effectively. You don’t even have to look at this. Just remember this. Go to this and change all of the defaults.
Toggle every single one of them to the alternate solution. It’s ridiculous. Thanks M365 Microsoft. do you want users to register applications? Well, no, I do not.
Do you want to restrict non admin users from creating tenants? That sounds like a really good idea. Yes, yes please. Do you want users to be able to create security groups? No, no please.
You get the idea. Stare at the slide. I’ll share the deck with you. You’re just going to basically talk. These are just common sense. You look at them and you go how could that possibly be the default?
Do you think it’s a good idea to restrict access to the Intra Admin center for non admin users? I think that would be good.
So check this out. And the really good news about this. Do not ignore change management. Do not ignore standard procedure in your environment. But these have zero impact. You can go toggle these probably middle of the day today and nobody knows, nobody cares and you reasonably significantly improve your infra security by going click click click click click the end again.
Don’t do that without some review and caution. But for the vast majority of enterprises I’ll have this conversation post bec and usually whoever I’m talking do so. Stop, stop, stop.
I’m pulling up the admin console now and making those changes. Sweet. I want, I want to have a slide. I want to have the next slide say silver bullets to keep this from happening.
And to the best of my knowledge there really there really aren’t any. There are a couple components that are important. Unfortunately you’re not going to like this one, but unfortunately I think the most critical component is the HI component.
It the human intelligence. Good old hi to the rescue. We have to help our users understand how this is happening and not from a super minutia technical perspective.
I have some suggestions momentarily. The other is that there are capabilities FIDO compliant MFA solutions do do some basic sort of browser certificate pinning kind of a thing that’s not accurate but the same kind of idea to the session cookie so that the session cookie can’t be stolen and used elsewhere.
Moving to FIDO hardware MFA tokens is hard. It’s a huge heavy lift and probably most enterprises aren’t going to do it. Stay tuned. Microsoft is working on components, conditional access components etc.
For right now. The due diligence things that we mentioned, the blocking of URLs, the educating your end user staff, et cetera are kind of your best bets. And then being on high alert, being vigilant, paying attention to these components.
So you can at least, least stop this before it goes too far. And then I want to make the user smarter. This is hard and I’m not picking on the users. I’m a user.
but I have some quick ideas and probably they’re not magical in any way, shape or form, but I really want to say three things to the user. I want to implant the idea, as per the opening slide, that electronic communications are not trustworthy anymore.
They haven’t been for a long time. But we don’t need to go there. If you’re old like me and you long for the days of classic Pizza Hut, you probably remember when for a while you’d get a phone call and the phone call would be from your bank and they’d ask you to give them your credit card or your Social Security number and you’d do it because you trusted in the integrity of the phone system.
Kind of inconceivable at this moment in history. And that is because we beat it in everyone’s heads repeatedly. You cannot trust. How do who you’re talking to? Mistrust, but verify if your bank calls.
I really doubt that the average user is going to say, oh, here’s my social. So I, I want to start just incorporating into my conversations with the users. I, I’m not so much into, don’t click the link, don’t do this, don’t do that.
I just want to say stop, stop, Think it through, think it through. Electronic communications are not inherently trustworthy, period, period.
And then I want to say to them, would you give your Social Security number away? Would you give your credit card number away? No, they wouldn’t. They wouldn’t. They know the value. Okay, then add to the list your password you do not need to authenticate for when it pertains to email, almost ever.
Almost ever. And if you do stop, pause, review, talk to it, whatever. Again, just the simple components.
Electronic communications are not trustworthy. And the most important three data elements in your life are your social, your credit card and your password. Last and definitely not least, multi factor all the things.
All the things. Define thresholds in your environment for critical decisions. Specifically when it comes to financial transactions. Probably don’t need to multi Factor a ten dollar transaction.
Maybe you $500. Can you believe that four and a half million dollar transactions occur via a singular, email For a singular individual in any environment that should not Happen.
Stop that from happening. Do something from a workflow perspective to make this much less possible, much more difficult. Define thresholds in advance, and maybe we’ve got a fighting chance of at least preventing huge financial fraud.
Okay, last slide. We made it. Extra stuff. let me show you really quickly because I hope this is useful. this is, GitHub repo GitHub.com secure cake.
and if you go to M365bec resources. I made a list. I made a list. And, I have a script for you for interacting with and extracting the Unified Audit Log.
I’m a huge fan of Soft Elk, so I have a link to Soft Elk. I have written, workflow instructions in three blog posts on the Black Hills Infosec blog that allow you to tie all of this together.
And this legitimately gives you a technical workflow for extracting the ual, pulling it into Soft Elk, and conducting the investigations that we just talked about.
In addition to that, if you go to this miscellaneous, wasn’t sure how else to do this, so what I did is just conglomerate a bunch of queries. This is me interacting with an M M365 tenant through PowerShell.
This is not API. It does not require a bunch of, advanced configuration. It just requires permissions. What permissions? You’re welcome. They’re all right here, specifically delineated.
You can look at that later. And this again is just me saying here’s a bunch of things I might want to know categorically with some comments about how do I ask questions of the user UAL to figure out what happened, what the threat actor did, etc.
Etc. Etc. In all sincerity, we’re doing a, workshop, on Friday, a pay what you can workshop, and we’re going to step through this as a lab to go through our demo scenario, pull the UAL, investigate in soft elk, etc.
If I don’t know you, if you don’t know me, then jot this stuff down. I want to be friends. anything I can do to help you here, I’m happy to do so. You have a question about the repo, about the blog post, whatever.
Talk to me, find me, reach out to me on discord, email, whatever. I like for this to be the beginning of the conversation as opposed to the end.
Although now it’s the end.
Zach Hill
It’s the end. Oh, no.
Patterson Cake
I went like two minutes over. That’s better than I thought I was going to do, to be honest.
Zach Hill
Oh, no, you, you have a, you have until your time. you’re good.
Patterson Cake
Okay. All right.
Zach Hill
You, have all these links that you include there. I made. I just made a playlist for you the other day on the Anti Siphon YouTube. I wanted to pull that up real quick.
Daniel Lowrie
I heard you talking about Classic Pizza Hut.
Patterson Cake
I’ll find that. I’ll find that you implanted the. The idea. Now I’m hungry.
Daniel Lowrie
I know we got to the backstage, I told Zach. I was like, so I straight up want some Pizza Hut today for lunch.
Patterson Cake
So true. So true.
Zach Hill
So I wanted to put, the link in the Discord for, the playlist that I had for you there. I’ll have to add this into that playlist now, too, once it. Once we’re done.
Awesome. Cool.
Daniel Lowrie
Patterson, you were talking about Fido. Fido keys. I just want to grab them while I got you here. Real quick, do you recommend a specific Fido device that seems to be the most useful, Convenient, whatever.
Patterson Cake
That is a fantastic question. And we started this webcast with transparency, so we probably should end with transparency. It has been a long time since I had any direct responsibility for Fido, key implementation.
And I’m talking back in RSA days. RSA FOBs, I don’t really know. I don’t have firsthand experience. I’d welcome input, obviously, from the audience, because I have not been responsible for implementing or managing that.
And again, to be frank, every enterprise customer that I’ve had this conversation with, one or two things come out of that conversation. One, we’re not going there, or two, we’re working on that initiative, and I’m still waiting for someone to say, we already did that, or we have a fantastic solution.
yeah, so, yeah, sorry.
Daniel Lowrie
it’s a good. It’s a good answer. It’s a good answer. Right? Like, there’s a lot of options out there, and maybe it’s very subjective. Maybe this is the right Fido solution for you and not for everybody else. it’s a one fits one kind of solution.
So very cool. Thank you so much.
Zach Hill
Yeah, thank you for taking the time with, today to. To share your knowledge with everybody, man. just looking at the. The discord, everybody’s just loving what you, presented today, which I knew that they would love it.
You’re a fantastic instructor and presenter, man. So we do appreciate it. thank you.
Patterson Cake
Someday I will advance to the ability to actually be able to pay attention to the Discord while I’m teaching, but not today.
Zach Hill
Yeah, that’s a Talent, it takes, takes a lot of practice for sure. Definitely. do you have some time for a few questions?
Patterson Cake
Heck yeah.
Zach Hill
Awesome. Cool. So, this, this question came back about halfway through. but they were asking just sign in frequency, not break the MFA token. That rings a bell to point your slide.
Patterson Cake
So some of that is manageable and some of it’s configurable and some of it’s not. And we have the typical conundrum, which is you can actually force the users to have to re.
Authenticate every two and a half minutes. Right. I mean, and then you’d get fired. so it’s that tug of war and finding the right balance between.
Think about it. Just simplistically think about how often are you presented with an MFA prompt for authentication to your M365 environment. Whether it’s Outlook or whether it’s, webmail, on your phone.
Think about that for your specific environment and then think about, could you, could you minimize that? Would it disrupt end user behaviors to a point where again, you lose your job?
it’s a real cat and mouse, give and take. And I’m not sure the right answer for your environment, but it is something, I think it’s a valid, A valid security control for you to stare at and think, how do we manage this?
How do we strike the right balance between making the threat actors lives difficult and And I am tangentially a huge, huge, huge fan of conditional access policies and trusted network locations.
If you can define those for your business, you get all sorts of leverage for bifurcating, you’re outside of the org. Sorry, things are going to be more complicated. That’s just the price of doing business.
You’re inside the org. Sweet. And whether that’s behind, a VPN address range or an actual enterprise IP address range or grapple with that a little bit. That is a built in component of conditional access that I think is worth, looking at for sure.
Great question.
Zach Hill
I could not imagine being prompted every two and a half minutes or whatever you said.
Daniel Lowrie
My gosh, Patterson. Speaking from experience, I remember I was a young admin one time, said let’s turn the wick up on these things, see what happens.
Patterson Cake
I’ve made, I’ve made one or two mistakes with conditional access policies, to be honest.
Zach Hill
But yeah, yeah, so that brought back like a trauma memory for me. Not that it was MFA related, but I was working at the hospital at a time and we had to send an alert out to all of our staff about one of our systems being down.
And it was supposed to just have the alert, pop up in 15 minutes. Instead of having the alert pop up in 15 minutes, it showed the alert for 15 minutes.
And it was one that you couldn’t close or move away. I don’t know why I just thought of that, but gosh, yeah, that was quite the day.
Patterson Cake
Learning opportunities right there for sure for.
Daniel Lowrie
Me was when I said, let me take all these production servers and stick them in the wrong WSUS update group. And they rebooted during the day.
And then I got a phone call. I was like, hey, could you come in here real quick? I was like, yeah, what’s up? They’re like, so fun times. All the servers rebooted. I was like, oh, no.
Yeah, so we had a good conversation about that. I remember it ending with like this, I made a mistake. I’m sorry, I guarantee it will never happen again.
Zach Hill
Yeah, that was the same conversation I had.
Patterson Cake
Yeah, sounds familiar.
Zach Hill
Jake has this question. Do you have any other good IOCs? we should be tracking in general other than unknown device, anonymous ip, outdated browser, tracking and alerting on.
Patterson Cake
So, so if I were going to give you two of the most high fidelity indicators that we’re seeing right now. Number one, number one is inbox rule creation period.
And I say that specifically because the most common name for threat actor created inbox rules is a period. What human being makes an inbox rule named period?
Nobody. So one of the most high fidelity alerts that we implement right now for our customers is short named, I mean like 2, 3, 4 character random named Inbox rule creations.
They are almost always an indication of a compromised mailbox. Not, not unequivocally, but almost always. So that is huge. And if you can do that, if you’re piping your UAL data to your SIEM or something, you need to implement that rule and you need to do it right away.
The next less clear one is a, handful of user agent strings. How many of your users are using the Yandex browser?
Daniel Lowrie
All of them.
Patterson Cake
I mean, you never know. If you do business in Russia, then possibly that’s not a good indicator. But for most enterprises, most US based enterprises, Yandex is not commonly in use.
Yandex, Python, manager. Forgot the third one that we saw a couple weeks ago. but better, better solution, go to your intra, export, your sign ins, export the user agent string list, sort and filter and look for weird, look for Normal.
Define what your business looks like. Do you use a standardized browser? Probably you use Edge, Chrome, maybe Firefox. And then it’s a pretty tremendous potential opportunity to look for other UAL strings that fall outside of normal.
again, for better or for worse, there’s going to be some variability there, but those are the two big ones. Geolocation IP address. I wanted to mention, and I forgot because too much content.
When you find an IP address, you find evil. IP 44, 12, 37, 24. I made that up, by the way. The next thing you want to do is pivot to the asn. What is the ASN for that?
That is, the overarching designator for that. That, isp. Threat actors are just like you and I. They probably have a singular isp.
So if you can look at asn, which is included in many of your UAL logs, and, or you can reference that pivot and look for that ASN elsewhere in your environment, because that may be a totally disparate IP address space, but it’ll still have the same ASN and the threat actors hang out in those spaces.
that’s, also a, an incredible clue, in your investigation. Great question.
Zach Hill
Have you, you seen any successful bypasses of Fido 2 keys for M365 or in general, other than physical access?
Patterson Cake
I have not, responded to or investigated any FIDO key bypass events. again, that, that’s my, my personal limited experience.
But, but, but, no, no. And, and, once again, here we are. Cat and game. Cat and game. I just made up a phraseology. So this is a cat and game mouse.
Let’s, let’s make it harder for the threat actors. I am, I won’t be shocked at all if we all move to Fido keys tomorrow. They’ll find a way around it. Right? I, mean, that’s just where we are. But you can be one step ahead if you move there before everybody else.
Yeah, that’s, that’s. Yeah, it’s the old analogy of, of the two people in the woods and the bears chasing the two people. And one stops and puts on running shoes and the other says, you can’t outrun the bear.
And they say, I don’t have to outrun the bear. I just have to outrun you. Tremendous cyber security parallels. Be less attractive. Be a less attractive target than everybody else by moving to FIDO tokens first.
Easy for me to say. Awesome.
Zach Hill
I got time for like, few more questions here. there was one I just had pulled up. Have you seen any success? Oh, no, that was the one I just read. Sorry, that was this one.
Oh. Do if entre can be configured to require an MFA challenge to add, delete, modify MFA authentication methods?
Patterson Cake
Boy, that’s a fantastic question. I, I can’t remember.
I don’t know. I don’t know. I love that thought. and it seems like there is a component that can enforce that at the MFA registration piece, but I can’t remember off the top of my head.
so fantastic question. Stop asking such hard questions, Stump M the instructor.
Zach Hill
I love it. this person Nerf, is asking. I know what Windows hello for business is Fido. Any appreciable difference between it and Fido 2 key like a Yubikey?
Patterson Cake
The the answer is once. again, I, I honestly don’t have enough tactical, tangible experience with pros and cons and differentiation there.
I, I think that they are generally on par. again, the challenges of deployment and management and I don’t know and I’m frankly grateful that I don’t have to wrestle with those things.
so again, I think the overarching solutions are pretty close to on par. How you go about implementing and managing them is a huge question mark in my mind. like I said, that not in my purview, thankfully.
Zach Hill
M. No problem. All right, we appreciate you again coming here, joining us, sharing your knowledge with us as always. you have your workshop coming up this Friday.
Do you want to tell us a little bit more about that before we get kicked off to our breakout room?
Patterson Cake
absolutely. Yeah. So for better or for worse, we’re going to go through this context again. I have built, effectively have built a business email compromise scenario through great effort, in a tenant, to mimic all the things that we just talked about.
And then I’ve exported the ual, I’ve created a soft elk VM for you and I’ve created a couple labs where we’ll go through this conversation, we’ll go through a little more technical specificity on the detection and investigation and then we’ll culminate that in a, in an actual hands on lab using soft elk, using the soft elk user interface to investigate UAL and pull out the important components of a business email compromise.
And this is, this is a legitimate IR workflow. This is, I do part of my job. this is not just a, an expose and do, hey, here’s a cool tool. This is legitimately a workflow process that we use to rapidly investigate business email compromise.
And I, I want to share it with you. Awesome.
Zach Hill
Thank you, M. Man, I’m really looking forward to it. I’m excited for it. I will be there to join you.
Patterson Cake
Awesome.
Zach Hill
and join everybody else. again, we just put a link in the discord for your workshop, so if you guys are interested, definitely come and check that out.
Patterson Cake
Patterson.
Zach Hill
man, thank you again for being here with us. Appreciate your time. Wonderful. If you guys are sticking around for our breakout room, we’re going to be open up that room here in just a second. That’s if you have your Zoom application installed on your device.
At the bottom of your screen you should see a little button that says breakout Rooms. And there’ll be a section there for ama. you can join. Daniel and I will be in there and to, try to answer all the questions that you might have.
Patterson, if you have time, you’re more than welcome to join us as well. but until, what next week, we will have. Let’s see. Tim Medine next week. So, we’ll see you then and, hope you all have a great day.
Take care everybody. And, see you in the breakout room or see you next week.