TLS Fingerprinting: Rethinking Encrypted Traffic Analysis Strategies
There seems to be some confusion about the appropriate way to use TLS fingerprinting in an environment.
Anytime an SSL library, a library that uses any of those libraries, an OS or the application itself is updated or changed, there’s a good possibility that the fingerprint for that application will change. Fingerprints also change for the same application, depending on a few conditions. That’s for legitimate applications.
Malware, on the other hand, have no reason to reuse the same SSL libraries for communication, nor do they have to worry about compatibility with anything aside from their C2 servers. During my research (which can also be confirmed by looking at pcaps from malware traffic analysis), I often saw JA3 fingerprints changing for the same piece of malware several times in the course of the same infection. This was due to different modules of the malware using different methods for SSL communication and also the traffic meeting the ‘conditions’ mentioned earlier. Any new malware could and probably will have a fingerprint that is entirely different from the malware that preceded it. This differs from legitimate applications that tend to follow a similar pattern from version to version.
It’s a much more effective solution to attempt to identify legitimate applications and “other” applications to identify malware and other malicious traffic. Using JA3 for this may be a little more difficult since it already creates many fingerprints for the same client since it does not take into account conditional TLS fields. However, the way this process has previously been described makes the randomization method sound extremely noisy. So, even with an outdated method such as JA3, I expect it may be possible to identify this kind of randomization just by identifying an abnormal number of “new” fingerprints on your network.
Using more mature methods of fingerprinting makes identifying this supposed evasion technique even more trivial since we aim to detect applications based on the same identifying information used in traditional fingerprinting (TLS fields) and cross-referencing it with other traffic with similar traits and the behavior of the traffic involved. There are methods that can be used to identify the SSL library being used (you may notice that Akamai previously said it deduced the malware was Java-based, so the company is probably doing something similar, albeit manually), the browser likely being used, whether it is a browser or a command-line tool and more, regardless of what the specific fingerprint obtained from the TLS information is. In some cases, it’s even possible to deduce this information from the extensions used and their values, which means that randomizing the cipher suites would do absolutely nothing to avoid detection anyway.
It is a much better approach, in general, to use TLS fingerprinting to identify known legitimate applications and then tag everything your fingerprinting methods can’t figure out as potentially interesting (and enhance those results with additional detection mechanisms). Using that approach, the randomized cipher suites would stick out like a skyscraper in a haystack. This is because their other fields will probably be identical, so it would be extraordinarily obvious that they have the same client source. If you really wanted to avoid TLS fingerprinting methods, you’d be much better off attempting to blend in with legitimate traffic by spoofing their fingerprints or using the same libraries.
