Cannot create exception for "Phishing_website.mzle" protection

[Vladimir]

I am on a verge of loosing my cool after spending half a day on a seemingly trivial task of trying to create an exception for the Threat Prevention policy.

The goal is to allow my client's PCs to receive the Phishing training communication from the KnowBe4.

The vendor has three IPs but each campaign generates new resources.

Every time client tries to go to the spoofed site, i.e. "gmail.net-login.com", the gateway promptly bags it with:

Time: 2019-04-30T19:18:48Z
Interface Direction: inbound
Interface Name: eth3
Id: c0a8071f-0100-00c0-5cc8-9f9800000001
Sequencenum: 1
Threat Prevention Policy: Clean_Slate
Threat Prevention Policy Date:2019-04-30T19:17:59Z
Source: 10.101.30.101
Source Port: 50859
Destination Country: Israel
Destination: 62.0.58.94
Destination Port: 80
IP Protocol: 6
Session Identification Number:0x5cc89f98,0x1,0x1f07a8c0,0xc0000001
Protection Name: Phishing_website.mzle
Description: Connection to DNS trap bogus IP. See sk74060 for more information.
Confidence Level: High
Severity: High
Malware Action: Malicious network activity
Protection Type: DNS Trap
Threat Prevention Rule Id: FE9921CA-B861-425E-B0F2-19A1D217EFAD
Protection ID: 0018B6567
Log ID: 2
Scope: 10.101.30.101
Source User Name: ADuser2 Two (aduser2@higherintelligence.com)
Source Machine Name: win10net30@higherintelligence.com
User: ADuser2 Two (aduser2@higherintelligence.com)
Action: Prevent
Type: Log
Policy Name: Clean_Slate
Policy Management: SMS8030EA
Db Tag: {BAC69145-F44A-4148-9603-7CEBB47B7A42}
Policy Date: 2019-04-30T14:32:16Z
Blade: Anti-Virus
Origin: GW8030EA
Service: TCP/80
Product Family: Threat
Resource: gmail.net-login.com
Marker: @A@@B@1556596801@C@31302
Log Server Origin: 192.168.7.30
Orig Log Server Ip: 192.168.7.30
Index Time: 2019-04-30T19:19:54Z
Lastupdatetime: 1556651989000
Lastupdateseqnum: 1
Rounded Sent Bytes: 0
Rounded Bytes: 0
Stored: true
Rounded Received Bytes: 0
Suppressed Logs: 21
Sent Bytes: 0
Received Bytes: 0
Interface: eth3
Description: 10.101.30.101 performed malicious network activity that was prevented with DNS Trap
Threat Profile: Go to profile
Bytes (sent\received): 0 B \ 0 B

Trying to exempt the traffic by negating the destination group in the TP rules, creating manual exemptions with either "Detect" or "Inactive", doing same by creating the exemptions from the logs, does not change the behavior. DNS trap is activated every time.

Searching for the Protection Name: "Phishing_website.mzle" in either "Protections" or IPS Protections, does not help. The thing is not there.

Even creating a Categorization Exception:

As unfeasible as it is for this particular task, still does not work.

HELP!!!

[PhoneBoy]

I believe you can create a Threat Prevention rule where if the destination of the traffic is one of those specific IP addresses, the profile is a Detect only profile, inactive, or similar.
Have you tried that?

[Vladimir]

You would not believe how many different combinations of rules, policies, profiles and exceptions I have tried 🙂

Presently, this is the policy with 2 profiles, one of them has no AV blade, as that's the one that seem to be triggering this protection, but I have tried it with single profiles with negated cells as well:

The exceptions are now in "Detect" mode, but I have tried it with "Inactive" as well:

Not to mention that the actual spoofed domain resolving to those IPs is in the "Categorization Exemption".

All of it is still does not work.

Even if it would, it is not really a long term solution for Spoofing training vendors: they spin-up instances on AWS behind dynamically allocated IPs and newly crafted domains every time.

That being said, the exemptions must work and they do not. 

[Vladimir]

P.S. I think that the best solution for all involved will be for these companies to feed their exercise domains to the Threat Cloud for whitelisting and differentiated categorization.

This way, they will not be bagged by the protections and reduce manual labor for admins fighting with this issue. 

[TP_Master]

Hi Vladimir

Categorization Exemption is for URLF, not AV/AB ..

After setting up all those exception experiments - what logs do you see in SmartLog? Prevent logs for what?

Maybe the issue is that you didn't exempt the internal DNS server from inspection? is there one? if so - IT asks for gmail.net-login.com's IP address and gets the bogus address...

[Vladimir]

@TP_Master , please see the very first post in this threat describing the event that I am seeing.

Of course the internal DNS forwarded itself is not exempt from overall inspection, but how does this figures into the AV triggering DNS Trap?

while gmail.net-login.com is definitely a spoofing URL, it does resolve to a number of IPs when tested from outside of Check Point protected environment. 

What then decides that the returned address supposed to be replaced by the DNS Trap?

How that action could be exempt, if neither IPs nor application or URL exceptions are working?

[TP_Master]

My theory is this - the DNS request is sent from your computer to the internal DNS server. It is then forwarded by the internal DNS server to the exteranl one through the Check Point GW. *this request is found by AV and the response is with the DNS Trap bogus IP*.
Subsequently, it is sent to the computer which tries to access gmail.net-login.com but goes to the bogus IP which is blocked...

Try to add exemption for this domain when the protected scope is your internal DNS server.

Does that make sense?

[Vladimir]

@TP_Master , in this environment there is a common protection scope for the entire organization (i.e single default TP rule with scope "Any".

So the exception should, theoretically, work for both, the clients as well as internal DNS forwarders.

[Vladimir]

It is actually funny: KnowBe4 emailed me response with the URLs to the txt files listing their phishing domains.

Along the way it was bagged by:

1. Office 365

2. Check Point gateway

3. Kaspersky AV on the endpoint

The only solution that did not pay any heed to this message was Check Point CloudGuard SaaS for Office 365.

Makes me wander if it is a good sign or the bad one...

I am yet to see the darned lists.

[dantlitz]

Having the same issue and CG SAAS is bagging our messages as well.  We have overcome the SAAS issues but the gateway doesn't seem to like any exception we put in  KB4 support is little no help 

[TP_Master]

It is true if you had an exception with "any" in the scope, source and destination fields. In your screenshot there isn't one..

[Vladimir]

@TP_Master , in client's environment it is, but as you've rightly noticed, in my lab it is different.

Regardless, the problem is that the destination IPs of the spoofed domains are dynamic.

So trying to exempt them in the TP policy using scope, source and/or destination will not work.

I have to figure out how to bypass the TP based on domain names and FQDNs which TP Policy does not support and categorization exception does not work.

[TP_Master]

Have you tried to add a site and add it to the exception? (in the site/protection column)

[Marco_Valenti]

Have you try to disable dns trap on tp profile?

[Vladimir]

@Marco_Valenti , I think KnowBe4 got this site whitelisted with the Threat Cloud, because it does not cause same issues anymore in my clients case.

Their other landing page was being blocked by Quad9 secure DNS service and I have notified KB4 about all of these issues.

Got the response that they are working with the threat intelligence vendors to get their domains cleared.

[Biggsy]

I'm having this same issue only with a vendor named InfoSec IQ, used to be Security IQ.  Anyway, I tried basically everything you tried.  I am now asking the vendor to whitelist their domains with the Threat Cloud. 

[r1der]

We use KB4 too and this is exactly the issue I'm running into. I right clicked the Prevent log card and "added exception" and then removed the source so it is ANY, but the URL is still blocked. Based on your solution I opened a case up with KB4. I tried to get the category changed, but CP still marked it as phishing. Waiting to see if that would help or I might open a CP case up to see how I can add an exception there since our spam filter also did mark it as phishing.