{
	"id": "85db33c8-bd5c-46fc-a39d-ac584504c746",
	"created_at": "2026-04-06T01:31:45.917838Z",
	"updated_at": "2026-04-10T03:20:18.692259Z",
	"deleted_at": null,
	"sha1_hash": "e89cdd6746d89719ddfb5d67f788432e27e20d1a",
	"title": "Malicious OAuth applications abuse cloud email services to spread spam",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 885506,
	"plain_text": "Malicious OAuth applications abuse cloud email services to spread\r\nspam\r\nBy Microsoft Threat Intelligence\r\nPublished: 2022-09-22 · Archived: 2026-04-06 00:14:33 UTC\r\nMicrosoft researchers recently investigated an attack where malicious OAuth applications were deployed on\r\ncompromised cloud tenants and then used to control Exchange Online settings and spread spam. The investigation\r\nrevealed that the threat actor launched credential stuffing attacks against high-risk accounts that didn’t have multi-factor authentication (MFA) enabled and leveraged the unsecured administrator accounts to gain initial access.\r\nThe unauthorized access to the cloud tenant enabled the actor to create a malicious OAuth application that added a\r\nmalicious inbound connector in the email server. The actor then used the malicious inbound connector to send\r\nspam emails that looked like they originated from the targets’ domain. The spam emails were sent as part of a\r\ndeceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions.\r\nMicrosoft has been monitoring the rising popularity of OAuth application abuse. One of the first observed\r\nmalicious usage of OAuth applications in the wild is consent phishing. Consent phishing attacks aim to trick users\r\ninto granting permissions to malicious OAuth apps to gain access to user’s legitimate cloud services (mail servers,\r\nfiles storage, management APIs, etc.). In the past few years, Microsoft has observed that more and more threat\r\nactors, including nation-state actors, have been using OAuth applications for different malicious purposes –\r\ncommand-and-control (C2) communication, backdoors, phishing, redirections, and so on.\r\nThis recent attack involved a network of single-tenant applications installed in compromised organizations being\r\nused as the actor’s identity platform to perform the attack. As soon as the network was revealed, all the related\r\napplications were taken down and notifications to customers were sent, including recommended remediation\r\nsteps.\r\nThis blog presents the technical analysis of this attack vector and the succeeding spam campaign attempted by the\r\nthreat actor. It also provides guidance for defenders on protecting organizations from this threat, and how\r\nMicrosoft security technologies detect it.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 1 of 11\n\nFigure 1. Overview of the attack chain. The time between application deployment and usage varied;\r\nthere were cases where the actor took months before using the application.\r\nInitial access\r\nFor the attack to succeed, the threat actor needed to compromise cloud tenant users with sufficient permissions\r\nthat would allow the actor to create an application in the cloud environment and give it admin consent. The actor\r\nperformed credential stuffing attacks against their targets, attempting to access users with the global admin role.\r\nThe authentication attempts, which originated from a single IP address, were launched against the Azure Active\r\nDirectory PowerShell application (app ID: 1b730954-1685-4b74-9bfd-dac224a7b894). The same application was\r\nlater used to deploy the rest of the attack.\r\nBased on the success ratio of the authentication attempts, it is inferred that the attacker used a dump of\r\ncompromised credentials. The investigation also revealed that 86% of the compromised tenants had at least one\r\nadmin with a real-time high risk score, which means they were flagged by Azure AD Identity Protection to be\r\nmost likely compromised. It is also important to note that all the compromised admins didn’t have MFA enabled,\r\nwhich could have stopped the attack. These observations amplify the importance of securing accounts and\r\nmonitoring for high-risk users, especially those with high privileges.\r\nDeploying malicious OAuth application\r\nOnce the threat actor gained access to privileged users, their next step was to set up the malicious application.\r\nBased on analysis of the event user agent (Swagger-Codegen/1.4.0.0/csharp) and how quickly the deployment of\r\nthe application was done, it is likely that the actor ran a PowerShell script to perform the following Azure Active\r\nDirectory (AAD) management activities in all targeted tenants:\r\nRegister a new single–tenant application with the naming convention of [domain name]_([a-zA-Z]){3} (for\r\nexample: Contoso_GhY)\r\nAdd the legacy permission Exchange.ManageAsApp which can be used for app-only authentication of\r\nExchange Online PowerShell module\r\nGrant admin consent to the above permission\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 2 of 11\n\nGive global admin and Exchange Online admin roles to the previously registered application\r\nAdd application credentials (key/certificate/both)  \r\nThe threat actor added their own credentials to the OAuth application, which enabled them to access the\r\napplication even if the initially compromised global administrator changed their password.\r\nThe activities mentioned gave the threat actor control of a highly privileged application. It was observed that the\r\nthreat actor did not always use the application right after it was deployed. In some cases, it took weeks or months\r\nbefore the application was utilized. Also, in organizations that didn’t monitor for suspicious applications, the\r\napplications were deployed for months and used multiple times by the threat actor.\r\nModifying Exchange Online settings\r\nThe threat actor used the privileged application to authenticate the Exchange Online PowerShell module and\r\nmodify the Exchange Online settings. There were two modifications which allowed them to perform the next step\r\nin the attack chain:\r\nCreate a new inbound connector\r\nConnectors are a collection of instructions that customize the way email flows to and from organizations using\r\nMicrosoft 365 or Office 365. Most organizations using Microsoft 365 and Office 365 don’t need custom\r\nconnectors for regular mail flow, but some use it when they need to process messages from another messaging\r\nsystem that’s not running Exchange Online, or if they have a network appliance that performs policy checks and\r\nthen routes messages to their Exchange Online service.\r\nThe threat actor set a new inbound connector with the naming convention Ran_([a-zA-Z]){5} (for example\r\nRan_xAFzd). The purpose of the inbound connector was to allow mails from certain IPs (that are related to the\r\nattacker’s infrastructure) to flow through the victim’s Exchange Online service. This allowed the threat actor to\r\nsend emails that looked like they originated from the compromised Exchange domain. The configuration\r\ninformation for the newly created connectors were seen in Exchange Online audit event New-InboundConnector.\r\nThe following table shows the configuration parameters in the audit event related to this change:\r\nName Value\r\n“Name” “Ran_jBelh”\r\n“Enabled” “True”\r\n“CloudServicesMailEnabled” “True”\r\n“RestrictDomainsToCertificate” “False”\r\n“SenderDomains” “smtp:*;1”\r\n“SenderIPAddresses”\r\n“170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95;\r\n54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 3 of 11\n\n“RestrictDomainsToIPAddresses” “True”\r\n“ConnectorSource” “HybridWizard”\r\n“EFSkipIPs”\r\n“170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95;\r\n54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”\r\n“TreatMessagesAsInternal” “False”\r\n“ConnectorType” “OnPremises”\r\n“RequireTls” “False”\r\nCreate transport rules\r\nTransport rules (also known as mail flow rules) are sets of actions that can be taken on any mail that flows in the\r\norganization. The threat actor utilized this feature to set 12 new transport rules with the naming convention of\r\nTest01 to Test012. Each of these transport rules were responsible for deleting the following specific headers from\r\nevery mail that flowed in the organization:\r\nX-MS-Exchange-ExternalOriginalInternetSender\r\nX-MS-Exchange-SkipListedInternetSender\r\nReceived-SPF\r\nReceived\r\nARC-Authentication-Results\r\nARC-Message-Signature\r\nDKIM-Signature\r\nARC-Seal\r\nX-MS-Exchange-SenderADCheck\r\nX-MS-Exchange-Authentication-Results\r\nAuthentication-Results\r\nX-MS-Exchange-AntiSpam-MessageData-ChunkCount\r\nBy deleting these headers, the attacker tried defense evasion to prevent security products or email providers\r\ndetecting or blocking their emails and increase the success rate of the spam campaign. The configuration\r\ninformation for the newly created transport rules were seen in Exchange Online audit event New-TransportRule.\r\nThe following table shows the configuration parameters in the audit event related to this change:\r\nName Value\r\n“Name” “Test06”\r\n“SenderAddressLocation” “Header”\r\n“RemoveHeader” “ARC-Message-Signature”\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 4 of 11\n\nThese modifications to the Exchange Online settings allowed the threat actor to perform their primary goal in the\r\nattack: sending out spam emails. After each spam campaign, the actor deleted the malicious inbound connector\r\nand transport rules to prevent detection, while the application remained deployed in the tenant until the next wave\r\nof the attack (in some cases, the app was dormant for months before it was reused by the threat actor).\r\nFigure 2. An example of the PowerShell script used for setting new Exchange Online connector and\r\ntransport rules\r\nSpam email campaign sent through Exchange Online connector\r\nThe actor behind this attack has been actively running spam email campaigns for many years. Based on our\r\nresearch, this actor has sent high volumes of spam emails in short timeframes through other methods, such as\r\nconnecting to mail servers from rogue IP addresses or sending directly from legitimate cloud-based bulk email\r\nsending infrastructure.\r\nThe actor’s motive was to propagate deceptive sweepstakes spam emails designed to trick recipients into\r\nproviding credit card details and signing up for recurring subscriptions under the guise of winning a valuable\r\nprize. While the scheme possibly led to unwanted charges for targets, there was no evidence of overt security\r\nthreats such as credential phishing or malware distribution.\r\nThe spam campaign carried the hallmarks of this actor: programmatically generated messages containing two\r\nvisible hyperlinked images in the email body, as well as dynamic and randomized content injected within the\r\nHTML body of each mail message to evade spam filters.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 5 of 11\n\nFigure 3. An example of spam email sent through the Exchange Online inbound connector\r\nThe hyperlinked images within the spam messages implied to recipients that they were eligible for a prize. Once\r\nclicked, the hyperlink directed recipients to a website where they were asked to complete a survey and provide\r\ncredit card details to pay for the shipping of their prize.  Familiar brand logos, names, and websites were used\r\nthroughout the spam email, likely to give an illusion of legitimacy.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 6 of 11\n\nFigure 4. Clicking the image in the spam email leads to this website indicating a prize has been won\r\nThe fine print, visible only by scrolling to the very bottom of a subsequent page, revealed that in providing their\r\ncredit card information, recipients were not paying a shipping fee for their prize, but were in fact agreeing to be\r\ncharged fees for several paid subscription services in order to enter into a sweepstakes for the prize. It is likely the\r\nthreat actor’s main motive was potential financial gain from people who fell victim to this deceptive sweepstakes\r\nspam campaign.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 7 of 11\n\nFigure 5. The fine print shows the chance to win a prize is only through a sweepstakes after paying\r\nfees\r\nLikely to achieve scale and further maximize the chances of successful email delivery, the actor triggered this\r\nspam campaign from cloud-based outbound email infrastructure outside of Microsoft, mainly Amazon SES and\r\nMail Chimp. These email platforms enable sending of mass bulk email, normally for marketing and other\r\nlegitimate purposes.\r\nThe campaign also utilized techniques to generate unique dynamic URLs underpinning the hyperlinked images\r\nwithin each spam email message, as shown in the examples below.\r\nFigure 6. Examples of dynamic URL generation (domain obfuscated)\r\nThis spam campaign exclusively targeted consumer email accounts. In the case of spam messages sent to\r\nMicrosoft-hosted consumer email accounts (outlook.com), the spam emails were moved into customers’ junk\r\nfolders before they could be viewed and clicked.\r\nMitigations\r\nWhile the follow-on spam campaign targets consumer email accounts, this attack targets enterprise tenants to use\r\nas infrastructure for this campaign. This attack thus exposes security weaknesses that could be used by other threat\r\nactors in attacks that could directly impact affected enterprises.\r\nAs the main initial access vector of the attack was to obtain the admin’s credentials, we recommend organizations\r\ntake the following steps to reduce their attack surface:\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 8 of 11\n\nMitigate credential guessing attacks risks\r\nA key step in reducing the attack surface is securing the identity infrastructure. The most common initial access\r\nvector observed in this attack was account compromise through credential stuffing, and all the compromised\r\nadministrator accounts did not have MFA enabled. Implementing security practices that strengthen account\r\ncredentials such as enabling MFA raises the cost of an attack.   \r\nEnable conditional access policies\r\nConditional access policies are evaluated and enforced every time the user attempts to sign in. Organizations can\r\nprotect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or\r\ntrusted IP address requirements.\r\nEnable continuous access evaluation\r\nContinuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks,\r\nsuch as when a user is terminated or moves to an untrusted location.\r\nEnable security defaults\r\nWhile some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which\r\nis mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect\r\nthe organizational identity platform, as they provide preconfigured security settings such as MFA, protection for\r\nprivileged activities, and others.\r\nLeveraging its cross-signal capabilities, Microsoft 365 Defender alerts customers using Microsoft Defender for\r\nOffice 365, Microsoft Defender for Cloud Apps, Application governance add-on, and Azure Active Directory\r\nIdentity Protection to detect the techniques covered in the attack through the attack chain. Each product can\r\nprovide a different aspect for protection to cover the techniques observed in this attack:\r\nMicrosoft 365 Defender\r\nSuspicious email-sending pattern from new Exchange inbound connector – This alert is generated when a\r\nsuspicious email-sending pattern originating from a new Exchange inbound connector is detected. This behavior\r\nmight suggest that an attacker set a malicious inbound connector to allow anonymous relay through the\r\norganization’s Exchange Online service.\r\nRecommended reading to response for malicious connector incidents:\r\nRespond to a compromised connector in Microsoft 365\r\nAlert grading for malicious exchange connectors\r\nNew transport rule removing antispam header – This alert is generated when a new transport rule to remove\r\nantispam header is detected.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 9 of 11\n\nSuspicious inbound connector and transport rule created to remove sender email headers – This alert is\r\ngenerated when a suspicious inbound connector and transport rule is created to remove headers that identify the\r\ntrue source address of sender. This might indicate a spam campaign is ongoing from the organization’s mailbox.\r\nSuspicious Azure AD app creation – This alert is generated when a user account creates Azure Active Directory\r\nOAuth application with suspicious characteristics, as observed in this campaign.\r\nAzure AD app registration by risky user – This alert is generated when a user account with high risk score as\r\ncalculated by AAD Identity Protection is creating a new OAuth application and grants admin consent to it.\r\nMicrosoft Defender for Office 365\r\nMicrosoft Defender for Office 365 detects threat activity associated with this spamming campaign through the\r\nfollowing email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity.\r\nWe’re listing them here because we recommend that these alerts be investigated and remediated immediately.\r\nEmail messages from a campaign removed after delivery. This alert is generated when any messages\r\nassociated with a campaign are delivered to mailboxes in an organization. Microsoft removes the infected\r\nmessages from Exchange Online mailboxes using zero-hour auto purge (ZAP) if this event occurs.\r\nMicrosoft Defender for Cloud Apps\r\nActivity from suspicious IP addresses. This alert is generated when there is activity from an IP address that has\r\nbeen identified as risky by Microsoft Threat Intelligence or by the organization. These IP addresses were identified\r\nas being involved in malicious activities, such as performing password spray, botnet C2, and may indicate a\r\ncompromised account.\r\nActivity from a password-spray associated IP address. This alert is generated when a successful sign-in from\r\nan IP address that had been identified as participating in password spray was observed.\r\nApp governance\r\nApp governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth\r\napplications that make sensitive Exchange Online Administrative activities along with other threat detection alerts.\r\nActivity related to this campaign will trigger the following alert:\r\nOAuth app with suspicious metadata has exchange permission. This alert is generated when a line of business\r\nOAuth app with suspicious metadata has privilege to manage permission over Exchange Online, which can lead\r\nan OAuth App to perform data collection or exfiltration activities or attempts to access and retrieve sensitive\r\ninformation.\r\nAzure AD Identity Protection automatically detects and remediates identity-based risks. It detects suspicious sign-in attempts and raises any of the following alerts:\r\nAnomalous Token. This alert flags a token’s unusual characteristics, such as its token lifetime or played\r\nfrom an unfamiliar location.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 10 of 11\n\nUnfamiliar sign-in properties. In this phishing campaign, the attackers used multiple proxies or VPNs\r\noriginating from various countries or regions unfamiliar to the target user.This alert flags anomalies in the\r\ntoken claims, token age, and other authentication attributes.\r\nAnonymous IP address. This alert flag sign-in attempts from anonymous IP addresses (for example, Tor\r\nbrowser or anonymous VPN).\r\nHunting queries\r\nTo locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:\r\nApplications given the “Exchange.ManageAsApp” permission:\r\nCloudAppEvents\r\n| where Timestamp \u003e ago(30d)\r\n| where ActionType == \"Add app role assignment to service principal.\"\r\n| where RawEventData.ResultStatus == \"Success\"\r\n| where RawEventData has \"dc50a0fb-09a3-484d-be87-e023b12c6440\" //Exchange.ManageAsApp Role Id\r\n| project Timestamp, AccountObjectId,AccountDisplayName, AppId =\r\nRawEventData.ModifiedProperties[0].NewValue, AppName = RawEventData.ModifiedProperties[6].NewValue\r\nNew transport rules that remove anti-spam headers from emails:\r\nCloudAppEvents\r\n| where ActionType == \"New-TransportRule\"\r\n| mvexpand Param = RawEventData.Parameters\r\n| where Param.Name == \"RemoveHeader\" and Param.Value contains \"X-MS-Exchange-AntiSpam-MessageData\"\r\n| project Timestamp, AccountObjectId, AccountDisplayName, ServicePrincipalId =\r\ntostring(RawEventData.AppId)\r\nUpdate 09/23/2022 – Updated instances ‘Exchange server’ to ‘Exchange Online” to clarify that\r\nattackers were not able to compromise on-premises Exchange servers, but that the permissions they\r\ngained during their compromise of cloud tenants allowed the attackers to modify Exchange Online\r\nsettings.\r\nSource: https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spre\r\nad-spam/\r\nhttps://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam/"
	],
	"report_names": [
		"malicious-OAuth-applications-used-to-compromise-email-servers-and-spread-spam"
	],
	"threat_actors": [],
	"ts_created_at": 1775439105,
	"ts_updated_at": 1775791218,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e89cdd6746d89719ddfb5d67f788432e27e20d1a.pdf",
		"text": "https://archive.orkl.eu/e89cdd6746d89719ddfb5d67f788432e27e20d1a.txt",
		"img": "https://archive.orkl.eu/e89cdd6746d89719ddfb5d67f788432e27e20d1a.jpg"
	}
}