Presented at the 2018 SANS DFIR Summit by Devon Ackerman, Associate Managing Director, Kroll Cyber Risk
A planned methodology for developing and implementing a forensically sound incident response plan in Microsoft’s Office 365 cloud environment must be thoroughly researched and re-evaluated over time as the system evolves, new features are introduced, and older capabilities are deprecated. Devon Ackerman’s presentation is based on two years’ worth of collection of forensics and incident response data in Microsoft’s Office 365 and Azure environments, combining knowledge from over a hundred Office 365 investigations, primarily centered around business email compromise (BEC) and insider threat cases.
Densely packed into a 35-minute presentation, Devon walks through the numerous forensic, incident response, and evidentiary aspects of Office 365. The full video is available below, courtesy of the SANS Institute, along with the full slides and text transcript.
Watch: Forensically Sound Incident Response in Office 365
Video Transcript
Without further ado, Office 365 Forensics, the forensically sound approach. At the end of the day, the transition from on-prem exchange servers to doing forensics in Microsoft's playground, on their servers and in their backend data infrastructures, has presented interesting forensic challenges. Because no longer am I able to put hands on the original, the old traditional IS logs; now we're kind of working off logs filtered by Microsoft and put into certain areas of Office 365. We now have to interpret, have to 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 at risk of being accessed by an unauthorized third party.
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 & Compliance, and there is something called the unified audit log. 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.
You go to Search & Investigation, you go to Audit Log Search, and then you would be greeted with an interesting window, which we'll get to in a minute, to actually search through.
There’re some caveats, some very important forensic 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 is of course a bunch of technical reasons for that. One of which is, if I close the web browser by not clicking the logout button, I just click the X, close my session. Microsoft probably could log the latency or could probably log that my session's 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 a username and password and I'm viewing emails in your email account, the viewed messages 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, the body of the email is not the important part, it doesn't have the PII or the PHI, the HIPAA data; it's the attachment. It's the Excel spreadsheet that contains 10,000 user records with Social Security number, date of birth, et cetera. Was that attachment viewed? The unified audit log doesn't tell me. So, usually, I take the position that if I know that a bad guy was in the account, based on the unified audit log, likely the contents of that account are at least at risk, because the limitations of Microsoft has kind of strapped us with from this one data source.
Length of session, I already spoke about.
This is the one thing, this is the nightmare that you never ever want to see as an incident 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?" 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. We just turned it on and we found out about this event. So, it's now capturing data." Great, doesn't help me for the last 30 days. Or you have a proactive IT group and they're like, "Yes, that was turned on and we have log 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, it says, "Because you started recording user and admin activities within the past 24 hours, some activities may not show up." Depending on the size of the tenant and depending, what I mean by that is depending on the amount of users in the tenant base and the licensing, sometimes it will take 24 hours before log 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. It may not be complete, but you'll start actually seeing data populate in there.
What's one of the first things you need to do as an incident responder? It's establish a global admin account. Now, Microsoft's got an interesting tier to the user accounts. You can be a global admin, you can be a normal user, or you can be a member of one of many user kind of levels, if you will. 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. We'll talk about that in a couple minutes. There's a role particularly you need if you want to actually download PSTs or search the results of a content search.
Know your environment. This is probably one of the more important slides. If you 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. Protection.office.com gets you to the Security & Compliance portal, which allows you to access the unified audit log and 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. I've been engaged on intrusion investigations where we've been told by the client, "We know there was phishing 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." 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. If you try searching for that user, you will not find any logs. You've got 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.
So, the Admin Center is where you will spend a lot of your time if you're looking at particular users, you want to see what their titles are, you want to see how they're configured within the tenant, what licensing is assigned to them. It gives you, I kind of equate it to metadata about the user and it may help you with your investigation.
Windows Azure. For those of you that know Azure and the environment, it's kind of, I would kind of equate it to Amazon AWS. At the end of 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. We're going to talk about some of the forensic artifacts that are relevant there to Office 365 and email accounts, specifically.
Then, the last one, Windows PowerShell. I don't know Nathan [Mitchell] personally, I've gotten to talk with him over email a couple times, really good guy. He wrote a tool called Pshell for O365. You can google it and find that there's a third-party website that posts his article on the tool. What's great about the tool is that it has bundled with it all the dependencies and the PowerShell commandlets for all of Office 365: Azure, OneDrive, SharePoint. All of those are pre-bundled. So, when you want to 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. I have some PowerShell queries I'll show you in a bit, where, by default, logging in from a normal Windows stock machine, you're not able to run those commandlets without this.
I'm not going to spend too much time on this. As most of us as seasoned investigators, we understand, if there's something wrong with an account we need to identify which account is at risk. Usually, with a typical business email compromise lifecycle, usually someone has found out about it because they've either (a) admitted, "Hey, I found out I had a weird link and it was for a document or it was for an invoice. I had to go and it asked me to log in my credentials," and of course, you're going, and they've kind of self-admitted it. Or, all of a sudden you have a report that a user's email account was sending out messages asking for something. It's like hundreds of messages going out. That's a clue. So you usually know, 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.
Exporting the log, the unified audit log. This is the screen I was mentioning. When you go to Search & 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, depending on what tool you're using, Splunk or Excel, or 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 incident responders that will try to load up 15 email addresses into this box, they get a really large file and they're all meshed together.
Again, 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 them together based on what's relevant. Because again, if you're doing an incident 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 incident responder, what's bad, what's good, the good guy in this account using Outlook, bad guy in the account using a web browser, and I need to separate that out. It becomes a little more convoluted if you're running 15-something users all through this search screen.
By default, once logging is, 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 six 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, at least I've never seen any documentation and when I have 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. 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 color-coded dates for what days have logs available. I just kept going back and back, and I'm like, surely there's something wrong. I pulled a log from two 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.
Microsoft humor. I have found significant issues with trying to run this search engine, if you will, and typing in users if you're 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. Again, I'm not sure if that's just something odd with my testing or if that's a Microsoft joke to try to force people to use their browsers.
One requirement I mentioned, the content search. I think I mentioned twice so far. The content search allows you to download PSTs for users that you can do offline forensics. That export tool that Microsoft has created requires a Microsoft-based browser. The little plugin that loads I have not had any success with it loading in a non-Microsoft browser.
Azure AD, which we'll talk about in a bit, same functionality. Some of the search fields in the search boxes, some of the sliders, it will not render as well unless you're using Edge or IE11.
Under the search window that we were talking about couple screens ago, in the top right-hand corner, is where you download the results of your search. [Let me go back for a quick minute here.]
In the top right-hand corner though, here's 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’s 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 is JSON and it does not render super well in Excel. But I'll talk about that in a minute.
I made a chart for all of the operators or the auditable events that are captured as well as their default status by Microsoft in the unified audit log. A couple interesting ones here.
A message being copied to another folder. That action is an auditable 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 audible event. If I'm an admin level user, it is.
Folder bind and message bind. These are two very interesting ones. Folder bind, a mailbox folder being accessed. Well, that can be extremely useful to an incident responder, right? If a bad guy has been in one of my user's email accounts, it'd be extremely useful to know if a bad guy was traversing down through folder structures. Did he stay in my inbox? Did he go to my doctor's folder with his rounding lists where he's been keeping my patient PII and PHI going back for years? Did he ever access that folder? Because that changes a forensic finding of years' worth of notifications now for the client. Or bad guy was only looking for invoiced 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.
Message bind, being even more important, message being viewed in the preview pane or open. Now this is speaking to, if I log in, whether as a legit user or a bad guy, into Office 365.com and I'm looking at an email account via the web browser and I'm clicking down through messages or objects, it's how Microsoft refers to it in their nomenclature, all of the objects that are being viewed, if you are a 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. Of course, then, you can comma separate the values of the operators that you want to turn on. By default, Microsoft does not have all of the operators on. Well, as we already discussed, by default, that logging is 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. This is kind of a sanitized one. I apologize for the big black boxes. 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 exported, 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 because 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 going to use for phishing on the compromised accounts in OneDrive or in their SharePoint. 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 right on that last screen. Those are kind of the more granular effects. I have another screenshot on that. But the mailbox log 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. UserLoggedIn 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 in an authentication event into the Office 365 account.
Now, for the most part, UserLoggedIn is the default. If a bad guy has logged in via Office365.com, via a web browser, this is the one you'll see the most common. But depending on if the client is 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 licensing Office 365, a lot of those factors can affect the way Microsoft sees the authentication into their infrastructure. Hence, the different operators that may capture a login event. So, you'd be remiss, if when you load that data you're only looking for UserLoggedIn, 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 UserLoggedIn for the purposes of this example, it can be 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 baselining a user's account.
You know, most of the time when my team is brought in we don't know the user's environment, the client's 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. I can go in here, we can pull this data out and I can baseline an account's activity.
Now, what are my outliers? IP addresses are always geolocating to this one part of the United States. That's right where the headquarter is for this client. All of a sudden, 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 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.
Of course, the ResultStatusDetail, value, success. I don't care about value fails. You'll see a lot of failures when you're doing these types of logs. Filter them all out. I mean, at the end the day, it may help give you some information. You know, someone beating on the door or someone trying passwords. But the end of the day, I care about success. If there wasn't 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-MailboxPermission, Add-RecipientPermission, and Set-Mailbox. Set-Mailbox is the forensic artifact that has laid down 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 user's 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 because, typically, most users aren't changing core settings in their account. If I'm looking at 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.
The Add-MailboxPermission and RecipientPermission 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 that account is logged in and being set as a delegate on other email accounts, the Add-MailboxPermission, RecipientPermission 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 admin's UAL.
Again, this is not rocket science for those of us that do this on a regular basis. I want to know if I've had unauthorized access, when did it happen and what else the actor did in the account. We're going to baseline that user activity. We're going to identify what is normal, what is legitimate, and now what is my outlier activity. And the outlier activity is what I'm going to care about. I'm going to 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 trying not to name specific countries, but from the African region that are usually interested in monetary gain through wire transfer, they will create mail rules. They will create mail rules to either cover their tracks from the kind of the spam that they flood out, or they will create a mail rule to auto-delete responses, and they want to 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 helped rise to the top if I'm looking at hundreds of accounts to look for those outliers. In fact, there's a good example … we're working on a 191-account breach right now. One of the things we've done with this volume of accounts is (a), it's 191 in total. I mean, that's a lot of accounts that have had unauthorized access out of a 10,000, 12,000 account tenant. One of the things we've been looking for is during the time we know of unauthorized access, who had mail rules? We 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 geolocation of the IP addresses is at 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 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 clients 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 a bad guy on one account, they may, especially if 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, they're from that same IP netblock.
I've got a 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 more of a broader scalpel to see if there's other IPs from that same actor group.
A couple examples of the clients you may see in the unified audit log. Microsoft's very proud of their products, right? So, they're going to give you very detailed information about Outlook, if it's their product, their client. Then, in my experience in looking at these logs, if it's not an Outlook client, they're like, it's IMAP. Well, thanks, Microsoft. You will notice they do not identify other non-Microsoft Outlook mail clients. They, literally, let you know there's a protocol, which is indicative of a non-Microsoft Outlook mail client access in the account. Which, of course, 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 active sync of an email account.
Going back to the rules we touched on briefly a minute ago. So, these are the operators you would see inside that 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. 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. You can actually see almost the seconds between the actor clicking the different options within the mail rule 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 incident responder to see if a bad guy has put an email address. This, more times than not, is completely missed by InfoSec teams in the company. They know to go to look for mail rules. Mail rules have been around since as long as Microsoft has had earlier versions of Outlook. This is specific to Office 365. The only way you'd be able to go in and find that is actually you could do it via PowerShell or go into the user's account and manually go look for this.
Here's the IP address examples I was telling you about. So, if you want to search unified audit log from PowerShell, you're a command line guru, you want to dive in, this would be the command that you would issue from PowerShell to actually search the unified audit log. This will actually search all unified audit logs. So, all the audit logs for all of your users in your tenant. This is a quick way, quick down and dirty way. If you have some indicators of compromise: type them in, you give the dates, the start and the end, export to a CSV. 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 trying to do netblock. So if you know I have a bad IP, it goes back to a hosting center, no legitimate activity, do a who-is, 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 actor is using other boxes from that hosting provider or other IPs within that range.
Beyond the unified audit log. In Azure, depending on the licensing of the tenant, usually it requires an E1 and E3 licensing, there are a couple additional things that Microsoft has done to try to help incident responders pull out suspicious activity. You would see users flagged for risk and risky sign-ins, and those would be two very quick logs you go to. Usually, it logs seven days, or 30 days is the max that are available. So, they're extremely volatile.
Wrapping up real quick because I think I'm pushing my time. If you want to 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. 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.
This was, very briefly, had an incident response scenario we were doing. Had a couple emails I pulled out of a PST: “Hello Frank, per our prior conversation, please let me know what you think about it.” I was 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.
I'm not going to 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 looking at the emails that may be of interest and may still be left over in the PST. Those, of course, help from a timeline analysis standpoint. If we know the actor is in the account and we're looking for particularly what they did, you may find some very interesting emails actually still left in the account. RSS subscription 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. It's a great spot where actors’ rules will usually mark as read and move messages to there.
The 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 it had the user, legitimate user ID, 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 by clients, "What can we do to make sure that we protect and harden ourselves?” Multi-factor authentication usually will nullify probably 99% of these types of attacks. Right? If you're using single factor and a phishing page captures username and password, you're going to 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. It asks for username, password, and your token. I've had some instances where users have given up their token, token's usually good for 10, 15 minutes, depending how it's configured, and the bad guy still gets in. So, be aware of that.
Domain auto-forwarding blocks. At the end of the day, auto-forwarding messages out of your tenant because the bad actor has created a mail rule is a significant issue. These would be ways where you can stop that. In most clients I speak with and do the 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, if they do tend to be auto-forwarded, they will get dropped and they will not be delivered successfully.
That's it. Questions.
