{
	"id": "63c7f4f8-0948-49b2-8f2f-d72a7270d95c",
	"created_at": "2026-04-06T00:19:22.622058Z",
	"updated_at": "2026-04-10T13:11:34.456049Z",
	"deleted_at": null,
	"sha1_hash": "188e8e3b9b58ddeeb4ddee4720bacec6123ffc1d",
	"title": "Detecting and mitigating a multi-stage AiTM phishing and BEC campaign | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1252904,
	"plain_text": "Detecting and mitigating a multi-stage AiTM phishing and BEC\r\ncampaign | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2023-06-08 · Archived: 2026-04-05 16:53:47 UTC\r\nMicrosoft Defender Experts uncovered a multi-stage adversary-in-the-middle (AiTM) phishing and business email\r\ncompromise (BEC) attack against banking and financial services organizations. The attack originated from a\r\ncompromised trusted vendor and transitioned into a series of AiTM attacks and follow-on BEC activity spanning\r\nmultiple organizations. This attack shows the complexity of AiTM and BEC threats, which abuse trusted\r\nrelationships between vendors, suppliers, and other partner organizations with the intent of financial fraud.\r\nFigure 1. AiTM and BEC attacks spanning multiple suppliers and partner organizations  \r\nWhile the attack achieved the end goal of a typical AiTM phishing attack followed by business email compromise,\r\nnotable aspects, such as the use of indirect proxy rather than the typical reverse proxy techniques, exemplify the\r\ncontinuous evolution of these threats. The use of indirect proxy in this campaign provided attackers control and\r\nflexibility in tailoring the phishing pages to their targets and further their goal of session cookie theft. After\r\nsigning in with the stolen cookie through a session replay attack, the threat actors leveraged multifactor\r\nauthentication (MFA) policies that have not been configured using security best practices in order to update MFA\r\nmethods without an MFA challenge. A second-stage phishing campaign followed, with more than 16,000 emails\r\nsent to the target’s contacts.\r\nThis attack highlights the complexity of AiTM attacks and the comprehensive defenses they necessitate. This\r\nsophisticated AiTM attack requires beyond the typical remediation measures for identity compromise such as a\r\npassword reset. Affected organizations need to revoke session cookies and roll back MFA modifications made by\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 1 of 12\n\nthe threat actor. The incident also highlights the importance of proactive threat hunting to discover new TTPs on\r\npreviously known campaigns to surface and remediate these types of threats.\r\nTo launch this attack, the attackers used an AiTM phishing kit developed, maintained, and operated by a threat\r\nactor that Microsoft tracks as Storm-1167. As part of our threat actor tracking and naming taxonomy, Microsoft\r\nuses Storm-#### designations as a temporary name given to an unknown, emerging, or developing cluster of\r\nthreat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about\r\nthe origin or identity of the actor behind the activity.\r\nAiTM with indirect proxy\r\nAdversary-in-the-middle (T1557, T1111) is a type of attack that aims to intercept authentication between users and\r\na legitimate authentication service for the purpose of compromising identities or performing other actions. The\r\nattackers position themselves between a user and the service to steal credentials and intercept MFA in order to\r\ncapture the session cookie. The attackers can then replay the session with the stolen session cookie before the\r\ntoken expiration time and impersonate the user without user intervention or MFA. With this session, the attackers\r\ncould access the affected user’s resources and applications and perform business email compromise attacks and\r\nother malicious activities. More details about AiTM campaigns can be found on the blog Attackers use AiTM\r\nphishing sites as entry point to further financial fraud.\r\nUnlike campaigns we have previously reported, this attack did not use the reverse proxy method that AiTM kits\r\nlike EvilProxy and NakedPages use, in which the attacker’s server proxies the request from the application’s\r\nlegitimate sign-in page. Instead, the attack used AiTM attack with indirect proxy method, in which the attacker\r\npresented targets with a website that mimicked the sign-in page of the targeted application, as in traditional\r\nphishing attacks, hosted on a cloud service. The said sign-in page contained resources loaded from an attacker-controlled server, which initiated an authentication session with the authentication provider of the target\r\napplication using the victim’s credentials.\r\nIn this AiTM attack with indirect proxy method, since the phishing website is set up by the attackers, they have\r\nmore control to modify the displayed content according to the scenario. In addition, since the phishing\r\ninfrastructure is controlled by the attackers, they have the flexibility to create multiple servers to evade detections.\r\nUnlike typical AiTM attacks, there are no HTTP packets proxied between the target and the actual website.\r\nWhen MFA is requested after successful password validation, the server displays a fake MFA page. Once the MFA\r\nis provided by the user, the attacker uses the same MFA token in the initiated session with the authentication\r\nprovider. Following successful authentication, the session token is granted to the attacker, and victim is redirected\r\nto another page. The following diagram illustrates the AiTM attack observed in this scenario:\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 2 of 12\n\nFigure 2. AiTM with indirect proxy\r\nAttack chain: AiTM phishing attack leads to second-stage BEC\r\nOur investigation into an AiTM phishing attack using the Storm-1167 AiTM kit uncovered details of a campaign\r\nthat led to BEC activity. In the following sections, we present our in-depth analysis of the end-to-end attack chain.\r\nFigure 3. Attack chain from AiTM phishing attack to BEC\r\nStage 1: Initial access via trusted vendor compromise\r\nThe attack started with a phishing email from one of the target organizations’ trusted vendors. The phishing email\r\nwas sent with a seven-digit code as the subject. This code was unique for every target organization, which is likely\r\na tracking mechanism for the attacker. The email body included a link to view or download a fax document. The\r\nlink pointed to a malicious URL hosted on canva[.]com.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 3 of 12\n\nSending phishing emails from a trusted vendor was one of the common behaviors that was observed for this threat\r\nactor across multiple targeted organizations. The intent of this behavior is to abuse the trusted vendor relationship\r\nand to blend with legitimate email traffic. A few of the target organizations had policies that automatically allow\r\nemails from trusted vendors, enabling the attacker to slip past detections.\r\nStage 2: Malicious URL click\r\nThreat actors often abuse legitimate services and brands to avoid detection. In this scenario, we observed that the\r\nattacker leveraged the legitimate service Canva for the phishing campaign. Canva is a graphic design platform that\r\nallows users to create social media graphics, presentations, posters, and other visual content. Attackers abused the\r\nCanva platform to host a page that shows a fake OneDrive document preview and links to a phishing URL:\r\nFigure 4. Screenshot of the intermediary page leading to AiTM landing page\r\nStage 3: AiTM attack\r\nAccessing the URL redirected the user to a phishing page hosted on the Tencent cloud platform that spoofed a\r\nMicrosoft sign-in page. The final URL was different for every user but showed the same spoofed sign-in page.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 4 of 12\n\nFigure 5. Fake Microsoft sign-in page requesting the target’s password\r\nAfter the target provided the password on the phishing page, the attacker then used the credentials in an\r\nauthentication session created on the target website. When the attacker is prompted with MFA in the\r\nauthentication session, the attacker modified the phishing page into a forged MFA page (as seen below). Once the\r\ntarget completed the multifactor authentication, the session token was then captured by the attacker.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 5 of 12\n\nFigure 6. Fake Microsoft MFA page requesting a verification code\r\nThe phishing pages for the AiTM attack were hosted on IP addresses located in Indonesia. The follow-on sign-ins\r\ndescribed in the following sections were also observed from the same IP addresses.\r\nStage 4: Session cookie replay\r\nIn a stolen session cookie replay attack, the attacker uses the valid stolen cookie to impersonate the user,\r\ncircumventing authentication mechanisms of passwords and MFA. In this campaign, we observed that the attacker\r\nsigned in with the stolen cookie after a few hours from an IP address based in the United States. The attacker\r\nmasqueraded as the target with this session replay attack and accessed email conversations and documents hosted\r\nin the cloud. In addition, the attacker generated a new access token, allowing them to persist longer in the\r\nenvironment.\r\nStage 5: MFA method modification\r\nThe attacker then proceeded to add a new MFA method for the target’s account, which was through phone based\r\none-time password (OTP), in order to sign in using the user’s stolen credentials undetected. Adding a new MFA\r\nmethod, by default, does not require re-authentication. In this campaign, a common behavior that was observed\r\nwas the attacker adding OneWaySMS, a phone-based OTP service, as a new MFA method in addition to the\r\nexisting method used by the target. A phone number with the Iranian country code was observed added as the\r\nnumber used to receive the phone-based OTP.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 6 of 12\n\nFigure 7. MFA configuration change from cloud application activity logs\r\nStage 6: Inbox rule creation\r\nThe attacker later signed in with the new session token and created an Inbox rule with parameters that moved all\r\nincoming emails on the user’s mailbox to the Archive folder and marked all the emails as read.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 7 of 12\n\nFigure 8. Inbox rule creation\r\nStage 7: Phishing campaign\r\nFollowed by Inbox rule creation, the attacker initiated a large-scale phishing campaign involving more than\r\n16,000 emails with a slightly modified Canva URL. The emails were sent to the compromised user’s contacts,\r\nboth within and outside of the organization, as well as distribution lists. The recipients were identified based on\r\nthe recent email threads in the compromised user’s inbox. The subject of the emails contained a unique seven-digit\r\ncode, possibly a tactic by the attacker to keep track of the organizations and email chains.\r\nStage 8: BEC tactics\r\nThe attacker then monitored the victim user’s mailbox for undelivered and out of office emails and deleted them\r\nfrom the Archive folder. The attacker read the emails from the recipients who raised questions regarding the\r\nauthenticity of the phishing email and responded, possibly to falsely confirm that the email is legitimate. The\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 8 of 12\n\nemails and responses were then deleted from the mailbox. These techniques are common in any BEC attacks and\r\nare intended to keep the victim unaware of the attacker’s operations, thus helping in persistence.\r\nStage 9: Accounts compromise\r\nThe recipients of the phishing emails from within the organization who clicked on the malicious URL were also\r\ntargeted by another AiTM attack. Microsoft Defender Experts identified all compromised users based on the\r\nlanding IP and the sign-in IP patterns. \r\nStage 10: Second-stage BEC\r\nThe attacker was observed initiating another phishing campaign from the mailbox of one of the users who was\r\ncompromised by the second AiTM attack. Microsoft revoked the compromised user’s session cookie, intervening\r\nwith the second-stage attack.  \r\nMicrosoft Defender Experts: Extending security and threat defense\r\nThis AiTM attack’s use of indirect proxy is an example of the threat’s increasingly complex and evolving TTPs to\r\nevade and even challenge conventional solutions and best practices. Proactively hunting for and quickly\r\nresponding to threats thus becomes an even more important aspect in securing organization networks because it\r\nprovides an added layer to other security remediations and can help address areas of defense evasion.\r\nMicrosoft Defender Experts is part of Microsoft’s global network of more than 8,000 security analysts and\r\nresearchers who, through our managed services like Microsoft Defender Experts for Hunting, help extend\r\norganizations’ ability to defend their environment, manage security, and even augment SOC teams. Our experts\r\nalso enrich our vast cross-domain signals and let us deliver coordinated threat defense in our security products and\r\nsolutions.\r\nIn this incident, because our experts actively research for new AiTM and BEC techniques, they were able to create\r\nadvanced hunting detections for the Defender Experts service. These detections, combined with our experts’ own\r\nanalyses of the anomalous emails and user behavior, enabled them to uncover the attack at its early stages, analyze\r\nthe entire attack chain, and identify and promptly reach out to affected and targeted customers through Defender\r\nExperts Notifications. They then continuously monitored the attack for any additional compromised users or\r\nchanges in the phishing patterns as it rapidly unfolded into a large-scale campaign.\r\nDefender Experts also initiated rapid response with Microsoft 365 Defender to contain the attack including:\r\nAutomatically disrupting the AiTM attack on behalf of the impacted users based on the signals observed in\r\nthe campaign\r\nInitiating zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to find and take automated\r\nactions on the emails that are a part of the phishing campaign\r\nDefender Experts further worked with customers to remediate compromised identities through the following\r\nrecommendations:\r\nRevoking session cookies in addition to resetting passwords\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 9 of 12\n\nRevoking the MFA setting changes made by the attacker on the compromised user’s accounts\r\nRequire re-challenging MFA for MFA updates as the default\r\nMitigation and protection guidance\r\nMicrosoft 365 Defender detects suspicious activities related to AiTM phishing attacks and their follow-on\r\nactivities, such as session cookie theft and attempts to use the stolen cookie to sign into Exchange Online. To\r\nfurther protect themselves from similar attacks, organizations should also consider complementing MFA with\r\nconditional access policies, where sign-in requests are evaluated using additional identity-driven signals like user\r\nor group membership, IP location information, and device status, among others.\r\nMitigating AiTM phishing attacks\r\nThe general remediation measure for any identity compromise is to reset the password for the compromised user.\r\nHowever, in AiTM attacks, since the sign-in session is compromised, password reset is not an effective solution.\r\nAdditionally, even if the compromised user’s password is reset and sessions are revoked, the attacker can set up\r\npersistence methods to sign-in in a controlled manner by tampering with MFA. For instance, the attacker can add a\r\nnew MFA policy to sign in with a one-time password (OTP) sent to attacker registered mobile number. With this\r\npersistence mechanisms in place, the attacker can have control over the victim’s account despite conventional\r\nremediation measures.\r\nWhile AiTM phishing attempts to circumvent MFA, implementation of MFA still remains an essential pillar in\r\nidentity security and highly effective at stopping a wide variety of threats. MFA is the reason that threat actors\r\ndeveloped the AiTM session cookie theft technique in the first place. Organizations are advised to work with their\r\nidentity provider to ensure security controls like MFA are in place. Microsoft customers can implement through\r\nvarious methods, such as using the Microsoft Authenticator, FIDO2 security keys, and certificate-based\r\nauthentication. \r\nDefenders can also complement MFA with the following solutions and best practices to further protect their\r\norganizations from such attacks: \r\nUse security defaults as a baseline set of policies to improve identity security posture. For more granular\r\ncontrol, enable conditional access policies, especially risk-based access policies. Conditional\r\naccess policies evaluate sign-in requests using additional identity-driven signals like user or group\r\nmembership, IP location information, and device status, among others, and are enforced for suspicious\r\nsign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling\r\npolicies such as compliant devices, trusted IP address requirements, or risk-based policies with proper\r\naccess control.\r\nImplement continuous access evaluation.\r\nInvest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites.\r\nFor example, organizations can leverage web browsers that automatically identify and block malicious\r\nwebsites, including those used in this phishing campaign, and solutions that detect and block malicious\r\nemails, links, and files.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 10 of 12\n\nContinuously monitor suspicious or anomalous activities. Hunt for sign-in attempts with suspicious\r\ncharacteristics (for example, location, ISP, user agent, and use of anonymizer services). \r\nDetections\r\nBecause AiTM phishing attacks are complex threats, they require solutions that leverage signals from multiple\r\nsources. Microsoft 365 Defender uses its cross-domain visibility to detect malicious activities related to AiTM,\r\nsuch as session cookie theft and attempts to use stolen cookies for signing in.\r\nUsing Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AiTM-related alerts in\r\nmultiple scenarios. For Azure AD customers using Microsoft Edge, attempts by attackers to replay session cookies\r\nto access cloud applications are detected by Defender for Cloud Apps connectors for Office 365 and Azure. In\r\nsuch scenarios, Microsoft 365 Defender raises the following alert:\r\nStolen session cookie was used\r\nIn addition, signals from these Defender for Cloud Apps connectors, combined with data from the Defender for\r\nEndpoint network protection capabilities, also triggers the following Microsoft 365 Defender alert on Azure AD\r\nenvironments:\r\nPossible AiTM phishing attempt\r\nA specific Defender for Cloud Apps connector for Okta, together with Defender for Endpoint, also helps detect\r\nAiTM attacks on Okta accounts using the following alert:\r\nPossible AiTM phishing attempt in Okta\r\nOther detections that show potentially related activity are the following:\r\nMicrosoft Defender for Office 365\r\nEmail messages containing malicious file removed after delivery\r\nEmail messages from a campaign removed after delivery\r\nA potentially malicious URL click was detected\r\nA user clicked through to a potentially malicious URL\r\nSuspicious email sending patterns detected\r\nMicrosoft Defender for Cloud Apps\r\nSuspicious inbox manipulation rule\r\nImpossible travel activity\r\nActivity from infrequent country\r\nSuspicious email deletion activity\r\nAzure AD Identity Protection\r\nAnomalous Token\r\nUnfamiliar sign-in properties\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 11 of 12\n\nUnfamiliar sign-in properties for session cookies\r\nMicrosoft 365 Defender\r\nBEC-related credential harvesting attack\r\nSuspicious phishing emails sent by BEC-related user\r\nHunting queries\r\nMicrosoft Sentinel\r\nMicrosoft Sentinel customers can use the following analytic templates to find BEC related activities similar to\r\nthose described in this post:\r\nExchange workflow MailItemsAccessed operation anomaly\r\nMalicious Inbox Rule\r\nSharePointFileOperation via previously unseen IPs\r\nSharePointFileOperation via devices with previously unseen user agents\r\nUser login from different countries within 3 hours\r\nTI Matching Analytics\r\nIn addition to the analytic templates listed above Microsoft Sentinel customers can use the following hunting\r\ncontent to perform Hunts for BEC related activities:\r\nPossible AiTM phishing attempt against Azure AD\r\nUnfamiliar Signin Correlation with AzurePortal Signin Attempts and AuditLogs\r\nMultiple users email forwarded to same destination\r\nOffice Mail Rule Creation with suspicious archive mail move activity\r\nSign-ins From VPS providers\r\nSuccessful sign-in from non-compliant device\r\nRisky sign-in with new MFA method\r\nFurther reading\r\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat\r\nIntelligence Blog: https://aka.ms/threatintelblog.\r\nTo get notified about new publications and to join discussions on social media, follow us on Twitter at\r\nhttps://twitter.com/MsftSecIntel.\r\nSource: https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nhttps://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/"
	],
	"report_names": [
		"detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign"
	],
	"threat_actors": [
		{
			"id": "7af47f73-be62-4152-9579-42b26478d2ec",
			"created_at": "2024-02-02T02:00:04.056014Z",
			"updated_at": "2026-04-10T02:00:03.544365Z",
			"deleted_at": null,
			"main_name": "Storm-1167",
			"aliases": [
				"DEV-1167"
			],
			"source_name": "MISPGALAXY:Storm-1167",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434762,
	"ts_updated_at": 1775826694,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/188e8e3b9b58ddeeb4ddee4720bacec6123ffc1d.pdf",
		"text": "https://archive.orkl.eu/188e8e3b9b58ddeeb4ddee4720bacec6123ffc1d.txt",
		"img": "https://archive.orkl.eu/188e8e3b9b58ddeeb4ddee4720bacec6123ffc1d.jpg"
	}
}