cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Cisco Secure Email Support Community

Product Support Talos Support Cisco Support Reference + Current Release
Gateway Reputation Lookup Open a support case Secure Email Guided Setup
Gateway: 14.2.0-616
Cloud Gateway Email Status Portal Support & Downloads docs.ces.cisco.com
Email and Web Manager: 14.2.0-203
Email and Web Manager Web & Email Reputation Worldwide Contacts Product Naming Quick Reference
Reporting Plug-in: 1.1.0.136
Encryption Bug Search
Encryption Plug-in: 1.2.1.167
Cloud Mailbox Notification Service
Outlook Add-in(s): More info

941
Views
0
Helpful
14
Replies
rolelael
Beginner

URL Reputation question regarding ESA opening the url in background?

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 :  146.112.163.35

 

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
Ken Stieers
VIP Advocate

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

 

rolelael
Beginner

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 146.112.163.35 ( 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. 

 

https://docs.ces.cisco.com/docs/url-rewriting-and-analysis#cloud-url-analysis 

 

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: https://www.cisco.com/c/en/us/td/docs/security/ces/user_guide/esa_user_guide_13-5/b_ESA_Admin_Guide_ces_13-5/m_service_logs.pdf

 

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

 

Thanks!

-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