The threat actor behind the SolarWinds attack – which was thought to have compromised around 18,000 customers using the company’s Orion software last year – is now targeting Microsoft mailbox owners by exploiting a legitimate feature of Microsoft Exchange.
The assault on Microsoft is reportedly part of a wider and longer-lasting wave of attacks that have been taking place over the last six months, which has seen the company inform over 600 users of more than 22,000 attacks.
These attacks appear to show no sign of slowing down. Microsoft itself has previously warned us about them. If you’re a Microsoft 365 user, there are measures you can take to mitigate this latest threat specifically – we detail how.
How the Microsoft Mailbox Attack Works
The threat actor – which cybersecurity experts have dubbed UNC2452 – is “moving laterally from on-premises networks to the Microsoft 365 cloud”, Cybersecurity firm Mandiant says.
Mandiant’s report details how the threat actor is infiltrating cloud service providers to gain access to their customers. Other techniques being used are detailed in the report, including reports from March that the threat actor was altering mailbox folder permissions to facilitate constant access to email messages.
But it’s how this threat is utilizing a function of Microsoft’s Exchange Web Services API to access information contained in mailboxes that has caused alarm amongst security experts in recent days.
Impersonation in Microsoft Exchange
The report claims the threat actor has been taking advantage of the ‘impersonation’ contained within Microsoft’s Exchange Web Services (EWS). EWS is a native Application Programme Interface. APIs help two applications communicate with one another, and EWS permits Microsoft Exchange servers and Office 365 to integrate or ‘communicate’ with other applications.
This integration consists of allowing client applications (such as Microsoft Outlook) to pull information out of a Microsoft Exchange server used by a business or team. It also allows service applications – such as a CRM system, to pull out things like contact information, or a sales program to access calendars and email addresses.
The ‘impersonation’ function – controlled by a privileged role called ‘Application Impresonation’ – is usually used for service applications/accounts that need to extract certain types of information from a number of inboxes, and thus need to act ‘as’ the mailbox owner in each instance. This stands in contrast to functions such as delegate access, which is used when, for example, a single user needs to access multiple calendars for planning meetings.
How is The Threat Actor Using Impersonation?
Mandiant explains that threat actors were “compromising accounts that had the Exchange Administrator or Global Administrator roles” because, in order to assign the ApplicationImpersonation role (the built-in exchange role that allows you to impersonate other mailbox owners), an account must have the privileges associated with the Exchange Administrator role/roles with similar privileges.
“It is useful to a threat actor because with access to one single account, they can become any other user in the victim organization and access that user’s email, attachments and contacts” – Doug Bienstock, Mandiant.
The document continues, “After obtaining the right level of privilege, the threat actor logs into the tenant using Exchange Online PowerShell and creates a new Management Role Assignment. The threat actor will create a new assignment and give it a name that blends in with other pre-existing assignments.” The role is created without restrictions, Mandiant says, so any mailbox in the tenant can be easily accessed.
“This feature must be explicitly granted to an account by an administrator in the organization,” Doug Bienstock, Mandiant’s Incident Response Manager, explains in Cybersecurity Dive.
He continued “It is useful to a threat actor because with access to one single account, they can become any other user in the victim organization and access that user’s email, attachments, and contacts.”
What Should I do if I’m Using a Microsoft Exchange Mailbox?
At the moment, the advice to all teams using Microsoft mailboxes is to review all the accounts and groups that have the Application Impersonation role assigned to them and remove them. Limiting what mailboxes this role will permit a user or application to access is also suggested.
News like this should also prompt companies to reflect whether they’re enforcing the Principle of Least Privilege – that any given module, user, or application on a network only has access to the bare minimum amount of information needed to perform the tasks it needs to – in all possible areas.
Going forward, it’s a good idea to create alerts for when new accounts are granted this specific privilege. Mandiant also suggests creating a whitelist of IP addresses to manage the logins of accounts with this role assigned.
It’s also worth considering setting up multifactor authentication, following Microsoft’s guidance.
The more functional and integrated available applications become, and the more they’re designed to create easier user experiences, the more shortcuts and automated processes are created. The exploitation of this sort of function means that there’s now an onus on businesses to not only regularly review their cybersecurity infrastructure, but also the use of easily-exploitable features, especially ones centered around permissions.
