Security researchers have flagged an active, widespread email-driven social engineering campaign using adversary-in-the-middle (AitM) techniques to seize control of Microsoft 365 accounts. The objective is not broad data theft — it is surgical: identify personnel involved in financial workflows and harvest payroll- and finance-related email. The campaign routes malicious sign-ins through residential proxies, making attacker logins indistinguishable from ordinary consumer traffic at the network layer. Organizations running Microsoft 365 with weak MFA posture or legacy authentication are the primary exposure population, and finance, payroll, and HR teams are the explicit targets. This is business email compromise (BEC) tradecraft matured into a scalable, infrastructure-backed operation — and it is active right now.
Technical Analysis
Affected Products and Platforms
- Microsoft 365 (Exchange Online, SharePoint Online, Teams)
- Microsoft Entra ID (Azure AD) authentication plane
- Any tenant relying on SMS/voice MFA, TOTP-only MFA, or legacy authentication protocols (IMAP, POP3, SMTP AUTH, basic auth remnants)
How the Attack Works
AitM phishing defeats conventional MFA by inserting a malicious reverse proxy between the victim and the legitimate Microsoft login service. The attack chain typically unfolds as follows:
- Delivery: A spear-phishing email — often themed around HR, payroll, invoices, or document sharing — directs the victim to a phishing URL hosting an AitM proxy (tooling such as Evilginx-class frameworks is typical in these campaigns).
- Credential and session capture: The proxy relays the victim's credentials and MFA token to the real Microsoft 365 service in real time. The victim completes MFA successfully — and the attacker captures the resulting session cookie / refresh token, which is the actual prize.
- Session replay: The attacker replays the stolen session token from infrastructure hidden behind residential proxies. This is the campaign's defining feature: sign-ins originate from consumer ISP IP space (Comcast, AT&T, Vodafone and similar ASNs), defeating crude geo-blocking and IP reputation controls.
- Entrenchment and reconnaissance: With a valid session, the attacker authenticates to Exchange Online, enumerates mailboxes, and runs searches for payroll, wire transfer, banking, and payment-related correspondence. Common follow-on behaviors include registering an attacker-controlled MFA method, creating inbox rules to hide replies, and setting up OAuth consent or forwarding to external addresses.
- Monetization: The harvested financial context is used to craft highly credible payroll diversion or vendor payment fraud — the classic BEC payoff, now executed with the victim's own authenticated session.
Why Residential Proxies Matter
Traditional impossible-travel and ASN-based detections assume attackers log in from datacenter or VPN IP space. Residential proxies collapse that assumption. Sign-in logs will show authentications from US (or victim-local) consumer broadband addresses with no obvious anomaly beyond, potentially, device fingerprint mismatches and concurrent sessions from multiple locations. Detection must therefore shift to token/session behavior and post-authentication activity, not just source IP reputation.
Exploitation Status
- Confirmed active, widespread in-the-wild campaign per the research reporting.
- No CVE is associated with this activity — it abuses the design of session-token authentication, not a software flaw. There is nothing to patch; the defense is configuration, phishing-resistant MFA, and detection.
Detection & Response
The highest-fidelity detection points for AitM compromise in a Microsoft 365 environment are: (1) anomalous session/token issuance and sign-in patterns, (2) suspicious mailbox rule creation, (3) attacker MFA method registration shortly after sign-in, and (4) mailbox search/egress behavior consistent with payroll reconnaissance.
---
title: Microsoft 365 AitM Phishing - Suspicious Inbox Rule Creation for Email Concealment
id: 3f8a1c42-7b9d-4e51-a2c6-9d4e5f6a7b8c
status: experimental
description: Detects creation of inbox rules in Exchange Online that move, delete, or mark-as-read inbound mail - a hallmark post-AitM-takeover behavior used to hide payroll diversion replies from victims.
references:
- https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html
- https://attack.mitre.org/techniques/T1098/002/
- https://attack.mitre.org/techniques/T1114/002/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.persistence
- attack.t1098.002
- attack.collection
- attack.t1114.002
logsource:
product: m365
service: exchange
detection:
selection_operation:
Operation:
- 'New-InboxRule'
- 'Set-InboxRule'
selection_parameters:
Parameters|contains:
- 'DeleteMessage'
- 'MoveToFolder'
- 'MarkAsRead'
- 'SoftDeleteMessage'
- 'RedirectTo'
- 'ForwardTo'
- 'ForwardAsAttachmentTo'
condition: selection_operation and selection_parameters
falsepositives:
- Legitimate user-created inbox rules, particularly around shared mailboxes and service accounts
- Helpdesk-administered rules during onboarding
level: high
---
title: Microsoft 365 - New Authentication Method Registered After Sign-In From Residential IP
id: 8c2d4e6f-1a3b-4c5d-9e7f-2a4b6c8d0e1f
status: experimental
description: Detects registration of new MFA/authentication methods on a Microsoft 365 account, a common attacker entrenchment step following AitM session theft. Correlate with sign-in source for confidence.
references:
- https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html
- https://attack.mitre.org/techniques/T1556/006/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.persistence
- attack.t1556.006
- attack.t1078
logsource:
product: azure
service: auditlogs
detection:
selection:
OperationName|contains:
- 'User registered security info'
- 'User started registration of security info'
- 'Add phone authentication method'
- 'Add Microsoft Authenticator authentication method'
- 'Add FIDO2 security key'
- 'Update user'
filter_legit:
InitiatedBy|contains:
- 'helpdesk'
- 'idp-admin'
condition: selection and not filter_legit
falsepositives:
- New employee MFA onboarding
- Users adding backup authentication methods voluntarily
level: medium
---
title: Microsoft 365 - External Email Forwarding Configured on Mailbox
id: 5e7f9a1b-3c4d-4e5f-8a9b-1c2d3e4f5a6b
status: experimental
description: Detects mailbox forwarding or redirect to external addresses in Exchange Online, used to exfiltrate payroll and finance correspondence after AitM account takeover.
references:
- https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html
- https://attack.mitre.org/techniques/T1114/003/
- https://attack.mitre.org/techniques/T1048/
author: Security Arsenal
date: 2026/08/12
tags:
- attack.exfiltration
- attack.t1114.003
- attack.t1048
logsource:
product: m365
service: exchange
detection:
selection:
Operation:
- 'Set-Mailbox'
Parameters|contains:
- 'ForwardingSmtpAddress'
- 'ForwardingAddress'
- 'DeliverToMailboxAndForward'
condition: selection
falsepositives:
- Legitimate executive assistant or shared mailbox forwarding configured by admins
- Departing-employee mail handling
level: high
The following Sentinel hunt query surfaces the session-anomaly pattern at the heart of this campaign: successful interactive sign-ins to Office 365 workloads from residential ISP space, correlated with token/session events that look inconsistent with the user's baseline, plus follow-on mailbox rule and MFA changes.
// Hunt: AitM session hijack pattern - residential-IP sign-ins followed by mailbox manipulation
// Requires: SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, OfficeActivity (Unified Audit Log ingestion)
let Lookback = 14d;
let ResidentialKeywords = dynamic(["comcast", "att", "verizon", "charter", "spectrum", "cox", "lumen", "centurylink", "frontier", "optimum", "vodafone", "deutsche telekom", "bt group", "orange", "telefonica", "sky", "virgin media", "rogers", "telstra", "a1 telekom"]);
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(Lookback)
| where ResultType == 0
| where AppDisplayName has_any ("Office 365 Exchange Online", "Office 365 SharePoint Online", "Microsoft Teams", "OfficeHome")
| extend ISP_lower = tolower(NetworkLocationDetails)
| extend IsResidential = ISP_lower has_any (ResidentialKeywords)
| extend AuthDetail = tostring(AuthenticationDetails)
// Single-factor or claim-in-token auth (token replay often shows no fresh interactive MFA claim)
| where IsResidential == true
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
DistinctIPs=dcount(IPAddress), IPs=make_set(IPAddress),
Devices=make_set(DeviceDetail), UserAgents=make_set(UserAgent)
by UserPrincipalName, IPAddress
| where DistinctIPs >= 1;
SuspiciousSignins
| join kind=inner (
AuditLogs
| where TimeGenerated > ago(Lookback)
| where OperationName has_any ("Update user", "User registered security info", "Add service principal credentials")
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| project MFAChangeTime=TimeGenerated, OperationName, TargetUPN, InitiatedBy
) on $left.UserPrincipalName == $right.TargetUPN
| project UserPrincipalName, IPAddress, FirstSeen, LastSeen, IPs, UserAgents, MFAChangeTime, OperationName
| sort by LastSeen desc
;
// Secondary: inbox rules and forwarding created in the same window
OfficeActivity
| where TimeGenerated > ago(Lookback)
| where OfficeWorkload == "Exchange"
| where Operation in~ ("New-InboxRule", "Set-InboxRule", "Set-Mailbox")
| extend RuleParams = tostring(Parameters)
| where RuleParams has_any ("DeleteMessage", "MoveToFolder", "MarkAsRead", "Forward", "Redirect", "ForwardingSmtpAddress")
| project TimeGenerated, UserId, ClientIP, Operation, RuleParams
| sort by TimeGenerated desc
If a compromised session was used interactively from an endpoint, or you need to validate which local browser sessions and tokens exist on finance-team workstations during IR scoping, Velociraptor can hunt for anomalous processes and outbound connections to known AitM/phishing infrastructure patterns.
-- Hunt endpoints for processes and connections consistent with token theft tooling
-- and suspicious browser session artifacts following suspected AitM compromise
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(evilginx|modlishka|muraena|phishlet|-proxy|-phish)'
OR Name =~ '(?i)(evilginx|modlishka|muraena)'
-- Enumerate active outbound connections from browser processes to non-Microsoft
-- destinations for triage of session replay staging on finance-team endpoints
LET browser_procs = SELECT Pid, Name, Username
FROM pslist()
WHERE Name =~ '(?i)(msedge|chrome|firefox|brave)\\.exe'
SELECT n.Pid, n.Name, n.LocalAddr, n.LocalPort, n.RemoteAddr, n.RemotePort, n.Status
FROM netstat() AS n
JOIN browser_procs AS b ON n.Pid = b.Pid
WHERE n.RemoteAddr !~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.|127\\.)'
AND n.Status =~ '(?i)ESTABLISHED'
Remediation
There is no patch for this campaign — it exploits authentication architecture, not a software defect. Remediation is posture and response:
Immediate (if compromise is suspected):
- Revoke all sessions and refresh tokens for affected users. In the Microsoft 365 admin center or via Graph: revoke sign-in sessions, force password reset, and invalidate refresh tokens. Password reset alone is insufficient — the attacker holds a session token.
- Audit and remove attacker persistence: enumerate and delete newly registered MFA methods, inbox rules, mailbox forwarding, OAuth app consents, and added email addresses.
- Review Exchange message trace and Unified Audit Log for mailbox searches, eDiscovery activity, and mail egress touching payroll/finance keywords during the compromise window.
- Notify payroll/finance counterparts to freeze any pending wire or payroll changes requested over email during the exposure period; verify via out-of-band channels.
Hardening (the durable fix):
- Deploy phishing-resistant MFA — FIDO2 security keys or Windows Hello for Business — for all users, prioritizing finance, payroll, HR, and executives. TOTP and SMS MFA are precisely what AitM proxies defeat. Microsoft documentation: https://learn.microsoft.com/entra/identity/authentication/concept-fido2-compatibility
- Enforce Conditional Access token protection and compliant-device requirements: require token binding where supported, block legacy authentication outright, and require compliant/hybrid-joined devices for Exchange Online and SharePoint access.
- Disable legacy authentication tenant-wide (IMAP, POP3, SMTP AUTH) via authentication policies if not already done.
- Block external forwarding by default via Exchange outbound spam filter policy and alert on any exception.
- Tune sign-in detections: enable Microsoft Entra ID Protection risk policies (leaked credentials, anomalous token, unfamiliar sign-in properties) and route sign-in risk to require re-authentication.
- Train finance workflows, not just users: enforce out-of-band verification for any payroll diversion or payment instruction change, regardless of how legitimate the email thread appears — the attacker may be replying inside a genuine thread.
Containment Verification Script
Use the following PowerShell (with the Microsoft Graph PowerShell SDK) to enumerate and revoke attacker persistence artifacts on a suspected compromised account:
# Requires: Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All","Directory.Read.All","MailboxSettings.Read"
# Run under an admin context; replace $TargetUser with the affected UPN
$TargetUser = "jsmith@contoso.com"
# 1. Revoke all refresh tokens and sessions immediately
Revoke-MgUserSignInSession -UserId $TargetUser
# 2. Enumerate registered authentication methods for attacker-added factors
$AuthMethods = Get-MgUserAuthenticationMethod -UserId $TargetUser -All
$AuthMethods | ForEach-Object {
[PSCustomObject]@{
MethodId = $_.Id
MethodType = $_.AdditionalProperties.'@odata.type'
DisplayName = $_.AdditionalProperties.displayName
PhoneNumber = $_.AdditionalProperties.phoneNumber
CreatedDate = $_.AdditionalProperties.createdDateTime
}
} | Format-Table -AutoSize
# Remove unauthorized methods, e.g.:
# Remove-MgUserAuthenticationPhoneMethod -UserId $TargetUser -PhoneAuthenticationMethodId "<id>"
# 3. Audit mailbox rules and forwarding for exfiltration artifacts
Connect-ExchangeOnline
Get-InboxRule -Mailbox $TargetUser |
Select-Object Name, Description, Enabled, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder |
Format-List
Get-Mailbox -Identity $TargetUser |
Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward
# 4. Clear suspicious forwarding after evidence preservation
# Set-Mailbox -Identity $TargetUser -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false
# Get-InboxRule -Mailbox $TargetUser | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage } |
# ForEach-Object { Remove-InboxRule -Mailbox $TargetUser -Identity $_.RuleIdentity -Confirm:$false }
# 5. Verify legacy authentication is blocked tenant-wide
Get-MgPolicyAuthenticationMethodPolicy | Format-List
# Confirm Conditional Access policies block legacy auth: review in Entra portal under Protection > Conditional Access
This campaign is a reminder that MFA is a floor, not a ceiling. Attackers have industrialized session theft with residential proxy infrastructure that neutralizes network-layer controls. The organizations that stop this are the ones that bind tokens to devices, deploy phishing-resistant authentication for the people who move money, and detect the post-authentication behaviors — inbox rules, forwarding, MFA changes — that every AitM takeover produces.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.