|Product Support||Talos Support||Cisco Support||Reference +||Current Release|
|Gateway||Reputation Lookup||Open a support case||Secure Email Guided Setup|
|Cloud Gateway||Email Status Portal||Support & Downloads||docs.ces.cisco.com|
|Email and Web Manager||Web & Email Reputation||Worldwide Contacts||Product Naming Quick Reference|
|Cloud Mailbox||Notification Service|
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 : 22.214.171.124
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.
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
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 126.96.36.199 ( 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
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: 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.
I checked and we even have it with VOF disabled etc
In the docu it states :
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
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 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