Exfiltration Over a Blocked Port on a Next-Gen Firewall

More and more organizations are adopting proactive cybersecurity validation technologies to verify that their security measures are working as expected and reduce risk before an attack. Knowledge of the usefulness of these technologies is spreading, which is great.

What is less known, though, is how these technologies can uncover industry-wide structural flaws in services provided by vendors. And of course, provide remediation! Sometimes, these discoveries can even come from the customer success department.

As a customer success lead and security advisor at Cymulate, I was recently lucky enough to uncover such a flaw.  

Feeling Protected? Guess Again  

Cymulate offers the most comprehensive platform for threat validation. For example, the data exfiltration module tests controls against exfiltration over network channels, email, removable devices, and cloud services. Usually, our customers run simulated data exfiltration attacks with the platform, and if a gap is found, they remediate it according to our easy-to-digest guidance. But sometimes, it is not as straightforward. 

Recently, a customer ran a data exfiltration assessment over network protocols and the Cymulate platform alerted them that data was exfiltrated through Telnet (port 23). The customer checked with their Next-Gen Firewall (NG-FW) vendor who answered that there was no way data could be exfiltrated through that closed port. So, the customer reached out to me to investigate further with this email: 

Working as a customer success team lead here at Cymulate, I encounter this kind of situation a lot. A favorite part of my job is exploring, along with the customer, why a simulated attack succeeded and what they can do to prevent it from happening when faced with a real threat. This is the true value of a security validation platform—finding the gaps and vulnerabilities of your security stack and fixing them before an attacker takes advantage. 

How Does Cymulate Assess for Data Exfiltration? 

Before I continue with the story, it will help to have some background about how Cymulate’s exfiltration over alternative network protocol works. Let’s look at Telnet as an example. 

During this type of data exfiltration assessment, Cymulate connects to a remote C2 server over port 23 (Telnet port), initiating a 3-way handshake. Upon the handshake completion, the session is established, and data is sent as packets over it.  

At the same time, the agent hashes the exfiltrated data and sends it over the agent-to-cloud communication channel to the C2 server. The C2 server receives the hash and the exfiltrated data and compares them to ensure that the original data has been successfully and completely exfiltrated. Hash validation does not leave room for mistakes – identical hashes are proof of data exfiltration.   

Getting Around the Blocked Telnet Port 

As we needed more data to further our investigation, we asked the customer to share their NG-FW dropped logs with us.  To verify that the network traffic indeed occurred as we thought, we captured packets using Wireshark and clearly saw the traffic: 

We looked again at the email the customer sent us after calling his NG-FW vendor and these words caught our attention: “Post 3-way handshake…” The NG-FW permitted the 3-way handshake and allowed us to establish a connection to the C2 server. After the handshake, the NG-FW detected that our traffic was not Telnet protocol, but just a TCP socket of port 23, so the connection was reset. 

Yet, looking at the packet captures obtained from the NG-FW vendor to analyze successfully exfiltrated data sessions, we were amazed – the NG-FW allowed them to be exfiltrated! 

But why? 

And here comes the interesting part – without exception, all successfully exfiltrated data packets were in small formats (such as plain string or TXT files), smaller than the MTU (maximum transmit unit). This meant that these data types could only be exfiltrated in single packets, rather than multiple, to avoid exceeding the MTU size.  

When asked about this finding, the NG-FW vendor acknowledged that “to determine which application is being used, and whether the session aligned with the protocol’s standard, the NG-FW must allow at least one packet to pass.”  

This potential exfiltration path appeared to be by design and specific to the NG-FW workflow. Surprised by this unexpected flaw-by-design, we tested it with many leading NG-FW vendors and successfully reproduced the exfiltration techniques with all of them.  

The transition from Firewall to NG-FW introduced a new approach and a new level of security. It allows inspection into the traffic instead of focusing exclusively on the transport layer. However, allowing some packets to pass to identify which application is used and whether it violated the policy or not, opened a breach. For an attacker, this “grace packet” is good enough to exfiltrate a small chunk of data or even communicate with a C&C server for additional instructions.   

Practical Steps to Keep Your Next-Gen Firewall from Allowing Exfiltration 

Here are some steps you can take to reduce the risk of data exfiltration and still benefit from the advanced NG-FW technology. When setting your NG-FW policy: 

1. Limit both service (port) and application.  

2. Limit source and destinations.  

3. Implement network least privilege, allowing traffic between two points over a specified port exclusively based on “need to access” logic. 

Cymulate Can Help 

Security controls are vital to ensure your organization is safe from an attack but validating that those controls are set up and working as they should is just as important. Sometimes validation can even lead to exposing a fault within the control itself and remediation will immediately reduce your risk of exposure.