CasesCASE-003

SOC investigation

Trusted SharePoint Link Leads to Session Hijack and BEC

A trusted SharePoint lure led to AiTM session theft, mailbox concealment, and follow-on phishing from the compromised identity.

Based on publicly reported attack activity. User identities and workstation names have been anonymized.

User: denis@example.com
Initial alert: Suspicious cloud sign-in after a SharePoint phishing click
Severity: High

Case story

What happened

A SharePoint-style lure from a trusted organization led into an AiTM authentication path. The compromised identity was later used from another IP, an Inbox rule concealed incoming mail, and the account sent more than 600 follow-on phishing messages.

Initial message
Trusted sender delivers a SharePoint lure
A phishing message arrived from an address belonging to a trusted organization and used a SharePoint document-sharing workflow.
After the click
User follows the SharePoint link
The link redirected the user toward the credential and AiTM path.
Later sign-in
Suspicious cloud session appears
The attacker later accessed the compromised identity from another IP address.
After sign-in
Mailbox concealment is added
An Inbox rule was created to delete incoming mail and mark messages as read.
Follow-on activity
Compromised identity becomes a phishing sender
More than 600 phishing messages were sent to internal and external recipients.
During the campaign
Attacker manages warning messages and replies
NDR, out-of-office, and authenticity-question messages were monitored, answered where useful, and deleted.

Investigation

What was checked

Follow how the analyst tested and revised explanations. This is discovery order, not event chronology.

01
Trace the phishing message
The source campaign used trusted-sender context and a SharePoint document-sharing lure; Microsoft published the hunting subject NEW PROPOSAL – NDA.
Next pivot
Use the message identifier and recipient to recover URL-click activity.
View query
Q-01
Find the source campaign message
What this checks
Find source-campaign messages delivered to denis@example.com and preserve the message identifiers needed for click correlation.
KQL
let target_user = "denis@example.com"; let lookback = 7d; EmailEvents | where Timestamp >= ago(lookback) | where RecipientEmailAddress =~ target_user | where Subject has "NEW PROPOSAL" and Subject has "NDA" | project Timestamp, NetworkMessageId, InternetMessageId, SenderFromAddress, SenderMailFromAddress, SenderDisplayName, SenderFromDomain, SenderIPv4, RecipientEmailAddress, Subject, EmailDirection, DeliveryAction, DeliveryLocation, LatestDeliveryAction, LatestDeliveryLocation, ThreatTypes, AuthenticationDetails, UrlCount, AttachmentCount | order by Timestamp asc
SPL
index=<m365_email_index> sourcetype=<email_events_sourcetype> earliest=-7d | eval recipient=lower(coalesce(recipient, RecipientEmailAddress)), sender=lower(coalesce(sender, SenderFromAddress, SenderMailFromAddress)), subject=coalesce(subject, Subject), message_id=coalesce(message_id, NetworkMessageId), internet_message_id=coalesce(internet_message_id, InternetMessageId), delivery_action=coalesce(delivery_action, LatestDeliveryAction, DeliveryAction), delivery_location=coalesce(delivery_location, LatestDeliveryLocation, DeliveryLocation), threat_types=coalesce(threat_types, ThreatTypes) | where recipient="denis@example.com" | where like(subject, "%NEW PROPOSAL%") AND like(subject, "%NDA%") | fields _time message_id internet_message_id sender recipient subject delivery_action delivery_location threat_types | sort 0 _time
What to look for
A message record with sender and delivery context plus NetworkMessageId for the click pivot.
Technical details
Tested signal
A source-scoped phishing subject delivered to the affected identity.
Assumptions
Defender for Office 365 EmailEvents is available or equivalent mail-security telemetry is mapped.
The Microsoft hunting subject is source-scoped to this campaign and is not treated as a universal AiTM indicator.
Data requirements and relevant fields
email
Message-level mail telemetry with sender, recipient, subject, delivery, threat, and message identifiers.
Timestamp
NetworkMessageId
InternetMessageId
SenderFromAddress
SenderMailFromAddress
SenderDisplayName
SenderFromDomain
SenderIPv4
RecipientEmailAddress
Subject
EmailDirection
DeliveryAction
DeliveryLocation
LatestDeliveryAction
LatestDeliveryLocation
ThreatTypes
AuthenticationDetails
UrlCount
AttachmentCount
KQL schema
Uses documented EmailEvents fields. Microsoft Defender for Office 365 is required.
SPL schema
Replace index, sourcetype, and field aliases with the local mail-security source. Keep message_id available for the next pivot.
Limitations
Subject matching can miss modified lure text.
A trusted sender identity can itself be compromised, so sender reputation cannot close the investigation.
KQL uses Defender for Office 365 EmailEvents. SPL uses a raw normalized mail-security scaffold because message IDs are not guaranteed by Email CIM mappings.
More reasoning
Observation
A SharePoint-style message from a trusted organization preceded the compromise.
Working explanation
The affected identity may have received a campaign message whose identifiers can anchor click correlation.
What was checked
Find the source message, sender context, delivery state, embedded-link count, and NetworkMessageId.
Interpretation
The message should be treated as the starting evidence object, while the sender's apparent trust must not be treated as proof of legitimacy.
Supporting evidence
E-01
02
Check the URL click
The source reporting establishes that recipients who clicked were redirected toward the attacker-controlled authentication path, while the original landing domain remains unpublished.
Next pivot
Correlate the click time and user with successful browser sign-ins.
View query
Q-02
Recover the user's email clicks
What this checks
List email-origin Safe Links clicks for denis@example.com and expose the URL, redirect chain, source IP, and message identifier.
KQL
let target_user = "denis@example.com"; let lookback = 7d; UrlClickEvents | where Timestamp >= ago(lookback) | where Workload == "Email" | where AccountUpn =~ target_user | project Timestamp, AccountUpn, Url, UrlChain, ActionType, IsClickedThrough, ThreatTypes, DetectionMethods, IPAddress, NetworkMessageId, ReportId, AppName | order by Timestamp asc
SPL
index=<m365_security_index> sourcetype=<url_click_events_sourcetype> earliest=-7d | eval user=lower(coalesce(user, AccountUpn, account_upn)), url=coalesce(url, Url), url_chain=coalesce(url_chain, UrlChain), action=coalesce(action, ActionType), click_src=coalesce(src, IPAddress, ip_address), message_id=coalesce(message_id, NetworkMessageId, network_message_id), workload=coalesce(workload, Workload), threat_types=coalesce(threat_types, ThreatTypes) | where user="denis@example.com" AND lower(workload)="email" | fields _time user click_src action url url_chain message_id threat_types | sort 0 _time
What to look for
A relevant click with redirect-chain and source-IP context that can be compared with the next sign-in.
Technical details
Tested signal
Email-origin URL-click telemetry for the affected identity.
Assumptions
Safe Links click telemetry is retained for the reviewed period.
NetworkMessageId correlation can be incomplete for Draft or Sent click scenarios.
Data requirements and relevant fields
network
Safe Links click telemetry with user, URL, redirect chain, action, source IP, and message ID.
Timestamp
Url
ActionType
AccountUpn
Workload
NetworkMessageId
ThreatTypes
DetectionMethods
IPAddress
IsClickedThrough
UrlChain
ReportId
AppName
KQL schema
Uses documented UrlClickEvents fields. Safe Links / Defender for Office 365 telemetry is required.
SPL schema
Replace index and sourcetype placeholders with the local click-telemetry source and preserve message_id/url_chain where available.
Limitations
A click does not prove credential submission or session theft.
Safe Links and equivalent products can rewrite or mediate the URL path.
KQL uses UrlClickEvents. SPL is a raw normalized scaffold because Safe Links-specific message and redirect-chain fields are not standardized in CIM.
More reasoning
Observation
The message contained the link path that moved the recipient toward the AiTM flow.
Working explanation
Safe Links or equivalent click telemetry may preserve the clicked URL, redirect chain, source IP, and message identifier.
What was checked
Review email-origin clicks for denis@example.com and preserve UrlChain and NetworkMessageId.
Interpretation
The click establishes exposure; the redirect chain and source IP become the next local pivots when retained.
Supporting evidence
E-01
E-02
03
Reconstruct post-click sign-ins
Microsoft reported attacker access from another IP after the phishing sequence.
Next pivot
Check Exchange Online for mailbox-rule or concealment activity after the suspicious session.
View query
Q-03
Reconstruct sign-ins around the compromise
What this checks
Return successful browser sign-ins for denis@example.com with source, risk, device-trust, and session context needed to assess suspected AiTM replay.
KQL
let target_user = "denis@example.com"; let lookback = 7d; EntraIdSignInEvents | where Timestamp >= ago(lookback) | where AccountUpn =~ target_user | where ErrorCode == 0 | where ClientAppUsed == "Browser" | project Timestamp, AccountUpn, Application, ResourceDisplayName, IPAddress, Country, State, City, UserAgent, Browser, DeviceName, OSPlatform, DeviceTrustType, IsManaged, IsCompliant, AuthenticationRequirement, RiskLevelDuringSignIn, RiskLevelAggregated, RiskEventTypes, RiskState, ConditionalAccessStatus, SessionId, UniqueTokenId, GatewayJA4 | order by Timestamp asc
SPL
index=<identity_index> sourcetype=<entra_signin_sourcetype> earliest=-7d | eval user=lower(coalesce(user, AccountUpn, user_principal_name)), src=coalesce(src, IPAddress, ip_address), app=coalesce(app, Application, ResourceDisplayName), browser=coalesce(browser, Browser), user_agent=coalesce(user_agent, UserAgent), device=coalesce(device, DeviceName), session_id=coalesce(session_id, SessionId), error_code=tonumber(coalesce(ErrorCode, error_code)), risk_level=tonumber(coalesce(RiskLevelDuringSignIn, RiskLevelAggregated, risk_level)), risk_state=tonumber(coalesce(RiskState, risk_state)), is_managed=tonumber(coalesce(IsManaged, is_managed)), is_compliant=tonumber(coalesce(IsCompliant, is_compliant)) | where user="denis@example.com" AND error_code=0 | fields _time user src app browser user_agent device session_id risk_level risk_state is_managed is_compliant | sort 0 _time
What to look for
A post-click sign-in whose source, risk, device-trust, or session context is inconsistent with the expected user activity.
Technical details
Tested signal
Successful browser authentication after the phishing click.
Assumptions
Microsoft Entra ID P2 EntraIdSignInEvents is available or equivalent identity telemetry is mapped.
Expected VPN, secure-web-gateway, VDI, mobile, and roaming behavior is understood before source changes are escalated.
Data requirements and relevant fields
authentication
Successful browser sign-ins with identity, application, source, risk, device-trust, and session fields.
Timestamp
Application
ErrorCode
SessionId
AccountUpn
ResourceDisplayName
DeviceName
OSPlatform
DeviceTrustType
IsManaged
IsCompliant
AuthenticationRequirement
RiskLevelAggregated
RiskLevelDuringSignIn
RiskEventTypes
RiskState
UserAgent
ClientAppUsed
Browser
ConditionalAccessStatus
IPAddress
Country
State
City
GatewayJA4
UniqueTokenId
KQL schema
Uses EntraIdSignInEvents, which requires Microsoft Entra ID P2. The table supersedes AADSignInEventsBeta for new content.
SPL schema
Map the local Entra sign-in source into user, src, app, session, risk, managed, and compliant fields before investigation.
Limitations
Different IP addresses are common with VPN, mobile, proxy, VDI, and secure web gateways.
Successful MFA does not prove the resulting session is trustworthy, but it also does not independently prove AiTM.
KQL uses EntraIdSignInEvents. SPL requires local Entra field normalization; identity-risk and device-trust fields are vendor-specific.
More reasoning
Observation
The attacker later used the compromised identity from another IP address.
Working explanation
Post-click authentication may show a materially different source, device-trust, risk, or session context.
What was checked
Review successful browser sign-ins with source, device, risk, session, browser, and resource context.
Interpretation
IP change alone is not proof of AiTM because VPN, mobile, VDI, and secure web gateways can alter egress. The sign-in must be judged with independent risk and device/session context.
Supporting evidence
E-03
04
Check mailbox concealment
The source campaign created an Inbox rule that deleted incoming messages and marked them as read.
Next pivot
Scope outbound and intra-organization mail from the compromised identity and identify every exposed recipient.
View query
Q-04
Find Inbox-rule changes
What this checks
Find Exchange Online mailbox-rule operations for denis@example.com and preserve source IP, object, and rule parameters.
KQL
let target_user = "denis@example.com"; let lookback = 7d; CloudAppEvents | where Timestamp >= ago(lookback) | where Application == "Microsoft Exchange Online" | where AccountId =~ target_user | where ActionType in ( "Set-Mailbox", "New-InboxRule", "Set-InboxRule", "UpdateInboxRules" ) | project Timestamp, AccountId, AccountObjectId, ActionType, IPAddress, CountryCode, City, Isp, UserAgent, ActivityType, ObjectName, ObjectType, RuleConfig = RawEventData.Parameters, RawEventData | order by Timestamp asc
SPL
index=<m365_audit_index> sourcetype=<exchange_audit_sourcetype> earliest=-7d | eval user=lower(coalesce(user, UserId, AccountId, account_id)), operation=coalesce(Operation, action, ActionType), src=coalesce(ClientIP, src, src_ip, IPAddress), object=coalesce(ObjectId, ObjectName, object, object_id), parameters=coalesce(Parameters, parameters) | where user="denis@example.com" | where in(operation, "New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Set-Mailbox" ) | fields _time user src operation object parameters | sort 0 _time
What to look for
A new or modified mailbox rule that deletes, hides, moves, or forwards mail and aligns with suspicious identity activity.
Technical details
Tested signal
Mailbox-rule creation or modification after suspected session compromise.
Assumptions
CloudAppEvents or equivalent Microsoft 365 audit telemetry is available.
AccountId may require object-ID mapping in tenants where it does not contain a UPN.
Data requirements and relevant fields
saas audit
Exchange Online audit activity with identity, action, source, object, and rule parameters.
Timestamp
ActionType
Application
AccountObjectId
AccountId
IPAddress
CountryCode
City
Isp
UserAgent
ActivityType
ObjectName
ObjectType
RawEventData
KQL schema
If AccountId is represented as object ID, resolve the target AccountObjectId and filter on that field.
SPL schema
Map Exchange audit Operation/ActionType, UserId/AccountId, ClientIP/IPAddress, object, and parameters to local fields.
Limitations
Legitimate users and administrators can create Inbox rules.
AccountId representation and rule-parameter visibility vary by connector and tenant.
KQL uses CloudAppEvents and documented Exchange Online ActionType values. SPL uses a raw Microsoft 365 audit scaffold.
More reasoning
Observation
The compromised identity showed post-authentication mailbox manipulation.
Working explanation
The attacker may have created or modified Inbox rules to hide messages that could expose the compromise.
What was checked
Review Exchange Online mailbox-rule operations for the affected identity and preserve source IP and rule parameters.
Interpretation
The rule is strong post-compromise evidence when it aligns with the suspicious identity session and has no approved business explanation.
Supporting evidence
E-03
E-04
05
Determine BEC and follow-on impact
Microsoft reported more than 600 phishing messages and active management of NDR, out-of-office, and authenticity-question messages.
Next pivot
Start the wider-environment AiTM hunt across recipients, clickers, sign-ins, mailbox rules, and follow-on senders.
View query
Q-05
Review follow-on mail from the compromised identity
What this checks
Summarize outbound and intra-organization mail from denis@example.com to measure recipient scale and subject reuse after compromise.
KQL
let target_user = "denis@example.com"; let lookback = 7d; EmailEvents | where Timestamp >= ago(lookback) | where SenderFromAddress =~ target_user | where EmailDirection in ("Outbound", "Intra-org") | summarize MessageEvents=count(), UniqueRecipients=dcount(RecipientEmailAddress), FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Recipients=make_set(RecipientEmailAddress, 100), Subjects=make_set(Subject, 30) by SenderFromAddress, EmailDirection | order by UniqueRecipients desc
SPL
| tstats summariesonly=t allow_old_summaries=t count min(_time) as first_seen max(_time) as last_seen values(Email.recipient) as recipients values(Email.subject) as subjects values(Email.action) as actions from datamodel=Email.All_Email where Email.sender="denis@example.com" by Email.sender | rename Email.sender as sender | eval recipient_count=mvcount(recipients) | table first_seen last_seen sender recipient_count recipients subjects actions count | sort - recipient_count
What to look for
A sudden expansion in recipients or repeated lure subjects that identifies users requiring click and sign-in review.
Technical details
Tested signal
Unexpected high-volume or campaign-like sending from the compromised identity.
Assumptions
Outbound and intra-organization message telemetry is retained.
Recipient count must be compared with the user's normal role and legitimate bulk-mail workflows.
Data requirements and relevant fields
email
Message telemetry with sender, recipient, direction, subject, threat verdict, and timestamp.
Timestamp
SenderFromAddress
RecipientEmailAddress
Subject
EmailDirection
ThreatTypes
KQL schema
Uses documented EmailEvents sender, recipient, subject, direction, threat, and timestamp fields.
SPL schema
Requires mail telemetry mapped to Email.All_Email. Validate whether the local model distinguishes outbound and intra-organization mail.
Limitations
Legitimate distribution-list or business communications can create high recipient counts.
The Microsoft-reported total of more than 600 messages is a source fact, not a universal detection threshold.
KQL uses EmailEvents. SPL uses Email CIM for portable sender-to-recipient scoping; local direction fields can be added when available.
More reasoning
Observation
The compromised identity was used as a trusted phishing sender and the attacker actively managed mailbox responses.
Working explanation
A single session compromise may have exposed a wider recipient population and created additional compromised identities.
What was checked
Measure outbound and intra-organization sending, identify recipients and subject reuse, and pivot recipients into click telemetry.
Interpretation
The investigation must expand from the original identity to recipients, clickers, and later suspicious sessions rather than stopping after credential reset.
Supporting evidence
E-05
E-06

Response

Actions to take

Contain affected systems, preserve evidence, and scope the same behavior elsewhere.

Revoke active sessions and tokens for denis@example.com.
Reset the password after session revocation.
Review and remove attacker-added or modified MFA authentication methods.
Remove suspicious Inbox and mailbox rules.
Review sign-ins, mailbox access, message deletion, sent mail, and cloud activity.
Purge related phishing messages where supported.
Identify every internal and external recipient of follow-on phishing.
Hunt every recipient who clicked the follow-on lure.
Block the confirmed source-scoped attacker infrastructure.
Require phishing-resistant MFA where feasible.

Conclusion

What was concluded

A trusted SharePoint-style message did not end as an email problem. The user followed the link into an adversary-in-the-middle authentication path, the compromised identity was later used from another IP address, and the mailbox was modified to suppress warning messages.

The same trusted identity then became a new phishing sender. Microsoft reported more than 600 follow-on phishing messages and active management of delivery notifications and authenticity questions. This portfolio Case follows that publicly reported sequence without inventing the unpublished landing domain or exact victim timestamps.

Technical detail

Technical evidence

Stable evidence anchors preserve the fields behind the investigation story.

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Email
Timestamp: Not applicable

The phishing message originated from an address at a trusted organization and used a SharePoint-style document-sharing workflow.

Account: denis@example.com
Subject hunt: NEW PROPOSAL – NDA
Delivery context: Trusted-organization sender and SharePoint lure

Referenced by

Step 01
Step 02

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Network
Timestamp: Not applicable

Recipients who followed the SharePoint link were redirected toward the attacker-controlled authentication path.

Workload: Email / SharePoint-style link
Landing domain: Not published by Microsoft
Analyst pivot: Recover URL and redirect chain from retained click telemetry

Referenced by

Step 02

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Authentication
Timestamp: Not applicable

Microsoft reported that the attacker later signed in to the compromised identity from another IP address.

Account: denis@example.com
Reported infrastructure: 178[.]130[.]46[.]8; 193[.]36[.]221[.]10
Session context: Post-phishing cloud sign-in

Referenced by

Step 03
Step 04

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Saas Audit
Timestamp: Not applicable

The attacker created an Inbox rule that deleted incoming messages and marked them as read.

Account: denis@example.com
Mailbox action: Inbox rule created
Concealment: Delete incoming mail and mark messages as read

Referenced by

Step 04

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Email
Timestamp: Not applicable

The compromised identity sent more than 600 phishing messages to internal and external recipients selected from recent mailbox activity.

Account: denis@example.com
Reported volume: More than 600 phishing emails
Recipient sources: Recent threads, contacts, internal and external users, and distribution lists

Referenced by

Step 05

Source: Microsoft January 2026 SharePoint AiTM/BEC campaign
Telemetry class: Email
Timestamp: Not applicable

The attacker monitored delivery notifications and authenticity questions, deleted messages, and replied where useful to preserve the phishing operation.

Account: denis@example.com
Monitored messages: NDR, out-of-office, and authenticity questions
Operator behavior: Read, reply where useful, and delete

Referenced by

Step 05

Detection engineering

Would your SOC catch this behavior?

See the detection built for this investigation.

View detection

Behavior context

ATT&CK and sources

Behavior mapping

MITRE ATT&CK

T1566.002 · Spearphishing LinkEnterprise ATT&CK 19.2
The reported campaigns delivered phishing links through trusted or convincing email and collaboration workflows.
T1204.001 · Malicious LinkEnterprise ATT&CK 19.2
Compromise depended on a recipient following a malicious or attacker-controlled link path.
T1539 · Steal Web Session CookieEnterprise ATT&CK 19.2
AiTM infrastructure captured authenticated session material that could be replayed after MFA completed.
T1078.004 · Cloud AccountsEnterprise ATT&CK 19.2
The attacker reused the compromised cloud identity to access Microsoft 365 resources.
T1114.002 · Remote Email CollectionEnterprise ATT&CK 19.2
The source campaign used mailbox content and recent threads to select recipients and manage follow-on phishing.

These mappings describe the behavior examined here. They do not establish attribution.

Review boundary

Sources and limits

Last reviewed: Aug 29, 2026
External sources: 1

This case documents the available evidence and analytical limits; control effectiveness is environment-specific.

Resurgence of a multi-stage AiTM phishing and BEC campaign abusing SharePointMicrosoft Security

Sections

What happened
Investigation
Actions
Conclusion
Evidence
Detection
Context

What happened

Trusted sender delivers a SharePoint lure

User follows the SharePoint link

Suspicious cloud session appears

Mailbox concealment is added

Compromised identity becomes a phishing sender

Attacker manages warning messages and replies

What was checked

Next pivot

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

Observation

Working explanation

What was checked

Interpretation

Next pivot

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

Observation

Working explanation

What was checked

Interpretation

Next pivot

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

Observation

Working explanation

What was checked

Interpretation

Next pivot

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

Observation

Working explanation

What was checked

Interpretation

Next pivot

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

Observation