KnowBe4 Phishing Training and WildFire testing

[Steve27596]

My company uses KnowBe4 for email phishing training.  During our current campaign we discovered that test emails were getting opened and attachments or hyperlinks were triggered identifying a test failure.  This happened when the user could not have opened the email as they were not at work, nor did they have remote access.  Upon further inspection I discovered the attachment had been tested via WildFire which caused the false positive.

Is anybody out there using KnowBe4 and found a way to get around this issue?  It invalidates IT's stance when our own tools are creating a false positive.  I am not trying to discredit KnowBe4 or compare with other products, because I am sure this would happen with any product that sends test email that flow through the firewall.

Thanks in advance,

-Steve

[SCantwell_IM]

I am not using the solution you provided, but from a WF perspective, you can always change the verdict from malicious to benign.

The FW and WF solution is working as expected.  You WANT the WF to filter out malicious traffic.

What I would probably do (if this is a training environment) is simply NOT have a WF profile attached to the inbound mail rule, now WF cannot prematurely filter those out.

Just trying to helpful.  😛

[Gmileon]

Our situation is similar to the OP's. When the KnowBe4 phishing tests hit the PA and are inspected by Wildfire, they often generate a false positive. Exacerbating the issue is our use of a cloud-based antispam solution. The inbound mail rule on the PA only sees the 2 IP's owned by our antispam solution. So there's no way to create an IP exception in Wildfire for KnowBe4 emails. Wildfire doesn't parse email headers so there's no way to write an exception that way either. Disabling Wildfire is obviously not an option. Dumping the cloud-based antispam solution would be trading one set of problems for another. We're stuck.

I'd like to see Palo Alto built more exception capabilities into Wildfire. Being able to write an exception based on email headers would help a lot. This has to be a pretty common issue for PA customers. I'm surprised they haven't done more to address this issue.

[aleksandar.astardzhiev]

Hi @Gmileon ,

Have you tried to create custom application? If I remember correctly KnowBe4 is adding additional email header to the test email to indicate that this email is not real phishing. I am wondering - if you create custom smtp applicication with signature that is looking at the email headers. Put that custom application to new rule above your existing rule and simply not enable the WildFire profile.

When email is received the new rule will allow some traffic to pass, to completely identify the application. If KnowBe4 header present in the email it should keep using the rule without wildfire profile. But if the the header is not present, application should shift to default smtp and no longer match the bypassing rule and fall to the rule below that has wildfire profile enabled.

What bothers me is that to completely identify the custom application SMTP session needs to be established and part of the actual message received by the firewall. Will it still send the whole email/data to Wildfire if matching rule switch in the middle of data/email process.

[Gmileon]

Hi Alexander!

Yes, I worked with PA support about a year ago to create a custom application similar to what you have in the screenshot. It seemed to help a bit at first. Not perfect but a small decrease. After a while the false positives increased again. I'm not sure the custom app is working at all anymore - based on the number of FP's. It's a workaround IMO. I'll revisit and perhaps open a new ticket with support.

Appreciate your input. If you or anyone else that reads this has any other ideas, I'd love to hear them. Thanks!

George