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. Learn: Detection technology details table What's on the Email entity page Filterable properties in the All email view in Threat Explorer
TVM still showing outdated vulnerabilities despite applications being up to date
Hi everyone, we’re using Microsoft Defender for Endpoint with Threat & Vulnerability Management (TVM) enabled. Lately, we've noticed that certain vulnerabilities (e.g., CVEs in browsers or third-party software) continue to be flagged on devices, even though the affected applications have been updated weeks ago. Example scenario: The device is actively onboarded and reporting to Defender XDR The application has been updated manually or via software deployment The correct version appears under Software Inventory However, the CVE still shows up under Weaknesses Has anyone experienced similar behavior? Are there any best practices to trigger a re-evaluation of vulnerabilities or force a TVM scan refresh? Would a device reboot or restarting the MDE service help in this case? Any insights, suggestions, or known workarounds would be greatly appreciated. Thanks in advance!
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?
Playbook when incident trigger is not working
Hi I want to create a playbook to automatically revoke session user when incident with specifics title or gravity is created. But after some test the playbook is'nt run autimacally, it work when I run it manually. I did'nt find what I do wrong. See the image and the code bellow. Thanks in advance! { "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "contentVersion": "1.0.0.0", "triggers": { "Microsoft_Sentinel_incident": { "type": "ApiConnectionWebhook", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['azuresentinel']['connectionId']" } }, "body": { "callback_url": "@{listCallbackUrl()}" }, "path": "/incident-creation" } } }, "actions": { "Get_incident": { "type": "ApiConnection", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['azuresentinel-1']['connectionId']" } }, "method": "post", "body": { "incidentArmId": "@triggerBody()?['object']?['id']" }, "path": "/Incidents" }, "runAfter": {} }, "Send_e-mail_(V2)": { "type": "ApiConnection", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['office365']['connectionId']" } }, "method": "post", "body": { "To": "email address removed for privacy reasons", "Subject": "Ceci est un test", "Body": "</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['id']}</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['properties']?['description']}</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['properties']?['incidentNumber']}</p> <p>", "Importance": "Normal" }, "path": "/v2/Mail" }, "runAfter": { "Get_incident": [ "Succeeded" ] } } }, "outputs": {}, "parameters": { "$connections": { "type": "Object", "defaultValue": {} } } }, "parameters": { "$connections": { "type": "Object", "value": { "azuresentinel": { "id": "/subscriptions/xxxx/providers/Microsoft.Web/locations/xxxxx/managedApis/xxxxxxx", "connectionId": "/subscriptions/xxxxxxx/resourceGroups/xxxxxx/providers/Microsoft.Web/connections/azuresentinel-Revoke-RiskySessions1", "connectionName": "azuresentinel-Revoke-RiskySessions1", "connectionProperties": { "authentication": { "type": "ManagedServiceIdentity" } } }, "azuresentinel-1": { "id": "/subscriptions/xxxxxx/providers/Microsoft.Web/locations/xxxx/managedApis/xxx", "connectionId": "/subscriptions/xxxxxxx/resourceGroups/xxxxx/providers/Microsoft.Web/connections/xxxx", "connectionName": "xxxxxx", "connectionProperties": { "authentication": { "type": "ManagedServiceIdentity" } } }, "office365": { "id": "/subscriptions/xxxxxx/providers/Microsoft.Web/locations/xxxxx/managedApis/office365", "connectionId": "/subscriptions/xxxxx/resourceGroups/xxxxxx/providers/Microsoft.Web/connections/o365-Test_Send-email-incident-to-xxxx", "connectionName": "o365-Test_Send-email-incident-to-xxxxx" } } } } }Auto-Remediation of Malicious Messages in Automated Investigation and Response (AIR) is GA
We are excited to announce the GA release of auto-remediation of malicious messages through automated investigation and response (AIR) expanding this powerful tool and deliver on full end to end automation of key SOC scenarios. AIR works to triage, investigate and remediate and respond to high-impact, high-volume security alerts providing tenant level analysis to increase customer protection and optimize SOC teams. With this enhancement, customers will be able to configure AIR to automatically execute remediations for messages within malicious entity clusters saving SOC teams time and further expediting remediation by removing the need to for SOC teams to approve these actions! To highlight the key user submission scenario, in addition to AIR completing triage, investigation, remediation identification, and end user feedback responses, customers may now configure AIR to take this a step even further to automatically execute on identified remediations. Auto-Remediation Action When AIR recognizes a malicious file or URL, it creates a cluster around the malicious file or URL grouping all messages that contain that file or URL into the respective cluster. The automated investigation then checks the location of the messages within the cluster and if it finds messages within user’s mailboxes, AIR will produce a remediation action. With the auto-remediation enhancement, if the customer has configured the cluster type to auto-remediate, this action will automatically be executed without the need for SecOps approval - removing identified threats at machine speed! Auto-remediated clusters showing in action center history with decided by stating automation: Configuration Auto-remediation will be controlled by a configuration within Settings > Email & Collaboration > MDO automation settings. Within the message clusters section, organizations may specify which types of message clusters they would like to be auto-remediated: Similar files: When the automated investigation recognizes a malicious file, it creates a cluster around the malicious file grouping all messages that contain that file into the cluster. Selecting this checkbox will opt the organization into auto-remediation for these malicious file clusters. Similar URLs: When the automated investigation recognizes a malicious URL, it creates a cluster around the malicious URL grouping all messages that contain the URL into the cluster. Selecting this checkbox will opt the organization into auto-remediation for these malicious URL clusters. The next configuration is for the remediation action, designating soft delete as soft delete is currently the only action supported through AIR. Auto-remediation of malicious entity clusters configuration found in settings>Email & collaboration>MDO automation settings: Note: Customers interested in auto-remediation must turn it on through the MDO automation settings page as it will not be on by default. Auto-Remediation Action Logging The Defender portal provides several ways for customers to review remediation actions to stay cognizant of the actions executed. These include within the investigation, action center, email entity as well as threat explorer and advanced hunting. Should customers disagree with the action executed, the ability to move the messages back to mailboxes is available as well based on configuration and timing. Auto-remediated messages showing in Threat Explorer Additional actions as Automated Remediation: automated: Auto-remediated messages showing in Advanced Hunting with ActionType as Automated Remediation and ActionTrigger as Automation: Learn More Register for the deep dive webinar on Microsoft Defender for Office 365 automated investigation and response (AIR) on June 25, 2025, at 8:00am PDT / 3:00pm UTC. Learn more about the feature enhancements, as well as how AIR can help optimize SOC teams and accelerate threat response. To learn more about the auto-remediation in AIR, please visit Automated remediation in AIR - Microsoft Defender for Office 365 | Microsoft Learn. To learn more about investigations in MDO, please visit the following pages: Automated investigation and response in Microsoft Defender for Office 365 - Office 365 | Microsoft Learn View the results of an automated investigation in Microsoft 365 - Office 365 | Microsoft Learn How automated investigation and response works in Microsoft Defender for Office 365 - Office 365 | Microsoft Learn Automatic user notifications for user reported phishing results in AIR - Microsoft Defender for Office 365 | Microsoft Learn
Optimisation For Abnormal Deny Rate for Source IP
Hi, I have recently enabled the "Abnormal Deny Rate for Source IP" alert in Microsoft Sentinel and found it to be quite noisy, generating a large number of alerts many of which do not appear to be actionable. I understand that adjusting the learning period is one way to reduce this noise. However, I am wondering if there are any other optimisation strategies available that do not involve simply changing the learning window. Has anyone had success with tuning this rule using: Threshold-based suppression (e.g. minimum deny count)? Source IP allowlists? Frequency filters (e.g. repeated anomalies over multiple intervals)? Combining with other signal types before generating alerts? Open to any suggestions, experiences, or best practices that others may have found effective in reducing false positives while still maintaining visibility into meaningful anomalies. Thanks in advance,
Change service account to avoid cached password in windows registry
Hi , In Microsoft 365 defender > secure score there's a recommendation for me saying "Change service account to avoid cached password in windows registry" , and I can see multiple MSSQL services falling into this recommendations . But the remediation is not very clear , what should I need to do in here ? Thanks ,upgraded from P1 to P2... how do I configure this?
Upgraded to Defender 365 P2 from P1, based on the automated responses. Kinda figured we'd be able to tweak these, but I guess not? Anyway, I'm a little bit confused about how to set this up maximally. Realized yesterday we had a 'User click a malicious link" investigation that was pending - but no one knew. When I click 'Email Notification' in the 'Incidents' window, it brings me to the XDR settings menu, with options for setting emails to notify of Alerts, Incidents and Threat Analytics. Except we don't have XDR? So I can't tell if these are even valid? The documentation on the AIR component is really hard to decipher - wondering if anyone has much experience with this, and knows how to configure it optimally? As in, how do I notify someone of a Critical Investigation, or something needing approval for remediation? Can I configure certain things to not require approval? Like... removing a reported phishing email from everyone's inbox?
