Why Default Coverage Falls Short

Defender for Cloud Apps ingests activity logs and applies policy-based alerts. Conditional Access evaluates sign-in risk at authentication time. Neither tool is designed to stitch together a behavioral narrative across multiple workloads over time.

An attacker who steals a valid refresh token, waits 48 hours, and then accesses SharePoint from a new IP while Exchange Online activity remains normal will not trigger most out-of-box alerts. The individual signals are below threshold. The composite behavior is not evaluated because the logs are not joined.

This is not a product failure — it is an architecture gap. Closing it requires deliberate engineering, not just enabling more policies.

Architecture Perspective

The detection architecture that actually works in enterprise environments treats Entra ID, Exchange Online, and SharePoint as a single audit surface, not three separate products. Microsoft Sentinel is the right aggregation layer for this. Log Analytics workspaces ingest data from all three via Microsoft 365 Defender connector and the Office 365 connector, giving you a unified query surface.

Lateral Movement Detection

Lateral movement in cloud environments does not look like port scanning. It looks like a user who authenticated to Teams, then accessed SharePoint sites they have never visited, then queried Exchange mailboxes outside their normal working hours — all within a 90-minute window.

Traditional detection methods miss this because each individual action is authorized. The pattern is the signal.

To detect lateral movement, join activity logs from Entra ID, Exchange Online, and SharePoint in a single KQL query. The following query identifies users with high cross-service activity volume within a one-hour window — a pattern inconsistent with normal single-application workflows:

let startTime = ago(7d);
let endTime = now();
let threshold = 5;
let loginEvents =
    union
    (SigninLogs
    | where TimeGenerated between (startTime .. endTime)
    | where ResultType == 0
    | project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location),
    (OfficeActivity
    | where TimeGenerated between (startTime .. endTime)
    | where OfficeWorkload in ("Exchange", "SharePoint")
    | project TimeGenerated, UserPrincipalName, Operation, OfficeWorkload, ClientIP);
loginEvents
| summarize ServiceCount = dcount(AppDisplayName), EventCount = count()
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where EventCount > threshold and ServiceCount >= 3
| project TimeGenerated, UserPrincipalName, ServiceCount, EventCount
| order by EventCount desc

This query surfaces users who touched three or more distinct services within a single hour with above-threshold event volume. Tune the threshold value against your baseline — start at 5 and adjust after reviewing 30 days of historical data.

A refinement worth adding: join the output against Entra ID Identity Protection risk detections using AADUserRiskEvents to prioritize users who already carry an elevated risk score. That join eliminates noise from power users with legitimately high activity.

Token Theft Without Credential Compromise

Token theft is the attack pattern most likely to bypass Conditional Access entirely. An attacker who obtains a valid refresh token — through adversary-in-the-middle phishing, malware on an unmanaged device, or a compromised browser session — can request new access tokens without triggering a re-authentication prompt.

Conditional Access evaluates sign-in risk. It does not evaluate token replay from a new context if the token itself is valid and the sign-in conditions are met. The detection gap is real.

The signal to hunt is token issuance from a new IP or device without a corresponding interactive sign-in. In Sentinel, this surfaces in SigninLogs as non-interactive sign-ins with TokenIssuerType == "AzureAD" and a DeviceDetail that does not match the user's registered devices.

Use PowerShell against the Microsoft Graph API to extract and baseline token issuance patterns:

Connect-MgGraph -Scopes "AuditLog.Read.All"

$startDate = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
$endDate = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ")

$signInLogs = Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and createdDateTime le $endDate and isInteractive eq false" -All

$anomalies = $signInLogs |
    Group-Object -Property UserPrincipalName |
    Where-Object { $_.Count -gt 15 } |
    Select-Object Name, Count

foreach ($anomaly in $anomalies) {
    Write-Output "Elevated non-interactive sign-in volume: $($anomaly.Name) — $($anomaly.Count) events"
}

Non-interactive sign-in volume above 15 events in seven days for a single user warrants investigation, particularly when the DeviceId field is absent or inconsistent. Cross-reference against Microsoft Entra ID's Continuous Access Evaluation (CAE) logs to determine whether token revocation events were issued and whether the client honored them.

Operational Impact

The operational consequence of missing these signals is not theoretical. A token theft attack that goes undetected for 72 hours gives an attacker enough time to exfiltrate mailbox content, enumerate SharePoint document libraries, and register a new OAuth application — all using legitimate credentials and valid tokens.

Anomalous App Consent Patterns

OAuth consent abuse is one of the most undermonitored attack vectors in Microsoft 365 environments. Attackers register applications in external tenants, craft convincing consent prompts, and trick users into granting delegated permissions to Mail.Read, Files.ReadWrite.All, or Contacts.Read. Once consent is granted, the attacker's application can access data continuously without requiring the user's credentials again.

Defender for Cloud Apps has an App Governance add-on that surfaces high-risk OAuth apps, but it requires explicit enablement and policy configuration. Many environments have it licensed but not configured.

The following KQL query identifies applications that received consent from multiple users within a short window — a pattern consistent with a phishing campaign targeting OAuth consent:

AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName == "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend ConsentingUser = tostring(InitiatedBy.user.userPrincipalName)
| extend PermissionsGranted = tostring(TargetResources[0].modifiedProperties)
| summarize ConsentCount = count(), Users = make_set(ConsentingUser)
    by AppName, bin(TimeGenerated, 24h)
| where ConsentCount > 3
| project TimeGenerated, AppName, ConsentCount, Users
| order by ConsentCount desc

Any application receiving consent from more than three distinct users within a 24-hour window should be treated as suspicious until proven otherwise. Cross-reference the AppName against your approved application inventory in Entra ID Enterprise Applications.

To restrict future exposure, enforce admin consent workflow via Entra ID portal under Enterprise Applications → User Settings → Admin consent requests. This routes all user consent requests to a designated reviewer queue rather than allowing silent self-service consent.

Enhancing Detection Coverage

A multi-layered detection approach closes the gaps that individual tools leave open:

• Log Correlation: Ingest Entra ID, Exchange Online, SharePoint, and Defender for Cloud Apps activity into a single Sentinel workspace. Use the Microsoft 365 Defender and Office 365 data connectors. Do not rely on individual product portals for cross-workload analysis.
• Behavioral Analytics: Enable Sentinel UEBA (User and Entity Behavior Analytics). UEBA builds activity baselines per user and surfaces deviations — including access to resources the user has never previously touched — without requiring manual threshold tuning.
• Continuous Monitoring: Schedule KQL queries as Sentinel Scheduled Analytics Rules with alert thresholds tied to your environment's baseline. Review and update thresholds quarterly or after any significant change in workforce size or application portfolio.

Governance Considerations

Undetected cloud app threats create direct compliance exposure under SOC 2, FedRAMP Moderate, and HIPAA. Each framework requires demonstrable continuous monitoring of cloud application behavior, access patterns, and data handling. A detection gap that allows unauthorized access to persist for days is not just a security failure — it is an audit finding.

Compliance and Audit Requirements

Governance teams need evidence, not assertions. Detection coverage must be documented in a way that satisfies auditor requests for control evidence:

• Documenting Detection Strategies: Maintain a detection catalog that maps each KQL rule or Sentinel analytic to the threat scenario it addresses, the log sources it queries, and the alert threshold rationale. Store this in a version-controlled repository alongside your Sentinel workspace ARM templates.
• Regular Audits: Run quarterly reviews of Sentinel analytics rule coverage against the MITRE ATT&CK for Cloud matrix. Map each enabled rule to a technique ID. Gaps in coverage become visible and actionable.
• Incident Response Plans: Ensure your IR playbooks address token theft and OAuth consent abuse specifically. Generic cloud IR playbooks often omit token revocation steps — including revoking all refresh tokens via Revoke-MgUserSignInSession and disabling the consented application in Entra ID Enterprise Applications.

Recommendations

Closing detection gaps requires specific actions, not general principles:

1. Integrate Logs Across Services: Configure Sentinel data connectors for Microsoft 365 Defender, Office 365, and Entra ID. Validate that SigninLogs, AuditLogs, OfficeActivity, and CloudAppEvents tables are all populated before building detection rules.
2. Enable and Configure App Governance: In the Microsoft 365 Defender portal, activate the App Governance add-on under Cloud Apps → App Governance. Create policies that alert on apps with high-privilege permissions and low community use scores.
3. Deploy UEBA in Sentinel: Enable User and Entity Behavior Analytics under Sentinel → Settings → Entity Behavior. Allow 14 days of baseline collection before treating anomaly scores as actionable.
4. Enforce Admin Consent Workflow: Disable user self-service consent for all applications except verified publisher apps with low-risk permission scopes. Route all other consent requests through the admin approval queue.
5. Hunt for Token Replay Proactively: Schedule a weekly threat hunt using the non-interactive sign-in query above. Do not wait for an alert — token theft often produces no alert under default configurations.
6. Map Coverage to MITRE ATT&CK for Cloud: Use the ATT&CK Navigator to visualize which techniques your current Sentinel rules address. Treat uncovered techniques as a prioritized backlog, not a future consideration.