Unwanted email clicks and page views caused by Palo Alto Networks Wildfire

[Anonymous]

Recently we've started noticing that companies using Palo Alto Networks 'WildFire' product are generating automatic email link clicks and page views.

Attempts by our IT team to reach out to PAN to be added to some sort of safe/verified sender whitelist to prevent this from happening anymore have been unsuccessful.

Anyone have any thoughts or advice on how to work around this? Because of this we've been unable to score email clicks or page views because so many are fake. Suppressing anyone with the inferred company 'Palo Alto Networks' (as an ISP) have cut it down, but we still can't behavioral score all those organizations.

Marketo is uninterested in reaching out to Palo Alto Networks on our behalf

[Justin_Cooperm2]

Hi Mitchell,

I can assure you were actually working on this as we speak. We've been seeing an increase in bot clicks as well and are doing some analysis to see how we can limit these in the future. Shoot me an email at jcooperman@marketo.com because I'd be interested in learning what you've identified in your research, in terms of the characteristics of user-agents that you're seeing.

Justin

[Anonymous]

thanks Justin. I will get in touch

[SanfordWhiteman]

Attempts by our IT team to reach out to PAN to be added to some sort of safe/verified sender whitelist to prevent this from happening anymore have been unsuccessful.

I should think so!  The idea is to stop malicious emails with first-hop and/or deep-hop links to malware/ransomware/phishing sites.  This is very serious business. I was at a risk meeting today in which this was discussed with grave concern. 

It would be catastrophic to whitelist based on an easily forged From: header.  A whitelist by IP address for all PAN customers would also be reckless, since malicious email could be sent from hijacked mailservers or other hosts behind those IP addresses. The only whitelisting measure that makes (a little) sense would be for an individual subscriber to check a checkbox that says "I trust that emails from these IPs will never contain a link to a hijacked site." (I wouldn't check that box myself. Maybe some would, but I'd wonder then why they're using the service at all.) 

Ultimately the approach needs to be not evasion, but cooperation + applied intelligence.  (And not user-agent detection: if these people are stupid enough to use identifiable user-agent strings, they should be replaced by people who understand their own company's mission!)  An example of a non-evasive tactic would be skipping email and web activities that occur before an email is delivered at the SMTP level.  This does not disrupt or manipulate the service's inspection of links, but allows for triage of human vs. bot activities on Marketo's end.  All the same, it will not catch all cases, because not all inspection happens during the initial SMTP envelope (WildFire supports POP3 inspection, for example, and there are also multi-hop MX-to-mailbox architectures in play).

[Anonymous]

I saw this somewhere: "WildFire does not forward files that are known or signed by a trusted file signer." And thought that might be an option to avoid this. Tryin to learn! Thanks for your comments!

[SanfordWhiteman]

Signed files are way different from signed URLs, though.

Binary files are monomorphic (speaking here of bytes on disk, not of runtime footprint).  That is, the file on disk that's signed by a public code signing cert is a distinct, unchanging series of bytes. Signing itself doesn't prove something is safe, but if the cert is, for example, Microsoft's, you can agree to trust their internal security + release process, trust that they are the ones who originated the file, and trust that it will always be the same file.

In contrast, a URL is explicitly polymorphic in terms of the bytes in an HTTP response. It's just a pointer to whatever the server feels like dishing out. So even if you "vouch for" http://www.example.com/mylandingpage.htm at 12:00pm, the person operating www.example.com could send you a different, malicious file at 12:01pm. (This is the same reason that a deep scanner like PAN must not use a distinct user-agent string if it wants to be effective, since it's trivial to switch between an innocent page and a malicious page based on characteristics of the request.)

One can sign the contents of an HTTP response.   But I question whether a multi-tenant application like Marketo could ever be trusted to deep-inspect and vouch for all linked content.  That's a really tall order and would, among other things, mean that third-party web content needs to be prefetched and that web content couldn't be changed after an email goes out.  Maybe Marketo could strike an agreement with Palo Alto so the outside service would pre-crawl URLs before they're personalized; if there are any failures, the email would not be sent. But you still have the problem of web personalization, a natural feature of digital marketing.  If I make an anonymous request and sign response bytes A as safe, that doesn't mean lead 123 will see those same response bytes. Do you trust that response bytes B must also be safe because the sender seemed to act in good faith originally?  Or do you err on the side of suspicion, as security software should?

In all, this is a very tough nut.

[Anonymous]

Is there any easy way to filter reports/automation where we see non-human type activity from subscribers? Even manually when we ID potential companies who have deployed this?  One of the most troubling aspects of this is the possibility of significant perturbations in reporting or automated responses as the result of non-human activity.

[Anonymous]

It's possible to create a custom field to manually ID records with non-human activity and filter on this for reporting.