Check Point ThreatCloud flags whole cloudfront.net as phishing

[Tobias_Moritz]

False positives can happen and do happen from time to time. Normally I would not create a CheckMates post for that.

But today, we got a quite big problem:

The original Check Point ThreatCloud feeds flagged the the whole cloudfront.net domain (not just specific sub domains) as phishing with confidence level set to high.

This results in huge problems:

• Our DNS recursive resolvers were not able to resolve a quite large part of the internet anymore, because cloudfront is that common these days (in CNAMEs).
• Even more problematic was the the problem, that our gateways could not reach the Check Point TP feed URLs anymore, because even Check Point uses Cloudfront for that. That means the problem does not correct itself by just waiting until Check Point or its supplier fixes this false positive.

We added TP exceptions, did TP policy install and everthing starts to recover.

We will now wait until CP delivers fixed feeds before removing our exception again.

Please see screenshot. The Action=detect was after we added the exception:

 

The problem started first in our logs at 23.02.2026 08:00 UTC and is still occuring about two hours later (covered by our exception).

[PhoneBoy]

That was an AV signature, which only exists in ThreatCloud (not in downloaded signatures).
Given I saw no other reports of this internally, I have to assume this was caught and addressed quickly.

[Tobias_Moritz]

Thanks for that clarification, Dameon. So I was wrong about the "won't fix itself", because the broken signature download had no side effect to the correction of the wrong classification.

However, 23.02.2026 08:22 UTC (first log entry) and 23.02.2026 12:48 UTC (last log entry) means aprox. 4,5 hours of blocking of one of the top 1000 domains, at least for customers who use ThreatCloud for DNS filtering.

[Tobias_Moritz]

Unfortunalty, the problem is back. Today, starting 24.02.2026 09:16 UTC, Check Point Thread Cloud is again classifying cloudfront.net as phishing. It still is, while I'm writing this.

What's going? Such a major false-positive two days in a row?

[Alex-]

We don't see this. Do you have IoC configured?

[Tobias_Moritz]

We have indicators (custom IOC feeds) configured, but as you see in the screenshot in my first post, the vendor list is "Check Point ThreatCloud". When we have matches within our custom IOC feeds, we see the reference to that feed in the log card. But this one seems to be native from Check Point. The matching protection name today is the same like yesterday in my screenshot: "Phishing.TC.d16ePthE"

[mp2012]

I’m seeing the same behavior on my end. I had to add an exception because even the CP community wasn’t accessible.

[PhoneBoy]

I have not seen any other reports of this issue, including in TAC cases. 
I would get the TAC involved at this point.

[Fabian1307]

Can confirm I also have a customer facing the same problems!
Like you said, major dns domains accross the internet are beeing blocked since a few days!

[Tobias_Moritz]

As Dameon suggest, I opened a TAC case and currently, it looks like a bug:

1. cloudfront.net is clean in ThreatCloud, and URL Filtering currently categorizes it as Computers / Internet with Low Risk.
2. The detection seen in the screenshot is tied to a specific CloudFront subdomain: d2zvg5qlc6mxlr[.]cloudfront[.]net, which triggered Phishing.TC.d16ePthE.

3. When you take a look at the screenshots, you see that it blocks cloudfront.net and not d2zvg5qlc6mxlr[.]cloudfront[.]net. This should not happen. This blocking occurs, when our recursive DNS server tries to resolve for example www.checkpoint.com over the root chain, because this a CNAME to d4epvaz4tpdrm.cloudfront.net and we have DNS-Sec enabled so our resolver asks for type=DS Name=cloudfront.net. This DS-Request for cloudfront.net is blocked by the protection Phishing.TC.d16ePthE.

4. From the PCAP, we can confirm that the traffic shown is a standard DNSSEC validation step: a DS query for cloudfront.net sent from the recursive resolver to a .net TLD server, with a normal DNSSEC response (NSEC3/RRSIG) returned. In the corresponding log overview (matching minutes/seconds), the Anti-Virus blade shows a Prevent action for a DNS query to cloudfront.net, triggered by protection Phishing.TC.d16ePthE.
   Based on the behavior observed, this appears to be a technical issue related to how the Anti-Virus blade applies the reputation decision during DNS resolution (specifically at the DNSSEC/DS validation stage), resulting in the block being enforced at the cloudfront.net level rather than only at the specific malicious subdomain.
   For further investigation, this is now escalated to RnD

So lets see, what RnD says. If I get a resolution for this problem, I will share it here with you folks.

[PhoneBoy]

Thanks for the details on this and definitely keep us posted!

[Fabian1307]

Checkpoint TAC reported the same to me.

Looks like we need to wait until RnD is done.

[Fabian1307]

Any updates from your side?
We are asked to provide a lot of data which may lead to downtime. By that it is not possible for us to provide..