Tag: Exchange Online

eDiscovery in Office 365

Now that we’ve spent a few minutes to go over data retention and destruction in the service to make sure you’re retaining the data that you’re obligated to keep, let’s take a bit of time to make sure you’re able to quickly and reliably identify information. Why? Because there are times where you’ll need to export copies of data for legal reasons, delete phishing attempts, or just to find out if a message was read by someone.

I’ll spend time outlining PowerShell syntax in the examples here to help cut down on human error. Most people who are adverse to using the command line are usually uncomfortable because the syntax is difficult to remember or the process seems more arcane. It’s often beneficial to leverage the shell for discovery to enable you to be more granular with your searches in order to reduce the cost of first pass litigation by outside council (the numbers are scary). It also allows you to efficiently document the search syntax to ensure reliable internal knowledge transfer and simplify repeated searches by allowing the individual performing the search to copy/paste the actual search commands.

Before you’ll even be able to connect to the service via PowerShell you’ll need to make sure that you have the right level of permission. With RBAC (Role Based Access Control) it’s possible to scope permissions within the compliance center to allow only eDiscovery to individuals who may not need access to things like email security settings or the audit log. In most cases, the eDiscovery Administrator role will be enough for discovery activities, but if those individuals also need to be able to purge data they’ll also need to have the “Search and Purge” role assigned which is only part of the Organization Management role by default. A little more information on those permissions can be found here and a quick reference on how to assign role group members to a role is included there as well. And since it’s easy for an attacker to use eDiscovery to exfiltrate data, don’t forget to make sure that individuals with eDiscovery permission are required to use multifactor authentication as well!

Now that you’ve got the permissions taken care of and we’ve touched on ensuring MFA is enabled, you’ll need to connect to the security and compliance center using the Exchange Online PowerShell module. Once the module is installed, it’s just a simple one line command to connect.

Connect-IPPSSession -UserPrincipalName matt@collab-crossroads.com

Once you’re connected, the syntax is simple. We’ll be working with 

New-ComplianceSearch
command to identify the potentially malicious message below:

The search syntax is simple. We know the message we want to identify was sent on 4/4 and has ‘Test’ in the subject and body. We’re not sure who else might have gotten this particular message that we want to remove so we’ll check every mailbox in the organization using ‘All’ for the Exchange location. The search is boolean so there are a couple gotchyas every now and then. In this case, note the parenthesis around the sent and receive dates. We need to make sure that those are considered first, so we put them in a block before moving on to the less complicated key word search in the subject. We won’t get into complexities of script blocks, but in our case just know that it’s just like simple math; we calculate what’s in parenthesis first before moving on to the rest.

New-ComplianceSearch -Name "Test Search" -ExchangeLocation all -ContentMatchQuery '(sent>=04/01/2019 AND sent<=04/05/2019) AND subject:"Test"'

Once you’ve created the search, start it using:

Start-ComplianceSearch "Test Search"
Depending on how complex the search is it might take a while to complete. In our case it’s a single message in a single mailbox so it completes very quickly and you can see the results using: 
Get-ComplianceSearch "Test Search"

There are a number of really handy metrics that Exchange will report on that you might be interested in from time to time. The obvious ones are who started the search, is it completed, how long did it take, and how many items did we find?

If you pipe the Get-ComplianceSearch command to FL it will format the results in list form and show you everything that you can select from. Since we only want a subset of these results you can select specific items in results of the previous command.

Now that we’ve confirmed the results are what I was looking for we can choose to take action on those results using the New-ComplianceSearchAction command. Before choosing to delete anything always make sure to preview and export a copy:

A couple things to note here, first we’re deduplicating results in the export using the -EnableDedupe parameter. Next, we’re choosing to export a PST per mailbox that the results are in using the -ArchiveFormat parameter. Since the compliance center temporarily stores the export in Azure blob storage, it’s not possible to actually download the export through PowerShell so we’ll go into the compliance center to actually download the report. Under Search and Investigation and Content Search you’ll see the search we just created. Selecting the Exports tab will show the export as well:

Since Google deprecated ClickOnce you’ll need to use Internet Explorer to install the small agent required to download the export. Once clicking the “Download results” button within the export request you’ll be prompted to install the agent. Then you’ll be prompted for the export key shown below as well as an export location to save your export.

Now that we’ve made sure that we’re deleting the right content and have a copy of that content, let’s go ahead and delete it. The New-ComplianceSearchAction command will be used here as well.

 New-ComplianceSearchAction -SearchName "Test Search" -Purge -PurgeType SoftDelete -confirm:$False

After verifying that the action was completed using the Get-ComplianceSearchAction command, you can see that the message in question was indeed removed:

In this scenario we focused on deleting a potentially malicious email (phishing, malware, or malicious insider) from a mailbox. The process of exporting data for a litigation search is identical, with the exception that you’re not actually deleting the data. Next time we’ll take a look at using the threat explorer to accomplish the same activity!

Securing Exchange Online

For those of you who weren’t lucky enough to attend, or simply didn’t know it was happening, Microsoft wrapped up Ignite last week and left us with plenty of savory info!

For most of 2018 I’ve been working with customers of all sizes and helping them to understand security in Office 365, namely in One Drive for Business and Exchange Online. Most customers are at least a little leery about placing critical workloads like Exchange and file storage in the cloud without understanding at least a little bit about how that information is secured. Well, Microsoft took a moment to outline a few simple configuration changes that will immediately improve your security stance in Exchange Online.

So to get this shindig kicked off, let’s take a look at the different stages of breach. When defending against threats it’s important to understand this as a killchain and defend as far to the ‘left’ in the killchain as possible and of course, throughout.

S_EXO_Attacker Killchain

Attackers will perform a discovery, or recon of your tenancy to understand more about your users. During this phase, they’ll try to determine more about your users and what they may be able to use to exploit them. This may be as simple as checking your company’s webpage or wikipedia to find out who senior management is in order to either target them or use their information to convince others.

After they’ve gathered enough information, they’ll try to use it to actually breach your organization. Things like password spray, brute force, and just good ole’ fashion fishing will be their tools of choice.

Once they’ve gained access, then the exciting stuff starts! They’ll first enumerate who your users are, including your admins and specifically target them. Not only that, they’ll do their best to make sure that they retain access to anyone they gain access to with things like inbox rules, mobile device enrollment, delegation, external sharing requests, etc. Finally, they’ll use common practices like eDiscovery, mailbox protocols, and external forwarding to grab your information and sell it to the highest bidder!

So how do you protect yourself? Again, focusing to the left in the killchain we’ll want to start with end user education. Educate your users around things like passwords and what kind of information they divulge in social media. Then we’ll do our best to combat the initial breach. Enforcing things like extranet lockout in ADFS, ensuring mail authentication (SPF, DKIM, and DMARC) are set up correctly, and limiting app framework in Azure.

To address elevation of privilege, we really want to focus on admin roles and impersonation. First, multifactor auth is an absolute requirement for administrators. That’s non-negotiable. Impersonation should only be used when absolutely necessary, and that’s pretty rare. Some third party apps require impersonation to work, but other than that, almost no one should be grated impersonation permissions. Since it doesn’t change too often, a pretty easy way to review it would be to imply set up an alert policy in Office 365 to alert an admin when impersonation has been granted. If it wasn’t you, then remove the access and start an account breach remediation  process on the person who granted it.

Next, we’ll want to address entrenchment. Attackers will do their damnedest to retain the access/information they have. First, look into Azure information protection. If your information leaves the organization but is encrypted, it’s much better than the alternative. Attackers will create inbox rules for end users to automatically forward messages or to hide responses or remove responses based on key words like ‘Helpdesk’, ‘phish’, ‘hack’, etc. Then they’ll forward mail outside of the organization that looks interesting to them. Allowing automatic forwarding outside of your organization needs to be disabled unless absolutely necessary.

Finally, they’ll use admin roles to export all the information they can. You need to make sure that you don’t grant discovery permissions to people who don’t need it. Then you need to alert on who exports that information and audit on what else that person did.

There’s a lot here, but start with some simple things. Enforce multifactor authentication for both admins, and all users. That will drastically reduce the risk to your end users. Next, disable legacy protocols like POP, IMAP, and SMTP Authenticated Send to ensure that attackers can’t bypass MFA and can’t use accounts they have access to, to phish your internal users. Finally, set up alerting policies for forwarding, elevation or privilege, and eDiscovery.

Don’t believe me? Watch the presentation from Ignite:

https://myignite.techcommunity.microsoft.com/sessions/65645#ignite-html-anchor