3rd party Phishing testing url being identified as malicious, unable to whitlist fully.

[Gareth_somers]

Hi Checkmates,

We're using a 3rd party (proofpoint) for phishing simulations, these work be sending in emails from proofpoint owned domains and include links to these domains that track click through (and present a notice to the user about phishing).

We're having a lot of trouble trying to allow the emails in and the http traffic out. We tried whitelisting the urls via dynamic objects and static but we're not getting consistent results and this is only for the sending domains and URL clicks, we can't see to prevent Checkpoint from defanged some of the urls contained in the emails.

Ideally the ProofPoint domains would be re-categorised but as we don't own them and can't vouch for them beyond our usage, I'm not sure if we better off getting ProofPoint to request this with Checkpoint? And if so, how likely is it that they will be actioned outside of opening a TAC call (our experience with other vendors on URL re-categorisation has not been great).

Is there a way to whitelist these consistently and across both HTTP and SMTP protections?

We're using R81.20 with URL Filtering, ThreatEmulation, IPS, Anti-Bot, AntiVirus and HTTPS inspection.

An example defang in an inbound email below:

Time: 2024-02-15T14:08:01Z
Triggered By: MTA
Original Queue ID: 4TbH2n5W89z4y9vC
Log ID: 0
Severity: High
Confidence Level: High
Malware Action: Malicious file/exploit download
Protection Type: Signature
Verdict: Malicious
Risk: 100
IP Protocol: 6
Destination Port: 25
Sender: updates@emailquarantine.net
Email Subject: Security Update
Email Recipients Number: 1
Scan Result: Malicious
Protection Name: Infecting URL
Last Hit Time: 2024-02-15T14:08:01Z
Action: Prevent

And below is the HTTPS behaviour, the policy was not changed during the 2 logs below:

Example HTTPS traffic outbound that matches the whitelist fine:

Time: 2024-02-08T17:22:59Z
Interface Direction: outbound
Service ID: https
Destination: 52.213.205.224
Destination Port: 443
IP Protocol: 6
Protection Name: Infecting URL.RS.TC.93c3wTZS
Confidence Level: High
Severity: Critical
Malware Action: Access to site known to contain malware
Protection Type: URL Reputation
Threat Prevention Rule Name: Phishing Simulator
Vendor List: Check Point ThreatCloud
Action Details: exception
Method: GET
HTTP Host: updates.emailquarantine.net
Action: Detect
Type: Log
Blade: Anti-Virus
Product Family: Threat
Action: Inspect
Resource: http://updates.emailquarantine.net/

A request 10 minutes before that was blocked even though it has the same domain and IP:

Time: 2024-02-08T17:08:18Z
Interface Direction: outbound
Service ID: https
Destination: 52.213.205.224
Destination Port: 443
Protection Name: Infecting URL.RS.TC.93c3wTZS
Confidence Level: High
Severity: High
Malware Action: Access to site known to contain malware
Protection Type: URL Reputation
Threat Prevention Rule Name: TE HTTP Rule Hold
Protection ID: 004CCA60C
Vendor List: Check Point ThreatCloud
Method: GET
HTTP Host: updates.emailquarantine.net
Confirmation Scope: Application
Action: Block
Type: Log
Blade: Anti-Virus
Product Family: Threat
Action: Inspect
Resource: http://updates.emailquarantine.net/
UserCheck Message to User: The site you are trying to access is classified as malicious and has been blocked. For more information, please contact your help desk. Click here to report an incorrect classification. Activity: Access to site known to contain malware URL: https://updates.emailquarantine.net/ Reference: 493203FD
UserCheck Interaction Name: Anti-Virus Blocked

[G_W_Albrecht]

I would suggest to contact CP TAC to get this resolved !

[Gareth_somers]

Just to update anyone that's hitting the same issue as me. I've had a TAC case opened now for 2 months, it has gone to Checkpoint developers and a couple of TAC engineers and the call is still open.

• Using Indicator files is the best way to whitelist and consistently works for HTTP/S & DNS protections. Configuring Threat Indicators (checkpoint.com) example csv: proofpoint1,www.shipping-notification.info,Domain,high,low,AV,"ProofPoint Phishing Simulation" and then set the action to Detect or Inactive. 
• However in 2 months we have been unable to prevent the links inside the emails from being defanged. The indicators do not work for this and neither does whitelisting the sender address, global exceptions or any other fix that's been tried.
• The only working solution that was provided was to disable scanning of links inside emails globally!
• A request to recategorise the problem domains was denied by Checkpoint devs (request came via TAC engineer) as the email are technically phishing so the category is correct apparently.

ProofPoint for their part have been quite accommodating but I'm not sure they believe that we can't just whitelist domains. They have offered to have a technical call where their engineers will try and fix the issue for us, at this point I'm almost willing to let them have a go!

Has anyone else had issues with urls inside emails being incorrectly identified by Checkpoint and short of turning off the link scanning, have a fix for this?

[Gareth_somers · Accepted solution]

As a final update, the issue is now resolved and the case closed. In order to fully whitelist a domain across all protections:

• Add an Indicator File with an action of detect or inactive: Configuring Threat Indicators (checkpoint.com)
• This works for all protections outside of email (so HTTP/S, DNS,IPS) and is more consistent than standard exceptions.
• Create a file on the MTA(s) -> $FWDIR/conf/mta_click_time_url_white_list add the domains in the format of .*<FQDN>.* with one entry per line. Push the Threat prevention policy and then wait! This is crucial as the file does not seem to take effect straight away, it was 10+ minutes before it started working (did not work on initial testing and was actually the following day before we tested again). After this emails with a URL that matches will be exempt from the MTA URL rewriting.

[PhoneBoy]

Thanks for the update.

[the_rock]

I just tested this link you gave -> http://updates.emailquarantine.net/

I whitelisted it using custom object *emailquarantine* and worked fine, though I have AV blade enabled in the lab.

If you wish, we can do remote session and see if we can figure it out.

Let me know.

Best,

Andy

[Gareth_somers]

Hi Andy,
Thanks it's one of a couple of domains in use for this, and the issue is I'm getting inconsistent results. Sometime it works and sometimes I get blocked (I'm also getting AntiBot DNS rewrites too). I've tried adding exceptions via static and dynamic objects and via custom Applications (although not with wildcards) but I can't see to get it where the urls will reliable get in untouched and can be followed to the remote site.
I'm going down the TAC route on this so I'm touch with our vendor to get a call opened.

Thanks!

[the_rock]

No worries...happy to do remote and check it, if you like.

Best,

Andy

[Paul_Kazzi]

Have experienced similar and the request was being allowed/overridden by configured  Proxy rulebase but was being blocked by DNS trap. Please refer to sk74060 for workaround. This worked for me.