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!

Unique Local Admin Passwords – How and Why.

So here we are, early 2019 and just a few months removed from a data breach at Marriott that saw over 500 million guests’ personal information hit thSecurity_Oopsiese public internet. If that sounds like an insane number you’re absolutely right! That’s nearly 6% of the world population and about 150% the population of the US.

So the big question is how. How do things like this happen, how do attackers gain so much information, how do they exfiltrate the data, and how is it so common that Forbes is over here making cyber predictions for 2019!?

A while back I wrote about securing privileged access with a brief, high level overview of how an attacker will work to gain access in an organization and work to keep it. Part of that process is by making use of local admin credentials harvested from the first compromised machine to pivot around the network to see what else those credentials will work on. Sounds harmless enough, but what if the machine they gain access to is a domain controller? Or an admin’s workstation who happens to have administrative privileges on his daily account?

Security_killchain

During this process it’s difficult to detect because the attacker is using valid credentials to pivot around the network digging for more information or waiting for an admin to slip up. The first step to stopping this is by attacking the first link in the kill chain and limit privileged escalation of other workstations. How? By making sure that other workstation doesn’t have the same administrative password as the one the attacker already has.

Enter LAPS! The first part of the solution involves deploying an agent to each workstation and server on the network. That agent can be downloaded here. Since Microsoft was kind enough to provide the package as an MSI it’s easy enough to deploy with a script (msiexec /i \\fileserver\share\LAPS.x64.msi /quiet), Intune if you’re into comanagement, or good ole’ fashion SCCM. Definitely be sure to update your images to include the agent as well! Once that’s deployed and imaging has been updated, admin users need to install the management client on their PAWs (you are using a privileged access workstation, right?) to get the management client, powershell module, and GPO templates for management.

LAPS_AdminInstall

The next step is to make sure that the Active Directory Schema is taken care of. We need to extend the schema to include the attributes that we’ll be working with and then make sure to update permissions so we’ve accounted for users who shouldn’t be able to see those attributes. To extend the schema we need to use one of the admin workstations we just installed the management tools on and import the module in a powershell session and update the schema:

Import-module AdmPwd.PS
Update-AdmPwdADSchema

LAPS_SchemaExtension

After waiting a short while for that schema change to replicate we’ll move on to making sure only specific users and computers have access to the AD attribute that now stores these passwords. The first step is to remove permissions for groups at the OU level. If you’ve blocked inheritance you’ll need to make sure to take care of any nested OUs as well.

  1. Open ADSIEdit
  2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties.
  3. Click the Security tab
  4. Click Advanced
  5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit.
  6. Uncheck All extended rights

*Be sure to preview all extended rights permissions first to make sure you aren’t removing permissions required by that group of users

LAPS_Security1

Now that we’ve taken care of scoping away permissions from unintended users/computers, we need need to make sure that the machines themselves have access to write to this attribute so they’re able to update their own passwords as they expire.

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Servers,DC=domain,DC=com"

LAPS_Security2

We’ll grant individual admin groups access to read those randomized admin passwords:

Set-AdmPwdReadPasswordPermission `
-OrgUnit "OU=Admins,DC=domain,DC=com" `
-AllowedPrincipals Domain\PasswordAdmins

And of course we need to account for password resets as well so let’s add reset permissions:

Set-AdmPwdResetPasswordPermission `
-OrgUnit "OU=Admins,DC=domain,DC=com" `
-AllowedPrincipals Domain\PasswordAdmins

Finally, you’ll want to hop into Group Policy on that admin workstation you installed the tools on to establish the password policy settings you’ll be enforcing on those workstations and servers.

LAPS_GroupPolicy

There’s quite a bit here to chew on but it’s not technically challenging so give it a try in a lab, then roll it out to your user workstations and eventually the servers as well! Again, the idea here is to limit lateral movement and make elevation of privilege more and more difficult for bad actors.

We’ll have another shorter session to go over some of the day to day admin tasks like looking up those passwords and resetting them, but that day is not today!

Securing Privileged Access – Part 1

After a little bit of a holiday hiatus we’re back to start a segment on securing privileged access. When we refer to privileged access we’re talking about everything from the different levels of administrative access, to privileged users who might handle extremely sensitive data for your organization.

So many organizations still believe that traditional firewalls are enough to keep the big, bad internet at bay. Well, in the modern enterprise it’s foolish to believe that you’re able to keep your data within any boundary while your users begin to work remotely, leverage third party SaaS storage (Dropbox, Google Drive, OneDrive, etc.), or you begin to host your data in an enterprise cloud like Office 365. I’m not here to tell you that those firewalls aren’t absolutely necessary, but it’s important to realize that the days of recognizing your firewall as the security boundary are over and you need to work hard to secure identity, regardless of where your data is hosted.

Recognizing that, let’s take a look at how a typical credential theft takes place in an organization:

Privsec_CredentialTheft

An attacker is going to establish a foothold in your organization by targeting end users with social engineering or phishing attacks. Once they’ve got access to that user’s computer they’ll start working on lateral movement, meaning that they’ll begin reaching out to other computers or servers on the network to see what else can be compromised. Maybe it’s by exploiting non unique local admin passwords, maybe the originally breached user has access elsewhere, or maybe an admin isn’t using a separate account for admin activities. Pivoting further and further until control of the directory database is gained (through actual domain admin permissions, by exploiting misconfigurations, or server agent configuration).

Privsec_Stage1

The first step is a simple one, and to many organizations it’s already very well ingrained in IT culture. Administrators need dedicated administrative accounts that are not shared with any other admins. I work with too many customers where this isn’t that case. Some have a generic account with domain admin that’s used for automation or just ‘general use’, or they flat out grant admin permission to their day to day account. Admin roles in your org should be reported on regularly to identify these and there should be alerts for elevation of privilege with an actual process for following up on those.

The next steps are again, not technically challenging but require culture change that many admins are adverse to. Privileged Access Workstations need to be deployed for users owning high value admin roles, and unique local admin passwords need to be deployed to workstations first and finally servers to help stop lateral movement. I’ll reach back to these two topics later with dedicated articles, but for now; know that it needs to be accomplished and needs to be prioritized.

Now that we’ve touched on high level goals of attackers and the first steps required to secure privileged access, I’ll follow up soon with part two. I’ll be working through Microsoft guidelines published here so definitely feel free to read ahead a little and ask questions!

Managing Major Changes to Office 365

Admins are expected to keep tabs on major changes to the service and understand how those could impact uptime, or just good ole’ fashioned end user experience. Unfortunately, there are hundreds of items coming down the pipe that may or may not be relevant to every organization and it’s difficult to follow it all.

The first part of making that manageable is understanding how Microsoft’s release options work. Updates are released to different update ‘Rings’ as the updates become more mature. The first three rings are Microsoft release teams where Microsoft consumes the updates first, prior to being formally released to the rest of the world.

M_O365_UpdateRings

After that, you can select to add friendlies to the targeted release group. These would typically be IT groups or power users who will be a little more adaptive to change. Here are a few of the benefits of making sure you have decision makers in the targeted release group:

  • Test and validate new updates before they are released to all the users in the organization.

  • Prepare user notification and documentation before updates are released worldwide.

  • Prepare internal help-desk for upcoming changes.

  • Go through compliance and security reviews.
  • Use feature controls, where applicable, to control the release of updates to end users.

Here’s how you can add individuals to targeted release.

Handy, right? Super common use case here; Teams were released about a year ago and most customers had no idea exactly how it would impact them or how their users would cope. The feature was added to enterprise licensing and enabled by default upon standard release. The trouble? End users were able to go to http://teams.microsoft.com and create a new one with any name and any picture which shows up in the address book with (at the time) no central management and can potentially be shared with the wide world of the internet. Mayyyybe you might want to review that feature to make sure you have controls in place that match your organization’s goals.

Facepalm

In addition to release options you’ll want make sure that your team is managing the message center for major updates.

M_O365_MessageCenter

Updates in the service come at you pretty fast, but Microsoft does a pretty decent job of providing information and allowing you to plan for them. Make sure you keep an eye on the roadmap, the message center, and of course make use of targeted release to find out how those changes will impact your users!

Now don’t mind me while I go drown myself in meaningless college football games!

Saturday

The Journey Begins

And here we are at the Crossroads of collaboration and productivity. With this little diddy I’ll make my foray into the wild, wild world of technical blogging.

I’ve been lucky enough to become an established engineer and have claimed some of the most iconic brands and organizations in the world as my customers in the last ten years. My goal is to share some of the knowledge I’ve gained along the way with hopefully, a bit of a smile as well.

Here you’ll find tips, tricks, and news about technical collaboration solutions used by organizations today. Everything from specific script samples, deployment guidance, and migration scenarios to major news released by industry leaders.

I’ll start with the message that struck me quite a while back and hope it does the same for you. Steve Jobs paid forward to the graduates of Stanford University in 2005 when he sent them off into the world with four words. Stay hungry, stay foolish.

For those of you who don’t recognize the reference, Steve was referencing the closing message of The Whole Earth Catalog. His message was one of ambition, living life, and embracing risk.

Education begins the gentleman, but reading, good company, and reflection must finish him. – John Locke

post