Threat Actors Leverage SharePoint Services in Sophisticated AiTM Phishing Campaign

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
910
4,299
2,168
Germany
Microsoft Defender researchers have exposed a sophisticated adversary-in-the-middle (AiTM) phishing campaign targeting energy sector organizations through SharePoint file-sharing abuse.
The multi-stage attack compromised multiple user accounts and evolved into widespread business email compromise (BEC) operations across several organisations.
Initial Compromise Through Trusted Vendor
The attack began with phishing emails sent from a compromised trusted vendor’s email address. Threat actors leveraged SharePoint URLs requiring authentication, mimicking legitimate document-sharing workflows to evade suspicion.
Attackers exploited the widespread trust in Microsoft SharePoint and OneDrive services, which are ubiquitous in enterprise environments and frequently bypass traditional email security filters.
Read more here:
 
Read more here:
This matches a common (and effective) modern pattern: attackers abuse trusted infrastructure (a real vendor mailbox + Microsoft SharePoint/OneDrive links) to get users to authenticate into a fake Microsoft sign-in flow, then pivot into account takeover and BEC.

Why SharePoint/OneDrive links help attackers
  • Many organizations implicitly trust microsoft.com/sharepoint.com/onedrive.live.com-style URLs, so users are less suspicious.
  • Email gateways may be more permissive with these “business” domains, especially when the sender is a real (but compromised) vendor.
  • AiTM (“adversary-in-the-middle”) kits can steal credentials and also capture session tokens/cookies, which can let attackers bypass some MFA methods and immediately access mailboxes.

High-impact mitigations (most important first)
  • Use phishing-resistant MFA where possible (FIDO2 security keys / Windows Hello for Business / passkeys). AiTM is far less effective against these than OTP/push-based MFA.
  • Conditional Access hardening (Microsoft Entra ID): require compliant device, trusted location/risk-based policies, and block legacy authentication.
  • Tighten external sharing controls for SharePoint/OneDrive: reduce “anyone links,” require sign-in, limit external domains, set link expirations, and review guest access.
  • Defender for Office 365 controls (if available): Safe Links/Safe Attachments, anti-phishing policies, and impersonation protection—treat “trusted platform link” as not automatically safe.
  • Disable/limit user OAuth consent (or require admin approval). Some campaigns pivot by tricking users into granting malicious app consent after sign-in.

Detection and response priorities (when you suspect this happened)
  • In Entra ID sign-in logs: look for unusual IPs/locations, unfamiliar device identifiers, repeated MFA prompts, “token replay”/atypical session behavior, or sign-ins shortly after link-click events.
  • In Exchange/Defender: check for new inbox rules, forwarding to external addresses, new OAuth apps, and changes to mailbox permissions.
  • Immediate containment: reset password, revoke sessions/refresh tokens, remove malicious rules/forwarders, review MFA methods, and rotate any exposed credentials.
  • BEC controls: enforce out-of-band payment verification, and ensure SPF/DKIM/DMARC are deployed to reduce spoofing and improve detection.

Practical user guidance (works even in well-secured orgs)
  • Treat “SharePoint document shared” emails from vendors as high risk if the request is unexpected—verify via a known-good channel.
  • Be wary of sign-in pages reached from email links; prefer accessing SharePoint/Office via bookmarks/known portals.

If this is being discussed as a real incident, the safest next step is to follow your incident-response playbook: confirm the initial compromised vendor communication path, identify affected accounts, revoke sessions, and check for BEC persistence (rules/forwarding/payment fraud) before normal operations resume.
 
The campaign follows a multi-stage execution flow designed to evade traditional email security filters and maintain stealth.

Initial Vector
Phishing emails are dispatched from compromised accounts of trusted vendors. These emails contain SharePoint URLs that require authentication, mimicking standard corporate document-sharing workflows to lower victim suspicion.

Adversary-in-the-Middle (AiTM) Proxying
Victims are directed to a proxy server that mirrors a legitimate Microsoft 365 login page. When credentials and MFA codes are entered, the attacker intercepts the session cookie in real-time.

Stealth & Persistence
Upon successful session takeover, threat actors immediately implement automated inbox rules to delete incoming security alerts and mark messages as "read". They actively monitor mailboxes to delete "Out of Office" notifications and undelivered reports to prevent detection.

Expansion
Using the compromised account, attackers launch secondary phishing campaigns—sometimes exceeding 600 emails—to internal and external contacts found in the victim's inbox history.

Infrastructure Indicators

178.130.46[.]8
(Attacker infrastructure)

193.36.221[.]10
(Attacker infrastructure)

Recommendation / Remediation​

Standard password resets are insufficient for AiTM attacks as the stolen session cookie remains valid. Follow this prioritized pl

Session Invalidation
Revoke all active session tokens for compromised users via the Microsoft 365 Admin Center to terminate the attacker's current access.

MFA Audit
Inspect and reset MFA settings. Attackers often register their own phone numbers or devices as backup MFA methods to maintain long-term access.

Inbox Rule Scrubbing
Manually review and delete all "delete" or "move to folder" rules created after the initial compromise timestamp.

Phishing-Resistant MFA
Shift to FIDO2-based hardware keys or certificate-based authentication (NIST SP 800-63B). Traditional SMS or app-based OTPs are vulnerable to the proxying techniques used in this campaign.

Conditional Access (CA)
Implement CA policies that evaluate device compliance, IP reputation, and geographic location to block sign-ins from known malicious infrastructure like the IPs listed above.

References​

Cybersecurity News
(Jan 2026)

NIST SP 800-63B
(Digital Identity Guidelines).

SANS Institute
"Defending Against Adversary-in-the-Middle (AiTM) Phishing."
 
Last edited: