cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2379
Views
0
Helpful
14
Replies

URL Reputation question regarding ESA opening the url in background?

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

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

 

 

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

KevinNg59926
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.

rolelael
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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: