microsoft 365 defender
598 TopicsAttack Simulation Training – Any update on Microsoft Teams phishing simulations (GA timeline)?
Hi everyone, We run Attack Simulation Training for several customers, and we're getting more and more questions about phishing simulations delivered through Microsoft Teams. As far as we know, this feature has been in private preview for quite a while now. In some tenants the Teams option is visible in the simulation wizard but greyed out. Does anyone have recent information on: General availability: is there a public preview or GA date, or a Microsoft 365 Roadmap ID we can follow? Access to the preview: is it still possible to join the private preview, and if so, how? Scope: which social engineering techniques will be supported in Teams (Credential Harvest, Link to Malware, etc.)? Will Teams payloads work with simulation automations and reporting the same way email does? Any feedback from people already in the preview, or any official update from the product team, would be much appreciated. Thanks in advance ! JulienProofpoint’s Core Email Protection API solution joins the Microsoft Defender ICES vendor ecosystem
Email remains the most exploited gateway for cyberattacks, as the threat landscape continues to get more sophisticated with attackers using AI to scale phishing, malware, and business email compromise. Microsoft Defender is a leading email security solution, helping organizations stay ahead of these threats with a modern, cloud-native approach. At the same time, many organizations choose to layer additional email security solutions to meet compliance requirements or align to an existing defense-in-depth strategy. This approach can strengthen resilience, but it can also add operational complexity for SOC teams. That’s why one year ago, we introduced the Microsoft Defender Integrated Cloud Email Security (ICES) vendor ecosystem, which is designed to simplify that complexity by integrating partner protections into Microsoft Defender. Today, we’re continuing to expand the ICES vendor ecosystem by adding Proofpoint Core Email Protection API. Proofpoint joins existing members Darktrace, KnowBe4, Cisco, and VIPRE Security Group. How joint customers benefit from a streamlined SOC experience in Microsoft Defender The ICES ecosystem brings trusted third-party email security verdicts and telemetry into the Defender portal through an API-based integration model. This allows Microsoft Defender to acknowledge partner verdicts on messages, apply the highest-severity determination, and surface that information in the same investigation and response workflows security teams already use. The integration with Proofpoint Core Email Protection API is designed specifically for customers who have already chosen to deploy Proofpoint’s ICES solution alongside Microsoft Defender. It supports environments where customers run both solutions and want to reduce friction for their SOC teams. By integrating Proofpoint into the ICES ecosystem, customers can now preserve their existing security strategy while improving how investigations and response are carried out day to day. "Organizations rely on both Microsoft and Proofpoint to protect their most critical communications and data. By extending Proofpoint’s interoperability across ICES, we’re delivering a more unified security experience that strengthens defense-in-depth and simplifies operations for our shared customers. This milestone reflects our commitment to joint customers worldwide.” - Tom Corn, EVP and GM, Threat Protection Group at Proofpoint Below we have outlined how Proofpoint’s ICES solution now integrates within Microsoft Defender: Unified quarantine: Quarantine is the central place where suspicious, unwanted, or malicious messages are held so they do not remain in users’ mailboxes while analysts review them. With unified quarantine, teams can view and manage quarantined email from both Defender and supported ICES vendors in one experience. The benefit is less context switching, faster triage, and a more consistent response workflow because analysts do not need to jump between separate admin consoles to understand what was held and why. In Figure 1, you can see that in the column “detection technology” ThirdPartyFiltering is listed, indicating to you that this was directly contributed by Proofpoint’s Core Email Protection API solution. Emails quarantined by Proofpoint Core Email Protection API show up in the quarantine experience in Defender, alongside Defender-quarantined emails. Streamlined operations: ICES integrations make Defender more actionable for SOC teams by extending familiar investigation experiences across Microsoft and partner-detected email. In Threat Explorer, analysts can review messages actioned by Defender and integrated partners in one place, making it easier to correlate verdicts and understand which layer acted on a message. 2 and 3: Shows how you can review emails actioned by Proofpoint by using ‘ThirdPartyFiltering’ in Threat Explorer. Click on a particular row and dive deeper into delivery and email details. In Advanced Hunting, teams can query email events that include third-party detections to investigate patterns, validate coverage, and hunt for missed or emerging threats. And on the Email entity page, analysts can see message-level details and action history, including which product took action and what verdict was assigned. Together, these experiences give teams a more complete investigation workflow without forcing them to jump between separate consoles. Reinforcing Our Commitment to Customer Choice The continued expansion of the ICES vendor ecosystem reinforces Microsoft’s commitment to supporting customers who strategically layer email security solutions. The goal of our ecosystem is making multiple solutions operationally effective together with Microsoft Defender as the shared Security Operations experience. By integrating partner signals directly into the Defender portal, customers can reduce analyst fatigue, improve consistency across email threat response, and scale their security posture while reducing the operational complexity of managing layered solutions. Learn more Get started by checking out the Defender for Office 365 ICES Vendor Ecosystem Integration Guide Read our blog: Ensure your ICES solution works seamlessly alongside Microsoft DefenderWhat happens when attackers get AI too?
Join Microsoft's live AMA on October 27, from 9:00–10:00 AM Pacific Time, to explore how AI could reshape cyberattacks—from reconnaissance and phishing to scripting and data analysis. Hear experts unpack realistic threats, practical limits, and the security controls that help keep organizations protected.239Views1like0CommentsSecuring AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365
Organizations are rapidly adopting AI agents to automate workflows, access enterprise data, invoke tools, and take actions on behalf of users. This autonomy creates a fundamentally new security challenge. Unlike traditional AI applications, agents operate across dynamic execution flows, interacting with external content, calling tools, and accessing sensitive resources. These interactions create new attack paths that traditional security controls were not designed to address. Today, we're announcing two major milestones for Security for AI in Microsoft Defender for Microsoft Agent 365: Threat detection for Microsoft Agent 365 agents — now in public preview. Real-time protection for Microsoft Agent 365 tooling servers — now generally available. Together, these capabilities help security teams detect, investigate, and block attacks targeting AI agents, extending Microsoft Defender's threat protection capabilities into the agent runtime. Threat detection for Microsoft Agent 365 Agents (Public Preview) Threat detection provides SOC teams with detailed visibility into attacks and suspicious activity targeting AI agents. By analyzing runtime signals across agent interactions, tool usage, and execution patterns, Microsoft Defender identifies suspicious and malicious behavior throughout the agent execution lifecycle and surfaces actionable security alerts for SOC teams. Threat detection supports cloud agent types that emit observability logs to Microsoft Agent 365, including: Microsoft Copilot Studio Microsoft Foundry Microsoft 365 Copilot Agent Builder Agents integrated through the Microsoft Agent 365 SDK This provides consistent threat visibility across supported Microsoft Agent 365 agent experiences, regardless of how the agent was built. Fig. 1. Microsoft Security for AI alerts in Microsoft Defender XDR (Preview) Microsoft Defender identifies a broad range of AI-specific threats, including: Indirect prompt injection (XPIA) — malicious instructions embedded in external content designed to manipulate agent behavior. Evasion techniques — attempts to bypass agent instructions or security controls. Malicious content propagation — attempts to use agents to generate or distribute malicious content. Secret leakage — exposure of credentials, API keys, or other sensitive information through agent interactions. LLM reconnaissance — attempts to probe agent capabilities, instructions, or security boundaries. Suspicious IP access — agent access originating from anonymized or suspicious IP addresses. Alerts are surfaced directly in Microsoft Defender, enabling SOC analysts to investigate and respond using familiar workflows, Advanced Hunting queries, and the Defender XDR investigation experience. Real-time protection for WorkIQ and Custom MCP servers (General Availability) Real-time protection moves beyond detection by blocking threats inline when AI agents interact with WorkIQ and custom MCP servers (see Microsoft Agent 365 tooling servers). When an agent invokes a registered tool or receives a tool response, Defender evaluates the interaction against configured security policies and determines whether to allow or block it directly within the agent's execution flow. This helps prevent malicious actions and data leakage in real time, without requiring agent developers to implement custom security logic. Fig. 2. Microsoft Security for AI Real-Time Protection policy in Defender Real-time protection currently guards against high-impact threats, including: Evasion techniques — attempts to bypass agent guardrails or security controls. Malicious content propagation — preventing agents from spreading malicious content through tool actions. Secret leakage — blocking agents from inadvertently exposing credentials or sensitive data through tool calls. Communication with untrusted domains — preventing agents from sending email or data to high-risk or untrusted email domains. Better Together: Detection and Protection Threat detection and real-time protection address complementary parts of the agent security lifecycle. Real-time protection provides inline enforcement to block malicious interactions during execution, while threat detection gives SOC teams the visibility and investigation context needed to identify attack patterns, assess impact, and respond to suspicious activity. Together, they provide a defense-in-depth approach that combines runtime enforcement with SOC-driven detection and investigation, purpose-built for AI agents. Getting Started Both capabilities are available through Microsoft Defender, using a dedicated Security for AI workload experience that brings together AI threat detections, investigations, and runtime protection policies. To learn more: Enable security for AI agents using Microsoft Defender Detect and investigate threats to AI agents using Microsoft Defender (Preview) Protect AI agents in real time using Microsoft Defender As AI agents become more autonomous and gain access to enterprise data and tools, securing their runtime behavior becomes critical. With Threat Detection and Real-Time Protection, Microsoft Defender helps organizations adopt AI agents with security controls designed for how agents actually operate—detecting attacks, enabling SOC investigation, and blocking malicious interactions at runtime.1.9KViews1like0CommentsWindows defender is having a lot of problems.
So I have a Microsoft 365 Family subscription, and Dark Web Monitoring shows 0 monitored items. SSN verification fails and advises you to contact support. I was also unable to delete the monitored information. I’m receive the error "Something went wrong, try again in a bit." The issue occurs in the Microsoft Defender app, web portal, and across devices. Is there anyway that I can get help with this?Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now
While going through the June Sentinel updates I almost scrolled past this one, and I think that would have been a mistake: custom detection rules can now be managed as code in Sentinel Repositories, the same way analytics rules, playbooks, parsers and workbooks already are. You connect a GitHub or Azure DevOps repo, enable the Custom Detection Rules content type, and rules are synced on every commit. There is also a standalone path via the Bicep CLI for teams running their own pipelines. The feature is in preview per the Learn documentation, and in my view it matters more than the low-key rollout suggests. Microsoft has been positioning custom detections as the unified experience for building rules over both Defender XDR and Sentinel data since late 2025. If custom detections are becoming the primary detection type, then this preview is the moment your primary detection type becomes pipeline-managed. I spent some time in the documentation to understand what that actually means, and there is one implication I have not seen anyone talk about yet. How it works Custom detection rules use a different mechanism than every other content type in Repositories. Analytics rules deploy as Microsoft.OperationalInsights/workspaces/providers/alertRules resources, with the Microsoft.SecurityInsights provider sitting in the resource name. Custom detection rules instead use a dedicated Bicep extension. You declare it in a `bicepconfig.json` at the repo root: { "extensions": { "MicrosoftSecurity": "br:mcr.microsoft.com/bicep/extensions/microsoftsecurity:v1.0.1" } } The rule itself is a `Microsoft.Security/detectionRules` resource. This is the structure from the Microsoft documentation: extension MicrosoftSecurity resource detectionRule 'Microsoft.Security/detectionRules@2026-06-01-preview' = { id: 'custom-rule-id' displayName: 'Custom Rule Display Name' status: 'enabled' queryCondition: { queryText: 'DeviceProcessEvents | take 10 | project DeviceId, Timestamp, FileName' } schedule: { frequency: 'PT1H' } detectionAction: { alertTemplate: { title: '<ruleTitle>' description: 'Custom detection rule' severity: 'medium' tactics: [ { tactic: 'Execution' techniques: [ { technique: 'T1059' } ] } ] entityMappings: { hosts: [ { id: 'h' deviceIdColumn: 'DeviceId' } ] } } } } Rules are uniquely identified by the `id` property, which you provide in the template. Deployment is either the automatic Repositories sync or a plain `az deployment group create` against a resource group. That last part is what I like most about the design: any CI/CD system that can run Azure CLI can ship these rules. Prerequisites beyond the standard Repositories setup: a Microsoft 365 E5 license or equivalent that includes Defender XDR, and a Sentinel workspace onboarded to the Defender portal. Two preview limitations are documented: custom frequency for Sentinel-only data is not supported yet, and neither are custom details. The part that made me stop reading and think Repositories are designed as the single source of truth. The documentation is explicit that content in your repo overwrites changes made through the portal. That is the whole point of the feature, and for analytics rules it has been mostly harmless. For custom detections I see a wrinkle. When Microsoft renames tables or columns in the advanced hunting schema, those naming changes are applied automatically to queries saved in Microsoft Defender, including the queries inside custom detection rules. The docs are equally explicit that this automatic migration does not cover queries run via API or saved anywhere outside Defender. A Git repo is outside Defender. Play that forward with a current example. The `AIAgentsInfo` table stopped being accessible on July 1, 2026, replaced by the unified `AgentsInfo` table with a changed column set. A portal-managed custom detection referencing the old table got migrated automatically. The same rule managed as code did not, because the authoritative copy of the query now lives in your repo, and nothing in the sync path rewrites your Bicep files. Your repo is now the thing standing between Microsoft's server-side fix and your production detection. Either the sync starts failing, or the stale query gets reasserted over the migrated rule. The documentation does not say which of the two happens, and honestly, neither is good. No alert fires for either. And if smart deployments, which skip files that have not changed since the last deployment, apply to this content type the same way they do to the rest of Repositories, it gets slightly worse in a way I find almost funny: a stale rule would sit untouched until someone happens to edit it. What I would put in front of the merge To be clear, none of this is an argument against the feature. I want detections in Git, and I suspect most people reading this do too. It is an argument that moving custom detections into a repo moves the schema lifecycle responsibility into your review process, because the portal safety net explicitly does not reach into source control. Concretely, a PR touching detection content should be checked for references to deprecated or transitioning advanced hunting tables, for the result columns the custom detection docs recommend (`Timestamp` or `TimeGenerated`, plus `DeviceId` or `DeviceName` for Defender for Endpoint tables, plus `Timestamp` and `ReportId` from the same event for the other Defender tables), and for complete entity mappings, since entities drive how alerts group into incidents. One more detail from the custom detection docs that I suspect will trip up people coming from analytics rules, because it goes against years of muscle memory: avoid filtering on `Timestamp` or `TimeGenerated` in the query itself. The service prefilters data based on the detection lookback using ingestion time. The scheduled-analytics-rule reflex of always pinning a time window works against you here. Whether you enforce these checks with a homegrown script or a linting step in the pipeline matters less than doing it before merge rather than discovering it in the alert queue. The deployment mechanics are now solved. The content governance is yours. Full transparency: I have worked through the documentation and the sample content, but I have not yet run a retired-table scenario through the sync myself. So if you are testing the preview, I would genuinely like to hear how it behaves in your environment when a repo-managed rule references a table like `AIAgentsInfo`. That failure mode is the one I want to understand before this reaches GA. Beyond that specific case, I am curious where you all stand: are you moving custom detections into Git now, or waiting for GA? And if you already run detections as code for analytics rules, what checks have earned a permanent place in your PR pipeline? My used references: Manage content as code with Microsoft Sentinel repositories: https://learn.microsoft.com/en-us/azure/sentinel/ci-cd-custom-content Advanced hunting schema naming changes: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes Create custom detection rules in Microsoft Defender XDR: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules Custom detections as the unified detection experience: https://techcommunity.microsoft.com/t5/microsoft-defender-threat-protection/custom-detections-are-now-the-unified-experience-for-creating/ba-p/4463875SolvedMicrosoft Defender for Office 365 Plan 1 is now rolling out to Microsoft 365 E3 and Office 365 E3
Starting today, Microsoft Defender for Office 365 Plan 1 is rolling out to customers with Microsoft 365 E3/G3 and Office 365 E3/G3 licenses, with rollout expected to complete by Fall 2026. For security teams, this means added protection against phishing, malware, and malicious links across email and collaboration, without needing to purchase or deploy a separate email security solution. It also means some protections will turn on automatically, so now is the right time to review your configuration and prepare for any changes to mail flow, policies, and end-user experience. What E3 customers are getting Previously, these subscriptions included built-in security to help filter spam and known malware. Defender for Office 365 Plan 1 builds on that foundation with additional protections designed to catch more sophisticated phishing attempts, malicious links, and zero-day threats, while giving your team better visibility into what is happening in your environment. Safe Links: Helps protect users with time-of-click protection by checking URLs and blocking malicious destinations, including QR code-based attacks. Safe Attachments: Helps stop unknown and zero-day malware before harmful files reach users. Advanced anti-phishing: Helps detect impersonation attacks that target your users, executives, and trusted domains. Expanded visibility and reporting: Gives security teams more actionable detections, alerts, and reporting in the Microsoft Defender portal. What changes automatically As the plan rolls out, protection will turn on automatically for licensed users. That is good news from a security perspective, but it is still important to understand what is changing in your environment. New protections can affect how messages are processed, how suspicious links are handled, what users see when they click blocked content, and how your team monitors and tunes policy settings after rollout. Read more about it here: https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies#use-the-microsoft-defender-portal-to-add-exclusions-to-the-built-in-protection-preset-security-policy. How to prepare for the rollout Review your current mail flow and security configuration. If you know how mail is routed today and which protections are already in place, it will be easier to spot what changes once Defender for Office 365 Plan 1 is active. Decide how you want to manage policies. When the plan becomes available in your tenant, built-in protection is applied automatically for licensed users. If you want Microsoft recommended settings beyond that baseline, consider enabling the Standard or Strict preset security policies. Prepare your help desk and users. Users may start seeing warning or block experiences when Safe Links identifies a malicious destination. A simple heads-up can reduce confusion and support tickets. For more details and how to customize user notification, see Set up Safe Links policies. Plan for exceptions and tuning. If you have specific users, domains, or workflows that need exclusions, review those requirements early so your team is ready to adjust policies after rollout. Monitor what changes. Use the Microsoft Defender portal and Microsoft Secure Score to track new detections, review improvement actions, and prioritize follow-up configuration work. If you use a third-party secure email gateway If your organization routes email through a third-party secure email gateway such as Proofpoint, Mimecast, or Barracuda before it reaches Microsoft 365, you should review your configuration now. In many environments, it is recommended to configure Enhanced Filtering for Connectors, preserve original sender details in Exchange Online, and decide which service will handle link rewriting to avoid unnecessary overlap. If you are evaluating a broader consolidation of your email security stack, our guides on defense in depth and migration to Defender for Office 365 can help. Protection also extends to Microsoft Teams The plan also extends protection to Microsoft Teams chats and channels. That includes protection for shared links and files, post-delivery removal of malicious content, admin controls to manage enforcement, and user reporting to help your security team investigate suspicious messages faster. For practitioners, this adds another layer of coverage across the collaboration tools users rely on every day. Learn more For implementation guidance, visit the Microsoft Defender for Office 365 security documentation, review the step-by-step guides, and use the preset policy, defense in depth, migration, and connector configuration resources linked above to plan your rollout.Microsoft 365 Developer E5 license lacking endpoints and device ON defender portal
Dear Support Team, I am a microsoft certified trainer (MCT). I currently have a Microsoft 365 Developer E5 license assigned to my tenant. However, I have noticed that my Microsoft Defender portal (security.microsoft.com) is missing several critical features. For example, I cannot see the Endpoints or Devices menus, which is preventing me from implementing and testing Microsoft Defender for Endpoint. Additionally, my Azure tenant and Microsoft 365 tenant are separate. This has created challenges when configuring security services such as Microsoft Sentinel (SIEM), as certain prerequisites and integrations require configuration through the Microsoft Defender portal. Due to the missing Defender features, I am unable to complete the necessary setup. I would appreciate your assistance in understanding: Why the Endpoints and Devices sections are unavailable in my Defender portal despite having a Microsoft 365 Developer E5 license. Whether additional licensing, onboarding steps, or tenant configurations are required to enable Microsoft Defender for Endpoint features. How best to integrate or align my separate Azure and Microsoft 365 tenants to support services such as Microsoft Sentinel and Defender XDR. These issues are significantly impacting my ability to evaluate and implement Microsoft's security solutions. I would appreciate any guidance or recommendations to resolve them.724Views1like2CommentsNo way to automate restoring user‑reported emails after “no threats found”
When a user reports an email as phishing in Defender, the message gets moved to Deleted Items. After we triage it, if we mark it as “no threats found,” there’s no way to push it back to the user’s inbox as part of that workflow. That creates a bit of a broken experience: User is told the email is safe with our customized email response, but has to go find it themselves In a lot of cases they don’t (Outlook search won’t find it) We end up with follow‑ups like “where did it go?” Technically we could restore the email as part of our triage process, but that just shifts the effort onto the SOC. It doesn’t scale, and it’s not really the right place for that work. We have tried to create an automation to do this, but we have not been able to create an advanced hunting query based on our triage result that can then trigger an action to restore it to the mailbox. So we end up choosing between: Users having a bad experience, or Analysts doing manual mailbox work Neither is ideal. Other platforms (like Proofpoint) handle this end‑to‑end — once something is confirmed clean, it can be returned to the user automatically. Right now Defender stops at classification instead of completing the workflow. Is there a reason this isn’t wired in, or anything on the roadmap to address it?