How should security teams detect Microsoft 365 attacks when default logs miss reconnaissance and failed actions?

Security teams should not rely on Microsoft 365 logs as a complete source of truth. The practical approach is to detect what is reliably logged, such as sign-ins, inbox rule creation, and permission changes, then build detections around attack chains rather than isolated events. When visibility is incomplete, defenders also need stronger baselines, misconfiguration review, and compensating controls.

Why Microsoft 365 Detection Fails When Teams Expect the Logs to Tell the Whole Story

Microsoft 365 monitoring often breaks down when defenders treat native audit data as if it were comprehensive telemetry. In practice, some meaningful attacker activity is recorded, but reconnaissance, probing, and failed actions may be sparse, delayed, or absent, which makes single-event alerting unreliable. The real issue is not that nothing is logged, but that the platform may only expose part of the attack chain.

That changes the detection problem. Teams need to look for combinations of identity events, mailbox changes, permission shifts, and unusual access patterns, then interpret those signals in context rather than waiting for an obvious malicious record. This is where attack-path thinking matters more than event counting. The MITRE ATT&CK Enterprise Matrix is useful here because it frames activity by adversary behaviour rather than by whether every action leaves a perfect log trail. In practice, many security teams only discover the gap after they have already tuned their detections to the events Microsoft 365 reliably surfaces.

How Detection Strategy Changes When Reconnaissance Is Invisible

The practical response is to build detections around what can be observed consistently, then infer likely attacker behaviour from sequences and side effects. That means sign-in anomalies, inbox rule creation, consent or permission changes, forwarding configuration, and unusual administrative actions become more important than isolated failed attempts. If recon activity is not logged, defenders should treat repeated low-signal changes as part of a broader chain rather than as noise.

A strong Microsoft 365 detection model usually includes three layers:

Identity and authentication signals, such as unusual location, device, timing, or session characteristics.
Tenant configuration and mailbox behaviour, such as rules, forwarding, application consent, and delegated access changes.
Correlation logic that connects small events into an attack narrative, especially where the platform does not preserve every failed action.

This approach works because many Microsoft 365 intrusions create detectable side effects even when the preparatory steps are missing. Teams should also validate whether telemetry gaps come from product design, licensing scope, retention settings, or logging configuration, because those are different problems with different remedies. CISA cyber threat advisories can help teams align their detections with current attacker tradecraft, but the key operational move is still to hunt for chains, not single alerts. Where teams depend on one log source to explain the whole incident, the guidance breaks down as soon as the attacker stays quiet, moves slowly, or operates through normal administrative features.

Tighter detection logic often increases analyst workload, requiring organisations to balance sensitivity against alert fatigue and incomplete evidence.

One common edge case is benign administrative activity that looks similar to abuse, especially in large tenants with frequent mailbox and permission changes. Another is the false assumption that more retention automatically solves visibility problems. It does not, if the missing data was never captured in the first place. Guidance also varies by control objective: for hardening and detection engineering, you can usually proceed with imperfect telemetry; for incident reconstruction, the same blind spots may leave you unable to prove whether reconnaissance ever occurred.

For teams operating in heavily integrated Microsoft 365 environments, the practical question is not whether every malicious step will be visible, but whether the combined control stack can still surface an abnormal sequence early enough to matter. That is why detections should be reviewed against realistic attacker behaviour, not against the assumption that audit logs will narrate the whole event. The most important limit is simple: if the environment does not record the side effects you rely on, correlation will still miss what never became observable.

Risk and Threat Considerations

The main risk is false confidence in telemetry completeness. Microsoft 365’s native logging can leave gaps around reconnaissance, failed actions, and slow-burn abuse, which gives attackers room to test access, adjust tactics, and remain below alert thresholds.

Failure mechanism: Defenders anchor detections to individual log events instead of to attack chains, while the platform omits or de-emphasises the preparatory activity that would explain intent. That allows abuse of mailbox rules, delegated access, consent grants, and authentication patterns to appear as routine change activity until the sequence is correlated.

Impact: Teams may miss early intrusion signals, misclassify malicious behaviour as administrative noise, and lose the ability to reconstruct dwell time or initial access paths with confidence.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1087 — Account Discovery	Reconnaissance gaps map to account and tenant discovery behaviour in M365.
	T1114 — Email Collection	Mailbox abuse and rule-based collection are central M365 attack outcomes.
	T1098 — Account Manipulation	Permission and delegation changes are key visible side effects in M365 compromise.
Recommendation — Map observable prep activity to T1087 and correlate it with later mailbox or permission changes. Hunt for T1114 indicators in rule creation, forwarding, and delegated mailbox access. Detect T1098-style permission changes and treat them as compromise indicators when they cluster.
CIS Controls v8	8 — Audit Log Management	The question centers on what logs exist, what is missing, and how to compensate.
Recommendation — Review Control 8 coverage and retain the audit events needed to support attack-chain detections.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	M365 detection requires continuous monitoring across imperfect identity and mailbox telemetry.
	DE.AE — Anomalies and Events	The issue is recognising malicious sequences when individual events are incomplete.
Recommendation — Use DE.CM to correlate weak signals into a defensible monitoring and alerting strategy. Apply DE.AE to define which Microsoft 365 anomalies should trigger escalation.

Practitioner Guidance

What to prioritise: Prioritise the few Microsoft 365 events that consistently survive logging gaps, then build detections around sequences that show intent rather than isolated failures. If a detection cannot survive the absence of reconnaissance telemetry, it is too dependent on perfect visibility to be reliable.

What to verify: Verify which audit sources are actually enabled, what retention applies, and which actions are recorded versus inferred. Teams often underestimate the difference between “available in the portal” and “usable for detection engineering,” especially when tuning for investigations instead of real-time hunting.

Practitioner takeaway: In Microsoft 365, the best detections are usually those that assume the attacker’s first probes may be invisible and still catch the account, mailbox, or permission changes that follow.