phishing
44 TopicsImpersonation Protection: Users to Protect should also be Trusted Senders
Hey all, sort of a weird question here. Teaching my staff about Impersonation Protection, and it's kind of occurred to me that any external sender added to 'Senders to Protect' sort of implicitly should also be a 'Trusted Sender'. Example - we're an MSP, and we want our Help Desk (email address removed for privacy reasons) to be protected from impersonation. Specifically, we want to protect the 'Help Desk' name. So we add email address removed for privacy reasons to Senders to protect. However, we ALSO want to make sure our emails come thru. So we've ALSO had to add email address removed for privacy reasons to Trusted Senders on other tenants. Chats with Copilot have sort of given me an understanding that this is essentially a 'which is more usefuI' scenario. But CoPilot makes things up, and I want some human input. In theory, ANYONE we add to 'trusted senders' we ALSO want protected from Impersonation. Anyone we protect from Impersonation we ALSO want to trust. Copilot says you SHOULDN'T do both. Which is better / more practical?I would like to know the complete list of alerts whose serviceSource is MDO
Hi all In order to determine the alerts that should be monitored by the SOC, I would like to identify, from the alerts listed at the link below, those whose serviceSource is Microsoft Defender for Office 365 (MDO). https://learn.microsoft.com/en-us/defender-xdr/alert-policies I couldn’t find where this is documented, no matter how thoroughly I searched, so I would appreciate it if you could point me to the relevant documentation. thxuser-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!Display Name Spoofing very often recently - how to prevent it
Hi experts, recently, I have noticed increase in emails that tries to impersonate sender (Display Name Spoofing). The Display name shows a real user from our organization, however the sender email/domain is totally different. I thought I had the protection configured properly but looks like that is not the case :/. I have anti-phish policy with Impersonation as below: few critical users listed in "Enable users to protect" was going to enable it for all now, but there is no option like that, ..and it looks I need to manually add all internal users Enable domains to protect Include domains I own (does this include all domains I have registered in M365? See below). I would expect this will prevent these emails Include custom domains - I have nothing here, but I am not sure now whether my few domains created in M365 - including default domain, needs to be added here? As from what I know, the custom domains are the domains I create in M365. Would like to check what is the proper way to configure protection against these email attacks. We use M365 E3 + M365 E5 SecuritySolved1.9KViews0likes2CommentsMicrosoft Defender EOP
We have been experiencing an issue since last week where we are unable to view the details of quarantined emails. Could you please confirm if this is related to a known backend service issue, or if there are any specific troubleshooting steps we should perform on our end? Any guidance or updates would be greatly appreciated.No URL Detection in Emails with Extensive %2580 Encoding
Hi Community, I encountered a concerning issue where emails containing URLs with extensive encoding (%2580) completely bypassed all detection and security mechanisms. These encoded URLs weren’t identified as links, which allowed them to evade security scanning. Issue Details: The email contained malicious URLs encoded with %2580. The URLs were not flagged or identified as links, allowing the payload to bypass filters entirely. Questions: Has anyone else encountered similar issues with encoded URLs bypassing detection? What’s the best process to submit this email to Microsoft for analysis and improvements to detection mechanisms, since no URL's were identified? Looking forward to your input and recommendations. Thanks in advance!553Views0likes4CommentsAdding Targeted Users/Groups in Attack Simulator
Is there a setting that may have changed recently or needs to be changed that enables filtering by groups when creating a simulation. I am unable to browse our groups in our organization any longer, I can choose from other options like City, Departments, Titles, etc. but the AD groups do not populate any longer in this list when trying to add Target Users. Thank you, Jerid6.1KViews1like4CommentsAIR Result : Email template modification
Hi, I want to change the email language for the Automated investigation and response (AIR) after a phishing report. I found the page where you can set a custom email "Body" and "Footer". This works, but I also need to change the other parts of the email or at least find a way to translate it in french. Right now, there's a mix of english and french (The body and footer I configured) but I need the whole thing to be in french. I would appreciate a hand on this issue. Thank you !! PS : See the screenshot for the part I want to translate.Effectiveness of "Impersonation Protection" within the Standard Protection security policy
Recently we began trying to improve the overall posture of our O365 Exchange. One step of that was enabling both the Preset Security Policies. These have been enabled and I've set up Impersonation Protection on both with pretty much the same list of internal stakeholders to protect. What we appear to be seeing is that impersonation protection doesn't work for those users on Standard Protection. Support is telling me that's how it works and that I should move all of our users to Strict Protection if we want to take advantage of the Impersonation Protection. My limited tests seem to back this up, but the fact that Impersonation Protection is an available option in the Standard preset policy is baffling if it's as ineffective as it seems to be. As a test I setup a new outlook.com account with the name of the a protected user. I then sent an email to my personal Gmail account and two internal employees. The email was delivered to the Gmail account (expected) and to the 'Standard' employee. The email to the 'Strict' employee was quarantined with a note about impersonation. For the 'Standard' employee it was allowed with the note "Allowed by user policy : Trusted recipient address list". I verified the external address is not in the 'Standard' user's Safe Sender list. Are others seeing this behavior as well?