Accessing Internal Fileshares through Exchange ActiveSync

Exchange ActiveSync (EAS) is a protocol for synchronising emails, policies and other items between a messaging server and mobile devices.

It was found that EAS could be used to remotely access Windows file shares and internal SharePoint sites needing only Exchange user mailbox credentials. This was confirmed against Exchange 2013 and 2016 with near-default configurations, despite file share access being removed from Outlook Web App in Exchange 2010.

MWR have released a library (PEAS) with an accompanying tool based on this research to assist in accessing file shares and executing other EAS commands.

MWR’s Cyber Defence consultants help clients design secure enterprise architectures. As a research-led consultancy, we study systems that present potential weak points in an organisation's architecture.

Microsoft Exchange is a widely used enterprise email server and, by nature of its function, is accessible from the internet. External attackers routinely target Exchange in their attempts to access sensitive information assets - stored in emails - and a target’s internal network.

Exchange has a broad ‘attack surface’ owing to the number of external interfaces. Email is a prime one and a number of vulnerabilities have been reported in internal email parsers that would give code execution in Exchange itself. A notably amusing example can be found here. It has also recently been found that the ability to set complex message handling rules can be abused to gain code execution on workstations.

Outlook Web Access (OWA) and a number of issues have been reported in this service over the years. 

Finally the Exchange ActiveSync (EAS) connector allows devices such as mobile phones and thick clients to connect to exchange. This protocol is relatively complex and is how (for example) rules are pushed to corporately joined mobile devices.

The primary goal of the research was to identify vulnerable functionality in EAS, in particular by confirming the viability of file share access after it was discovered in the documentation. This was split into the following objectives and sub-tasks:

• Build a domain controller and set up Microsoft Exchange Server.
• Test existing Python EAS projects and modify them to extract all emails in a mailbox.
• Implement file share access or other functionality of use in security assessments.

Initially, previous research was reviewed. In the paper 'Exchanging Demands: Weaknesses in SSL Implementations for Mobile Platforms' (Hanny, et al. 2013), the researchers found they could exploit MitM to remotely wipe devices. They made several suggestions, based around MitM, that were noted as potential areas of investigation should attempts at file share access be unsuccessful. The research was also useful in indicating that it was possible to disable SSL in order to assist sniffing EAS traffic.

The EAS documentation was reviewed to provide an understanding of the protocol. EAS was found to use XML, encoded as WAP Binary XML (WBXML), over HTTPS. This is what an example request looks like as XML:

Whereas WBXML looks like the following when displayed by a hex editor:

This data is sent via an HTTP POST request to the EAS web endpoint, e.g. /Microsoft-Server-ActiveSync for Exchange, along with the command, user and device info as GET parameters. Headers are used for authorisation, session management and specifying the EAS version.

The server responds to the command similarly with WBXML in the HTTP response body.

A virtual machine was configured running Windows 2012 R2 Standard (64-bit). Initially not enough RAM was available to run both the OS and Exchange. It would be advisable to use at least 8GB if repeating the process; 10GB was allocated the second time and 7.8GB was reported as being in use.

Active directory was enabled on the server, a new forest was created and the host was promoted to a domain controller.

Microsoft Exchange Server 2013 was installed with two roles enabled. This was the only way the install could be said to differ from a default installation. The "Mailbox role" was enabled because it must be enabled to host user mailboxes, a primary function of Exchange. The "Client Access role" was enabled because it's necessary for ActiveSync clients as well as Outlook Web Access, POP3, IMAP4 protocols and Web services, such as Autodiscover and free-busy.

After the install, Outlook Web App (OWA) was accessible at https://server-name/owa/ and the Exchange Admin Center (EAC) was at https://server-name/ecp/. These were accessible over the network.

Initially there was an Administrator mailbox only. The EAC was used to create a new mailbox. An email was successfully sent between the new mailbox and the Administrator mailbox using OWA.

More details about the server setup can be found in the git repository for this research project.

To gain a practical understanding of the protocol and to test the server, HTTP requests with WBXML were constructed with the assistance of a guide and the protocol documentation. These requests were sent to the Exchange server using Python.

Attempting to send a Sync command as the Administrator account returned the status code 126, which was documented as "UserDisabledForSync", meaning ActiveSync was disabled. Attempting the same command with the new mailbox account was successful. This suggested the Administrator account had some restrictions by default.

The server responded to EAS requests, over the network, without need for additional configuration.

An attempt at identifying an exhaustive set of Python projects was made by searching Github, Stackoverflow and Google. Two other projects were included for their potential use as a reference for writing new software if the existing Python libraries were found to be unsuitable.

Only two Python projects could talk directly to a server using EAS: pyActiveSync and py-eas-client. A comparison was made of their functionality to assess which was a more complete implementation of the protocol and which would be more useful for the research. A wrapper for both libraries was written in the process to create a consistent interface and to form the basis of the tool to be produced as output of the research.

pyActiveSync partially supported at least EAS 12.1, implementing seventeen of the twenty-three commands offered by the server. It came with some sample code but lacked documentation.

pyActiveSync required the creation of a Python source file called proto_creds.py, containing the EAS server address, a username and password. It persistently stored values in a local database to allow it to resume some operations using previous values.

To make use of the library with the test environment, SSL verification had to be disabled. The example code tried to request "suggested contacts", which didn't exist so also had to be disabled. After this the library was able to request email from the test server successfully.

py-eas-client came as a package with a proper setup.py script and installed successfully. It only supported four of the twenty-three commands offered by the server however. It came with a sample script but lacked documentation.

py-eas-client used Twisted which meant its functionality was tied to the Twisted library's way of doing things asynchronously, which could've caused difficulties extending it. It also produced WBXML from Python dictionaries, making it restrictive, which caused an issue for another user, leading them to use libwbxml instead.

To make use of the library with the test environment, again SSL verification had to be disabled. This proved more difficult because an understanding of Twisted was required. The example code tried to request a message with a hard-coded index that didn't exist, so this was modified to request all returned message indexes. After this the library was able to request email from the test server successfully.

pyActiveSync supported significantly more commands than py-eas-client, was updated more recently and didn't require a transition to the Twisted paradigm. This made pyActiveSync the preferable choice for use in the research.

Although the primary goal was to gain file share access, a methodical approach was taken to come up with potential attacks to investigate. Initial research suggested file share access was not possible after Exchange 2010 and there was always the possibility of finding another attack that could take priority.

The EAS documentation was parsed to extract a listing of supported functionality from the example sections of each document. For each example of functionality, possible attacks were considered using STRIDE as a prompt to ensure different angles of attack were covered consistently.

The output of this was a list of supported functionality and a list of potential attacks. The potential attacks were then sorted by priority based on the goals of the research, the probability of success based on the current understanding and the time required to verify. The full listings are available on the project wiki.

The first attack prioritised for investigation was whether Windows file shares could be accessed using EAS commands.

Two Windows file shares were created on the server. One was set to require administrator permissions and the other allowed access to the everyone group. Files were placed in both of the shared directories. The goal was to list the file share contents and download files from the shares using EAS.

The EAS documentation indicated that file share contents could be listed with the Search command and files read with the ItemOperations command. The store type had to be set to DocumentLibrary for file share access.

As Search was not one of the commands supported by pyActiveSync, the library was extended to implement it.

A standard user mailbox account was used to authenticate to EAS for the first test. Supplying a UNC path to the permissive share, e.g. \\test-server\share, returned an error code 14 in the response meaning "Credentials required". Further examination of the documentation located a UserName and Password element in one of the sub elements of the Search command. Sending the same username and password used to authenticate granted access to the share and successfully returned a directory listing.

Changing the request to target the share restricted to administrators, resulted in a status code 5: "Access denied". Trying again using the administrator credentials to both authenticate to the EAS server and in the search options, resulted in the error seen earlier: "UserDisabledForSync". However, authenticating to EAS with the standard user account and supplying the administrator credentials in the Search request successfully returned a directory listing for the share.

Next, accessing files on the shares was attempted with the ItemOperations command and the Fetch operation. The permissions behaviour was found to be the same as with Search and the contents of each file specified was successfully returned as base64.

A new Windows 7 virtual machine was added to the domain to check if shares on different machines could be accessed, not just those on the Exchange server or domain controller. A share was created on this machine. The share could be accessed using the computer name in the UNC path with the same method as used previously.

Additionally it was found that all shares could be listed by providing the UNC path to a given host without a share name e.g. \\test-pc. However using the IP addresses or FQDN of the machines in place of the hostname was not successful.

To further test whether permissions were being controlled effectively, detailed file share auditing was enabled. Observing events in the event log with ID 5145 showed that the account being used to access the shares was the one supplied in the Search options and not another with different privileges.

The ability to download files was reported to Microsoft with MWR's belief that this was legacy code from when OWA supported the functionality. Microsoft informed MWR that the ability to do this is by design and directed MWR to guidance on overriding the default exchange setting that allows downloading of files. 

Organisations are recommended to disable fileshare access and sharepoint access through Exchange ActiveSync. Guidance can be found here at and requires setting the following parameters to false:

• UNCAccessEnabled
• WSSAccessEnabled

 MWR also strongly recommend that organisations use client certificates on endpoints such as OWA and EAS.

Investigation was done as to the forensic artifacts done when an attacker exploits this functionality.

A new user mailbox was created with the name filesharetest for use in identifying means of detection.

To list file shares the following PEAS command was used:

python -m peas -u filesharetest -p ChangeMe123 --list-unc='\\fictitious-dc' 10.207.7.100

and to download a file from a file share:

python -m peas -u filesharetest -p ChangeMe123 --dl-unc='\\fictitious-dc\hr\passwords.txt' 10.207.7.100

The EAC showed the devices for each user that had accessed Exchange using EAS. These could be viewed under recipients > mailboxes > *specific mailbox* > View details.

The PEAS tool resulted in an entry with the family and model listed as "Python". This indicated that if the details are not forged to that of a valid mobile device, the entry may stand out.

Manual review through the web interface is likely to be time consuming in real investigations. The Exchange cmdlet Get-ActiveSyncDevice was used to list all known devices, which could then be parsed, processed and reviewed to identify anomalies.

As of Exchange 2013, logging was enabled for many Exchange components by default (ref).

Logs were located in <Install Drive>\Microsoft\Exchange Server\V15\Logging.

The log file format was:

Log path: ./HttpProxy/Eas/HttpProxy_2016081619-1.LOG

The items of immediate interest in the request were the UserAgent of 'Python', the DeviceId and DeviceType, however these could easily be forged to have realistic values and would need to be checked against a list of known good devices, which even then would not be a guarantee. The Cmd=Search string indicated that a search had been performed but it does not distinguish between a file share search and other types of search.

Log path: ./HttpProxy/Eas/HttpProxy_2016081619-1.LOG

The Cmd=ItemOperations string in this request indicated that something was being fetched from the server but it does not confirm a file from a file share was requested.

The IIS logs directory was located at C:\inetpub\logs\LogFiles\. The values were similar to the Exchange logs.

Log path: ./W3SVC1/u_ex160816.log

Log path: ./W3SVC2/u_ex160816.log

Log path: ./W3SVC1/u_ex160816.log

Log path: ./W3SVC2/u_ex160816.log

With detailed file share logging enabled, event logs were created with event ID 5145 that showed the target path of files accessed. It was not determined whether these were distinguishable from normal share access alone but they could be correlated with the time stamps from the IIS or Exchange logs. When testing, the time stamps between the logs were identical after taking into account timezone offsets.

The following entry was repeated for each share on ficticious-dc with the corresponding share names.

• Parse the output of Exchange cmdlet Get-ActiveSyncDevice and review for anomalies.
• Parse IIS and Exchange logs for EAS command entries, in particular those containing Cmd=ItemOperations.
• Consider what level of investigation is possible given the number of results.
• Consider if known legitimate devices and EAS requests can be removed.
• Correlate entries with Windows event logs to determine if a file share was accessed at the same time as an EAS command and what was accessed.

Exchange ActiveSync is used by a large number of organisations and can be accessed from outside the organisation. Exchange then typically has network access to hosts inside the network such as a  domain controller as well as controlling access to sensitive assets such as mailboxes.

This work shows the danger of not architecturing a network to assume compromise. In this case, legitimate functionality is abused to extract files but should remote code execution be found in Exchange, attackers would be in a privileged position on the network.

Organisations are recommended to design networks so that all externally accessible services are segregated from other hosts and actively monitored for abuse.