Recent Discussions
Defender XDR: Tables not supported for table management
I am trying to extend the table retention of specific tables to allow them to flow to Sentinel Analytics but keep getting the message "This table is not supported for table management" in the Sentinel > Configuration > Tables page. The Sentinel workspace is connected in System > Settings > Microsoft Sentinel. I can see the table type is XDR in the list which seems to be the reason why it can't be managed. Any ideas why this table is not able to be managed.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.
SmartScreen reputation issue for EV Code Signed Windows application
Hello Microsoft Defender Threat Intelligence Team, We are the developer of a legitimate Windows desktop application called "ShangJing". Recently, our users reported that Microsoft Defender SmartScreen displays the following warning when downloading and launching our application: "Microsoft Defender SmartScreen can't verify this file is safe." The application is not malicious and has been digitally signed with a GlobalSign EV Code Signing Certificate. Application information: Product Name: ShangJing Publisher: Zhaoyi Information Technology (Shanghai) Co., Ltd. Certificate: GlobalSign EV Code Signing Certificate File: 尚镜_2.0.0_platinum_setup.exe Issue: Users receive SmartScreen reputation warning when downloading our application. We have already submitted the file through Microsoft Security Intelligence submission portal 7 days ago, but we have not received any update yet. Submission ID: 0c015296-b9cf-4130-9eaf-fc59cd145370 The file is distributed through our official website: https://www.changine.cn/downloads We would like to understand: 1. Is this caused by insufficient SmartScreen reputation for a newly released binary? 2. Is there any additional verification required from the software publisher side? 3. How can we ensure our legitimate application gains proper SmartScreen reputation? Our application is widely used for live streaming and camera-related workflows. It does not contain any malicious behavior. We would appreciate any guidance from the Microsoft team. Thank you.
Need information on generating sample events for Threat Intelligence" (both duplicate posts)
Two things are tripping this up, and they're common mix-ups: First — Attack Simulation Training doesn't generate Threat Intelligence events. If you used the built-in phishing simulator, its logs only show up under Email & collaboration → Attack simulation training → Simulations — they're intentionally excluded from real Threat Intelligence telemetry. That's likely why nothing's showing up even though you ran a campaign. Second — your EICAR test should actually work, but check the right place: not the generic Office 365 Management Activity API's AuditLogRecordType page in isolation — go specifically to the RecordType values used for Defender for Office 365 threat events: 28 = ThreatIntelligence (phishing/malware events) 41 = ThreatIntelligenceUrl (Safe Links time-of-click/block events) Plus ThreatIntelligenceAtpContent, ThreatFinder, MSTIC To reliably generate one: Confirm Purview audit logging is enabled for the tenant first — if it isn't, nothing downstream gets logged regardless of what you trigger. From an external mailbox, send a test user the EICAR string as a .txt attachment (exact 68-byte string, see Microsoft's anti-malware testing doc). Defender for Office 365 should detect and quarantine it. Verify it landed first in the portal UI: Email & collaboration → Explorer → Malware tab — if it's there, the underlying ThreatIntelligence record exists and the Management API call should return it (allow a short delay; these aren't instant). For the Safe Links side, send a known-safe-but-flagged test URL (Microsoft publishes test URLs for this) to trigger ThreatIntelligenceUrl. If it shows up in Explorer but still doesn't appear via the Management API, that's usually an API subscription/permission issue (you need an active subscription to the DLP.All or relevant Office 365 Management API content type, not just Graph permissions) — worth checking separately from the detection side.Can the Microsoft Defender portal show the server details as per security group?
Yes — this is exactly what Device Groups + RBAC are designed for in Microsoft Defender (assuming you're managing these servers through Defender for Endpoint, which is the typical path for cross-vendor server monitoring). The model: Device groups are the scoping unit (not Entra security groups directly) — create one per vendor/company (e.g., "Company A Servers", "Company B Servers"), using a matching rule (tag, OS, name pattern, etc.) to auto-assign devices. RBAC roles then get tied to an Entra security group and granted access to only specific device groups. So: Company A's people go in an Entra group → that group is assigned an MDE role scoped to "Company A Servers" only → they only ever see those devices, alerts, and incidents in the portal. You as admin keep your existing Global Admin/Security Admin role (or get added to both device groups' RBAC scope), so you retain visibility across both. Path: Settings → Endpoints → Permissions → Device groups to create the groups, then Permissions → Roles to create a role and tie it to your Entra security group with that device group as the scope. One thing to verify before committing to this design: this RBAC model affects what shows in alerts, incidents, advanced hunting (scoped automatically), and inventory — but make sure nobody from Company A/B also needs organization-wide Defender features like global threat analytics, since those aren't scopable the same way. If you're actually talking about servers monitored via Defender for Cloud (Azure subscription-based, not MDE-onboarded), the equivalent mechanism is Azure RBAC at the subscription/resource group level (assign Security Reader scoped to the RG containing Company A's VMs) — different mechanism, same outcome. Worth clarifying which portal/product this is so the right one gets recommended.
Microsoft Defender doesn't, Spy hunter shows a Hijacker
Spy Hunter indicates a "Elex Hijacker" and three other problems were as Defender and McAfee do not show any problem. Is Spy Hunter legitimate? I did have a Search engine redirect problem that has a name "ext.ladispatcher.com" and "search-load.com" while using Chrome browser with Chrome search engine. But no problem with Microsoft Edge and Bing. My monitor screen occasionally momentary collapses and reverts back to normal in a split second. Could there be a connection to malware.? Please let me know if i am posting on the wrong site.Need information on generating sample events for Threat Intelligence
Hi community, I am working on exploring MS Threat Intelligence and its features. But I am not able to generate sample data for this product, nor able to view the Threat Intelligence logs using Microsoft Management API following the schema - https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#auditlogrecordtype I tried sending some mails from external email account to my organisation's test user containing EICAR files, and also tried with some safe but malicious test URLs. But still unable to get data inside Threat Intelligence. Can someone please help me here for generating events and viewing the content using Management APIs?
Need information on generating sample events for Threat Intelligence
Hi community, I am working on exploring MS Threat Intelligence and its features. But I am not able to generate sample data for this product, nor able to view the Threat Intelligence logs using Microsoft Management API following the schema - https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#auditlogrecordtype I tried sending some mails from external email account to my organisation's test user containing EICAR files, and also tried with some safe but malicious test URLs. But still unable to get data inside Threat Intelligence. Can someone please help me here for generating events and viewing the content using Management APIs?Can the Microsoft Defender portal show the server details as per security group?
I'm using Microsoft Defender to monitor the servers. I have multiple groups of people working from various other vendors. I would like create multiple security groups and add people based on their company and configure the defender such a manner that only people from Company "A" can see their own servers and people working from Campany "B" can see their respective servers. Also, I as admin can see both "A's" and "B's" servers. Can this be achieved using Microsoft Defender? If yes, how to achieve this? Any step-by-step approach would help. Or if there are any other ways, please suggest. Thanks
New Blog | New Copilot for Security Plugin Name Reflects Broader Capabilities
By Michael Browning The Copilot for Security team is continuously enhancing threat intelligence (TI) capabilities in Copilot for Security to provide a more comprehensive and integrated TI experience for customers. We're excited to share that the Copilot for Security threat Intelligence plugin has broadened beyond just MDTI to now encapsulate data from other TI sources, including Microsoft Threat Analytics (TA) and SONAR, with even more sources becoming available soon. To reflect this evolution of the plugin, customers may notice a change in its name from "Microsoft Defender Threat Intelligence (MDTI) to "Microsoft Threat Intelligence," reflecting its broader scope and enhanced capabilities. Since launch in April, Copilot for Security customers have been able to access, operate on, and integrate the raw and finished threat intelligence from MDTI developed from trillions of daily security signals and the expertise of over 10 thousand multidisciplinary analysts through simple natural language prompts. Now, with the ability for Copilot for Security's powerful generative AI to reason over more threat intelligence, customers have a more holistic, contextualized view of the threat landscape and its impact on their organization. Read the full post here: New Copilot for Security Plugin Name Reflects Broader CapabilitiesNew Blog | Introducing the MDTI Premium Data Connector for Sentinel
By Michael Browning The MDTI and Unified Security Operations Platform teams are excited to introduce an MDTI data connector available in the Unified Security Operations Platform and standalone Sentinel experiences. The connector enables customers to apply the powerful raw and finished threat intelligence in MDTI, including high-fidelity indicators of compromise (IoCs), across their security operations to detect and respond to the latest threats. Microsoft researchers, with the backing of interdisciplinary teams of thousands of experts spread across 77 countries, continually add new analysis of threat activity observed across more than 78 trillion threat signals to MDTI, including powerful indicators drawn directly from threat infrastructure. In Sentinel, this intelligence enables enhanced threat detection, enrichment of incidents for rapid triage, and the ability to launch investigations that proactively surface external threat infrastructure before it can be used in campaigns. This blog will highlight the exciting use cases for the MDTI premium data connector, including enhanced enrichment, threat detection, and hunting to ensure customer organizations are protected against the most critical threats. It will also cover how you can easily get started with this out-of-the-box connector. Read the full post here: Introducing the MDTI Premium Data Connector for SentinelNew Blog | More Threat Intelligence Content in MDTI, TA Enables Better Security Outcomes
By Michael Browning Microsoft threat intelligence empowers our customers to keep up with the global threat landscape and understand the threats and vulnerabilities most relevant to their organization. We are excited to announce that we have recently accelerated the speed and scale at which we publish threat intelligence, giving our customers more critical security insights, data, and guidance than ever before. This blog will show how our 10,000 interdisciplinary experts and applied scientists reason over more than 78 trillion daily threat signals to continuously add to our understanding of threat actors and activity. It will also show how this increased publishing cadence in Microsoft Defender Threat Intelligence (MDTI), Threat Analytics, and Copilot for Security helps enrich and contextualize hundreds of thousands of security alerts while enhancing customers' overall cybersecurity programs. Increased Intel Profiles Microsoft has published 270 new Intel profiles over the past year to help customers maintain situational awareness around the threat activity, techniques, vulnerabilities, and the more than 300 named actors Microsoft tracks. These digital compendiums of intelligence help organizations stay informed about potential threats, including Indicators of Compromise (IOCs), historical data, mitigation strategies, and advanced hunting queries. Intel profiles are continuously maintained and updated by Microsoft's threat intelligence team, which added 24 new Intel profiles in May alone, including 10 Activity Profiles, 4 Actor Profiles, 5 Technique Profiles, and 5 Vulnerability Profiles. Intel profiles are published to both MDTI and Threat Analytics, which can be found under the "Threat Intelligence" blade in the left-hand navigation menu in the Defender XDR Portal. In Threat Analytics, customers can understand how the content in Intel profiles relates to devices and vulnerabilities in their environment. In MDTI, Intel Profiles enhance security analyst triage, incident response, threat hunting, and vulnerability management workflows. In Copilot for Security, customers can quickly retrieve information from intel profiles to contextualize artifacts and correlate MDTI and Threat Analytics content and data with other security information from Defender XDR, such as incidents and hunting activities, to help customers assess their vulnerabilities and quickly understand the broader scope of an attack. For example, Copilot can reason over vulnerability intelligence in MDTI and Threat Analytics to deliver a customized, prioritized list based on a customer organization’s unique security posture. Read the full post here: More Threat Intelligence Content in MDTI, TA Enables Better Security Outcomes
Massive reduction in Threat Intelligence IP data since Monday 10th June
Hi, Anyone else see a massive reduction in Threat Intelligence IP data since Monday 10th June into Sentinel platforms? I operate two Sentinel environments and they both seen the same change. The screenshot below is the past 30 days. The past 48 hours still reports some IP information being sent but at a very reduced rate. What's changed with the feed?New Blog | Copilot for Security TI Embedded Experience in Defender XDR is now GA
By Michael Browning he Microsoft Defender Threat Intelligence (MDTI) and Defender XDR teams are pleased to announce that the Copilot for Security threat intelligence embedded experience in the Defender XDR portal is now generally available. As of today, Defender XDR customers will see a handy AI-powered sidecar in the Threat Analytics, intel profiles, intel explorer, and intel projects tabs in the threat intelligence blade (in brackets below), which returns, contextualizes, and summarizes intelligence from across MDTI and Threat Analytics about threat actors, threat tooling, and indicators of compromise (IoCs) related to their vulnerabilities and security incidents. The embedded experience on the right hand side of the Defender XDR portal has an open prompt bar as well as a guided experience with three pre-populated prompts. Read the full post here: Copilot for Security TI Embedded Experience in Defender XDR is now GANew Blog | MDTI Achieves PCI DSS Certification: Elevating Security Standards
By Ash Luitel We are excited to announce that MDTI has successfully obtained the Payment Card Industry Data Security Standard (PCI DSS) certification, representing a significant milestone in our continuous pursuit of security excellence. This accomplishment follows closely after our ISO certification, highlighting our unwavering commitment to upholding the highest standards of data protection and our dedication to safeguarding information and proactively combating fraud. This certification not only strengthens our security measures but also reaffirms the trust our customers have in us to handle their most sensitive data with the utmost care and diligence. Why the PCI DSS certification matters PCI DSS is a renowned global standard for securing credit card data and preventing fraud. For organizations that handle sensitive payment information, compliance with PCI DSS is not just a requirement - it's a cornerstone of our promise to safeguard customer data. Read the full post here: MDTI Achieves PCI DSS Certification: Elevating Security StandardsNew Blog | A Copilot for Security Customer’s Guide to MDTI
By Michael Browning With just one Security Compute Unit (SCU), Copilot for Security customers have unlimited access to the powerful operational, tactical, and strategic threat intelligence in Microsoft Defender Threat Intelligence (MDTI), a $50k per seat value, at no extra cost. This compendium of high-fidelity intelligence developed by Microsoft's team of more than 10,000 multidisciplinary security experts and informed by over 78 trillion security signals enables teams to unmask and neutralize adversaries quickly and efficiently. In this blog, we will review what MDTI is, what you get as a Copilot for Security customer, and how you can immediately tap into this powerful intelligence. What is MDTI? MDTI is a threat intelligence product that enables security professionals to directly access, ingest, and act upon trillions of daily security signals in Microsoft's telemetry. MDTI's finished intelligence, including threat articles and intel profiles, provides the latest on cyber threat actors and their tools, tactics, and procedures. Its unique security data sets enable advanced investigations that uncover malicious infrastructure connections across the global cyberthreat landscape to highlight where an organization is vulnerable and address the tools and systems used in cyberattacks. MDTI is a powerful complement to Microsoft's SIEM, XDR, and AI solutions. Copilot for Security customers can use the incredible depth and breadth of Microsoft threat intelligence in MDTI with Generative AI to quickly understand the full scope of attacks, anticipate the next steps of an ongoing campaign, and drive an optimal security plan for their organizations. They can immediately begin using MDTI in the Copilot for Security standalone experience or embedded experience in Defender XDR. They can also use MDTI directly via the MDTI' analyst workbench' experience in the Threat Intelligence blade in Defender XDR. Copilot for Security customers can tap into MDTI’s powerful threat intelligence in a variety of ways Read the full post here: A Copilot for Security Customer’s Guide to MDTI
Recent Blogs
- Many major breaches involve compromised identities, excessive privileges, or misconfigured access. Long before ransomware detonates or data leaves the building, adversaries are quietly abusing valid ...Sep 01, 2026
- 6 MIN READMicrosoft Defender Monthly news - August 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defe...Aug 05, 2026
