Recent Blogs
Member: TysonPaul | Microsoft Community Hub
Retirement of Microsoft HPC Pack
Team Blog: Azure High Performance Computing (HPC)
Author: XinXin
Published: 08/25/2026
Summary: Microsoft HPC ...
Sep 04, 2026
We want to hear from the people who configure, operate, and defend with Microsoft Security every day. Share your priorities, challenges, and where you go to learn and connect.
Your feedback will he...
Sep 04, 2026
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
12 MIN READ
Executive Summary
The solution provides a repeatable way to determine which Microsoft Defender for Endpoint for Linux package is released by configured Microsoft package repositories for each opera...
Sep 01, 2026Recent Discussions
Microsoft Purview - Insider Risk Management
Microsoft AI User Group Hyderabad What are the Problems statements you faced while Implementing Insider Risk Management for different clients ? Any Common Problems and Challanges which is similar to Financial Services Organization and You have used similar approach or build a Unique Solution to solve this ? Regards, Subhajit Bhuiya
Cloudflare Log ingestion in Sentinel with CCF
Hi all, I built a connector to ingest cloudflare firewall logs using CCF. The reason why I had to build this custom one while the official one was available was because official one uses Logpush which is a service that is available only on Enterprise plan, so if you are on pro or business plan you can not use it. Putting it out here in case anyone wants to try. https://amankhan.net/posts/Cloudflare-CCF-Connector/An Entra app credential is expiring. Which workload still uses it?
A credential rotation ticket often starts with three things: an application name, an expiry date and a deadline. That is enough to know something must happen, but not enough to rotate safely. Before touching the credential, I want to know whether that exact key is still requesting tokens, which resources it accesses and where those requests appear to come from. If Microsoft Entra sign-in logs are already connected to Log Analytics or Microsoft Sentinel, KQL can answer most of that without changing anything in the tenant. This is the workflow I use. What needs to be in the workspace The important diagnostic category is ServicePrincipalSignInLogs. In Log Analytics it becomes the AADServicePrincipalSignInLogs table. Normal SigninLogs are for interactive user sign-ins and are not the right data source for an app authenticating with its own secret or certificate. The diagnostic setting is configured under: Microsoft Entra ID > Monitoring & health > Diagnostic settings Make sure ServicePrincipalSignInLogs is being sent to the workspace you are querying. Microsoft documents the available log categories and their purpose here: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-diagnostic-settings-logs-options From the Entra recommendation or the affected application, copy the Application (client) ID. Do not confuse it with the application object ID or the service principal object ID. In the Kusto table: AppId is the Application (client) ID. ServicePrincipalId is the object ID of the service principal in the tenant. ServicePrincipalCredentialKeyId identifies the secret or certificate key used for the token request. ServicePrincipalCredentialThumbprint can help identify a certificate. ResourceDisplayName and ResourceServicePrincipalId identify the target resource. Those fields are part of the documented AADServicePrincipalSignInLogs schema: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadserviceprincipalsigninlogs Step 1: See every credential recently used by the application Replace TargetAppId with the Application (client) ID from Entra: let Lookback = 30d; let TargetAppId = "00000000-0000-0000-0000-000000000000"; AADServicePrincipalSignInLogs | where TimeGenerated >= ago(Lookback) | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= ago(Lookback) | where AppId =~ TargetAppId | extend SignInSucceeded = tostring(ResultType) == "0" | summarize FirstSeen = min(SignInTime), LastSeen = max(SignInTime), Attempts = count(), SuccessfulSignIns = countif(SignInSucceeded), FailedSignIns = countif(SignInSucceeded == false), CredentialTypes = make_set(ClientCredentialType, 10), SourceIPs = make_set(IPAddress, 20), UserAgents = make_set(UserAgent, 10), TargetResources = make_set( strcat(ResourceDisplayName, " [", ResourceServicePrincipalId, "]"), 20 ) by AppId, ServicePrincipalId, ServicePrincipalName, ServicePrincipalCredentialKeyId, ServicePrincipalCredentialThumbprint, FederatedCredentialId | order by LastSeen desc This gives me a short usage map for the application. If the expiring credential's key ID appears in the result, that exact credential was used for at least one recorded token request during the selected lookback period. The target resources show what it requested a token for. Source IPs and user agents usually help narrow down the workload. They are clues, not host identification. A source IP might be a NAT gateway, proxy or shared outbound address, and user-agent strings are neither guaranteed nor trustworthy. I use them to narrow the search in deployment settings, automation jobs, Key Vault references and CI/CD configuration, not as final proof of where the workload runs. Rows with a populated FederatedCredentialId represent workload identity federation. They should not be mistaken for use of the expiring secret or certificate. Step 2: Inspect the exact credential Once the expiring key ID is known, this query shows the individual sign-in records for that key: let Lookback = 30d; let TargetAppId = "00000000-0000-0000-0000-000000000000"; let ExpiringCredentialKeyId = "11111111-1111-1111-1111-111111111111"; AADServicePrincipalSignInLogs | where TimeGenerated >= ago(Lookback) | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= ago(Lookback) | where AppId =~ TargetAppId | where ServicePrincipalCredentialKeyId =~ ExpiringCredentialKeyId | extend Result = iff(tostring(ResultType) == "0", "Success", "Failure") | project SignInTime, Result, ResultType, ResultDescription, ServicePrincipalName, ServicePrincipalId, ClientCredentialType, ServicePrincipalCredentialKeyId, ServicePrincipalCredentialThumbprint, IPAddress, UserAgent, ResourceDisplayName, ResourceServicePrincipalId, CorrelationId | order by SignInTime desc A successful row is direct evidence that Entra accepted that credential for a token request at that time. Repeated failures can also be useful: they might show an incomplete rotation, an expired credential that is still configured somewhere, or a forgotten workload that keeps retrying. No rows do not mean "safe to delete." They only mean that no matching event exists in the data currently available to this workspace for the selected period. The workload might run monthly, the event might be outside retention, the diagnostic category might have been enabled recently, or the relevant logs might be routed elsewhere. The table also does not contain the application's business owner. I confirm ownership on the application or enterprise application in Entra, or enrich the result from an existing CMDB or Sentinel watchlist. I would not invent an owner from the last source IP or from whoever originally created the app. Step 3: Prove the replacement is actually in use After adding the replacement credential and updating the workload, I use the cutover time plus the old and new key IDs to verify the change: let CutoverTime = datetime(2026-08-26T12:00:00Z); let TargetAppId = "00000000-0000-0000-0000-000000000000"; let OldCredentialKeyId = "11111111-1111-1111-1111-111111111111"; let NewCredentialKeyId = "22222222-2222-2222-2222-222222222222"; AADServicePrincipalSignInLogs | where TimeGenerated >= CutoverTime | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= CutoverTime | where AppId =~ TargetAppId | where ServicePrincipalCredentialKeyId in~ (OldCredentialKeyId, NewCredentialKeyId) | extend Credential = case( ServicePrincipalCredentialKeyId =~ OldCredentialKeyId, "old", ServicePrincipalCredentialKeyId =~ NewCredentialKeyId, "new", "other" ) | where Credential != "other" | summarize FirstSeen = min(SignInTime), LastSeen = max(SignInTime), Attempts = count(), SuccessfulSignIns = countif(tostring(ResultType) == "0"), FailedSignIns = countif(tostring(ResultType) != "0"), SourceIPs = make_set(IPAddress, 20), TargetResources = make_set(ResourceDisplayName, 20) by Credential, ServicePrincipalCredentialKeyId | order by LastSeen desc Before I remove the old credential, I want to see a successful token request with the new key ID after the cutover. I also run a real operation against the intended resource. A generic process health check is not enough if it never exercises the dependency that uses Entra authentication. Continued sign-ins with the old key after the cutover are a clear sign that another instance, deployment slot or workload still has the old value. An absence of old-key sign-ins becomes meaningful only after the expected workload schedule has been covered and the logs have arrived in the workspace. One final trap is token caching. Service principal sign-in logs show token requests, not every API call made with a token. Removing the old client credential prevents it from obtaining new tokens, but an access token already issued by Microsoft Entra normally remains valid until it expires. The rotation test must therefore force the workload to acquire a fresh token. Access token documentation: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens My rotation order is simple: Identify the exact old credential and the workload using it. Add the replacement while the old credential is still valid. Deploy the new credential to the workload's secret store. Force a fresh token request and execute a real operation. Confirm the new key ID in AADServicePrincipalSignInLogs. Watch for unexpected use of the old key for an appropriate period. Remove the old credential after the evidence and rollback window are sufficient for that workload. Microsoft Entra's preview recommendations for expiring application credentials and expiring service principal credentials are useful starting points. For me, the KQL correlation is the part that turns the warning into a controlled change instead of a blind rotation. Recommendation documentation: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-renew-expiring-application-credential https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-renew-expiring-service-principal-credential How are you carrying application ownership into Sentinel? A maintained watchlist works, but it can easily become just another stale inventory.Thank you
Thank You, Microsoft Defender Team I want to express my appreciation to the Microsoft Defender team. As a user who spends a lot of time online supporting educators, families, and community partners, it is reassuring to know that web protection, phishing protection, and reputation-based security features are working behind the scenes to help keep my devices and information safe. Technology often gets noticed when something goes wrong, but today I want to recognize what is working well. Thank you for creating tools that help protect users from threats while allowing us to focus on our work. Your efforts are appreciated!
Passkey Sign‑In Fails in Entra Free Tenants (AADSTS135016 – FIDO Sign‑In Disabled via Policy)
Hello everyone, I’m documenting an issue which seems to be appearing across multiple tenants and multiple threads, but the root cause has never been clearly stated. If I’m mistaken in any part of this analysis, my apologies and I welcome correction. This post is intended to consolidate the symptoms, the misleading error message, and the actual underlying cause so other admins don’t waste time troubleshooting a problem that cannot be fixed through configuration. Summary of the Issue In Microsoft Entra ID Free tenants: Passkeys can be enabled Passkeys can be registered Passkeys appear correctly in Security Info Passkeys work for MFA Passkeys work for self‑service setup But passkey sign‑in fails, consistently, with: AADSTS135016: FIDO sign‑in is disabled via policy This occurs even when: FIDO2 is fully enabled AAGUIDs are correct “Allow self‑service setup” is enabled No Conditional Access policies exist Security defaults are disabled User‑level MFA settings are off Passkey profiles are correctly targeted Browser/device combinations are clean Multiple admins have reported this exact behavior. Why This Error Is Misleading The error suggests that a policy is blocking FIDO sign‑in. However, in Entra Free tenants, the real issue is that the required policy objects do not exist at all. Specifically, Entra Free tenants do not include: Authentication Strengths Passwordless Strength Phishing‑Resistant MFA Strength FIDO2 Strength Conditional Access enforcement Strength‑based sign‑in policies Passkey sign‑in requires these backend objects to bind the FIDO2 credential to the primary authentication flow. Without them, the sign‑in pipeline rejects the passkey and throws error 135016, even though registration succeeds. This is why: Some tenants work (licensed) Some tenants fail (Entra Free) “Fixes” like waiting, renaming profiles, or toggling settings only work in licensed tenants where the backend policy objects exist No amount of configuration resolves the issue in Entra Free This is a licensing limitation, not a configuration problem. Why This Needs Attention Microsoft is actively promoting: Passkeys Passwordless authentication Phishing‑resistant MFA Modern identity security But Entra Free tenants — including personal tenants, small labs, students, developers, and home environments — cannot use passkey sign‑in at all, despite documentation implying otherwise. This creates: Confusion Wasted time Misleading error messages Failed deployments Frustration for users who purchased physical passkeys A contradiction between Microsoft’s marketing and actual product behavior Passkeys are a security feature, not an enterprise feature. Basic passkey sign‑in should not be locked behind Entra ID P1. Request to Microsoft Please consider enabling basic passkey sign‑in for Entra Free tenants. At minimum: Update documentation to clearly state that passkey sign‑in requires Authentication Strengths (P1+) Update the error message to reflect the real cause Provide guidance for admins deploying passkeys in small or personal tenants This would reduce confusion and align the product with Microsoft’s own passwordless security goals. Closing If anyone has additional data points, please add them here. This issue is affecting multiple tenants and deserves a clear, authoritative answer from Microsoft. Thanks.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.
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 OutcomesNew 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 MDTINew Blog Post | New at Secure: MDTI in Defender XDR Global Search
On the heels of introducing Microsoft Defender Threat Intelligence (MDTI) premium and standard editions into the Microsoft Defender XDR portal, we are thrilled to introduce an even greater integrated threat intelligence experience by making results for MDTI content available within Defender XDR’s global search bar. Users will notice that they can now use the top-level Defender XDR search to discover results from MDTI on indicators of compromise (IOCs), common vulnerabilities and exposures (CVEs), articles, threat actors and more. From anywhere in the portal, customers now can readily find MDTI raw intelligence including IPs, domains, hashes, and URLs as well as finished intelligence in the form of articles, intel profiles, and CVEs alongside their other content from Defender XDR when conducting searches, helping to accelerate investigations with critical threat intelligence context. Results from MDTI and Threat Analytics will appear within the “Intel Explorer” list in the results page: MDTI results are now available under the “Intel Explorer” tab when searching via Defender XDR’s global search bar. You may search and see results for indicators such as IP addresses or file hashes, intel profiles, CVEs, threat articles and more. Read the full post here: New at Secure: MDTI in Defender XDR Global Search - Microsoft Tech CommunityNew Blog | New at Secure: Enhanced Vulnerability Profiles and CVE Search within MDTI
The Microsoft Defender Threat Intelligence (MDTI) team revamped vulnerability profiles to improve customers’ ability to access world-class intelligence on vulnerabilities and exposures within the Defender XDR portal. These exciting updates include: A new layout that mirrors the design of our Threat Actor and Tool intel profiles for a more consistent experience Vulnerability profiles sorted by published date by default in list view to display a steady feed of new, high importance CVEs The decoupling of Vulnerability Profiles from open-source Common Vulnerabilities and Exposures (CVEs) so customers can access all available information on vulnerabilities An enhanced CVE search experience: searches will return all content related to a vulnerability instead of directing a user to a CVE information page. These enhancements will provide a more intuitive experience for surfacing content related to CVEs, offering critical context on threats and information within alerts and incidents. What are Vulnerability Profiles? Vulnerability Profiles are MDTI’s newest intel profile type, launched at Microsoft Ignite in November. Building off our work to introduce intel profiles to MDTI, which has become the definitive source of Microsoft’s shareable knowledge on over 200 threat actors and 70 tools, MDTI now also contains over 75 extensive profiles of the CVEs deemed most critical and relevant by our dedicated security researchers. Amid the many vulnerabilities teams must keep track of — old and new, with varying degrees of prominence and impact as threat actors adjust their techniques, tactics, and procedures (TTPs) — Vulnerability Profiles tilt the advantage back in favor of defenders by delivering focused, actionable insights and recommendations on how to protect against the most critical CVEs, based on information garnered from Microsoft’s 65 trillion threat signals per day. By routinely visiting the “Vulnerabilities” tab on the Intel Profiles page in Defender XDR, customers will see a steady stream of new profiles, sorted by published date, indicating CVEs that are considered pressing by Microsoft’s security researchers. This enables CISOs, Vulnerability Managers, SOC Analysts and Cyber Threat Intelligence Analysts alike to remain informed on these CVEs to prioritize detections and implement patching on endpoints and other recommendations in their environment for the vulnerabilities which are most relevant to their organization. Vulnerability Profiles are accessible from the “Intel profiles” page within the “Threat intelligence” blade in the left navigation. See these profiles by clicking on the “Vulnerabilities” tab: Vulnerability Profiles are accessible from the “Vulnerabilities” tab on the Intel Profiles page, which is contained under the threat intelligence blade in the left navigation. On the Vulnerability Profiles list view, the “Profile” column displays the CVE number, title, and summary of the profile, whereas the right-most column displays the published date, indicating how recently Microsoft wrote about the vulnerability. Under the “Intelligence” column in the Vulnerability Profiles list view, customers will see priority and CVSS scores as well as indications of active exploitation (“Active exploitation observed”), dark web chatter (“Chatter Observed”), and available public proof of concept exploits (“POC Available”, "1 Published POC") for these vulnerabilities. Vulnerability Profiles are decorated with proprietary information from Microsoft’s own research and telemetry that can only be found in our intel profiles. This includes original research such as observations of active exploitation in the wild; detailed analysis of the methods used to exploit these CVEs by malicious actors; detections and Advanced Hunting queries that will indicate or alert on related activity in an organization’s network; and recommendations to protect against the threat. Read the full post here: New at Secure: Enhanced Vulnerability Profiles and CVE Search within MDTI - Microsoft Tech CommunityNew Blog Post | What's New at Microsoft Secure 2024
At Microsoft Secure, we are excited to announce several new innovations from the Microsoft Defender Threat Intelligence (MDTI) team. These updates enable our customers to access valuable, high-fidelity threat intelligence where, when, and how they need it: To optimize MDTI content for customers, we have enhanced the look and feel of vulnerability profiles and are releasing the full corpus of Microsoft’s intel profiles to the MDTI standard version. We are keeping pace with Copilot for Security as it evolves, launching a new side card experience in the threat intelligence blade of Defender XDR. We have also introduced new MDTI skills and promptbooks for Copilot that deliver more of Microsoft's world-class threat intelligence to the SOC at machine speed. Finally, as we continue to build a more comprehensive threat intelligence experience across Microsoft Defender XDR, we’re proud to announce that MDTI content is now available via the global search function. Read more about what's rolling out at Microsoft Secure 2024 below: New MDTI skills and workbooks for Copilot for Security MDTI is making more threat intelligence available via new Copilot for Security skills and workbooks to help customers understand the full scope of attacks, anticipate the next steps of an ongoing campaign, and drive an optimal security plan for their organizations at machine speed and scale. These include: Correlate MDTI data with Defender XDR information: These out-of-the-box prompt books correlate MDTI data with other critical security information from Defender XDR such as incidents and hunting activities to help a user understand the broader scope of an attack. Correlate MDTI Content with Threat Analytics (TA) content: When prompted, this skill reasons over threat intelligence content from MDTI and Threat Analytics, and provides a summary of the two, e.g., "Tell me everything Microsoft knows about [this threat actor]." Obtain current reputation TI for file hashes, URLs, Domains, and IPs: This skill shows the full information for hashes and URLs, including MDTI and SONAR data. Register for our Tech Community Webinar in April 11 to learn more about how MDTI enables Copilot to deliver threat intelligence at machine speed. Read the full post here: What's New at Microsoft Secure 2024- Tech CommunityNew Blog Post | MDTI Standalone Portal Retirement and Transition to Defender XDR
On June 30th, 2024, the Microsoft Defender Threat Intelligence (MDTI) standalone portal will reach end-of-life and the Microsoft Defender XDR portal will become MDTI’s exclusive home for both standard and premium users. In this blog, we’ll guide customers using the standalone portal that wish to continue using MDTI in Defender XDR through the simple migration process. We’ll also help customers, and their teams, prepare to take advantage of the benefits MDTI brings to Microsoft’s XDR, SIEM, and AI solutions. What is happening to the MDTI standalone portal? On June 30th, 2024, the MDTI standalone portal at ti.defender.microsoft.com will be decommissioned. However, customers can seamlessly use the same features and content from MDTI's permanent home in the Microsoft Defender XDR portal in both free and premium capacities. All existing MDTI licenses will carry over to the new portal. Customers can also access this information via natural language prompts by purchasing Copilot for Security. How do I use MDTI within the Defender XDR portal? Within Microsoft Defender XDR, users will see the familiar MDTI pages under the “Threat Intelligence” blade in the left navigation menu: Microsoft Defender Threat Intelligence resources are accessible under the Threat Intelligence blade within the left navigation menu, on the “Intel profiles”, “Intel explorer”, and “Intel projects” tabs. On the “Intel explorer” tab within Defender XDR (pictured above), you will find the same features and content from the standalone portal Home page. This includes Threat Intelligence Search, Featured Articles, and Recent Threat Article streams. The content from the Profiles page on the standalone portal is available on the “Intel profiles” tab in Defender XDR. You can create or access your team and individual projects from the “Intel projects” tab. You can continue working on the same projects you created on the standalone portal by logging into Defender XDR with the same account. Read the full post here: MDTI Standalone Portal Retirement and Transition to Defender XDR - Microsoft Community Hub
New Blog | MDTI Earns Impactful Trio of ISO Certificates
Microsoft Defender Threat Intelligence (MDTI) has achieved ISO 27001, ISO 27017 and ISO 27018 certifications. The ISO, the International Organization for Standardization, develops market relevant international standards that support innovation and provide solutions to global challenges, including information security requirements around establishing, implementing, and improving an Information Security Management System (ISM). These certificates emphasize the MDTI team’s continuous commitment to protecting customer information and following the strictest standards of security and privacy standards. Read the full blog here: MDTI Earns Impactful Trio of ISO Certificates - Microsoft Community HubNew Blog | Introducing Automatic File and URL (Detonation) Analysis
The Microsoft Defender Threat Intelligence (MDTI) team continuously adds new threat intelligence capabilities to MDTI and Defender XDR, giving customers new ways to hunt, research, and contextualize threats. Read up on a new feature that enhances our file and URL analysis (detonation) capabilities in the threat intelligence blade within the Defender XDR user interface. If MDTI cannot return any results when a customer searches for a file or URL, MDTI now automatically detonates it to improve search coverage and add to our corpus of knowledge of the global threat landscape. See the blog post here: Introducing Automatic File and URL (Detonation) Analysis - Microsoft Community HubNew Blog Post | MDTI Adds Microsoft Threat Intelligence to Silobreaker
We are pleased to announce Microsoft Defender Threat Intelligence (MDTI)’s powerful new integration with Silobreaker. Silobreaker produces a reputation score for indicators of compromise (IOCs) based on a variety of open and commercial intelligence sources. Silobreaker users can now also access MDTI’s rich reputation scoring against IOCs, specifically IP addresses and domains, using Silobreaker’s 360 Search. MDTI’s reputation feature combines the power of its raw and finished threat intelligence, which tap into more than 65 trillion daily threat signals, machine learning algorithms, and over 8,500 cybersecurity researchers to calculate if an indicator is malicious or benign. If you’re a Silobreaker user and have an MDTI Premium and API subscription, you can begin taking advantage of this integration today. Read the full article here: MDTI Adds Microsoft Threat Intelligence to Silobreaker
Events
Learn more about Microsoft Entra Tenant Governance – a built-in solution that helps bring an organization’s tenants under control, reduce shadow-tenant risk, and manage tenant configuration at scale....
Online