(crescendoing music) (loud boom) (loud zoom) (applause) - Without further ado,
Office 365 Forensics, the forensically sound approach. and at the end of the day,
you know, the transition from on-prem exchange
servers to doing forensics, in Microsoft's playground
on their servers, and then in their back-end
data infrastructures has presented interesting
forensic challenges. There's no longer am I able
to put hands on the original, you know, the old
traditional IS logs. Now we're kind of working off
of logs filtered by Microsoft and put into certain
areas of Office 365. We now have to interpret and figure out what
is the causality, with what creates these entries,
and what can I then learn from these logs to
figure out an actor that has gained
unauthorized access, usually through business
email compromise, or through password spray
attacks, to get into an account and now what data is it
risk of being accessed by an authorized third party. So where do we go first? For those of you that have
done forensics in Office 365 the most important
place you want to go is under security
and compliance, and there is something
called the unified audit log. And the unified audit
log is Microsoft's dump of several data sources
into one location. And what you have
produced from that is this unified audit
log that allows you to pull auditable events,
that Microsoft has kind of again hand chosen for
us, to dump into one log that you can break
down by users. So you'd go to
search investigation, you'll go to audit log search, and then you'd be greeted
with an interesting window, which we'll get to in a minute,
to actually search through. There's some caveats. Some very important
friends of caveats to the unified audit log that if you're not aware
of you should be. Logouts are not captured. So if I'm a bad guy and I've
logged into an email account, one of the questions I
often get asked by law firms or clients, "How
long was the bad guy in our system/email account?" Logouts aren't
captured and there's, of course, a bunch of
technical reasons for that. One of which is, you know,
if I close the web browser by not clicking
the logout button, I just clicked the
"X", close my session, Microsoft probably
could log the latency or could probably log that
my sessions terminated. At the end of the
day, they just don't. So I have a login event. I have no logout event. Was he in there for hours? Was he in there for days? Messages. Specific viewed messages
within an email account are not logged in the
unified audit log. So if I'm a bad guy and
I'm in an email account, and I've logged in with
username and password, and I'm viewing emails
in your email account, the viewed message themselves are not captured in
the unified audit log. Search terms being run. Again, not actually
captured there. Was an attachment viewed? For a lot of the investigations that my team does
we're often asked, you know, the body of the
emails, not the important part. It doesn't have the PII or
the PHI, the HIPAA data. It's the attachment. It's Excel spreadsheet that
contains 10,000 user records with social security
number, date of birth, etc. Was that attachment viewed? Unified audit log
doesn't tell me. So usually I take the
position that if I know that, that guy was in the account
based on the unified audit log, likely the contents of that
account are at least at risk. Those are the limitations
that Microsoft has kind of strapped us with
from this one data source. Like the session, I
already spoke about. This is the one thing. This is the nightmare
that you never, ever want to see an
instant responder. If you've logged into a
client's Office 365 tenant and that is that the
audit log is not turned on because now you have
a significant issue. I have now lost one of my
primary forensic data sets to help tell you, the
client, what the actor did when he was in
your email account. By default, this is not on. So any time that we get engaged one of the first things we
usually do is ask the client, "Do you know if you have unified
audit logging turned on?" And for about a
quarter of our clients they have no idea what
we're talking about. For about another percentage
of our clients, they're like, "Yes and we just turned it
on when we found out about this event so it's
now capturing data." Great, that doesn't help
me for the last 30 days. Or, you know, you have
a proactive IT group and they're like, "Yes. That was turned on. We have logged data." Excellent. If not though, you're
greeted with this screen where you then
have to turn it on. Takes about 24 or so hours. A little hard to see on
the screen. I apologize. Bottom left there
though is says, "Because you started
recording user and admin activities
within the past 24 hours some activities
may not show up." And depending on the
size of the tenant and depending, what
I mean by that is, depending on the amount of users in the tenant based
on the licensing, sometimes it will take 24 hours before logged data
starts getting streamed and pulled into that. If it's a smaller
tenant and it's on one of Microsoft's newer servers, or it's been a more
recently subscribed tenant, usually it's within hours
we can start seeing data. May not be complete but you'll start actually
seeing data populate in there. So what's one of the
first things you need to do as an instant responder? And it's establish a
global admin account. Now Microsoft's got
an interesting tier to the user accounts and
you can be a global admin, you can be normal user,
or you can be a member of one of many user,
kind of levels. If you have a global admin
think of it as domain admin. It is your power user
within the tenant but even as a
global admin I still do not have 100% capabilities
across the tenant. I still need to
be assigned roles and we'll talk about
that in a couple minutes. There's a roll
particularly you need if you want actually
download PSTs or search the results
of a content search. Know your environment. This is probably one of
the more important slides. If have not done Office 365
Forensics these are the areas, the first three are
the areas within O365 where you will be
focused the most on. http://protection.office.com
gets you to the security
compliance portal. Which allows you to
access unified audit log and it allows you to
access the content search. Which allows you to do
searches within user accounts for particular messages
and generate PSTs that you can download and
do offline forensics on. The O365 admin center is
where you can look up users and I've been engaged on
intrusion investigations where we've been
told by the client, we know there was phising
emails being sent out from this one particular user, or there was something fishy
going on with this account and emails were being
deleted or marked as read, and I go in here and the
client had deleted the account and created the user
another account. Well as soon as they did
that they break the linkage within Office 365 to the
unified audit log for that user. You could try
searching for that user you will not find any logs. You've about a 30-day window
to restore that account. The restoration will
relink the logs for you and you'll be able to
rerun a search query within the unified audit log. To the admin center is
where you will spend a lot of your time if you're
looking up particular users. If you wanna see what
their titles are, you wanna see how they're
configured within the tenant, what licensing is assigned to
them, it gives you, I kind of, I kind of equate it to
metadata about the user and it may help you
with your investigation. Windows Azure. So for those of you that know
Azure and the environment, it's kind of, I would kind
of equate it to Amazon AWS, you know, at the end of the
day you can spin up servers but it also by default,
depending on the licensing level of your tenant, has active
directory resources in it and we're gonna talk about
some of the forensic artifacts that are relevant
there to Office 365 and email accounts specifically. And then the last one,
Windows Powershell. I don't know Nathan personally. I've gotten to talk to him
over email a couple times. Really good guy. He wrote a tool
called Pshell for 0365 and you can Google
it and find it off a, there's a third-party website that posts his
article and the tool. What's great about the
tool is that it has bundled with it all the dependencies in the Powershell command
list for all of Office 365. Azure, OneDrive, SharePoint, all of those are pre bundles
when you run his installer. You have all of the commandlets
loaded on your local system so that you can actually
enter, if you need to, into Powershell and I have some Powershell queries
I'll show you in a bit where by default loggin' in from a normal
Windows stock machine you're not able to run those
commandlets without this. I'm not gonna to spend
too much time on this. As most of us is seasoned
investigators we understand if there's something wrong
within an account we need to identify which
accounts at risk and usually with a typical
business email compromised life cycle usually someone
is found out about it because of either A,
you know, admitted, "Hey I found a, I
had a weird link and it was for a document,
or it was for an invoice, and I had to go, and it asked
me to log in my credentials." And of course, you're going (face palm) and they've kind
of self-admitted. Or all the sudden
you have a report that a user's email account was sending out messages
asking for something. And it's like hundreds
of messages going out. That's a clue. So you usually know it,
those of us that do this, which email account needs
to actually be investigated and now we have our accounts we're gonna pivot off
of for the evidence. So we're exploring the log. The unified audit log. This is the screen
I was mentioning. So when you go to
search and compliance, and you go specifically to
that, it loads this screen, allows you to run a search
of a particular user, or users you can do multiple,
at the end of the day it's, you know, depending
what tool you're using, Splunk, or Excel, or, you know, whatever tool you might prefer. It may be helpful to
download one log per user and try to separate
those events. I've seen users and instant
responders that will try to load up, you know, 15
email addresses into this box and you get a really large file and they're all meshed together. Again, you know, it depends on, I guess, your
preference for analysis. I like running it and getting
the individual log file so I can kind of
see what happened and then I'll merge em together
based on what's relevant. Cuz again, if you're doing an instant response
investigation for actor activity most
likely you're also going to see legitimate
account activity. So now you have to try
to correlate yourself as the instant responder,
what's bad, what's good? You know, the good guy in
his account using Outlook. Bad guy in the account
using a web browser. And then I need to
separate that out. And it becomes a little more
convoluted if you're running, you know, 15 something users
all through this search screen. By default, once loggings,
of course, turned on, I have seen logs available
for 30 days, up to 90 days, and I've seen some
larger tenants available for about 6 months
worth of data. There is a Powershell query. You can change the
default setting up to I believe the 180-day mark. I do not believe
you can exceed that. Like, so I've never
seen any documentation and when I've tried via
Powershell to exceed that I usually get
an error message. I do know that Microsoft
can exceed that number. I was dealing with
one client who had two years of
unified audit log data. Which blew my mind. It was an immense amount of
data and we were just amazed because when you
bring up the calendar, I don't think I have a slide, when you bring up the calendar it actually shows you
a color-coded dates for what days have
logs available and I
just kept going back and back and I'm like surely
there's something wrong and I pulled a log
from like 2 years prior that actually had data in it. Found out they had,
had a prior issue. They had reached
out to Microsoft and Microsoft kind of
flipped the magic switch and gave them longer
retention data. So Microsoft humor. I have found significant
issues with trying to run this search
engine, if you will and typing in users if you
are using Chrome or Firefox. In fact, when I have
tried with those browsers, even with the newer versions,
you start typing in there, the cursor actually disappears
and keeps you from typing. It's a really weird bug. But of course, Microsoft's
browsers work just perfectly. So again, I'm not sure if
that's just something odd with my testing or if
that's a Microsoft joke to try to prevent or force
people to use their browsers. One requirement, I mentioned
the content search, and I think I mentioned
it twice so far. The content search allows you
to download PSTs for users so that you can do
offline forensics. That export tool that Microsoft has created requires a
Microsoft based browser. The little plug-in that loads,
I've not had any success with it loading in a
non-Microsoft browser. And as your AD, which
we'll talk about in a bit, same functionality, some of the search fields
and the search boxes, some of the sliders, it just it will
not render as well unless you're using
Edge or IE 11. Under the search window that we were talkin' about
a couple screens ago, in the top right-hand corner is where you download the
results of your search. I'm gonna go back for
just a quick minute here. This may be easier
said than done cuz I forgot how many
slides it was back. This might have been a bad
idea. Sorry about that. I thought I had a
screen a couple back that actually showed the
results a little but better. Bear with me as I get back. Okay. In the top right-hand corner
though is where you'll export. Now, interesting nuance here, save loaded results versus
download all results. Kind of self-explanatory, but
for those of you that may not have done this before,
save loaded results will only download a JSON
dump of what's loaded on the screen and by default, it's loading about one
screen worth of data. As you scroll down
it keeps loading more and more data into the browser. If you only do save loaded
it will only save out what is loaded on the screen
versus download all results which will dump
everything responsive to the query you've executed. I have a little
bit of a joke there that with the Microsoft Excel. This data if JSON and it does
not render super well in Excel but I'll talk about
that in a minute. So I made a chart for
all of the operators or the auditable events
that are captured as well as their default status by Microsoft, the
unified audit log. It's a couple
interesting ones here. A message being copied
to another folder. That action is an audible event
but it is not on by default if you are a delegate or if
you are the account owner. So if I have an email
account in Office 365 and I copy a message that
is not an auditable event. If I'm an admin
level user it is. Folder bind and message bind. Now, these are two are
very interesting ones. So folder bind. A mailbox folder being accessed. Well, that can be
extremely useful to an instant responder, right? If a bad guys been in one
of my users' email accounts be extremely useful
to know if a bad guy was traversing down
through folder structures. Did he stay in my inbox or did
he go to my doctor's folder with his rounding
list where he's been keeping my pick up patient PII and PHI for
going back for years? Did he ever access that folder cuz that changes a forensic
finding of years worth of notifications
now for the client? Or bad guy was only looking
for invoice data in the inbox. Not auditable for
typical owner accounts. It cannot be configured. It cannot be turned on. When you try it in Powershell
to force that operator to be logged you'll get
an error response back. So message find being
even more important. Message being viewed in
the preview pane or opened. Now this is speaking
to if I log in whether as a legit
user or a bad guy into http://office365.com
and I'm looking at an email account
via the web browser and I'm clicking down
through messages, or objects is how
Microsoft refers to it in their nomenclature, all of the objects that
are being viewed. If you are normal owner
or a delegate the clicking of those messages is
not captured in the
unified audit log. If you're an admin,
interestingly enough, I have seen where it sometimes
is and sometimes is not. Regardless of it
being on or off. No explanation for that. So the Powershell query to
force on certain operators that are not on by
default is here. And, of course, then you can
comma separate the values or the operators that
you want to turn. By default, Microsoft does not
have all of the operators on. Well, as we already discussed, by default the
loggings not even on and then once you've turned
it on only a certain amount of operators are
logged by default. So now you actually
can go in yourself and turn on additional
ones if they're supported. So now we're into the analysis
of the unified audit log. Again it's JSON data. It's a little ugly
to look at in Excel but just for ease I
brought it up here and it's this kind
of a sanitized one so apologies for
the big black boxes but at the end of the day
you have four main columns that you'll see in Excel
when you open this up. Creation date and
time, the user IDs of the user accounts
you've export, and then the operations
or the operators. These are the auditable
events recorded down to the unified audit log. User logged in. Files being accessed. The files being accessed
and files being viewed is actually very interesting
cuz that speaks specifically to OneDrive and
SharePoint activity. Now a lot of the business email
compromise cases I've worked over the years
typically the actors are getting in, they're
looking at messages. We have seen a percentage
of our cases though where the actors will
actually host the file they're gonna use for phising on the compromised
accounts OneDrive or in their SharePoint
and you can actually see that activity and it
timelines out very well out of the unified audit log. So again that's just
kind of the highlight of the actual operators
and how they correlate and then the data
that's in that JSON blob to the to the right
on that last screen those are kind of the
more granular effects I have another
screenshot of that but the mailbox login is
one of the most important if you're trying to pivot
around actor timelines and their activity
within an account. It's not as simple
though as just looking for just one operator to
identify when a user logged in. Microsoft has several. In fact, this isn't
even a complete list. I think there's eight. But these are the six
that I see the most in the investigations
that I've done. User logged in is
the most basic. That is the easiest one
to search for or grep for. But the other ones
that are here depending on the client's
mail environment, the way they've got it set up, you may see all of
these other types of logins to capture a
username and password and an authentication event
into the Office 365 account. Now for the most part user
logged in is the default. If a bad guys logged in
via http://office365.com via web browser this is the
one you'll see the most common but depending on if the clients
using some type of an ADFS or a hybrid environment
where they still have exchange on-prem
maybe they haven't migrated all their users into Office
365 or they're hosting locally but they're using a
licensing in Office 365. A lot of those factors
can affect the way Microsoft sees the
authentication into
their infrastructure. Hence the different operators that make capture a login event. So you'd be remiss
if when you load that data you're only
looking for user logged in. You may miss other
types of login events. So here's that JSON
blob I was talking about and these are kind of the most
important aspects of that. The creation time. What is the actual operator
that you're caring about? The user logged in for this, for the purposes of this
example, the IP address. Where is that person logging
in from as far as an IP? The extended properties. The user agent. This is fantastic for base
lining a user's account. You know, most the times
when my team is brought in we don't know the
user's environment, the clients' environment, as
well as the client's IT team so I don't know
what a normal user may be using at their system. Are they using the most
recent version of Outlook? Are they a remote user? Are they using a browser
when they're traveling? So I can go in here we
can pull this data out and I can baseline
an accounts activity. Now, what are my outliers? IP addresses are
always geo-locating to this one part of
the United States. That's right where the
headquarters is for this client. I'll listen, I've got a login
that's a significant outlier and it's coming from a
different part of the world. Now I have something to
pivot off of. Very quickly. Very easily. Same thing for the user
agent string though. Am I only ever seeing Outlook as the normal baseline
activity for this client? And all of the sudden
I see a web browser and it's some odd
version of Opera. That's an outlier and now
I can pivot off of that. And of course the
result status detail. Value success. I don't care about value fails and you'll see a lot of failures when you're doing
these types of logs. Filter em all out. I mean
at the end of the day it may help give you
some information, then you know, is someone
beating on the door, someone trying passwords, but at the end of the
day, I care about success and if there was an
unauthorized access I don't normally care. I care about the
success and this is where you would be able
to go and pull that. Three more operators that
are significantly important, add mailbox permission, add recipient permission,
and set mailbox. Set mailbox is the
forensic artifact that is laid down in
the log when a change to the account has occurred. So the point in time via
Powershell, via the interface. If I have changed a setting within the users
Office 365 account there will be a set
mailbox operator that records the moment
in time that the changes have now taken effect
on the account. This is a great one
to pivot off of. Now I can just sort by set
mailbox cuz typically most users aren't changing core
settings in their account. If I'm looking in
accounts I'm looking for settings like
an auto-forwarding
rule being created. I can very quickly
filter by this and now I start to
see the outliers. But the add mailbox permission
and recipient permission is significant
because if you have had a global admin
account popped and that bad guy has
been able to leverage that account to log in,
so just say Devon Ackerman is the global admin,
his account gets popped, and now he's that
account is logging in and being set as a delegate
on other email accounts, the add mailbox permission
recipient permission will be recorded in the
log for every account that my primary global admin
is being used to log into. Those artifacts may
not be on those users in their individual
unified audit log but I'll see it on
the global admins UAL. So again, this is
not rocket science. Do this on a regular basis. I want to know if I've
had an authorized access when did it happen and what else did the actor do in the account? So we're gonna baseline
that user activity. We're gonna identify what is
normal, what is legitimate, and now what is my
outlier activity? And the outlier activity is
what I'm gonna care about. You're gonna use user agent
strings that we talked about. Mail rule creation. Typically I find that a lot of
the actors from Europe, from, I don't know, I'm tryin' not
to name a specific countries but from the African region
that are usually interested in monetary gain
through wire transfer they will create mail rules
and they will create mail rules to either cover their tracks
from the kind of the spam that they stay flood out or they will create a mail rule
to auto-delete responses. And they wanna try to hide their activity as
long as possible. So typically mail
users are not creating a lot of mail rules
in their accounts. If mail rules have been
created within a certain time, something to help rise
to the top If I'm looking at hundreds of accounts,
to look for those outliers. In fact is a good
example we're working a 191 account breach right now and one of the things
we've done with this volume of accounts is A, is
the 191 the total? I mean that's a lot of accounts that have had
unauthorized access out of a 10-12000 account tenant. One of things we've
been looking for is during the time we know of unauthorized access,
who had mail rules? And we've found
another 49 accounts and the mail rules
were all malicious. It was a very quick
way for us to pivot on that data and look for things. And the geolocation
of the IP address is the end of the day whatever
your preferred tool is. Splunk or another tool where
you're doing geo IP lookups. Something that helps you on
a map identify what is normal for this client or for
these user accounts and what is an outlier. Especially because most actors in my experience are
not very original. They will usually come
from the same area or the same data centers
or the same VPN client and you can very quickly start
kind of seeing that on a map. One thing to look
for in my experience is the IP addresses you
may see from a bad guy on one account they may
especially they're using like an IPVanish or they're using
some type of VPN client or an anonymizer service they
may get different IPs assigned to them over a period of time but typically there from
that same IP netblock. And I've gotta Powershell
query I'll show you. You can use to search
an entire netblock and make sure you're not
missing particular other IPs that you may not have seen
specifically in a log. This allows you to have a lot
more about broader scapple to see if there's other IPs
from that same actor or group. Couple examples of
clients you may see in the unified audit
log and it Microsoft's very proud of their
products, right? So they're going to give you
a very detailed information about Outlook if it's
their product their client and then in my experience
and lookin' these logs if it's not an Outlook
client they're like, "Eh, it's a IMAP". (laughs) Well, thanks Microsoft. You will notice they
do not identify other non-Microsoft
Outlook mail clients and they literally let you
know there's a protocol which is indicative of an non-Microsoft Outlook mail
client accessing the account. Which of course, you know,
at the end of the day I'll let you be the
forensic verifiers on that but in my opinion and through
testing normally means the possibility is there that
at least certain emails would have been allowed
to be downloaded if not a complete ActiveSync
of an email account. Going back to the
rules we've touched on briefly a minute ago. So these are the
operators you would see inside a unified audit log if
a bad guy creates a mail rule to do whatever it is whether
it's auto-forwarding, deleting messages based
on certain keywords. These are the operators
you would see written down to the log and again that's
a change to the account so forensically you
would see set mailbox as that last operator
being recorded after
the actor has gone and created the mail
rule, updated the
content or the rules, the arguments for the rule, and you can actually
see almost the seconds between the actor clicking
the different options with the mail role things
and then when he hits save that's when the set mailbox
is written to the log. There is something extremely
unique to Office 365 that is not reflected
in the Microsoft client, Outlook mail client, and that is another
auto-forwarding feature. So you can auto-forward
messages as a bad guy. Out of a victim's
account using mail rule. You can also in Office 365
go to options, mail accounts, forwarding, and I can type
in an email address here and say keep a copy
of forwarded messages, so they still get
delivered to the inbox, and now I have a second
place I have to look as an instant responder to see if a bad guy has put
an email address. And this, more times than
not, is completely missed by infosec teams
internal company. They know to go to
look for mail rules. Mail rules have been around
since as long, you know, Microsoft has had all
earlier versions of Outlook. This is specific to Office 365 and the only way you'd be able to go in and find
that is to actually you can do via Powershell or
go into the user's account and manually go look for this. Here's the IP address example
that I was telling you about. So if you want to search unified
audit log from Powershell, you're a command line
guru, you wanna dive in, this would be the command
that you would issue from Powershell to actually
search the unified audit log, and this is actually searched
all unified audit logs, so all the audit logs for all
of your users in your tenant, this is a quick way quick
way, quick down and dirty way, if you have some indicators
of compromise, type em in, you give the dates, the start, and the end, export
to a CSV, and boom. Usually within seconds
this query can run and it immediately
can give you IPs helping you identify
other accounts that you may not know about. And this second example
there is what I'd recommend if you're tryin' to do netblock. So if you know I have a bad IP it goes back to a hosting
center no legitimate activity do a Whois, do a DNS
lookup, figure out what is the netblock owned
by that organization. I'd recommend you
search the whole thing. You may find that
actors using other boxes from that hosting provider or
other IP's within that range. So beyond the unified audit log. In Azure, depending on the
licensing of the tenant, usually it requires an
E1 or an E3 licensing, there are a couple additional
things that Microsoft has done to try to
help instant responders pull out suspicious activity. And you would see
users flagged for risk and risky sign-ins and those would be two very
quick logs you'd go to. Usually is logs
7 days or 30 days is the max they're available. So they're extremely volatile. So wrapping up real quick. So I think I'm pushing my time. If you wanna jump to
Powershell you can additionally do some interesting queries
to pull out a massive amount of data about a
particular user account. Not necessarily of a
lot of forensic interest but it is some very
interesting details about what auditable events are
turned on for an account when the last password
reset was for the account, and some very
interesting activity that may tell you just
general information about the user
you're investigating. I talked briefly
that a global admin does not have 100%
rights within a tenant. You would need to, if you
want to do PST forensics and look for other
artifacts within that PST, you would need to
assign the global admin an eDiscovery admin role so that he can download
the actual PST contents. So this was very briefly had an instant response
scenario we were doing. Had a couple emails that
I pulled out of a PST and, "Hello Frank, per our
prior conversation, please let me know what
you think about it." I'm thinking this
looks a little odd. It was right during the
unauthorized access. I thought this was the actor. It was. So Julie responds, excuse
me, Frank responds, "Julie is this legitimate?" Of course, now Julie is the
account that has been popped and the actor is the one
sending the messages out. "Frank, yes it is, I sent it." Thank you Mr. Actor. I appreciate that. So, not gonna spend too much
long on the email analysis. You guys know what you're
doing with that, right? At the end of the day,
you're lookin' at the emails that may be of interest
and may still be left over in the PST and
those of course help from a timeline
analysis standpoint. If we know the actor
was in the account or we're looking
for particularly what they did you may find some very interesting
emails actually still left in the account. RSS subscriptions is
a very popular folder I recommend you go look at. Actors love hiding
messages there. It's a default folder
Microsoft has in Outlook. Almost no one ever uses
it and it's a great spot where actors rules
will usually mark as read and move
messages to there. Second really funny scenario. Phishing email with an
attachment received. We've identified through the
PST forensics the message had been marked as read
so we knew the user, the legitimate user,
had clicked the link in the phishing email. He'd gone to the website,
submitted his credentials, he was arguing he
had not done this but I found an email that
said and him responding to the actor, "Send me
something I can open and not something that makes
me feel uncomfortable." I usually get asked,
"What can my client" so I usually get asked,
"What can we do to make sure that we protect and
harden ourself". You know, multi-factor
authentication usually will nullify probably 99% of
these types of attacks, right? You're using single factor, and a phishing page captures
username and password, you're gonna have a little
bit of an issue there. If you turn multi-factor on
of course you're going to have that second
level of factor. You're gonna have the token. It's much harder for a
bad guy to capture that. I have seen a trend
where actors are starting to also put a token field
on these phish kit pages so it asks for username,
password, and your token. And I have had some instances where users have
given up their token. Tokens usually good
for 10-15 minutes, depending how it's configured, and the bad guy still gets in. So be aware of that. But domain
auto-forwarding blocks. At the end of the day
auto-forwarding messages out of your tenant because a bad
actors create a mail rule is a significant issue. These would be ways
where you can stop that. I've in most clients I speak
with and do consulting work for they're like, "We don't
have a legitimate reason to be sending messages outside of our tenant to an
external third-party." Microsoft gives you a
Powershell way to actually block that tenant wide and those
messages are attempted to be auto-forwarded
they will get dropped and they will not be
delivered successfully. And that's it. What questions? (audience applause) (thumping music)
