This is one of the three part security auditing post for Exchange servers.

Many implementers, system integrators, users and administrators implement Exchange servers as part of their collaboration infrastructure without knowing what’s going on in Exchange. For security conscious companies/people, its important to know that not only Exchange but any email system put out there have a potential of a security breech, more often than not, they (the threats) may come from inside.

All systems have administrators or superusers which (can) have full control over applications and data inside servers. Now this article focuses on one very important factor when it comes to administering an Exchange server and that is knowing what our administrator does.

Problem with admins being “Gods” on mail server is that they can take ownership of a mailbox on Exchange or associate themselves (or someone other user) to a mailbox thus giving full rights to read other user’s emails/data.

Now, that’s good for some reasons but it can be seriously become dangerous if for example, this administrator reads his/her bosses email or the CEO’s email, for instance.

Facts:

1. By design, one user can only have one mailbox (that’s called the primary user for this mailbox)
   
2. By design since Exchange 2000, administrators have been denied access to other users mailbox out of the box
   
3. By design, when admins do this (associate themselves or other users to another mailbox), no one knows (or nothing is logged) on the Windows box hosting Exchange or Active Directory servers

Questions this article plans to address.

1. Can we track when someone access a mailbox that does not belong to him/her
2. Can we track if the auditing are disabled.

In most articles you find online, they address the tracking of events that are associated with anyone accessing mailboxes that are not theirs. That’s good, but these articles do not address when someone removes the audit setting. Since admins are Gods, they can do this. Doing this will disable tracking of such events (reversing the auditing).

In all cases where you would like to start monitoring your Exchange based on this 360degree Exchange monitoring document, i suggest audit your existing Exchange for possibly any delegation that are “suspicious”. I will not discuss auditing just yet unless its requested.

The steps in general are as below; (i assume you know how to turn auditing events on and off on a Windows box). I suggest use a remote event viewer tracker application like a vbscript (shall show you on a later post) or software like EventSentry to trap events that appear and send emails etc..

1. Enable auditing of directory access at the global level – I suggest turning this on at the domain controller security policy) – This is to audit changes made to the audit settings (explained later)
2. Enable audit of changes made to the domain controller security policy
3. Enable diagnostic logging setting for Logons, under MSExchangeIS, Mailbox
4. Enable auditing the removal of the diagnostic logging

Enable global level auditing

• Launch Active Directory Users and Computers, go to Domain Controllers and edit the Default Domain Controller Security Policy (or use GPMC) or you could use a new one to avoid changing this default policy
  
• Go to Computer Configuration, Windows Settings, Security Settings, Audit Policy
• Turn on Audit Directory Service Access – Success

NOTE: You do not have to turn on failure audits and account management audits, i enabled it for other purposes.

Enable auditing the changes to global level auditing (360deg)

• Launch Active Directory Users and Computers, go to Domain Controllers and click Properties of Default Domain Controller Security Policy (or use GPMC) or the security policy that you’ve used in the step above.
• Click on Auditing, click Add…
• When prompted for a user, this is the part where you need to monitor all users making changes to this policy, so select Everyone or Authenticated Users
• Click on Properties at the next dialog box…, select Write All Properties, click OK several times until you go back to the ADUC’s GPO objects inside that OU. Before quitting that, take note of the GPO’s GUID (Unique Name) for use later when an event is triggered.

Now, at this point, if someone edits or removes this policy or the auditing settings, an event will be triggered to give you enough time to capture the event. An event like below can be then captured.

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 4/15/2008

Time: 5:31:37 AM

User: CHAMPSAdministrator

Computer: FIRSTSERVER

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: groupPolicyContainer

Object Name: CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=champs,DC=int

Handle ID: –

Primary User Name: FIRSTSERVER$

Primary Domain: CHAMPS

Primary Logon ID: (0x0,0x3E7)

Client User Name: Administrator

Client Domain: CHAMPS

Client Logon ID: (0x0,0x1BEB5)

Accesses: Write Property

Properties:

Write Property

Default property set

versionNumber

groupPolicyContainer

Additional Info:

Additional Info2:

Access Mask: 0x20

Notice that the versionNumber is “written” therefore a change to this policy (6AC1786C-016F-11D2-945F-00C04fB984F9 which was the domain controller security policy’s GUID) has been made and this event is logged in the Security event on your domain controller. You have to now manually go check if anyone changed this policy to deem it useless for logging :).

Enable diagnostic logging – triggering alerts for non default mailbox access

Now that you’ve got the auditing at the global level turned on and tracked for changes, we can proceed with the second part. Please note though, diagnostic logging in Exchange is not dependent on the above global logging settings and the events are logged in the Application tab on your Exchange server unlike auditing, where events are stored in the security tab. If this event is triggered, your remote event correlator tool should immediately send an email out. Even if someone tries to clear the event viewer, this event has already been generated so the remove event correlator tool would have picked it up.

Anyway, how to turn on diagnostic logging for the above event..

• Launch Exchange System Manager
• Drill down to your Exchange server’s physical name, right click and click properties
• Go to the diagnostic logging tab, go to MSExchangeIS and select Mailbox
• Select logons and set that to minimum (will do)

Now, any non default user access will trigger event 1016 in your application log of that Exchange server. NOTE: If you use clusters, it will be triggered on all the physical servers.

NOTE: You can omit selecting maximum or Access control. I am doing it for some other purposes.

To eliminate false positives, use your monitoring software and filter out the 1016 events for attempts by exchange full administrators. There are instances where other software and system that could trigger this event, these could be;

1. SYSTEM

2. Antivirus account

3. Backup account

4. Blackberry or equivalent software

5. Folders delegation in Outlook (done by users themselves)

Due to the chances of a high false positive rate, it is recommended to only log exchange full administrators like Administrator alone will do.

Enable auditing the removal of diagnostic logging settings (360deg)

Alright, now that you’ve got auditing of non default mailbox out of the way, we now attempt to audit anyone removing or changing this setting. This auditing will need the policy setup at the local Exchange server level (unlike above, where you could set it at the domain level). Object Access need to be turned on, on each physical Exchange Servers. Please note that if you have a OU, Domain or Domain Controller or Site group policy that conflicts with this setting, your local settings be overwritten. So, i recommend, group all exchange servers together into one OU, then create a group policy in this OU to enable Object Access Auditing – Success turned on.

NOTE: You do not need to audit Failure.

On each physical Exchange servers, browse to the following registry key

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISDiagnostics9000 Private

Right click on 9000 Private and click permissions. Click Advanced and click on the auditing tab. Select Everyone or Authenticated Users when prompted for users then track the following like the diagram below;

This registry key basically refers to the diagnostic logging settings. Enabling auditing on this key will track changes made to the key’s auditing settings itself and values within this key.

check on the Set Value for success is sufficient. I selected both for other purposes.

Okay, now that you’ve set that up, any attempts to modify the diagnostic logging settings and/or the registry settings will be tracked and an event like below shall be triggered.

Event Type: Success Audit

Event Source: Security

Event Category: Object Access

Event ID: 560

Date: 4/17/2008

Time: 1:04:13 AM

User: CHAMPSAdministrator

Computer: SECONDSERVER

Description:

Object Open:

Object Server: Security

Object Type: Key

Object Name: REGISTRYMACHINESYSTEMControlSetServicesMSExchangeISDiagnostics9000 Private

Handle ID: 1340

Operation ID: {0,2242247}

Process ID: 2148

Image File Name: C:WINDOWSsystem32mmc.exe

Primary User Name: Administrator

Primary Domain: CHAMPS

Primary Logon ID: (0x0,0x21F7F)

Client User Name: –

Client Domain: –

Client Logon ID: –

Accesses: Query key value

Set key value

Enumerate sub-keys

Privileges: –

Restricted Sid Count: 0

Access Mask: 0xB

Alright, there you go, happy auditing. Be secure, start by knowing and gaining visibility.