Showing results for 
Search instead for 
Did you mean: 

URL Reputation question regarding ESA opening the url in background?

Level 1
Level 1

We have url filtering in place for several scores. Works fine


But we use a phishing tool ( external ) to test our users if they click on a 'phishing' url in an email they receive from the attacking tool


We noticed recently that Cisco seems to open the url in the background ( or in Talos or whatever ) that triggers it , just like a user would click on it.  This gives false positives


We thought 1st O365 is doing it due to their safelinks etc, but even if we quarantine the mail ( so not deliver it to O365 ) the link is being triggered ( the phising application is reporting a cisco ip that triggered the click : not one of our ip's , but a strange one :


If we look that one op via Talos its Cisco OpenDns or something.... and it is even listed on a blacklist....


We also tried disabling VOF ( outbreak filter ) in the mailpolicy for he sending ip's of the phishing app, so that VOF does not trigger it somehow. But even without VOF interfering,a click occurs..


And we cannot whitelist the specific urls , since we rewrite them for example to https://rewrite/originalUrl .


We want to test if users take the hassle to remove the rewrite part from an url and then open it


Any ideas what might trigger the click on the url ? And the strange cisco originated ip ?


And the tool is reporting the client whom clicks as Chrome 98.0.4758 on Windows. 

14 Replies 14

Yes, Cisco is getting the URLs and sandboxing them in the cloud to see what they are.

Which product are you using?

What do you mean  which product ? The anti phishing tool ? That's cymulate


Cisco esa version is :  14.0.0 for Cisco C390 build 698

Just wanted too make sure you weren't on Cloud Mailbox Defense as I don't know much about it... and I hadn't had enough coffee.

So we use Knowbe4, and have a policy that has no url checks of any kind (usually in content filters) and no outbreak filters, no spam filter enabled.

Strangly it is, that it is not always triggered ( cache ? ) 


And before the 19th of April we didn't had this behaviour


SO if cisco sandboxes it in te background we should have seen this behaviour before

New content filter? Upgrade to 14?

No not recently. No changes on ESA


Level 1
Level 1

We even tested with a mailpolicy, were NO CF were triggered, and every service off ( no antispam, VOF etc ) . And still from time to time the phishing mail gets triggered. Seems by ip ( Cisco OpenDns ) according to the logs in the phishing tools.  ANd always from the same browser version ( a browser we don't have at our company ) ; Chrome 98.0.4758 on Windows


Very strange

I've heard similar stories recently and this is most likely our Cloud URL Analysis (CUA) feature scanning them. Effectively sandboxing them and crawling the page, and hence you see a 'clicked on link' type of behavior. 


I was informed that disabling Service Logs may be a potential workaround, but, this would also decrease overall efficacy and is not recommended. 


You can read more about Service Logs here:


If you want, feel free to open a TAC case and we can help take a closer look. 



-Dennis M.

Hello dmccabej;


I checked and we even have it with VOF disabled etc


In the docu it states :


  1. Outbreak Filters must be enabled and configured
  2. Web Interaction Tracking must be enabled in Outbreak Filters
  3. Service Logs must be enabled
  4. Depending on the version of AsyncOS deployed, a Message Filter may be needed for URLs included in attachments
    • Message Filter dependency is removed as of AsyncOS 14.0

We truned off everything on our 'prod' environment, and still have the issue from time to time ( not on every similar email )


in our 'TDA' environment, everything is on, and we don't have an issue ..Exactly the same version etc. Very strange


Service logs is indeed enabled, but so it is on our TDA



Thanks for confirming. You can test the workaround I suggested and see if that helps. Else, I'd recommend a TAC case and we can assist. 

Workaround does not help. They will first discuss this with the phishing tool to see if they can whitelist cisco's ip range for clicks ( its a specific range )

I'd suggest checking with your phishing vendor to see if they have an exception list for this.
KnowBe4 has one...

Level 1
Level 1

I have the same issue lately as well. Will be good to know what the solution is to prevent a possible false positive.

Level 1
Level 1

I found the possible culprit


There is a setting : Enable sharing limited data with the Service Logs Information Service (Recommended)


I disabled that one, and found that there were no more ' click actions ' reported for urls ( sent  in via pishing campaign )


Hope anyone else can test it also and give feedback