detection
198 TopicsMicrosoft Defender for Office 365: Fine-Tuning
In incident response, most business email compromise doesn’t start with “sophisticated zero-day malware.” It starts with configuration gaps: forwarding mail outside the tenant, users clicking through Safe Links warnings, impersonation policies left at day-one defaults, or post-delivery cleanup still relying on a human analyst at 2:00 AM. Those gaps are what attackers actually exploit. This blog covers our top recommendations for fine-tuning Microsoft Defender for Office 365 configuration from hundreds of deployments and recovery engagements: Core fine-tuning actions every email or security admin should land right now Data-driven bulk mail tuning (BCL and Bulk Mail Insights) Impersonation and anti-phishing policy hygiene for executive protection Automate post-delivery cleanup by enabling Automated Remediation Each section includes a short video and practical guidance you can apply immediately in Microsoft Defender for Office 365. These recommendations align with Microsoft’s “secure by default” direction: applying the Standard and Strict preset security policies to users, using Configuration analyzer to catch configuration drift, and enforcing least-privilege release of high-risk mail. When possible, enable the Preset security policies to give you Microsoft’s recommended settings for Safe Links, Safe Attachments, Anti-Phishing, and Anti-Spam. If you use custom policies (or if you exclude users from the Presets) then use Configuration analyzer regularly to compare custom policies to the Standard/Strict baselines, since those get updated as Microsoft updates the Preset policies. Core Fine-Tuning Checklist for Defender for Office 365 This section highlights six controls we recommend implementing broadly. These are “day one hardening” items we repeatedly validate with customers. Block automatic external forwarding by default Attackers often create hidden inbox rules that quietly forward mail (invoices, purchase orders, wire info) to an external account they control. Use outbound spam policies to block automatic external forwarding for the entire org and then create tightly scoped exceptions only for the handful of mailboxes that legitimately need it. This prevents data leakage and payment fraud scenarios where mail auto-forwards out of your tenant without anyone noticing. Although this setting is on by default (“System Controlled” means that external forwarding is disabled), we’ve found many tenants where this was disabled because the admin didn’t know how to create a custom policy for authorized forwarders. The trick is to order custom outbound policies to run as a higher priority than the default outbound policy which should be set to block auto-forwarded emails. It is a good idea to regularly review the auto forwarded message report (located in the Exchange Admin Center). Use Enhanced Filtering for Connectors (“skip listing”) when necessary If you’re routing inbound mail through a third-party Secure Email Gateway or an on-prem hop before Microsoft 365, Defender will see that intermediary as the source IP instead of the original sending IP, which degrades anti-spoofing effectiveness.Enhanced Filtering for Connectors — also called skip listing — lets Microsoft 365 look past that last hop and evaluate the real sending IP and headers, so SPF / DKIM / DMARC and anti-spam logic work correctly. This setting does not support centralized mail routing (unless the routing is linear; see the Enhanced Filtering for Connectors learn article), so make sure you are not using that before enabling Enhanced Filtering. Centralized routing is sometimes used by organizations running a hybrid Exchange deployment, connecting Exchange Online with an on-premises Exchange Server organization. Important: Do this instead of blanket SCL -1 transport rules that “bypass spam filtering for anything coming from our gateway.” Over-bypassing means phishing that slipped through the third-party filter can sail straight to user inboxes, which Microsoft specifically warns against. Turn on Safe Attachments protection beyond email (SharePoint, OneDrive, Teams) In the Safe Attachments “Global settings,” make sure Defender for Office 365 is set to protect files in SharePoint, OneDrive, and Microsoft Teams. When enabled, if a file is identified as malicious, Defender automatically locks the file in-place so users can’t open it in Teams or OneDrive. This gives you malware detonation and containment in collaboration channels, not just email. This step closes a gap we still see a lot: customers protect mail attachments well, but shared files and Teams chats are wide open. In the 1st part of this blog series, Microsoft MVP Purav Desai describes (here) how to prevent users from downloading malicious files by running a SharePoint PowerShell cmdlet: Set-SPOTenant -DisallowInfectedFileDownload $true Don’t let users click through Safe Links warnings Safe Links rewrites and time-of-click scans URLs in mail, Office apps, and Teams. In the Safe Links policy, clear “Let users click through to the original URL.” That prevents the classic “I know it says it’s malicious, but I really need to see it…” moment. Users get blocked instead of “warned but allowed.” This setting is also enforced in Microsoft’s Standard AND Strict preset security policies where click-through is explicitly disabled. Go beyond the default Common Attachment filter The anti-malware policy’s Common Attachment filter blocks known dangerous file extensions (executable content, scriptable content, etc.). Microsoft ships a default list (historically 50+ high-risk extensions), and you can customize it to block additional file types common in malware delivery, like HTML droppers or password-protected archives. Messages with those file types are treated as malware and quarantined. Do this centrally rather than relying on users to “spot a suspicious attachment.” Automation beats user judgment here. Use custom quarantine policies that require admin approval (instead of self-release) If you are not using the Preset Policies, you can create a quarantine policy to customize the user experience with quarantined messages. For anything phishing-related, I recommend creating a custom policy that allows the user to “request release from admin.” That means users can raise a hand if they think something should not have been quarantined, and an Incident is created for administrators to review before it is released. To me, this strikes the best balance between security and productivity. This keeps containment intact and gives the SOC final say. It also creates an auditable workflow: who asked for release, who approved it, and why. Bulk Mail Insights: Tune BCL using your tenant’s mail Bulk email (“graymail”) is noisy. Payroll alerts and benefits notifications are legitimate, but they look exactly like phishing. At the same time, true marketing email (graymail) are also bulk. The traditional response (“just whitelist the sender so users stop complaining”) often opens the door for attacker-looking mail to get delivered straight to executives. Defender for Office 365 gives you something better: Bulk Mail Insights (a.k.a. Bulk senders insight). This report shows, over the last 60 days, how much mail at each Bulk Complaint Level (BCL 1–9) was delivered vs. blocked, which senders are generating volume, and where users are likely to experience false positives or false negatives. You can interactively simulate raising or lowering the bulk threshold and immediately see, “If we tighten BCL, how many more messages get quarantined? How many of those were probably junk? How many were probably wanted?” Why this matters: You stop tuning bulk mail based on anecdotes and start tuning based on real telemetry from your own tenant. You can justify decisions to leadership and audit (“We set BCL at X because here is the simulation showing false positive/false negative impact”). You avoid blanket allow rules. Instead, you adjust bulk thresholds for legitimate high-volume senders while keeping stricter actions for everyone else. Note: You can modify the BCL threshold in your default or custom anti-spam policy, but you can’t change it inside the Standard (BCL:6) or Strict (BCL:5) preset security policies themselves. Standard and Strict are already aligned to Microsoft’s recommended baselines. Additional Links: https://security.microsoft.com/senderinsights https://learn.microsoft.com/en-us/defender-office-365/anti-spam-bulk-senders-insight https://learn.microsoft.com/en-us/defender-office-365/mdo-deployment-guide#step-2-configure-threat-policies https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies#policy-settings-in-preset-security-policies https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365 https://www.microsoft.com/en-us/security/blog/2025/07/17/transparency-on-microsoft-defender-for-office-365-email-security-effectiveness/ Anti-Phishing / Impersonation Tuning: Protect the people attackers actually spoof Business email compromise very often looks like this: “Hi, can you handle this payment today?” sent from an address that looks like your CFO or CEO. Microsoft Defender for Office 365 includes targeted impersonation protection, but it only really works if you target your most targeted executives. Here are five pitfalls we see over and over: Empty or stale VIP list Populate “users to protect / high value targets” with executives, finance approvers, legal, anyone authorized to move money or data. Review it monthly. Roles change, and you only get a finite number of protected users (for example, ~350 entries). An out-of-date list silently weakens protection for the people attackers actually impersonate. Phishing email threshold stuck at 1 forever We find organizations that are not using the preset policies have left their phishing threshold values at the default “1” because of initial false positives. We recommend raising it to match the Standard Preset (“3”) or Strict (“4”). Weak action If suspicious “CFO” mail just goes to Junk, users can still act on it. High-confidence impersonation of executives should be quarantined with AdminOnly or request-release workflows, not left in end-user control. Tie this back to the custom quarantine policies (discussed later in this article). Common-name overload If your CEO’s name is something extremely common, you’ll get noise. Expect it. Don’t “turn off” protection for that name — add that address to the Trusted Senders otherwise it will be blocked as an impersonation attempt. Use Trusted Senders / Trusted Domains for known-good partners and vendors so you keep protection high without drowning in alerts. Add only legitimate senders/domains to the Trusted Senders or Trusted Domains instead of lowering enforcement. No scheduled review This control can’t be “set and forget.” Put impersonation tuning and spoof intelligence review on a monthly checklist. That lets you catch new vendors pretending to be finance, new “urgent wire” lure patterns, and any drift from Standard / Strict baseline that Configuration analyzer will also call out. When done right, impersonation protection is not just “spam reduction.” It’s payment fraud prevention. Automated Investigation & Response (AIR): Let Defender remove malicious email before your SOC has to! One of the biggest wins you can land quickly is letting Microsoft Defender for Office 365 automatically remove clusters of malicious messages — without waiting for analyst approval on every single item. Here’s how it works. Defender’s Automated Investigation and Response (AIR) groups messages into “clusters” based on shared indicators like the same malicious URL or malicious file hash. If you opt in to automatic remediation for those cluster types, AIR will go find every matching copy of that threat across the tenant and soft-delete those messages, not just the one that triggered the alert. Why this matters: It turns post-delivery cleanup into something that happens immediately instead of “after Tier 1 has time to review.” It removes known-bad messages from user mailboxes (and related collaboration surfaces like Teams) before a target can click. It dramatically cuts the classic “Did anyone else get this?” manual hunt-and-purge work that burns out SOC analysts. When you configure AIR automation settings in the Microsoft Defender portal (Settings > Email & collaboration > MDO automation settings), you’ll see checkboxes for “Similar files” and “Similar URLs.” Selecting those opts you into automatic soft delete for those clusters. Today, soft delete is the default supported action for these automatic remediations, enabling administrators to undo a deletion, if necessary. This is Defender for Office 365 Plan 2 / Microsoft 365 E5 functionality, and it’s exactly the kind of “secure operations by default” Microsoft has been pushing: detect, contain, and clean up automatically, then let humans investigate with context instead of manually chasing every copy of a phish. This automation triggers when malicious clusters are detected. For automating the classification and triage of user-submitted phishing incidents, check out the Security Copilot Phishing Triage Agent (Preview). Additional Links: GA Announcement: https://techcommunity.microsoft.com/blog/-/auto-remediation-of-malicious-messages-in-automated/4418047 Docs: https://learn.microsoft.com/en-us/defender-office-365/air-auto-remediation Final Thoughts Defender for Office 365 is more than “email filtering.” It’s part of your security operations surface. The decisions you make about automated remediation (AIR), bulk mail thresholds, Safe Links/Attachment behavior, outbound forwarding, connector hygiene, quarantine policy, and impersonation tuning directly determine how easy — or how hard — it is for an attacker to penetrate your organization. Microsoft’s current guidance is clear: Apply Standard or Strict preset security policies so users get the recommended protections by default (for example, Safe Links with no click-through). If you must use a custom policy, review the recommendations from the Configuration analyzer monthly for new recommendations, or to catch and correct drift whenever someone weakens a control. Align internal procedures with the excellent Security Operations Guide for Defender for Office 365. Lock down quarantine so only admins can release high-risk messages, with an auditable “request release” path for users. Turn on automated remediation so Defender can remove malicious clusters of messages before anyone clicks. Organizations that land these basics are in a dramatically better position during an incident. Instead of “Who clicked the link?” you can say, “AIR already pulled it, users were blocked from clicking through, outbound forwarding is disabled, and impersonation of the CFO is quarantined for admin review.” That’s what “secure by default” actually looks like in production. ________ This blog was authored by Joe Stocker, Microsoft Security MVP and Founder of Patriot Consulting Technology Group, in partnership with the Microsoft Defender for Office 365 product team, including Paul Newell, Senior Product Manager, Microsoft Defender for Office 365. Joe Stocker 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: Microsoft Defender for Office 365: Migration & Onboarding by Purav Desai Safeguarding Microsoft Teams with Microsoft Defender for Office 365 by Pierre Thoor You may be right after all! Disputing Submission Responses in Microsoft Defender for Office 365 by Mona Ghadiri (This post) "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 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 LinkedIn
Declutter and Defend: Reducing promotional mail noise with Microsoft Defender
Enterprise inboxes are overwhelmed with graymail — legitimate, bulk email like newsletters, vendor promotions, and product updates that isn't malicious but buries the messages that matter. When high volumes of these mails land in the inbox, it crowds out priority communications and can dull security vigilance. Employees conditioned to ignore repetitive emails may miss signs of a real threat. It also creates recurring work for admins and security teams who must continuously tune filters, manage exception requests, and chase noise from user reports for email that isn’t malicious. Because graymail passes every spam filter check, traditional defenses don't separate it — leaving this signal-to-noise gap unaddressed. Today we’re excited to announce that Microsoft Defender now includes built-in graymail filtering. It is delivered natively through a new Promotions experience in Outlook that automatically classifies and separates bulk email, so it no longer competes with business-critical communication in the inbox. Now in Public Preview, this capability learns from how users interact with graymail to become more accurate over time. Coupled with the existing Bulk Senders Insight report, Defender brings data-driven bulk classification and control into the security workflows you already use. What Is Graymail? Graymail is legitimate bulk email that isn't malicious—product newsletters, event announcements, marketing promotions, and software update notifications from reputable, authenticated senders. It is distinct from spam and from phishing - graymail comes from real organizations with proper authentication and traditional spam filters aren't designed to handle it. Graymail handling in Microsoft Defender Microsoft Defender's approach is built on three principles: classify intelligently, deliver natively, and learn continuously. Promotions Folder — Intelligent Inbox Organization A dedicated Promotions folder, natively provisioned in Outlook, now keeps legitimate bulk mail out of the primary inbox. Promotional content is separated from priority emails without being sent to Junk, which means users can still access and browse newsletters and updates at their own pace. The folder appears at the top level of the mailbox for easy discovery and is visible across all Outlook experiences. Non-spam bulk mail below the organization's configured Bulk Complaint Level threshold is automatically routed to the Promotions folder. Messages from senders the user has explicitly allowed continue to land in the Inbox. Messages identified as spam continue to go to Junk. To enable the Promotions folder administrators need to enable the "Bulk Moves Enabled" setting in their anti-spam policy. The Promotions folder is then created for all users and used for routing only when this setting is ON. Existing mail flow is unaffected. Promotional mail tagging and Mailbox Rule Support Messages classified as graymail will automatically be labeled with a "Promotions" system tag in Outlook. The tag provides instant visual context without requiring users to open each message and is visible in Outlook on the Web and the native Outlook desktop apps for Windows and Mac. During Public Preview, the tagging component is opt-in, requiring administrators to enable it by configuring an Exchange Transport Rule. Once generally available, it will be enabled by default. Because this classification is integrated at the client level, the Promotions tag can also be used as a condition in Outlook mailbox rules. This enables custom routing logic for advanced scenarios like moving all promotions-tagged messages from a specific sender to a custom folder, flagging certain promotional emails for follow-up, or auto-forwarding or deleting promotions that meet specific criteria. This transforms the Promotions classification from a one-way filter into a flexible building block for personal and organizational workflows—particularly valuable for power users and teams with compliance or archival requirements. Adaptive Learning Microsoft Defender's graymail filtering gets smarter with every interaction. The system learns directly from how users handle their mail. When a user moves a message out of the Promotions folder and back to the Inbox, future emails from that sender will no longer be placed in the Promotions folder. When a user moves a message from the Inbox into the Promotions folder, future emails from that sender will be routed to the Promotions folder automatically. This creates a personalized, self-improving experience that becomes more accurate over time - no manual rule configuration required, no safe-sender lists to maintain, and no filtering rules for IT teams to manage on behalf of individual employees. Built into existing Security Workflows Administrators also gain visibility through the Bulk Senders Insight report, which provides data-driven guidance on what your organization actually receives and can help tune your bulk mail filtering. Graymail has long been the unsolved middle ground of email security—too legitimate to block, too noisy to ignore. Microsoft Defender now handles it where it should be handled: inside the platform, inside the mailbox, and inside the security workflows your organization already relies on. No new portals, no new vendors, no compromise between security and user experience. Get Started Configure promotions tagging and the promotions folder today - Bulk email detection documentation on Microsoft Learn. Monitor the experience using the Bulk Senders Insight report.Protect your organizations against QR code phishing with Defender for Office 365
QR code phishing campaigns have most recently become the fastest growing type of email-based attack. These types of attacks are growing and embed QR code images linked to malicious content directly into the email body, to evade detection. They often entice unwitting users with seemingly genuine prompts, like a password reset or a two-factor authentication request. Microsoft Defender for Office 365 is continuously adapting as threat actors evolve their methodologies. In this blog post we’ll share more details on how we’re helping defenders address this threat and keeping end-users safe.RSAC 2026: New Microsoft Sentinel Connectors Announcement
Microsoft Sentinel helps organizations detect, investigate, and respond to security threats across increasingly complex environments. With the rollout of the Microsoft Sentinel data lake in the fall, and the App Assure-backed Sentinel promise that supports it, customers now have access to long-term, cost-effective storage for security telemetry, creating a solid foundation for emerging Agentic AI experiences. Since our last announcement at Ignite 2025, the Microsoft Sentinel connector ecosystem has expanded rapidly, reflecting continued investment from software development partners building for our shared customers. These connectors bring diverse security signals together, enabling correlation at scale and delivering richer investigation context across the Sentinel platform. Below is a snapshot of Microsoft Sentinel connectors newly available or recently enhanced since our last announcement, highlighting the breadth of partner solutions contributing data into, and extending the value of, the Microsoft Sentinel ecosystem. New and notable integrations Acronis Cyber Protect Cloud Acronis Cyber Protect Cloud integrates with Microsoft Sentinel to bring data protection and security telemetry into a centralized SOC view. The connector streams alerts, events, and activity data - spanning backup, endpoint protection, and workload security - into Microsoft Sentinel for correlation with other signals. This integration helps security teams investigate ransomware and data-centric threats more effectively, leverage built-in hunting queries and detection rules, and improve visibility across managed environments without adding operational complexity. Anvilogic Anvilogic integrates with Microsoft Sentinel to help security teams operationalize detection engineering at scale. The connector streams Anvilogic alerts into Microsoft Sentinel, giving SOC analysts centralized visibility into high-fidelity detections and faster context for investigation and triage. By unifying detection workflows, reducing alert noise, and improving prioritization, this integration supports more efficient threat detection and response while helping teams extend coverage across evolving attack techniques. BigID BigID integrates with Microsoft Sentinel to extend data security posture management (DSPM) insights into security operations workflows. The solution brings visibility into sensitive, regulated, and critical data across cloud, SaaS, and on‑premises environments, helping security teams understand where high‑risk data resides and how it may be exposed. By incorporating data‑centric risk context into Sentinel, this integration supports more informed investigation and prioritization, enabling organizations to reduce data‑related risk and align security operations with data protection and compliance objectives. Commvault Cloud Commvault Cloud integrates with Microsoft Sentinel to bring data protection and cyber‑resilience telemetry into security operations workflows. The connector ingests security‑relevant signals from Commvault Cloud—such as backup anomalies, malware and ransomware indicators, and other threat‑related events—into Sentinel, enabling centralized detection, investigation, and automated response. By correlating backup intelligence with broader Sentinel telemetry, this integration helps security teams reduce blind spots, validate the scope of incidents, and improve coordination between security and recovery operations. CyberArk Audit CyberArk Audit integrates with Microsoft Sentinel to centralize visibility into privileged identity and access activity. By streaming detailed audit logs - covering system events, user actions, and administrative activity - into Microsoft Sentinel, security teams can correlate identity-driven risks with broader security telemetry. This integration supports faster investigations, improved monitoring of privileged access, and more effective incident response through automated workflows and enriched context for SOC analysts. Cyera Cyera integrates with Microsoft Sentinel to extend AI-native data security posture management into security operations. The connector brings Cyera’s data context and actionable intelligence across multi-cloud, on-premises, and SaaS environments into Microsoft Sentinel, helping teams understand where sensitive data resides and how it is accessed, exposed, and used. Built on Sentinel’s modern framework, the integration feeds context-rich data risk signals into the Sentinel data lake, enabling more informed threat hunting, automation, and decision-making around data, user, and AI-related risk. TacitRed CrowdStrike IOC Automation Data443 TacitRed CS IOC Automation integrates with Microsoft Sentinel to streamline the operationalization of compromised credential intelligence. The solution uses Sentinel playbooks to automatically push TacitRed indicators of compromise into CrowdStrike via Sentinel playbooks, helping security teams turn identity-based threat intelligence into action. By automating IOC handling and reducing manual effort, this integration supports faster response to credential exposure and strengthens protection against account-driven attacks across the environment. TacitRed SentinelOne IOC Automation Data443 TacitRed SentinelOne IOC Automation integrates with Microsoft Sentinel to help operationalize identity-focused threat intelligence at the endpoint layer. The solution uses Sentinel playbooks to automatically consume TacitRed indicators and push curated indicators into SentinelOne via Sentinel playbooks and API-based enforcement, enabling faster enforcement of high-risk IOCs without manual handling. By automating the flow of compromised credential intelligence from Sentinel into EDR, this integration supports quicker response to identity-driven attacks and improves coordination between threat intelligence and endpoint protection workflows. TacitRed Threat Intelligence Data443 TacitRed Threat Intelligence integrates with Microsoft Sentinel to provide enhanced visibility into identity-based risks, including compromised credentials and high-risk user exposure. The solution ingests curated TacitRed intelligence directly into Sentinel, enriching incidents with context that helps SOC teams identify credential-driven threats earlier in the attack lifecycle. With built-in analytics, workbooks, and hunting queries, this integration supports proactive identity threat detection, faster triage, and more informed response across the SOC. Cyren Threat Intelligence Cyren Threat Intelligence integrates with Microsoft Sentinel to enhance detection of network-based threats using curated IP reputation and malware URL intelligence. The connector ingests Cyren threat feeds into Sentinel using the Codeless Connector Framework (CCF), transforming raw indicators into actionable insights, dashboards, and enriched investigations. By adding context to suspicious traffic and phishing infrastructure, this integration helps SOC teams improve alert accuracy, accelerate triage, and make more confident response decisions across their environments. TacitRed Defender Threat Intelligence Data443 TacitRed Defender Threat Intelligence integrates with Microsoft Sentinel to surface early indicators of credential exposure and identity-driven risk. The solution automatically ingests compromised credential intelligence from TacitRed into Sentinel and can support synchronization of validated indicators with Microsoft Defender Threat Intelligence through Sentinel workflows, helping SOC teams detect account compromise before abuse occurs. By enriching Sentinel incidents with actionable identity context, this integration supports faster triage, proactive remediation, and stronger protection against credential-based attacks. Datawiza Access Proxy (DAP) Datawiza Access Proxy integrates with Microsoft Sentinel to provide centralized visibility into application access and authentication activity. By streaming access and MFA logs from Datawiza into Sentinel, security teams can correlate identity and session-level events with broader security telemetry. This integration supports detection of anomalous access patterns, faster investigation through session traceability, and more effective response using Sentinel automation, helping organizations strengthen Zero Trust controls and meet auditing and compliance requirements. Endace Endace integrates with Microsoft Sentinel to provide deep network visibility by providing always-on, packet-level evidence. The connector enables one-click pivoting from Sentinel alerts directly to recorded packet data captured by EndaceProbes. This helps SOC and NetOps teams reconstruct events and validate threats with confidence. By combining Sentinel’s AI-driven analytics with Endace’s always-on, full-packet capture across on-premises, hybrid, and cloud environments, this integration supports faster investigations, improved forensic accuracy, and more decisive incident response. Feedly Feedly integrates with Microsoft Sentinel to ingest curated threat intelligence directly into security operations workflows. The connector automatically imports Indicators of Compromise (IoCs) from Feedly Team Boards and folders into Sentinel, enriching detections and investigations with context from the original intelligence articles. By bringing analyst‑curated threat intelligence into Sentinel in a structured, automated way, this integration helps security teams stay current on emerging threats and reduce the manual effort required to operationalize external intelligence. Gigamon Gigamon integrates with Microsoft Sentinel through a new connector that provides access to Gigamon Application Metadata Intelligence (AMI), delivering high-fidelity network-derived telemetry with rich application metadata from inspected traffic directly into Sentinel. This added context helps security teams detect suspicious activity, encrypted threats, and lateral movement faster and with greater precision. By enriching analytics without requiring full packet ingestion, organizations can reduce noise, manage SIEM costs, and extend visibility across hybrid cloud infrastructure. Halcyon Halcyon integrates with Microsoft Sentinel to provide purpose-built ransomware detection and automated containment across the Microsoft security ecosystem. The connector surfaces Halcyon ransomware alerts directly within Sentinel, enabling SOC teams to correlate ransomware behavior with Microsoft Defender and broader Microsoft telemetry. By supporting Sentinel analytics and automation workflows, this integration helps organizations detect ransomware earlier, investigate faster using native Sentinel tools, and isolate affected endpoints to prevent lateral spread and reinfection. Illumio The Illumio platform identifies and contains threats across hybrid multi-cloud environments. By integrating AI-driven insights with Microsoft Sentinel and Microsoft Graph, Illumio Insights enables SOC analysts to visualize attack paths, prioritize high-risk activity, and investigate threats with greater precision. Illumio Segmentation secures critical assets, workloads, and devices and then publishes segmentation policy back into Microsoft Sentinel to ensure compliance monitoring. Joe Sandbox Joe Sandbox integrates with Microsoft Sentinel to enrich incidents with dynamic malware and URL analysis. The connector ingests Joe Sandbox threat intelligence and automatically detonates suspicious files and URLs associated with Sentinel incidents, returning behavioral and contextual analysis results directly into investigation workflows. By adding sandbox-driven insights to indicators, alerts, and incident comments, this integration helps SOC teams validate threats faster, reduce false positives, and improve response decisions using deeper visibility into malicious behavior. Keeper Security The Keeper Security integration with Microsoft Sentinel brings advanced password and secrets management telemetry into your SIEM environment. By streaming audit logs and privileged access events from Keeper into Sentinel, security teams gain centralized visibility into credential usage and potential misuse. The connector supports custom queries and automated playbooks, helping organizations accelerate investigations, enforce Zero Trust principles, and strengthen identity security across hybrid environments. Lookout Mobile Threat Defense (MTD) Lookout Mobile Threat Defense integrates with Microsoft Sentinel to extend SOC visibility to mobile endpoints across Android, iOS, and Chrome OS. The connector streams device, threat, and audit telemetry from Lookout into Sentinel, enabling security teams to correlate mobile risk signals such as phishing, malicious apps, and device compromise, with broader enterprise security data. By incorporating mobile threat intelligence into Sentinel analytics, dashboards, and alerts, this integration helps organizations detect mobile driven attacks earlier and strengthen protection for an increasingly mobile workforce. Miro Miro integrates with Microsoft Sentinel to provide centralized visibility into collaboration activity across Miro workspaces. The connector ingests organization-wide audit logs and content activity logs into Sentinel, enabling security teams to monitor authentication events, administrative actions, and content changes alongside other enterprise signals. By bringing Miro collaboration telemetry into Sentinel analytics and dashboards, this integration helps organizations detect suspicious access patterns, support compliance and eDiscovery needs, and maintain stronger oversight of collaborative environments without disrupting productivity. Obsidian Activity Threat The Obsidian Threat and Activity Feed for Microsoft Sentinel delivers deep visibility into SaaS and AI applications, helping security teams detect account compromise and insider threats. By streaming user behavior and configuration data into Sentinel, organizations can correlate application risks with enterprise telemetry for faster investigations. Prebuilt analytics and dashboards enable proactive monitoring, while automated playbooks simplify response workflows, strengthening security posture across critical cloud apps. OneTrust for Purview DSPM OneTrust integrates with Microsoft Sentinel to bring privacy, compliance, and data governance signals into security operations workflows. The connector enriches Sentinel with privacy relevant events and risk indicators from OneTrust, helping organizations detect sensitive data exposure, oversharing, and compliance risks across cloud and non-Microsoft data sources. By unifying privacy intelligence with Sentinel analytics and automation, this integration enables security and privacy teams to respond more quickly to data risk events and support responsible data use and AI-ready governance. Pathlock Pathlock integrates with Microsoft Sentinel to bring SAP-specific threat detection and response signals into centralized security operations. The connector forwards security-relevant SAP events into Sentinel, enabling SOC teams to correlate SAP activity with broader enterprise telemetry and investigate threats using familiar SIEM workflows. By enriching Sentinel with SAP security context and focused detection logic, this integration helps organizations improve visibility into SAP landscapes, reduce noise, and accelerate detection and response for risks affecting critical business systems. Quokka Q-scout Quokka Q-scout integrates with Microsoft Sentinel to centralize mobile application risk intelligence across Microsoft Intune-managed devices. The connector automatically ingests app inventories from Intune, analyzes them using Quokka’s mobile app vetting engines, and streams security, privacy, and compliance risk findings into Sentinel. By surfacing app-level risks through Sentinel analytics and alerts, this integration helps security teams identify malicious or high-risk mobile apps, prioritize remediation, and strengthen mobile security posture without deploying agents or disrupting users. Semperis Lightning Semperis Lightning integrates with Microsoft Sentinel to deliver deep visibility into identity‑centric risk across Active Directory and Microsoft Entra environments. The connector ingests identity security telemetry such as indicators of exposure, Tier 0 assets, and attack path insights into Sentinel, enabling security teams to correlate identity risks with broader security signals. By bringing rich identity context into Sentinel analytics, hunting, and investigations, this integration helps organizations detect, prioritize, and respond to identity‑driven attacks more effectively across hybrid identity infrastructures. Synqly Synqly integrates with Microsoft Sentinel to simplify and scale security integrations through a unified API approach. The connector enables organizations and security vendors to establish a bi‑directional connection with Sentinel without relying on brittle, point‑to‑point integrations. By abstracting common integration challenges such as authentication handling, retries, and schema changes, Synqly helps teams orchestrate security data flows into and out of Sentinel more reliably, supporting faster onboarding of new data sources and more maintainable integrations at scale. Versasec vSEC:CMS Versasec vSEC:CMS integrates with Microsoft Sentinel to provide centralized visibility into credential lifecycle and system health events. The connector securely streams vSEC:CMS and vSEC:CLOUD alerts and status data into Sentinel using the Codeless Connector Framework (CCF), transforming credential management activity into correlation-ready security signals. By bringing smart card, token, and passkey management telemetry into Sentinel, this integration helps security teams monitor authentication infrastructure health, investigate credential-related incidents, and unify identity security operations within their SIEM workflows. VirtualMetric DataStream VirtualMetric DataStream integrates with Microsoft Sentinel to optimize how security telemetry is collected, normalized, and routed across the Microsoft security ecosystem. Acting as a high-performance telemetry pipeline, DataStream intelligently filters and enriches logs, sending high-value security data to Sentinel while routing less-critical data to Sentinel data lake or Azure Blob Storage for cost-effective retention. By reducing noise upstream and standardizing logs to Sentinel ready schemas, this integration helps organizations control ingestion costs, improve detection quality, and streamline threat hunting and compliance workflows. VMRay VMRay integrates with Microsoft Sentinel to enrich SIEM and SOAR workflows with automated sandbox analysis and high-fidelity, behavior-based threat intelligence. The connector enables suspicious files and phishing URLs to be submitted directly from Sentinel to VMRay for dynamic analysis, while validated, high-confidence indicators of compromise (IOCs) are streamed back into Sentinel’s Threat Intelligence repository for correlation and detection. By adding detailed attack-chain visibility and enriched incident context, this integration helps SOC teams reduce investigation time, improve detection accuracy, and strengthen automated response workflows across Sentinel environments. XBOW XBOW integrates with Microsoft Sentinel to bring autonomous penetration testing insights directly into security operations workflows. The connector ingests automated penetration test findings from the XBOW platform into Sentinel, enabling security teams to analyze validated exploit activity alongside alerts, incidents, and other security telemetry. By correlating offensive testing results with Sentinel detections, this integration helps organizations identify monitoring gaps, validate detection coverage, and strengthen defensive controls using real‑world, continuously generated attack evidence. Zero Networks Segment Audit Zero Networks Segment integrates with Microsoft Sentinel to provide visibility into micro-segmentation and access-control activity across the network. The connector can collect audit logs or activities from Zero Networks Segment, enabling security teams to monitor policy changes, administrative actions, and access events related to MFA-based network segmentation. By bringing segmentation audit telemetry into Sentinel, this integration supports compliance monitoring, investigation of suspicious changes, and faster detection of attempts to bypass lateral-movement controls within enterprise environments. Zscaler Internet Access (ZIA) Zscaler Internet Access integrates with Microsoft Sentinel to centralize cloud security telemetry from web and firewall traffic. The connector enables ZIA logs to be ingested into Sentinel, allowing security teams to correlate Zscaler Internet Access signals with other enterprise data for improved threat detection, investigation, and response. By bringing ZIA web, firewall, and security events into Sentinel analytics and hunting workflows, this integration helps organizations gain broader visibility into internet-based threats and strengthen Zero Trust security operations. In addition to these solutions from our third-party partners, we are also excited to announce the following connector published by the Microsoft Sentinel team: GitHub Enterprise Audit Logs Microsoft’s Sentinel Promise For Customers Every connector in the Microsoft Sentinel ecosystem is built to work out of the box. In the unlikely event a customer encounters any issue with a connector, the App Assure team stands ready to assist. For Software Developers Software partners in need of assistance in creating or updating a Sentinel solution can also leverage Microsoft’s Sentinel Promise to support our shared customers. For developers seeking to build agentic experiences utilizing Sentinel data lake, we are excited to announce the launch of our Sentinel Advisory Service to guide developers across their Sentinel journey. Customers and developers alike can reach out to us via our intake form. Learn More Microsoft Sentinel data lake Microsoft Sentinel data lake: Unify signals, cut costs, and power agentic AI Introducing Microsoft Sentinel data lake What is Microsoft Sentinel data lake Unlocking Developer Innovation with Microsoft Sentinel data lake Microsoft Sentinel Codeless Connector Framework (CCF) Create a codeless connector for Microsoft Sentinel Public Preview Announcement: Microsoft Sentinel CCF Push What’s New in Microsoft Sentinel Monthly Blog Microsoft App Assure App Assure home page App Assure services App Assure blog App Assure Request Assistance Form App Assure Sentinel Advisory Services announcement App Assure’s promise: Migrate to Sentinel with confidence App Assure’s Sentinel promise now extends to Microsoft Sentinel data lake Ignite 2025 new Microsoft Sentinel connectors announcement Microsoft Security Microsoft’s Secure Future Initiative Microsoft Unified SecOps Editor's Note - April 7th, 2026: This blog was updated to include connector descriptions for BigID, Commvault, Semperis, and XBOW.1.8KViews0likes0CommentsRSAC 2026: What the Sentinel Playbook Generator actually means for SOC automation
RSAC 2026 brought a wave of Sentinel announcements, but the one I keep coming back to is the playbook generator. Not because it's the flashiest, but because it touches something that's been a real operational pain point for years: the gap between what SOC teams need to automate and what they can realistically build and maintain. I want to unpack what this actually changes from an operational perspective, because I think the implications go further than "you can now vibe-code a playbook." The problem it solves If you've built and maintained Logic Apps playbooks in Sentinel at any scale, you know the friction. You need a connector for every integration. If there isn't one, you're writing custom HTTP actions with authentication handling, pagination, error handling - all inside a visual designer that wasn't built for complex branching logic. Debugging is painful. Version control is an afterthought. And when something breaks at 2am, the person on call needs to understand both the Logic Apps runtime AND the security workflow to fix it. The result in most environments I've seen: teams build a handful of playbooks for the obvious use cases (isolate host, disable account, post to Teams) and then stop. The long tail of automation - the enrichment workflows, the cross-tool correlation, the conditional response chains - stays manual because building it is too expensive relative to the time saved. What's actually different now The playbook generator produces Python. Not Logic Apps JSON, not ARM templates - actual Python code with documentation and a visual flowchart. You describe the workflow in natural language, the system proposes a plan, asks clarifying questions, and then generates the code once you approve. The Integration Profile concept is where this gets interesting. Instead of relying on predefined connectors, you define a base URL, auth method, and credentials for any service - and the generator creates dynamic API calls against it. This means you can automate against ServiceNow, Jira, Slack, your internal CMDB, or any REST API without waiting for Microsoft or a partner to ship a connector. The embedded VS Code experience with plan mode and act mode is a deliberate design choice. Plan mode lets you iterate on the workflow before any code is generated. Act mode produces the implementation. You can then validate against real alerts and refine through conversation or direct code edits. This is a meaningful improvement over the "deploy and pray" cycle most of us have with Logic Apps. Where I see the real impact For environments running Sentinel at scale, the playbook generator could unlock the automation long tail I mentioned above. The workflows that were never worth the Logic Apps development effort might now be worth a 15-minute conversation with the generator. Think: enrichment chains that pull context from three different tools before deciding on a response path, or conditional escalation workflows that factor in asset criticality, time of day, and analyst availability. There's also an interesting angle for teams that operate across Microsoft and non-Microsoft tooling. If your SOC uses Sentinel for SIEM but has Palo Alto, CrowdStrike, or other vendors in the stack, the Integration Profile approach means you can build cross-vendor response playbooks without middleware. The questions I'd genuinely like to hear about A few things that aren't clear from the documentation and that I think matter for production use: Security Copilot dependency: The prerequisites require a Security Copilot workspace with EU or US capacity. Someone in the blog comments already flagged this as a potential blocker for organizations that have Sentinel but not Security Copilot. Is this a hard requirement going forward, or will there be a path for Sentinel-only customers? Code lifecycle management: The generated Python runs... where exactly? What's the execution runtime? How do you version control, test, and promote these playbooks across dev/staging/prod? Logic Apps had ARM templates and CI/CD patterns. What's the equivalent here? Integration Profile security: You're storing credentials for potentially every tool in your security stack inside these profiles. What's the credential storage model? Is this backed by Key Vault? How do you rotate credentials without breaking running playbooks? Debugging in production: When a generated playbook fails at 2am, what does the troubleshooting experience look like? Do you get structured logs, execution traces, retry telemetry? Or are you reading Python stack traces? Coexistence with Logic Apps: Most environments won't rip and replace overnight. What's the intended coexistence model between generated Python playbooks and existing Logic Apps automation rules? I'm genuinely optimistic about this direction. Moving from a low-code visual designer to an AI-assisted coding model with transparent, editable output feels like the right architectural bet for where SOC automation needs to go. But the operational details around lifecycle, security, and debugging will determine whether this becomes a production staple or stays a demo-only feature. Would be interested to hear from anyone who's been in the preview - what's the reality like compared to the pitch?Solved134Views0likes1CommentAccelerate Agent Development: Hacks for Building with Microsoft Sentinel data lake
As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Microsoft Sentinel data lake for the first time. I’ve written this article to walk you through one possible approach for agent development – the process I use when building sample agents internally at Microsoft. If you have questions about this, or other methods for building your agent, App Assure offers guidance through our Sentinel Advisory Service. Throughout this post, I include screenshots and examples from Gigamon’s Security Posture Insight Agent. This article assumes you have: An existing SaaS or security product with accessible telemetry. A small ISV team (2–3 engineers + 1 PM). Focus on a single high value scenario for the first agent. The Composite Application Model (What You Are Building) When I begin designing an agent, I think end-to-end, from data ingestion requirements through agentic logic, following the Composite application model. The Composite Application Model consists of five layers: Data Sources – Your product’s raw security, audit, or operational data. Ingestion – Getting that data into Microsoft Sentinel. Sentinel data lake & Microsoft Graph – Normalization, storage, and correlation. Agent – Reasoning logic that queries data and produces outcomes. End User – Security Copilot or SaaS experiences that invoke the agent. This separation allows for evolving data ingestion and agent logic simultaneously. It also helps avoid downstream surprises that require going back and rearchitecting the entire solution. Optional Prerequisite You are enrolled in the ISV Success Program, so you can earn Azure Credits to provision Security Compute Units (SCUs) for Security Copilot Agents. Phase 1: Data Ingestion Design & Implementation Choose Your Ingestion Strategy The first choice I face when designing an agent is how the data is going to flow into my Sentinel workspace. Below I document two primary methods for ingestion. Option A: Codeless Connector Framework (CCF) This is the best option for ISVs with REST APIs. To build a CCF solution, reference our documentation for getting started. Option B: CCF Push (Public Preview) In this instance, an ISV pushes events directly to Sentinel via a CCF Push connector. Our MS Learn documentation is a great place to get started using this method. Additional Note: In the event you find that CCF does not support your needs, reach out to App Assure so we can capture your requirements for future consideration. Azure Functions remains an option if you’ve documented your CCF feature needs. Phase 2: Onboard to Microsoft Sentinel data lake Once my data is flowing into Sentinel, I onboard a single Sentinel workspace to data lake. This is a one-time action and cannot be repeated for additional workspaces. Onboarding Steps Go to the Defender portal. Follow the Sentinel Data lake onboarding instructions. Validate that tables are visible in the lake. See Running KQL Queries in data lake for additional information. Phase 3: Build and Test the Agent in Microsoft Foundry Once my data is successfully ingested into data lake, I begin the agent development process. There are multiple ways to build agents depending on your needs and tooling preferences. For this example, I chose Microsoft Foundry because it fit my needs for real-time logging, cost efficiency, and greater control. 1. Create a Microsoft Foundry Instance Foundry is used as a tool for your development environment. Reference our QuickStart guide for setting up your Foundry instance. Required Permissions: Security Reader (Entra or Subscription) Azure AI Developer at the resource group After setup, click Create Agent. 2. Design the Agent A strong first agent: Solves one narrow security problem. Has deterministic outputs. Uses explicit instructions, not vague prompts. Example agent responsibilities: To query Sentinel data lake (Sentinel data exploration tool). To summarize recent incidents. To correlate ISVs specific signals with Sentinel alerts and other ISV tables (Sentinel data exploration tool). 3. Implement Agent Instructions Well-designed agent instructions should include: Role definition ("You are a security investigation agent…"). Data sources it can access. Step by step reasoning rules. Output format expectations. Sample Instructions can be found here: Agent Instructions 4. Configure the Microsoft Model Context Protocol (MCP) tooling for your agent For your agent to query, summarize and correlate all the data your connector has sent to data lake, take the following steps: Select Tools, and under Catalog, type Sentinel, and then select Microsoft Sentinel Data Exploration. For more information about the data exploration tool collection in MCP server, see our documentation. I always test repeatedly with real data until outputs are consistent. For more information on testing and validating the agent, please reference our documentation. Phase 4: Migrate the Agent to Security Copilot Once the agent works in Foundry, I migrate it to Security Copilot. To do this: Copy the full instruction set from Foundry Provision a SCU for your Security Copilot workspace. For instructions, please reference this documentation. Make note of this process as you will be charged per hour per SCU Once you are done testing you will need to deprovision the capacity to prevent additional charges Open Security Copilot and use Create From Scratch Agent Builder as outlined here. Add Sentinel data exploration MCP tools (these are the same instructions from the Foundry agent in the previous step). For more information on linking the Sentinel MCP tools, please refer to this article. Paste and adapt instructions. At this stage, I always validate the following: Agent Permissions – I have confirmed the agent has the necessary permissions to interact with the MCP tool and read data from your data lake instance. Agent Performance – I have confirmed a successful interaction with measured latency and benchmark results. This step intentionally avoids reimplementation. I am reusing proven logic. Phase 5: Execute, Validate, and Publish After setting up my agent, I navigate to the Agents tab to manually trigger the agent. For more information on testing an agent you can refer to this article. Now that the agent has been executed successfully, I download the agent Manifest file from the environment so that it can be packaged. Click View code on the Agent under the Build tab as outlined in this documentation. Publishing to the Microsoft Security Store If I were publishing my agent to the Microsoft Security Store, these are the steps I would follow: Finalize ingestion reliability. Document required permissions. Define supported scenarios clearly. Package agent instructions and guidance (by following these instructions). Summary Based on my experience developing Security Copilot agents on Microsoft Sentinel data lake, this playbook provides a practical, repeatable framework for ISVs to accelerate their agent development and delivery while maintaining high standards of quality. This foundation enables rapid iteration—future agents can often be built in days, not weeks, by reusing the same ingestion and data lake setup. When starting on your own agent development journey, keep the following in mind: To limit initial scope. To reuse Microsoft managed infrastructure. To separate ingestion from intelligence. What Success Looks Like At the end of this development process, you will have the following: A Microsoft Sentinel data connector live in Content Hub (or in process) that provides a data ingestion path. Data visible in data lake. A tested agent running in Security Copilot. Clear documentation for customers. A key success factor I look for is clarity over completeness. A focused agent is far more likely to be adopted. Need help? If you have any issues as you work to develop your agent, please reach out to the App Assure team for support via our Sentinel Advisory Service . Or if you have any other tips, please comment below, I’d love to hear your feedback.591Views2likes0CommentsDo XDR Alerts cover the same alerts available in Alert Policies?
The alerts in question are the 'User requested to release a quarantined message', 'User clicked a malicious link', etc. About 8 of these we send to 'email address removed for privacy reasons'. That administrator account has an EOM license, so Outlook rules can be set. We set rules to forward those 8 alerts to our 'email address removed for privacy reasons' address. This is, very specifically, so the alert passes through the @tenant.com address, and our ticketing endpoint knows what tenant sent it. But this ISN'T ideal because it requires an EOP license (or similar - this actually hasn't been an issue until now just because of our customer environments). I've looked at the following alternatives: - Setting email address removed for privacy reasons as the recipient directly on the Alert Policies in question. This results in the mail going directly from microsoft to our Ticketing Portal - so it ends up sorted into Microsoft tickets. and the right team doesn't get it. SMTP Forwarding via either Exchange AC User controls or Mail Flow Rules. But these aren't traditional forwarding, and they have the same issue as above. Making administrator @tenant.com a SHARED mailbox that we can also login to (for administration purposes). But this doesn't allow you to set Outlook rules (or even login to Outlook). I've checked out the newer alerts under Defender's Settings panel - XDR alerts, I think they're called. Wondering if these can be leveraged at all for this? Essentially, trying to get these Alerts to come to our external ticketing address, from the tenants domain (instead of Microsoft). I could probably update Autotask's rules to check for a header, and set that header via Mail Flow rules, but.. just hoping I don't have to do that for everyone.Impersonation Protection: Users to Protect should also be Trusted Senders
Hey all, sort of a weird question here. Teaching my staff about Impersonation Protection, and it's kind of occurred to me that any external sender added to 'Senders to Protect' sort of implicitly should also be a 'Trusted Sender'. Example - we're an MSP, and we want our Help Desk (email address removed for privacy reasons) to be protected from impersonation. Specifically, we want to protect the 'Help Desk' name. So we add email address removed for privacy reasons to Senders to protect. However, we ALSO want to make sure our emails come thru. So we've ALSO had to add email address removed for privacy reasons to Trusted Senders on other tenants. Chats with Copilot have sort of given me an understanding that this is essentially a 'which is more usefuI' scenario. But CoPilot makes things up, and I want some human input. In theory, ANYONE we add to 'trusted senders' we ALSO want protected from Impersonation. Anyone we protect from Impersonation we ALSO want to trust. Copilot says you SHOULDN'T do both. Which is better / more practical?Ingest Microsoft XDR Advanced Hunting Data into Microsoft Sentinel
I had difficulty finding a guide that can query Microsoft Defender vulnerability management Advanced Hunting tables in Microsoft Sentinel for alerting and automation. As a result, I put together this guide to demonstrate how to ingest Microsoft XDR Advanced Hunting query results into Microsoft Sentinel using Azure Logic Apps and System‑Assigned Managed Identity. The solution allows you to: Run Advanced Hunting queries on a schedule Collect high‑risk vulnerability data (or other hunting results) Send the results to a Sentinel workspace as custom logs Create alerts and automation rules based on this data This approach avoids credential storage and follows least privilege and managed identity best practices. Prerequisites Before you begin, ensure you have: Microsoft Defender XDR access Microsoft Sentinel deployed Azure Logic Apps permission Application Administrator or higher in Microsoft Entra ID PowerShell with Az modules installed Contributor access to the Sentinel workspace Architecture at a Glance Logic App (Managed Identity) ↓ Microsoft XDR Advanced Hunting API ↓ Logic App ↓ Log Analytics Data Collector API ↓ Microsoft Sentinel (Custom Log) Step 1: Create a Logic App In the Azure Portal, go to Logic Apps Create a new Consumption Logic App Choose the appropriate: Subscription Resource Group Region Step 2: Enable System‑Assigned Managed Identity Open the Logic App Navigate to Settings → Identity Enable System‑assigned managed identity Click Save Note the Object ID This identity will later be granted permission to run Advanced Hunting queries. Step 3: Locate the Logic App in Entra ID Go to Microsoft Entra ID → Enterprise Applications Change filter to All Applications Search for your Logic App name Select the app to confirm it exists Step 4: Grant Advanced Hunting Permissions (PowerShell) Advanced Hunting permissions cannot be assigned via the portal and must be done using PowerShell. Required Permission AdvancedQuery.Read.All PowerShell Script # Your tenant ID (in the Azure portal, under Azure Active Directory > Overview). $TenantID=”Your TenantID” Connect-AzAccount -TenantId $TenantID # Get the ID of the managed identity for the app. $spID = “Your Managed Identity” # Get the service principal for Microsoft Graph by providing the AppID of WindowsDefender ATP $GraphServicePrincipal = Get-AzADServicePrincipal -Filter "AppId eq 'fc780465-2017-40d4-a0c5-307022471b92'" | Select-Object Id # Extract the Advanced query ID. $AppRole = $GraphServicePrincipal.AppRole | ` Where-Object {$_.Value -contains "AdvancedQuery.Read.All"} # If AppRoleID comes up with blank value, it can be replaced with 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 # Now add the permission to the app to read the advanced queries New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id # Or New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 After successful execution, verify the permission under Enterprise Applications → Permissions. Step 5: Build the Logic App Workflow Open Logic App Designer and create the following flow: Trigger Recurrence (e.g., every 24 hours Run Advanced Hunting Query Connector: Microsoft Defender ATP Authentication: System‑Assigned Managed Identity Action: Run Advanced Hunting Query Sample KQL Query (High‑Risk Vulnerabilities) Send Data to Log Analytics (Sentinel) On Send Data, create a new connection and provide the workspace information where the Sentinel log exists. Obtaining the Workspace Key is not straightforward, we need to retrieve using the PowerShell command. Get-AzOperationalInsightsWorkspaceSharedKey ` -ResourceGroupName "<ResourceGroupName>" ` -Name "<WorkspaceName>" Configuration Details Workspace ID Primary key Log Type (example): XDRVulnerability_CL Request body: Results array from Advanced Hunting Step 6: Run the Logic app to return results In the logic app designer select run, If the run is successful data will be sent to sentinel workspace. Step 7: Validate Data in Microsoft Sentinel In Sentinel, run the query: XDRVulnerability_CL | where TimeGenerated > ago(24h) If data appears, ingestion is successful. Step 8: Create Alerts & Automation Rules Use Sentinel to: Create analytics rules for: CVSS > 9 Exploit available New vulnerabilities in last 24 hours Trigger: Email notifications Incident creation SOAR playbooks Conclusion By combining Logic Apps, Managed Identities, Microsoft XDR, and Microsoft Sentinel, you can create a powerful, secure, and scalable pipeline for ingesting hunting intelligence and triggering proactive detections.146Views1like1CommentAgentic Use Cases for Developers on the Microsoft Sentinel Platform
Interested in building an agent with Sentinel platform solutions but not sure where to start? This blog will help you understand some common use cases for agent development that we’ve seen across our partner ecosystem. SOC teams don’t need more alerts - they need fast, repeatable investigation and response workflows. Security Copilot agents can help orchestrate the steps analysts perform by correlating across the Sentinel data lake, executing targeted KQL queries, fetching related entities, enriching with context, and producing an evidence-backed decision without forcing analysts to switch tools. Microsoft Sentinel platform is a strong foundation for agentic experiences because it exposes a normalized security data layer, an investigation surface based on incidents and entities, and extensive automation capabilities. An agent can use these primitives to correlate identity, endpoint, cloud, and network telemetry; traverse entity relationships; and recommend remediation actions. In this blog, I will break down common agentic use cases that developers can implement on Sentinel platform, framed in buildable and repeatable patterns: Identify the investigation scenario Understand the required Sentinel data connectors and KQL queries Build enrichment and correlation logic Summarize findings with supporting evidence and recommended remediation steps Use Case 1: Identity & Access Intelligence Investigation Scenario: Is this risky sign-in part of an attack path? Signals Correlated: Identity access telemetry: Source user, IPs, target resources, MFA logs Authentication outcomes and diversity: Success vs. failure, Geographic spread Identity risk posture: User risk level/state Post-auth endpoint execution: Suspicious LOLBins Correlation Logic: An analyst receives a risky sign-in signal for a user and needs to determine whether the activity reflects expected behavior - such as travel, remote access, or MFA friction - or if it signals the early stage of an identity compromise that could escalate into privileged access and downstream workload impact. Practical Example: Silverfort Identity Threat Triage Agent, which is built on a similar framework, takes the user’s UPN as input and builds a bounded, last-24-hour investigation across authentication activity, MFA logs, user risk posture, and post-authentication endpoint behavior. Outcome: By correlating identity risk signals, MFA logs, sign-in success and failure patterns, and suspicious execution activity following authentication, the agent connects the initial risky sign-in to endpoint behavior, enabling the analyst to quickly assess compromise likelihood, identify escalation indicators, and determine appropriate remediation actions. “Our collaboration with Microsoft Sentinel and Security Copilot underscores the central role identity plays across every stage of attack path triage. By integrating Silverfort’s identity risk signals with Microsoft Entra ID and Defender for Endpoint, and sharing rich telemetry across platforms, we enable Security Copilot Agent to distinguish isolated anomalies from true identity-driven intrusions - while dramatically reducing the manual effort traditionally required for incident response and threat hunting. AI-driven agents accelerate analysis, enrich investigative context, reduce dwell time, and speed detection. Instead of relying on complex queries or deep familiarity with underlying data structures, security teams can now perform seamless, identity-centric reasoning within a single interaction.” - Frank Gasparovic, Director of Solution Architecture, Technology Alliances, Silverfort Use Case 2: Cyber Resilience, Backup & Recovery Investigation Scenario: Are the threats detected on a backup indicative of production impact and recovery risk? Signals Correlated: Backup threat telemetry: Backup threat scan alerts, risk analysis events, affected host/workload, detection timestamps Cross-vendor security alerts: Endpoint, network, and cloud security alerts for the same host/workload in the same time window Correlation Logic: The agent correlates threat signals originating from the backup environment with security telemetry associated with same host/workload to validate whether there is corroborating evidence in the production environment and whether activity aligns in time. Practical Example: Commvault Security Investigation Agent, which is built on a similar framework, takes a hostname as input and builds an investigation across Commvault Threat Scan / Risk Analysis events and third-party security telemetry. By correlating backup-originating detections with production security activity for the same host, the agent determines whether the backup threat signal aligns with observable production impact. Outcome: By correlating backup threat detections with endpoint, network, and cloud security telemetry while validating timing alignment, event spikes, and data coverage, the agent connects a backup originating threat signal to production evidence, enabling the analyst to quickly assess impact likelihood and determine appropriate actions such as containment or recovery-point validation. Use Case 3: Network, Exposure & Connectivity Investigation Scenario: Is this activity indicative of legitimate remote access, or does it demonstrate suspicious connectivity and access attempts that increase risk to private applications and internal resources. Signals Correlated: User access telemetry: Source user, source IPs/geo, device/context, destinations Auth and enforcement outcomes: Success vs. failure, MFA allow/block Behavior drift: new/rare IPs/locations, unusual destination/app diversity. Suspicious activity indicators: Risky URLs/categories, known-bad indicators, automated/bot-like patterns, repeated denied private app access attempts Correlation Logic: An analyst receives an alert for a specific user and needs to determine whether the activity reflects expected behavior such as travel, remote work, or VPN usage, or whether it signals the early stages of a compromise that could later extend into private application access. Practical Example: Zscaler ZIA ZPA Correlation Agent starts with a username and builds a bounded, last-24-hour investigation across Zscaler Internet Access and Zscaler Private Access activity. By correlating user internet behavior, access context, and private application interactions, the agent connects the initial Zscaler alert to any downstream access attempts or authentication anomalies, enabling the analyst to quickly assess risk, identify suspicious patterns, and determine whether Zscaler policy adjustments are required. Outcome: Provides a last‑24‑hour verdict on whether the activity reflects expected access patterns or escalation toward private application access, and recommends next actions—such as closing as benign drift, escalating for containment, or tuning access policy—based on correlated evidence. Use Case 4: Endpoint & Runtime Intelligence Investigation Scenario: Is this process malicious or a legitimate admin action? Signals Correlated: Execution context: Process chain, full command line, signer, unusual path Account & logon: Initiating user, logon type (RDP/service), recent risky sign-ins Tooling & TTPs: LOLBins, credential access hints, lateral movement tooling Network behavior: Suspicious connections, repeated callbacks/beaconing Correlation Logic: A PowerShell alert triggers on a production server. The agent ties the process to its parent (e.g., spawned by a web worker vs. an admin shell), validates the command-line indicators, correlates outbound connections from the same PID to a first-seen destination, and checks for immediate follow-on persistence and any adjacent runtime alerts in the same time window. Outcome: Classifies the activity as malicious vs. admin and produces an evidence pack (process tree, key command indicators, destinations, persistence/tamper artifacts) as well as the recommended containment step (isolate host and revoke/reset initiating credentials). Use Case 5: Exposure & Exploitability Investigation Scenario: What is the likelihood of exploitation and blast radius? Signals Correlated: Asset exposure: Internet-facing status, exposed services/ports, and identity or network paths required to reach the workload Exploit activity: Defender alerts on the resource, IDS/WAF hits, IOC matches, and first seen exploit or probing attempts Risk amplification signals: Internet communication, high privilege access paths, and indicators that the workload processes PII or sensitive data Blast radius: Downstream reachability to crown jewel systems (e.g., databases, key vaults) and trust relationships that could enable escalation Correlation Logic: An analyst receives a Medium/High Microsoft Defender for Cloud alert on a workload and needs to determine whether it’s a standalone detection or an exploitable exposure that can quickly progress into privilege abuse and data impact. The agent correlates exposure evidence signals such as internet reachability, high-privilege paths, and indicators that workload handles sensitive data by analyzing suspicious network connections in the same bounded time window. Outcome: Produces a resource-specific risk analysis that explains why the Defender for Cloud alert is likely to be exploited, based on asset attack surface and effective privileges, plus any supporting activity in the same 24-hour window. Use Case 6: Threat Intelligence & Adversary Context Investigation Scenario: Is this activity aligned with known attacker behavior? Signals Correlated: Behavior sequence: ordered events identity → execution → network. Technique mapping: MITRE ATT&CK technique IDs, typical progression, and required prerequisites. Threat intel match: campaign/adversary, TTPs, IOCs Correlation Logic: A chain of identity compromise, PowerShell obfuscation, and periodic outbound HTTPS is observed. The agent maps the sequence to ATT&CK techniques and correlates it with threat intel that matches a known adversary campaign. Outcome: Surfaces adversary-aligned behavioral insights and TTP context to help analysts assess intrusion likelihood and guide the next investigation steps. Summary This blog is intended to help developers better understand the key use cases for building agents with Microsoft Sentinel platform along with practical patterns to apply when designing and implementing agent scenarios. Need help? If you have any issues as you work to develop your agent, the App Assure team is available to assist via our Sentinel Advisory Service. Reach out via our intake form. Resources Learn more: For a practical overview of how ISVs can move from Sentinel data lake onboarding to building agents, see the Accelerate Agent Development blog - https://aka.ms/AppAssure_AccelerateAgentDev. Get hands-on: Explore the end-to-end journey from Sentinel data lake onboarding to a working Security Copilot agent through the accompanying lab modules available on GitHub Repo: https://github.com/suchandanreddy/Microsoft-Sentinel-Labs.958Views1like0Comments