What happens when Microsoft 365 attacks succeed before the logs reveal them?

Why Detection Lag Changes the Shape of a Microsoft 365 Incident

When an attacker can operate inside Microsoft 365 before logs expose the activity, the issue is no longer just “was access obtained?” It becomes “what changed while defenders were blind?” Mailbox manipulation, inbox rule creation, consent abuse, and permission changes can all create durable access paths that remain useful even after the original entry point is closed. The delay matters because the most valuable evidence may already be overwritten, aged out, or spread across multiple audit surfaces by the time the alert arrives. Microsoft guidance on investigating suspicious activity in Microsoft 365 and MITRE ATT&CK Enterprise Matrix both reflect that post-compromise actions often matter as much as initial access.

In practice, many security teams discover the compromise only after the attacker has already converted short-lived access into a more persistent operational foothold.

How It Works in Practice

In Microsoft 365, logging lag creates a blind window between attacker action and defender visibility. During that window, the attacker may read mail, create forwarding rules, add OAuth consent, modify shared mailbox access, or abuse administrative roles. The important detail is that these actions do not need to be noisy to be damaging. A small number of legitimate-looking changes can alter who receives messages, where data flows, and which identities can act on behalf of others.

Operationally, this means incident response starts from the symptoms that remain, not from a clean sequence of events. Analysts often have to correlate sign-in records, mailbox audit events, Entra ID role changes, message trace data, and endpoint telemetry to reconstruct what happened. The reconstruction is usually slower than the attacker’s sequence because some logs arrive late, some are retained for limited periods, and some records show the effect of a change rather than the change itself.

• Mailbox rules can redirect sensitive messages away from the intended recipient.
• Delegated or granted permissions can let an attacker keep access after password reset.
• OAuth consent and app registrations can create durable access paths that survive simple remediation.
• Deleted or delayed logs can hide the earliest evidence needed to establish scope.

The practical consequence is that response teams must treat “no alert yet” as weak reassurance when mailbox or identity state has already changed. This guidance breaks down when audit coverage is incomplete, retention is too short for the organisation’s dwell time, or the environment lacks enough identity and message telemetry to reconstruct sequence reliably.

When the Usual Playbook Stops Working

Tighter detection often increases operational burden, requiring organisations to balance visibility against log volume, retention cost, and analyst time.

One edge case is delayed visibility caused by normal platform latency rather than malicious activity. That distinction matters because a slow event feed can look like stealth, but the response should focus on coverage gaps and retention rather than attacker tradecraft. Another edge case is cross-tenant or hybrid mail flow, where the evidence may be split across Microsoft 365, identity providers, and downstream archiving tools. In those cases, the main failure is not the absence of logs but the inability to join them quickly enough to preserve sequence.

There is also a governance tradeoff that teams often underestimate: the more aggressively they rely on mailbox rules and delegated access for productivity, the more carefully they need to monitor for abuse. That is consensus in security operations, but there is less consensus on the best balance between broad alerting and alert fatigue. A good rule is to treat any unexpected rule, consent, or permission change as a potential persistence event until proven otherwise. For a question like this, the reader should think in terms of state change, not just event detection.

Risk and Threat Considerations

The material risk is post-compromise persistence and concealment inside a collaboration platform that many organisations trust for business-critical communication. When logs reveal activity late, the attacker may already have established forwarding, delegated access, or privileged changes that continue after the initial account is remediated.

Failure mechanism: The attacker exploits the gap between action and detection by using legitimate platform features, delayed audit visibility, or insufficient retention to create durable access and reduce forensic clarity.

Impact: Defenders lose the clean sequence of events needed to contain the incident quickly, and the organisation may retain hidden exposure in mail flow, permissions, or administrative state.

Practitioner Guidance

What to prioritise: Treat unexpected mailbox rules, forwarding changes, app consent, and delegated permissions as higher priority than the original sign-in event if the audit trail is incomplete. Those state changes often tell you whether the attacker still has a foothold.

What to verify: Confirm whether your telemetry can show both the action and the actor with enough retention to cover your realistic dwell time. If you can only see the aftermath, your investigation will be partial even when the alert is accurate.

Practitioner takeaway: In Microsoft 365 incidents, the decisive question is often not how the attacker entered, but whether they left behind a durable control of mail, identity, or access before detection caught up.

Related resources from NHI Mgmt Group

• Why do Microsoft 365 and Intune attacks bypass many endpoint controls?
• Why do browser-native OAuth attacks increase the risk for Microsoft 365 environments?
• Why do post-MFA session theft attacks complicate Microsoft 365 security assumptions?
• What is the difference between sending logs to custom tables and sending them to native ASIM tables in Microsoft Sentinel?