Secure Cloud Apps with Microsoft Defender for Cloud Apps

Cloud Discovery: finding shadow IT

Cloud Discovery identifies every cloud application employees are using, including applications IT has not sanctioned. The discovery data comes from two sources.

Defender for Endpoint integration is the primary method. When enabled in Settings, then Cloud Apps, then Microsoft Defender for Endpoint, the endpoint sensor automatically reports network traffic to cloud applications. Every HTTP and HTTPS connection from an onboarded device to a SaaS application is captured and sent for analysis. This provides per-device, per-user cloud app discovery without network infrastructure changes. No proxy logs, no firewall configurations, just the existing endpoint sensor.

Log collectors provide network-level visibility for environments where not all devices are onboarded. Defender for Cloud Apps accepts log uploads from most enterprise firewalls (Palo Alto, Fortinet, Check Point, Cisco) and web proxies (Zscaler, Squid, Blue Coat). The service maps traffic against a catalog of over 31,000 cloud applications, each scored on regulatory compliance, encryption, MFA support, and data handling practices.

Applications scoring below your risk threshold can be tagged as "Unsanctioned." With Endpoint integration enabled, unsanctioned apps are blocked at the endpoint level without configuring anything at the network layer. During incident response, Cloud Discovery reveals whether a compromised user was accessing unauthorized cloud storage (potential exfiltration channels) and whether users are sending corporate data to personal accounts. The "Discovered apps" tab shows per-application usage statistics: transaction counts, upload volumes, and download volumes. A user who uploaded 2GB to a personal Dropbox account during the same time window as a confirmed account compromise gives you a concrete exfiltration indicator to investigate further.

App connectors and anomaly detection

While Cloud Discovery identifies which applications are in use, app connectors provide deep visibility into what users do inside those applications. For Microsoft 365, the connector is automatic. Activity data from Exchange Online, SharePoint, OneDrive, and Teams populates the CloudAppEvents table in Advanced Hunting. For third-party SaaS (Salesforce, Google Workspace, Box, GitHub, ServiceNow), you configure connectors individually using API credentials.

Once connected, the activity log captures every user action: file uploads, downloads, shares, permission changes, login events, admin configuration changes, and application-specific actions like inbox rule creation in Exchange Online.

Defender for Cloud Apps uses machine learning to establish behavioral baselines for each user and alert when activity deviates significantly. The built-in anomaly detection policies most relevant to SOC operations include:

Impossible travel detects authentication from two geographically distant locations within a time window that makes physical travel impossible. A sign-in from London at 09:00 and Singapore at 09:30 indicates either a compromised account or a VPN/proxy issue. The policy accounts for known corporate VPNs to reduce false positives.

Suspicious inbox forwarding detects rules that forward or redirect email to external addresses. This is one of the most common BEC post-compromise actions: the attacker creates a forwarding rule to maintain access to the victim's email even after the password is changed, silently copying inbound messages to an external mailbox.

Suspicious inbox manipulation targets rules designed for concealment rather than exfiltration: deleting messages, moving them to hidden folders, or marking them as read to hide attacker activity from the legitimate mailbox owner.

Unusual file download activity fires when download volume significantly exceeds the user's baseline. A user who normally downloads 5-10 files per week suddenly pulling 500 in an hour is consistent with data exfiltration.

Activity from infrequent country fires when a user performs actions from a country they have never previously accessed applications from. This is a weaker signal than impossible travel (it could be legitimate business travel) but becomes a significant indicator when combined with other alerts in the same XDR incident. A risky sign-in from an infrequent country followed by inbox rule creation and mass file downloads is a high-confidence compromise pattern.

Unusual file share activity detects external sharing at an anomalous rate. This catches both intentional exfiltration (sharing confidential files with a personal account) and compromised accounts distributing phishing links via shared documents. The policy is particularly useful for SharePoint and OneDrive, where a single shared link can expose an entire document library.

Multiple failed login attempts extends brute-force detection to third-party SaaS applications connected via app connectors. Failed attempts against Salesforce, GitHub, or ServiceNow are captured here, supplementing the Entra ID Protection coverage for Microsoft authentication.

These policies can be tuned in Settings, then Cloud Apps, then Policy management. Tuning options include sensitivity adjustment (reducing false positives at the cost of broader detection), user and group exclusions for service accounts that legitimately perform bulk operations, and scope configuration to apply policies only to specific user groups. The tuning balance is important: anomaly detection policies with default sensitivity may generate alert volumes that overwhelm a small SOC team, while heavily tuned policies may miss real attacks. Start with default sensitivity for high-value policies (impossible travel, suspicious inbox forwarding) and adjust based on your false positive rate over the first two weeks.

OAuth app governance

OAuth app governance detects consent phishing, one of the most persistent access techniques in the M365 threat landscape. When a user consents to an OAuth application (clicking "Allow" on a permission request), the application receives an access token granting specific permissions: mailbox access, file access, calendar access, directory read. Attackers exploit this through consent phishing: they create a malicious application, send the victim a link triggering the consent prompt, and if the user clicks "Allow," the attacker's application gets persistent access that survives password changes and MFA. The attacker does not need to authenticate again because the OAuth app has its own independent token.

Defender for Cloud Apps monitors OAuth registrations and alerts on suspicious patterns: applications requesting excessive permissions (full mailbox access for a claimed calendar tool), low community trust scores, unknown publishers, and recently created applications rapidly accumulating user consents. The OAuth app governance dashboard shows every application granted permissions in your tenant, including the permissions, the number of consenting users, the publisher, and community trust. During investigation, this dashboard tells you whether a compromised user consented to a malicious application, what data that application accessed, and which other users also consented. If five users in the finance department all consented to the same unknown application within an hour, you are looking at a targeted consent phishing campaign, not an isolated compromise.

// Detect suspicious OAuth consent grants
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType == "Consent to application."
| extend AppName = tostring(RawEventData.Target[3].ID)
| extend Permissions = tostring(RawEventData.ModifiedProperties[4].NewValue)
| project Timestamp, AccountDisplayName, AppName, Permissions
| where Permissions has_any ("Mail.ReadWrite", "Mail.Send",
    "Files.ReadWrite.All", "MailboxSettings.ReadWrite")

That query surfaces consent events where users granted high-risk permissions: mailbox read/write, mail send, and full file access. Any result from a user involved in an active incident is a strong indicator that the attacker obtained persistent access through consent phishing. The RawEventData field contains the full audit record from Azure AD, including the application ID, the specific permissions granted, and the IP address from which the consent was given. Cross-reference the consent timestamp with sign-in records to determine whether the consent happened during a suspicious session or during normal user activity. The response is to revoke the OAuth app's permissions from the Cloud Apps portal, which immediately invalidates the app's access tokens.

Conditional Access App Control

Conditional Access App Control extends Conditional Access policies into the application session itself. Standard Conditional Access gates the authentication decision: allow, block, or require MFA. App Control gates what the user can do after authentication: block file downloads, prevent copy/paste of sensitive content, apply DLP labels, or monitor the session in real time.

App Control works by proxying the user's session through the Defender for Cloud Apps reverse proxy. The proxy intercepts requests and responses between the user's browser and the SaaS application, applying policies at the request level. A policy can allow a user to view documents in SharePoint but block downloads from unmanaged devices. Another policy can allow email access from personal devices but watermark downloaded attachments with the user's identity for DLP tracing.

The configuration starts in Conditional Access. You create a CA policy with the session control "Use Conditional Access App Control" and select either "Monitor only" (log all activity without blocking) or "Block downloads" (prevent file downloads from the session). The CA policy triggers the proxy routing. Then in Defender for Cloud Apps, you create session policies that define the granular controls: which file types to block, which DLP labels to enforce, which actions to log. The combination of CA policy (who is routed through the proxy) and session policy (what the proxy enforces) gives you precise control over application access without an all-or-nothing approach.

For SOC operations, the investigation value of session policies is the session log. Every action within the proxied session is recorded with full detail: pages viewed, files downloaded, data copied, search queries executed. During incident response, session logs show exactly what the attacker accessed and downloaded through the compromised session. These logs provide evidence that activity logs from the SaaS application itself may not capture at the same level of granularity, because the proxy sees the raw HTTP requests and responses rather than the application's own audit interpretation.

Response actions for cloud app threats

Defender for Cloud Apps provides response actions specific to the cloud application layer. Revoke OAuth app immediately invalidates the malicious application's access tokens, cutting off persistent access that survives password resets. This is the single most important response action for consent phishing because the OAuth token is independent of the user's credentials. Resetting the user's password and revoking their sessions does not invalidate the OAuth app's token. Only revoking the app itself cuts the attacker's access.

Suspend user blocks the user from accessing connected cloud apps without disabling their AD or Entra ID account, useful when you want to contain cloud activity while preserving on-premises access for investigation. Require user to sign in again forces re-authentication, effective when combined with a Conditional Access policy that requires MFA or blocks risky locations.

For governance actions, you can configure automated responses: automatically suspend a user when impossible travel is detected, automatically revoke an OAuth app when consent phishing patterns match, or automatically notify the user's manager when unusual file sharing is detected. These governance actions run as part of the policy engine at machine speed, providing automated containment before an analyst opens the incident.