While Defender for Endpoint watches the device layer and Defender for Identity watches the on-premises identity layer, Defender for Cloud Apps watches the cloud application layer — what users do inside SaaS applications after they have authenticated. It answers questions that no other Defender product can: Which cloud applications are employees using that IT does not know about? Is a compromised user creating inbox forwarding rules? Did someone consent to a malicious OAuth application that now has access to their mailbox and files? Is a user downloading hundreds of files from SharePoint in a pattern consistent with data exfiltration?
This subsection teaches you how Defender for Cloud Apps discovers shadow IT, how its app connectors provide deep SaaS visibility, how anomaly detection policies identify post-compromise behavior, how OAuth app governance detects consent phishing, and how to investigate CloudAppEvents in Advanced Hunting. Understanding Defender for Cloud Apps is particularly important for Modules 11-13, where post-compromise activity — inbox rule creation, mailbox access, OAuth app abuse — is detected by this product.
---
Cloud Discovery: finding shadow IT
Cloud Discovery is the feature that identifies every cloud application employees are using, including applications that IT has not sanctioned. The discovery data comes from two primary sources.
Defender for Endpoint integration. When Defender for Endpoint is integrated with Defender for Cloud Apps (enabled in Settings → Cloud Apps → 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 to Defender for Cloud Apps for analysis. This provides per-device, per-user cloud app discovery without requiring any network infrastructure changes — no proxy logs, no firewall configurations, just the existing endpoint sensor.
Log collectors and firewalls. For environments where not all devices are onboarded to Defender for Endpoint (or for network-level visibility), you can configure automatic log upload from firewalls and proxies. Defender for Cloud Apps supports log formats from most enterprise firewalls (Palo Alto, Fortinet, Check Point, Cisco) and web proxies (Zscaler, Squid, Blue Coat). The logs are uploaded to the cloud service, which parses them and maps network traffic to its catalog of over 31,000 cloud applications.
The Cloud Discovery dashboard shows the total number of discovered applications, categorized by risk score. Each application receives a risk score based on factors including regulatory compliance certifications, security features (encryption, MFA support), data handling practices, and legal terms. Applications scoring below your organization's risk threshold can be tagged as "Unsanctioned" — and if Defender for Endpoint integration is enabled, unsanctioned apps can be blocked at the endpoint level, preventing users from accessing them without needing to configure anything at the network layer.
Investigation value of Cloud Discovery. During incident response, Cloud Discovery tells you whether a compromised user was accessing unauthorized cloud storage services (potential data exfiltration channels), whether the organization has exposure to a newly disclosed SaaS vulnerability, and whether users are sending corporate data to personal cloud accounts (Google Drive, Dropbox, personal OneDrive). The "Discovered apps" tab shows usage statistics per application — transaction counts, upload volumes, and download volumes — which helps you assess whether a shadow IT application poses a data leakage risk.
---
App connectors: deep SaaS visibility
While Cloud Discovery identifies which applications are in use, app connectors provide deep visibility into what users do inside those applications. App connectors use the application's API to retrieve activity logs, user accounts, file metadata, and configuration settings.
For Microsoft 365, the connector is automatic — Defender for Cloud Apps has native integration with Exchange Online, SharePoint Online, OneDrive, and Teams. Activity data from these services populates the CloudAppEvents table in Advanced Hunting and feeds anomaly detection policies.
For third-party SaaS applications, you configure app connectors individually. Supported applications include Salesforce, Google Workspace, Box, Dropbox, ServiceNow, Okta, GitHub, Atlassian, and many others. Each connector requires API credentials (typically an OAuth app registration or API key) with read permissions for activity logs and user data.
Once connected, the activity log in Defender for Cloud Apps shows every user action within the connected application: file uploads, file downloads, file shares, permission changes, login events, admin configuration changes, and application-specific actions (such as creating an inbox rule in Exchange Online or modifying a pipeline in GitHub). This activity data is the foundation for both anomaly detection and manual investigation.
---
Anomaly detection policies
Defender for Cloud Apps includes built-in anomaly detection policies that use machine learning to identify suspicious behavior patterns. These policies establish a baseline of normal behavior for each user (login locations, devices, activity volume, typical working hours) and fire alerts when behavior deviates significantly from the baseline.
The most important built-in anomaly detection policies for SOC analysts are:
Impossible travel. Detects when a user authenticates from two geographically distant locations within a time window that makes physical travel impossible. For example, a sign-in from London at 09:00 and a sign-in from Singapore at 09:30 indicates either a compromised account or a VPN/proxy configuration issue. The policy accounts for known VPNs and corporate proxy configurations to reduce false positives.
Activity from infrequent country. Fires when a user performs activity from a country they have never previously accessed applications from. This is a weaker signal than impossible travel (it could be legitimate travel) but becomes significant when combined with other indicators.
Suspicious inbox forwarding. Detects the creation of inbox rules that forward or redirect email to external addresses. This is one of the most common post-compromise actions in business email compromise (BEC) attacks — the attacker creates a forwarding rule to maintain access to the victim's email even after the password is changed. The rule silently copies inbound emails to the attacker's external mailbox.
Unusual file download activity. Fires when a user downloads a volume of files that significantly exceeds their baseline. A user who normally downloads 5-10 files per week suddenly downloading 500 files in an hour is consistent with data exfiltration.
Unusual file share activity. Detects when a user shares files with external users at an unusual rate. This catches both data exfiltration (sharing confidential files with a personal account) and compromised accounts being used to distribute phishing links or malware via shared files.
Multiple failed login attempts. While Entra ID Protection also detects this, Defender for Cloud Apps extends the detection to third-party SaaS applications connected via app connectors. Failed login attempts against Salesforce, GitHub, or ServiceNow are captured here.
Suspicious inbox manipulation rule. Specifically targets inbox rules that delete messages, move them to hidden folders, or mark them as read — behaviors designed to hide the attacker's activity from the legitimate mailbox owner. This is distinct from suspicious forwarding because the rule's purpose is concealment rather than exfiltration.
You can tune anomaly detection policies in Settings → Cloud Apps → Policy management. Tuning options include adjusting sensitivity (fewer false positives vs. broader detection), excluding specific users or groups (service accounts that legitimately perform bulk operations), and configuring scope (apply to all users or only to specific groups).
---
OAuth app governance
OAuth app governance is one of the most critical capabilities for detecting consent phishing attacks. When a user consents to an OAuth application (clicking "Allow" on a permission request popup), that application receives an access token that grants it specific permissions to the user's data — mailbox access, file access, calendar access, or directory read permissions.
Attackers exploit this mechanism through consent phishing: they create a malicious OAuth application, send the victim a link that triggers the consent prompt, and if the user clicks "Allow," the attacker's application receives a persistent access token to the victim's mailbox and files. This token survives password changes and MFA — the attacker does not need to authenticate again because the OAuth application has its own independent access.
Defender for Cloud Apps monitors OAuth application registrations across the tenant and alerts on suspicious patterns: applications requesting excessive permissions (full mailbox access for an application that claims to be a calendar tool), applications with low community trust scores, applications registered by unknown publishers, and applications that were recently created and are rapidly accumulating user consents.
The OAuth app governance dashboard shows every OAuth application that has been granted permissions in your tenant, including the permissions granted, the number of users who consented, the publisher, and the application's community trust score. During investigation, this dashboard tells you whether a compromised user consented to a malicious application, what permissions that application has, and which other users may have also consented.
| Timestamp | AccountDisplayName | AppName | Permissions |
|---|
| Mar 18 14:22 | J. Morrison | SecureDoc Viewer Pro | Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite |
Consent phishing indicator: An application named "SecureDoc Viewer Pro" requesting Mail.ReadWrite, Mail.Send, and MailboxSettings.ReadWrite permissions is consistent with consent phishing. A legitimate document viewer does not need permission to send email or modify mailbox settings. Response: revoke the application's permissions immediately in Entra ID → Enterprise applications, revoke the user's active sessions, and investigate whether the application has already accessed the user's mailbox data.
---
Conditional Access App Control
Conditional Access App Control is a session-level proxy that sits between the user and the cloud application, providing real-time monitoring and enforcement during the user's session. Unlike app connectors (which review activity after the fact via API), session controls intercept activity as it happens.
When Conditional Access App Control is configured for an application, user traffic is routed through the Defender for Cloud Apps proxy. The proxy can then enforce policies such as blocking downloads of files containing sensitive data (credit card numbers, social security numbers), blocking copy-paste of sensitive content from the application, applying read-only access for unmanaged devices, watermarking downloaded documents with the user's identity, and monitoring all session activity in real time.
Session controls are particularly valuable for scenarios where you want to allow access to an application but need to prevent specific high-risk actions — for example, allowing a contractor to view documents in SharePoint Online but blocking them from downloading or printing those documents.
For SOC analysts, session control logs provide granular evidence during investigations. If a compromised user accessed a connected application, the session logs show exactly what the user viewed, downloaded, uploaded, and shared during each session — with the actual content of downloaded files available for review if download monitoring was enabled.
---
Investigating CloudAppEvents
The CloudAppEvents table in Advanced Hunting is where Defender for Cloud Apps activity data lands for KQL investigation. This table contains every user action captured by app connectors and session controls, including actions in Exchange Online, SharePoint Online, OneDrive, Teams, and connected third-party applications.
Key fields in CloudAppEvents include ActionType (the specific action performed, such as "New-InboxRule", "FileDownloaded", "Add delegated permission grant"), AccountDisplayName (the user who performed the action), Application (the cloud application where the action occurred), IPAddress (the source IP), and RawEventData (a JSON blob containing the full event details specific to each action type).
| Timestamp | Account | IPAddress | RuleDetails |
|---|
| Mar 17 11:42 | J. Morrison | 203.0.113.47 | ForwardTo: ext-backup@proton.me, MarkAsRead: true |
BEC indicator: An inbox rule forwarding to an external Proton Mail address and marking forwarded messages as read is a textbook BEC/account compromise pattern. The attacker is exfiltrating email while hiding the forwarding from the legitimate user. The external IP address should be cross-referenced with sign-in logs to confirm it belongs to the attacker. Remove the rule immediately, revoke all active sessions, and force MFA re-registration for the compromised user.
| AccountDisplayName | Timestamp | DownloadCount | UniqueFiles | TotalSizeMB |
|---|
| J. Morrison | Mar 17 11:00 | 347 | 312 | 2,847 |
Data exfiltration indicator: 347 file downloads (312 unique files, ~2.8 GB) in a single hour is orders of magnitude above normal user behavior. Cross-reference with sign-in logs to determine whether this activity originated from the user's normal device and location, or from a compromised session. If the IP address matches a known attacker IP from other alerts in the incident, this confirms active data exfiltration.
---
Response actions for cloud app threats
When you identify a cloud app-related threat, the response actions span multiple products because cloud app compromise typically involves identity, email, and data:
Revoke OAuth app permissions. In Entra ID → Enterprise applications → the malicious app → Permissions, revoke all delegated and application permissions. This immediately cuts the attacker's OAuth-based access.
Remove inbox rules. Use Exchange Online PowerShell or the Defender portal to remove malicious inbox rules: Get-InboxRule -Mailbox j.morrison@northgateeng.com | Where-Object {$_.ForwardTo -or $_.RedirectTo} | Remove-InboxRule.
Revoke user sessions. In Entra ID → Users → the compromised user → Revoke sessions. This invalidates all active tokens and forces re-authentication.
Block the source IP. If the attacker accessed cloud apps from a specific IP, add that IP to your Conditional Access named locations as a blocked location, or add it as a Sentinel indicator for automated blocking.
Review file access. Use CloudAppEvents to determine which files the attacker accessed, downloaded, or shared. If sensitive files were accessed, notify the data owner and assess whether the data breach requires regulatory notification.
