Forum Discussion
Solved
Mark a URL as malicious in Microsoft 365 Defender
Our tenant received phishing mails a few days ago from an external hacked email account with good reputation. Emails went through, and contained a link to a phishing site. Now that I know the URL...
- Depending on the severity, I would do all or some of the following:
1) Find the mail on the Security portal and look for additional copies, searching on sender and separately on sender domain and on subject line elements if they are not too generic.
2) If these are not already zapped, report the most recent 10 as phish to stimulate a ZAP. If the original message or copies were zapped but the detection message was spam-related, report them as a phish anyway.
You can also report a URL directly via https://security.microsoft.com/reportsubmission but as far as I am aware, reporting the mail is simpler and quicker. Ideally you have the Report Message add-in for Outlook already deployed and your users trained to use it.
3) You should have a mail flow rule already set up to which you can add the problem URL. You need to be confident of the correct wildcard format to ensure a match. A typical action could be to subject line-tag and divert matches to the hosted quarantine or to an administrative mailbox. This is useful for shutting down cases that Microsoft seem to be unable to accept, but remember that MFR changes take half-an-hour or more to apply, and will also shut down any internal IT discussion of the case. You and any of your colleagues will need to obfuscate the link in whatever format your security providers typically use. If memory serves, Microsoft substitute [%%] for period.
4) The Security portal URL search only matches whole host names. For attacks with varying subdomains, try the KQL:
let timeframe = ago(3d);
EmailUrlInfo
| where Timestamp > timeframe
| where Url contains "suspect.tld"
| join (EmailEvents
| where Timestamp > timeframe)
on NetworkMessageId
| project Timestamp, Subject, SenderIPv4, SenderFromAddress, RecipientEmailAddress, DeliveryLocation, Url, UrlCount
| sort by Subject asc, Timestamp asc
That may help you understand the threat a little more, but it doesn't get the domain into Microsoft's database. Including ThreatTypes, ThreatNames or DetectionMethods in the project may help you see if it is already in there.
5) You can put the URL into the Tenant Allow/Block list under the URL tab, which will also cover you for SharePoint / OneDrive: https://security.microsoft.com/tenantAllowBlockList. Bear in mind that there is a limit of 500 blocks including senders and domains, so a lot of Never Expires will soon run out of space. I don't know if Microsoft uses these entries as a source of intelligence.
Depending on the severity, I would do all or some of the following:
1) Find the mail on the Security portal and look for additional copies, searching on sender and separately on sender domain and on subject line elements if they are not too generic.
2) If these are not already zapped, report the most recent 10 as phish to stimulate a ZAP. If the original message or copies were zapped but the detection message was spam-related, report them as a phish anyway.
You can also report a URL directly via https://security.microsoft.com/reportsubmission but as far as I am aware, reporting the mail is simpler and quicker. Ideally you have the Report Message add-in for Outlook already deployed and your users trained to use it.
3) You should have a mail flow rule already set up to which you can add the problem URL. You need to be confident of the correct wildcard format to ensure a match. A typical action could be to subject line-tag and divert matches to the hosted quarantine or to an administrative mailbox. This is useful for shutting down cases that Microsoft seem to be unable to accept, but remember that MFR changes take half-an-hour or more to apply, and will also shut down any internal IT discussion of the case. You and any of your colleagues will need to obfuscate the link in whatever format your security providers typically use. If memory serves, Microsoft substitute [%%] for period.
4) The Security portal URL search only matches whole host names. For attacks with varying subdomains, try the KQL:
let timeframe = ago(3d);
EmailUrlInfo
| where Timestamp > timeframe
| where Url contains "suspect.tld"
| join (EmailEvents
| where Timestamp > timeframe)
on NetworkMessageId
| project Timestamp, Subject, SenderIPv4, SenderFromAddress, RecipientEmailAddress, DeliveryLocation, Url, UrlCount
| sort by Subject asc, Timestamp asc
That may help you understand the threat a little more, but it doesn't get the domain into Microsoft's database. Including ThreatTypes, ThreatNames or DetectionMethods in the project may help you see if it is already in there.
5) You can put the URL into the Tenant Allow/Block list under the URL tab, which will also cover you for SharePoint / OneDrive: https://security.microsoft.com/tenantAllowBlockList. Bear in mind that there is a limit of 500 blocks including senders and domains, so a lot of Never Expires will soon run out of space. I don't know if Microsoft uses these entries as a source of intelligence.
1) Find the mail on the Security portal and look for additional copies, searching on sender and separately on sender domain and on subject line elements if they are not too generic.
2) If these are not already zapped, report the most recent 10 as phish to stimulate a ZAP. If the original message or copies were zapped but the detection message was spam-related, report them as a phish anyway.
You can also report a URL directly via https://security.microsoft.com/reportsubmission but as far as I am aware, reporting the mail is simpler and quicker. Ideally you have the Report Message add-in for Outlook already deployed and your users trained to use it.
3) You should have a mail flow rule already set up to which you can add the problem URL. You need to be confident of the correct wildcard format to ensure a match. A typical action could be to subject line-tag and divert matches to the hosted quarantine or to an administrative mailbox. This is useful for shutting down cases that Microsoft seem to be unable to accept, but remember that MFR changes take half-an-hour or more to apply, and will also shut down any internal IT discussion of the case. You and any of your colleagues will need to obfuscate the link in whatever format your security providers typically use. If memory serves, Microsoft substitute [%%] for period.
4) The Security portal URL search only matches whole host names. For attacks with varying subdomains, try the KQL:
let timeframe = ago(3d);
EmailUrlInfo
| where Timestamp > timeframe
| where Url contains "suspect.tld"
| join (EmailEvents
| where Timestamp > timeframe)
on NetworkMessageId
| project Timestamp, Subject, SenderIPv4, SenderFromAddress, RecipientEmailAddress, DeliveryLocation, Url, UrlCount
| sort by Subject asc, Timestamp asc
That may help you understand the threat a little more, but it doesn't get the domain into Microsoft's database. Including ThreatTypes, ThreatNames or DetectionMethods in the project may help you see if it is already in there.
5) You can put the URL into the Tenant Allow/Block list under the URL tab, which will also cover you for SharePoint / OneDrive: https://security.microsoft.com/tenantAllowBlockList. Bear in mind that there is a limit of 500 blocks including senders and domains, so a lot of Never Expires will soon run out of space. I don't know if Microsoft uses these entries as a source of intelligence.
