Help me understand why this email was quarantined?
I'm pretty familiar with Defender's Threat Policies. I've probably set them up on 40 tenants. I know the Hosted Content Filter Policy is backend for Anti Spam Inbound policy. I know that, confusingly, the AntiSpam Inbound Policies contain the actions for High Confidence/Normal Confidence Phishing - NOT the AntiPhishing policies (which seem more geared towards impersonation). What I DON'T know is why this was quarantined - and whether the anti-phish policy had anything to do with it. The Policy Type linked is the IB Anti Spam. This tenant is one of the few we have set at a BCL tolerance level of 7 - which shows me that 0 messages in the last 60 days would've been caught for this reason (which would include the email in question). So it was either the SCL or some 'anti phish' component of the anti-spam policy. I have none of the custom 'increase spam score' markers here. I was sure there was a 'evidence' tab within email entity, but i guess not - the only info I have about the detection (now released) is the following: This particular sender does not send reliably over 45 days, but also has been a business partner of this tenant for decades. So rather than the Tenant Allow/Block list which allows a max of 45 days, I want to add it to the offending policy. which SEEMS like it would be the inbound anti-spam - except that it also says it's phishing everywhere. I don't want to bypass both the phishing and spam policies unless I have to - but I don't really know why this got blocked. It's an external address that had sent an email days ago that got through without issue... This one has an attached pdf, but so do they all. Thoughts?Protect your organizations against QR code phishing with Defender for Office 365
QR code phishing campaigns have most recently become the fastest growing type of email-based attack. These types of attacks are growing and embed QR code images linked to malicious content directly into the email body, to evade detection. They often entice unwitting users with seemingly genuine prompts, like a password reset or a two-factor authentication request. Microsoft Defender for Office 365 is continuously adapting as threat actors evolve their methodologies. In this blog post we’ll share more details on how we’re helping defenders address this threat and keeping end-users safe.
user-reported phishing emails
Dear Community I have a technical question regarding user-reported emails. In Defender, under “Action and Submissions” -> “Submissions,” I can see the emails that users have reported under the “user reported” option. There, we have the option to analyze these emails and mark them as “no threats found,” “phishing,” or “spam.” The user is then informed. Question: Do these reported emails remain in the user's inbox when they report them? If not, do we have the option to return these reported emails to the user's inbox with the “No threats found” action? Because I don't see this option. In another tenant, under “Choose response Action,” I see “move or delete,” but the “inbox” option is grayed out. Why is that? Thank you very much!'system has learned from the submission / mail is automatically allowed'
Hey folks, got an alert about a tenant allow//block list entry expiring. Only recently did we start getting these, because only recently did we start using expiring whitelisting. But I'm a little confused by the details, which says 'Mail from x is now automatically alllowed and the allow entry has been removed' and the activity that ''an allow entry is no longer required as the system has learned from the submission' The referenced email is actually an internal tenant - it receives ticket requests, and sends out ticket updates. But I'm REALLY curious about the 'automatic' allowing. Is this a feature limited to Defender 2, or part of Microsoft's AI detection framework for all 365 Defender/EOP? I don't even remember submitting this email - if I did, it was probably more than 45 days ago. So 1) Is this notice primarily that the entry had expired, but ALSO it's not needed or does this send out as soon as 'the system' recognizes it as legitimate, and removed regardless of the time left? 2) is there a way to review a list of entries Microsoft has 'accepted'? 3) What exactly does this 'allow'? I know that the tenant allow/block list allowed a certain set of lower-risk indicators in an email, but still blocked some higher-risk ones - unless there was a submission made. At that point, more is allowed. But there's still a limit, compared to a blanket bypass on the policy itself.
Incident Missing Entities
Good morning! I would like to have some clarification on how entities work. Yesterday I found out that if I have 2 entities of the same type (In this particular case, two entities of the type Account), with the same identifier (originally, both share the identifier 'Name'), Sentinel appears to throw away one of them, or both in some instances, and when the alert generates an incident, the entities defined won't appear. I have switched out the identifier on both account types to something different, but until an incident gets triggered, I can't confirm if this will fix the original issue. So my questions are An analytic rule can or can't have two entities of the same type defined? If yes, that means that they need to have different identifiers. Is this a correct asumption? Some identifiers expect a certain type of value to be assigned, that means that eventually, I can ran out of identifiers for my entities or face the added complexity of dealing with types when returning values from my KQL query What could happen if I map an identifier to something that matches the type but not what that identifier represents? in this case, for Account, we have the identifier ObjectGuid. If I assign a value type string to it, that is not a guid, wouldn't that mess up something else in the background? Example, incident grouping If I move instead to use Sentinel Entities, which appear to be the 'general' option, I could only use one, since I only have 'entity' as available identifier, looping back to the problem of can have only one type of identifier for identity type. Thanks in advanceIntroducing the Microsoft Defender for Office 365 ICES vendor ecosystem
In today's digital landscape, the need for comprehensive security measures is more critical than ever, as email continues to be a primary vector for cyberattacks such as phishing and malware. To address this, Microsoft Defender for Office 365 leverages the extensive scale of Microsoft's threat intelligence, which processes trillions of signals daily. By integrating Large Language Models (LLMs) and advanced Natural Language Processing, Defender for Office 365 empowers organizations with AI-driven threat detection, behavioral analytics, and automated responses thus proactively identifying and neutralizing risks before they reach end users. This collaborative defense approach reinforces the principle that security is a team sport, requiring shared intelligence and coordinated action across the ecosystem. We recognize in today’s dynamic cyber threat landscape, defense-in-depth strategy has become a vital approach not only for Microsoft customers but also across the broader Secure Email Gateway (SEG) market. Organizations are increasingly adopting layered security solutions to comply with regulatory requirements, enhanced detection, and ensure robust protection. To address this, we’re announcing the Microsoft Defender for Office 365 ICES Vendor Ecosystem — a unified framework that enables seamless integration with trusted third-party vendors. This ecosystem is designed to eliminate integration friction and deliver: Broader detection coverage through vendor diversity Transparency across Microsoft Defender for Office 365 and partner detections Streamlined SOC workflows through consistent policy enforcement and shared investigation tools Stronger compliance alignment with layered security mandates This partner ecosystem is about creating a cohesive defense fabric that enhances SOC efficiency with Microsoft Defender for Office 365 as the foundation. The ecosystem also provides flexibility, scalability, and preparedness for the complexities of contemporary enterprise security. With this in mind, we are pleased to announce that our trusted ICES security vendors, Darktrace and KnowBe4, have become the first launch partners within our ecosystem. They offer customers a seamless and collaborative defense framework where each solution enhances the strengths of the others. We welcome additional partners soon as we continue to expand this integrated ecosystem. “Our integration with Microsoft gives security teams the tools they need to act faster and more precisely to detect and respond to threats,” said Jill Popelka, CEO of Darktrace. “Together, we’re strengthening defenses where it matters most to our customers —at the inbox.” “I’m incredibly excited at the opportunity afforded by this partnership with Microsoft and the deeper integrations it enables. Leveraging this integration allows us to use our vast quorum of data around email security and human risk in a way that provides the most comprehensive layered security approach available to the market. A complementary defense strategy is mandatory and this integration with Microsoft M365 furthers that vision by combining our capabilities to create comprehensive defense strategies that address the full spectrum of modern cyber threats.” noted Greg Kras, Chief Product Officer @ KnowBe4 Unified Quarantine The core strength of this new ecosystem is the seamless integration between Defender for Office 365 and its ICES partners, through the Unified Quarantine feature. Managing quarantined messages from multiple solutions can often be complex and inefficient. Unified Quarantine streamlines the process by consolidating quarantined items identified by both Defender for Office 365 and third-party (3P) solutions into a single, unified interface, enhancing customer ease and visibility. Administrators can efficiently review, release, or remediate messages through this unified interface, irrespective of the provider that identified the threat. This approach not only optimizes time management but also guarantees uniform policy enforcement and facilitates transparency on detections, resulting in improved operational efficiency and a more coherent user experience. As part of the Unified Quarantine, security admins can also see which provider quarantined the message. Transparency and Insight Across Solutions In environments with multiple email security solutions, transparency is crucial to understanding each vendor's detections. Microsoft Defender for Office 365 offers a unified dashboard that clearly distinguishes between threats stopped by Defender and those identified by third-party solutions, ensuring transparent and fair attribution of protection value. This dashboard provides security teams with a comprehensive view of how each solution contributes to protection, helping to identify overlapping coverage and areas of unique value. This clarity supports more informed decision-making around threat trends, policy optimization, and vendor strategy fostering stronger collaboration between internal teams and external partners. Deeper SOC Investigation Capabilities: Threat Explorer, Advanced Hunting, and Email Entity Page Modern defenders need tools for rapid investigation, root cause analysis, and tactical response. The Defender for Office 365 ecosystem unifies investigative workflows across partner solutions. Within Threat Explorer, security analysts can seamlessly pivot between messages actioned by Microsoft Defender for Office 365 and those flagged by integrated partners. The side-by-side display of verdicts and actions enables quick correlation and pattern recognition. Advanced Hunting brings even greater depth, allowing analysts to craft queries that span both Microsoft Defender for Office 365S and 3P data sources. This holistic view accelerates threat hunting and helps organizations surface novel attack techniques or gaps in coverage. EmailEvents | where Timestamp > ago(7d) //List emails caught by a Third-party solution | where DetectionMethods contains "Thirdparty" | project NetworkMessageId, RecipientEmailAddress, ThreatTypes, DetectionMethods, AdditionalFields, LatestDeliveryLocation On the Email Entity Page, every message surfaces a complete action history, including which product took action and what verdict was assigned. This granular visibility demystifies complex incidents and builds confidence in the layered defense model. Summary As the threat landscape continues to evolve, so must our defenses. While organizations embrace defense-in-depth, fragmented integrations may lead to unintended consequences such as diminished detection capabilities, overlapping controls, and SOC inefficiencies. With the Defender for Office 365 ICES vendor ecosystem, Microsoft is setting a new standard for collaborative, integrated security platforms. By combining proven protection, seamless partnerships, and unified visibility, organizations can embrace defense-in-depth without complexity or compromise. Whether combating phishing, malware, or the next generation of email-borne threats, customers benefit from a defense-in-depth strategy built for agility and efficiency. With hands-off enablement, unified experiences, and unmatched transparency, the Defender for Office 365 ecosystem empowers every organization to stay one step ahead—today and tomorrow. Learn More To learn more about the Microsoft Defender for Office 365 ICES Vendor Ecosystem, please visit https://learn.microsoft.com/defender-office-365/mdo-ices-vendor-ecosystem.
User Profile Deletion
Hi, I just wanted to pick anyone's brains, in case they have also encountered this or would have any idea why this is the case. I am fairly new to Intune and script writing, to clarify. Basically, we have been working on a Detect and Remediation script that is deployed via Intune (Devices >Ssni Script and Remediations) to Windows 10 (Ent 22H2) and Windows 11 (Ent 24H2) devices. On any fresh enrolled devices, it detects and deletes user profiles completely fine, but fails to even detect profiles on devices that were enrolled a while ago. However, if we run an Autopilot reset on those devices, the script works again. What difference would a freshly built/enrolled device have to an older one, when they also run other scripts fine. The script targets profiles that are older than 1 hour as we want to keep on top of removing profiles consistently to keep disk space low, especially on lower spec laptops. It will exclude SYSTEM profiles and also any *Admin* user folders - as that has a separate script to only delete LAPSAdmin on an evening, when the workplace is closed (8pm UK). This LAPSAdmin script worked fine on the older enrolled devices. Some of the profiles on the machines go back to 2023, is the '1 hour' target not effective against that old of a profile - has it become stale?SS Like I said, I am fairly new to this and have used bits and pieces from different locations to help muster up a script. I thought I had it nailed as it was working on test devices that were just enrolled purely for testing, until I was asked to put it onto another group. Intune doesn't say the script fails - indicating there are no errors. However, I am not saying there isn't. Detect: Remediate: Thanks for your time, Dean
