Office 365 urls as phishing detected!

IPFire Projects IPFire DBL
1

I’ve detected a very serious problem. The issue is with Office 365 email accounts and the incorrect categorization of the service’s URLs as phishing:

10:08:46 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.10, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:46 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:45 kresd[9439]:  [rules ] => local data applied, user: 172.16.1.10, name: outlook.cloud.microsoft. 
10:08:38 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.16, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:38 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:36 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: autodiscover.outlook.cloud.microsoft. 
10:08:22 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.50, name: outlook.cloud.microsoft. 
10:08:22 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.10, name: consumer.activity.roaming.windows.cloud.microsoft. 
10:08:22 kresd[9439]:  [rules ] => local data applied, user: 172.16.1.50, name: consumer.activity.roaming.windows.cloud.microsoft. 
10:08:21 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.10, name: outlook.cloud.microsoft. 
10:08:21 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.16, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:21 kresd[9439]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:21 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:08:21 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: outlook.cloud.microsoft. 
10:08:12 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: editor.svc.cloud.microsoft. 
10:08:06 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.16, name: outlook.cloud.microsoft. 
10:08:06 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: outlook.cloud.microsoft. 
10:07:56 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: eu.roaming.svc.cloud.microsoft. 
10:07:56 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: augloop.svc.cloud.microsoft. 
10:07:52 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.14, name: outlook.cloud.microsoft. 
10:07:52 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.50, name: outlook.cloud.microsoft. 
10:07:48 kresd[9439]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:07:39 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: m365.cloud.microsoft. 
10:07:39 kresd[9439]:  [rules ] => local data applied, user: 172.16.1.10, name: cloudpolicyclientsconfig.originmira.tm.svc.cloud.microsoft. 
10:07:39 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.50, name: cloudpolicyclientsconfig.originmira.tm.svc.cloud.microsoft. 
10:07:36 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: licensing.m365.svc.cloud.microsoft. 
10:07:29 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.10, name: autodiscover.outlook.cloud.microsoft. 
10:07:29 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: autodiscover.outlook.cloud.microsoft. 
10:07:29 kresd[9435]:  [rules ] => local data applied, user: 172.16.1.10, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:07:29 kresd[9437]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft. 
10:07:22 kresd[9436]:  [rules ] => local data applied, user: 172.16.1.50, name: atm.office.mira.tm.svc.cloud.microsoft.

It detects it as:

imagen
imagen811×189 3.67 KB

These false detections make this module unusable!

This is because a service as important as a company’s email cannot be interrupted at any time, and if incorrect categorization of certain URLs, whether from Microsoft or anyone else, causes a legitimate service to stop working correctly, then, in my opinion, it’s not viable.

2

Have had customers lose their email access using MS Outlook app today.

Disabled Phishing in DNS block list and now working.

Getting echoes of Location Block snafu where countries were not matching previous system entries.

This looks like a BIG problem in that nobody is policing block list changes and relying on community goodwill. A bad actor could put lots of legitimate sites into the DNS blocklists.

Maybe I am wrong on this? I’m sure IPFire devs will clarify.

3

The cloud.microsoft domain was added into the PhishDestroy list on Saturday.

An hour ago @kuni submitted a fix to that to the IPFire DBL and it was allowed.

Screenshot_2026-07-27_11-59-13
Screenshot_2026-07-27_11-59-131450×577 28 KB

4

No the IPFire devs are not reviewing all 206,334 entries in the PhishDestroy every time an update is done. This site is updating its list roughly every 1 to 3 hours with around 75 to 500 changes each time.

The phishing category as a whole has 680,799 entries.

False positives occur in any of these list, irrespective of where you get them from. The ones we have chosen are managed in such a way that they are responsive to issues that occur.

If you choose lists from sources that charge you, they still say that false positives can occur.

However, feedback of false positives from the IPFire community will result in a quicker response as we will apply that false positive input to the list that we get from our source. So it will be applied before the source has updated their list.

In fact 20 minutes ago another report was made into the IPFire DBL about cloud.microsoft but it had already been fixed by then from the first report.

5

Was really annoying today in the morning. outlook.office.com and outlook.office365.com (MS365 endpoints for outlook/web) also do not work, cause these are cnames to .cloud.microsoft-Domains. But temporary whitelisting in url-filter/dns firewall and a complete flush of dns-cache on dns-servers and firewall works.

6

No longer needs to be done as the domain was allowed 4 hours ago based on your report into the IPFire DBL.

7

Yeah, didn’t know how long it takes to revert this and i got other appointment, so i decided to whitelist.

8

We try our best to be as responsive as we can but I can understand that you whitelisted it.

9

Also Teams, One drive etc… all from M$ was blocked.

slika
slika1246×850 85.2 KB

Domain name system log display also cuts “com” at the end of blocked adresses…

Regards,

B. Hudina

10

No, Microsoft got its own top level domain “microsoft”.

Resolve-DnsName cloud.microsoft

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
cloud.microsoft                                AAAA   300   Answer     2603:1020:201:10::10f
cloud.microsoft                                AAAA   300   Answer     2603:1030:b:3::152
cloud.microsoft                                AAAA   300   Answer     2603:1030:20e:3::23c
cloud.microsoft                                AAAA   300   Answer     2603:1030:c02:8::14
cloud.microsoft                                AAAA   300   Answer     2603:1010:3:3::5b
cloud.microsoft                                A      300   Answer     20.112.250.133
cloud.microsoft                                A      300   Answer     20.231.239.246
cloud.microsoft                                A      300   Answer     20.236.44.162
cloud.microsoft                                A      300   Answer     20.70.246.20
cloud.microsoft                                A      300   Answer     20.76.201.171
11

I guess some of you guys have never heard of the Zero Trust philosophy?

The argument that Microsoft 365 is too important to risk being blocked seems rather contrary to the whole concept of Zero Trust.

A service does not become inherently trustworthy merely because it is business-critical or operated by Microsoft. In fact, services such as Microsoft 365 are particularly attractive targets for phishing and account compromise.

This was clearly a serious false positive, and the blocklist provider needs to correct it quickly—as they apparently did. But the conclusion should not be that Microsoft domains must never be blocked.

Before deploying broad, generalised filtering, administrators should also establish which services and destinations their organisation actually requires and ensure that appropriate exceptions and monitoring are in place.

The sensible conclusion is that security controls need good reporting, rapid correction, local override mechanisms and proper operational monitoring.