Most users are familiar with Microsoft Exchange Online only as an application for accessing their email inboxes. However, by default, all users also have access to a system called Exchange Online PowerShell. This feature, designed primarily to assist IT administrators, allows a user to programmatically perform actions on a Microsoft 365 (M365) tenant. The specific actions a user can perform depend entirely on the user’s assigned roles.
Throughout the course of conducting M365 business email compromise investigations, Kroll has observed successful logon events that indicate some threat actors are leveraging Exchange Online PowerShell to aid in and/or automate interactions with compromised mailboxes and user accounts.
Identifying Exchange Online PowerShell Authentication Events
Kroll has identified the following indicators as likely evidence of an Exchange Online PowerShell logon attempt:
- Azure sign-in log entries with an “App Display Name” of Microsoft Exchange Online Remote PowerShell
- Unified Audit Log entries with user agent strings mentioning:
- Microsoft WinRM Client
- Microsoft.Exchange.PowerShell
- Unified Audit Log entries with user agent strings attributable to Internet Explorer 11
The newer Exchange Online PowerShell V2 module, which Microsoft recommends be used for Exchange Online connections, results in user agent strings that do not mention PowerShell or WinRM. Rather, the recorded user agent strings represent Internet Explorer 11. Entries mentioning WinRM are likely generated by older PowerShell modules that might rely on basic authentication.
Risks of Successful Threat Actor Authentications
Threat actors may leverage Exchange Online PowerShell to rapidly deploy malicious inbox rules and configure forwarding SMTP addresses. While the potential impact of an Exchange Online PowerShell sign-in by a compromised, non-privileged user account is limited to that user’s mailbox, compromised users with certain additional roles may pose a risk to all users on the tenant.
A user with default permissions would be able to perform the following common threat actor actions after logging in using PowerShell:
- Create/modify/delete own inbox rules (Figures 1 and 2)
- Create/modify/delete own forwarding SMTP address
- Send email as the user via the OWA API
Figure 1: Example of malicious inbox rule that redirects emails containing certain keywords to the junk folder
Figure 2: Resulting malicious rule in user mailbox
A user with elevated permissions could perform some—or all of—the following actions, depending on their assigned role(s):
- Create/modify/delete inbox rules for any user in the tenant
- Create/modify/delete forwarding SMTP address for any user in the tenant (Figure 3)
- Create and delete users
- Disable logging sources and/or limit the retention period for certain logs
- Reset user passwords
- Create and export compliance search results for any content in the tenant
Figure 3: Example of a malicious forwarding rule that sends a copy of all inbound emails to another inbox for all mailboxes for which the compromised user has access
Note that some of the expanded capabilities listed above may require PowerShell modules other than those that provide access to Exchange Online. As of this writing, Kroll has determined that it is not possible for a user to export the result of a compliance search unless they have the “Export” role, which is included by default in the “eDiscovery Manager” role group. Accordingly, due to this requirement, Kroll identified no risk that a threat actor could exfiltrate a user’s mailbox content following an Exchange Online PowerShell connection if the user is non-privileged.
Two Ways to Proactively Mitigate the Risk
As most users do not have a business need for Exchange Online PowerShell, IT administrators might simply consider disabling the feature for all users except those that require it for administration purposes (see here for how to disable Exchange Online PowerShell).
When multifactor authentication (MFA) is enabled for all authentication methods, threat actors will be forced to provide an MFA token to access Exchange Online PowerShell.
- Note that if you have disabled basic authentication via an authentication policy, PowerShell is a category separate from SMTP, Outlook and other services and needs to be independently disabled.
- If basic authentication is disabled for mail access protocols but left enabled for PowerShell, a threat actor would still be able to take actions on a compromised user’s account without needing to provide an MFA token.
Conclusion
In the short term, organizations can protect themselves from Exchange Online PowerShell exploitation by requiring employees to enable MFA and restricting user permissions according to a least-privilege policy. However, this is just one example of how threat actors exploit legitimate software tools and features for malicious purposes. Combined with malware and threat actor tactics that grow more sophisticated every day, cyber challenges are crucial to address as early as possible.
