Email remains one of the most heavily used communications mediums within organizations today. With as much as 75 percent of your organization’s intellectual property stored in email^[1], Microsoft Exchange is for all practical purposes a treasure trove of organization’s most valuable secrets—just waiting for inappropriate access.

Regulatory bodies realize this and therefore email and compliance go hand in hand-in-hand. So IT needs to keep a watchful eye on exactly who is accessing what within Exchange Online. And that focus shouldn’t be only on the people you trust, such as those who have been granted access to a given mailbox, but on any user. IT needs to help ensure visibility into the actions of potential threat actors who might have hijacked privileged accounts. The first thing external threat actors do after infiltrating your network is attempt to identify accounts that have elevated permissions. And those accounts can have access to the sensitive information stored within Exchange Online.

For years, Microsoft has enabled an audit trail within on-premises Exchange Server. The same capability exists for Exchange Online—with some improvements to boot—giving IT organizations visibility into actions performed by administrators and regular users alike. But be forewarned: You’re largely on your own here. Microsoft has provided some functionality via administrative consoles, but the ability to successfully enable, configure, and audit Exchange Online events depends fairly heavily on PowerShell^[LP1].

The challenge isn’t configuring the auditing of events; that part is simple. Rather, the challenge is finding the event or events that are pertinent to the auditing query in question. If you’ve spent any time in Event Viewer, you know how it feels to rummage through countless thousands of event entries, trying to find the one entry you’re looking for.

Microsoft has taken great strides to provide you the tools necessary to simplify the process of auditing. Still, a bit of work remains to enable, configure, and retrieve meaningful audit data.

This whitepaper explains those necessary steps and provides guidance for properly auditing changes to your Exchange Online environment within Office 365. The paper also covers ways to focus your auditing lens on the right what, who, and where so that you can quickly and accurately find answers to those sometimes difficult auditing questions. 

Auditing Experts – Quest

Understanding what’s going on within Exchange Online involves much more than the ability to centralize audit data. To truly audit such complex environments, you need a deeper understanding of each event and its detail, how audit events correlate, and what that information means to the organization—along with the ability to make the data understood.

Quest Change Auditor is the culmination of tens of thousands of hours of work dissecting every auditable event over a variety of platforms and applications. This effort turns raw, indecipherable information into intelligent detail, from which an IT organization can obtain actionable insight.

Look for auditing insights from Quest throughout this paper.

Connecting to Office 365 to Enable and Configure Auditing

The first step is to enable auditing. Auditing is disabled by default, as not every organization is required to — or even interested in — auditing what happens within Exchange Online. As previously mentioned, much of this step happens in PowerShell. You’ll need to connect to Exchange Online via PowerShell so that all commands are run against your instance of Exchange Online.

Open a PowerShell window. You don’t need to be a local admin to run Exchange commands against the cloud, but you do need appropriate permissions within Exchange Online; more on these permissions soon. To connect to Exchange Online, you’ll run four commands.

Set-ExecutionPolicy RemoteSigned

This command tells PowerShell that any scripts that are downloaded by a trusted publisher (Microsoft, in this case) can run on the local computer.

$UserCredential = Get-Credential

This command displays a login dialog box that you use to store an Office 365 admin credential (which does not necessarily need to be the same credential you used to start the PowerShell window) as a parameter for use in the third command.

$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential –Authentication Basic –AllowRedirection

This command establishes a new PowerShell session with Office 365, using the provided credentials and the specified URL. The command stores all this information in the $Session variable.

Import-PSSession $Session

This command imports commands (e.g., cmdlets, functions, aliases) from the remote computer (i.e., Office 365) into the current session. At this point, you’re properly connected to Exchange Online and can begin auditing your Exchange Online environment. 

Quest Insight – What Should You Be Auditing?

Exchange Online can be configured to generate a ton of information—which, of course, means more data for you to sift through. Because you are essentially in control of how much audit data is generated, you can determine which activities to include. You can focus on three categories of audit activity:

·         Message tracking is the actual flow of messages from one user to another. At a minimum, this category can be used to show who is emailing whom, such as whether email is being sent to a competitor. On a larger scale, message tracking can be used with analytics to see how the business uses email. This tracking is useful to see how internal messaging flows; for example, from one department to another. Message tracking can also be used to see the flow of traffic in and out of the organization; for example, which domains send or receive the most email. You can use the Get-MessageTrace cmdlet to retrieve a list of messages that meet query criteria such as sender or recipient address, date range, or source IP address. This activity is most appropriate when a review of specific sent and received messages is needed in addition to a review of mailbox contents. This tracking can also be useful when connected to a SIEM solution, using keyword alerts to identify inappropriate messages.

·         Admin operations involve any actions that are taken within Office 365, including actions by your IT team or Microsoft (which maintains the Exchange Online instance). Admin operations, such as assigning permissions to a mailbox or setting up forwarding rules, can play a key role during an audit; even IT can play a role in inappropriate behaviors.

·         Non-owner mailbox access occurs whenever someone other than the owner accesses a mailbox. This category is important when sensitive information has been inappropriately accessed or forwarded, and the focus is on identifying who is responsible.

Because message tracking typically falls outside an IT security audit, this paper foregoes that topic and focuses on the other two audit areas, which directly affect your organization’s ability to document access, changes, and actions that would be of interest during an audit.

Auditing Admin Operations

Auditors are big believers in the ability to watch the watchers. Questions around changes that IT has made are just as important as those that focus on users exercising access that IT has granted. For example, if an audit revolves around the CEO forwarding intellectual property to a competitor, a good auditor doesn’t just accept that the CEO forwarded the information. Rather, the auditor also asks who has been granted permissions to the CEO’s mailbox—and who in IT granted those permissions.

Both security and compliance initiatives are useless without auditing admin operations. Because there are no preventative controls for admins (who need the ability to do “everything” to get their job done), the need for controls that detect and deter inappropriate behavior is necessary. By putting an audit trail in place, you create accountability. After all, knowing that they’re being audited tends to encourage admins to keep their behavior in check.

When it comes to Exchange Online, a number of actions can indicate malicious activity. For example, the exporting of a mailbox doesn’t require logging on to the mailbox; IT can simply export and review the local PST. Therefore, IT logging on to an exported mailbox should trigger non-owner mailbox auditing. Another example is granting permissions: IT could assign a cohort inappropriate permissions to another user’s mailbox, and then remove those permissions after improper access is completed. Unless you have non-owner mailbox auditing enabled, this access would go completely unnoticed.

You can see why admin operations need to be included as part of your auditing strategy. Everything an admin does within Exchange Online is ultimately a PowerShell command, so Exchange audits admin activity at the PowerShell level. Each time an audited cmdlet is run, the action is logged.

To check which auditing is enabled within your organization, you can use the Get-AdminAuditConfig command, shown in the following figure.

Place specific focus on the AdminAuditLogCmdlets, AdminAuditLogExcludedCmdlets, and AdminAuditLogParameters fields, which identify whether every admin operation is audited or a subset.

Quest Insight – Age Limits

By default, admin audit data is kept for 90 days (as indicated by the AdminAuditLogAgeLimit value in the previous figure). You might want to consider extending the retention time. Organizations that perform annual audits should consider extending this value to more than 365 days (one year).

To enable auditing, you need to leverage the Set-AdminAuditLogConfig cmdlet:

Set-AdminAuditLogConfig –AdminAuditLogEnabled $true

Quest Insight – Enabling Just the Right Amount of Admin Auditing

Each organization has different auditing requirements, so auditing of admin actions isn’t always as simple as “just audit everything.” If you simply enable all admin auditing, you’ll see all the changes that Microsoft makes on the back end, which might be something you don’t care to filter through during an audit.

Because admin auditing is based on the premise that every performed action relates to running a PowerShell cmdlet, the Set-AdminAuditLogConfig cmdlet enables you to specify which cmdlets and cmdlet parameters to include or exclude. Be sure to note that auditing of commands in Exchange Online does not include read-only types of commands, such as any Get and Search commands.

You can specify individual cmdlets or use wildcard characters to denote a group of cmdlets:

Set-AdminAuditLogConfig –AdminAuditLogEnabled $true

-AdminAuditLogCmdlets * -AdminAuditLogParameters *

-AdminAuditLogExcludedCmdlets *Mailbox*, *TransportRule*

 So, how do you get this information out of Office 365?

There are two ways to extract admin auditing information from Office 365: via PowerShell or by using the Office 365 Security & Compliance portal.

Auditing via PowerShell

Using PowerShell to audit can be accomplished by using the Search-AdminAuditLog cmdlet. When you use this cmdlet with no filtering parameters, you obtain the last 1000 entries. This information shows the cmdlets and parameters that were used, who ran each action, whether the action was successful, the object affected, and more, as shown in the following figure.

The Search-AdminAuditLog cmdlet results don’t provide comprehensive detail; for example, the Caller field, which specifies which users called the cmdlet, is blank. So the cmdlet is more useful if you’re trying to get an overview of changes made rather than performing an actual audit.

You can alternatively use the New-AdminAuditLogSearch cmdlet to receive an emailed XML report of the log entries within a specified date. For example, in the following figure, you can see that an admin is adding full mailbox permissions to the user bbrooks.

Quest Insight – Filtering Cmdlet Searches

The basic cmdlets return a large amount of data that might include the behind-the-scenes management actions performed by Microsoft. So it’s important to use the cmdlet’s parameters to filter the noise of all the resulting data.

Both the Search-AdminAuditLog and New-AdminAuditLogSearch cmdlets enable you to filter by date, cmdlet used, parameters used, the user who performed the action, whether that user is external to the organization, and the objects that the action affected.

By using some of these filters, you can hone down the results to a more pertinent set of data, increasing your productivity by more quickly finding the answers you need. 

Auditing via the Office 365 Security & Compliance Portal

Those who simply aren’t “PowerShell people” and would rather use a management console can take advantage of the Audit Log Search functionality in the Office 365 Security & Compliance Portal. In the pre-created Activities, you can begin your audit by simply selecting a management action, such as the delegation of mailbox permissions in the following figure. You can use the additional filter fields to further refine the results to the few that meet your criteria.

Be aware that the Activities are a double-edged sword. You are limited to those activities (with the supported filters) and cannot generate custom search scenarios of your own. For example, you can’t search for every time someone exported a mailbox (at the time of this writing).

Results can be exported as well, for reporting and further analysis.

You will experience a few limitations should you choose to use the console. First, you’re limited to only 90 days of audit data — and there’s no way around that. In addition, although audit data is available to PowerShell cmdlets within 30 minutes, accessing the same data via the console can take up to 24 hours.

Auditing Non-Owner-Mailboxes

Auditing administrative actions helps to identify the events leading up to inappropriate activity within Exchange. But the real value is found in auditing access to the data that is stored within Exchange. The assumption with non-owner mailbox auditing is that the mailbox owner is using the mailbox appropriately. (Sure, cases of insider misuse by a mailbox owner exist, but those issues are addressed by message tracking.) So, the focus shifts to any non-owners that access a given mailbox.

In general, you should be concerned any time a non-owner views, sends email on behalf of, or deletes email in another user’s mailbox. Delegates — a part of Exchange for as long as the product has been available — are a vital part of the productivity of many users who require assistance from other employees. But because delegate access exists, and because inappropriate delegate access can be granted, auditing non-owner access to mailboxes provides an important piece of data. 

Quest Insight – Which Mailboxes Should You Audit?

Which mailboxes to audit is a valid question. Find the answer by considering these questions:

·         Is there any delegate access? If so, turn on auditing. This way, you have an audit trail of every time the delegate accesses the owner’s mailbox and what was done.

·         Does the mailbox contain sensitive data? Mailboxes that are owned by users who regularly send and receive financials, intellectual property, legal documents, and so on might be prime targets for insider activity. Even when no delegates are assigned to a mailbox that contains sensitive data, enable auditing proactively so that you have an audit trail of any and all access to the mailbox.

Unlike admin auditing, which is an organizational-wide audit setting, non-owner mailbox auditing is enabled on a per-mailbox basis. Audit log entries are retained, by default, for 90 days—a value that can be customized.

You can enable non-owner mailbox auditing at three levels, each with specific audited actions:

• Admin. This level audits actions by admins who have not been granted delegate permissions to a mailbox.
• Delegate. Anyone who is assigned permissions or given Send on Behalf of permissions is considered a delegate.
• Owner. Auditing for the mailbox owner is typically disabled, as it isn’t relevant to audits. In addition, enabling owner auditing generates a great deal of information. Non-owner access is generally infrequent and limited in scope (e.g., an assistant sending out calendar invites for their boss, someone in IT finding a specific message), whereas audits of owner access encompass every email created, read, filed, deleted, and so on.

Enabling Non-Owner Mailbox Auditing

Like admin auditing, non-owner mailbox auditing is enabled by using PowerShell via the Set-Mailbox cmdlet. As previously mentioned, this action is accomplished on a per-mailbox basis and requires that you specify which level or levels of auditing (admin, delegate, or owner) you want to enable:

Set-Mailbox –Identity “John Smith” –AuditDelegate SendOnBehalf,FolderBind –AuditEnabled $true

How do you figure out when someone was actually logged onto their PC? By “logged onto” I mean, physically present and interacting with their computer. The data is there in the security log but it’s so much harder than you’d think.

First of all, while I said it’s in the security log, I didn’t say which one. The bad news it isn’t in the domain controller log. Domain controllers know when you logon but they don’t know when you logoff. This is because domain controllers just handle initial authentication to the domain and subsequent authentications to each computer on the network. These are reflected as Kerberos events for Ticket-Granting Tickets and Service Tickets respectively. But domain controllers are not contacted and have no knowledge when you logoff – at all. In fact, look at the evens under Account Logon audit policy subcategory; these are the key domain controller events generated when a user logs on with a domain account. As you can see there is no logoff event. That event it only logged by the Logoff subcategory which and really, the whole concept of a discreet session with a logon and logoff has disappeared. You may remain “logged on” to your PC for days if not weeks. So the real question is not “Was Bob logged in?”, it’s more about “Was Bob physically present, interacting with the PC?”. To answer this you have to look at much more than simple logon/logoff events which may be separated by long periods of time during which Bob is anywhere but at his computer.

Physical presence auditing requires looking at all the events between logon and logoff such as when the console locks, the computer sleeps and screen saver events.

Logon session auditing isn’t just a curious technical challenge. At every tradeshow and conference I go to, people come to me with various security and compliance requirements where they need this capability. In fact one of the cases where I’ve been consulted as an expert witness centered around the interpretation of logon events for session auditing.

The absolute only way to track actual logon sessions is to go to the workstation’s security log. There you need to enable 3 audit subcategories:

1. Logon
2. Logoff
3. Other Logon/Logoff

Together, these 3 categories log 9 different events relevant to our topic

• 4624 - An account was successfully logged on
• 4634 - An account was logged off
• 4647 - User initiated logoff
• 4800 - The workstation was locked
• 4801 - The workstation was unlocked
• 4802 - The screen saver was invoked
• 4803 - The screen saver was dismissed

But how do you correlate these events because that’s what it’s all about when it comes to figuring out logon sessions. It is by no means a cakewalk. Matching these events is like sequencing DNA but the information is there. The best thing to do is experiment for yourself. Enable the 3 audit policies above and then logon, wait for your screen saver to kick in, dismiss the screen saver, lock the console as though you are walking away and then unlock it. Allow the computer to sleep. Wake it back up.

As you can see there is some overlap among the above events. What you have to do is between a given logon/logoff event pair (linked by Logon ID), identity the time periods within that session where the user was not present as a result of

• Sleep (that of the computer)
• Hibernation
• Screen saver
• Console locked

And count any session as ending if you see

• Event ID 4647 for that session’s Logon ID (User initiated logoff)
• Event ID 4354 for that session’s Logon ID (Logoff)
• Event ID 4608 – System startup

As you can see, the information is there. But you have to collect it and that is a challenge for most organization because of the sheer number of workstations. SIEM solutions like EventTracker automate this for you whether by remote event collection which can be practical in some cases or with the more feasible end-point agent.

“This article by Randy Smith was originally published by EventTracker” https://www.eventtracker.com/newsletters/tracking-physical-presence-windows-security-log/

Moving Exchange to the Office 365 cloud eliminates a lot of work but it doesn’t eliminate your compliance responsibilities or security requirements. To be compliant and to detect information grabs and data theft you need 2 critical feeds of activity from Exchange Online:

1. Non-owner mailbox access – especially “high value” mailboxes like executives
2. Privileged user operations

Exchange Online provides the ability to monitor both. And if you are familiar with Exchange on-premise you will find a degree of shared functionality – at least on the surface.

For instance, the configuration of mailbox audit policy and of the admin audit log use the same 2 PowerShell commands as Exchange on-premise

• Set-Mailbox and all the “-Audit…” parameters
• Set-AdminAuditLogConfig

But as with Exchange on-premise, getting the audit data out of Exchange Online is nowhere as easy. Especially with regard to mailbox auditing. The Search-MailboxAuditLog command that runs synchronously has restrictions on the amount of detail that eliminates it from consideration. The asynchronous New-MailboxAuditLogSearch command has restrictions (also found in Exchange 2016) that silently limits you to 10 search requests in any 12-hour period. And those search requests have caps on the amount of results and can take many hours to be fulfilled.

On the interactive side, Office 365 provides an Audit and Compliance portal that allows you to perform ad hoc searches against the “unified audit log” which includes Exchange Online audit events. However this portal is really only appropriate for fairly casual investigations into recent activity. You are limited to certain pre-conceived search scenarios of which viewing content of mailboxes is conspicuously absent. Perhaps most importantly, Office 365 only keeps audit data for 90 days.

So how does an enterprise fulfill their compliance requirements? Microsoft is certainly not unaware of compliance and the fact that they can’t go to market without giving customers some options. Right now there is just one option: the Management Activity API. This RESTful service does provide an enterprise-grade ability to get all your audit data out of Office 365. But it requires custom programming and at that point you’ve only gotten the audit data out of the cloud in XML format. What do you do with it then? Never mind the rest of the compliance story such as reporting, alerting, archiving and so on. And if I was a cyber security officer I’d want to be able to correlate that activity in the cloud with everything else going on in my network.

That’s where Quest Change Auditor comes in. The folks at Quest have done the heavy lifting to integrate audit logs from Exchange Online with the rest of the activity they collect, normalize and monitor from all over your network. The latest version of Change Auditor implements the Management Activity API and other APIs from Office 365 to automatically collect Exchange Online mailbox and administrator audit logs. Change Auditor brings to Exchange Online the same Who, What, When, Where, and what Workstation capability ChangeAuditor is famous for. And the cool thing is now you see what a given user like Bob is doing both in the cloud and on your internal network because ChangeAuditor already monitors

• Active Directory
• Azure AD
• Windows
• SharePoint
• SQL Server
• Network Attached Storage - EMC, NetApp, Dell FluidFS
• Skype for Business/Lync
• VMware

You can’t be secure and compliant without monitoring your environment and that fact doesn’t go away when you move to the cloud. Office 365 captures the activity required by enterprises for compliance but it’s up to you after that. Change Auditor simplifies the audit process by tracking, auditing, reporting and alerting on Microsoft® Exchange Server and Office 365 Exchange Online configuration and permission changes in real time, and solves this issue by combining cloud activity and on-premise activity on the same pane of glass. To ensure Exchange and Office 365 compliance, you can automatically generate intelligent, in-depth reports, protecting you against policy violations and avoiding the risks and errors associated with day-to-day modifications. And, for fast troubleshooting, you always get the original and current values.

To learn more information on Change Auditor please visit: https://www.quest.com/change-auditor

Or for a Trial Download of Change Auditor for Exchange and Exchange Online: https://www.quest.com/products/change-auditor-for-exchange/.