SAML SP Authentication Bypass Vulnerability in nevisAuth

Two months ago, we wrote about SAML Raider, a Burp extension which allows automating SAML attacks based on manipulations of the intercepted security assertion. Using this tool, we were able to identify a severe vulnerability in the service provider (SP) implementation of AdNovum‘s nevisAuth. The following conditions make exploitation possible:

  • SAML POST-Binding is used, i.e. the security assertion is transmitted from the identity provider (IdP) via the user-agent to the SP, therefore exposing the contents of valid assertions to the attacker.
  • The SP accepts signed assertions from one or more identity providers, whereas the signing X.509 certificate is embedded into the assertion.

As described in the previous blog post, SAML Raider features a certificate cloning utility that allows inserting a self-signed, rogue copy of the X.509 certificate into the assertion. The assertion details can then be modified to impersonate other users, grant additional rights, etc. Finally, the rogue certificate is used to sign the modified security assertion.

Due to a flaw in nevisAuth’s signature validation logic, only some attributes of the embedded signing certificate are matched against the legitimate certificate, originating from the IdP. For example the distinguished names (DN) of issuer and subject are checked, but no uniquely identifying attributes such as public key or fingerprint. Then, since both the embedded certificate and the legitimate certificate from the truststore are seen as equivalent, the implementation does not care which one is actually used to validate the assertion’s signature. Unfortunately, the embedded, rogue certificate is used, enabling the attacker to inject arbitrary assertions.

After addressing the issue with AdNovum, they responded very swiftly, providing a security bulletin, a patch and mitigation procedures to their customers a mere day later. After a grace period of a couple of months, the vulnerability was disclosed under the CVE id CVE-2015-5372.

Excuse me, where is the best site of the city? After the DOM, just turn right!

During a SharePoint 2013 penetration test I performed last November, I noticed that a dynamically constructed JavaScript constantly fetched content or redirected me to the requested pages.
Using a variation of the double-slash trick we exploited in the past, I misused this functionality in order to perform a DOM based open redirection attack. Every SharePoint 2013 server is vulnerable, as the weakness is within a component accessible anonymously even when sites are restricted to authenticated users only.

This vulnerability enables an attacker to create a malicious link, which is sent i.e. via e-mail to his target. When the victim clicks on the link, the malformed JavaScript is executed and redirects the victim to a third party site. i.e This attack leaves no audit trail in the server’s log and cannot be blocked by a Web Application Firewall as the payload is executed and stays exclusively in the client’s browser. As a pentester, but especially as a social engineer, this is exactly the technical vulnerability that I’m always looking for in order to perform very effective phishing attacks abusing a trustworthy domain.

Before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their SharePoint servers adequately. While Microsoft estimated that an anonymous and by default enabled DOM based open redirect in SharePoint 2013 was not severe enough for the release of a dedicated security bulletin, they committed themselves to fix it in a product update. Update KB3054867 fixes the issue and is available since June on Microsoft’s Download Center. While the page doesn’t mention any security updates, we strongly encourage you to test and install the patch across all your SharePoint 2013 servers. Microsoft acknowledged my contribution on its page “Security Researcher Acknowledgments for Microsoft Online Services” of August 2015. Further technical details will be released after a grace period of 2 months, to leave enough time to everyone to patch the issue.

Wie stiehlt man KMU-Geheimnisse?

Ein Hintegrundartikel zur SRF Einstein Sendung vom Donnerstag, 3. September 2015 um 21:00 Uhr zum Thema “Cybercrime, wie sicher ist das Know-how der Schweiz”. (Trailer online)

In diesem Artikel zeigen wir Ihnen die Vorgehensweisen von Angreifern auf, die versuchen unerlaubten Zugriff auf fremde Systeme zu erlangen — beispielsweise im Netzwerk eines KMUs. Schematisch sind diese Vorgehensweisen auch im Rahmen der von SRF Einstein dokumentierten Angriffe gegen die SO Appenzeller durchgeführt worden. Der Artikel soll Sie nicht nur für die Angriffsseite sensibilisieren, sondern hält auch sechs einfache Tipps zur Abwehr bereit.


Direkte Angriffe

Direkte Angriffe richten sich unmittelbar gegen die IT-Infrastruktur eines Unternehmens. Typischerweise sucht ein Angreifer dabei nach Schwachstellen auf einem Perimeter System, dass ins Internet exponiert ist.
Direkte Angriffe

  1. Ein Angreifer versucht unerlaubten Zugriff auf interne Systeme zu erlangen.
  2. Der Angreifer, beispielsweise vom Internet her, sucht nach offenen Diensten die er möglicherweise für das Eindringen ausnutzen kann.
  3. Ein ungenügend geschützter Dienst erlaubt dem Angreifer Zugriff auf interne Systeme.

Indirekte Angriffe

Im Gegensatz zu direkten Angriffen, nutzen indirekte Angriffe nicht unmittelbar eine Schwachstelle auf einem ins Internet exponierten System aus. Vielmehr versuchen indirekte Angriffe die Perimeter Sicherheit eines Unternehmens zu umgehen.

Man-in-the-Middle / Phishing Angriffe

Indirekte Angriffe

  1. Ein Angreifer schaltet sich in den Kommunikationsweg zweier Parteien. Dies erlaubt ihm das Mitlesen sensitiver Informationen.
  2. Der Angreifer nutzt die erlangten Informationen um unbemerkt auf interne Systeme zuzugreifen.

Malware / Mobile Devices / W-LAN
Indirekte Angriffe

  1. Ein Angreifer infiziert ein Gerät mit Schadsoftware.
  2. Durch die Schadsoftware erlangt der Angreifer Kontrolle über das infizierte Gerät, welches Zugriff auf andere interne Systeme hat.
  3. Zusätzlich kann ein Angreifer über andere Zugriffspunkte ins interne Netzwerk gelangen, beispielsweise über unsichere Wireless-LAN Access Points.

Covert Channel
Indirekte Angriffe

  1. Ein Angreifer präpariert ein Medium wie USB-Sticks oder CD-ROMs mit Schadsoftware.
  2. Der Angreifer bringt sein Opfer dazu das Medium zu verwenden.
  3. Die Schadsoftware wird automatisiert ausgeführt und verbindet sich unbemerkt zurück zum Angreifer. Der Angreifer erhält die Kontrolle über das infizierte Gerät.

Sechs Tipps zur Abwehr

  1. Regelmässige Aktualisierung von Betriebssystem, Browser und Anwendungssoftware
  2. Schutz durch Verwendung von Firewall und Anti-Viren Software
  3. Verwendung von starken Passwörtern, sowie deren regelmässige Änderung
  4. Löschen von E-Mails mit unbekanntem Absender, Sorgfalt beim Öffnen angehängter Dateien
  5. Vorsicht bei der Verwendung von unbekannten Medien wie USB-Sticks oder CD-ROMs
  6. Regelmässige Erstellung von Backups

Wie kann Compass Security Ihre Firma unterstützen?

Gerne prüfen wir, ob auch Ihre Geheimnisse sicher sind!SRF Einstein, Compass, Appenzeller


Unter folgenden Referenzen finden Sie Tipps und Anregungen zu häufig gestellten Fragen.

IP-Box – Why a 4 digit passcode is still a bad idea

Up to the iPhone 4, 4 digit passcodes could be brute-forced within a short amount of time – maximum 30 minutes, depending on the passcode. With the iPhone 4s, the Boot ROM vulnerability required to upload a custom RAM disk has been closed thus rendering newer phones immune to this attack.

This is where the IP-Box comes in. The IP-Box is small box which can be ordered with various adapters for iPhones up to the iPhone 6 (Plus). The device is powered by the iPhone battery and has a light sensor to detect if the iPhone has been unlocked. The box comes at a price tag of around CHF 250, including the iOS8 adapter.

While there is only sparse documentation available for the box itself – most of it being in Chinese – Detective Cindy Murphy from the Madison Police Department created a manual which serves as an excellent starting point (iP-BOX: Breaking Simple Pass Codes on iOS Devices).

There are several modes of operation for brute-forcing the passcode. Besides the obvious sequential counting from 0000 to 9999 or from 9999 to 0000, the software allows for different pattern-based attacks – i.e. birth dates, patterns or ordered lists – slashing the time needed to crack the code.

Compass Security ordered the Box and tested if it lives up to its expectations. The hardest part of cracking the passcode was actually opening our test devices where the iPhone 5 actually resulted in a broken suction cup.

The first test subject was an iPhone 4 running iOS 7.1.3. For iOS 7 the device luckily does not need to be opened, the IP-Box and its light sensor can be attached and the device is ready to get pwned. The passcode can even be cracked if the phone is in the disabled mode. This state normally would no longer allow manually entering passcodes and requires the iPhone to be connected to iTunes to get it back to a working state.

We set the “Each group of data interval (ms)” to 4500 while leaving the “Stop while the brightness changes” and “Each time interval bit (ms)” at their respective default settings. We found that faster passcode guessing rates lead to unsuccessful passcode tries. With the above settings the box managed to enter 1 passcode per 6 seconds which means that in the worst case, cracking a 4 digit passcode would take about a day on an iOS 7 device.

As our video shows, the IP Box was not overly impressed with the fact that the iPhone 4 was disabled.

The second and third test subjects were an iPhone 4s and an iPhone 5 each running iOS 8.1. This is the last version currently supported by the IP Box. With iOS 8 a special adapter is needed and the device needs to be opened in order to disconnect the iPhone’s battery and connecting the IP-Box directly to the power connector of the device. This setup allows the IP Box to aggressively cut the power supply, preventing the iPhone from increasing the counter on failed passcode attempts.

Since the iPhone restarts after every passcode guessing attempt, in addition to the parameters used on the iOS 7 device, a startup power delay needs to be configured. In our tests we chose a delay of 15 seconds, but the delay could be decreased to 7-8 s, since the IP Box is only powered on, when the iPhone is running again.

The time required per passcode try largely depends on the time the iPhone takes to restart. We determined the startup times of the different devices as follows:

  • iPhone 4s: 48s
  • iPhone 5: 29s
  • iPhone 6: 27s

Brute-forcing a 4 digit passcode on an iOS 8 device will thus take between 3.5 and 6 days depending on the hardware.

The following video shows a successful passcode recovery on an iPhone 4s running iOS 8.1

Unlike iOS 7 where a phone can be disabled and the retrieval of the passcode is still possible, iOS 8 does no longer allow brute forcing the passcode on a disabled device. So make sure not to manually enter codes before unleashing the IP-Box on the iPhone.

Our tests lead to the conclusion that a 6 digit passcode already greatly improves the security of your iPhone. Running iOS 8 on a modern phone it would take about a year in the worst case to retrieve the passcode compared to the 3.5 days of the 4 digit code. If you are using a passcode with numbers and special characters while avoiding words from a dictionary or personal data such as the birth date, name, address or similar, it is currently virtually impossible to retrieve the passcode within a reasonable time frame.

This blog post resulted from internal research which has been conducted by Michael Fisler and Cyrill Bannwart in April 2015.

Hacklab Q2 – NoSQL mischief

At our reoccurring Hacklab days, we at Compass get the chance to hack some stuff of our own choice together for a day. For example playing with GSM in an attempt to send fake SMS or eavesdrop on voice data, comparing Encase capabilities to Unix command line forensic tools or cloning door entry badges in an attempt to gain unauthorized access to buildings or elevators.

During the Hacklab I gathered a few colleagues to create “team NoSQL” and toyed around with some of the example applications. Our project was based on a VM with several instances of “state of the art” web technologies, most of them involving a NoSQL database.

As a first task we performed a NoSQL injection on a self-developed PHP frontend with a MongoDB backend, as discussed in Hacking NodeJS and MongoDB. Additionally we wrote a python script which extracts cleartext password from the MongoDB with a binary search algorithm using the same vulnerability.

We also spent some time analyzing and exploiting race conditions in web applications, as for example described in Race Conditions on Facebook  and Hacking Starbucks for unlimited coffee. Using just the Linux command line, it was possible to generate arbitrary amount of money in a mockup Bitcoin website by sending a large amount of HTTP requests in parallel.

The slides of our presentation and the MongoDB bruteforcer script can be downloaded here:

SAML Burp Extension

SAML [3] is a standard, which is widely used to deploy Single Sign-On and federation identity solutions. SAML is based on the XML technology, using XML Signatures and X.509 certificates.

Manual testing for SAML vulnerabilities is time consuming and error prone. For example, because a SAML message is only valid for a predefined period of time, the penetration tester potentially needs to be able to manipulate SAML messages within a short time. This is a factor which increases the chance of errors.

Therefore students of the University of Applied Sciences Rapperswil, Switzerland [6] developed an extension [2] for the Burp Suite [1] in collaboration with Compass Security. This extension automates most of the steps, which are necessary to test a SAML environment.
The extension, called “SAML Raider”, supports the penetration tester with the following tasks:

  • “Clone” a certificate, i.e. all fields are copied but a random new key-pair is generated.
  • Edit certificates and sign them with the arbitrary generated key-pair or with valid keys
  • Encode and decode SAML messages
  • Display SAML messages with syntax highlighting
  • Edit SAML messages manually
  • (Re-)sign SAML messages and assertions
  • Remove signatures
  • Perform XML Signature Wrapping (XSW) attacks

The extension intercepts the POST message with the SAML Assertion, which is received from the Identity Provider (IdP) and is sent from the browser to the Service Provider (SP). The point of manipulation is illustrated in the following flow graph with the red field “Manipulate”.

Point of manipulation in the data-flow.

Point of manipulation in the data-flow.

The following example case illustrates a possible attack, which could be executed with “SAML Raider”. At Hacking-Lab [7] subscribers and license holders can test this vulnerability riskless in a secured environment.

  1. An attacker can log in as an ordinary user to an Identity Provider and intercepts the SAML assertion before it is sent to the Service Provider.
  2. The attacker now extracts the embedded x509 certificate and clones it.
  3. The attacker changes the user group which is included in the SAML Assertion to administrators.
  4. The attacker signs the assertion with the cloned certificate and embeds the cloned certificate in the assertion.
  5. The attacker sends the manipulated SAML message to the Service Provider.
  6. The Service Provider wrongly acknowledges the embedded cloned certificate as valid and validates the signature with the wrong certificate.
  7. The attacker is now logged in as an administrator.

SAML Raider supports the penetration tester in testing SAML Environments with Burp.

There is another Burp extension [4] of the Ruhr University Bochum, which displays Single Sign-On messages and allows to manually edit SAML messages.
At Black Hat 2015 a tool called “samlyze” is announced. Its goal is to pentest SAML service providers fast and easy [5]. We are looking forward and really hope samlyze supplements this extension with one or the other feature.



Netzwerktraffic und APT Analyse

Compass Security wird vermehrt von Kunden bzgl. Verdacht auf Advanced Persistent Threat (APT) kontaktiert. Unter die Bezeichnung “APT” fallen komplexe, zielgerichtete und äusserst effektive Angriffe auf kritische und zuweilen gar unternehmenswichtige Computersysteme bzw. deren gespeicherte Informationen.
Die Analyse von potentiell infiltrierten Netzen und Systemen gestaltet sich jedoch als enorm aufwändig, da Unmengen von Datensätzen und Logs ausgewertet werden müssen. Compass hat deshalb immer wieder verschiedene Aspekte im Bereich APT, Forensik und Incident Response beleuchtet. Einerseits betreiben wir Research mit internen “Hack Labs” und “Research Weeks”, wo unsere Spezialisten sich mit den neusten Erkenntnissen der Scene auseinandersetzen bzw. diese weiter treiben und andererseits bearbeitet Compass in Zusammenarbeit mit den Security Fachabteilungen einer Vielzahl von Hochschulen, entsprechende Themen.

Eine entsprechend gewürdigte Maturaarbeit aus dem letzten Sommer möchten wir der Öffentlichkeit nicht länger vorenthalten und publizieren darum die Resultate im Rahmen dieses Posts. Im Mittelpunkt des Whitepapers steht die Analyse von APT mittels Splunk, einer spezialisierten Software zur Analyse von grossen Mengen maschinengenerierter Logdaten. Es werden darin auch alternative Wege zur Auswertung eruiert und ein Standardvorgehen für APT Fälle vorgeschlagen. Das Paper greift auch das bei Compass übliche Vorgehen bei forensischen Analysen auf und gibt dem technischen Leser in gewohnter Compass manier, viele technische Details mit auf den Weg. Natürlich auch einige Ideen, wie man das Logging von bestimmten Diensten optimieren könnte.

Möchten Sie gerne mehr zum Thema wissen? Möchten Sie auch erfahren, was dies in der Praxis bedeutet? Dann können wir Ihnen unser nächstes “Hands-on Seminar” mit dem Titel: Network Analysis & Advanced Persistent Threats vom 25. und 26. August 2015 in Bern empfehlen.

In der Zwischenzeit wünschen wir Ihnen viel Spass beim Schmökern. Behalten Sie einen kühlen Kopf compass_security_schweiz_whitepaper_apt_network_analysis_w_splunk_v1.1.pdf.

Compass Security Crew,
Cyrill Brunschwiler

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

XSLT Security and Server Side Request Forgery

Nowadays, a growing list of XSLT processors exist with the purpose of transforming XML documents to other formats such as PDF, HTML or SVG. To this end such processors typically offer a powerful set of functionalities – which, from a security point of view, can potentially pose severe risks.

Within this post, we highlight some of the threats one gets exposed when operating a misconfigured XSLT processor. The goal here is to increase people’s awareness when configuring modern XSLT processors.

Tested XSLT Processors

The subsequent table lists the XSLT processors investigated in our tests.

XSLT Processor Manufacturer License Windows Version Linux Version
libxslt Gnome Project MIT License 1.1.26 1.1.28
Saxon-HE Saxonica Limited Mozilla Public License V1.0
Saxon-EE Saxonica Limited Mozilla Public License V1.0
Xalan-J Apache Software Foundation Apache License V2.0 2.7.1 2.7.2
Xalan-C Apache Software Foundation Apache License V2.0 1.11 1.11
MSXML 4.0 Microsoft Proprietary 4.0 SP3
MSXML 6.0 Microsoft Proprietary SP2 (File Version 6.20.1099)
.NET System.xml Microsoft Proprietary 4.0.30319


We divided the security threats exposed by the XSLT processors into six categories:

  1. Information Disclosure
  2. Read Files
  3. Write Files
  4. Database Access
  5. Include External Stylesheet
  6. Code Execution

The results are summarized in following figure:

XSLT Vulnerabilities

Vulnerability Overview of Tested XSLT Processors

The above results clearly show that the great functionality of modern XSLT processors comes with a tremendous downside: If used in their default configuration, or otherwise not properly configured, XSLT processors can endanger confidentiality and integrity on XSLT servers or allow the execution of arbitrary code. Even worse, the vulnerable XSLT server might be abused to forge attacks against remote third parties, such as for instance performing anonymous port scans (see example below).

Example: Server Side Port Scanning Forgery

Here, we give a short example of how to misuse the document() function (used to access external XML documents) on a remote XSLT server to forge port scanning against an external third party. In the example, the investigated third party is located on host ““, and tested against port 22 (SSH).

The attacker “Mallory“, trying to learn whether or not port 22 on “” is open or closed, submits the following XSL file to a server “Alice” running a vulnerable XSLT processor.

XSLT Portscan

Port Scanning XSL File

Next, “Alice” processes the XSL file submitted by “Mallory” and as consequence tries to access the external XML resource located on ““. Dependent on whether or not port 22 is open on ““, a different response is sent back to “Alice“, who finally forwards the result to “Mallory“. Since the result “Mallory” receives is different for open/closed ports, she can learn the port state on ““. Note that in this way “Mallory” has performed the port scan anonymously, since the only party speaking to “” was “Alice“.

For the sample processor libxslt in our test set, the response received by “Mallory” might look like shown below:

Port State Response
Port Open parser error : Document is empty
Port Close (Timeout) Operation in progress I/O warning
Invalid Host No such file or directory I/O warning

In summary, “Mallory” was able to forge a port scanning request from “Alice” against ““.


This blog post is based on a Seminar paper (XSLT Processing Security and Server Side Request Forgeries) written by Emanuel Duss and Roland Bischofberger, in collaboration with Compass Security Schweiz AG:

E. Duss and R. Bischofberger. “XSLT Processing Security and Server Side Request Forgeries: Analyse, Demonstration und Gegenmassnahmen“. Seminar Paper, Hochschule für Technik Rapperswil, Autumn 2014

Further Readings

Exchange 2013 – Spot the Security Features

Microsoft Exchange 2013, the newest product in the Exchange series, is more and more enrolled in enterprise environments. With the new and enhanced features, for example the integration of SharePoint or Lync, the new Exchange is a well-designed piece of software which in parallel addresses different security concerns. Like Lync 2013 and the whole Microsoft Office Suite, Exchange is available as on premise installation or as Office365 solution, even a combination of both worlds is possible. There is for example the Exchange Online Protection solution which could be combined with a on premise installation.

Exchange 2013 Workloads

Exchange 2013 Workloads

Compass Security would like to share their recent experience to enlighten some of the risks and security issues within an Exchange environment. This post is not about fuzzing or testing the product itself, it’s more about the secure configuration of the Exchange environment. The other heavy-weight product from Microsoft, the Lync 2013, was also a recent blog topic where I wrote about the security issues, the privacy configuration and the missing security features.

At least the following built-in security features are available:

  • Encryption: Transport security is enabled by default and can’t be disabled. The communication is always RPC over HTTPs (Outlook Anywhere)
  • Fine-grained role-based-access-control (RBAC) system. A similar RBAC system is also used in a Lync eco-system
  • Passive databases and lagged database copies for high availability and disaster recovery
  • Archiving and Journaling possibilities for backup and compliance requirements
  • An optional anti-spam and anti-malware detection framework built into Exchange
  • Data Loss Prevention (DLP) engine to filter sensitive information, based on pattern matching

Besides these security features, following security issues must be properly addressed:

  1. RBAC: When the RBAC system is used too loosely, too many people have too many privileges on the sensitive enterprise e-mail content. Therefore, like in Lync, the RBAC roles must be implemented with the least-privilege principle. Custom roles should be implemented for enterprise-specific requirements:

Read all roles:

Get-ManagementRoleAssignment | select roleassigneename –Unique

Read all members of all the role groups:

foreach ($rg in Get-RoleGroup) { `
  Get-RoleGroupMember –Identity $rg.Name `
    | select name,@{n="RoleGroup";e={$rg.Name}} | `
      ft -autosize }

Read members of a specific role group:

Get-RoleGroupMember "My AD Group"

List all allowed cmdlets for a specific group:

Get-ManagementRoleEntry "RoleName\*"

Or list all groups in which a specific cmdlet is allowed:

Get-ManagementRoleEntry "*\cmdlet-name"
  1. E-mail encryption: However, transport security is used within the whole Exchange environment. End-to-end encryption must be implemented with e.g. RMS (Right-Management-System) or S/MIME. The email content is not encrypted by default. Furthermore, when using Exchange Cache Mode, on every enterprise workstation a “<filename>.ost” file is stored unencrypted on the disk. This file contains the whole email and calendar and other sensitive information in a mailbox. With tools like “Kernel to PST” the .ost file could be opened and accessed as with Outlook.

Cached Exchange Mode Settings under Account Settings in Outlook:

Exchange Cached Mode

Tool to read the content of .ost files is for example “Kernel for OST to PST“.

  1. Auditing: Tracking mailbox access and configuration changes is essential for forensic analysis and security investigations. There exist the admin (RBAC) and mailbox auditing. The latter can be enabled for the owner, delegates or admins. Furthermore, the auditing can be set for different actions, e.g. move, copy, open delete.

Admin audit:

Get-AdminAuditLogConfig | fl AdminAuditLogEnabled, `
  AdminAuditLogCmdlets, AdminAuditLogParameters, LogLevel

Mailbox audit:

Get-Mailbox | select userprincipalname,auditenabled | ft –AutoSize

List all actions which are logged for a specific mailbox:

get-mailbox <username> | % { `
  "Displayname: {0}" -f $_.displayname; "AuditEnabled: {0}" `
  -f $_.auditenabled; "AuditAdmin: {0}" -f $_.auditadmin; `
  "AuditDelegate: {0}" -f $_.auditdelegate; "AuditOwner: {0}" `
  -f $_.auditowner }

Identify mailboxes which are excluded from the auditing:

Get-MailboxAuditBypassAssociation -ResultSize unlimited | ? `
  { $_.AuditBypassEnabled -match "True" }
  1. Mailbox permissions: It’s well known, that the private flag is only respected within the Exchange Eco-System (e.g. Outlook, OWA). When directly access Exchange with Exchange Web Services (EWS), private flagged items (e.g. private appointments) can be read. Therefore, the permissions for a mailbox should be set to “limited details” and for the inbox the allowed delegates must be set very rare. “Reviewer” permissions would allow access to the private appointments through EWS.
Get-MailboxFolderPermission <username>:\Calendar

Example Output:

FolderName           User                 AccessRights
----------           ----                 ------------
Calendar             All                  {LimitedDetails}

The same is used for the inbox:

Get-MailboxFolderPermission <username>:\Inbox
  1. Connector Security: Connectors are the interfaces from and to the Exchange servers. Outlook clients, IMAP/POP clients, any other SMTP server and also third-party applications like scanners or FAX devices.

List given details for all connectors

Get-ReceiveConnector | fl Name, AuthMechanism, PermissionGroups

To verify, that a connector is not used as anonymous open relay, read the extended AD permissions for a specific connector:

Get-ReceiveConnector | % `
  { $; Get-ADPermission -identity $ -user `
  "NT AUTHORITY\ANONYMOUS LOGON" | ft extendedrights `
  -HideTableHeaders –AutoSize }

“Ms-Exch-SMTP-Accept-Any-Recipient” should not be available for any anonymous connector.

  1. OWA Offline Storage: In respect to information leakage, disabling offline storage would prevent the application from storing the following information on the client: up to 150 emails or content of last 3 days, all contacts, calendar entries for the next year but not attachments.
Get-OwaMailboxPolicy | fl AllowOfflineOn
  1. Management Interface: The new Exchange Administrative Center (EAC) is the management web application (/eac) for the Exchange. The same EAC is used by normal users to change their password or change other account settings. This leaves us in an unpleased situation where the management interface can’t be hided from the client network because both the administration and the user settings are handled with the same application.

As with Lync, the provided Exchange security mechanisms are good and give an enterprise a solid baseline for a secure email, calendar and contact manager solution. However, there are different locations which must be considered in the design and configuration phase: auditing must be enabled, custom RBAC roles should be used to limit access to sensitive mailbox content and connector security settings should be hardened to only allow authenticated users.

Thanks to Marek Madrzycki for the review and comments for this post.