application control categories

[Daniel_Kavan]

Has anyone tried to create a category for unallowed domains, like webhook.site?

https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-...   We're blocking traffic to the domain webhook.site currently.   Rather than maintaining a rule getting 0 hits, is there an application control category to block traffic to webhook.site?   How do you look up to see if an IP or domain falls into an already existing category?

Non-authoritative answer:
Name: webhook.site
Addresses: 2a01:4f8:121:114d::2
2a01:4f8:121:11a5::2
178.63.67.153
178.63.67.106

[Chris_Atkinson · Accepted solution]

Going custom objects is probably the path here purely from a URLF perspective.

Last i looked at this it was more a case of a legitimate online service being misused meaning it potentially falls outside the normal use case of URLF based on categories alone.

Suspect it would fit into Computers / Internet / Business but you can check it here: https://usercenter.checkpoint.com/ucapps/urlcat/ 

[Daniel_Kavan]

I made a recommendation that it gets re-categorized to malicious sites based on Widespread Supply Chain Compromise Impacting npm Ecosystem | CISA   Maybe, check point can create a new category like application control jail.  For temporary sites that are out of compliance.

[the_rock]

Always good idea to send a request.

[the_rock · Accepted solution]

Hey Dan,

Here is what MS copilot gave me. This is on "deep think" setting, whatever that means lol

***************************

✅ Check Point — Custom Application Control Category

Here is a ready‑to‑paste definition for Check Point:

1. Go to Objects → Object Explorer → Application Categories
2. Click New Category
3. Name it:
   Blocked Callback Domains (Internal Security)
4. Add Custom Applications & URLs → New → Application/Site
5. Add these entries:

webhook.site
*.webhook.site
emailhook.site
*.emailhook.site
dnshook.site
*.dnshook.site
178.63.67.153
178.63.67.106
168.119.249.101
2a01:4f8:121:114d::2
2a01:4f8:121:11a5::2

[Roslany]

I would recommend adding either both of these for exclusively blocking a domain (none regex custom application):

webhook.site
www.webhook.site

Or this for blocking both the domain and its subdomains:

*webhook.site

Regarding the main topic -

If there are many URLs / Domains / IPs we need to block (and maintain & update the list), then IoC feeds or External Network Feeds would be best approach.

For a smaller list of just URLs - a custom application object would suffice.

sk165094: Best Practices - Custom Applications/Sites for Application Control and URL Filtering

R81.20 Quantum Security Management Administration Guide - External Network Feeds

sk132193: What is the "Custom Intelligence Feeds" feature?

[the_rock]

Im with you, totally agree. I just have bad habit of doing *domain* to exempt these things, but of course thats not close to optimal solution, I just found myself too many times in the past troubleshooting these things for hours on end.

[the_rock]

Here is what url lookup shows:

URL Categorization

For:  http://webhook.site

Current Categories: Computers / Internet, Low Risk

Computers / Internet

This category is intended to cover websites related to computing software and hardware, as well as Internet and technology-related companies. This includes, but is not limited to vendors, product reviews, and deployment and maintenance of software and hardware. This also includes addons such as scripts, plugins, drivers, peripherals, and other equipment used in conjunction with computers and networks. Examples: http://www.archive.org, http://www.verisign.com, http://www.limewire.com, http://www.w3schools.com

Low Risk

Applications and Websites that are potentially non business related yet low risk.

[SimonFredsted]

Hello

I'm the founder of Webhook.site. I found this via Google Alerts. In case you didn't know, we have thousands of paying customers using Webhook.site for testing webhooks, building workflows and other purposes, so it is worrying that some of our users are seeing their access blocked. Here's some more info about our company: https://docs.webhook.site/#what-is-webhooksite

Where can we report this false positive? Thanks.

[Chris_Atkinson]

To contrary the access is not blocked by default, some community members are requesting better ways of blocking hosted elements should they choose to.