Recently, our pentesters were working with the PEAS utility for Exchange ActiveSync (EAS) — and stumbled upon an interesting issue.
When trying to get a listing of file shares through Document Library Access, the utility would crash with error 141 (LegacyDeviceOnStrictPolicy). Meanwhile, credential checking via --check worked normally.
It turned out that previously PEAS worked without errors because servers did not require mandatory Provisioning. But when administrators started enabling strict security policies on Exchange, servers began to require Provisioning.
Provisioning in EAS is a mechanism for negotiating security policies between a device and a server through a standard two-phase handshake, where the client accepts the server’s security policies, and the server allows further operations in response. As a result, the server issues a PolicyKey — a trust token for a specific account/device/server. This token changes when a new device is connected for the first time or when administrators update policies; the token can also change due to inactivity (long absence from logging into mail).
That is, without a valid PolicyKey, the server simply rejects data requests. An interesting point: the server cannot actually verify whether the device has applied the policies — it completely trusts the client. It is enough to simply go through the provisioning handshake and respond “yes, I’ve applied everything”.
Previously, when servers did not require Provisioning, the PEAS utility simply sent PolicyKey=0. But now this may not work, since the server may require a valid token.
To solve this problem, our experts patched PEAS, adding automatic Provisioning before UNC operations. Now the utility first performs a two-phase handshake with the server, obtains a valid PolicyKey, and only then makes requests to file shares. Additionally, we added the --policy-key flag for reusing the key during mass operations, which eliminates unnecessary requests and reduces noise in the logs.
If you want to delve deeper into the EAS mechanism and historical context of the utilities, you can read a detailed article by the creators of PEAS published back in 2016. It seems that the topic resurfaces every five years, and we’ve just provided an update.
What to do for defenders:
It is necessary to monitor Microsoft Exchange as a critical node that often becomes an “open door” to mail, files, and internal resources. Therefore:
— If possible, disable legacy functionality (EAS Document Library/UNC and other relics), reduce exceptions and compatibility with everything.
— If you cannot disable it, use behavioral control of EAS clients: check that there is always normal two-phase Provisioning before accessing data, monitor spikes of Status=141/142 and HTTP 449, and watch the dynamics of PolicyKey (sudden changes/reuse between devices — signs of alarm).
— At the same time, tighten basic hygiene: regularly review policies, clean up old profiles and temporary exceptions, and validate third-party clients before production.
— Limit the lifetime of cached PolicyKey and fix their binding to account/server/device. Drag all this into SIEM with binding “account » device » PolicyKey » operations”. Because in Exchange, there can be all sorts of things: mixed policies, strange clients, historical configuration tails — and this regularly makes trouble.
The main idea: EAS is designed to trust the client’s statement about accepting policies. This is normal for the protocol, but from a security perspective, you cannot rely solely on EAS. Use behavioral monitoring, external compliance checks (MDM/Intune), and minimize the attack surface by disabling unnecessary legacy features.
