Integrating Proofpoint and Mimecast Email Security with Microsoft Sentinel
Microsoft Sentinel can ingest rich email security telemetry from Proofpoint and Mimecast to power advanced phishing detection. The Proofpoint On Demand (POD) Email Security and Proofpoint Targeted Attack Protection (TAP) connectors pull threat logs (quarantines, spam, phishing attempts) and user click data into Sentinel. Similarly, the Mimecast Secure Email Gateway connector ingests detailed mail flow and targeted-threat logs (attachment/URL scans, impersonation events). These integrations use Azure-hosted ingestion (via Logic Apps or Azure Functions) and the new Codeless Connector framework to call vendor APIs on a schedule. The result is a consolidated dataset in Sentinel’s Log Analytics, enabling correlated alerting and hunting across email, identity, and endpoint signals. Figure: Phishing emails are processed by Mimecast’s gateway and Proofpoint POD/TAP services. Security logs (delivery/quarantine events, malicious attachments/links, user clicks) flow into Microsoft Sentinel. In Sentinel, these mail signals are correlated with identity (Azure AD), endpoint (Defender) and network telemetry for end-to-end phishing detection. Proofpoint POD (Email Protection) Connector The Proofpoint POD connector ingests core email protection logs. It creates two tables, ProofpointPODMailLog_CL and ProofpointPODMessage_CL. These logs include per-message metadata (senders, recipients, subject, message size, timestamps), threat scores (spamScore, phishScore, malwareScore, impostorScore), and attachment details (number of attachments, names, hash values and sandbox verdicts). Quarantine actions are recorded (quarantine folder/rule) and malicious indicators (URL or file hash) and campaign IDs are tagged in the threatsInfoMap field. For example, each ProofpointPODMessage_CL record may carry a sender_s (sender email domain hashed), recipient list, subject, and any detected threat type (Phish/Malware/Spam/Impostor) with associated threat hash or URL. Deployment: Proofpoint POD uses Sentinel’s codeless connector (an Azure Function behind the scenes). You must provide Proofpoint API credentials (Cluster ID and API token) in the connector UI. The connector periodically calls the Proofpoint SIEM API to fetch new log events (typically in 1–2 hour batches). The data lands in the above tables. (Older custom logic-app approaches similarly parse JSON output from the /v2/siem/messages endpoints.) Proofpoint TAP (Targeted Attack Protection) Connector Proofpoint TAP provides user-click and message-delivery events. Its connector creates four tables: ProofPointTAPMessagesDeliveredV2_CL, ProofPointTAPMessagesBlockedV2_CL, ProofPointTAPClicksPermittedV2_CL, and ProofPointTAPClicksBlockedV2_CL. The message tables report emails with detected threats (URL or attachment defense) that were delivered or blocked by TAP. They include the same fields as POD (message GUID, sender, recipients, subject, threat campaign ID, scores, attachments info). The click tables log when users click on URLs: each record has the URL, click timestamp (clickTime), the user’s IP (clickIP), user-agent, the message GUID, and the threat ID/category. These fields allow you to see who clicked which malicious link and when. As the connector description notes, these logs give “visibility into Message and Click events in Microsoft Sentinel” for hunting. Deployment: The TAP connector also uses the codeless framework. You supply a TAP API service principal and secret (proofpoint SIEM API credentials) in the Sentinel content connector. The function app calls TAP’s /v2/siem/clicks/blocked, /permitted, /messages/blocked, and /delivered endpoints. The Proofpoint SIEM API limits queries to 1-hour windows and 7-day history, with no paging (all events in the interval are returned). (A Logic App approach could also be used, as shown in the Tech Community blog: one HTTP GET per event type and a JSON Parse before sending to Log Analytics.) Mimecast Secure Email Gateway Connector The Mimecast connector ingests the Secure Email Gateway (SEG) logs and targeted-threat (TTP) logs. Inbound, outbound and internal mail events from the Mimecast MTA (receipt, processing, delivery stages) are pulled via the API. Typical fields include the unique message ID (aCode), sender, recipient, subject, attachment count/names, and the policy actions or holds (e.g. spam quarantine). For example, the Mimecast “Process” log shows AttCnt, AttNames, and if the message was held (Hld) for review. Delivery logs include the success/failure and TLS details. In addition, Mimecast TTP logs are collected: URL Protect logs (when a user clicks a blocked URL) include the clicked URL (url), category (urlCategory), sender/recipient, and block reason. Impersonation Protect logs capture spoofing detections (e.g. if an internal name is impersonated), with fields like Sender, Recipient, Definition and Action (hold/quarantine). Attachment Protect logs record malicious file detections (filename, hash, threat type). Deployment: Like Proofpoint, Mimecast’s connector uses Azure Functions via the Sentinel content hub. You install the Mimecast solution, open the connector page, then enter Azure app credentials and Mimecast API keys (API Application ID/Key and Access/Secret for the service account). As shown in the deployment guide, you must provide the Azure Subscription, Resource Group, Log Analytics Workspace and the Azure Client (App) ID, Tenant ID and Object ID of the admin performing the setup. On the Mimecast side, you supply the API Base URL (regional), App ID/Secret and user Access/Secret. The connector creates a Function App that polls Mimecast’s SIEM APIs on a cron schedule (default every 30 minutes). You can optionally specify a start date for backfilling up to 7 days of logs. The default tables are MimecastSIEM_CL (for email flow logs) and MimecastDLP_CL (for DLP/TTP events), though custom names can be set. Ingestion Considerations Data Latency: All these connectors are pull-based and typically run on a schedule (often 30–60 minutes). For example, the Proofpoint POD docs note hourly log increments, and Mimecast logs are aggregated every 30 minutes. Expect a delay of up to an hour or more from event occurrence to Sentinel ingestion. Schema Nuances: The APIs often return nested arrays and optional fields. For instance, the Proofpoint blog warns that some JSON fields can be null or vary in type, so the parse schema should account for all possibilities. Similarly, Mimecast logs come in pipe-delimited or JSON format, with values sometimes empty (e.g. no attachments). In KQL, use tostring() or parse_json() on the raw _CL columns, and mv-expand on any multivalue fields (like message parts or threat lists). Table Names: Use the connector’s tables as listed. For Proofpoint: ProofpointPODMailLog_CL and ProofpointPODMessage_CL; for TAP: ProofPointTAPMessagesDeliveredV2_CL, ProofPointTAPMessagesBlockedV2_CL, ProofPointTAPClicksPermittedV2_CL, ProofPointTAPClicksBlockedV2_CL. For Mimecast SEG/TTP: MimecastSIEM_CL (seg logs) and MimecastDLP_CL (TTP logs). API Behavior: The Proofpoint TAP API has no paging. Be aware of timezones (Proofpoint uses UTC) and use the Sentinal ingestion TimeGenerated or event timestamp fields for binning. Detection Engineering and Correlation To detect phishing effectively, we correlate these email logs with identity, endpoint and intel data: Identity (Azure AD): Mail logs contain recipient addresses and (hashed) sender user parts. A common tactic is to correlate SMTP recipients or sender domains with Azure AD user records. For example, join TAP clicks by recipient to the user’s UPN. The Proofpoint logs also include the clicker’s IP (clickIP); we can match that to Azure AD sign-in logs or VPN logs to find which device/location clicked a malicious link. Likewise, anomalous Azure AD sign-ins (impossible travel, MFA failure) after a suspicious email can strengthen the case. Endpoints (Defender): Once a user clicks a bad link or opens a malicious attachment (captured in TAP or Mimecast logs), watch for follow-on behaviors. For instance, use Sentinel’s DeviceSecurityEvents or DeviceProcessEvents to see if that user’s machine launched unusual processes. The threatID or URL hash from email events can be looked up in Defender’s file data. Correlate by username (if available) or IP: if the email log shows a link click from IP X, see if any endpoint alerts or logon events occurred from X around the same time. As the Mimecast integration touts, this enables “correlation across Mimecast events, cloud, endpoint, and network data”. Threat Intelligence: Use Sentinel’s ThreatIntelligenceIndicator tables or Microsoft’s TI feeds to tag known bad URLs/domains in the email logs. For example, join ProofPointTAPClicksBlockedV2_CL on the clicked url against ThreatIntelligenceIndicator (type=URL) to automatically flag hits. Proofpoint’s logs already classify threats (malware/phish) and provide a threatID; one can enrich that with external intel (e.g. check if the hash appears in TI feeds). Mimecast’s URL logs include a urlCategory field, which can be mapped to known malicious categories. Automated playbooks can also pull Intel: e.g. use Sentinel’s TI REST API or Azure Sentinel watchlists containing phishing domains to annotate events. In summary, a robust detection strategy might look like: (1) Identify malicious email events (high phish scores, quarantines, URL clicks). (2) Correlate these events by user with Azure AD logs (did the user log in from a new IP after a phish click?). (3) Correlate with endpoint alerts (Defender found malware on that device). (4) Augment with threat intelligence lookups on URLs and attachments from the email logs. By linking the Proofpoint/Mimecast signals to identity and endpoint events, one can detect the full attack chain from email compromise to endpoint breach. KQL Query Here are representative Kusto queries for common phishing scenarios (adapt table/field names as needed): Malicious URL Click Detection: Identify users who clicked known-malicious URLs. For example, join TAP click logs to TI indicators:This flags any permitted click where the URL matches a known threat indicator. Alternatively, aggregate by domain: let TI = ThreatIntelligenceIndicator | where Active == true and _EntityType == "URL"; ProofPointTAPClicksPermittedV2_CL | where url_s != "" | project ClickTime=TimeGenerated, Recipient=recipient_s, URL=url_s, SenderIP=senderIP_s | join kind=inner TI on $left.URL == TI._Value | project ClickTime, Recipient, URL, Description=TI.Description This flags any permitted click where the URL matches a known threat indicator. Alternatively, aggregate by domain: ProofPointTAPClicksPermittedV2_CL | extend clickedDomain = extract(@"https?://([^/]+)", 1, url_s) | summarize ClickCount=count() by clickedDomain | where clickedDomain has "maliciousdomain.com" or clickedDomain has "phish.example.com" Quarantine Spike (Burst) Detection: Detect sudden spikes in quarantined messages. For example, using POD mail log:This finds hours with an unusually high number of held (quarantined) emails, which may indicate a phishing campaign. You could similarly use ProofPointTAPMessagesBlockedV2_CL. ProofpointPODMailLog_CL | where action_s == "Held" | summarize HeldCount=count() by bin(TimeGenerated, 1h) | order by TimeGenerated desc | where HeldCount > 100 Targeted User Phishing: Find if a specific user received multiple malicious emails. E.g., for user email address removed for privacy reasons:This lists recent phish attempts targeting Username. You might also join with TAP click logs to see if she clicked anything. ProofpointPODMessage_CL | where recipient has "email address removed for privacy reasons" | where array_length(threatsInfoMap) > 0 and threatsInfoMap_classification_s == "Phish" | project TimeGenerated, sender_s, subject_s, threat=threatsInfoMap_threat_s Campaign-Level Analysis: Group emails by Proofpoint campaign ID to see scope of each campaign:This shows each campaign ID with how many unique recipients were hit and one example subject. Combining TAP and POD tables on GUID_s or QID_s can further link click events back to the originating message/campaign. ProofpointPODMessage_CL | mv-expand threatsInfoMap | summarize Recipients=make_set(recipient), Count=dcount(recipient) by CampaignID=threatsInfoMap_campaignId_s | project CampaignID, RecipientCount=Count, Recipients, SampleSubject=any(subject_s) Each query can be refined (for instance, filtering only within a recent time window) and embedded in Sentinel Analytics rules or hunting. The key is using the connectors’ fields – URLs, sender/recipient addresses, campaign IDs – to pivot between email data and other security signals.Cloud Posture + Attack Surface Signals in Microsoft Sentinel (Prisma Cloud + Cortex Xpanse)
Microsoft expanded Microsoft Sentinel’s connector ecosystem with Palo Alto integrations that pull cloud posture, cloud workload runtime, and external attack surface signals into the SIEM, so your SOC can correlate “what’s exposed” and “what’s misconfigured” with “what’s actively being attacked.” Specifically, the Ignite connectors list includes Palo Alto: Cortex Xpanse CCF and Palo Alto: Prisma Cloud CWPP. Why these connectors matter for Sentinel detection engineering Traditional SIEM pipelines ingest “events.” But exposure and posture are just as important as the events—because they tell you which incidents actually matter. Attack surface (Xpanse) tells you what’s reachable from the internet and what attackers can see. Posture (Prisma CSPM) tells you which controls are broken (public storage, permissive IAM, weak network paths). Runtime (Prisma CWPP) tells you what’s actively happening inside workloads (containers/hosts/serverless). In Sentinel, these become powerful when you can join them with your “classic” telemetry (cloud activity logs, NSG flow logs, DNS, endpoint, identity). Result: fewer false positives, faster triage, better prioritization. Connector overview (what each one ingests) 1) Palo Alto Prisma Cloud CSPM Solution What comes in: Prisma Cloud CSPM alerts + audit logs via the Prisma Cloud CSPM API. What it ships with: connector + parser + workbook + analytics rules + hunting queries + playbooks (prebuilt content). Best for: Misconfig alerts: public storage, overly permissive IAM, weak encryption, risky network exposure. Compliance posture drift + audit readiness (prove you’re monitoring and responding). 2) Palo Alto Prisma Cloud CWPP (Preview) What comes in: CWPP alerts via Prisma Cloud API (Compute/runtime side). Implementation detail: Built on Codeless Connector Platform (CCP). Best for: Runtime detections (host/container/serverless security alerts) “Exploit succeeded” signals that you need to correlate with posture and exposure. 3) Palo Alto Cortex Xpanse CCF What comes in: Alerts logs fetched from the Cortex Xpanse API, ingested using Microsoft Sentinel Codeless Connector Framework (CCF). Important: Supports DCR-based ingestion-time transformations that parse to a custom table for better performance. Best for: External exposure findings and “internet-facing risk” detection Turning exposure into incidents only when the asset is critical / actively targeted. Reference architecture (how the data lands in Sentinel) Here’s the mental model you want for all three: flowchart LR A[Palo Alto Prisma Cloud CSPM] -->|CSPM API: alerts + audit logs| S[Sentinel Data Connector] B[Palo Alto Prisma Cloud CWPP] -->|Prisma API: runtime alerts| S C[Cortex Xpanse] -->|Xpanse API: exposure alerts| S S -->|CCF/CCP + DCR Transform| T[(Custom Tables)] T --> K[KQL Analytics + Hunting] K --> I[Incidents] I -->P[SOAR Playbooks] K --> W[Workbooks / Dashboards] Key design point: Xpanse explicitly emphasizes DCR transformations at ingestion time, use that to normalize fields early so your queries stay fast under load. Deployment patterns (practical, SOC-friendly setup) Step 0 — Decide what goes to “analytics” vs “storage” If you’re using Sentinel’s data lake strategy, posture/exposure data is a perfect candidate for longer retention (trend + audit), while only “high severity” may need real-time analytics. Step 1 — Install solutions from Content Hub Install: Palo Alto Prisma Cloud CSPM Solution Palo Alto Prisma Cloud CWPP (Preview) Palo Alto Cortex Xpanse CCF Step 2 — Credentials & least privilege Create dedicated service accounts / API keys in Palo Alto products with read-only scope for: CSPM alerts + audit CWPP alerts Xpanse alerts/exposures Step 3 — Validate ingestion (don’t skip this) In Sentinel Logs: Locate the custom tables created by each solution (Tables blade). Run a basic sanity query: “All events last 1h” “Top 20 alert types” “Distinct severities” Tip: Save “ingestion smoke tests” as Hunting queries so you can re-run them after upgrades. Step 4 — Turn on included analytics content (then tune) The Prisma Cloud CSPM solution comes with multiple analytics rules, hunting queries, and playbooks out of the box—enable them gradually and tune thresholds before going wide. Detection engineering: high-signal correlation recipes Below are patterns that consistently outperform “single-source alerts.” I’m giving them as KQL templates using placeholder table names because your exact custom table names/columns are workspace-dependent (you’ll see them after install). Recipe 1 — “Internet-exposed + actively probed” (Xpanse + network logs) Goal: Only fire when exposure is real and there’s traffic evidence. let xpanse = <XpanseTable> | where TimeGenerated > ago(24h) | where Severity in ("High","Critical") | project AssetIp=<ip_field>, Finding=<finding_field>, Severity, TimeGenerated; let net = <NetworkFlowTable> | where TimeGenerated > ago(24h) | where Direction == "Inbound" | summarize Hits=count(), SrcIps=make_set(SrcIp, 50) by DstIp; xpanse | join kind=inner (net) on $left.AssetIp == $right.DstIp | where Hits > 50 | project TimeGenerated, Severity, Finding, AssetIp, Hits, SrcIps Why it works: Xpanse gives you exposure. Flow/WAF/Firewall gives you intent. Recipe 2 — “Misconfiguration that creates a breach path” (CSPM + identity or cloud activity) Goal: Prioritize posture findings that coincide with suspicious access or admin changes. let posture = <PrismaCSPMTable> | where TimeGenerated > ago(7d) | where PolicySeverity in ("High","Critical") | where FindingType has_any ("Public", "OverPermissive", "NoMFA", "EncryptionDisabled") | project ResourceId=<resource_id>, Finding=<finding>, PolicySeverity, FirstSeen=TimeGenerated; let activity = <CloudActivityTable> | where TimeGenerated > ago(7d) | where OperationName has_any ("RoleAssignmentWrite","SetIamPolicy","AddMember","CreateAccessKey") | project ResourceId=<resource_id>, Actor=<caller>, OperationName, TimeGenerated; posture | join kind=inner (activity) on ResourceId | project PolicySeverity, Finding, OperationName, Actor, FirstSeen, TimeGenerated | order by PolicySeverity desc, TimeGenerated desc Recipe 3 — “Runtime alert on a workload that was already high-risk” (CWPP + CSPM) Goal: Raise severity when runtime alerts occur on assets with known posture debt. let risky_assets = <PrismaCSPMTable> | where TimeGenerated > ago(30d) | where PolicySeverity in ("High","Critical") | summarize RiskyFindings=count() by AssetId=<asset_id>; <CWPPTable> | where TimeGenerated > ago(24h) | project AssetId=<asset_id>, AlertName=<alert>, Severity=<severity>, TimeGenerated, Details=<details> | join kind=leftouter (risky_assets) on AssetId | extend RiskScore = coalesce(RiskyFindings,0) | order by Severity desc, RiskScore desc, TimeGenerated desc SOC outcome: same runtime alert, different priority depending on posture risk. Operational (in real life) 1) Normalize severities early If Xpanse is using DCR transforms (it is), normalize severity to a consistent enum (“Informational/Low/Medium/High/Critical”) to simplify analytics. 2) Deduplicate exposure findings Attack surface tools can generate repeated findings. Use a dedup function (hash of asset + finding type + port/service) and alert only on “new or changed exposure.” 3) Don’t incident-everything Treat CSPM findings as: Incidents only when: critical + reachable + targeted OR tied to privileged activity Tickets when: high risk but not active Backlog when: medium/low with compensating controls 4) Make SOAR “safe by default” Automations should prefer reversible actions: Block IP (temporary) Add to watchlist Notify owners Open ticket with evidence bundle …and only escalate to destructive actions after confidence thresholds.
Strengthening calendar security through enhanced remediation
In today’s evolving threat landscape, phishing attacks are becoming increasingly sophisticated, often leveraging meeting invites to bypass traditional defenses. While Security Operations (SOC) teams rely on Microsoft Defender’s remediation actions to remove malicious emails, a hidden risk persists: calendar entries created by Outlook during email delivery. These entries can remain active even after the email is deleted, leaving users exposed to harmful content. This update addresses that gap. Remediation supports cleaning up calendar entries SOC teams currently use remediation actions such as Move to Junk, Delete, Soft Delete, and Hard Delete to quickly eliminate email threats from user inboxes. However, meeting invite emails introduce an additional challenge. Even after the email is removed, Outlook automatically creates a calendar entry during delivery, which remains accessible to users. For example, consider a phishing email sent as a meeting invite. Despite the admin removing the email from the user’s inbox, the user can still interact with the same malicious content via the calendar entry. This residual entry may contain harmful links or phishing content, creating a security gap. With this update, we’re taking the first step toward closing that gap. Hard Delete will now also remove the associated calendar entry for any meeting invite email. This ensures threats are fully eradicated—not just from the inbox but also from the calendar—reducing the risk of user interaction with malicious content. This change applies to Hard Delete actions taken from any surface, including Explorer, Advanced Hunting, and API. Note: 1) Deleted calendar entries can be restored by resending the meeting invite. 2) This action does not remove calendar entries manually added by users via .ics files. Ability to Block URL domains via submission/TABL actions from Explorer SOC teams can currently add senders and URLs to the TABL block list when submitting false negatives to Microsoft. However, phishing campaigns often use variations of URLs under the same parent domain, making full URL blocking less effective. With this update, TABL options for URL domains are now dynamically surfaced, enabling SOC teams to block entire domains without leaving their workflow. This enhancement simplifies remediation and strengthens defenses against domain-based phishing attacks. These updates strengthen SOC remediation workflows by closing critical security gaps and ensuring threats are fully neutralized across all user touchpoints. By extending remediation to calendar entries and enabling domain-level URL blocking, we deliver comprehensive protection that reduces risk, streamlines operations, and safeguards user experiences. At Microsoft, our priority is your security, and we remain committed to empowering SOC teams with tools that make defense smarter and more effective. Learn more: Remediate malicious email that was delivered in Office 365 - Microsoft Defender for Office 365 | Microsoft LearnUnifying AWS and Azure Security Operations with Microsoft Sentinel
The Multi-Cloud Reality Most modern enterprises operate in multi-cloud environments using Azure for core workloads and AWS for development, storage, or DevOps automation. While this approach increases agility, it also expands the attack surface. Each platform generates its own telemetry: Azure: Activity Logs, Defender for Cloud, Entra ID sign-ins, Sentinel analytics AWS: CloudTrail, GuardDuty, Config, and CloudWatch Without a unified view, security teams struggle to detect cross-cloud threats promptly. That’s where Microsoft Sentinel comes in, bridging Azure and AWS into a single, intelligent Security Operations Center (SOC). Architecture Overview Connect AWS Logs to Sentinel AWS CloudTrail via S3 Connector Enable the AWS CloudTrail connector in Sentinel. Provide your S3 bucket and IAM role ARN with read access. Sentinel will automatically normalize logs into the AWSCloudTrail table. AWS GuardDuty Connector Use the AWS GuardDuty API integration for threat detection telemetry. Detected threats, such as privilege escalation or reconnaissance, appear in Sentinel as the AWSGuardDuty table. Normalize and Enrich Data Once logs are flowing, enrich them to align with Azure activity data. Example KQL for mapping CloudTrail to Sentinel entities: AWSCloudTrail | extend AccountId = tostring(parse_json(Resources)[0].accountId) | extend User = tostring(parse_json(UserIdentity).userName) | extend IPAddress = tostring(SourceIpAddress) | project TimeGenerated, EventName, User, AccountId, IPAddress, AWSRegion Then correlate AWS and Azure activities: let AWS = AWSCloudTrail | summarize AWSActivity = count() by User, bin(TimeGenerated, 1h); let Azure = AzureActivity | summarize AzureActivity = count() by Caller, bin(TimeGenerated, 1h); AWS | join kind=inner (Azure) on $left.User == $right.Caller | where AWSActivity > 0 and AzureActivity > 0 | project TimeGenerated, User, AWSActivity, AzureActivity Automate Cross-Cloud Response Once incidents are correlated, Microsoft Sentinel Playbooks (Logic Apps) can automate your response: Example Playbook: “CrossCloud-Containment.json” Disable user in Entra ID Send a command to the AWS API via Lambda to deactivate IAM key Notify SOC in Teams Create ServiceNow ticket POST https://api.aws.amazon.com/iam/disable-access-key PATCH https://graph.microsoft.com/v1.0/users/{user-id} { "accountEnabled": false } Build a Multi-Cloud SOC Dashboard Use Sentinel Workbooks to visualize unified operations: Query 1 – CloudTrail Events by Region AWSCloudTrail | summarize Count = count() by AWSRegion | render barchart Query 2 – Unified Security Alerts union SecurityAlert, AWSGuardDuty | summarize TotalAlerts = count() by ProviderName, Severity | render piechart Scenario Incident: A compromised developer account accesses EC2 instances on AWS and then logs into Azure via the same IP. Detection Flow: CloudTrail logs → Sentinel detects unusual API calls Entra ID sign-ins → Sentinel correlates IP and user Sentinel incident triggers playbook → disables user in Entra ID, suspends AWS IAM key, notifies SOC Strengthen Governance with Defender for Cloud Enable Microsoft Defender for Cloud to: Monitor both Azure and AWS accounts from a single portal Apply CIS benchmarks for AWS resources Surface findings in Sentinel’s SecurityRecommendations tableYou may be right after all! Disputing Submission Responses in Microsoft Defender for Office 365
Introduction As a Microsoft MVP (Most Valuable Professional) specializing in SIEM, XDR, and Cloud Security, I have witnessed the rapid evolution of cybersecurity technologies, especially those designed to protect organizations from sophisticated threats targeting email and collaboration tools. Microsoft Defender for Office 365 introduced an LLM-based engine to help better classify phishing emails that, these days, are mostly written using AI anyways about a year ago. Today, I'm excited to spotlight a new place AI has been inserted into a workflow to make it better…a feature that elevates the transparency and responsiveness of threat management: the ability to dispute a submission response directly within Microsoft Defender for Office 365. Understanding the Challenge While the automated and human-driven analyses are robust in Defender for Office 365, there are occasions where the response—be it a verdict of "benign" or "malicious"— doesn’t fully align with the security team's context or threat intelligence. If you are a Microsoft 365 organization with Exchange Online mailboxes, you’re probably familiar with how admins can use the Submissions page in the Microsoft Defender portal to submit messages, URLs, and attachments to Microsoft for analysis. As a recent enhancement, now all the admin submissions use LLM based response for better explainability. In the past, disputing such verdicts required separate support channels, using Community support, or manual email processes, often delaying resolution and impacting the speed of cyber operations. Introducing the Dispute Submission Response Feature With the new dispute submission response feature, Microsoft Defender for Office 365 bridges a critical gap in the incident response workflow. Now, when a security analyst or administrator receives a verdict on a submitted item, they have the option to dispute the response directly within the Microsoft 365 Defender portal. This feature streamlines feedback, allowing teams to quickly flag disagreements and provide additional context for review at the speed of operations. How It Works Upon submission of a suspicious item, Microsoft Defender for Office 365 provides a response indicating its assessment—malicious, benign, or other categorizations. If the security team disagrees with the verdict, they can select the "Dispute" option and submit their rationale, including supporting evidence and threat intelligence. The disputed case is escalated directly to Microsoft’s threat research team for further review, and the team is notified of progress and outcomes. This direct feedback loop not only empowers security teams to advocate for their organization's unique context, but also enables Microsoft to continually refine detection algorithms and verdict accuracy based on real-world input, because security is a team sport. Benefits for Security Operations Faster Resolution: Streamlined dispute submission eliminates the need for external support tickets and escalations, reducing turnaround time for critical cases. Greater Transparency: The feature fosters a collaborative relationship between customers and Microsoft, ensuring that verdicts are not final judgments but points in an ongoing dialogue. Continuous Improvement: Feedback from disputes enhances Microsoft’s threat intelligence and improves detection for all Defender for Office 365 users. Empowerment: Security teams gain a stronger voice in the protection of their environment, reinforcing trust in automated defenses. MVP Insights: Real-World Impact Having worked with global enterprises, I’ve seen how nuanced and context-specific threats can be. Sometimes, what appears benign to one organization may be a targeted attack for another, a slight modification to a URL may catch one email, but not others, as slight changes are made as billions of emails are sent. We are only as good as the consortium. The ability to dispute submission responses creates a vital safety net, ensuring that security teams are not forced to accept verdicts that could expose them to risk. It’s a welcome step toward adaptive, user-driven security operations. Conclusion The dispute submission response feature in Microsoft Defender for Office 365 is one of the most exciting features for me, because it focuses on enabling organizations striving for agility and accuracy in threat management. By enabling direct, contextual feedback, Microsoft empowers security teams to play an active role in shaping their defenses. As an MVP, I encourage all users to leverage this feature, provide detailed feedback, and help drive the future of secure collaboration in the cloud. You may be right after all. _________ This blog has been generously and expertly authored by Microsoft Security MVP, Mona Ghadiri with support of the Microsoft Defender for Office 365 product team. Mona Ghadiri Microsoft Security MVP Learn More and Meet the Author 1) December 16th Ask the Experts Webinar: Microsoft Defender for Office 365 | Ask the Experts: Tips and Tricks (REGISTER HERE) DECEMBER 16, 8 AM US Pacific You’ve watched the latest Microsoft Defender for Office 365 best practices videos and read the blog posts by the esteemed Microsoft Most Valuable Professionals (MVPs). Now bring your toughest questions or unique situations straight to the experts. In this interactive panel discussion, Microsoft MVPs will answer your real-world scenarios, clarify best practices, and highlight practical tips surfaced in the recent series. We’ll kick off with a who’s who and recent blog/video series recap, then dedicate most of the time to your questions across migration, SOC optimization, fine-tuning configuration, Teams protection, and even Microsoft community engagement. Come ready with your questions (or pre-submit here) for the expert Security MVPs on camera, or the Microsoft Defender for Office 365 product team in the chat! REGISTER NOW for 12/16. 2) Additional MVP Tips and Tricks Blogs and Videos in this Four-Part Series: 1. Microsoft Defender for Office 365: Migration & Onboarding by Purav Desai 2. Safeguarding Microsoft Teams with Microsoft Defender for Office 365 by Pierre Thoor 3. (This blog post) You may be right after all! Disputing Submission Responses in Microsoft Defender for Office 365 by Mona Ghadiri 4. Microsoft Defender for Office 365: Fine-Tuning | Real-world Defender for Office 365 tuning that closes real attack paths by Joe Stocker Learn and Engage with the Microsoft Security Community Log in and follow this Microsoft Defender for Office 365 blog and follow/post in the Microsoft Defender for Office 365 discussion space. Follow = Click the heart in the upper right when you're logged in 🤍 Learn more about the Microsoft MVP Program. Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more. Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Customer Connection Community. Join the Microsoft Security Community LinkedInMicrosoft Ignite 2025: Transforming Phishing Response with Agentic Innovation
Phishing attacks remain one of the most persistent and damaging threats to organizations worldwide. Security teams are under constant pressure to investigate a growing number of user reported phishing emails daily, ensuring accurate verdicts and timely responses. As threats grow in volume and sophistication, SOC teams are forced to spend valuable time triaging and investigating, often at the expense of strategic defense and proactive threat hunting. At Microsoft Ignite 2025 we are delivering innovation that showcases our continued commitment to infuse AI agents, and agentic workflows into the core of our email security solution and SOC operations to automate repetitive tasks, accelerate investigations, and provide transparent, actionable insights for every reported phishing email. In addition, we continue to invest in our ecosystem partnerships to empower customers with seamless integrations, as they adopt layered security solutions to comply with regulatory requirements, enhance detection, and ensure robust protection. Today I’m excited to announce: General Availability of the Security Copilot Phishing Triage Agent Agentic Email Grading System in Microsoft Defender Cisco and VIPRE Security Group join the Microsoft Defender ICES ecosystem The Security Copilot Phishing Triage Agent is now generally available In March 2025, we introduced the Phishing Triage Agent, designed to autonomously handle user-submitted phishing reports at scale. The agent classifies incoming alerts, resolves false positives, and escalates only the malicious cases that require human expertise. Today, we’re announcing its general availability. We will also be extending the agent to triage alerts for identity and cloud alerts. The Phishing triage agent automates repetitive tasks, accelerates investigations, and every decision is transparent, allowing security teams to focus on what matters most—investigating real threats and strengthening the overall security posture. Early results prove how it is transforming analyst work: Identified 6.5X more malicious alerts Improved verdict accuracy by 77% Agent supported analysts spent 53% more time investigating real threats Agentic email grading: Advanced analysis of phishing email submissions When customers report suspicious messages to Microsoft, they expect clarity, speed, and actionable insights to protect their environment. They expect a response they can trust, understand easily, and take additional investigation and response action for the organization. Previously, when customers reported messages to Microsoft, our response depended largely on manual human grader reviews, creating delays and inconsistent verdicts. Customers often waited several hours for a response, and sometimes it lacked clarity on how a verdict was reached. Today, we are excited to announce that we integrated an agentic grading system into the Microsoft Defender submission analysis and response workflow when customers report phishing messages to Microsoft. Image 2: Agentic Email Grading: Advanced analysis of phishing email submissions The agentic grading system brings a new level of speed and transparency to phishing analysis. It uses large language models (LLMs) orchestrated within an agentic workflow to analyze phishing emails, assess the full content of a submitted email, and communicate context and related metadata. This system combines advanced AI with existing machine learning models and human review for additional levels of accuracy and transparency for decision making. Every verdict comes with higher quality, clear verdicts, and context-rich explanations tailored to each phishing email submission. Additionally, it establishes a feedback mechanism that enhances continuous learning and self-healing, thereby strengthening and optimizing protection over time. By reducing reliance on manual reviews, users will experience lower wait times, faster responses and higher-quality results. It will enable security teams to respond promptly and act confidently against phishing threats. Over time we plan to expand beyond phishing verdicts to include spam, scam, bulk, and clean classifications, making the process more comprehensive. The system will continue to evolve through feedback and adapt to emerging attack patterns. How to view agentic submission responses in Microsoft Defender When you report a suspicious email—whether as an admin or an end user—you can now see how Microsoft Defender’s new agentic grading system evaluates your submission. To view agentic grading system responses, follow the steps below: Report the suspicious email Submit the email through the admin submission or user-reported submission process. Sign in to Microsoft Defender Go to https://security.microsoft.com. Navigate to Submissions From the left menu, select: Investigation & response > Actions & submissions > Submissions. Choose the correct tab Emails for admin submissions User reported for user submissions Open the submission details Click the email submission you want to review. A flyout panel will display Result details. Look for the Agentic AI note If the verdict was generated by Agentic AI, you’ll see: “AI-generated content may be incorrect. Check it for accuracy.” Image 3: AI generated explainable verdicts Expanding the Integrated Cloud Email Security (ICES) ecosystem In June, we introduced the Microsoft Defender ICES vendor ecosystem, a unified framework that enables seamless integration of Microsoft’s Defender’s email security solution with trusted third-party vendors. Today we are excited to announce two new partners: Cisco and VIPRE Security Group. The addition of these partners to our ecosystem reinforces our ongoing commitment to support customers in their choice to strategically layer their email security solutions. Organizations benefit from a unified quarantine experience, and a deep integration across the various SOC experiences including threat explorer, advanced hunting, and the email entity page, while providing clear insight into detection efficacy of each solution. As we continue to innovate, our commitment remains steadfast: empowering defenders with intelligent, transparent, and integrated security solutions that adapt to the evolving threat landscape. By infusing agentic AI into every layer of Microsoft Defender, expanding our ecosystem of trusted partners, and delivering faster, more actionable insights, we’re helping organizations build resilience and stay ahead of attackers. Our strategy is rooted in delivering real value making security simpler, more effective, and adapted to the needs of every customer. Learn More: Want to know what else is new in Microsoft Defender at Ignite 2025 check out the blog here. For info on how to complete admin phish submissions, please see For end user reported phish submissions, you need to have it configured for reporting messages to Microsoft. Set it up today. Join us at Microsoft Ignite Join us at Microsoft Ignite to see these advancements in action and discover how intelligent, agentic defense is becoming accessible to every organization. Don’t miss our featured sessions: AI vs AI: Protect email and collaboration tools with Microsoft Defender on Thursday, November 20 th . Learn More. Microsoft Defender: Building the agentic SOC with guest Allie Mellen on Wednesday, November 19 th . Learn more. Empowering the SOC: Security Copilot and the rise of Agentic Defense on Friday, November 21 st . Learn more.Safeguarding Microsoft Teams with Microsoft Defender for Office 365
As organizations rely more on Microsoft Teams for daily collaboration, securing this platform has become a top priority. Threat actors are increasingly targeting Teams chats and channels with phishing links and malicious files, making it critical for IT admins and security professionals to extend protection beyond email. Enter Microsoft Defender for Office 365, now armed with dedicated Teams protection capabilities. Microsoft Defender for Office 365 enables users to report suspicious messages, brings time-of-click scanning of URLs and files into Teams conversations, and provides rich alerts and hunting insights for SecOps teams. As a collaborative piece between Pierre Thoor, a Microsoft Security Most Valuable Professional (MVP), and the Defender for Office 365 Product Engineering Team, the below guides with accompanying videos emphasize a proactive, user-driven approach to threat detection and response, turning everyday Teams interactions into actionable security signals for SecOps. See something, say something: Reporting suspicious messages in Microsoft Teams Your fastest sensor isn’t AI – it’s your people. Report this message in Microsoft Teams lets anyone flag a suspicious conversation in two clicks and routes a triageable submission to your security team in the Microsoft Defender portal. Why this matters: Speed to signal: Catch threats at the conversation layer, not just in email. Complete context: Original message, participants, URLs, and verdicts in one place. Habit-forming: A simple, repeatable action employees remember under pressure. How to report (desktop, web, and mobile) In Desktop/Web Hover the message → … More options → Report this message Select Security concern → (optional) add a short note → Report In Mobile (iOS/Android) app Long-press the message → Report message Select Security concern → (optional) add a short note → Report *Tip: Short notes like “Unexpected MFA reset link” help analysts triage faster. Where reports go (for security teams) In the Microsoft Defender portal, navigate to: Investigation & response → Actions and submissions → Submissions → User reported. Open an item to view the Teams message entity (sender/domain, Teams message ID, extracted URLs, verdict) and take action – mark as phish/clean, pivot to Explorer or Advanced Hunting, or copy indicators. Quick setup check Defender portal → Settings → Email & collaboration → User reported settings: enable Monitor reported messages in Microsoft Teams. Licensing: Microsoft Defender for Office 365 Plan 2 (included in Microsoft 365 E5). What good looks like (mini playbook) User reports the message. Security triages the submission and captures the URL/domain and other indicators. Block or allow as appropriate via the Tenant Allow/Block List (TABL). Hunt for related activity or clicks (see Video 3). Close the loop: thank the reporter and share the outcome to reinforce the behavior. Common gotchas Reporting is disabled in the Teams messaging policy – verify before rollout. Some users assume “Report” notifies the sender – clarify that it routes to the Security team, not the sender. Call to action: Enable reporting for your users and add this line to your awareness site: “If it feels phishy, report – don’t click.” Think before you click - Safe Links catches threats at click-time Links can change after delivery. Safe Links waits until click-time, evaluates the destination, and shows an in-app warning page in Teams. Pair it with the Tenant Allow/Block List (TABL) to tune quickly across the tenant. Why this matters Prevents delayed redirects: Avoids “clean-at-send” methods. Consistent protection in Teams: Familiar warning UX reduces risky clicks. Rapid tuning: Block newly observed domains in seconds; no advanced transport rules required. What you’ll see in the video Policy check (Teams in scope) Defender portal → Email & collaboration → Policies & rules → Threat policies → Safe Links → ensure Apply Safe Links to Microsoft Teams is enabled for target users or groups OR that you use Standard/Strict Preset Policy. Warning page at click-time Post a benign test URL in Teams and click it to show the Safe Links warning experience. Block it as you spot it (Allow/Block) Defender portal → Threat policies → Tenant Allow/Block List → URLs → Add (domain or URL). Re-click in Teams – now blocked at click-time. Optional telemetry (Advanced Hunting) Confirm outcomes and adoption: UrlClickEvents | where Timestamp > ago(24h) and Workload == "Teams" | summarize Clicks=count(), Users=dcount(AccountUpn) by ActionType | order by Clicks desc Deployment tips Start with a pilot group that includes IT + power users; expand after validation. Create a review cadence for TABL (e.g., monthly) and expire temporary blocks. Troubleshooting No warning page? Verify policy scope includes the user and the Teams workload. Block not taking effect? Give TABL a short sync window, then re-test; confirm you blocked the correct domain/URL pattern. “Hunt the chat”: Advanced hunting for Teams threats Overview With Advanced Hunting you can quickly reconstruct activity in Microsoft Teams – who sent the message, who clicked the link, and what protections kicked in. This section shows how the four Teams-relevant tables work together, so you can move from signal to action quickly. New: message warnings for malicious URLs (internal and external) Teams now shows a warning banner on messages that contain URLs flagged as spam, phishing, or malware. Warnings appear in internal and external chats/channels, and can be added after delivery (up to ~48 hours) if a URL’s reputation changes. This complements Safe Links (time-of-click) and doesn’t replace ZAP; when ZAP removes a message, that action takes precedence. Public preview began September 2025; GA November 2025, enabled by default at GA and manageable in Teams admin center → Messaging settings. See Message Center: https://admin.cloud.microsoft/?#/MessageCenter/:/messages/MC1150984 The four tables you’ll use MessageEvents – delivery context (sender, thread, internal vs. external). MessagePostDeliveryEvents – post-delivery actions, including Phish ZAP and Malware ZAP. MessageUrlInfo – URLs extracted from Teams messages. UrlClickEvents – time-of-click outcomes for links, including those clicked in Teams. What you’ll learn in the video Surface active external domains in your tenant’s Teams chats. Identify who clicked risky links and the click outcomes (via Safe Links telemetry). See where message warnings appear in the chat UI. Pivot to an incident and block indicators fast via the Tenant Allow/Block List (TABL). A couple hunts to try right now 1) Malicious verdicts in Teams (last 24 hours) Find messages that already carry a Spam/Phish/Malware verdict – your fastest triage queue. MessageEvents | where Timestamp > ago(1d) | where ThreatTypes has "Phish" or ThreatTypes has "Malware" or ThreatTypes has "Spam" | project Timestamp, SenderDisplayName, SenderEmailAddress, RecipientDetails, IsOwnedThread, ThreadType, IsExternalThread, ReportId Use it for: a quick sweep + pivot to incident/entities, then TABL block if needed. 2) “IT helpdesk” imposters in external DMs (last 5 days) Surface social-engineering lures that impersonate support. MessageEvents | where Timestamp > ago(5d) | where IsExternalThread == true | where (RecipientDetails has "help" and RecipientDetails has "desk") or (RecipientDetails has "it" and RecipientDetails has "support") or (RecipientDetails has "working" and RecipientDetails has "home") or (SenderDisplayName has "help" and SenderDisplayName has "desk") or (SenderDisplayName has "it" and SenderDisplayName has "support") or (SenderDisplayName has "working" and SenderDisplayName has "home") | project Timestamp, SenderDisplayName, SenderEmailAddress, RecipientDetails, IsOwnedThread, ThreadType, ReportId Use it for: first-contact scams (external tenant posing as IT). Pair with Safe Links telemetry to see who clicked. Tip: has is token-aware and generally faster/cleaner than contains for word matches. Keep both hunts detection-ready by ensuring the final projection includes Timestamp and ReportId. 3) BONUS! External DMs with links (last 7 days) MessageEvents | where Timestamp > ago(7d) and IsExternalThread == true | join kind=inner (MessageUrlInfo) on TeamsMessageId | summarize Links=dcount(Url), Senders=dcount(SenderEmailAddress) by UrlDomain | top 10 by Links desc 4) Who clicked (Teams workload) – exposure view: UrlClickEvents | where Timestamp > ago(7d) and Workload == "Teams" | project Timestamp, AccountUpn, Url, ActionType | order by Timestamp desc “From Hunt to Action”: Respond & contain Finding a risky link in Teams is only half the job. This walkthrough shows how to go from detection to containment – block the domain, clean up delivered messages, and cut attacker access. Why this matters Speed: Shrink time from “we saw it” to “it’s blocked”. Consistency: Turns ad-hoc hunting into a repeatable response flow. Coverage: Pair URL blocking with identity and device containment. What you’ll see in the video Turn a hunt into an alert In Advanced Hunting, run a short query (below) and choose Create detection rule to schedule it. Alerts auto-create incidents you can triage. Block at click-time (Safe Links + TABL) In the incident, open the URL entity and add the URL/domain to the Tenant Allow/Block List (TABL) so future Teams clicks are blocked by Safe Links. Post-delivery cleanup (ZAP) If a malicious message slipped through, ZAP can remove or mark it after delivery. You’ll see evidence on the incident timeline. Contain accounts and devices Revoke user sessions in Entra ID to invalidate active tokens. Reset the password (and require strong, unique credentials), then enforce MFA for the account. Review MFA methods and remove anything suspicious; review app consents and revoke illicit grants. If endpoints are onboarded, isolate the device in Microsoft Defender for Endpoint to stop outbound connections while you investigate. The Microsoft Learn guide, https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account, for compromised accounts recommends session revocation, password reset, MFA enforcement, reviewing OAuth app consents and admin roles, and checking mail forwarding/rules – steps that complement the Teams response you see here. The hunt This KQL surfaces rare external domains in Teams and any user clicks. let lookback = 1d; // External Teams messages let externalMsgs = MessageEvents | where Timestamp > ago(lookback) and IsExternalThread == true | project MsgTime = Timestamp, TeamsMessageId, SenderEmailAddress, ME_ReportId = ReportId; // URLs found in Teams messages let urlsInMsgs = MessageUrlInfo | where Timestamp > ago(lookback) | project MUI_Time = Timestamp, TeamsMessageId, Url, UrlDomain, MUI_ReportId = ReportId; // Clicks coming from Teams let clicks = UrlClickEvents | where Timestamp > ago(lookback) and Workload == "Teams" | project ClickTime = Timestamp, Url, Clicker = AccountUpn, ClickAction = ActionType, UCE_ReportId = ReportId; // Define “rare” domains in the period let rareDomains = urlsInMsgs | summarize msgCount = dcount(TeamsMessageId) by UrlDomain | where msgCount < 3; rareDomains | join kind=inner (urlsInMsgs) on UrlDomain | join kind=leftouter (externalMsgs) on TeamsMessageId | join kind=leftouter (clicks) on Url | project Timestamp = coalesce(ClickTime, MUI_Time, MsgTime), UrlDomain, Url, SenderEmailAddress, Clicker, ClickTime, ClickAction, TeamsMessageId, ReportId = coalesce(UCE_ReportId, MUI_ReportId, ME_ReportId) After verifying results, select Create detection rule, set a schedule (e.g., hourly), and map entities so incidents include the right artifacts. What good looks like (response playbook) Alert fires → open incident; confirm scope and entities. Block URL/domain via TABL to stop future clicks. Confirm ZAP removed or marked delivered messages. Revoke sessions and reset password; enforce MFA. Review MFA methods and remove unknown devices/methods. Audit app consents (revoke illicit grants) and verify the user holds no unexpected admin roles. If email abuse is suspected, check for forwarding or malicious Inbox rules. Isolate device if execution is suspected; collect artifacts and un-isolate after remediation. FAQs Does the block remove the message? No – TABL blocks at click-time. Post-delivery removal is handled by ZAP when detections apply. Will revoking sessions disrupt users? It forces sign-in again (expected). Communicate this in your response template. What if the attacker used consent phishing? Revoke the offending enterprise app consent and review publisher verification status. Call to action: Save the query, create the detection, and attach this playbook to your incident template. The goal every time: find → block → clean up → contain Securing Microsoft Teams is most effective when technology and people work together. By enabling user reporting, leveraging real-time protections, and empowering security teams to act quickly, organizations can turn everyday collaboration into a strong defense against threats. ## Please take two minutes to take this survey to let us know what you think of this blog (series), video, and community content. Questions or comments on this blog "Microsoft Defender for Office 365 – A Four-Part Guide to Secure Collaboration" for the author or other readers? Please log in and post your response below! _____________ This blog has been generously and expertly authored by Microsoft Security MVP, Pierre Thoor with support of the Microsoft Defender for Office 365 product team. Pierre Thoor Microsoft Security MVP | Microsoft Defender for Office 365 Champ Learn More and Meet the Author 1) December 16th Ask the Experts Webinar: Microsoft Defender for Office 365 | Ask the Experts: Tips and Tricks (REGISTER HERE) DECEMBER 16, 8 AM US Pacific You’ve watched the latest Microsoft Defender for Office 365 best practices videos and read the blog posts by the esteemed Microsoft Most Valuable Professionals (MVPs), now bring your toughest questions or unique situations straight to the experts. In this interactive panel discussion, Microsoft MVPs will answer your real world scenarios, clarify best practices, and highlight practical tips surfaced in the recent series. We’ll kick off with a who’s who and recent blog/video series recap, then dedicate most of the time to your questions across migration, SOC optimization, fine-tuning configuration, Teams protection, and even Microsoft community engagement. Come ready with your questions (or pre-submit here) for the expert Security MVPs on camera, or the Microsoft Defender for Office 365 product team in the chat! REGISTER NOW for 12/16. 2) Additional MVP-Authored Blogs in this Four- Part Series: Microsoft Defender for Office 365: Migration & Onboarding by Purav Desai (This post) Safeguarding Microsoft Teams with Microsoft Defender for Office 365 You may be right after all! Disputing Submission Responses in Microsoft Defender for Office 365 by Mona Ghadiri Microsoft Defender for Office 365: Fine-Tuning by Joe Stocker Learn and Engage with the Microsoft Security Community Log in and follow this Microsoft Defender for Office 365 blog and follow/post in the Microsoft Defender for Office discussion space. Follow = Click the heart in the upper right when you're logged in 🤍 Learn more about the Microsoft MVP Program. Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more. Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Customer Connection Community. Join the Microsoft Security Community LinkedIn
XDR advanced hunting region specific endpoints
Hi, I am exploring XDR advanced hunting API to fetch data specific to Microsoft Defender for Endpoint tenants. The official documentation (https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) mentions to switch to Microsoft Graph advanced hunting API. I had below questions related to it: 1. To fetch the region specific(US , China, Global) token and Microsoft Graph service root endpoints(https://learn.microsoft.com/en-us/graph/deployments#app-registration-and-token-service-root-endpoints ) , is the recommended way to fetch the OpenID configuration document (https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc#fetch-the-openid-configuration-document) for a tenant ID and based on the response, the region specific SERVICE/TOKEN endpoints could be fetched? Since using it, there is no need to maintain different end points for tenants in different regions. And do we use the global service URL https://login.microsoftonline.com to fetch OpenID config document for a tenantID in any region? 2. As per the documentation, Microsoft Graph Advanced hunting API is not supported in China region (https://learn.microsoft.com/en-us/graph/api/security-security-runhuntingquery?view=graph-rest-1.0&tabs=http). In this case, is it recommended to use Microsoft XDR Advanced hunting APIs(https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) to support all region tenants(China, US, Global)?
