Authorized pishing scenarios, issues with Pan DB Url filtering

[marcelocampos]

In my company we are generating authorized pishing test scenarios to test users who compromise their assets when interacting with pishing links in their emails, for this we want to collect information and statistics on who opened the email, clicked on the link and / or entered personal information. To then generate awareness campaigns.
The tool used is called Smartfense, we previously tested with Cofense but we had the same result. The problem is that the links contained in the emails are previously analyzed by the PAN DB URL, which corrupts the test results generating false positives.

The data of our corporate firewall are: Model PA3250 S.O version 9.0.9h1.

Inbound security policies were configured allowing in the policy a customized url pointing to the url of the Smartfense tool, according to the information released by the tool manufacturer. Even so, the links continue to be analyzed.

Has anyone had the same problem ?, I remain attentive to your kind help. Regards.

[Remo]

Hi @marcelocampos 

Are you sure that it is pan-db service which is opening the urls? If yes, then there is another reason that triggers pan-db. It could be wildfire - if you configured wildfire analysis for incoming emails. If your mailgateway is located somewhere in the cloud (like office365) and you do not control it directly, then it could be also a security feature there that analyses the urls in emails.

Could you share some more information about your email infrastructure?

[marcelocampos]

Hi @Remo , 

I'm not sure if it's the pan db url filtering or wildfire. The truth is that it performs the exercise by removing the security profile sends to wildfire from the security policy, keeping the custom url filter in the policy, to allow the urls of the pishing testing tools (smartfense). Even so, the emails are still being analyzed by IP of palo alto.

our mail flow is: load balancers (untrust) -> vsys perimetral fw - trendmicro antispam (dmz zone) -> on-premises exchange server (trust). the tests were done by removing the wildfire security profile in the untrust -> dmz policies and dmz -> trust zone.

I stay tuned, I appreciate your help.

[Remo]

@marcelocampos  just that I understand correctly: even if you completely remove wildfireprofiles from securityrules that affect your mailflow, the full unique URLs (not only the domain) are still analyzed by a public IP address that belongs to paloaltonetworks?

[marcelocampos]

Good day @Remo 

As you indicate, effectively remove the security profile in the perimeter vsys, but after a new review I realized that there is another context that participates in the mail communication flow, a virtual context called vsys datacenter (internal servers).

Regarding the custom url filter, add the urls with the wilcard *. before the domain in order to allow everything associated.

It may be that with the discovery of the participation of the vsys datacenter context in the communication flow is the reason for the inconvenience.

Similarly, is there a way to empirically diagnose if it corresponds to wildfire or pan db URL?

[Remo]

Hi @marcelocampos 

The chance that it is queried by PAN-DB actually isn't very high - as long as these are individual URLs for every user. If it is PAN-DB someone would have to enter the URLs to the request category change website or a user has to open the url in the browser and as long as the category is still unknown, then the URL is automatically queried by PAN-DB. So wildfire is the likely the reason, as the firewalls forward the links in emails to wildfire when an email passes the firewall. So in your case there could be another firewall that forwards the urld to wildfire right?

You could write a custom app-id for these test-spam/phishing-emails and for these emails do not assign a wildfire forwarding profile. With this solution you do not have to disable wildfire completely for smtp traffic.

[marcelocampos]

Hello @Remo ,  thanks for you help.

According to what I understand and what I have investigated, the issue of the custom application is not clear to me, how is it configured? since the traffic is smtp tcp / 25. What differentiates it from normal smtp? and how is the bypass performed so that wildfire in the firewall does not analyze it?.

Thanks!.

Best regards.

[Remo · Accepted solution]

as far as I know such phishing tests, prior to the test you know exactly how the mail should look like and what the sender address will be. With these information you could configure a custom application based on smtp where you specify additional parameters to catch thes phishing-test-emails. When your custom application signature is working you can use this in the security policy to create another rule prior to the existing one and in this rule with the custom application you simply do not configure wildfire forwarding profiles.

Informations about creating custom applications you can find here:

• https://live.paloaltonetworks.com/t5/tech-note-articles/creating-custom-application-and-threat-signa...
• https://docs.paloaltonetworks.com/pan-os/u-v/custom-app-id-and-threat-signatures/custom-application-...
• https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClOQCA0

[marcelocampos]

Hello, @Remo.

I update the resolution of my problem, effectively I had to create 2 custom app id signatures, with the necessary patterns and parameters so that the traffic is identified as the custom app.

After confirming that the traffic is identified, continue generating the policies before the general flow of mail traffic.

Just a question, I actually see the queries pass to the app customized by the new rules, but I also see traffic pass with an incomplete app, this is a problem? Is it traffic that is specified? I understand that after the three-way handshake, not enough packets pass through to identify the application, but is it still traffic to the tcp / 25 port that is being allowed?

But functionally speaking, the pishing scenario is already productive, I greatly appreciate your collaboration and help.

Best regards.