So we've talked about what we can do to prevent a business email
compromise or some of the things that we can do,
but there are companies that are probably being affected by this right now.
So let's talk a little bit about business email compromise detection,
what we can do in order to detect an active compromise.
But before we do that, Aaron,
do you want to talk about what we've done here to
kind of demonstrate some of this?
‑Yeah, absolutely.
So let me let me talk for a second about it then we'll
probably just jump in and I'll show everybody.
But I think the important thing is that we wanted to
have something to show everyone.
But at the same time,
you can imagine having an entire in Office 365 enterprise that
looks realistic is probably pretty difficult. So there are options
to be able to do it for a free trial, and that's what we used.
We built a free trial environment on an E5 premium license for Office 365,
and we also have the Active Directory Premium 2 license,
and that's part of kind of the free trial ecosystem you can do
for 30 days to set it up and practice it.
So you absolutely can do that at home. If you want it yourself,
we'll include that link and some of the resources.
I think that'd be a good idea.
So if you want to set this up and test it,
you can make users and just let me show what it looks
like real quick when we do that.
When you first make this environment,
you're going to use another Outlook account and then
you have to make an admin account.
So it's very much tied to Active Directory and Azure,
just like everything else is.
So Office 365 still has that back end for authentication.
And when you get in here, this is my landing page for arosenmund@,
our domain that we created for Globomantics,
our fake company.
What you want to do is go to the admin portal,
and when that loads up,
you get a bunch of different things that you can use to set up security.
One that we'll talk about, you see that it just went away.
It's because it's already set up.
So a little bit later, when we get into the end of this,
I'm going to show some slides about different things I had to do as I built
this that you're not going to be able to see right now.
But it's it's checkboxes and turn this on and turn that on that allow,
if you have the correct license, for you to enable these protections.
They're not on by default,
and I think that's a common thing we get with Microsoft stuff.
Like, oh, yeah, you could defend yourself against this,
but it's not on by default, so you've got to turn it on.
That's something we have there as well.
You see how little actual user activity we have.
But this is a least one way to look at what users are logging in and out.
I did want to look at this user management,
so we can look at edit user,
and I can show we do have about five or six users that we've created and
sent some emails around just so there's a little bit of a realistic
environment and logins that we can use an example.
So that's really where we're starting from,
and if we look at this Show all piece here,
we can go and see that there's a security component,
there's an Exchange component.
There's admin panels for every single component of Office 365,
and that's something important to know too.
Before we jump into detections,
I wanted to just show that real quick so everybody can see
the environment that we're working with.
And it's a real live Office 365 environment,
a real boy, so to speak,
and something we'll be able to‑‑‑if you go to it as a
user in your enterprise environment,
this GUI will look pretty much exactly the same.
‑Yeah, and that's a great point too.
You want to get familiar with this environment,
too,
because as we've seen in doing this over the last couple of weeks or
so and in all the investigations that I've done,
Microsoft likes to hide a lot of things,
and so there's like 3 or 4 different interfaces into all the Azure
and Microsoft 365 and Office 365 components,
some of which show you some of the information and some of which don't.
Ao absolutely get in there,
get familiar with where these things are so you can
jump into it when you need to.
So we we talked about the lifecycle of the business email compromise,
that the initial attack is going to be through phishing.
So what would you use in this to detect a successful
phishing attack against one of your users?
Yeah, perfect.
And that was a bit of a learning curve for me with the enterprise environment,
too.
But what's interesting is, if you think about the logic of phishing,
again, that's the component of it that we're all very used to.
It's not different.
What happens after your users are phished?
They give their email accounts and their passwords out.
And like you said, sometimes you've seen a 4‑second difference,
and then that attacker then takes that email account and logs into the domain.
Now, there's standard stuff we can use to try to detect that.
Though it's a bit of a different environment in which we do it,
it's the same idea.
This user logged in over here, and 4 seconds later they logged in over here,
and that's weird.
So that's one of those,
the geolocation or the geofencing or just kind of anomalous
logins from different locations, either in the same country
or in different countries, it's something that you can use.
Now, I know that the ability to pop that alert comes in a couple different place.
And as I‑‑‑feel free interrupt me, Tyler, as I look through this.
You generated some traffic that allowed us to be able
to detect that post compromise.
So phishing's already occurred as we're coming into this environment,
and we want to look at detections.
So that initial event and the login from a bad actor has already happened.
They've probably also set up some stuff that we'll look at it a little bit too.
But we want to go ahead and look and see what can we
do to detect it visually here.
And we'll have some other stuff for some tooling to
be able to do it too in a bit.
But first place it makes sense to goes security.
So want to look here in security.
This isn't where we're going to find those additional login logs
because it's through Azure Active Directory,
actually.
But, and this is the main point here is, I want to see what we don't see.
I've already looked at this, obviously in prep before we got into this.
We do see some alerts here.
I don't know if you want to talk through what this alert probably is here.
‑We'll definitely get into that in a little bit.
‑We do see some alerts,
but what we don't see is any alert that has anything to do with a
successful login or that geolocation login change.
I think that's that's kind of what I wanted to point out is,
you can get in here and see that that's not there.
We can get into threat management.
A really good learning point, just kind of a gotcha here is,
there was malware here because I threw malware through this ahead of time.
It's not there anymore because it only goes back a week.
And so I went back,
I kind of struggled with that a little bit last night
trying to make sure this worked.
And sure enough,
it only has that week of data that it will represent to you at any given time.
And again, what's missing here is,
there's no alert on odd logins or risky logins.
Now,
that phrase I used you can find somewhere else, but these are
really the places that I would hope they'd pop up.
It's kind of like the logical, oh,
if I click Security and go to Threat management,
maybe there's the threat there.
It's not there.
So let me get back out of this.
I'm going to go back to this admin console so I can see the other locations.
And like I said, this is running on Active Directory.
So when we look inside Active Directory as the admin panel instead,
we get a bunch of other stuff.
And, again, no alerts here, but you can see kind of sign‑ins over time.
We're getting closer.
This is us getting warmer on where we're trying to
actually look for what we want.
But other than that, there's no specific security stuff straight on this portal.
You can, by the way,
just click on this and it takes you straight to the place I'm about to take you,
but this card's not always up.
So you can add cards to and from this location.
I kind of figured that piece out.
But on the left here,
and this is what Tyler showed me the other day, if you go
here and look down under Monitoring, you can see Sign‑ins and Audit logs.
Audit logs, I'll let, probably,
Tyler talk about that a little bit after we go through sign‑ins.
But audit logs are where we can see some of the
different activity that's been taken.
Sign‑ins is what we're looking for.
So we click Sign‑ins.
That card is the representation of these sign‑ins that we see here.
‑Yeah, and while that pulls up, we're basically,
once that comes in,
we're going to be looking for places that the user
wouldn't normally log in from, so like you mentioned,
different geographic locations.
So if I'm based in the US, I shouldn't see logins from around the world.
‑Yeah, absolutely.
And even, it's probably also okay,
and and we'll get into this in a little bit when we
talk more about specific detections.
This'll kind of go from more, oh, they logged in from different locations,
to more of the behavioral science of it.
But it's even okay if you log in from different places in the world if you
have customers that are in different places in the world.
What's not okay is if they log in in one place and then travel
faster than the speed of light to another place.
So they're not only breaking physics,
they're also breaking the fact that it could actually be them.
‑Exactly.
Here is where we can see all these logs.
So I just know them because we've already communicated this,
but the impossible login that were concerned about has happened previous.
‑Yeah, so if you go up to the top and you filter by user,
if you add a filter and, let's let's look at the user,
I think it's Kim.
Kim is the one who in our situation here has gotten compromised,
or at least one of the users.
‑Here's one way of doing it.
You can also, and want to talk about it first,
we're going to kind of like easy button it for you.
We know it was Kim.
Here's Kim doing it.
On an enterprise, obviously you have all of the users logging in,
and you'll want to pull all that information,
so we'll show that in a bit too.
‑So in our case, Kim normally logs in from New York City.
So the ones that we're seeing here are definitely something that's normal.
And then all of a sudden, we see her logging in from Vietnam.
That's a little bit odd.
And if you look at the date and time, just like what you were talking about,
there is really no way that she could physically travel from
New York City to Vietnam in 7 minutes.
If she does, I want that plane or car.
But in this case, this is definitely,
should be hanging high on the red flag meter.
‑Yeah, absolutely.
So this is where, unless this is specifically set up,
that threat's not going to pop up anywhere for you.
And again, even if it is specifically set up,
we have the E5 license, and a lot of customers don't.
So yeah,
I can for sure go to advanced threat protection and configure
the rule to make sure that this pops out.
It may be now, the fact that we didn't see it,
may be that it's actually already enabled.
It just has to happen four or five times or something.
Probably some rule like that, that before it shows up as an alert,
just to get rid of your noise.
If you think about an organization that has 300,000 employees,
that it's going to get kind of noisy.
‑And so when I'm going in and I'm doing in a BEC investigation,
this is the first place that I look.
I want to see who's logging in and where are they logging in from.
Something like this is going to pop out immediately.
And this is absolutely something that you can do,
or anybody who has Office 365 or Azure administrative privileges,
they can look to see where their users are logging and from.
The thing to keep in mind, attackers, again, these attackers are smart.
They know where you're based out of.
So we have seen attackers that will do things like,
they'll initially log in from a foreign country,
and then once they see that that login works,
they immediately switch and go through probably Tor or a third‑party VPN or
something like that to come from another location in the US.
But you still need to go back to your user at that point and say,
all right,
here is a list of all the places that you logged in from into your email.
Which of these are correct?
Which of these areas have you been around and have you not?
And so Kim here, she logs in from New York.
Well,
the attacker could switch and start logging in from a
VPN whose endpoint is in Pennsylvania.
So at that point, those Pennsylvanian logins tend to be suspicious as well.
The one thing that I'll throw out too is,
you have to do a little bit more research too.
GeoIP locations, like we're seeing here, is not an exact science.
So just because something,
just because Microsoft is telling us that this IP address is in New
York doesn't necessarily mean it actually is.
Run it through some other geoIP services just to verify.
See who the ISP is because if it's a cell phone network it's also possible
that Kim jumped onto her cell phone to check her email,
and for whatever reason the cell phone company was routing
it through Pennsylvania at that time.
So keep those things in mind as well.
That brings up another good point,
especially as we have a lot of people that are more
remote and VPNs are becoming a thing, where they try extend the boundary saying,
hey, you can only do business work while you're on a VPN.
I know there's a ton of companies that are doing that now.
What's interesting is the VPN will also change this.
So what if you are traveling somewhere else and,
I guess, imagine the situation as an administrator for this.
You see a log in from New York, and then you see it from Pennsylvania,
so your company's supposed to be in Pennsylvania.
Well, clearly they logged in, forgot they were supposed to go through the VPN,
logged out, and then logged back in through the VPN.
So even if that's a policy thing, that can be used as a policy enforcement for,
I see you operating not on our VPN.
That's probably something you shouldn't do,
which almost makes this more monolithic.
If everything's coming from the exact same location,
that means everybody is in your VPN.
I can now alert from anywhere else means they're not using the VPN,
which is an interesting thing I didn't think of
until we just talked about it now.
‑Yeah, and it really goes back to‑‑‑also,
you need to talk to the use when you're doing these types of investigations.
You need to have those conversations.
And I know we're computer people.
We don't like to talk to other people, but in this type of case,
we absolutely need to do that.
Because if I was working this investigation,
I would basically pull out all these IP addresses,
put them in a spreadsheet and send them to Kim and say,
hey, obviously, Vietnam, you weren't in there.
But were you in New York?
I would try to get a better geoIP location as to just New York, New York.
I'd want to know a little bit more specific than that,
and there are tools to do that.
I would ask her, were you around this area at this time?
And I've done that investigation, and I've had people say,
oh, yeah, my boyfriend's house is in that city or right next to it.
So she had, in that case,
she had just gone to her boyfriend's house and checked her email there.
So you can mark that off as legitimate.
And slowly you're starting to whittle down where the attacker logged in from.
And the reason that's important is because not only are you
showing which authentications were malicious or related to the
attacker; you're also now getting the time frame from which they
were actively accessing the email, which can be important as well.
‑Yeah so that ties to a bunch of stuff,
especially once we get into the response here in a bit.
This is a, if this becomes interesting, this is the IP that you want to record,
and then we can use that as part of the rest of the response.
But also, like you said about the time,
that then goes all the way back to what did they have access to?
Well, that really depends.
If we don't have the fidelity,
then they had access to everything that this user had
access to during this time period,
so time period becomes really important for that as well.
‑Good point ‑Exactly.
And you can show, if you export these logs or if you were to export these logs,
you actually get a lot more information than what
we're seeing on the screen here.
You get things like user agents, as well as for the program that was logging in,
and sometimes you can use those to find those malicious logins as well.
So, for example, if Kim always used Chrome on a Windows PC,
and then all of a sudden you start seeing user agents for Firefox on a Mac,
then that's another one of those indicators that you can
use to kind of pull out the malicious, or at least suspicious logons.
‑Yeah, that's a really good point,
and I'm glad that you brought up exporting these logs,
because, so just like last, I don't know if you remember last time,
so people who are watching these back to back it'll be a
little easier for them to figure it out.
But just like last time, I'm always trying to impress you.
I don't know what the deal is, but I'm like,
all right , I'm going to go meet Tyler, I'm going to bring something out.
But you have this poker face, and I'm like, oh, I thought it was cool.
We'll see whether you think this is cool or not.
So we'll see.
What we didn't have is an alert.
And even with the E5 premium license,
I'm sure there's some setup I'm missing or whatever.
But if if you don't have an E5 premium license like many don't,
you at least do have this Azure,
you have some sort of premium version of Azure that will give you this log in.
‑Yeah,
and we'll talk about the license levels and what you can
and can't get with those later on.
But with, at least in my experience so far,
and from what I can tell,
all license levels will at least give you these sign‑ins.
That will always be there,
so you can at least go in and determine this information.
‑Awesome.
Well, so I looked at this knowing that and said,
hey, what this really looks like, I don't know it's Kim.
When you when you did it, I don't know whether it's Kim or not.
I'm just looking at all of the logs.
And this is only five users that two people logged in as,
and that's that's a ton of logs.
And so what's interesting is if you have 100,000 people that are logging in,
that's even more stuff to worry about.
There's no way you're going to scroll through and say, oh, that's weird.
They've logged in here and then here.
If you found that, that'd be pure luck.
I'm sure there's a ton of other tools to do this,
but I always default back to PowerShell,
and I did notice that there's a way, like you said,
to export this information.
So up here in Download, I just picked Download.
Now, something I did find,
and maybe we'll make a note of this somewhere else too,
is that Azure AD preview module for PowerShell actually has a function that is,
Get‑AzureAuditADSignIinLogs.
It's not quite working yet,
and last night some of Azure wasn't working very well either.
And so that didn't happen.
But either way, the stopgap is, or the idea is,
you can download these things periodically and then run something to check it.
So I downloaded the CSV within the window that I knew we had logins,
and then let's see if I can switch this screen.
Good.
And then I wrote this PowerShell script.
And you talked about it having more information,
so I wrote this component to just kind of pull it in and then sort that object.
So now there's going to be people watching that are really,
really good programmers and devs and way better at this than I am.
But I default back to this just to kind of whip something together.
Part of the point of me doing this when I do it is that I woke up this morning,
felt like I wanted to do it, and had it done in about 30 minutes.
And the fact is that if I can do that in 30 minutes,
if you take some effort with your weeklong job,
you can start creating detections that don't require
you to have some tool to do so.
So that's part of my soapbox for why I do this sometimes too.
Anyway, so the point here is that we pull that information in.
So let me see if I can granularly run this.
Yeah, so that runs.
And then I want, like you said, let's look at what those sign‑ins give us.
And it's going to give us all kinds of stuff.
Oh, I had already sorted that.
Let's look at just sign‑ins.
Signins, there we go.
Okay, so a ton of stuff, but I wanted to kind of point out what you had said is,
here there's much more than what we saw in the logs originally.
And then there's the operating system, as well as the browser.
And so that's exactly what you were talking about before.
I just wanted to point that out for everybody.
‑Yeah, and remember too,
I think people should keep in mind that this is the user agent
string that's being sent by the attacker,
so that can easily be spoofed.
That can easily be changed.
However,
the likelihood of the attacker actually figuring out the exact user
agent string that the user is using is pretty low.
There's a low probability of that unless they have compromised the user system,
which does happen.
It's rare, but it does happen.
But I would say 99% of the time user agent strings in these
attacks so far have not been spoofed.
Or if they are, they're at least different enough that you can tell.
‑Yeah, absolutely.
And again, we're talking about,
and this is something as we get more and more into detections,
the first step of detection is, oh,
it's pretty suspicious that we have logins happening really close to each other.
Now it's triple suspicious because that happened and it's different user agents.
And you just kind of keep narrowing down the probability
that this is something actually malicious.
So each one of those things is just a good indicator.
So, speaking about that, what I did want to do is be able to look at something,
and we don't have to go through every piece of this,
but I basically split out the city, state,
and country from that location.
And then I said, hey, if you're traveling,
I just did state, and I wanted to show the example for just state.
I just did state.
If you change states within 30 minutes of your last
login and it does it by user.
So it looks at every user and then sorts all their logins by the date and
then loads that last login and then checks the next one.
That's essentially how this is working.
And then it says if the difference between those times is 30
minutes or less and the state is different,
that's an alert.
So that that's what this is doing.
Imagine you can do that for country, you can can do it for state,
you can do it for city.
And you can just change, right here you can just change,
oh well, if they traveled and it's less than 2 days or it's less than whatever,
you can change the amount of time that it's reasonable
for someone to travel between cities, states,
and countries.
Now,
this is obviously not as good as‑‑‑it took the geoIP and then did
the Google API to figure out what the distance between them was and
then calculated the time that it could be and then checked it
against the time it would actually take to travel at fastest speed
of a plane or something.
That is doable.
It's something that you can continue to develop,
but this also kind of got us where we needed to be.
So if I run this whole thing now, let me just run it all,
it'll probably totally not work because it worked every other time,
because that's how it always goes, but we'll see.
There we go.
It worked fine.
So when we run through this,
I always give myself more verbose stuff than I need when I do outputs.
But it says, hey, it's the same location,
we don't need to worry about this, and it doesn't for every user.
And then look at that. We can see Kimberly gets alerted
because she's been doing some impossible travel,
according to her last logins.
So this is something, we'll provide this in the notes.
This is something you can use whether or not you
have advanced threat protection.
You can pull these logs down and sort through them,
and you can set this up to happen every day,
and you can tune it to your environment.
So there you go.
That's my surprise to you.
‑Yeah, that is very cool.
Yeah, and I think that works great.
And that's good to look at as well,
because you're using PowerShell to kind of sort all
these logs for us and and pull that out.
In my experience,
if one user is compromised in a business email compromise attack,
there's another user,
or there are multiple other users that have been compromised as well.
And the attacker may have just logged in as them once and are saving those
in case their access to the current one gets taken away.
It's kind of like their secondary backdoor,
their sleeper backdoor that they're going to use later on if they need to.
‑Yeah, absolutely.
That makes sense.
And I think you have some pretty cool stuff to show about how
to track down what else they have access to.
Sometimes I see that stuff gets missed a lot is,
we detected the one thing, it happened, let's do our incident response.
And we're like, oh, no, no.
You now go find out all the other stuff they had access to.
‑Yah, absolutely.
If we go back and start thinking about the way that
business email compromises work, one of things that we mentioned that they do is,
once the attackers get into the account,
they are going to set up inbox forwarding rules to send emails out
to themselves so they don't have to sit in the email all the time
waiting for those emails to come in.
They can just kind of sit there and wait for the emails to come to them.
They don't need to be active with that.
And there are a couple ways that you can go and find this information out.
So right now I'm in the security and compliance portion of Office 365.
If you want to access that directly, you can just go to protection.office.com,
and it will show you this.
You jumped into this when you were in the admin portion by clicking on security.
So there are multiple ways to get into this.
So the first thing that we can do is,
Microsoft obviously is seeing a lot of this,
and so they've started to generate alerts because of
the forwarding rules being created.
And we can see here, if we go into the alerts and click on them,
we can see that there has been an alert created regarding the
creation of a forwarding or redirect rule.
And if we start looking into this, what it is,
we can see that the alert was triggered,
which means that email was forwarded out for our username klogan,
Kim.
So this is giving us an alert that something has happened
that a suspicious forwarding rule was put into place, or
created, in this user's email account.
It could be legitimate, depending on your policy.
And the interesting thing that we found out when we were setting all this up is,
by default with new Office 365 installations,
external email forwarding is actually turned off by default.
You have to either go in and allow it per user or allow it globally.
So this is something that's going to be turned off.
So chances are, though, somebody has gone in and turned this on for most users.
But this is one way that you can kind of detect this.
So let's say this alert wasn't here, or you weren't sure,
or you were coming into an investigation where they had either
suppressed these alerts or they were just ignoring them.
Where else can you go?
The alert is great,
but I want to see the raw data because that's what I'm going to look through.
The way to do that within Office 365 is to go down to Search,
and then go to Audit log search. And audit log search is
going to allow you to run a search across all the audit
logs that Office 365 is compiling.
Now, again, what you get to see depends on a couple different things,
mostly your license that you're using,
and we'll talk about that when we talk about response.
But I want to go in and I want to see what inbox rules were created.
And so the way that I can do that is, first thing I'm going to do is,
I'm going to set the start and the end date.
I'm just going to leave those as the defaults here.
And I can go ahead and click Search, and if I do that,
it is going to go and just show me everything.
It's going to show me all of the events that have taken place
throughout all of the time that I was in,
or that this Office 635 installation has been up,
or at least the last 7 to 30 days, depending on your license.
That's going to be a lot.
We don't want to go through every single one.
So what I'm going to do instead,
because I'm just looking for suspicious inbox rules,
or the creation of some, I'm going to go to the filter here.
I'm going to‑‑‑so instead of doing the Show results for all activities,
I'll go in here and search and type inbox, and here you
can see there are three that come up, Newinbox rule,
create rule, Set‑inboxRule, or Update‑InboxRule.
So I'm just going to select all three of those.
All three are selected.
You can tell by the 3 here.
And then I'll just click out.
Oops, sorry.
I'll just click out and then click Search again, and boom.
We see that there were three inbox rules created for klogan,
or at least three, I should more specifically say,
there were three audit logs related to inbox rules
either being created or modified for Kim.
And so I can go in here, and I can open this one up,
click on the detail, and scroll down.
And first thing you should notice is it shows us the client IP address.
This is the IP address of who set that up.
And if I remember correctly, that should be our Vietnamese IP address,
the logins from the attacker.
But more importantly, if I scroll down here,
I can see what the rule actually is.
So here it's telling us, all right, we've got this Outlook rule,
we have the ForwardTo name in the value of kimberly.l0gan,
where the o is a 0, at protonmail.com, not her corporate account.
The next value is Move all messages from the Customer Globomantics to Inbox.
So in other words, as emails come in, they're going to be moved,
or this rule will apply, and the action for this is BodyContainsWords.
So in other words, if the body of an email contains any of these words,
wire, wiring, fund, invoice, funding, bank,
banking, payment, any of those,
then that email gets forwarded out to this protonmail account.
‑Yeah, that's amazing.
So this is a really, really good way‑‑‑so first we started out with phishing,
account was compromised.
To kind of catchup on detection‑wise, we can detect malicious logins,
if we do detect mint malicious logins, probably should go and see,
or if we missed the malicious logins,
because maybe they logged in from the US with a good account,
whatever, if we missed that, here's the next thing we can use,
detections.
Let's go look through our inbox forwarding rules,
and we start making alerts based on that too.
That's that's so cool.
‑Yes, and understand that the alerts that we saw here,
or the audit logs that we saw here,
these get generated when a new inbox rule is created.
When we talk about response in the next clip,
we'll show how to actually pull all of the inbox rules that are already
existing so you can then go through them and look to see, well,
which ones are forwarding to external email addresses,
which ones are doing these kind of weird things looking for these
specific words in an email to do something with them?
‑Yeah, and even start doing some regex on that to look for,
hey, does this match our domain or not, or that kind of stuff?
That makes a lot of sense.
‑Yeah, absolutely.
Do that.
Load it into Excel.
Load it into an ELK stack.
Do whatever you need to in order to manipulate that
data in order to find what you need.
And so this is just one of the rules.
If I go out here, let me close this out,
and I go to the next one, and we go down here,
here we see something a little bit different.
Again, this is in Kim's inbox for her emails.
But in this case, we're not forwarding the emails out.
What's happening instead is,
any email that's coming from CustomerGlobomantics@mail.com,
which is who our second victim in our scenario is,
any email coming from that, it's getting moved to a folder called RSS.
This is something that the attackers in a BEC compromise will often do.
They'll set up another rule so that if any emails come in from the
victim that they're emailing to the legitimate user,
it gets hidden in another folder.
‑So say, what's really great about this is if you're on your detection game,
one, you can now see customers that are affected or who they plan on affecting,
depending on what timing you found this in.
So if you found this, they made the inbox,
they're probably trying to attack this customer at that exact moment.
And so now you can kind of maybe try to get ahead of that too, based on timing.
And we have logs and timing here, but, yeah.
‑Yeah, exactly.
This is a great way to also, like you just said,
kind of see the progression of the attacker and what they were doing.
And not only that,
you can now see what this folder is and go in and pull the
emails from that folder and start doing analysis on that to
see what emails were going in, when did the customer potentially detect this,
and why wasn't this user getting the emails to kind of alert everybody else?
‑Why wouldn't they just delete the emails?
Why are they moving them over?
‑That is a good question.
I don't really have a good answer for that.
I would expect them too to just delete the emails,
as opposed to just moving them to another folder.
‑Do you think maybe it's to have access to it? Like if they needed
that correspondence to be able to still get paid,
they wanted the option to be able to log back into a
pre‑compromised account and look at it?
‑I think you might be on that.
By moving it to another folder,
they can always go back and get those emails and then respond to them.
If they move it to the trash or delete it,
then there's always the chance that eventually Office 365 or the user is
going to empty their trash or empty their deleted emails,
and so they would lose access to it.
So I really do think that's what it is.
And normally they put it into a folder like RSS because most people,
if they have an RSS folder for RSS feeds,
don't use it, and so they're never going to look in there.
‑Yeah, that makes sense.
I never checked mine, so, I probably should now. Yeah, awesome.
And so that applies, and I kind of wanted to make a point of a note here.
Do you mind clicking back out of that so I can see the rest of the rules,
unless you're not done with this?
‑No, no, no, absolutely.
‑Okay, so we see New‑InboxRule, New‑InboxRule,
knowing how these detections are written often,
or if you're doing your own detections,
I just wanted to point out that Set‑InboxRule is
also something you should look at.
It's not just, if there's a new inbox rule,
that can sometimes be the way that detection mechanisms do this.
Microsoft's obviously doing a great job,
but there's other groups that don't always have that same capability.
It's not going to be the same rule set.
So my point here is that they can just come in and modify an existing one
and you probably should be alerting on that as well.
‑Yeah, exactly.
Now, you can go and export these here by going to Download all results.
Here's the catch with that, though.
Within at least this interface, you can only download 50,000 records at a time,
which sounds like a lot,
but if I'm investigating an organization or I'm looking at an organization,
and I wouldn't necessarily know what to filter it based on,
so I had to pull all logs, 50,000 records,
depending on the size of the organization,
could maybe be a day.
So you may have to go through that multiple times in order to pull
back records going back as far as you need to. ‑Yeah,
and again, this isn't just the sign‑in logs.
It's the audit logs, which historically,
if you look at any‑‑‑this is every user action that was taken.
For a reference, when you click into this API and you just made this log search,
it's probably about four or five audit log entries.
It's not simply user did a log.
It's not just that one thing.
So that's why it's so large.
‑Right.
And so one last thing to show in this interface.
The audit logs are really great for pulling this information out,
but let me clear it.
We also talked about the applications that can
bypass multifactor authentication.
So how can you search for that?
So there are a number of ways that you can go in and
search for applications themselves,
but really what you want to do is search for the users actually
consenting to applications to kind of narrow it down.
I mean,
you can absolutely use PowerShell to pull all
applications that are in your user accounts,
but you could be coming back with who knows how many
thousands of applications to look at, and you don't really have time to do that.
One of the things you can do is go to the audit view here,
go to Filter results, and then under Activity,
look for consent to application, consent to application,
and then filter it like that.
We didn't use malicious apps here, so nothing is going to pull up.
But if something did come up, that means a user said, yes,
I'm going to allow this application access into my environment.
And that's something then, you could go in,
you could dig into that, you can see what the application is.
Each application will have a unique ID associated with it,
which you can then go and Google and validate whether,
oh, this is iOS's email application, or this is Google's email application,
or this one has never been seen before.
That one that hasn't been seen before, then jump in,
look at what the permissions are,
what that application has access to and see if it does
allow access or full access in the email,
and that could be the way that the attackers have gotten in.
‑Yeah, absolutely, and I wanted to dig into that a little bit.
I think now is the time.
We talk about the attack chain of how the application would be used,
and we mainly,
specifically we're talking about bypassing multifactor authentication.
And that sounds super scary.
Again, it doesn't mean don't use multifactor authentication.
Highly encourage using multifactor authentication.
It gets rid of the whole swath of attackers who
aren't using this application method.
So you're at least narrowing down the potential attackers.
So with that out of the way, we're looking at these applications.
I want to talk a little bit about the mechanics of
why that works and how that works, just in case someone is not aware,
mainly because, so these applications get tokens,
or OAuth tokens,
and API tokens that are static and don't require multifactor authentication.
That's really the point of it.
When you authorize an application,
it generates a token that is permanent authentication
access to your account or your environment.
‑Yeah, exactly.
Think of these applications similar to a program
that you install on your computer.
You log in to your computer, you authenticate to your computer,
but after you do that, you have access to your computer.
And if you install a backdoor malicious program into your computer,
it's got access to everything on there.
Same concept here.
You are allowing this basically app in the cloud
access to your Office 365 environment.
You're saying, yes, you can access whatever you want.
And then that app just happens to be malicious,
and then you can then use that,
or the attacker can then use that to access whatever they want,
grab emails, send emails through your account,
and so on.
‑Yeah, make forwarding rules.
So yeah, effectively, that app's access is the same as having a user.
‑Yes,
and that is absolutely why you need to have some of these
detections and protections in place.
Microsoft has started to add things in to do app analysis,
or at least let you know when new apps are being installed into Office
365 so that you can get a report that shows that,
hey, these 10 users just added in these applications.
And you can use those to validate whether or not they're
legitimate or not in more kind of real time than having to go in
and manually pull all this information out.
‑Yeah, absolutely.
And I don't want to say that this is new. Office 365 isn't new by any means.
But I think defenders, and depending on the organization you're in,
have room to grow to start including this type of information.
Like we just talked about, some of it's even difficult to get to.
The logs aren't in the place or it's this dashboard or that dashboard,
or you have to have a license, and all of that becomes a misunderstanding.
Or it's AWS or another, whatever it is.
There's just a million different ways to try to get the information you need.
But this is definitely the evolution of,
here's the kind of things we can you start adding
to our tool bag as connections.
And yeah,
I know it's increased things to look at because Office 365 doesn't exist only
when you don't also have on‑premises stuff to worry about.
You now have both, but that's just another place when you start looking,
for sure.
‑Right, exactly.
‑And so that happens all the time,
and hopefully now we can get a better grasp of what to do to detect it.
But say we have people out there who are literally following along,
and right now they're like, yeah, that sounds,
like, really cool.
Let's look at this application thing,
press Enter and there's really bad application names
coming up that have weird access to it.
And they're finding all the same rules.
They're like, oh, no, yeah, people are logging in from all over the world.
They're logging in from other planets.
That's definitely impossible.
This is weird.
What do we do now?
We need to get into doing some instant response.
So are we ready to talk about that next?
‑Yeah, absolutely.
Let's go in and let's talk about what you do once you find one of these things.
And we'll talk a little bit even more about,
you know, we've gone through and done some of this analysis.
Let's show how to actually automate a little bit this a little
bit more to make it a little bit easier to do.
‑That sounds good to me.
I'm about tired of scrolling through logs at this point in my career.