Phishing campaign result is altered by WildFire profile as email-link is clicked by Wildfire sandbox

Phishing campaign result is altered by WildFire profile as email-link is clicked by Wildfire sandbox

11357
Created On 07/13/20 16:31 PM - Last Modified 04/24/24 09:46 AM


Objective


When WildFire receives an Elink, its API tends to visit the link, in the process the results are changed. For example, all links are clicked in a phishing campaign, hence the results are not accurate. Another example is a link that is clicked for automatic approvals.   There are two ways for WildFire to stop visiting the ELINK in the mail as follows. 
(a) Either you can stop the WildFire from clicking those links.
(b) Or you can stop at Firewall by filtering out the phishing campaign traffic using App-ID in a security rule that doesn't have a WildFire profile. 
 

Environment


  • All PAN-OS version
  • Phishing campaign email traffic  

Procedure


Option(a): You can stop the WildFire to click those links.

  1. You can open a support case using the support portal.
  2. List your company name, phishing company name, and domains/URL the user can visit by clicking the links. 
  3. We will add those domains to the WildFire whitelist. Even the ELINK has been submitted to WildFire by Firewall, WildFire will not visit links.  
Option(b): You can stop at the Firewall by filtering out the phishing campaign traffic using App-ID in a security rule that doesn't have a WildFire profile. 
This is a simple three-step process. 
  1. Create a custom application signature to match the phishing campaign emails by using email header fields.
Please note, once a "custom app" is created and traffic is identified with a custom app, an application shift happens. Most of the time the WildFire profile is not applied to the custom app.  That is why we don't need another security rule with a custom app and no wildfire profile.  Since the traffic base application is SMTP, this traffic will match with the first policy that allows SMTP.
      2. However, you can still create a security rule with a "custom application" in the Application tab for traffic monitoring. Although not needed, I would recommend it. 
      3. Finally, move this security rule to precede the currently matched SMTP rule.

The following example illustrates the knowbe4 phishing campaign, you can create a custom application signature for any application once a unique indicator and create a custom signature; these indicators can be a field in the header. Here is a link that describes how to create a custom application.

Step:1  

 1.Open the UI->open objects-> Application-> click on “Add”
 2. Give the name of the signature, select the category -> general-internet, Parent App->smpt, select the other fields.

              configure custom app

           3. Move to next tab, “advance”, and select scanning as needed for Filetype, virus, and Data patterns

             advance tab
 
4. Select the Signature tab and fill in the required fields.
  • Click on the "Add" and give a name.
  • Click on the “ Add or condition”,  and do the following selection:
  • Operator-> Pattern match
  • Context -> email-header
  • pattern-> X-PHISHTEST { Please note this header can be changed, you can see the current header by selecting the "show original" email}  
signature selectionsignature config

6. You can add more conditions in the custom app based on the email header. While adding the second condition, you can use "or" or "and" condition. 
 
Step:2
          1. Create a security policy with the custom application.

Step 3:

  1.  Move this policy before any other policy that can match such traffic, so this policy will hit first. 
Other users also viewed:
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000008UoBCAU&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language