Protection Against Email Bombs with Microsoft Defender for Office 365
In today's digital age, email remains a critical communication tool for businesses and individuals. However, with the increasing sophistication of cyberattacks, email security has become more important than ever. One such threat that has been growing is the email bombing, a form of net abuse that sends large volumes of email to an address to overflow the mailbox, overwhelm the server, or distract attention from important email messages indicating a security breach. Email bomb - Wikipedia Understanding Email Bombing Email bombing, typically involves subscribing victims to a large number of legitimate newsletter and subscription services. Each subscription service sends email notifications, which in aggregate create a large stream of emails into the victim’s inbox, making email triage for legitimate emails very difficult. This form of attack is essentially a denial-of-service (DDOS) on the victim's email triaging attention budget. Hybrid Attacks More recently, email subscription bombs have been coupled with simultaneous lures on Microsoft Teams, Zoom, or via phone calls. Attackers impersonate IT support and offer to help solve the email problem caused by the spike of unwanted emails, ultimately compromising the victim's system or installing malware on their system. This type of attack is brilliant because it creates a sense of urgency and legitimacy, making victims more likely to accept remote assistance and inadvertently allow malware planting or data theft. Read about the use of mail bombs where threat actors misused Quick Assist in social engineering attacks leading to ransomware | Microsoft Security Blog. Incidence and Purpose of Email Bombing Email bombing attacks have been around for many years but can have significant impacts on targeted individuals, such as enterprise executives, HR or finance representatives. These attacks are often used as precursors to more serious security incidents, including malware planting, ransomware, and data exfiltration. They can also mute important security alerts, making it easier for attackers to carry out fraudulent activities without detection. New Detection technology for Mail Bombing attacks To address the limitations of current defenses which often include the victim’s attempt to build their own mail flow rules, Microsoft Defender for Office 365 releases a comprehensive solution involving a durable block to limit the influx of emails, majority of which are often Spam. By intelligently tracking message volumes across different sources and time intervals, this new detection leverages historical patterns of the sender and signals related to spam content. It prevents mail bombs from being dropped into the user’s inbox and the messages are rather sent to the Junk folder (of Outlook). Note: Safe sender lists in Outlook continue to be honored, so emails from trustworthy sources are not unexpectedly moved to the Junk folder (in order to prevent false positives). Since the initial rollout that started in early May, we’ve seen a tremendous impact in blocking mail bombing attacks out of our customers’ inboxes: How to leverage new “Mail bombing” detection technology in SOC experiences 1. Investigation and hunting: SOC analysts can now view the new Detection technology as Mail bombing within the following surfaces: Threat Explorer, Email entity page and Advanced Hunting empowering them to investigate, filter and hunt for threats related to mail bombing. 2. Custom detection rule: To analyze the frequency and volume of attacks from mail bombing vector, or to have automated alerts configured to notify SOC user whenever there is a mail bombing attack, SOC analysts can utilize the custom detection rules in Advanced hunting by writing a KQL query using data in DetectionMethods column of EmailEvents table. Here’s a sample query to get you started: EmailEvents | where Timestamp > ago(1d) | where DetectionMethods contains "Mail bombing" | project Timestamp, NetworkMessageId, SenderFromAddress, Subject, ReportId The SOC experiences are rolled out worldwide to all customers. Conclusion Email bombs represent an incidental threat in the world of cybersecurity. With the new detection technology for Mail Bombing, Microsoft Defender for Office 365 protects users from these attacks and empowers Security Operations Center Analysts to ensure to gain visibility into such attacks and take quick actions to keep organizations safe! Note: The Mail bombing protection is available by default in Exchange Online Protection and Microsoft Defender for Office 365 plans. This blog post is associated with Message Center post MC1096885. Also read Part 2 of our blog series to learn more about protection against multi-modal attacks involving mail bombing and correlation of Microsoft Teams activity in Defender. Learn: Detection technology details table What's on the Email entity page Filterable properties in the All email view in Threat Explorer
Question malware autodelete
A malware like Trojan:Win32/Wacatac.C!ml can download other malware, this other malware can perform the malicious action, this malware can delete itself and in the next scan of antivirus free this malware that deleted itself will not have any trace and will not be detected by the scan?
Defender for Endpoint | Deception
Hi Everyone, I hope this topic is going to help someone. I want to know after 31 of October 2025 Does that mean that no one can run Deceptions and policy rules, etc? As at the moment I'm experiencing this: It would be good to know if I have to deal with it and look into what the issue is, as I'm using Zscaler. The issue is definitely there after running a number of commands to check the reg key, etc. Can someone provide me with any documentation if this will be fully retired or will still be functioning to some point?Microsoft Defender for Office 365: Migration & Onboarding
This blog covers four key areas that are frequently missed, but they are essential for a secure and auditable deployment of Defender for Office 365. Before diving into the technical details, it is important to clarify a common misconception about Defender for Office 365 protections. Blocking Malicious File Downloads in SharePoint and OneDrive A common assumption during onboarding is that Microsoft Defender for Office 365 protections only apply to email. In reality, Safe Attachments also integrates with SharePoint Online, OneDrive for Business and Microsoft Teams. It scans files for malware even after they are uploaded or shared internally. However, this protection is only effective when the configuration explicitly prevents users from downloading files flagged as malicious. Without this setting, files detected as threats can still be downloaded locally. This creates a major risk particularly if the malware is detected post-delivery. In one investigation, I found that this setting had been left at its default, allowing users to download malicious files from SharePoint. This oversight created a significant exposure risk until it was corrected. This setting is part of the Safe Attachments for SPO/ODB policy and is critical in reducing internal exposure. Once enabled, this setting protects users in real time and acts as a powerful audit point. If someone disables this setting, whether intentionally or by accident, that action is recorded in Purview's Unified Audit Log under the DisallowInfectedFileDownloadDisabled operation. The video below offers a brief walkthrough on how to enable the setting, details the associated audit log events, and provides guidance on configuring alerts for any modifications: Regularly auditing for this event can help identify misconfiguration or potentially malicious administrative activity that could indicate insider threat behaviour. Including this check as part of your continuous security monitoring process is a smart, proactive move. Learn more at Step 2: (Recommended) Use SharePoint Online PowerShell to prevent users from downloading malicious files Once you have established protection against malicious files, the next step is ensuring your tenant is correctly set up to create and manage threat policies. Ensuring Organization Customization is Enabled A frustrating yet common hurdle during Defender for Office 365 onboarding is the inability to create threat policies such as anti-phishing or Safe Attachments policies. This confusion often stems from a basic configuration oversight: the tenant has not been enabled for organization customization. Without this step, the Microsoft 365 platform prevents the creation or editing of many critical security policies in Defender for Office 365. A few years prior with a new client being onboarded to Defender for Office 365, I encountered a situation where policy creation kept failing because this step wasn’t followed. It caused unnecessary delays and frustrated the security team until we identified the missing customization. The fix is simple. Run the Enable-OrganizationCustomization PowerShell cmdlet from Exchange Online. It is a one-time configuration task, but it is essential for policy management and overall service functionality. Including this step early in your deployment or migration plan prevents unnecessary delays and ensures the security team can fully leverage Defender for Office 365's capabilities from day one. This is particularly important for consultants who are brought in to assist after issues have already arisen. Getting ahead of this configuration means one less troubleshooting rabbit hole. With customization enabled, you can now take advantage of the preset security policies to quickly build a solid baseline. Using Preset Security Policies for a Strong Starting Point One of the best tools Microsoft has provided for onboarding is the Preset Security Policies feature. These come in two flavors: Standard and Strict. Figure 4 - Defender for Office 365 Preset security policies (Standard & Strict protection) They represent Microsoft’s recommended baseline configurations for anti-malware, anti-phishing, and spam protection. Learn more at Preset security policies in cloud organizations. For customers with limited security maturity or time to deeply understand the inner workings of Defender for Office 365, these presets are a game-changer. Figure 5 - Microsoft recommendation is to apply standard protection to all users In several cases, I have seen organizations with limited security teams benefit from activating these presets early. This approach gave them immediate protection while freeing up time to better understand and tune policies over time. For incident response, having a consistent and known-good baseline also helps reduce noise and false positives in the initial stages of deployment. Figure 6 - Apply strict Defender for Office 365 protection for priority users After setting foundational policies, controlling who has access to what within Defender for Office 365 is crucial to maintaining a secure environment. Implementing Unified RBAC for Least Privilege Access As more business units engage with Defender for Office 365 for everything from investigation to reporting, it is important to ensure each role has access only to what they need. Unified Role-Based Access Control (RBAC) in Defender for Office 365 makes this possible by allowing granular control over who can see and change what within the security portal. Figure 7 – Example least privilege role configuration for a Defender for Office 365 Incident Responder (image trimmed). This becomes critically valuable in larger or more complex organizations where responsibilities are split between security, compliance, IT, and operations teams. Figure 8 - Activating Microsoft Defender for Office 365 Workload in Defender XDR Roles. By using unified RBAC, you can avoid the dangerous and often default behavior of assigning Security Administrator rights to everyone involved. Instead, define roles based on function. For example, Tier 1 analysts might only need view and investigation access, while admins can manage policies. Figure 9 - Assigning a user to a Custom Microsoft Defender for Office 365 role, Entra Security Groups are also supported. This approach aligns with zero trust principles and makes it easier to audit who has access to sensitive areas. During onboarding, I recommend mapping stakeholders to the available roles and applying this model as early as possible. This helps establish accountability and improves your security posture before an incident occurs. Learn more at Map Defender for Office 365 permissions to the Microsoft Defender XDR Unified RBAC permissions Having set the right roles and permissions, it is vital to understand how these configurations contribute to a resilient and well-prepared security posture. Final Thoughts Successful onboarding to Microsoft Defender for Office 365 is not just about flipping switches. It is about making intentional configuration choices that support operational efficiency and long-term security goals. The points covered here are often missed in quick start guides but they are essential for building a solid foundation. Those who invest time in proper configuration are far better prepared when incidents arise. Migration is just the beginning. Set up Defender for Office 365 right to reduce risk and build real resilience. Please take two minutes to take this survey to let us know what you think of this blog (series), video, and community content. Questions or comments on this blog "Microsoft Defender for Office 365 Migration & Onboarding" for the author or other readers? Please log in and post your response below! _____________ This blog has been generously and expertly authored by Microsoft Security MVP, Purav Desai. with support of the Microsoft Defender for Office 365 product team. Lead M365 Incident Responder, Financial Services | Dual Microsoft Security MVP Log in and follow this Microsoft Defender for Office 365 blog and follow/post in the Microsoft Defender for Office discussion space. Follow = Click the heart in the upper right when you're logged in 🤍 Learn more about the Microsoft MVP Program. Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more. Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Customer Connection Community. Join the Microsoft Security Community LinkedInMicrosoft Sentinel’s AI-driven UEBA ushers in the next era of behavioral analytics
Co-author - Ashwin Patil Security teams today face an overwhelming challenge: every data point is now a potential security signal and SOCs are drowning in complex logs, trying to find the needle in the haystack. Microsoft Sentinel User and Entity Behavior Analytics (UEBA) brings the power of AI to automatically surface anomalous behaviors, helping analysts cut through the noise, save time, and focus on what truly matters. Microsoft Sentinel UEBA has already helped SOCs uncover insider threats, detect compromised accounts, and reveal subtle attack signals that traditional rule-based methods often miss. These capabilities were previously powered by a core set of high-value data sources - such as sign-in activity, audit logs, and identity signals - that consistently delivered rich context and accurate detections. Today, we’re excited to announce a major expansion: Sentinel UEBA now supports six new data sources including Microsoft first- and third-party platforms like Azure, AWS, GCP, and Okta, bringing deeper visibility, broader context, and more powerful anomaly detection tailored to your environment. This isn’t just about ingesting more logs. It’s about transforming how SOCs understand behavior, detect threats, and prioritize response. With this evolution, analysts gain a unified, cross-platform view of user and entity behavior, enabling them to correlate signals, uncover hidden risks, and act faster with greater confidence. Newly supported data sources are built for real-world security use cases: Authentication activities MDE DeviceLogonEvents – Ideal for spotting lateral movement and unusual access. AADManagedIdentitySignInLogs – Critical for spotting stealthy abuse of non - human identities. AADServicePrincipalSignInLogs - Identifying anomalies in service principal usage such as token theft or over - privileged automation. Cloud platforms & identity management AWS CloudTrail Login Events - Surfaces risky AWS account activity based on AWS CloudTrail ConsoleLogin events and logon related attributes. GCP Audit Logs - Failed IAM Access, Captures denied access attempts indicating reconnaissance, brute force, or privilege misuse in GCP. Okta MFA & Auth Security Change Events – Flags MFA challenges, resets, and policy modifications that may reveal MFA fatigue, session hijacking, or policy tampering. Currently supports the Okta_CL table (unified Okta connector support coming soon). These sources feed directly into UEBA’s entity profiles and baselines - enriching users, devices, and service identities with behavioral context and anomalies that would otherwise be fragmented across platforms. This will complement our existing supported log sources - monitoring Entra ID sign-in logs, Azure Activity logs and Windows Security Events. Due to the unified schema available across data sources, UEBA enables feature-rich investigation and the capability to correlate across data sources, cross platform identities or devices insights, anomalies, and more. AI-powered UEBA that understands your environment Microsoft Sentinel UEBA goes beyond simple log collection - it continuously learns from your environment. By applying AI models trained on your organization’s behavioral data, UEBA builds dynamic baselines and peer groups, enabling it to spot truly anomalous activity. UBEA builds baselines from 10 days (for uncommon activities) to 6 months, both for the user and their dynamically calculated peers. Then, insights are surfaced on the activities and logs - such as an uncommon activity or first-time activity - not only for the user but among peers. Those insights are used by an advanced AI model to identify high confidence anomalies. So, if a user signs in for the first time from an uncommon location, a common pattern in the environment due to reliance on global vendors, for example, then this will not be identified as an anomaly, keeping the noise down. However, in a tightly controlled environment, this same behavior can be an indication of an attack and will surface in the Anomalies table. Including those signals in custom detections can help affect the severity of an alert. So, while logic is maintained, the SOC is focused on the right priorities. How to use UEBA for maximum impact Security teams can leverage UEBA in several key ways. All the examples below leverage UEBA’s dynamic behavioral baselines looking back up to 6 months. Teams can also leverage the hunting queries from the "UEBA essentials" solution in Microsoft Sentinel's Content Hub. Behavior Analytics: Detect unusual logon times, MFA fatigue, or service principal misuse across hybrid environments. Get visibility into geo-location of events and Threat Intelligence insights. Here’s an example of how you can easily discover Accounts authenticating without MFA and from uncommonly connected countries using UEBA behaviorAnalytics table: BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.IsMfaUsed == "No" | where ActivityInsights.CountryUncommonlyConnectedFromInTenant == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn Anomaly detection Identify lateral movement, dormant account reactivation, or brute-force attempts, even when they span cloud platforms. Below are examples of how to discover UEBA Anomalous AwsCloudTrail anomalies via various UEBA activity insights or device insights attributes: Anomalies | where AnomalyTemplateName in ( "UEBA Anomalous Logon in AwsCloudTrail", // AWS ClousTrail anomalies "UEBA Anomalous MFA Failures in Okta_CL", "UEBA Anomalous Activity in Okta_CL", // Okta Anomalies "UEBA Anomalous Activity in GCP Audit Logs", // GCP Failed IAM access anomalies "UEBA Anomalous Authentication" // For Authentication related anomalies ) | project TimeGenerated, _WorkspaceId, AnomalyTemplateName, AnomalyScore, Description, AnomalyDetails, ActivityInsights, DeviceInsights, UserInsights, Tactics, Techniques Alert optimization Use UEBA signals to dynamically adjust alert severity in custom detections—turning noisy alerts into high-fidelity detections. The example below shows all the users with anomalous sign in patterns based on UEBA. Joining the results with any of the AWS alerts with same AWS identity will increase fidelity. BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.FirstTimeConnectionViaISPInTenant == True or ActivityInsights.FirstTimeUserConnectedFromCountry == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn, ActivityInsights | evaluate bag_unpack(ActivityInsights) Another example shows anomalous key vault access from service principal with uncommon source country location. Joining this activity with other alerts from the same service principle increases fidelity of the alerts. You can also join the anomaly UEBA Anomalous Authentication with other alerts from the same identity to bring the full power of UEBA into your detections. BehaviorAnalytics | where TimeGenerated > ago(1d) | where EventSource == "Authentication" and SourceSystem == "AAD" | evaluate bag_unpack(ActivityInsights) | where LogonMethod == "Service Principal" and Resource == "Azure Key Vault" | where ActionUncommonlyPerformedByUser == "True" and CountryUncommonlyConnectedFromByUser == "True" | where InvestigationPriority > 0 Final thoughts This release marks a new chapter for Sentinel UEBA—bringing together AI, behavioral analytics, and cross-cloud and identity management visibility to help defenders stay ahead of threats. If you haven’t explored UEBA yet, now’s the time. Enable it in your workspace settings and don’t forget to enable anomalies as well (in Anomalies settings). And if you’re already using it, these new sources will help you unlock even more value. Stay tuned for our upcoming Ninja show and webinar (register at aka.ms/secwebinars), where we’ll dive deeper into use cases. Until then, explore the new sources, use the UEBA workbook, update your watchlists, and let UEBA do the heavy lifting. UEBA onboarding and setting documentation Identify threats using UEBA UEBA enrichments and insights reference UEBA anomalies reference
MTO Portal MFA Prompt Not Loading
Hi We are using the mto portal to hunt across multiple tenants. My team get the "loading completed with errors" message and the prompt for "MFA Login Required". When they select this the window to authenticate opens and then closes instantly. When selecting the tenant name they can authenticate in a new tab directly to Defender in this tenant without any issue (but this does not carry over to the MTO portal). The old behaviour was that they selected "MFA Login Required" and they could authenticate to the tenants they needed to at that time. Is this happening to anyone else? Does anyone have any tips for managing multiple Defender instances using MTO? ThanksRegistration Now Open for Series "Sentinel to Defender: Your Path to the Unified SOC Experience"
We're excited to announce a 3-part technical webinar series designed to guide security teams through the transition from Microsoft Sentinel to the unified Microsoft Defender portal! Who should attend: Security Architects, Engineers, and Analysts working with Sentinel and Defender implementations What you'll gain: Step-by-step onboarding guidance and real-world configurations Hands-on demos covering incident handling, threat hunting, and automation Clarity on RBAC changes, analytics rules, and new capabilities like Copilot, MTO, and UEBA Register now
Advanced Hunting Query Help
Hey y'all, I'm trying to write a query that can be used to determine the number of times an each IOC generated an alert (file hash, URL, IP, etc). I'm using the query builder tool within Defender, and I'm looking into the AlertInfo and AlertEvidence tables, but I'm not seeing where the link exists between each of these alert records and the corresponding IOC. For instance. If I submit a custom indicator, to Block a file identified by a sha256 hash, and that file gets correctly blocked, I want to see a count for the number of times that IOC value (the hash in this instance) triggered an alert. I'm hoping the community can help me determine whether I'm missing something glaringly obvious or if there's some documentation I haven't read yet. Thanks for reading!
