If you would like to read the other parts in this article series please go to:
Auditing Mailbox Access
In every organization, there are always mailboxes with sensitive information. These might be the mailboxes of the CEO, directors, users from the HR or Payroll departments, or simply mailboxes for which administrators have to perform discovery actions to demonstrate compliance with regulatory or legal requirements. Although normally administrators are not concerned with the content of user’s mailboxes, there might be someone less honest that attempts to access someone’s mailbox in order to obtain information of value for their own benefit.
Versions of Exchange prior to Exchange 2010 did not provide a full range of compliance capabilities. Managed Folders or Journaling simply were not enough to perform basic audits or to be fully compliant with legislation such as the Sarbanes-Oxley Act in the United States. Exchange 2010 Service Pack 1 introduced a new feature known as Auditing Mailbox Access, which allows administrators to record operations on a mailbox such as the deletion or copy of e-mails. After enabling audit for one or more mailboxes and configuring the level of detail that we want to capture, audit entries are captured in the Audit subfolder of the Recoverable Items folder and can be interrogated using the Exchange Management Shell or the GUI (being that the Exchange Control Panel or the Exchange Admin Center)
|
|
Scenario 3 – Dinner. Let us assume that, in this case, a hacker (which could simply be a co-worker) got SendAs permissions to the Offender’s mailbox and sent an e-mail to Victim pretending to be Offender. |
As the hacker managed to gain SendAs permissions to Offender’s mailbox, all the hacker needs to do is change the From field to Offender’s e-mail address and the e-mail will be received by Victim as being sent by Offender.
Figure 3.1: Fake E-mail using SendAs
When Victim receives the e-mail, all she sees in the From field is Offender’s display name without any indication that it was actually the hacker who sent the e-mail (this is the whole purpose of SendAs functionality):
Figure 3.2: Fake E-mail Received by Victim
Even when looking at the message headers, there is no indication whatsoever that it was actually the hacker who sent the e-mail:
Received: from AIO.letsexchange.com ([::1]) by AIO.letsexchange.com ([::1]) with mapi id 14.03.0123.003; Sat, 27 Apr 2013 14:32:40 +0100
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: Offender <[email protected]>
To: Victim <[email protected]>
Subject: Dinner Tonight
Thread-Topic: Dinner Tonight
Thread-Index: Ac5DS5ag4ICxxtGwQxKfC4kS+LFMoQ==
Date: Sat, 27 Apr 2013 14:32:38 +0100
Message-ID: <[email protected]>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organisation-SCL: -1
X-MS-TNEF-Correlator: <[email protected]>
MIME-Version: 1.0
X-MS-Exchange-Organisation-AuthSource: AIO.letsexchange.com
X-MS-Exchange-Organisation-AuthAs: Internal
X-MS-Exchange-Organisation-AuthMechanism: 04
X-Originating-IP: [192.168.1.230]
|
|
Note that there is a reference to the IP address of the sender’s machine. This could be used to show that the e-mail was sent from hacker’s machine or that it was his account logged in at “27 Apr 2013 14:32:40” on the workstation with the IP address of 192.168.1.230. |
To start off with, we need to confirm that auditing is enabled for the Offender’s mailbox and if the SendAs action is being audited. Traditionally, an investigator might go through the entire log as it might not be clear at first what happened and what he/she is looking for.
As can be seen from the screenshot below, SendAs actions are being audited for Delegates, which is what we are interested in:
Figure 3.3: Mailbox Audit Settings
Now that we determined that logging is enabled, let us use the Search-MailboxAuditLog cmdlet and check if we can find out if any e-mails were sent from the Offender’s mailbox using SendAs permissions, meaning if someone else sent an e-mail pretending to be Offender. As these type of logs usually contain a lot of information, we filter the information we do not want by only returning Operations of the type SendAs:
Figure 3.4: Filtering Search Results
As it can be seen from the screenshot above, an e-mail with the subject Dinner Tonight was sent from Offender’s mailbox. However, it was actually the user Hacker who sent it using SendAs permissions. The logs also tell us that the e-mail client used to send the e-mail was Outlook (MSExchangeRPC).
Scenarios of users abusing the SendAs functionality to send e-mails pretending to be other users are typically easy to identify and investigate. This is so for two reasons: SendAs permissions have to be assigned by administrators; and information regarding who actually sent the e-mail is also logged in the message tracking logs.
For example, if we look at the tracking logs for this same e-mail, we can easily conclude it was actually Hacker who sent the e-mail pretending to be Offender. When the e-mail first reaches Exchange (EventId RECEIVE) it comes from Hacker as it was him who sent it from his own mailbox. However, because it was sent using SendAs permissions, Exchange modifies the sender with the e-mail address of Offender and delivers it to the recipient’s mailbox. By comparing the MessageId field, we can prove this is the same e-mail throughout.
Figure 3.5: Investigating SendAs using Message Tracking Logs
Auditing Mailbox Access becomes more useful when there is the need to prove that someone logged into another user’s mailbox and/or did something in that mailbox without permission, such as deleting an e-mail. There might be cases where, for example, a Personal Assistant deletes an e-mail from the boss’s mailbox on purpose so the boss does not read it. In scenarios such as this one, as long as actions of MoveToDeletedItems, SoftDelete and HardDelete are being audited, it becomes easy to prove what happened.
In the following example, we can see that the user Hacker (LogonUserDisplayName), logged in to Victim’s mailbox (MailboxOwnerUPN), and deleted (Operation: MoveToDeletedItems) an e-mail with the subject “Meeting” (ItemSubject) from the Inbox folder (FolderPathName) using Outlook Web App (ClientInfoString):
Figure 3.6: Investigating Deletions using Mailbox Audit Logs
The main issues with mailbox auditing is that it is disabled by default and enabling it for all mailboxes will obviously take up more space on each mailbox. However, a good auditing policy where only key actions such as send permissions or deletions are audited, will not cause any noticeable impact in terms of storage and performance, and can very well easily resolve many investigations.
Bypass an Account from Auditing
In some situations, Exchange environments have special accounts such as the Blackberry Enterprise Server [BES] account that administrators want to exclude from auditing. This account is used by BES to read e-mails from users’ mailboxes and sending them to their Blackberry mobile device.
The problem is that when Delegate auditing is enabled for a mailbox and the environment has a BES server, this account alone will fill the audit event folder with events administrators are not interested in. For these cases, this type of account can be configured to bypass mailbox audit logging, so that actions performed by them on any mailbox are not logged. However, it is not possible to specify the BES account, for example, to bypass audit logging for only a specific mailbox only – it is an all or nothing.
To do this, an administrator uses the EMS to configure bypassing with the following cmdlet:
Set-MailboxAuditBypassAssociation <account_name> -AuditBypassEnabled $True
This might become a problem because it means that administrators can bypass their account from auditing and do things they are not authorized to do.
Auditing users that have the capability of assigning FullAccess permissions for any mailbox to themselves, setting the AuditBypassEnabled option or enabling/disabling audit is much harder. Nothing prevents an administrator with this level of permissions from assigning himself FullAccess to the CEO’s mailbox, bypass his account from auditing and do what he wants on the mailbox. For these scenarios, the only option is to use Auditing Mailbox Access together with Administrator Audit Logging so that, for example, if an Administrator uses the Set-MailboxAuditBypassAssociation cmdlet, this is automatically logged. Unfortunately it is possible for administrators to clear this log by setting the log age limit to zero… However, at least this action of clearing the log file gets logged, giving investigators an indication that something dubious might have happened.
Administrator Audit Logging
Administrator Audit Logging allows the logging of when a user or administrator makes a change in the Exchange organization. By keeping a log of the changes, it becomes possible to trace changes to the person who made them, supplement change logs with detailed records of the change as it was implemented, comply with regulatory requirements and requests for discovery, troubleshoot, etc.
|
|
Unlike Mailbox Audit Logging, Administrator Audit Logging is enabled by default. |
This feature audits cmdlets that are run directly in the Exchange Management Shell as well as operations performed using the Exchange Management Console and Exchange Control Panel as these management tools run cmdlets in the background. As such, regardless of where an action is performed, it is audited as long as it is on the cmdlet auditing list and one or more of its parameters are also on the parameter auditing list.
By default, administrator audit logging is enabled, logging every single cmdlet run and keeping the logs for 90 days. This can be verified by checking the AdminAuditLogEnabled, AdminAuditLogCmdlets, AdminAuditLogParameters and AdminAuditLogAgeLimit parameters when running the following cmdlet:
Figure 3.7: Admin Audit Log Configuration
Changing any of these settings is simply a matter of using the Set-AdminAuditLogConfig cmdlet. It is also possible to exclude certain cmdlets from being audited by using the AdminAuditLogExcludedCmdlets parameter. However, note that changes to the administrator audit log configuration are always logged, regardless of whether the Set-AdministratorAuditLog cmdlet is included in the list of cmdlets being audited and whether audit logging is enabled or disabled.
When a cmdlet is run, Exchange inspects it and if it matches any of the cmdlets included in the AdminAuditLogConfigCmdlets parameter, Exchange then checks the parameters specified in the AdminAuditLogConfigParameters parameter. If at least one or more parameters from the parameters list are matched, an audit log entry is created. Audit logs are stored in a hidden, dedicated arbitration mailbox that can only be searched using the ECP or the Search-AdminAuditLog and New-AdminAuditLogSearch cmdlets. This arbitration mailbox cannot be opened using Outlook or OWA.
The auditing page in the ECP has several reports that provide information about various types of compliance and administrative configuration changes. The following two reports provide information about configuration changes in the organization:
- Administrator role group report searches for changes to management role groups specified within a timeframe. The results include the role groups that have been changed, who changed them and when, and what changes were made;
- Administrator audit log exports the audit log entries recorded within a specified timeframe to a XML file and sends via e-mail to the recipient specified.
Figure 3.8: Running Compliance Reports from the EAC in Exchange 2010
Figure 3.9: Running Compliance Reports from the EAC in Exchange 2013
The New-AdminAuditLogSearch cmdlet searches the audit log just like the Search-AdminAuditLog cmdlet but instead of displaying the results in the Shell, it sends them to a recipient specified via an e-mail message. The results are included as an XML attachment to the e-mail message. The same search criteria can be used with the New-AdminAuditLogSearch cmdlet that is used with the Search-AdminAuditLog cmdlet.
When running the Search-AdminAuditLog cmdlet, all the audit log entries that match the search criteria specified are returned and displayed in the Shell. For example, by running the search below, we can easily tell that the user Administrator (Caller) gave himself permissions (CmdletName: Add-MailboxPermission) to the Victim’s mailbox (ObjectModified):
Figure 3.10: Tracking Mailbox Permission Assignment
We can also tell that 10 minutes later, the same user modified the AuditBypassEnabled property of the Set-MailboxAuditBypassAssociation cmdlet so that actions performed by his account on other users’ mailboxes were not audited:
Figure 3.11: Tracking Audit Bypass Changes
As we can see, it is not easy to perform an action in Exchange without leaving a trace behind of what was done and by whom. An attempt to try to hide what was done would be to clear the administrator audit log by setting the AdminAuditLogAgeLimit property to zero, do whatever unauthorised actions desired, and then setting it back to what it was set before:
Figure 3.12: Clearing Admin Audit Log
Although this would delete every trace of what was done before the log got deleted (assuming a backup was not run after the unauthorised actions were performed but before the log got deleted), there would still be a log entry saying that the AdminAuditLogAgeLimit property was changed (ModifiedProperties):
Figure 3.13: Tracking Who Cleared Admin Audit Log
Although we cannot find out what was done, we know that the user Administrator cleared the administrator audit log which cannot be a good sign if no one knew about it. This assuming that mailbox audit logs and other logs were also cleared by this rogue administrator.
Conclusion
In this part of our article series, we finished with extracting data using Exchange features, namely Mailbox and Administrator Auditing. In the next and final two parts, we will look at extracting data directly from Outlook or from a PST file.
If you would like to read the other parts in this article series please go to:
