Why Zero Trust is a Lie Without Them

An account pulled down 12,000 SharePoint files in 20 minutes. No malware, no DLP alert, no blocked session. Zero Trust said “allowed.” In this episode, we dissect why Zero Trust without audit evidence is policy theater—and how to fix it. You’ll learn how to fuse Entra sign-in risk, the Microsoft 365 Unified Audit Log, Purview policy edits, and Copilot interactions into one coherent timeline. We finish by reconstructing a quiet exfiltration case step by step and give you concrete detection recipes, KQL ideas, and automation patterns you can deploy in your own tenant.

Opening – The Anomaly Zero Trust Can’t Explain It starts with a warning and ends with silence:
One account downloads 12,000 SharePoint files in under 20 minutes.
No malware. No DLP alert. Conditional Access says “allowed.” The thesis: Zero Trust without audit evidence is policy theater.
Verification isn’t a checkbox; it’s a trail. In this episode, we:

• Pull from four log sources:
  • Entra ID sign-in & risk
  • Microsoft 365 Unified Audit Log (UAL)
  • Purview retention & policy changes
  • Copilot interaction logs
• Show the one log pivot that reliably exposes data staging
• Reconstruct a real-style exfiltration case, end to end
• Turn it into queries, alerts, dashboards, and automation

Section 1 – Entra ID Sign-in & Risk: Verify the Verifier Every breach still begins with an identity. Entra’s risk signals are your earliest warning—but only if you keep them long enough and correlate them correctly. Key points:

• Entra splits visibility:
  • Risky sign-ins: ~30-day window
  • Risk detections: often ~90 days
• If you only review risky sign-ins, you lose early signals and can’t reconstruct the path later.

Three streams you must track together:

1. Risky sign-ins – the attempts and outcomes
2. Risk detections – patterns like anomalous token or AiTM
3. Workload identity anomalies – service principals behaving like users

High-priority detections:

• Anomalous token → session theft / replay
• Attacker-in-the-middle → sign-in through a malicious proxy
• Unfamiliar sign-in properties → new device / client / IP combos

The catch:

• Conditional Access can “succeed” while the threat remains.
  • Medium-risk sign-in → prompt for MFA → success → session allowed.
  • Repeated medium risk over days correlates strongly with later data staging.

What to actually do:

• Join sign-ins with Conditional Access evaluation so every successful auth carries:
  • UserId, AppId, IP, DeviceId, derived SessionId
  • RiskDetail, RiskLevel at event time
  • Which CA policy allowed / challenged it

Patterns to alert on:

• Repeated medium-risk sign-ins:
  • 3+ in 7 days from distinct ASNs / IP ranges → investigation, not “business as usual”
• Workload identities suddenly authenticating from public IPs or gaining new API permissions
• If risk >= high and token anomalies present → force sign-out and require password reset

Retention hygiene:

• Export risky sign-ins weekly beyond the 30-day window.
• Keep risk detections in your SIEM for 180 days+ so you can replay the first 12 hours when it matters.

Bottom line: verify the verifier. The sign-in narrative is the prologue. The story starts when movement begins. Section 2 – Unified Audit Log: Trace Lateral Movement Across Workloads Once the door opens, the Unified Audit Log is your ledger. It captures cross-service movement:

• Exchange, SharePoint, OneDrive, Teams, and admin actions in one place.

Why it matters:

• Real attackers don’t stay in one workload. They:
  • Add mailbox forwarding rules
  • Change SharePoint permissions
  • Register new sync clients
  • Create sharing links that bypass normal paths

Three lenses to apply to the UAL:

1. Identity lens – UserId, AppId, ClientIP, SessionKey
2. Privilege lens – mailbox permissions, site admin changes, role assignments
3. Data lens – FileDownloaded, FileAccessed, FileSyncAdded, SharingLinkCreated

Core idea: Privilege change + data surge = staging, not collaboration. Better than raw “mass download”:

• Build per-user baselines and look for change from baseline:
  • User normally touches ~20 files per day
  • Suddenly touches 800 unique items across two sites in 30 minutes
  • Plus: new sync relationship and wider sharing links → staging, not sync

Kill chain reconstruction uses patterns like:

• Set-InboxRule or Set-Mailbox forwarding externally
• Followed by a burst of SharePoint FileDownloaded in that same session
• Plus SharingLinkCreated with “Anyone” or “Organization” scope

Practical moves:

• Stream UAL via the Management Activity API into Sentinel/Log Analytics
• Normalize by: UserId, ClientIP, Operation, ObjectId, RecordType, Timestamp
• Build session keys (User + IP + App + 30–45 min bin) and aggregate:
  • UniqueFiles, UniqueSites, privilege-change flags, sharing-scope changes

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast–6704921/support.

Follow us on:
LInkedIn
Substack