Malicious Oauth app enables attackers to send spam through corporate cloud tenants

Microsoft investigated a new kind of attack where malicious OAuth applications were deployed on compromised cloud tenants before being used for mass spamming.

In this attack, as reported by Microsoft, threat actors start their operation by compromising particular cloud tenant users, as these users need to have sufficient privileges to create applications in the environment and give administrator consent to it. Those users were not using multi-factor authentication for logging into the cloud service.

To get successful access to those cloud environments, the attackers have deployed credential stuffing attacks: They attempted to reuse valid credentials they obtained from other services or applications. Such attacks work when individuals are using the same login and password on many different online services or websites. As an example, an attacker obtaining stolen credentials from an email account might use it for accessing social media services.

SEE: Mobile device security policy (TechRepublic Premium)

In this case, attackers used the credentials to get access to the cloud tenant. A single IP address ran the credential stuffing operation, hitting Azure Active Directory PowerShell applications for authentication. Microsoft researchers believe the attackers used a dump of compromised credentials.

How does the malicious application work?

The threat actor, once in possession of valid privileged users credentials, used a PowerShell script to perform actions in the Azure Active Directory of all compromised tenants.

The first action was to register a new single-tenant application using a specific naming convention: A domain name followed by an underscore character and then three random alphabetic characters. Legacy permission Exchange.ManageAsApp was then added for app-only authentication of the Exchange Online PowerShell module.

It was also granted admin consent. The previously registered application was then given both global administrator rights and Exchange Online administrator rights.

The final step was to add application credentials. This way, the attackers could add their own credentials to the OAuth application.

Once all these steps were done, the attackers could easily access the malicious application, even in the case of a password change from the compromised administrator account.

Why did they deploy the application?

The whole purpose of deploying the malicious application was to mass spam. To achieve that goal, the threat actor altered the Exchange Online settings via the privileged malicious application, which enabled them to authenticate the Exchange Online PowerShell module.

The attackers created a new Exchange connector, which are instructions to customize the way email flows to and from organizations using Microsoft 365 or Office 365. The new inbound connector was named using once again a specific naming convention, this time using a “Ran_” string followed by five alphabetical characters. The purpose of that connector was to allow emails from certain IP addresses from the attackers infrastructure to flow through the compromised Exchange Online service.

Twelve new transport rules were also created by the threat actor, named from Test01 to Test012. The purpose of these rules was to delete specific headers from every email flowing in:

• X-MS-Exchange-ExternalOriginalInternetSender
• X-MS-Exchange-SkipListedInternetSender
• Received-SPF
• Received
• ARC-Authentication-Results
• ARC-Message-Signature
• DKIM-Signature
• ARC-Seal
• X-MS-Exchange-SenderADCheck
• X-MS-Exchange-Authentication-Results
• Authentication-Results
• X-MS-Exchange-AntiSpam-MessageData-ChunkCount

The deletion of those headers allowed the attackers to evade security products detections and from email providers blocking their emails, therefore increasing the success of the operation.

Once the connector and the transport rules were set up, the actor could start sending massive volumes of spam emails.

How experienced was the threat actor?

The researchers mention that “the actor behind this attack has been actively running spam email campaigns for many years.” Based on their research, Microsoft established that the same actor has sent high volumes of spam emails in a short time frame by connecting to email servers from rogue IP addresses or sending spam from legitimate cloud-based bulk email sending infrastructure.

Microsoft researchers indicate that the threat actor was also deleting the malicious connector and associated transport rules after a spamming campaign. The actor would then recreate it for a new wave of spam, sometimes months after the initial one.

The threat actor triggered the spam campaign from cloud-based outbound email infrastructure outside of Microsoft, mainly Amazon SES and Mail Chimp, according to Microsoft. Those platforms enable sending of mass bulk email, usually for legitimate marketing purposes. Such modus operandi can only come from an experienced spamming actor.

What did the threat actor send in the spam?

The spam sent by this campaign contained two visible images in the email body — as well as dynamic and randomized content injected within the HTML body of the email message — to avoid being detected as spam, which is a common technique used by this threat actor.

The images entice the user to click a link because they are allegedly eligible for a prize. A click redirects the user to a website operated by the attackers where they are prompted to provide details for a survey and credit card information to pay for the shipping of the prize.

Small text at the very bottom of the web page reveals that the user is not paying for a shipping fee but for several paid subscription services in order to enter into a lottery for the prize.

How to protect your organization from this threat

This attack would have failed if the initial cloud tenants were protected by MFA. It is highly recommended to always deploy MFA for any internet-facing service or website.

Conditional access policies can also be set to enable device compliance or trusted IP address requirements for signing in.

A careful monitoring of all accesses also might help detect such compromises. Unusual IP addresses connecting to a service need to be flagged as suspicious and raise an alert.

Microsoft also recommends enabling security defaults in Azure AD, since it helps protect the organizational identity platform by providing preconfigured security settings such as MFA, protection for privileged accounts and more.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.