DFIR Case Study - Microsoft 365 Account Takeover

Ten Days Inside a Compromised Tenant:
How a Microsoft 365 Account Takeover Became a Financial Fraud Attempt

A forensic reconstruction of a Microsoft 365 identity compromise - session token abuse, fraudulent internal accounts, directory role escalation, mailbox rule abuse and deliberate evidence deletion - investigated by ISECURION's DFIR team using Entra ID, Exchange Online, Unified Audit Log and SharePoint/OneDrive evidence.

Account Takeover Business Email Compromise Privilege Escalation
Contents
01Why M365 Account Takeover Is the Fastest-Growing DFIR Case Type
02Case Study: The Ten-Day Compromise Timeline
03Forensic Findings & Technical Analysis
04What the Evidence Could - and Could Not - Prove
05Root Cause & Remediation Delivered
06Key Lessons for Every M365 Tenant Owner
07Anatomy of a Session Token Attack
08Frequently Asked Questions

Why Microsoft 365 Account Takeover Is the Fastest-Growing DFIR Case Type

Microsoft 365 is the identity backbone of most modern organisations - email, files, collaboration and, increasingly, directory administration all sit behind a single sign-on. That concentration of trust is exactly why account takeover (ATO) inside Microsoft 365 tenants has become one of the most frequent and most damaging categories of incident ISECURION investigates.

Unlike a traditional network intrusion, a Microsoft 365 account takeover rarely involves malware at all. Once a session token or set of credentials is obtained, an attacker operates entirely inside Microsoft's own, fully legitimate workflows - reading mail through Outlook Web App, creating sharing links through SharePoint, assigning directory roles through Entra ID. Every action looks, on the surface, like ordinary user behaviour. That is precisely what makes these cases difficult to detect and forensically demanding to reconstruct.

The case study below documents a real ISECURION DFIR engagement: a Microsoft 365 tenant in which a single compromised, privileged account was used over ten days to create fraudulent internal identities, escalate privileges, generate sharing links on financial documents, send a fraudulent bank-detail email, and then deliberately delete the evidence of having done so.

10 Days
Between initial session persistence and full lateral expansion across three mailboxes
3
Mailboxes affected, including one secondarily compromised account and two attacker-created identities
0
Malware artefacts found - every attacker action used legitimate, authenticated Microsoft 365 workflows
High
Confidence in tenant compromise; low confidence in attributing the human operator, per ISECURION's evidence-based methodology

Because the fraudulent activity in this case involved a financial email and access to invoice documentation, it also intersects with CERT-In's mandatory 6-hour incident reporting window and, where personal or financial data is implicated, DPDP Act 2023 breach notification obligations. ISECURION is a CERT-In empanelled firm and builds regulatory reporting support into every DFIR engagement of this kind.

Case Study: Microsoft 365 Account Compromise, Identity Abuse & Attempted Wire Fraud

Investigation Report: Session Token Abuse, Fraudulent Identity Creation & Concealed Financial Fraud
Account Takeover / BEC
Engagement TypeMicrosoft 365 Forensic Investigation
Investigation Period05 - 15 Dec 2025
Accounts Affected3 Mailboxes
Evidence SourcesEntra ID, Exchange Online, UAL, SharePoint/OneDrive
SeverityHigh

Background & Discovery

ISECURION was engaged following internal reports of unauthorised email activity and a suspected financial fraud attempt inside a client's Microsoft 365 tenant. The engagement scope covered Microsoft Entra ID, Exchange Online, the Unified Audit Log, SharePoint Online and OneDrive for Business, with the investigation focused on three user mailboxes flagged for anomalous behaviour during the period.

Working strictly from authenticated, read-only log review - no modification, deletion or testing action was performed inside the live tenant at any point - ISECURION's forensic team reconstructed a ten-day chronology of attacker activity between 05 December and 15 December 2025, correlating identity, mailbox and file-access telemetry into a single evidence-backed timeline.

Endpoint (laptop/desktop) forensics, network firewall logs and determination of the precise initial infection vector were explicitly out of scope for this engagement - a constraint that shaped what the investigation could, and could not, conclusively establish (see Section 4).

Attack Timeline Reconstruction

Day 1 (05 Dec) - Session Persistence After Password Reset

A new Azure AD session token was issued for the primary mailbox immediately following a password change. Within roughly two hours, the MailItemsAccessed operation was logged against the same mailbox under that authenticated session - the attacker had already retained access through session token reuse rather than requiring the new password at all.

Day 5 (09 Dec) - Multi-Geography Session Reuse

The identical Azure AD session identifier was observed authenticating and accessing mailbox data from multiple, geographically inconsistent locations - browser sign-ins traced to Miami and New York, plus mobile/desktop client sign-ins from Ashburn, Virginia - all within a single short window, and all with MFA satisfied purely by claim in the reused token rather than a fresh interactive challenge.

Day 5 (09 Dec) - Fraudulent Internal Identity Creation & Privilege Escalation

Using the compromised account - which held Global Administrator privileges at the time - the attacker created two new internal Microsoft 365 user accounts. A directory role assignment then granted one of the new accounts elevated privileges, establishing a second, independent foothold in the tenant. The other newly created account was deleted shortly after, consistent with anti-forensic cleanup rather than a mistaken provisioning action.

Day 5 (09 Dec) - Secure Link Creation on Financial Documents

A SecureLinkCreated event was logged for an invoice document stored in OneDrive, generating a sharing link that extended access beyond the file owner. Multiple successful sign-ins from different IP addresses followed, and file access/download events were recorded from both Microsoft service ranges and non-Microsoft IP addresses - confirming the file was actively retrieved by a human session, not merely processed in the background by Microsoft's own services.

Day 6 (10 Dec) - Fraudulent Financial Email, Sent and Then Deleted

An internal email referencing a bank account update was submitted through an authenticated Outlook Web App session. The same message was subsequently pushed through MoveToDeletedItems, SoftDelete and HardDelete operations in sequence - a deliberate removal pattern, not routine mailbox hygiene. A near-identical email was sent externally from a second, secondarily compromised mailbox, again via authenticated OWA submission through the standard Microsoft 365 mail pipeline.

Day 8 (12 Dec) - Inbox Rule Deployment Across Three Mailboxes

Inbox rules were created on all three affected mailboxes via Exchange Online (OWA), automatically moving and suppressing messages - concealment behaviour typical of BEC operations, designed to hide replies from the legitimate account holders while the attacker corresponds on their behalf.

Attack Progression at a Glance

Stage 1
Session Persistence
Stage 2
Identity Creation & Privilege Escalation
Stage 3
Financial Document Access
Stage 4
Fraud Attempt & Evidence Deletion
Stage 5
Lateral Expansion via Inbox Rules

Forensic Investigation Findings

Technical Analysis and Correlation

Persistence after password reset. A password reset alone did not end the compromise: the session token issued at reset time was reused across subsequent authentications, meaning the attacker never needed the new password to keep operating inside the mailbox. This is a critical, frequently misunderstood gap - resetting a password without also revoking active refresh tokens and forcing tenant-wide sign-out leaves session-based access fully intact.

Authenticated access and deliberate evidence deletion. Because MailItemsAccessed and the subsequent fraudulent OWA-submitted email both required an authenticated session, and because the same message was later run through SoftDelete and HardDelete in sequence, the deletion cannot be explained as routine retention policy or accidental user action - it is a targeted attempt to erase the fraud trail.

Fraudulent identity creation and privilege assignment. Account creation and directory role assignment are authorisation-gated operations in Entra ID; they cannot be performed through mailbox access alone. Their presence in the log - paired with the selective deletion of one created account while the other persisted - demonstrates deliberate, technically competent identity manipulation rather than accidental misuse.

Share link creation and file retrieval. The SecureLinkCreated event on the invoice document, followed by file access and download activity from non-Microsoft IP ranges, confirms the document was not simply indexed by background Microsoft services but actively opened and pulled by a human-driven session.

Exclusion of email spoofing. Every fraudulent message in this case traced back through authenticated OWA submission and successful transport processing (SUBMIT → SEND → SENDEXTERNAL) with no evidence of spoofed headers or unauthorised SMTP relay. This distinction matters operationally: spoofing defences (SPF/DKIM/DMARC) would have done nothing to stop this attack, because the messages were sent from real, authenticated mailboxes.

Mailbox rule abuse as a distinct access path. Inbox rule creation on the third affected mailbox occurred without any corresponding Entra ID sign-in anomaly - indicating mailbox-level access (for example, via a compromised app password, delegated access, or a narrower token scope) rather than a full identity takeover of that account. This is an important nuance: not every affected mailbox in a lateral-movement case represents the same depth of compromise.

The most important finding wasn't any single action - it was the sequence. Session persistence, account creation, role assignment, fraud, and cleanup happened in that order, across ten days, using nothing but legitimate Microsoft 365 workflows. That is what deliberate, operationally aware attacker behaviour looks like inside a cloud identity platform.

- ISECURION DFIR Investigation Team

What the Evidence Could - and Could Not - Prove

A defensible forensic report is as clear about its limits as it is about its conclusions. ISECURION frames every finding in this case as either directly evidence-backed or an explicitly stated limitation - never an assumption dressed up as fact.

Established With High Confidence
  • When authenticated access occurred and which accounts were affected
  • That session tokens were issued and reused across sessions and geographies
  • That fraudulent accounts, role assignments and inbox rules were attacker-created
  • That deletion of financial email evidence was deliberate
  • That all sends used legitimate, authenticated Microsoft 365 paths - not spoofing
Could Not Be Determined From Available Logs
  • The initial credential or token capture technique (phishing, AiTM, or other)
  • The identity of the human operator behind the activity
  • Whether lateral movement extended beyond Microsoft 365 into on-premises systems
  • Endpoint-level artefacts, since device forensics was out of scope

Based on the totality of correlated evidence, ISECURION assessed high confidence that a malicious external actor compromised the tenant and abused valid authentication artefacts - grounded in token reuse across incompatible geographies, unauthorised identity and privilege changes, and clear anti-forensic behaviour. Confidence in identifying the specific human operator, or linking the activity to a named threat group, was assessed as low, given the absence of endpoint telemetry and the use of shared or proxied infrastructure that is common to abuse.

Root Cause & Remediation Delivered

Session token abuse was the mechanism by which access was maintained - it was not, by itself, the root cause. ISECURION's root cause analysis identified five underlying control gaps that, in combination, allowed the incident to unfold and persist for as long as it did:

  1. Inadequate session and token controls - lack of effective refresh-token revocation or short token lifetimes allowed reuse of tokens after password changes.
  2. Insufficient Conditional Access and device compliance enforcement - authenticated activity from unmanaged or geographically inconsistent devices occurred without being blocked.
  3. Weak visibility and detection for mailbox/role abuse - mailbox rule creation, role assignments and sharing-link creation were not sufficiently alerted on, allowing persistence and cover-up to go unnoticed.
  4. Over-privileged accounts with no separation of duties - the compromised account could both create identities and assign directory roles, with no secondary control to catch the abuse.
  5. Incomplete endpoint telemetry available to investigators - the absence of host-level logs limited how precisely the initial compromise vector could be confirmed.
Immediate Containment

Revocation of all active refresh tokens and forced sign-out tenant-wide; disabling of attacker-created accounts; removal of unauthorised role assignments and OAuth app consents; preservation of Unified Audit Log, mailbox audit and sign-in evidence with chain-of-custody documentation.

Short-Term Hardening

Credential rotation with mandatory MFA re-registration for all privileged accounts; Conditional Access enforcing device compliance and blocking legacy authentication; alerting on mailbox rule creation, mass deletion, new-user creation and role assignment events.

Long-Term Governance

Privileged Identity Management with just-in-time admin elevation; shortened token lifetimes with Continuous Access Evaluation; centralised SIEM correlation for token reuse across geographies; annual tabletop exercises.

Financial Process Controls

Mandatory out-of-band, telephone-based verification for any bank-detail or payment-instruction change received by email, regardless of apparent sender authority or urgency.

Because the fraudulent financial email was intercepted and the full sequence of attacker actions was reconstructed before funds were released, the client avoided a completed wire-fraud loss. The engagement produced a forensic report structured for internal leadership briefing, legal review and potential regulatory notification, alongside an immediate containment plan and a phased remediation roadmap covering identity, session and financial-process controls.

Key Lessons for Every Microsoft 365 Tenant Owner

1
A password reset alone does not end a compromise.
Session tokens issued before the reset can persist. Token revocation and forced sign-out must accompany every credential reset.
2
Privileged accounts need separation of duties.
A single compromised Global Administrator was able to create identities and assign roles unchecked. Just-in-time elevation limits this blast radius.
3
Inbox rules and role assignments deserve real-time alerts.
These are high-value, low-frequency admin actions - ideal candidates for anomaly detection, yet frequently unmonitored.
4
Out-of-band verification defeats BEC regardless of technical sophistication.
No email-based payment or bank-detail change should be actioned without a phone call to a known, pre-verified number.
5
Geography-inconsistent session reuse is a strong detection signal.
The same session identifier authenticating from incompatible locations within minutes is rarely legitimate and should trigger automatic step-up verification.
6
Deletion of evidence is itself evidence.
SoftDelete followed by HardDelete on a single, recently sent message is a distinctive forensic signature worth alerting on in its own right.

Anatomy of a Microsoft 365 Session Token Attack

This case is a representative example of a broader pattern ISECURION sees across Indian enterprises using Microsoft 365: attackers increasingly target the session, not just the password. Understanding the mechanics helps explain why traditional password-only defences fall short.

1
Token Acquisition

A session token or refresh token is obtained - via phishing, adversary-in-the-middle proxying, or malware-based theft. This case's investigation scope did not include the initial vector, but the effect is the same regardless of method: a working, authenticated session in the attacker's hands.

2
Persistence Through Reset

Because many organisations reset passwords without also revoking refresh tokens, a password change can feel like remediation while leaving the attacker's session fully functional.

3
Privilege Expansion

If the compromised account carries administrative rights, the attacker can create new identities and self-assign roles - manufacturing redundant access that survives even if the original account is disabled.

4
Monetisation & Cleanup

Financial fraud, data exfiltration via sharing links, or both - followed by targeted deletion of the messages and rules that would otherwise expose the operation.

Why this matters for detection: Every stage above is technically "authorised" activity from Microsoft 365's point of view - a valid session performing valid operations. Detecting this class of incident depends on behavioural correlation (impossible travel, new inbox rules, unusual role assignments) rather than signature-based malware detection, which is one reason these cases require specialist DFIR review rather than standard antivirus or EDR alerting alone.

Frequently Asked Questions: Microsoft 365 Account Takeover Investigations

Common questions ISECURION receives from CISOs and IT leaders after a suspected Microsoft 365 compromise.

A Microsoft 365 account takeover occurs when an unauthorised party gains authenticated access to a user's mailbox, identity, or session - typically through stolen credentials, phishing, adversary-in-the-middle proxying, or session token theft - and then uses that legitimate access to read mail, manipulate mailbox rules, access files, or perform administrative actions. Unlike malware-based intrusions, ATO activity uses Microsoft's own authorised workflows, which is what makes it difficult to detect with traditional security tooling.

A password reset invalidates the password itself, but not necessarily the session or refresh tokens that were already issued to an active login. If those tokens are not explicitly revoked - and the user is not forced to sign out everywhere - an attacker holding a valid token can continue operating exactly as this case study demonstrates. Effective remediation always pairs a password reset with tenant-wide session revocation (for example, Revoke-AzureADUserAllRefreshToken or its Microsoft Graph equivalent) and forced re-authentication.

Attackers commonly create inbox rules that silently forward, move, or delete incoming mail - most often to hide replies from a legitimate account holder while the attacker corresponds under their identity, or to route sensitive mail to an external address unnoticed. Because rule creation is a routine Exchange Online feature, it rarely triggers default alerting. ISECURION recommends explicit monitoring for new-inbox-rule events, particularly rules that move mail to rarely used folders or forward externally, as one of the highest-value, lowest-noise detections available in Microsoft 365.

Usually not with high confidence, and ISECURION is deliberately conservative on this point. Microsoft 365 logs can establish with strong confidence that a tenant was compromised, which accounts and actions were involved, and when events occurred. They rarely provide the endpoint-level or network-level artefacts needed to attribute activity to a specific human or named threat group, especially when attackers use shared cloud infrastructure or proxy services. ISECURION's reports separate these two confidence levels explicitly rather than overstating attribution.

ISECURION's standard evidence sources for this case type include:

  • Microsoft Entra ID (Azure AD): interactive and non-interactive sign-in logs, audit logs, session and token-related events
  • Exchange Online: mailbox audit logs, inbox rule creation/modification events, message deletion operations (MoveToDeletedItems, SoftDelete, HardDelete)
  • Unified Audit Log (UAL): cross-workload correlation of identity, mailbox and file-access events
  • SharePoint Online and OneDrive for Business: file access, download, and sharing-link creation activity
  • Message Trace and transport logs: internal/external delivery paths, submission validation, and originating client IP analysis

Where relevant and available, endpoint and network logs supplement this picture, though Microsoft 365 telemetry alone is frequently sufficient to reconstruct the full scope and timeline of an incident.

Message trace data records the full submission path of an email, including whether it passed through authenticated Outlook Web App or client submission versus arriving via external SMTP relay with spoofed headers. In this case, every fraudulent message showed a clean SUBMIT → SEND → SENDEXTERNAL path with no header anomalies - conclusively confirming authenticated mailbox access rather than spoofing. This distinction is operationally important because SPF, DKIM and DMARC (which defend against spoofing) offer no protection against fraud sent from a genuinely compromised, authenticated account.

Based on patterns from this and similar engagements, ISECURION recommends the following immediate containment sequence:

  1. Revoke refresh tokens and force tenant-wide sign-out for the affected account(s) and any admin accounts.
  2. Disable any recently created, unrecognised user accounts and review directory role assignments made during the suspected window.
  3. Remove any suspicious OAuth app consents granted during the same period.
  4. Export and preserve Unified Audit Log, Exchange mailbox audit, message trace, Entra ID sign-in, and SharePoint/OneDrive audit data before taking further remediation action, to protect the forensic record.
  5. Engage a DFIR specialist before assuming the incident is contained - deletion of malicious mail and disabling of one account does not guarantee full eviction if role assignments or secondary accounts were created.

Potentially, yes. CERT-In's 2022 directions require reporting of specified categories of cyber incidents - including unauthorised access and data breaches - within 6 hours of detection. Where the compromised mailboxes or accessed documents contain personal data, the DPDP Act 2023 may separately require notification to the Data Protection Board of India and affected individuals. Whether either obligation is triggered depends on the specific data involved and the nature of confirmed unauthorised access; ISECURION assesses this on a case-by-case basis and can support the notification process directly.

Classic BEC cases usually involve compromise or spoofing of a single executive or financial mailbox to redirect a payment. This case exhibits BEC-style financial fraud (a fraudulent bank-detail email) but goes further: the attacker also escalated privileges at the directory level, created durable secondary identities, and expanded laterally into additional mailboxes. It sits at the intersection of account takeover and BEC - which is why ISECURION's investigation scope extended beyond Exchange Online into Entra ID identity and role-assignment logs, not just message trace data.

This engagement's forensic review covered a ten-day incident window and was completed and reported within approximately three weeks, in line with ISECURION's typical timeframe for a focused, multi-mailbox Microsoft 365 investigation. Timelines scale with the number of affected accounts, the volume of log data available for the investigation period, and whether endpoint or network evidence must also be incorporated. Retainer clients receive priority scheduling and pre-agreed response SLAs.

Suspect a similar incident in your own tenant? Contact ISECURION's DFIR team at info@isecurion.com or submit an enquiry - we respond to all pre-incident and active-incident queries promptly.

Related ISECURION Services

BEC & Email Forensics

Investigation of business email compromise, fraudulent wire transfers and mailbox rule abuse.

Cloud & M365 Forensics

Entra ID, Exchange Online, SharePoint, OneDrive and Teams forensic investigation.

VAPT Services

Proactive testing to identify the gaps that make account takeover possible before an attacker finds them.

DPDP Act Compliance

Breach notification readiness and compliance support under India's Digital Personal Data Protection Act 2023.

Suspect an Account Compromise in Your Microsoft 365 Tenant?

ISECURION's DFIR team investigates identity, mailbox and file-access activity across Entra ID, Exchange Online, SharePoint and OneDrive - with evidence-based findings you can act on within hours, not weeks.

Request Incident Response Consultation

This case study is based on an ISECURION DFIR engagement. Client-identifying details have been redacted or generalised in accordance with our confidentiality obligations.