By Elliott Hinson, Integrations Engineer, Endace
Are you actually using encryption, or does your software simply support it?
The answer may seem silly, but there lies a hidden amount of complexity behind this question that many users never have the need or opportunity to approach.
At the Cisco Live USA 2026 Security Operations Center (SOC) we found a great number of instances of users using technology that supported encryption. However, through some form of misconfiguration or a sheer lack of knowledge, they had configured their system to not use the encryption that their software did, in fact, support.
Sony DSLR FTP uploads
The first incident that I would like to discuss regards a user operating a Sony DSLR camera with automated photo upload enabled. Most DSLR cameras these days offer a Wi-Fi or Bluetooth connectivity option to offload photos for later processing.
While sifting through log data in Splunk, we discovered one user at the conference had configured automated image uploading to an FTP server in the cloud directly from their Sony DSLR camera.
Because this was configured to an FTP cloud server, and because we had the full packet data recorded via the EndaceProbe, we were able to inspect the username and password for the login credentials of this FTP server, which were being broadcasted in the clear over the network. Furthermore, thanks to Endace’s file carving ability, we were even able to reconstruct the original file uploads that the user had sent to the cloud over the Wi-Fi network, also unencrypted.
This represented one of the lower risk level incidents of supporting encryption without using encryption because the photos were intended to be used at the Cisco Live Conference, and they were not particularly private. One could imagine an incident, however, where much more private photos had been taken on a similar camera system, and those photos could be gathered by any nefarious actor with access to the Wi-Fi network.
This problem is particularly unfortunate, since a quick perusal of the Sony documentation for that particular model of camera shows that they very clearly do support encryption in the form of SFTP or FTPS. However, the user had not configured these and was unaware that they had been uploading their photos and password in the clear all week.
POP3 email, using the wrong port
This flavor of incident resulted in several users being invited into the SOC for us to inform them of the dangers of using unencrypted email. The POP3 protocol, as well as the SMTP protocol, do support encryption. However, once again we found users were connecting to their email servers with mail clients that had not been configured to enable encryption. It had merely asked them for a port number, and the user, not knowing which port number to use or why that may be important, had simply selected the default.
This was quite convenient for us, since their username for their accounts was their email address (and their email login password was also exposed). So, all we had to do was use the email address that we had seen passing, unencrypted, over the network to send them an email inviting them to the SOC to improve their security posture. For one of the users, it was as simple as changing the mail client to use the POP3 port that supported encryption.
This represented a much higher risk level of incident, since not only was the username and password for their email accounts in the clear, but we could also reconstruct emails for several users with this problem. That allowed us to uncover an additional problem. Some of these users were using a network monitoring solution that also did have encryption enabled and was sending email reports containing sensitive information about the state of their laptop computers in the clear. The issue was fixed by digging through a nested menu to check a box that enabled encryption.
What was interesting was that this network monitoring software was attempting to send unencrypted email reports to service providers that were actually returning error codes indicating that they did not support receiving unencrypted email. However, while the service providers were attempting to stop this unencrypted email system from being received, this did not preventing the user’s client software from sending their username and password in the clear for anyone to see.
Almost encrypted office-suite
This next incident was particularly tragic because of how much effort the user had clearly put into attempting to ensure their security by supporting encryption at multiple layers of their software stack.
Once again sifting through Splunk logs and corroborating those Splunk logs with the original packet data – available to us from the EndaceProbe in the Cisco Live SOC – we discovered a user who had configured a self-hosted Office 365 alternative on their Android smartphone so they could synchronize and manage contacts, images, and important documents using a self-hosted office suite server.
Initially, we thought this was a case of some user setting up an office suite on a home network and port forwarding that instance to the open internet using their home router. This obviously is not a recommended way to expose a private service to a remote user, but is still very commonplace due to users not fully understanding the risks of such a setup.
In this case, however, upon further inspection we discovered this office suite server was running behind a Cloudflare TLS termination gateway. We also saw that encryption for the WebUI had been configured correctly so attempts to access a non-encrypted version of the login page would automatically redirect to the encrypted page.
The one weak link in the system was that this particular Android client had been configured to use the unencrypted webDAV endpoint and was not following redirects because it was not a full web browser. It was at this point that we realized, tragically, that we were observing a user who:
- had properly put their self-hosted office suite system behind a Cloudflare DDOS protection gateway
- had properly configured TLS for the service
- had properly HTTPS redirection in place.
However, since they did not have port 80 configured to only allow HTTPS redirection and not allow any other access to the services via port 80, and because the android client was defaulting to using port 80 but not being redirected, the user was leaking sensitive credentials and business information for anyone to see.
Conclusion
To wrap all this up, and provide a moral to this collection of stories: just because your software stack supports encryption does not guarantee that it is necessarily using that encryption. You have to make sure that all software is configured correctly to be using the encryption that it will most likely already support. Furthermore, most firewalls and security systems won’t flag unencrypted traffic as it is not necessarily malicious nor is it inherently risky to the network operator.
The only way we discovered this was thanks to the use of Splunk logging and its integration with Endace’s always-on packet capture system. This allowed us to reconstruct the full packets for these incidents – which a smart PCAP system or a firewall triggered PCAP system would never have seen.
Acknowledgements
Our thanks go to the Cisco SOC team, led by Jessica Oppenheimer and Ivan Berlinson, for the opportunity to integrate EndaceProbes with the Cisco Live Agentic SOC architecture.
The SOC team is a collection of Cisco and Splunk experts across many domains who were a pleasure to work and innovate with, and we came away with a great appreciation for the power of the Cisco Security and Splunk tools.
The Endace and Cisco teams were able to prove out integration innovations and test them in earnest in a real-world environment in preparation for making them generally available to the market.
More from Endace, Splunk and Cisco in the SOC series
Read more from Endace about the Cisco Live USA 2026 SOC:
- Barry (Baz) Shaw: Using LLMs and Endace Full Packet Capture for Incident Response
- Stephen Donnelly: Never underestimate Cisco Live!
Read related Cisco Team Blogs from the Cisco Live USA 2026 SOC:
https://blogs.cisco.com/security/clamer-soc-2026
For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/
Event SOC Website
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html